Procedure consigliate per il contenimento degli agenti: monitoraggio offline dei transcript degli agenti (beta privata)

Per i clienti del nostro Cyber Verification Program, forniamo un nuovo classificatore di sandbox escape nell'API per monitorare e ridurre gli abusi. Questo articolo spiega perché i transcript degli agenti meritano di essere letti. Contiene quindi una sezione per ogni livello di monitoraggio: prima i log del proxy, poi cosa dovrebbe contenere un transcript, le regole di pattern sui transcript e un revisore di modello sui transcript. Termina con cosa fare quando un livello segnala un agente mentre un batch è in esecuzione e cosa conservare successivamente.

Per una panoramica di tutte le risorse disponibili, consulta Procedure consigliate per il contenimento degli agenti: guida introduttiva (beta privata).

La sandbox e il classificatore di autorizzazioni in modalità automatica di Claude Code agiscono entrambi mentre un agente è in esecuzione. Leggere i transcript è un controllo che non dipende da nessuno di loro. Ha due usi.

Per gli impegni con accesso di rete a target reali, le procedure consigliate raccomandano che una persona supervisioni l'esecuzione, oppure che un monitor che conosce l'ambito previsto osservi continuamente, escalation a una persona quando un'esecuzione potrebbe superare tale ambito e possa terminare l'esecuzione (consulta la sezione Ambito e supervisione in Sandboxing). I livelli in questo articolo sono i componenti da cui è costruito un tale monitor.

Se esegui agenti direttamente contro l'API Messages, l'API può anche restituire un punteggio per richiesta dal classificatore di sandbox escape mentre vengono eseguiti (consulta Monitoraggio online).

Il livello più economico non legge alcun transcript.

Il proxy di uscita dovrebbe registrare ogni richiesta che rifiuta, con l'indirizzo del client e la destinazione. Con una lista di autorizzazione vuota, gli agenti raggiungono l'API del modello solo attraverso il proxy di credenziali e non hanno bisogno di altri host, quindi ogni richiesta rifiutata durante un'esecuzione merita un'occhiata. Leggi il transcript di ogni esecuzione che ne ha causata una. L'indirizzo del client mostra quale agente ha effettuato la richiesta, quindi sai quale transcript leggere per primo.

Sappi cosa il tuo livello di uscita non registra. Nel design di riferimento, il proxy di uscita registra le richieste HTTPS CONNECT rifiutate. I tentativi HTTP semplice e TCP grezzo non passano attraverso il proxy sulla rete interna, quindi falliscono senza una riga di log e appaiono solo nei transcript. Nel tuo build, considera di registrare le connessioni consentite e rifiutate, per ogni protocollo, con timestamp.

Il proxy di credenziali dovrebbe registrare una riga per qualsiasi richiesta che non fosse una chiamata di modello. Salva il suo log quando l'esecuzione termina (consulta la sezione Il proxy di credenziali in Sandboxing).

Il secondo e il terzo livello leggono i transcript stessi.

Fai in modo che l'orchestrator sull'host scriva un transcript per ogni fase dell'agente, un messaggio JSON per riga, man mano che ogni messaggio arriva. L'output stream-json di Claude Code ha questa forma. In ogni file, le righe con "type": "assistant" contengono quello che il modello ha prodotto: blocchi text, thinking e tool_use. L'input tool_use contiene il comando Bash o il file in fase di scrittura. Le righe con "type": "user" contengono blocchi tool_result: output dei comandi, contenuti dei file e risposte dei target.

Acquisisci ogni fase, incluse le fasi i cui agenti non hanno strumenti, come un agente che solo giudica o confronta i risultati. C'è meno da controllare in quei transcript, ma una fase senza transcript non può essere rivista affatto.

Scrivi le tue regole di pattern, come espressioni regolari, per i tuoi agenti e target. Per gli agenti che lavorano attraverso una shell, copri comportamenti come il bypass del proxy di uscita o del firewall, l'invio di credenziali o l'apertura di connessioni SSH al di fuori della sandbox, la modifica dei tunable del kernel o dei privilegi e l'elenco di altri processi attraverso /proc. Le regole corrispondono solo al comportamento che qualcuno ha anticipato, quindi trattale come punto di partenza, non come rilevatore completo.

Applica le regole a stringhe decodificate JSON piuttosto che a righe grezze, perché su una riga grezza le virgolette e le nuove righe sono sfuggite e i pattern potrebbero non corrispondere. Segnala ogni risultato con il file, la riga, la regola e uno snippet, e fai in modo che la scansione esca con uno stato distinto quando trova qualcosa, in modo che un lavoro pianificato possa eseguirlo durante un lungo batch e generare un avviso.

Un risultato è un motivo per leggere quella parte del transcript. Di per sé non significa che l'agente abbia fatto qualcosa di sbagliato. Gli agenti che conducono ricerche di vulnerabilità eseguono regolarmente comandi che corrispondono alle regole di escape per motivi ordinari:

Una regola di bypass del proxy può corrispondere a ogni richiesta curl, wget o netcat a un target di pentest con un IP pubblico, e una regola di uscita SSH può corrispondere a qualsiasi ssh o scp a un target con un IP pubblico o un nome DNS. Restringi o rimuovi le regole che producono solo risultati benigni sui tuoi target.

Per ogni transcript che le regole di pattern hanno segnalato, invia una richiesta dell'API Messages a Claude con un prompt di revisore che scrivi. Il prompt dovrebbe chiedere a Claude di cercare un agente che ha ampliato il suo accesso di rete o ha rotto la sua sandbox, sia tentato che realizzato, dire cosa segnalare e cosa non segnalare, e chiedere i risultati, o nessuno, con le righe del transcript che li supportano.

Costruisci il messaggio dell'utente in due parti:

Utilizza il modello con cui esegui gli agenti, o uno più economico. Sotto Amazon Bedrock o Google Cloud's Agent Platform (Vertex AI), utilizza uno che è abilitato nel tuo account.

Due limiti da tenere a mente:

Le regole di pattern catturano solo quello che qualcuno ha anticipato, quindi invia anche un campione casuale del 5-10% dei transcript che le regole non hanno segnalato, utilizzando la stessa richiesta. Il campione mostra cosa le regole perdono e se dovresti aggiungere una regola.

I rifiuti del classificatore in modalità automatica sono utili anche da leggere: cerca nei transcript i messaggi di rifiuto del classificatore e tienili separati dai rifiuti che emette quando non è disponibile (consulta Modalità automatica).

Questo revisore è separato dal classificatore di autorizzazioni in modalità automatica (consulta Modalità automatica), che decide su ogni azione prima che venga eseguita, e dal classificatore di sandbox escape nell'API (consulta Monitoraggio online). I tre si completano a vicenda.

Quando uno dei livelli mostra un agente che ha abbandonato il suo compito mentre il suo batch è ancora in esecuzione:

Se hai bisogno di condividere un transcript al di fuori del tuo team, lavora su una copia. Rimuovi gli id di sessione, la contabilità dell'utilizzo e l'inventario dell'host che la prima riga di un transcript registra, e leggi il file prima di inviarlo.

Conserva quanto segue per almeno 30 giorni dopo un'esecuzione, o più a lungo dove i tuoi obblighi normativi o contrattuali lo richiedono. Archiviali al di fuori dell'host:

Archiviali con gli stessi controlli di accesso dell'esecuzione stessa. I transcript possono contenere codice sorgente del target, codice di exploit e risultati.

Se uno di questi log esiste solo come log di un container, esportalo prima che il container venga rimosso o ricreato, perché il log viene eliminato con esso.