Managed AgentsSandbox self-hosted

Modello di sicurezza

Copy page



Modello di responsabilità condivisa per ambienti sandbox self-hosted.

Anthropic protegge il "control plane" (piano di controllo) in tutti gli ambienti: integrità delle sessioni e delle code di lavoro, isolamento multitenant e minimizzazione del contesto dell'agente. Quando esegui il self-hosting, le seguenti responsabilità ricadono su di te.

Cosa è di tua competenza

• Qualità dell'immagine sandbox e hardening del runtime. Anthropic non ispeziona né verifica la tua immagine sandbox. Segui le best practice come rimuovere le capability Linux non necessarie, eseguire come utente non root e usare un filesystem root in sola lettura.
• Controlli sul traffico di rete in uscita (egress). L'accesso alla rete della tua sandbox è determinato dalle regole della tua VPC e del tuo firewall. Senza restrizioni sull'egress, un'esecuzione di strumento compromessa può raggiungere host esterni arbitrari. Limita il traffico in uscita ai soli endpoint richiesti dai tuoi strumenti.
• Archiviazione e rotazione della chiave di servizio. La chiave di servizio dell'ambiente (ANTHROPIC_ENVIRONMENT_KEY) autorizza il polling della coda di lavoro del tuo ambiente e l'invio dei risultati alle sessioni. Conservala in un secrets manager, non in file di ambiente o immagini sandbox. Ruotala immediatamente se sospetti un'esposizione.
• Isolamento dei carichi di lavoro non attendibili. La chiave di servizio dell'ambiente ha un ambito limitato alla coda di lavoro di un singolo ambiente. Se esegui codice non attendibile all'interno della tua sandbox, valuta di predisporre un workspace e un ambiente separati per ciascun confine di fiducia. Questo limita ogni chiave alle sessioni di un singolo utente anziché a un pool condiviso.
• Credenziali per sessione. Ogni elemento di lavoro che il tuo worker acquisisce può contenere un secret per sessione, che il worker dell'SDK usa al posto della chiave di servizio dell'ambiente. L'accesso ai memory store richiede il secret: gli endpoint dei memory store rifiutano la chiave dell'ambiente (vedi Usare i memory store). Passa il secret solo alla sandbox che serve quella sessione, tienilo fuori da immagini e volumi condivisi e non registrarlo mai nei log.
• Raggio d'impatto dell'esecuzione degli strumenti. Gli strumenti vengono eseguiti all'interno della tua sandbox con qualsiasi permesso abbia il tuo processo. Applica il principio del privilegio minimo all'utente del processo e monta solo le directory richieste dai tuoi strumenti.
• Conservazione dei log e contenuto delle sessioni. Il contenuto delle conversazioni e gli output degli strumenti passano attraverso il tuo worker e rimangono nel tuo ambiente. Sei responsabile della conservazione, dell'oscuramento o dell'eliminazione di tali dati in conformità con le tue policy. Anthropic non ha visibilità su ciò che il tuo worker fa con il contenuto delle sessioni una volta consegnato.
• Contenuto dei memory store. I memory store rimangono ospitati da Anthropic, inclusa la loro cronologia delle versioni. Quando una sessione ne collega uno, il worker mantiene una copia di lavoro sotto /mnt/memory/ nella tua sandbox per la durata della sessione e sincronizza le modifiche. Il worker elimina quella copia al termine della sessione, ma un worker che termina senza eseguire il proprio teardown la lascia in sospeso. La pulizia delle copie residue, i permessi su quel percorso e l'isolamento tra sessioni che condividono un filesystem sono di tua responsabilità.
• Memory store in sola lettura. Uno store collegato con accesso read_only è protetto dal caricamento, non dalla modifica locale. Gli strumenti write ed edit del worker si rifiutano di scrivere nella sua directory, nulla di ciò che si trova lì viene sincronizzato e gli endpoint dei memory store rifiutano le scritture effettuate con il secret della sessione. Altri processi nella sandbox possono comunque modificare la copia locale: i comandi che l'agente esegue tramite lo strumento bash, e gli strumenti personalizzati o i server MCP che servi dalla sandbox, che vengono eseguiti con i permessi del worker. Le chiamate di strumenti successive in quella sessione leggono la copia modificata finché quella memoria non cambia nuovamente nello store. Se l'agente non deve poter alterare nemmeno la propria vista locale di tale store, disabilita lo strumento bash per quell'agente e non fornirgli alcuno strumento personalizzato che scriva sul filesystem della sandbox.

Cosa Anthropic non può fare per te

• Sapere che la tua chiave è trapelata. Anthropic può rilevare pattern di utilizzo anomali, ma non può sapere che la tua chiave è stata compromessa. Se sospetti che ANTHROPIC_ENVIRONMENT_KEY sia trapelata, revocala e genera immediatamente una sostituta. La revoca viene validata a ogni richiesta, quindi ha effetto alla successiva chiamata del worker.
• Verificare la build del tuo worker. Anthropic non ispeziona la tua immagine sandbox né il runtime. Una compromissione della supply chain nella tua immagine non è rilevabile dal control plane.
• Isolare gli strumenti all'interno della tua sandbox. Il confine di sicurezza di Anthropic si ferma alla sandbox. Il modo in cui isoli le singole esecuzioni degli strumenti l'una dall'altra all'interno di quel confine è interamente di tua responsabilità.
• Imporre la conservazione dei dati nel tuo ambiente. Una volta che il contenuto della sessione raggiunge il tuo worker, è al di fuori dei controlli del ciclo di vita dei dati di Anthropic.