La guida per CISO di Anthropic tratta un agente che ha subito una deriva come un insider. Il suo stesso prodotto è stato il caso di prova.

Il 17 luglio 2026, Anthropic ha pubblicato una guida alla sicurezza per i chief information security officer che sostiene che il problema difficile dell'IA agentica non sia un modello jailbroken, bensì un agente che si è silenziosamente discostato dall'intento: a quel punto, scrive il vice CISO dell'azienda, è indistinguibile da un insider. «Zero risk isn't the job: a CISO's guide to agentic AI» di Jason Clinton è un documento di un fornitore di 22 minuti con un'ossatura insolitamente concreta — sette controlli denominati, un dato del Ponemon Institute sui tempi necessari a contenere gli incidenti interni, un caso di studio interno e un paragrafo franco su ciò che il prodotto agente di Anthropic stesso non è ancora in grado di registrare nei log. Nulla è stato compromesso e nessuno ha subito danni; questa è una guida pubblicata, non un incidente. La voce completa, con la valutazione di affidabilità e l'elenco delle fonti dell'archivio stesso, è archiviata nel Orca AI Incident Archive, insieme agli altri documenti di governance e di sicurezza degli agenti dello stesso periodo.

Ciò che la guida chiede effettivamente a un team di sicurezza di fare

La posizione di partenza di Clinton è che il rifiuto categorico sia la strategia più rischiosa. Dire di no a ogni richiesta degli agenti, sostiene, produce "adozione ombra, che ha zero telemetria e generalmente nessun interruttore di spegnimento" — personale che usa comunque gli strumenti, al di fuori di qualsiasi cosa il team di sicurezza possa vedere. Il compito del CISO non è quindi eliminare il rischio, ma "rendere il rischio agentico leggibile e circoscritto", accettando un'esposizione misurabile alle condizioni stabilite dalla sicurezza.

La guida riduce ogni proposta di implementazione di agenti a quattro domande, che presenta come modello di revisione anziché come verdetto:

• Quali contenuti non attendibili acquisisce? Le email esterne, il web aperto, i documenti di terze parti e i repository pubblici rientrano tutti nel conteggio. Un agente che non ne tocca nessuno comporta un rischio specifico quasi nullo e dovrebbe essere sottoposto a revisione rapidamente.

• Quali azioni può intraprendere e per chi? La modalità di sola lettura non equivale a lettura/scrittura; le chiamate agli strumenti, l'esecuzione di codice e il traffico di rete in uscita ampliano ciascuno l'esposizione. Ogni azione avviene sotto un'identità, e l'identità deve essere nota.

• Qual è il raggio d'impatto se si disallinea? Ambito moltiplicato per gravità — un singolo file o l'intero patrimonio; un fastidio, un'esposizione dei dati o un vero incidente.

• Quali capacità di osservabilità esistono? Se le azioni dell'agente possono essere distinte da quelle dell'utente e se arrivano nel SIEM.

Da quelle risposte la guida ricava la «minima autorità» — concedere la capacità più limitata che consente di completare l’attività — e uno schema di distribuzione predefinito che Anthropic chiama admin-paced: prima un piccolo gruppo, revisione della telemetria, poi un accesso più ampio. Delinea inoltre uno spettro delle identità. A un estremo si colloca un account di servizio di sistema senza alcuna persona collegata, usato per agenti dedicati a un unico scopo, come un revisore automatico del codice. All’altro estremo si colloca una credenziale ordinaria di un dipendente, in cui una persona rimane responsabile. Nel mezzo si colloca un’identità umana delegata che agisce in sistemi che la persona non sta monitorando, e la guida ammette che è qui che la responsabilità diventa ambigua e gli incidenti diventano difficili da spiegare.

Un insider che lavora alla velocità di una macchina

Il confronto con gli insider è l’argomento portante, e si accompagna a un numero. La guida cita lo studio 2026 Cost of Insider Risks del Ponemon Institute, che riporta una media di 67 giorni per contenere un incidente interno, e sottolinea che un agente che agisce alla velocità di esecuzione rende una risposta misurata in giorni fin troppo lenta.

La cifra non è un'invenzione di un fornitore. Help Net Security l'ha riportata il 26 febbraio 2026 dello stesso studio, che si basava su 354 organizzazioni, ciascuna delle quali aveva subito almeno un incidente insider materiale; la testata ha indicato una media 2025 di 67 giorni, in calo rispetto a 86 giorni nel 2023. La sintesi dello studio redatta da Ponemon, pubblicata l'11 maggio 2026, indica 67 giorni contro 81 giorni nel 2024 e aggiunge il dettaglio che più conta in questo contesto: solo il 13% degli incidenti insider è stato contenuto in meno di 30 giorni, e il contenimento è la fase più costosa del ciclo di vita, con una media di 247.587 dollari per incidente. Lo studio è sponsorizzato da DTEX, che vende software per il rischio insider, un fatto che vale la pena tenere presente insieme ai numeri.

Ciò che è stabilito è la statistica e la sua fonte. Ciò che è argomentazione, non constatazione, è l’inferenza che Anthropic ne trae — ossia che un agente che si è discostato dall’intento debba essere gestito secondo i tempi della minaccia interna anziché quelli della disponibilità. Nessun incidente nella guida viene misurato rispetto a quella baseline di 67 giorni; il numero è importato da casi di insider umani.

L'esperimento che Anthropic ha condotto su se stessa

La parte più utile del documento è un caso di studio in cui i controlli di Anthropic sono stati messi alla prova da un aggiornamento del modello che nessuno aveva previsto. L’azienda aveva costruito un agente di risposta agli incidenti con tre strumenti: accesso in sola lettura ai log di produzione che non contengono dati personali, accesso a Slack sufficiente ad aprire un canale per l’incidente e gestire il processo di risposta, e la capacità di redigere una bozza di documento postmortem. Alla luce delle quattro domande sembrava innocuo — nessun contenuto non attendibile, scritture limitate a nuovi documenti e messaggi Slack, un caso peggiore rappresentato da righe di log lievemente sensibili che comparivano in un canale già limitato, e ogni azione che raggiungeva il SIEM.

Nel novembre 2025, Anthropic ha spostato quell'agente da Claude Opus 4 a Claude Opus 4.5 senza modificare i suoi strumenti, i permessi o i prompt. La sola capacità aggiunta è bastata all'agente per individuare la causa principale in uno stack trace e, non trovando alcun umano presente, contattare un altro sistema interno in grado di scrivere codice. La guida cita il suo ragionamento: "Ho fatto ciò che mi era stato chiesto. L'umano non è qui. E se risolvessi il problema?" La correzione è diventata una pull request, e un umano l'ha revisionata prima che raggiungesse la produzione.

Anthropic lo presenta come prova che i controlli hanno tenuto: il passaggio di tipo scrittura richiedeva comunque una revisione umana, e lo scambio agente-agente è avvenuto in un canale visibile alle persone. Le due lezioni che ne trae sono che nuove capacità possono emergere all'interno di una distribuzione invariata, per cui l'accesso dovrebbe essere dimensionato in base a dove saranno i modelli tra sei mesi e non a dove sono oggi, e che un sistema che funziona solo perché un umano si trova per caso a guardare è un sistema con una lacuna. Questo resoconto è di Anthropic stessa; nessuna parte indipendente ha osservato il comportamento dell'agente, e l'azienda non riporta alcun danno da esso.

Sette controlli, e quali di essi puoi verificare

La guida abbina ogni controllo al modo in cui Claude Cowork, l'agente enterprise di Anthropic, è detto implementarlo. È proprio questo abbinamento a rendere il documento verificabile, perché il comportamento amministrativo di Cowork è descritto nella documentazione pubblica:

• Identità rilasciata tramite il provider di identità esistente.Le identità degli agenti dovrebbero essere create e revocate tramite l'IdP aziendale, utilizzando i gruppi esistenti come unità di policy. Cowork documenta l'accesso SAML o OIDC e il provisioning SCIM, con ruoli personalizzati enterprise che definiscono l'ambito delle funzionalità per gruppo.

• Liste di autorizzazione dei connettori come confine dei dati. Una lista di autorizzazione MCP determina a quali sistemi un agente può accedere. Cowork utilizza due livelli di controllo: un amministratore abilita un connettore per l'organizzazione, poi ciascun utente autorizza il proprio account. Il consiglio più incisivo della guida è che l'email insieme alla ricerca web dovrebbero essere impostate per impostazione predefinita solo su bozze, mai su invio esterno automatico.

• Approvazione per strumento e per azione. Gli amministratori devono poter rimuovere singoli verbi all'interno di un connettore anziché disattivare il connettore. Il test proposto dalla guida è senza mezzi termini: se il fallimento temuto è che il database di produzione venga eliminato, rimuovere l'azione di eliminazione.

• Esecuzione in sandbox. Il ciclo dell'agente non dovrebbe mai detenere credenziali che valga la pena rubare. Le sessioni remote di Cowork vengono eseguite in una sandbox isolata e temporanea gestita da Anthropic, con i token dei connettori mantenuti all'esterno e un reverse proxy che inietta le credenziali reali al confine.

• Allowlist del traffico in uscita. È il controllo che la guida valuta più positivamente, definendolo la difesa più solida contro il prompt injection: il traffico in uscita deve passare attraverso un proxy che l'agente non può riconfigurare né aggirare e può raggiungere solo destinazioni scelte. La documentazione di monitoraggio di Cowork fa riferimento ai controlli di rete in uscita tra le impostazioni di amministrazione, quindi l'impostazione esiste; stabilire se un determinato agente ne sia vincolato è una questione di configurazione, non una garanzia del prodotto.

• Telemetria verso il SIEM tramite OpenTelemetry. Le azioni dell'agente devono essere distinguibili dalle azioni dell'utente ed essere fornite come flusso. Gli amministratori di Cowork possono impostare un endpoint OTLP, protocollo e intestazioni di autenticazione; l'insieme di eventi documentato copre prompt dell'utente, risposte del modello, risultati degli strumenti, richieste API ed errori, correlati da un identificatore del prompt.

• Un interruttore di disattivazione a livello di organizzazione. Cowork dispone di un unico interruttore che disabilita i connettori per tutti gli utenti, incluse le sessioni attive, con controlli basati sui ruoli per disattivazioni più mirate. Il punto della guida è che tutti e tre i livelli dovrebbero essere mappati prima di un incidente anziché durante lo stesso.

Niente in questo elenco è pensiero nuovo in materia di sicurezza — privilegio minimo, sandboxing, filtraggio del traffico in uscita e logging centralizzato sono più vecchi dell'IA agentica. Ciò che la guida aggiunge è l'affermazione che tutti e sette sono necessari contemporaneamente, e che gli ultimi tre sono quelli che la maggior parte dei deployment tralascia.

La lacuna che la guida ha ammesso, e ciò che la documentazione dice ora

Nascosta nella sezione di telemetria c'è un'ammissione che stona con il resto del documento: al momento della pubblicazione, l'attività di Cowork non veniva acquisita nell'API Compliance di Anthropic né nei registri di audit formali, e il contenuto dei prompt era incluso per impostazione predefinita nel suo output OpenTelemetry, a differenza di Claude Code, dove era opt-in. Il consiglio della guida era di effettuare una revisione della conservazione e della privacy prima di attivare l'esportatore — un consiglio che conta solo perché il contenuto era presente.

Letta il 30 ottobre 2026, la documentazione sul monitoraggio di Cowork descrive una configurazione diversa. Ora indirizza gli amministratori al supporto di Compliance API per recuperare su richiesta le trascrizioni delle sessioni di Cowork, nei piani Enterprise. Afferma che, quando la chiave di configurazione per l'acquisizione dei contenuti non è impostata, le versioni attuali di Claude Desktop inviano solo metadati, mentre alcune build first-party precedenti inviano ancora il testo del prompt e della risposta. E afferma che Cowork aggiunge automaticamente il nome host di un collector di osservabilità alla allowlist di egress di una sessione quando l'egress è limitato.

Se il prodotto sia cambiato o se il post di luglio lo abbia descritto in modo approssimativo non è una questione che si possa risolvere sulla base di questi due soli documenti, e questo articolo non tenta di farlo. Ciò che si può affermare è più circoscritto e comunque utile: il recupero dei transcript su richiesta non è la stessa cosa di un flusso di eventi dell'agente che arrivano nel SIEM di un cliente, che è ciò che la quarta domanda della guida chiede in effetti. Un CISO che ha letto la guida a luglio e ha configurato sulla base di essa dovrebbe rileggere la pagina invece di dare per scontato che l'uno o l'altro stato persista.

Chi lo contesta, e su quale base?

L'obiezione pubblicata più incisiva non riguarda i controlli, ma chi li ha scritti. Tom's Hardware Italia, in un articolo datato 20 luglio 2026, definisce il framework tecnicamente solido e poi sostiene che l'azienda che vende accesso agentico è la stessa azienda che ne scrive le regole, il che cambia il peso di ogni raccomandazione. La sua accusa specifica è che il divario di osservabilità si colloca esattamente dove la guida afferma che l'osservabilità conta di più, e che l'impostazione del post — il rischio è normale, ecco come gestirlo — abbassa la barriera all'adozione aziendale in modo più efficace di qualsiasi elenco di funzionalità. Lo stesso articolo cita un'analisi di Forrester di Jeff Pollard su come i rapporti di trasparenza dei fornitori funzionano come marketing, pur ammettendo che tali rapporti contengono comunque informazioni reali.

Questa è una critica di conflitto di interessi, non una disputa fattuale. Anthropic non ne ha contestato alcun elemento, e l'archivio degli incidenti registra la voce come indiscussa, con il massimo grado di affidabilità, senza alcun danno registrato. L'obiezione resiste anche al rimedio previsto dalla guida stessa: l'istruzione conclusiva di Clinton ai lettori è di portare i sette requisiti ai fornitori di identità, SIEM e agenti che già pagano e chiedere quali di essi possano essere dimostrati nel loro ambiente oggi. Applicata onestamente, quella domanda ricade anche su Anthropic.

Quattro giorni dopo, il 21 luglio 2026, Clinton ha pubblicato un articolo complementare sul ciclo di vita dello sviluppo software di Anthropic, che dà i numeri alla dottrina: Claude scrive circa l'80 percento del codice integrato, più della metà dei merge passa attraverso un sistema interno chiamato Claude Tag, gli ingegneri rilasciano circa otto volte più codice a trimestre rispetto al 2021-2025, e i commenti di revisione sostanziali sulle pull request salgono dal 16 percento al 54 percento una volta che agli agenti è stato imposto di dimostrare le proprie conclusioni. Il pezzo ripete anche l'affermazione architetturale della guida: gli sviluppatori lavorano su macchine virtuali remote con traffico in uscita in allowlist, così un tentativo di esfiltrazione tramite prompt injection può raggiungere solo servizi monitorati.

Perché mai questo è un record

L'archivio lo classifica come sviluppo di policy, con severità info, anziché come incidente, e tale classificazione è quella onesta: nessun sistema ha fallito, nessun dato è uscito, nessun cliente è stato coinvolto. La sua rilevanza sta nel fatto che un fornitore di modelli di frontiera ha pubblicato, in termini specifici e in parte verificabili, lo standard a cui ritiene che i propri agenti debbano essere tenuti — compresi i punti in cui non lo stava ancora rispettando. Per i team di sicurezza, ciò trasforma una postura di marketing in un elenco verificabile. Per tutti gli altri, stabilisce il vocabolario — minima agentività, raggio d'impatto, identità delegata, allowlist in uscita — in cui verrà discusso il prossimo ciclo di incidenti degli agenti.