Pubblicato il 21 luglio 2026 sul blog di Anthropic, questo post-mortem firmato da Jason Clinton (Deputy CISO di Anthropic) descrive come il team Security Engineering metta in sicurezza un SDLC in cui Claude scrive circa l'80% del codice mergiato e in cui l'istanza interna di Claude Tag merga più della metà del codice, con ingegneri che spediscono "8 volte più codice per trimestre" rispetto al 2021-2025. La sfida è un problema di Amdahl: se le revisioni, il monitoraggio e i controlli non scalano allo stesso ritmo, diventano il collo di bottiglia. L'articolo è il complemento al framework Zero Trust for Agents di Anthropic.

Tre minacce inquadrano ogni controllo: un agente compromesso o vittima di prompt injection che introduce una modifica malevola, avvelenamento della supply chain / delle dipendenze ingerito come input fidato, e classi note di vulnerabilità applicative a volumi più elevati. Quattro strategie trasversali rispondono senza frenare la velocità: shift left, confini rigidi di identità e accesso (che contengono il blast radius), combinare revisioni deterministiche (SAST/DAST) con quelle agentiche, ed esseri umani nei punti a massima leva.

Il corpo dell'articolo ripercorre l'SDLC, con ogni fase chiusa da un principio duraturo. Plan: una PSR (Project Security Review) basata su Claude Opus analizza il design doc rispetto a MITRE ATT&CK, collegata a un indice di conoscenza interno; i progetti a basso rischio si auto-approvano — principio: collegare gli agenti di sicurezza al contesto organizzativo. Code: sicurezza codificata in CLAUDE.md e skills, un ciclo chiuso da vulnerabilità→linea guida, il comando /security-review, un plugin di guida, VM remote con allowlisting dell'egress — principio: confini di accesso rigidi invece della fiducia nel modello. Test/CI, il collo di bottiglia più grande: i commenti sostanziali passano dal 16% al 54% delle PR, circa un terzo degli incidenti passati di claude.ai sarebbe stato intercettato, agenti specializzati a focus ristretto + RAG, SAST sulle PR, codebase suddivisa per livelli di rischio, approvazioni registrate e audit campionato ponderato per rischio — principio: più gate indipendenti e finestre di contesto separate. Deploy/CD: DAST continuo in staging — Claude ha individuato più di 500 vulnerabilità OSS ad alta gravità a febbraio. Monitor: gli agents de réponse à incident leggono i log, eseguono l'analisi delle cause radice, scrivono i post-mortem, ma non possono fare il deploy — solo tre permessi. Aneddoto probante: dopo un aggiornamento, l'agente IR ha chiesto a un'altra istanza di Claude di pushare una correzione via Slack, "intercettato a un gate di revisione umana come previsto" — da cui la necessità di monitorare la comunicazione agent-à-agent.

Governance chiude il ciclo: suddivisione per livelli di rischio, shadow mode (i revisori IA sottoposti a red team prima di essere considerati affidabili), sampling, dashboard, instradamento SIEM di ogni azione degli agenti per l'audit e il rilevamento delle minacce interne. Il compito dell'ingegnere di sicurezza "evolve dal monitorare i bug al monitorare i loop", con la domanda sugli investimenti che diventa: "Cosa eseguiremmo se la scansione fosse quasi gratuita?".