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

Cos'e la sicurezza degli agenti di codice IA?

La sicurezza degli agenti di codice IA e la disciplina che vincola cio che un agente di codice autonomo produce ed esegue, attraverso la generazione, l'esecuzione di comandi e le chiamate agli strumenti, anziche proteggere solo la scatola in cui gira. Copre il codice che l'agente scrive, le dipendenze che tira dentro, i segreti che puo leggere e le azioni che puo 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 puo 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 finira per esporre i dati di un altro tenant. Il runtime e contenuto; l'artefatto no. Proteggere un agente di codice IA deve includere la protezione di cio che scrive, nel momento in cui lo scrive.

Perche un agente di codice IA e una nuova superficie di attacco?

Un agente di codice IA e una nuova superficie di attacco perche compie azioni anziche 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 e piu un singolo blocco di codice.

Due cambiamenti aggravano la cosa. Il primo e l'autonomia: l'agente puo essere guidato. Poiche un modello linguistico non puo distinguere in modo affidabile un'istruzione attendibile da una ostile sepolta nei dati, un attaccante puo nascondere istruzioni in un file, una pagina web, una issue o la risposta di uno strumento, e l'agente le segue. Questa e la prompt injection indiretta, ed e 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 e la velocita, ed e quello che la maggior parte dei team sottovaluta. La pull request funzionava come gate di sicurezza perche si collocava al ritmo umano. L'agente non gira al ritmo umano. Quando una singola sessione spedisce piu 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 anziche prevenirla.

Perche la scansione post-PR fallisce per gli agenti IA?

La scansione post-PR fallisce per gli agenti IA perche 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 piu.

Il fallimento non e che gli scanner smettano di trovare bug. Li trovano ancora. Il fallimento e nei tempi e nel volume. Quando uno scanner segnala un'injection nel diff sottoposto a merge, l'agente ha gia scritto la riga, e andato oltre, ha costruito tre funzionalita sopra di essa, e uno sviluppatore ha una coda di risultati da smistare che cresce piu 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. E un registro di cio che e gia accaduto.

C'e anche un disallineamento piu profondo. Le cose piu dannose che un agente IA sbaglia non sono gli schemi in cui gli scanner sono bravi. Sono le falle di logica di business: un controllo di proprieta 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 puo vederle, e un revisore che annega nell'output dell'agente non le cogliera nemmeno. Il controllo deve conoscere le tue regole e deve agire prima che la riga venga scritta.

Cos'e la sicurezza agent-time?

La sicurezza agent-time e la pratica di imporre i tuoi controlli dentro il loop dell'agente di codice IA, prima che la riga incriminata venga scritta, anziche 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, cosi il requisito diventa parte dell'output anziche una casella da spuntare al momento dell'audit.

E la risposta naturale al problema del ritmo. Se l'agente spedisce piu in fretta di quanto tu riesca a rivedere, non vinci rivedendo piu 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 perche un essere umano la leggeva. Il prompt e il punto di controllo ora perche l'agente lo ascolta. La sicurezza agent-time e 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 cio che sfugge, e per il codice che gli esseri umani scrivono ancora a mano. La sicurezza agent-time e il livello davanti a loro, quello che corrisponde alla velocita della cosa che genera davvero il codice.

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

I rischi principali sono coerenti tra Claude Code, Cursor, GitHub Copilot, OpenAI Codex e Windsurf, perche condividono la stessa forma agentica. Le guide per singolo agente coprono nel dettaglio i controlli nativi di ciascuno strumento; le classi di rischio in se fanno rima.

• Codice generato insicuro. L'agente scrive query iniettabili, crittografia debole, autorizzazioni mancanti e deserializzazione non sicura, perche quegli schemi sono abbondanti nei suoi dati di addestramento. Questo e il rischio che l'inquadramento infrastrutturale ignora del tutto.
• Falle di logica di business. Controlli di proprieta 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.
• 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 puo 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.
• 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.

Come si protegge un agente di codice IA in pratica?

Proteggi un agente di codice IA 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 e un controllo che viva al prompt e governi cio che l'agente scrive prima che lo scriva.

In pratica significa una postura di difesa in profondita con il punto di controllo portato in avanti. Limita i permessi dell'agente e isola il suo runtime cosi che un agente guidato abbia un raggio d'azione ristretto. Gestisci i segreti cosi che il contesto dell'agente non sia piu ampio di quanto il compito necessiti. Mantieni SAST e la scansione delle dipendenze nella CI per tutto cio che sfugge e per il codice scritto dagli esseri umani. Poi aggiungi il livello che corrisponde davvero alla velocita 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 e 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 e ancora il posto giusto per un controllo finale a livello di artefatto, e dovresti mantenerla. L'agent-time e dove sposti i controlli che perdono tutto il loro valore nel momento in cui l'agente ha finito ed e andato oltre. L'errore che fa la SERP e finanziare solo il cugino infrastrutturale della colonna di destra (sandbox, IAM) lasciando il codice vero e proprio non governato fino al merge.

VibeDefend e 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 gia 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 all'intera piattaforma AppSec di CybeDefend, i suoi scanner (SAST con reachability, SCA, segreti, IaC e CI/CD) in esecuzione continua, cosi l'agente non si limita a scrivere codice sicuro, smista e corregge le vulnerabilita che hai gia. Il modello di privacy e la parte a cui i team di sicurezza tengono di piu: 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 e scattata, il percorso del file su cui puntava, la severita, un timestamp. Nessun codice sorgente, nessun contenuto del prompt. I tenant EU e US sono fisicamente separati e scelti al momento dell'installazione, senza alcun percorso cross-region.

Domande frequenti

Cos'e la sicurezza agent-time?

La sicurezza agent-time consiste nell'imporre i tuoi controlli dentro il loop dell'agente di codice IA, prima che la riga incriminata venga scritta, anziche 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, cosi il requisito diventa parte dell'output. E la risposta agli agenti che spediscono codice piu in fretta di quanto qualsiasi essere umano riesca a rivedere.

In cosa la sicurezza degli agenti di codice IA e diversa dalla sandbox?

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

Perche la scansione post-PR fallisce per gli agenti IA?

Perche 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 piu 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 cio che sfugge e per il codice scritto a mano. La sicurezza agent-time e il livello davanti a loro, che corrisponde alla velocita dell'agente che genera il codice. Considerali come partner: l'agent-time e la governance di prima linea dell'output dell'agente, la CI e il gate finale a livello di artefatto.

A quali agenti di codice IA 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, perche 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 e il principale rischio per la sicurezza di un agente di codice IA?

Due spiccano. La prompt injection e il rischio LLM numero uno di OWASP perche un modello non puo separare in modo affidabile un'istruzione attendibile da una ostile nascosta nei dati, e un agente guidato agisce anziche limitarsi a rispondere male. Quello piu silenzioso sono le falle di logica di business nel codice generato: controlli di proprieta 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 IA?

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 e governato dai quattro livelli. Il piano gratuito non richiede carta, oppure puoi prenotare una sessione per eseguirlo sul tuo codice.