Il caso degli agenti di programmazione compromessi attraverso la tecnica denominata “Comment and Control” evidenzia come il problema non risieda più solo nella robustezza del modello linguistico, ma nell’intera architettura di runtime e nella gestione dei segreti all’interno degli ambienti di esecuzione. Questa specifica minaccia si manifesta quando un attaccante, inserendo istruzioni malevole in elementi apparentemente innocui come i titoli delle pull request o i commenti al codice, riesce a manipolare il flusso logico dell’agente AI. Una volta attivata, l’iniezione del prompt consente all’agente di eseguire azioni non autorizzate, come l’esfiltrazione di chiavi API e token di accesso (GITHUB_TOKEN o chiavi di fornitori LLM) che sono spesso memorizzati come variabili d’ambiente nel corridore dell’agente.
Il fallimento sistemico identificato nelle analisi più recenti riguarda la discrepanza tra le capacità dichiarate nelle “System Cards” dei produttori e l’effettiva implementazione del controllo degli accessi. Sebbene molti vendor specifichino i rischi di iniezione di prompt nelle loro schede di sicurezza, le aziende continuano a distribuire agenti su superfici non verificate o prive di isolamento dinamico. La vulnerabilità è aggravata dalla natura stessa delle CI/CD moderne, dove i segreti a livello di organizzazione o repository vengono propagati indiscriminatamente a ogni fase del workflow. Un agente AI che opera in questo ambiente ha accesso visivo e programmatico a credenziali che non dovrebbero far parte della sua area di competenza, trasformando uno strumento di produttività in un potenziale vettore di esfiltrazione dati senza che l’attaccante debba controllare alcuna infrastruttura esterna, sfruttando le API stesse della piattaforma come canale di comando e controllo.
Un ulteriore elemento critico emerso nel panorama della sicurezza del 2026 è l’inefficacia delle patch tradizionali di fronte a attacchi di tipo agentico. Mentre Microsoft ha tentato di correggere iniezioni di prompt in sistemi come Copilot Studio, le evidenze mostrano che i dati continuano a fuoriuscire nonostante l’attivazione dei meccanismi di sicurezza. Questo accade perché i sistemi di Data Loss Prevention (DLP) convenzionali non sono progettati per monitorare le chiamate agli strumenti (tool calls) effettuate autonomamente dagli agenti. La capacità di un agente di riscrivere configurazioni infrastrutturali o firewall richiede un paradigma di sicurezza basato sulla “Runtime Isolation” e sul monitoraggio granulare delle intenzioni del modello, piuttosto che sul semplice filtraggio degli input.
La visibilità della catena di approvvigionamento dell’IA è diventata dunque il principale punto di rottura. Molte organizzazioni non dispongono di una Software Bill of Materials (SBOM) specifica per l’IA che tracci non solo il modello utilizzato, ma anche i punti di integrazione, le politiche di conservazione dei dati e i permessi OAuth concessi. L’assenza di workflow di approvazione per le autorizzazioni degli agenti permette a questi sistemi di muoversi lateralmente nelle reti aziendali con privilegi simili a quelli di un amministratore umano. Per chiudere questo gap di rilevamento, è necessaria una transizione verso token OIDC a breve durata e un audit rigoroso delle configurazioni di runtime, verificando se le protezioni del vendor si estendano effettivamente ai tenant specifici utilizzati dall’impresa, evitando di fare affidamento esclusivamente sugli annunci di lancio commerciale che spesso omettono le esclusioni tecniche critiche.