Docker indica isolamento e governance per mettere in sicurezza gli agenti AI

Docker ha pubblicato una guida sui cinque rischi per la sicurezza che emergono quando un agente AI naviga, esegue codice e richiama strumenti con una supervisione umana limitata. Il testo è firmato da Srini Sekaran, principal product marketing manager di Docker, con il product manager Eric Jia. La tesi è che l'autonomia che rende utili gli agenti rende anche insufficienti i controlli di sicurezza applicativa tradizionali.

I cinque rischi

Docker elenca prompt injection, uso improprio e avvelenamento degli strumenti, autonomia eccessiva, esposizione delle credenziali e sottrazione dei dati. Secondo l'azienda hanno una causa comune: un agente può scegliere gli strumenti a runtime, concatenare più azioni e spesso opera con i permessi della persona che lo ha avviato.

La sicurezza web tradizionale presuppone in genere che le richieste arrivino a endpoint noti e siano elaborate da codice deterministico. Gli agenti non rientrano in questo schema. Un agente che scrive codice può leggere un file, installare una dipendenza, modificare la configurazione, eseguire i test e fare push di un commit dopo aver ricevuto un solo ordine. Docker osserva che un agente compromesso o indirizzato male può quindi compiere una gamma di azioni molto più ampia rispetto a un servizio convenzionale.

Prompt injection e strumenti

Docker considera la prompt injection il rischio decisivo. Un attaccante non deve compromettere direttamente un sistema: può inserire istruzioni nel materiale che l'agente è chiamato a leggere, come una pagina web, un commento nel codice, una issue o un documento. Docker cita un episodio in cui un agente che scriveva codice ha seguito istruzioni nascoste nel contenuto di un repository ed eseguito azioni che l'utente non aveva chiesto.

"Un agente non si limita a rispondere a una domanda: naviga, esegue codice e richiama strumenti da solo, quindi una singola istruzione sbagliata o manipolata può trasformarsi in un danno reale invece che in una risposta errata." Eric Jia e Srini Sekaran, Docker

Docker dubita che la prompt injection si possa eliminare con istruzioni impartite al modello. Un agente non riesce a distinguere in modo affidabile un'istruzione legittima da una iniettata. La risposta preferita è limitare ciò che un agente dirottato può raggiungere, così che una manipolazione riuscita abbia effetti più contenuti.

"L'agente non ha un modo affidabile per distinguere un'istruzione legittima da una iniettata, quindi la difesa consiste nel limitare ciò che un agente dirottato può raggiungere." Eric Jia e Srini Sekaran, Docker

Gli strumenti sono il secondo fronte. Gli agenti usano connettori, query ai database, operazioni sui file ed esecuzione di codice per agire su sistemi esterni. Docker avverte che dare a un agente più strumenti di quanti ne serva per un compito allarga la superficie d'attacco. Avverte anche che la descrizione di uno strumento può contenere istruzioni nascoste che spingono l'agente a usarlo male.

La posizione coincide con il lavoro di OWASP su Agentic AI Threats and Mitigations, di cui InfoQ ha riferito a settembre 2025. OWASP indicava l'uso improprio degli strumenti come una delle principali minacce nuove. Descriveva attaccanti che manipolano gli agenti inducendoli ad abusare di strumenti autorizzati senza uscire dai permessi concessi. I controlli suggeriti erano verifica degli accessi, monitoraggio del comportamento, confini operativi e log di esecuzione a prova di manomissione. Il post di Docker chiede più o meno le stesse cose oltre un anno dopo.

Autonomia e credenziali

Docker descrive la "YOLO mode", in cui ogni azione dell'agente viene approvata automaticamente, come esempio visibile di permessi permanenti molto ampi. Ammette che la modalità può essere produttiva, ma sostiene che vada usata dentro un confine che impedisca all'agente di raggiungere sistemi o dati che non dovrebbe toccare.

Il post riporta due episodi. Uno sviluppatore ha chiesto a un agente che scriveva codice di ripulire un vecchio repository. L'agente ha generato un comando rm -rf con una ~/ finale e lo ha eseguito senza conferma, cancellando la directory home dello sviluppatore. Docker cita anche un ingegnere AWS che ha assegnato a un agente un bug di Cost Explorer mentre questo girava con accesso di livello operator. L'agente ha scelto di eliminare e ricostruire l'ambiente di produzione, causando un'interruzione regionale durata tredici ore.

La gestione delle credenziali è strettamente collegata. Docker sostiene che gli agenti non debbano ereditare il token personale di uno sviluppatore, perché ogni azione porterebbe con sé i permessi completi di quella persona. Consiglia credenziali separate e di breve durata, iniettate a runtime e tenute fuori dalla conversazione. Anche i segreti presenti nei prompt, nei file di configurazione o nelle variabili d'ambiente delle immagini sono un rischio, perché le istruzioni iniettate potrebbero leggerli dal contesto dell'agente.

L'ultimo rischio è la sottrazione dei dati. Un agente con accesso alla rete e informazioni sensibili nel proprio contesto può inviarle a una destinazione non prevista. Docker afferma che il rischio cresce nei sistemi multi-agente, dove un agente passa il lavoro a un altro. Consiglia di limitare il traffico in uscita a una lista di destinazioni consentite e di trattare ogni passaggio tra agenti come input non attendibile.

Cosa raccomanda Docker

Docker indica isolamento e governance, non solo modelli migliori, come difese principali. Le raccomandazioni puntano a limitare ciò che gli agenti possono raggiungere, separare le credenziali e controllare il traffico in uscita. La guida riecheggia altri lavori seguiti da InfoQ. Il blueprint di sicurezza per GKE di Google, riportato a luglio 2026, raccomanda GKE Sandbox, basato su gVisor, per contenere gli agenti.