Sicurezza · strumenti

Checklist di sicurezza degli agenti

Completa questi controlli prima che un agente acceda a dati reali o credenziali. Ogni controllo rimanda alla misura di protezione corrispondente; puoi esportare i progressi in un file Markdown da usare per una revisione o una pull request.

0 di 22 completati

Le spunte vengono salvate solo in questo browser.

Input non attendibili

Contrassegna i contenuti non attendibili in ogni punto di ingresso nell'agentContrassegna le pagine web, le email, i issue, i ticket e i risultati degli strumenti che possono essere scritti da persone esterne. Tutti questi contenuti possono contenere istruzioni.Interrompi la trifecta letale →Separa gli agent in modo che nessuno disponga di tutti e tre gli elementi della trifectaSe un agent legge contenuti non attendibili, privarlo dei dati riservati oppure del canale in uscita. Se un agent deve disporre di tutti e tre gli elementi, usa un approccio plan-then-execute o un'architettura dual-LLM.Limita l'agente dopo input non attendibili →Esamina e fissa le descrizioni di ogni strumento connessoLe descrizioni degli strumenti entrano direttamente nel contesto del modello. Leggile prima di connettere un server e calcolane l'hash per rilevare eventuali modifiche successive.Verifica skill, plugin e server MCP →Esegui l'escape dell'output del modello prima di visualizzarlo o eseguirloImpedisci il caricamento automatico di immagini e link esterni nell'output visualizzato e imposta una CSP rigorosa. Non passare mai l'output grezzo a una shell, una query SQL o eval.Considera non attendibili gli output del modello →

Strumenti e credenziali

Imposta ogni connessione agli strumenti in sola letturaConcedi i permessi di scrittura, eliminazione o invio solo agli strumenti che ne hanno bisogno e solo per l'attività in corso.Usa credenziali con privilegi minimi →Limita ogni token a un singolo progetto e ai permessi minimiNon usare chiavi admin o service_role per gli agent. I token con durata breve e limitati al progetto riducono al minimo l'impatto di una fuga di dati.Usa credenziali con privilegi minimi →Richiedi l'approvazione umana per scritture, eliminazioni e inviiMostra tutti gli argomenti dello strumento nella richiesta di approvazione e, se nessuno risponde, nega l'operazione. In OpenClaw, imposta tools.exec.ask su always.Richiedi l'approvazione per le azioni rilevanti →Fissa le versioni esatte di skill, plugin e server MCPEsamina le differenze prima di ogni aggiornamento e controlla i verdetti degli scanner di VirusTotal o degli audit di ClawHub. In OpenClaw, imposta security.installPolicy.Verifica skill, plugin e server MCP →Consenti il traffico in uscita solo verso gli host necessari a ciascuno strumentoNega per impostazione predefinita il traffico in uscita degli agent e dei server MCP. Escludi da ogni allowlist con approvazione automatica gli host multi-tenant, dove chiunque può pubblicare contenuti.Limita l'accesso alla rete in uscita →

Runtime e rete

Esegui il codice e gli strumenti shell in una sandboxUsa un container o una VM senza credenziali e monta solo l’area di lavoro. In OpenClaw, attiva il sandboxing, imposta tools.exec.security su deny o allowlist e lascia disattivata la modalità elevata.Esegui codice e tool in una sandbox →Limita gateway e dashboard all’interfaccia loopbackAccedi da remoto tramite un tunnel SSH o Tailscale Serve e usa un token di almeno 24 caratteri. Esegui openclaw security audit --deep per verificare la configurazione.Tieni i control plane fuori da Internet →Limita chi può inviare messaggi all’agenteUsa l’associazione per i messaggi diretti o una allowlist e richiedi una menzione nelle chat di gruppo. Chiunque possa inviare messaggi all’agente può provare a dargli istruzioni.Controlla chi può scrivere all'agente →Assegna una sessione separata a ogni utente o mittentePersone diverse non devono mai condividere lo stesso contesto di conversazione. In OpenClaw, imposta session.dmScope su per-channel-peer.Isola le sessioni e i tenant MCP →

Server e client MCP

Rifiuta i token MCP non emessi per il tuo serverVerifica l’audience di ogni access token e chiedi ai client di inviare resource indicator RFC 8707, così ogni token è associato a un solo server.Verifica l'audience dei token MCP →Non inoltrare mai i token dei client alle API upstreamOttieni token separati per le chiamate upstream. Se il tuo server fa da proxy per servizi di terze parti, raccogli il consenso di ogni client per evitare il problema del confused deputy.Verifica l'audience dei token MCP →Mantieni aggiornati MCP SDK e strumentiCome minimo: TypeScript SDK 1.26.0, Python SDK 1.27.2, mcp-remote 0.1.16 e MCP Inspector 0.14.1. Crea un server e un transport per ogni sessione.Isola le sessioni e i tenant MCP →

CI e code review

Non fornire segreti agli agenti CI attivabili da utenti esterniI job degli agenti avviati da pull request, issue o commenti di utenti esterni devono usare un token di sola lettura e non avere accesso ai segreti del repository.Tieni i segreti fuori dalle esecuzioni CI non attendibili →Considera ostili i testi di pull request e issueTitoli, descrizioni, commenti e diff di utenti esterni possono contenere istruzioni. Richiedi l’approvazione di un maintainer prima di eseguire su questi contenuti qualsiasi job che usi segreti.Tieni i segreti fuori dalle esecuzioni CI non attendibili →

Operatività

Registra ogni chiamata agli strumenti, con argomenti e risultatoConserva i log in un luogo che l’agente non possa modificare. Servono per ricostruire gli incidenti e individuare chiamate insolite.Tieni a portata di mano un modo rapido per fermare gli agenti e revocarne i tokenAssicurati di sapere come arrestare ogni agente in esecuzione e revocarne le credenziali in pochi minuti. Prova la procedura prima che serva.Prima del rilascio, verifica la resistenza degli agenti alla prompt injectionInserisci istruzioni nei contenuti letti dall’agente, ad esempio issue, email e pagine web, e verifica che non ne seguano azioni rilevanti. Ripeti i test dopo ogni modifica agli strumenti o ai prompt.Verifica le firme degli agenti prima di considerare attendibile il loro trafficoVerifica le firme Web Bot Auth rispetto alla directory delle chiavi dell’operatore per identificare un agente. Autorizza separatamente le sue azioni: la firma identifica l’operatore, non l’utente.Verifica le firme dell'agente, poi autorizzalo →

Esporta come Markdown

SECURITY-CHECKLIST.md

## Input non attendibili
- [ ] Contrassegna i contenuti non attendibili in ogni punto di ingresso nell'agent
- [ ] Separa gli agent in modo che nessuno disponga di tutti e tre gli elementi della trifecta
- [ ] Esamina e fissa le descrizioni di ogni strumento connesso
- [ ] Esegui l'escape dell'output del modello prima di visualizzarlo o eseguirlo

## Strumenti e credenziali
- [ ] Imposta ogni connessione agli strumenti in sola lettura
- [ ] Limita ogni token a un singolo progetto e ai permessi minimi
- [ ] Richiedi l'approvazione umana per scritture, eliminazioni e invii
- [ ] Fissa le versioni esatte di skill, plugin e server MCP
- [ ] Consenti il traffico in uscita solo verso gli host necessari a ciascuno strumento

## Runtime e rete
- [ ] Esegui il codice e gli strumenti shell in una sandbox
- [ ] Limita gateway e dashboard all’interfaccia loopback
- [ ] Limita chi può inviare messaggi all’agente
- [ ] Assegna una sessione separata a ogni utente o mittente

## Server e client MCP
- [ ] Rifiuta i token MCP non emessi per il tuo server
- [ ] Non inoltrare mai i token dei client alle API upstream
- [ ] Mantieni aggiornati MCP SDK e strumenti

## CI e code review
- [ ] Non fornire segreti agli agenti CI attivabili da utenti esterni
- [ ] Considera ostili i testi di pull request e issue

## Operatività
- [ ] Registra ogni chiamata agli strumenti, con argomenti e risultato
- [ ] Tieni a portata di mano un modo rapido per fermare gli agenti e revocarne i token
- [ ] Prima del rilascio, verifica la resistenza degli agenti alla prompt injection
- [ ] Verifica le firme degli agenti prima di considerare attendibile il loro traffico