L'errore che quasi tutti commettono con la sicurezza degli AI coding agent

Immagina questa scena: hai passato settimane a rafforzare il tuo ambiente di sviluppo. Container con profili seccomp restrittivi, nessun traffico in uscita, filesystem in sola lettura, controlli a livello di processo ovunque. Il tuo AI coding agent è blindato più di un cluster Kubernetes in produzione.

Eppure, il tuo team di sicurezza continua a guardarti con aria preoccupata durante le sprint review.

Il problema? Hai risolto solo la metà del puzzle.

Due proprietà di sicurezza, una conversione che nessuno fa

Esiste una distinzione fondamentale che spesso si perde nelle discussioni tra team: host isolation e authority isolation sono proprietà di sicurezza completamente diverse.

L'host isolation riguarda il contenimento dell'esecuzione del codice. Pensa ai container, alle microVM, alla segmentazione di rete, alle restrizioni sul filesystem. La domanda che risolve è: "Se questo processo diventa malevolo, quanto può muoversi su questa macchina?"

L'authority isolation risponde a qualcosa di diverso: "Cosa può fare questo processo attraverso API legittime e piani di controllo fidati?"

Ed è qui che la cosa si fa interessante. Un agente AI non ha bisogno di evadere dal tuo container o compromettere il kernel per causare danni seri. Se possiede un token GitHub con accesso in scrittura, può fare merge su main. Se ha credenziali cloud, può creare infrastruttura o cancellare database di produzione. Se ha accesso alla tua email, può intercettare reset di password e spostarsi in decine di altri sistemi.

Nella pratica, gli incidenti più gravi che coinvolgono AI coding agent non assomiglieranno a compromissioni classiche dell'host. Sembreranno azioni perfettamente autorizzate, ma eseguite nel contesto sbagliato — o da un agente che non capisce le implicazioni complete di quello che sta facendo.

La superficie di credenziali che nessuno mappa

La maggior parte dei team ragiona sulle credenziali degli agenti AI come sulle variabili d'ambiente in un .env. Pensano: "Non abbiamo passato esplicitamente quelle credenziali, quindi l'agente non le ha."

Questa assunzione non considera la realtà dei workflow di sviluppo moderni. Gli IDE e gli ambienti di sviluppo di oggi arrivano pre-autenticati. I tuoi strumenti CLI sono già loggati. Le sessioni del browser sono attive. Le tue pipeline CI/CD hanno token nei secret del repository. I tuoi server MCP stanno facendo da proxy per funzionalità che forse non sai nemmeno di avere.

Quando dai a un AI coding agent accesso al tuo ambiente di sviluppo, gli stai spesso consegnando una costellazione di credenziali che farebbe invidia a un penetration tester.

Vediamo cosa conta davvero:

Token GitHub e permessi delle GitHub App

Lo scope è tutto. Un token con accesso repo:read è fondamentalmente diverso da uno con contents:write, pull_requests:write o permessi a livello di organizzazione. Il principio del minimo privilegio significa che i permessi degli agenti GitHub dovrebbero essere task-scoped e repo-bounded di default — niente token org-wide, niente accesso admin a meno che non sia strettamente necessario per attività amministrative specifiche.

Credenziali dei package registry

npm, PyPI, crates.io e registry simili sono piani di distribuzione. Un token di pubblicazione compromesso può spedire artifact malevoli a migliaia di consumatori a valle, anche se il tuo source control resta impeccabile. Questo è rischio supply chain che vive al di fuori del tuo normale perimetro di sicurezza.

Credenziali delle piattaforme cloud

AWS, GCP, Azure — chiavi di accesso, credenziali di service account, sessioni federate e managed identities si traducono tutte in autorità sull'infrastruttura quando sono raggiungibili dal runtime dell'agente. Il blast radius da una credenziale cloud compromessa può estendersi ben oltre la tua infrastruttura immediata.

Email e strumenti di comunicazione

L'email è meta-autorità. Con accesso alla inbox o capacità SMTP, un agente può intercettare link di reset password, impersonare membri del team nei workflow, e usare la comunicazione come punto di pivot verso altri sistemi. La fiducia che abbiamo costruito attorno all'email la rende particolarmente pericolosa nelle mani sbagliate.

Sessioni del browser e token OAuth

Le sessioni del browser attive spesso bypassano le richieste MFA fresche, consegnando stato già autenticato. Un agente con accesso al browser o token OAuth memorizzati ha effettivamente lo stesso accesso che hai tu dopo aver completato l'autenticazione a più fattori — nessuna verifica aggiuntiva richiesta.

Identità CI/CD

I token della tua continuous integration e deployment sono credenziali operative. Possono eseguire build, iniettare artifact, modificare release flow e fare deploy in produzione. Alcuni team trattano le credenziali CI come a basso rischio perché "fanno solo test", ma le pipeline moderne hanno spesso capacità molto più ampie.

Connessioni ai server MCP

I Model Context Protocol server sono diventati centrali nei workflow di sviluppo assistiti da AI, e la loro sicurezza è ora critica, non opzionale. Gli strumenti MCP possono amplificare l'autorità di un agente facendo da proxy verso sistemi che l'agente altrimenti non potrebbe raggiungere — spesso senza rivelare esplicitamente cosa sono quei sistemi o quali operazioni abilitano.

Chiavi API SaaS

Jira, Slack, Notion, Linear e decine di altri strumenti SaaS espongono tutti chiavi API che creano effetti collaterali a livello organizzativo quando compromesse. Manipolazione di ticket, abuso di notifiche, esposizione di dati e opportunità di social engineering sono tutte sul tavolo.

Il rischio reale non è teorico

I ricercatori di sicurezza hanno dimostrato questo gap concretamente. Ricerche sui path di privilege escalation hanno mostrato transizioni da accesso a basso privilegi a controllo a livello admin attraverso catene di credenziali — incluse vie che sfruttano connessioni a server MCP e punti di integrazione simili.

Dall'altra parte dello spettro, c'è un'osservazione altrettanto importante: i sistemi autonomi hanno sempre più bisogno di accesso diretto autenticato alla produzione per fornire valore reale. Blindare completamente un AI coding agent può renderlo inutile per le attività che devi realmente svolgere.

Questo crea una tensione architetturale genuina che non ha una soluzione pulita. Non puoi simultaneamente pretendere che un agente AI sia abbastanza utile da automatizzare workflow significativi, e allo stesso tempo impedirgli qualsiasi autorità ad agire su quei workflow.

Guida pratica per i team

Cosa significa questo nella pratica? Alcuni principi che vale la pena considerare:

Mappa la tua superficie di credenziali reale prima di distribuire agenti AI. Fai un audit delle credenziali. Quali sono tutti i sistemi che il tuo agente potrebbe teoricamente raggiungere attraverso il tuo ambiente di sviluppo? Questa è la tua superficie d'attacco reale.

Applica defense in depth all'accesso alle credenziali. Non fare affidamento su un singolo strato di protezione. Se un agente ha bisogno di accesso cloud, limitane lo scope. Se ha bisogno di accesso GitHub, usa token con permessi minimi. Se ha bisogno di integrarsi con server MCP, capisci quali capacità quei server fanno da proxy prima di connetterli.

Separa gli ambienti degli agenti dai contesti di produzione dove possibile. Le credenziali di sviluppo e staging non dovrebbero essere le stesse della produzione. Un agente che lavora in un contesto di sviluppo non dovrebbe avere alcun percorso verso i sistemi di produzione.

Tratta la sicurezza degli agenti AI come un processo continuo, non come una configurazione una tantum. Man mano che i tuoi workflow evolvono e nuovi strumenti vengono integrati, la tua superficie di credenziali cambia. Audit regolari sono importanti.

Sii esplicito su ciò che stai autorizzando. Quando connetti un nuovo server MCP o concedi un nuovo permesso a un agente AI, documenta il perché. Capisci quali capacità stai aggiungendo all'autorità dell'agente.

Il quadro più ampio

Il panorama degli AI coding agent sta evolvendo rapidamente, e le pratiche di sicurezza faticano a tenere il passo. Siamo diventati bravi a parlare di confini runtime e sandboxing — ma siamo ancora troppo casuali su cosa consegniamo a questi agenti accesso attraverso canali legittimi.

Il container hardening conta. La VM isolation conta. Ma nessuno dei due affronta il problema dell'autorità, ed è lì che vivono i rischi reali.

I team che navigeranno questo con successo saranno quelli che inizieranno a pensare alla sicurezza degli agenti AI in termini sia di dove questi agenti girano sia di cosa possono accedere attraverso i sistemi di cui ci fidiamo. Non è un "o uno o l'altro". È entrambi, insieme — e capire questa distinzione è il primo passo verso workflow di sviluppo assistiti da AI più sicuri.

Il sandbox è solo l'inizio della conversazione.