Proteggere gli agenti AI di coding nell'SDLC — il playbook per il CISO

Usa questo playbook quando un agente AI di coding ha accesso permanente al tuo codice sorgente o alla pipeline di build: un bot per le pull request, un agente di triage degli issue, un assistente della classe Copilot, Claude Code o Codex collegato alla CI, o qualunque workflow autonomo che possa leggere un repository, eseguire comandi shell e fare push di commit. Il rischio che lo definisce è che l'agente legge testo influenzabile dall'attaccante — il titolo di un issue, un commento a una PR, un file di configurazione committato — mentre detiene credenziali pensate per l'automazione fidata.

Nell'ambito: l'identità dell'agente e i suoi permessi su repo e CI, come gli input non fidati del repository arrivano nel suo contesto, il gate di revisione umana per il codice scritto dall'AI e la provenance che conservi per dimostrare cosa ha fatto l'agente.

Fuori ambito: l'insieme di controlli generale valido per qualsiasi agente (identità, governance MCP, monitoraggio dell'egress) — quello è il playbook sui controlli di sicurezza per l'AI agentica; e la difesa da una dipendenza di terze parti avvelenata che l'agente finisce per tirare, che è il playbook di risposta al malware firmato nella supply chain. Questo playbook è il caso specifico dell'SDLC in cui il raggio d'azione dell'agente è il codice sorgente e la build.

La sicurezza applicativa classica assume che i percorsi di codice siano fissi e che gli input siano dati. Un agente di coding rompe entrambe le assunzioni: sceglie a runtime quale tool invocare e tratta il contenuto del repository — issue, commenti alle PR, contenuto dei file, persino un .env committato — come istruzioni. Una serie di divulgazioni nel 2026 ne ha mostrato il costo, e condividono una sola causa radice: un agente ha elaborato testo non fidato mentre deteneva credenziali pensate per l'automazione fidata.

• La modalità di sicurezza dell'agente non è un confine di sicurezza. In CVE-2025-66032 (CVSS 8.7), difetti di parsing della shell intorno a $IFS e ai flag corti hanno permesso a contenuto non fidato nel contesto di Claude Code di bypassare la validazione read-only dell'agente ed eseguire codice arbitrario; corretto in @anthropic-ai/claude-code 1.0.93.
• La configurazione della CI è eseguibile nel momento in cui un agente la legge. CVE-2026-12537 (CVSS 10.0) ha permesso a un .gemini/.env artefatto di eseguire comandi sull'host CI perché Gemini CLI in modalità headless si fidava automaticamente della cartella di lavoro — e separatamente ignorava il proprio allowlist dei tool sotto --yolo; corretto in @google/gemini-cli 0.39.1 e nell'action run-gemini-cli 0.1.22. Un workflow che si limita a revisionare una pull request inviata eseguirebbe i comandi dell'attaccante.
• Una destinazione pre-approvata è un canale di esfiltrazione. CVE-2026-54316 (CWE-183) aveva pre-approvato l'host nudo huggingface.co per la WebFetch di Claude Code, così un agente indotto da contenuto iniettato poteva far uscire file e variabili d'ambiente attraverso un repository di modelli controllato dall'attaccante; corretto in @anthropic-ai/claude-code 2.1.163.

I ricercatori alla Black Hat USA dell'agosto 2026 hanno generalizzato lo schema come Comment and Control: un singolo titolo di PR, commento a un issue o commento HTML poteva far trapelare a un agente di coding il GITHUB_TOKEN e le API key dei provider nei log delle Actions leggibili pubblicamente, senza alcuna azione del maintainer oltre al trigger automatico. Nessuna di queste era un difetto del modello preso da solo — erano segreti ereditati, token troppo ampi, caricamento non sicuro della configurazione ed egress permissivo. I controlli qui sotto limitano esattamente quelli.

Obiettivo: l'agente è un principal con un nome, i cui permessi su repository e pipeline corrispondono al compito, senza accesso in scrittura permanente né segreti ampi tra un'esecuzione e l'altra.

• Dai a ogni agente la propria identità — un account macchina dedicato o un'installazione di app, mai il token di un maintainer umano o un service account condiviso. Serve l'attribuzione per agente quando ricostruisci un incidente.
• Tara l'accesso al repository su ciò che serve al compito. Un agente di triage degli issue ha bisogno di lettura e commento, non di contents: write. Concedi la scrittura solo ai repo specifici e, dove la piattaforma lo consente, ai path specifici.
• Tara i permessi CI per workflow. Limita id-token: write e contents: write ai job che ne hanno davvero bisogno; un job di triage o revisione non dovrebbe avere né l'uno né l'altro.
• Tieni i segreti fuori dalla portata dei trigger non fidati. Non esporre le API key dei provider o un GITHUB_TOKEN con scope di scrittura ai workflow che girano su issue_comment o pull_request_target dai fork.
• Fissa le action di terze parti, inclusa l'action dell'agente stesso, a un commit SHA completo invece che a un tag mobile, così una compromissione a monte non entra silenziosamente nella tua pipeline.

Checklist:

• [ ] Ogni agente ha un'identità distinta e inventariata; nessun account condiviso o umano.
• [ ] Scrittura sul repo tarata su repo/path specifici; sola lettura dove basta.
• [ ] id-token: write e contents: write limitati ai job che ne hanno bisogno.
• [ ] Nessun segreto esposto ai workflow attivati da fork o da commento.
• [ ] Action di terze parti fissate a commit SHA.

Obiettivo: nulla di ciò che l'agente legge da un repository — issue, PR, commento, file o configurazione — è fidato come istruzione per default.

• Sanifica o delimita chiaramente i metadati non fidati prima che raggiungano il contesto dell'agente. Tratta titoli e corpi di issue e PR, commenti e commenti HTML come input ostile, allo stesso modo in cui tratti l'input utente di qualsiasi altro sistema (OWASP LLM01 Prompt Injection).
• Non lasciare mai che i file di configurazione del repository si eseguano implicitamente. Richiedi un opt-in esplicito per fidarti di una cartella di lavoro — lo schema del fix dietro CVE-2026-12537 — e non lasciare che .env, i file di istruzioni dell'agente (AGENTS.md, .gemini/) o le impostazioni nell'albero di lavoro allarghino i permessi dell'agente.
• Mantieni autoritativo l'allowlist dei tool. Una modalità auto-approve o --yolo che ignora l'allowlist granulare trasforma una sola prompt injection in esecuzione di shell — l'allowlist deve reggere indipendentemente dalla modalità.
• Vincola l'accesso di rete in uscita dai runner CI a una lista di destinazioni note e buone. Un singolo host pre-approvato troppo ampio (CVE-2026-54316) basta a esfiltrare; l'egress in default-deny è la rete di sicurezza quando un gate di policy è solo consultivo.
• Richiedi l'approvazione umana registrata per le chiamate a tool ad alta conseguenza — push su branch protetti, pubblicazione, deploy, pagamenti — invece di lasciarle alla discrezione del modello. È l'istanza SDLC del limitare l'eccesso di agency, LLM06.

Checklist:

• [ ] Il testo non fidato del repo è delimitato/sanificato prima di entrare nel contesto dell'agente.
• [ ] La fiducia nella cartella di lavoro e nella configurazione è un opt-in esplicito, mai implicito.
• [ ] L'allowlist dei tool è applicato in ogni modalità, auto-approve inclusa.
• [ ] L'egress della CI è in default-deny verso una lista di destinazioni note.
• [ ] Le azioni ad alta conseguenza richiedono approvazione umana registrata.

Obiettivo: il codice scritto dall'AI arriva su un branch protetto solo attraverso un gate di revisione che un umano esercita davvero, con la provenance registrata.

• Rendi il gate di revisione obbligatorio e imposto dalla branch protection, non consultivo. Un agente non deve poter approvare la propria pull request né fare merge senza un revisore umano, e i bypass locali in stile --no-verify devono essere irrilevanti perché il gate vive sul remote.
• Dimensiona la capacità di revisione sul volume. Gli agenti aumentano il throughput delle PR; se i revisori non stanno al passo, il gate degenera in timbro automatico e diventa teatro. Limita le PR concorrenti degli agenti a ciò che i tuoi revisori riescono davvero a leggere.
• Mantieni controlli deterministici pre-merge che non dipendono dal buon comportamento dell'agente: secret scanning, SAST, controlli su dipendenze e licenze, build e test devono passare sul branch dell'agente come su qualsiasi altro.
• Registra la provenance delle modifiche scritte dall'AI — quale agente, quale modello e versione, quale prompt o compito, e il revisore umano — così puoi rispondere chi e cosa ha scritto questo a posteriori. La provenance a livello di build (SLSA) riconnette l'artefatto alla pipeline che l'ha prodotto.
• Tratta il log delle azioni dell'agente come un controllo, non come un optional. Un log mancante rende un incidente non investigabile.

Checklist:

• [ ] Revisione umana imposta dalla branch protection; gli agenti non possono auto-approvarsi.
• [ ] Volume di PR concorrenti degli agenti limitato alla capacità dei revisori.
• [ ] Secret scan, SAST, controllo dipendenze e test fanno da gate a ogni branch dell'agente.
• [ ] Provenance registrata per ogni modifica scritta dall'AI (agente, modello, compito, revisore).
• [ ] Le azioni degli agenti sono loggate e conservate per l'investigazione.

Tieni pronte queste — firmate, con marca temporale e catena di custodia — per un audit o un incidente che coinvolge un agente di coding:

• Inventario di ogni agente di coding: proprietario, identità, repo e path su cui può scrivere, segreti che può leggere, permessi CI, destinazioni di egress.
• Configurazione di branch protection e dei check obbligatori per ogni repo che un agente tocca.
• Il log delle azioni dell'agente (prompt/compiti, chiamate ai tool, commit, approvazioni) per la finestra in esame.
• Record di provenance per i merge scritti dall'AI (agente, modello e versione, revisore).
• La lista degli SHA fissati per le action di terze parti e la data dell'ultima revisione dei permessi CI.

La domanda difficile che un auditor o un consiglio pone dopo un incidente con un agente non è hai revisionato il diff — è puoi dimostrare che i percorsi di codice toccati dall'agente sono davvero sicuri. Una revisione legge l'intenzione; non dimostra la sfruttabilità. È qui che si inserisce il red team AI autonomo di Zero Hunt: esercita l'applicazione che l'agente sta scrivendo — i flussi autenticati, i percorsi raggiungibili dall'input — e dove una debolezza è reale genera un proof-of-concept funzionante contro la versione esatta installata, black-box per default e gray-box quando gli passi il sorgente, invece di restituire una lista piatta di forse-problemi. Ogni finding è firmato al momento della scrittura (Ed25519, con hash-chain), così l'evidenza che un percorso scritto dall'AI è stato testato è a sua volta verificabile. Poiché il motore gira on-premise sui propri modelli con un umano nel loop per tutto ciò che conta, il codice e i segreti su cui ragiona non lasciano mai il tuo perimetro — che è il punto quando l'oggetto del test è il tuo codice sorgente.

1. L'agente gira come un maintainer umano. Eredita l'accesso completo di quella persona al repo e all'organizzazione, e ogni azione è attribuita a lei — perdi minimo privilegio e forensics in un colpo solo. Dai all'agente la propria identità tarata.

2. Fidarsi dell'etichetta read-only o sandbox dell'agente come confine. CVE-2025-66032 e CVE-2026-12537 hanno sconfitto esattamente quell'assunzione. Il confine di sicurezza è l'identità, lo scope del token e la policy di egress — non un flag di modalità che il modello impone a se stesso.

3. Segreti esposti ai trigger da fork o da commento. I workflow su pull_request_target o issue_comment che possono leggere le key dei provider o un GITHUB_TOKEN con scope di scrittura sono la classe Comment and Control: un solo commento esterno li fa trapelare nei log. Separa i workflow a trigger non fidato da quelli che portano segreti.

4. Il gate di revisione come teatro. Quando il volume di PR degli agenti supera la capacità dei revisori, le approvazioni diventano riflesse e il gate smette di intercettare qualunque cosa. Limita il volume o aggiungi revisori; un gate timbrato automaticamente è peggio di un processo manuale onesto perché sembra un controllo.

5. Niente provenance, niente log. Dopo un incidente non puoi dire quale agente ha scritto la modifica, sotto quale modello, o chi l'ha approvata. Registralo al momento del merge — ricostruirlo dalla sola storia Git è di solito impossibile.

6. Allowlist di egress troppo ampi. Una singola pre-approvazione di host nudo (CVE-2026-54316) è un canale di esfiltrazione. Tara l'egress su endpoint specifici e nega di default il resto.

Un programma per gli agenti di coding risponde a più regimi insieme, e un solo set di controlli li copre:

• Art. 21 NIS2 elenca la sicurezza nello sviluppo e nell'acquisizione tra le misure di base; un agente non governato con accesso al repo è una lacuna che un assessment ACN/ENISA sonderà.
• Artt. 24-25 DORA (finanza) si aspettano test regolari e produttori di evidenze sull'ICT che supporta funzioni critiche — inclusa la pipeline che lo spedisce.
• Art. 13 CRA obbliga i fabbricanti di prodotti a gestire uno sviluppo sicuro e un processo di gestione delle vulnerabilità; il codice scritto dall'AI in un prodotto con elementi digitali rientra nell'ambito.
• AI Act UE: se l'agente di coding è esso stesso un sistema AI ad alto rischio o general-purpose, scattano le sue obbligazioni di governance — pianificale invece di scoprirle in un assessment.
• NIST SSDF (SP 800-218) e il suo companion per l'AI generativa SP 800-218A danno il vocabolario di pratiche — proteggi la pipeline, revisiona il codice, archivia la provenance — che mappa sui tre domini di controllo qui sopra; la OWASP Agentic Security Initiative fornisce il catalogo delle minacce.

Costruisci le evidenze una volta ed esportale per regime. La validazione continua e ordinata per sfruttabilità del codice che i tuoi agenti spediscono — invece di un pentest annuale già obsoleto il giorno del merge — è il fratello offensivo di questo set di governance; vedi il penetration testing automatizzato continuo e, per come si inserisce nella gestione dell'esposizione, il CTEM.