Guida pratica NemoClaw per operazioni OpenClaw sicure nel 2026

La maggior parte degli stack per agenti AI tratta ancora la sicurezza come una correzione da applicare dopo la dimostrazione. NemoClaw parte dall’assunzione opposta e rende isolamento, policy e routing le impostazioni predefinite fin dal primo giorno.

OpenClaw rimane l’assistente, mentre OpenShell rimane il livello di enforcement, e NemoClaw agisce come il collante opinionato tra di loro. Questo collante è importante perché rende il percorso più sicuro più facile da installare, più semplice da osservare e molto più difficile da saltare quando si è in fretta.

È esattamente per questo che NemoClaw è importante nel 2026. Non è solo un altro wrapper attorno a un agente LLM, poiché è progettato come uno stack di riferimento per eseguire assistenti OpenClaw sempre attivi all’interno di container OpenShell sandboxed, con inferenza instradata, controllo dell’egress basato su policy e strumenti per il ciclo di vita integrati fin dall’inizio. Se si desidera un contesto più ampio su dove si colloca, iniziare con il Centro AI Systems e la Panoramica del sistema OpenClaw è il punto di partenza ideale.

C’è una dura verità che non si dovrebbe nascondere per il gusto dell’hype. NVIDIA classifica NemoClaw come software alpha in anteprima iniziale, a partire dal 16 marzo 2026, e avverte esplicitamente che le interfacce e il comportamento potrebbero ancora cambiare tra le release. Trattatelo come uno strumento di laboratorio serio, non come mobili di produzione finiti.

Cos’è NemoClaw e quando usarlo

NemoClaw esiste per un lavoro operativo specifico, non per teatro sperimentale. Offre un modo pratico per eseguire un assistente OpenClaw sempre attivo con guardrails per l’accesso alla rete, al filesystem, ai privilegi dei processi e al routing dei modelli. Se si è mai guardato a un agente autonomo pensando che non dovrebbe avere accesso casual all’host, NemoClaw è una risposta forte a tale disagio.

Lo stack è più facile da comprendere quando si separano i livelli:

• OpenClaw è il runtime dell’assistente, gli strumenti, la memoria e il comportamento all’interno del container.
• OpenShell è l’ambiente di esecuzione che fornisce il ciclo di vita della sandbox, il gateway per lo storage delle credenziali, il proxying dell’inferenza e l’enforcement delle policy.
• NemoClaw è lo stack di riferimento opinionato che onborda, configura e opera OpenClaw correttamente all’interno di OpenShell.

Questa distinzione è importante perché spiega lo scopo del prodotto. NemoClaw non sta cercando di sostituire OpenClaw. Sta cercando di rendere OpenClaw sopravvissibile in ambienti reali.

I casi d’uso tipici sono ovvi e sensati:

• eseguire un assistente sempre attivo con egress controllato
• testare il comportamento dell’agente prima di concedere un accesso più ampio
• spingere un assistente sandboxed su un host GPU remoto per un’operazione persistente

Il mio parere schietto è questo. Se si vuole solo una demo da buttare via, OpenClaw raw è più semplice e veloce da far partire, e il quickstart di OpenClaw è la via più rapida. Se si vuole qualcosa che si comporti come se appartenesse a una macchina reale, NemoClaw è la scelta più seria perché le sue impostazioni predefinite sono costruite per gli operatori invece che per screenshot.

Le funzionalità di sicurezza e operations di NemoClaw che contano

Una lunga lista di funzionalità è economica. La lista giusta delle funzionalità non lo è. Queste sono le capacità che cambiano realmente come si opera il sistema.

NemoClaw supporta diversi percorsi di inferenza, inclusi NVIDIA Endpoints, OpenAI, Anthropic, Google Gemini, endpoint compatibili con lo stile OpenAI e Anthropic, e Ollama locale. Per gli endpoint compatibili, l’onboarding valida l’endpoint con una richiesta di inferenza reale perché molti servizi copiano la forma OpenAI ma falliscono sul comportamento runtime reale. Se si sta scegliendo prima una strategia di runtime di inferenza, la più ampia Guida all’hosting LLM per il 2026 è un utile compagno. Esistono anche percorsi sperimentali per NIM locale e vLLM locale, ma sono dietro un flag ambientale per un motivo, quindi usarli per valutazione invece che per workload lunghi non supervisionati.

Il modello di sicurezza è la vera notizia. NemoClaw inizia con egress deny-by-default, mantiene le credenziali del provider sull’host, usa una configurazione OpenClaw read-only all’interno della sandbox e permette agli operatori di revisionare richieste di rete sconosciute nella TUI di OpenShell. Non è spettacolare, ma è esattamente il punto, perché stack di agenti spettacolari sono comuni mentre superfici di controllo noiose sono la risorsa scarsa in produzione.

Le impostazioni predefinite che non si dovrebbero rilassare casualmente

NemoClaw ha delle escape hatch. Dice anche, molto educatamente, quando si sta per fare qualcosa di stupido.

I maggiori foot-gun sono questi:

• --dangerously-skip-permissions scambia la postura sandbox predefinita con una permissiva
• aggiungere entry di policy baseline permanenti per richieste one-off rende il privilege creep normale
• scrivere direttamente in /sandbox/.openclaw è il modello mentale sbagliato perché quella configurazione è destinata a rimanere bloccata
• usare openclaw agent --local come se fosse la modalità operativa standard è una cattiva abitudine per qualsiasi cosa security-sensitive

L’ultimo punto merita enfasi. La modalità locale è conveniente per smoke testing e controlli one-off, ma non è la postura che si dovrebbe normalizzare per un assistente sempre attivo che ha permessi reali.

Quickstart di NemoClaw per la prima sandbox

Prerequisiti

Ecco la baseline pratica prima di perdere un pomeriggio fingendo che un laptop piccolo sia sufficiente. La pagina ufficiale dei prerequisiti attualmente elenca Node.js 22.16 o successivo e npm 10 o successivo in aggiunta ai requisiti runtime Docker.

Anche la matrice runtime testata è diretta:

Se si è su macOS, installare prima gli Xcode Command Line Tools. Se si è su Linux, assicurarsi che Docker sia effettivamente in esecuzione e che l’utente possa comunicarci senza drama di permessi.

C’è anche un dettaglio sulle risorse che cattura molti utenti per la prima volta. L’immagine della sandbox è di circa 2,4 GB compressa, e la pipeline di export può consumare temporaneamente memoria sufficiente per triggerare OOM su macchine deboli. Se non si può aggiungere RAM, aggiungere almeno 8 GB di swap è una workaround ufficiale, anche se rallenta l’onboarding. Per piccole box AI dedicate, la Panoramica NVIDIA DGX Spark dà un punto di riferimento concreto per deployment sempre attivi locali.

Installazione e onboarding

Il percorso di installazione ufficiale è intenzionalmente semplice:

curl -fsSL https://www.nvidia.com/nemoclaw.sh | bash

Poi confermare che il CLI è presente:

nemoclaw --help
nemoclaw --version

Da lì, il lavoro vero è l’onboarding. nemoclaw onboard guida la creazione della sandbox, il setup del provider e l’applicazione della policy in un flusso guidato, motivo per cui dovrebbe essere il punto di ingresso predefinito del ciclo di vita.

nemoclaw onboard

Durante l’onboarding si sceglierà un provider di inferenza, un nome per la sandbox e un tier di policy. La scelta del tier è più importante di quanto la maggior parte delle persone si aspetti:

• restricted mantiene solo la sandbox base
• balanced è il default e aggiunge tooling di sviluppo plus accesso correlato alla ricerca web
• open aggiunge accesso di terze parti ampio, inclusi servizi di messaggistica e produttività

Il mio consiglio non è sottile. Per un assistente sempre attivo, iniziare con la postura più piccola che possa funzionare. Se significa restricted, bene. Aggiungere solo ciò che l’agente dimostra di aver bisogno.

Se si vuole un run scripted, il flusso non-interattivo è così:

NEMOCLAW_POLICY_TIER=restricted \
nemoclaw onboard --non-interactive --yes-i-accept-third-party-software

Usare un nome per la sandbox sensato. NemoClaw si aspetta caratteri alfanumerici minuscoli e trattini. Se si continua a provare ad essere astuti con i nomi, il validator vincerà.

Prima connessione e primo prompt

Una volta completato l’onboarding, connettersi alla sandbox:

nemoclaw my-assistant connect

All’interno della sandbox, aprire l’interfaccia terminale UI:

openclaw tui

Se si vuole solo un smoke test di un messaggio, si può fare così:

openclaw agent --agent main --local -m "hello" --session-id test

Detto questo, non confondere uno smoke test con un modello operativo. Per un uso reale day-two, preferirei essere onesti sul sistema e usare la TUI plus monitoraggio host-side invece di normalizzare --local.

Operations di NemoClaw che contano al giorno due

Una volta che la sandbox esiste, NemoClaw diventa uno strumento di operations, non solo un installer. Questi sono i comandi che tirano il loro peso.

Cambiare accesso di rete dopo l’onboarding

Qui è dove NemoClaw è visibilmente migliore dei setup di agenti ad hoc. Invece di allentare tutti i controlli dopo il primo blocco, si può mantenere una baseline vincolata e poi approvare o persistere solo ciò che è necessario.

Per destinazioni bloccate one-off, usare la TUI:

openshell term

Questo permette di revisionare host, porta, binary e metodo o path information quando disponibile. Le richieste approvate restano disponibili per la sessione corrente, ma non diventano policy baseline permanente. È una feature, non un bug.

Per cambiamenti duraturi, aggiungere o rimuovere preset:

nemoclaw my-assistant policy-add github --yes
nemoclaw my-assistant policy-remove github --yes

Se serve qualcosa di più specifico di un preset stock, definire un’entry di policy custom e mantenere protocol: rest con restrizioni di metodo e path per HTTP APIs quando possibile. Regole solo L4 sono un compromesso. Fingere altrimenti rende solo le policy cattive sembrare ordinate.

Cambiare modelli senza rebuildare la propria vita intera

Se si rimane nella stessa famiglia di provider, i cambiamenti di modello sono semplici:

openshell inference set --provider openai-api --model <model>

Poi verificare il risultato:

nemoclaw my-assistant status

Se si sta cambiando tra famiglie di provider, la storia diventa più opinionata. Non si sta solo girando un puntatore runtime. Si sta cambiando il route e alcune configurazioni di immagine baked. In pratica, significa che si dovrebbe trattare il cambiamento come una riconfigurazione reale e rerun onboarding o ricreare la sandbox con gli override appropriati.

Il costo è un altro motivo pratico per mantenere questo workflow pulito. Le pagine di pricing pubbliche ad aprile 2026 mostrano grandi spread tra tier di modelli, come GPT-5.4 mini a dollari a cifra singola bassa per milione di token di output versus tier frontier premium che costano un ordine di grandezza in più. Il pricing di Anthropic varia similmente dalla classe Haiku alla classe Opus, e il più ampio shift di pricing è coperto in Claude, OpenClaw, e la Fine del Pricing Piatto per Agenti. Se serve un playbook pratico per spendere meno in queste condizioni, vedere Strategie di ottimizzazione token per il controllo costi LLM, perché essere capaci di cambiare modelli senza caos di policy è un vantaggio operativo, non solo una comodità.

Capire cosa persiste e cosa no

Lo stato utile vive nel workspace sotto /sandbox/.openclaw/workspace/. Questo include file come AGENTS.md, IDENTITY.md, MEMORY.md, SOUL.md, USER.md, e la directory memory/ di note daily. Se si stanno progettando assistenti più longevi, il Centro AI Systems Memory e il Confronto provider di memoria per agenti sono letture successive utili.

La buona notizia è che i restart della sandbox preservano questo stato. La cattiva notizia è che nemoclaw destroy non si cura dei tuoi sentimenti. Distruggere la sandbox cancella il suo volume persistente e il tuo workspace va con essa.

È per questo che i flussi di rebuild e snapshot contano. NemoClaw è usabile precisamente perché non costringe a scegliere tra upgrade e perdere la memoria dell’assistente.

La regola che tutti imparano tardi

Ecco la regola che salva più tempo una volta internalizzata. Una quantità sorprendente di configurazione NemoClaw è configurazione build-time o image-time, non stato mutabile live.

Questo spiega diversi comportamenti che confondono gli utenti nuovi:

• i canali di messaggistica sono baked nell’immagine e comandi host-side rebuildano la sandbox quando i canali cambiano
• il path di configurazione OpenClaw all’interno della sandbox è read-only
• alcune impostazioni auth, proxy e porta richiedono re-onboarding o ricreazione della sandbox
• editare lo stato host-side corretto è solitamente la mossa corretta, mentre editare da dentro la sandbox è solitamente quella sbagliata

Una volta accettato quel modello, la piattaforma smette di sentirsi random e inizia a sentirsi deliberata.

Troubleshooting di NemoClaw che salva realmente tempo

Problemi di installazione e piattaforma

Problemi runtime e policy

Se l’agente non può raggiungere un host esterno, la prima risposta di solito non è che il provider è rotto. La prima risposta di solito è che la destinazione non è ancora permessa dalla policy, specialmente su sandbox nuove.

Aprire la TUI:

openshell term

Se la richiesta è legittima, approvarla per la sessione o aggiungere l’entry di policy custom o preset corretta permanentemente.

Se l’onboarding fallisce perché la porta 18789 è occupata, trovare e killare il conflitto:

sudo lsof -i :18789
kill <PID>

Se una release più vecchia ha lasciato un forward SSH orphaned behind dopo un destroy, le versioni attuali di NemoClaw possono pulire quello automaticamente durante re-onboard. Quelle più vecchie potrebbero aver bisogno del kill manuale.

Se il dashboard non carica dopo aver impostato NEMOCLAW_DASHBOARD_PORT, rerun onboarding su una release corrente con la porta desiderata. Build più vecchi avevano un bug dove l’host rispettava la porta custom ma la sandbox ascoltava ancora su quella default.

Memoria, rebuilds e canali

Se la creazione della sandbox muore con exit code 137, probabilmente si è hit una condizione out-of-memory durante il percorso image push. Aggiungere swap o usare una macchina con più RAM. La macchina economica non era realmente economica se ti è costata un giorno.

Prima di cambiamenti rischiosi, snapshot prima:

nemoclaw my-assistant snapshot create --name before-upgrade

Se serve upgradeare la sandbox ma mantenere lo stato dell’assistente, rebuildare invece di destroy:

nemoclaw my-assistant rebuild --yes

Se si ruotano token Telegram, Discord o Slack, rerun onboarding così NemoClaw può rilevare il cambiamento di credenziali e ricreare la sandbox correttamente.

E se si prova a fixare canali da dentro la sandbox con comandi openclaw channels, fermarsi. La configurazione del canale è baked nell’immagine e il path di configurazione è read-only. Usare i comandi host-side invece:

nemoclaw my-assistant channels add telegram
nemoclaw my-assistant channels remove telegram
nemoclaw my-assistant channels stop telegram
nemoclaw my-assistant channels start telegram

Inferenza e dolore di modelli locali

Endpoint compatibili sono la fonte classica di falsa fiducia. Solo perché un server espone un API che sembra OpenAI non significa che supporta il comportamento streaming che OpenClaw si aspetta.

Se l’onboarding è successo ma chiamate runtime falliscono su un endpoint compatibile, rerun onboarding e lasciare che NemoClaw re-probi l’endpoint. Non assumere che un override di config solo sia sufficiente.

Per backends locali, tenere d’occhio salute e problemi di binding:

nemoclaw my-assistant status

Se health check di inferenza locale sembrano sbagliati su release più vecchie, risoluzione IPv6 versus IPv4 potrebbe essere il colpevole. Se Ollama si comporta male in WSL, assicurarsi che l’integrazione Docker Desktop stia funzionando e considerare aumentare OLLAMA_CONTEXT_LENGTH prima di restartare ollama serve.

Se tutto il resto fallisce, collezionare diagnostics invece di indovinare:

nemoclaw debug --sandbox my-assistant --output ./nemoclaw-debug.tar.gz

Questo è un bug report molto migliore di uno screenshot di un terminale parzialmente visibile.

Dovresti usare NemoClaw nel 2026

NemoClaw è opinionato nei posti giusti. Assume che un agente sempre attivo dovrebbe iniziare dentro una gabbia, che le credenziali di inferenza dovrebbero restare sull’host, e che l’accesso di rete dovrebbe essere guadagnato piuttosto che assunto. Per questa classe di tooling, quella filosofia è ancora il default giusto.

È anche ancora alpha. Questo significa che spigoli ruvidi sono reali, il modello runtime richiede tempo da imparare, e il problema che si hit può genuinamente essere un problema di prodotto piuttosto che errore dell’operatore. Se si è onesti su quel vincolo, lo stack è usabile oggi per valutazione seria e workload interni controllati.

Il mio consiglio è semplice. Usare NemoClaw se si cura operations di agenti secure-by-default, si vuole una separazione più chiara tra assistente e livello di enforcement, e si è disposti a operare dentro un ciclo di vita deliberato. Se si vuole solo la demo più veloce possibile, ci sono giocattoli più semplici, ma se si vuole uno stack long-running più sicuro, NemoClaw è una delle opzioni più convincenti disponibili ora. Una volta stabili, il follow-on pratico è Pattern di setup produzione OpenClaw con plugin e skill, che mappia modelli operativi day-to-day. A quel stage, aggiungere monitoraggio formale con Osservabilità inferenza LLM usando Prometheus e Grafana così operations non dipendono solo dall’intuizione del terminale.