Sicurezza degli agenti di codice AI: il modello agent-time

Cos'è la sicurezza degli agenti di codice AI?

La sicurezza degli agenti di codice AI è la disciplina che vincola ciò che un agente di codice autonomo produce ed esegue, attraverso la generazione, l'esecuzione di comandi e le chiamate agli strumenti, anziché proteggere solo la scatola in cui gira. Copre il codice che l'agente scrive, le dipendenze che tira dentro, i segreti che può leggere e le azioni che può compiere per tuo conto.

L'espressione viene spesso letta in modo troppo ristretto. Gran parte delle indicazioni pubblicate la tratta come un problema infrastrutturale: metti l'agente in una sandbox, limita il suo ruolo IAM, restringi il suo egress di rete, vincola i suoi permessi. Quei controlli sono necessari e non ci stiamo opponendo. Ma rispondono a una domanda diversa. La sandbox decide cosa l'agente può toccare. Non dice nulla sul fatto che l'SQL che l'agente ha appena scritto concateni l'input dell'utente in una query string, o che il controllo di autorizzazione che ha saltato finirà per esporre i dati di un altro tenant. Il runtime è contenuto; l'artefatto no. Proteggere un agente di codice AI deve includere la protezione di ciò che scrive, nel momento in cui lo scrive.

Perché un agente di codice AI è una nuova superficie di attacco?

Un agente di codice AI è una nuova superficie di attacco perché compie azioni anziché suggerirle. Un assistente IDE tradizionale propone un completamento che un essere umano sceglie di incollare. Un agente legge file che non hai nominato, esegue comandi che non hai digitato, modifica codice in tutto l'albero e richiama strumenti che hai collegato settimane fa. Il raggio d'azione non è più un singolo blocco di codice.

Due cambiamenti aggravano la cosa. Il primo è l'autonomia: l'agente può essere guidato. Poiché un modello linguistico non può distinguere in modo affidabile un'istruzione attendibile da una ostile sepolta nei dati, un attaccante può nascondere istruzioni in un file, una pagina web, una issue o la risposta di uno strumento, e l'agente le segue. Questa è la prompt injection indiretta, ed è il rischio numero uno di OWASP per le applicazioni LLM da tre anni consecutivi. Un assistente guidato risponde male; un agente guidato agisce.

Il secondo cambiamento è la velocità, ed è quello che la maggior parte dei team sottovaluta. La pull request funzionava come gate di sicurezza perché si collocava al ritmo umano. L'agente non gira al ritmo umano. Quando una singola sessione spedisce più codice in un pomeriggio di quanto un revisore ne legga in una settimana, ogni controllo che vive solo alla PR sta ora rivedendo la storia anziché prevenirla.

Perché la scansione post-PR fallisce per gli agenti AI?

La scansione post-PR fallisce per gli agenti AI perché era progettata per il ritmo umano e l'agente ha rotto quel ritmo. SAST, SCA e il revisore umano agiscono tutti sullo stesso artefatto, il diff, e tutti presumono che una persona rallenti per leggerlo prima del merge. Quando l'agente supera il revisore, quel presupposto non regge più.

Il fallimento non è che gli scanner smettano di trovare bug. Li trovano ancora. Il fallimento è nei tempi e nel volume. Quando uno scanner segnala un'injection nel diff sottoposto a merge, l'agente ha già scritto la riga, è andato oltre, ha costruito tre funzionalità sopra di essa, e uno sviluppatore ha una coda di risultati da smistare che cresce più in fretta di quanto chiunque riesca a svuotarla. I team rispondono in due modi prevedibili, entrambi sbagliati: alcuni fanno il merge dell'output dell'agente con un'occhiata, altri lo accorpano in un'unica enorme PR che nessuno legge dall'inizio alla fine. In ogni caso il diff ha smesso di essere un gate. È un registro di ciò che è già accaduto.

C'è anche un disallineamento più profondo. Le cose più dannose che un agente AI sbaglia non sono gli schemi in cui gli scanner sono bravi. Sono le falle di logica di business: un controllo di proprietà mancante, uno sconto che si cumula quando non dovrebbe, una transizione di stato che non sarebbe mai dovuta essere raggiungibile. Uno scanner che non conosce il tuo dominio non può vederle, e un revisore che annega nell'output dell'agente non le coglierà nemmeno. Il controllo deve conoscere le tue regole e deve agire prima che la riga venga scritta.

Cos'è la sicurezza agent-time?

La sicurezza agent-time è la pratica di imporre i tuoi controlli dentro il loop dell'agente di codice AI, prima che la riga incriminata venga scritta, anziché dopo che il codice arriva in una pull request. Il punto di controllo si sposta dal diff al prompt. L'agente legge le regole pertinenti come parte della scrittura del codice, così il requisito diventa parte dell'output anziché una casella da spuntare al momento dell'audit.

È la risposta naturale al problema del ritmo. Se l'agente spedisce più in fretta di quanto tu riesca a rivedere, non vinci rivedendo più duramente. Vinci mettendo la regola nelle mani dell'agente prima che agisca. In concreto, la sicurezza agent-time si aggancia alla sessione e alle chiamate di strumenti dell'agente: prima di una modifica, inietta le convenzioni e i requisiti di sicurezza che si applicano ai file toccati; prima che parta un comando distruttivo, intercetta. Nulla aspetta il merge.

“

La pull request era un punto di controllo perché un essere umano la leggeva. Il prompt è il punto di controllo ora perché l'agente lo ascolta. La sicurezza agent-time è il livello che mette l'ascoltatore dell'agente dalla tua parte.

Questo non sostituisce i tuoi scanner. SAST e SCA appartengono ancora alla CI come rete di sicurezza per tutto ciò che sfugge, e per il codice che gli esseri umani scrivono ancora a mano. La sicurezza agent-time è il livello davanti a loro, quello che corrisponde alla velocità della cosa che genera davvero il codice.

Quali sono i rischi principali tra gli agenti di codice AI?

I rischi principali sono coerenti tra Claude Code, Cursor, GitHub Copilot, OpenAI Codex e Windsurf, perché condividono la stessa forma agentica. Le guide per singolo agente coprono nel dettaglio i controlli nativi di ciascuno strumento; le classi di rischio in sé fanno rima. L'ultimo arrivato, Google Antigravity, segue lo stesso schema.

• Codice generato insicuro. L'agente scrive query iniettabili, crittografia debole, autorizzazioni mancanti e deserializzazione non sicura, perché quegli schemi sono abbondanti nei suoi dati di addestramento. Questo è il rischio che l'inquadramento infrastrutturale ignora del tutto.
• Falle di logica di business. Controlli di proprietà mancanti, controllo degli accessi compromesso tra tenant, macchine a stati che permettono transizioni illegali. Invisibili agli scanner generici, comuni nell'output dell'agente.
• Prompt injection, diretta e indiretta. Istruzioni ostili nascoste in un repo, una pagina web, una issue o una risposta di uno strumento MCP che l'agente tratta come un comando. OWASP LLM01. I file di regole del repository portano lo stesso attacco: vedi l'iniezione tramite file di istruzioni.
• Strumenti e server MCP con permessi eccessivi. Uno strumento di database con accesso in lettura a tutto, un server di filesystem puntato sulla home directory, uno strumento di deploy con credenziali di produzione. Il tool poisoning nasconde istruzioni nelle descrizioni degli strumenti, quindi il solo fatto di connettere un server può guidare l'agente.
• Supply chain e rischio delle dipendenze. L'agente installa pacchetti ed esegue script di setup come parte del normale lavoro. Il typosquatting e l'allucinazione dei pacchetti trasformano un banale "configura questo repo" in furto di credenziali. La variante del pacchetto allucinato ha un nome: slopsquatting.
• Esposizione di segreti e contesto. Un contesto locale ampio (file .env, credenziali, endpoint interni) viene fatto emergere nei log, nel codice generato o in una PR che sopravvive alla sessione.
• Azioni distruttive. Un agente manipolato esegue sudo rm -rf, riscrive una configurazione CI o altera l'infrastruttura, con qualsiasi accesso l'ambiente gli abbia concesso. I flag che tolgono l'ultimo punto di controllo sono spiegati per Codex, e una sandbox non risolve tutto, come mostrano le evasioni dalla sandbox degli agenti.

Come si protegge un agente di codice AI in pratica?

Proteggi un agente di codice AI combinando il contenimento del runtime con la governance agent-time, mantenendo poi la CI come rete di sicurezza. Privilegio minimo, sandbox, gestione dei segreti e revisione umana sono il minimo indispensabile. Il pezzo che manca alla maggior parte degli stack è un controllo che viva al prompt e governi ciò che l'agente scrive prima che lo scriva. Un file di regole non fa questo lavoro: nello studio controllato di CybeDefend, un CLAUDE.md realistico ha ottenuto lo stesso punteggio dell'assenza di file (Claude Code rispetta il CLAUDE.md?).

In pratica significa una postura di difesa in profondità con il punto di controllo portato in avanti. Limita i permessi dell'agente e isola il suo runtime così che un agente guidato abbia un raggio d'azione ristretto. Gestisci i segreti così che il contesto dell'agente non sia più ampio di quanto il compito necessiti. Mantieni SAST e la scansione delle dipendenze nella CI per tutto ciò che sfugge e per il codice scritto dagli esseri umani. Poi aggiungi il livello che corrisponde davvero alla velocità dell'agente: la governance dentro il loop, dove l'agente legge le tue regole di business e i tuoi requisiti di sicurezza mentre programma, e un guard intercetta le chiamate distruttive prima che partano. I quattro livelli agent-time qui sotto sono l'aspetto di quel controllo.

Quali controlli appartengono all'agent-time e quali alla CI?

I controlli appartengono all'agent-time quando governano un'azione che l'agente sta per compiere, e alla CI quando sono una rete di sicurezza sull'artefatto finito. La regola pratica: se un essere umano che rivede il diff arriverebbe troppo tardi, il controllo deve girare dentro il loop. Se è un gate finale prima del merge o del deploy, resta nella CI.

Leggi le due colonne come partner, non come rivali. La scansione in CI è ancora il posto giusto per un controllo finale a livello di artefatto, e dovresti mantenerla. L'agent-time è dove sposti i controlli che perdono tutto il loro valore nel momento in cui l'agente ha finito ed è andato oltre. L'errore che fa la SERP è finanziare solo il cugino infrastrutturale della colonna di destra (sandbox, IAM) lasciando il codice vero e proprio non governato fino al merge.

VibeDefend è il livello agent-time, confezionato come una CLI npm gratuita che si installa in circa cinque secondi. Un solo comando rileva automaticamente Claude Code, Cursor, OpenAI Codex, Windsurf e VS Code Copilot sulla tua macchina e collega ciascuno a quattro livelli di governance che girano dentro il loop dell'agente. Niente YAML, niente deploy, nessun container da costruire.

I quattro livelli corrispondono esattamente al modello descritto sopra. Le regole di business vengono estratte dal modo in cui il tuo team già scrive codice e proposte come regole esplicite di una riga. Le regole di sicurezza caricano i framework che i tuoi auditor si aspettano e li abbinano a ogni modifica. L'Action Guard intercetta le chiamate distruttive prima che partano. Live Findings collega l'agente alla piattaforma di sicurezza del codice di CybeDefend, i suoi scanner (SAST con reachability, SCA, segreti, IaC e CI/CD) in esecuzione continua, così l'agente non si limita a scrivere codice sicuro, smista e corregge le vulnerabilità che hai già. Il modello di privacy è la parte a cui i team di sicurezza tengono di più: nulla del tuo codice attraversa la rete. Le decisioni avvengono localmente, accanto all'agente, e solo metadati di governance strutturati raggiungono il backend, la regola che è scattata, il percorso del file su cui puntava, la severità, un timestamp. Nessun codice sorgente, nessun contenuto del prompt. Le regioni EU e US sono fisicamente separate e scelte al momento dell'installazione, senza alcun percorso cross-region.

Domande frequenti

Cos'è la sicurezza agent-time?

La sicurezza agent-time consiste nell'imporre i tuoi controlli dentro il loop dell'agente di codice AI, prima che la riga incriminata venga scritta, anziché dopo che il codice raggiunge una pull request. Il punto di controllo si sposta dal diff al prompt: l'agente legge le regole che si applicano mentre scrive, così il requisito diventa parte dell'output. È la risposta agli agenti che spediscono codice più in fretta di quanto qualsiasi essere umano riesca a rivedere.

In cosa la sicurezza degli agenti di codice AI è diversa dalla sandbox?

La sandbox protegge dove gira l'agente; la sicurezza degli agenti di codice AI deve proteggere anche ciò che l'agente scrive. Una sandbox può contenere perfettamente il runtime e lasciare comunque che l'agente scriva una query iniettabile o salti un controllo di autorizzazione, perché l'artefatto non sicuro non è una questione di runtime. Servono entrambi: il contenimento per il raggio d'azione, e la governance agent-time per il codice in sé.

Perché la scansione post-PR fallisce per gli agenti AI?

Perché presume che un essere umano rallenti per leggere il diff prima del merge, e l'agente ha rotto quel ritmo. Gli scanner trovano ancora bug, ma i risultati si accodano più in fretta di quanto i team riescano a smistarli, quindi le persone fanno il merge con un'occhiata oppure accorpano tutto in un'unica PR illeggibile. Il diff smette di essere un gate. Il controllo deve spostarsi dentro il loop, prima del merge.

La sicurezza agent-time sostituisce SAST e la scansione in CI?

No. SAST e la scansione delle dipendenze restano nella CI come rete di sicurezza per tutto ciò che sfugge e per il codice scritto a mano. La sicurezza agent-time è il livello davanti a loro, che corrisponde alla velocità dell'agente che genera il codice. Considerali come partner: l'agent-time è la governance di prima linea dell'output dell'agente, la CI è il gate finale a livello di artefatto.

A quali agenti di codice AI si applica tutto questo?

Le stesse classi di rischio e lo stesso modello agent-time si applicano a Claude Code, Cursor, GitHub Copilot, OpenAI Codex e Windsurf, perché condividono una forma agentica: leggono, scrivono, eseguono e richiamano strumenti. Le guide per singolo agente coprono i controlli nativi di ciascuno strumento e dove sono carenti.

Qual è il principale rischio per la sicurezza di un agente di codice AI?

Due spiccano. La prompt injection è il rischio LLM numero uno di OWASP perché un modello non può separare in modo affidabile un'istruzione attendibile da una ostile nascosta nei dati, e un agente guidato agisce anziché limitarsi a rispondere male. Quello più silenzioso sono le falle di logica di business nel codice generato: controlli di proprietà mancanti e controllo degli accessi compromesso che gli scanner generici non vedono e i revisori sovraccarichi si perdono.

Quanto velocemente posso proteggere il mio agente di codice AI?

Circa cinque secondi per l'installazione e all'incirca un minuto dall'inizio alla fine. Esegui npx -y @cybedefend/vibedefend@latest install, scegli EU o US, conferma l'agente che usi e inserisci un .cybedefend/config.json di una riga nel repo. Il prossimo prompt è governato dai quattro livelli. Il piano gratuito non richiede carta, oppure puoi prenotare una sessione per eseguirlo sul tuo codice. Per una guida pratica passo per passo, vedi come mettere in sicurezza un'intera applicazione in 5 minuti.