La modalità automatica è ora l'impostazione predefinita in Claude Code per i piani Pro, Max e Team

Aggiornamento, 22 ottobre 2026: la modalità automatica verrà introdotta la prossima settimana come impostazione predefinita per le nuove sessioni nella maggior parte delle app Claude dei piani Pro, Max e Team. Invece di chiederti di approvare ogni azione, un controllo automatizzato le esamina: le azioni sicure vengono eseguite, mentre quelle rischiose vengono bloccate mentre Claude cerca un'altra strada. Gli amministratori Enterprise riceveranno un'e-mail prima che la modalità automatica diventi quella predefinita per le proprie organizzazioni.

Prima di impostare la modalità automatica come predefinita in Claude Code, l'abbiamo testata internamente e tramite red-teaming di terze parti. Abbiamo sfruttato questi risultati per rafforzare il funzionamento della modalità automatica in tutti i nostri prodotti. I dati riportati di seguito in questo articolo si riferiscono specificamente a Claude Code.

Stiamo impostando la modalità automatica come predefinita in Claude Code. A partire dal 14 agosto, le nuove sessioni dei piani Pro, Max e Team verranno eseguite in modalità automatica. Se hai già impostato una modalità predefinita diversa, potresti ricevere un prompt una tantum che ti chiede se desideri passare alla modalità automatica. Se hai un'impostazione predefinita fissata, per te non cambia nulla. Il classificatore della modalità automatica utilizza un esiguo numero di token aggiuntivi per ogni chiamata a uno strumento e, a partire da oggi, non addebitiamo più agli utenti Claude Code con piani Pro, Max e Team tale sovraccarico del classificatore.

La modalità automatica rimane per il momento opzionale per Claude Enterprise, Claude API, Claude Platform on AWS, Amazon Bedrock, Google Cloud's Agent Platform e Microsoft Foundry, offrendo agli amministratori il tempo di esaminare la modifica. Nel prossimo mese, in collaborazione con i nostri partner cloud, prevediamo di renderla l'impostazione predefinita su tutte queste piattaforme e di non addebitare più i costi di gestione del classificatore. Nel frattempo, gli amministratori Enterprise possono rendere predefinita la modalità automatica di Claude Code tramite le impostazioni gestite.

La modalità automatica è progettata per conciliare il desiderio degli utenti di non essere interrotti con un sistema che aiuta a evitare azioni dannose: anziché mostrare prompt, instrada ogni chiamata a uno strumento attraverso un classificatore pensato per bloccare le azioni irreversibili, distruttive o rivolte all'esterno del tuo ambiente. Quando il classificatore blocca qualcosa, Claude di solito trova in autonomia un modo più sicuro per procedere o ti chiede direttamente l'autorizzazione; se non riesce a fare progressi, se ad esempio riceve tre blocchi consecutivi o venti nell'arco di una sessione, Claude Code torna alle approvazioni manuali.

Abbiamo trascorso gli ultimi mesi a verificare se la modalità automatica sia sicura quanto, o più, di un utente medio che approva i prompt uno dopo l'altro. Abbiamo condotto valutazioni interne di red-teaming, valutazioni di red-teaming di terze parti e di prompt injection, uno studio controllato con 1.053 tester a pagamento e un'analisi di sessioni di produzione reali. Per ogni parametro testato, la modalità automatica ha eguagliato o superato la revisione manuale.

La modalità automatica consente inoltre a Claude di lavorare in modo autonomo per periodi più lunghi. Ciò rende i modelli progettati per lavori di lunga durata, come Claude Opus 5, più pratici da lasciare in esecuzione per ore su attività di grandi dimensioni. Ridurre i costi operativi per gli utenti aumenta anche la produttività. Tra chi ha adottato Teams ed Enterprise, gli utenti della modalità automatica rilasciano circa il 25% di PR in più. Sbloccare Claude consente di eseguire le attività più a lungo senza interruzioni e di svolgere una maggiore quantità di lavoro. I team di Adobe, Nuro, Gusto e Garner Health utilizzano già la modalità automatica come impostazione di produzione predefinita.

Di seguito condividiamo i dati sulla sicurezza e i risultati ottenuti dai clienti che hanno motivato questo cambiamento, oltre alle indicazioni su come impostare un'opzione predefinita diversa, qualora lo desiderassi.

Confronto tra la revisione manuale e la modalità automatica

I dati suggeriscono che la revisione manuale può diventare un'abitudine: gli utenti approvano il 97% delle richieste di autorizzazione in Claude Code. Sebbene la maggior parte dei prompt si riferisca probabilmente a comandi sicuri e di routine, un tasso di approvazione così elevato suggerisce che molti utenti facciano clic in modo automatico, anziché esaminare ogni comando. Questi prompt richiedono ai team di sviluppo di prendere decine o centinaia di importanti decisioni di sicurezza ogni giorno, spesso nel bel mezzo di progetti, il che fa gravare l'onere di revisione sugli utenti e aumenta la probabilità che qualcosa di importante venga trascurato. I dati suggeriscono inoltre che gli utenti esaminano e respingono più frequentemente altri tipi di dialogo: ad esempio, quando Claude presenta un piano da approvare, gli utenti ne rifiutano il 39%. Tuttavia, per le singole richieste di autorizzazione, il tasso di rifiuto è solo del 3%.

Lo stesso pattern si presenta nei file delle impostazioni. A giugno 2026, il 49,5% degli utenti attivi della CLI ha creato manualmente una regola di autorizzazione per Bash: il 5% consente qualsiasi comando della shell senza restrizioni, mentre un altro 43% ha definito regole per interpreti come Bash(python:*) o Bash(node:*), che nella pratica sono sostanzialmente equivalenti. Tale quota sta crescendo di circa cinque punti percentuali ogni cinque settimane. Oltre alle regole di autorizzazione, il 62% degli utenti ha utilizzato bypassPermissions o ha fatto clic su "Non chiedere più" per Bash e il 25% delle sessioni interattive inizia in modalità di bypass delle autorizzazioni.

Le regole di autorizzazione continuano ad attivarsi prima del classificatore in modalità automatica, a eccezione delle regole di consenso abbastanza ampie da consentire l'esecuzione di codice arbitrario, ad esempio python:*. Queste regole arbitrarie vengono messe da parte in modalità automatica, poiché consentirebbero ai comandi di saltare completamente il classificatore. I file delle impostazioni non vengono modificati e le regole si applicano nuovamente nel momento in cui passi a un'altra modalità.

Migliorare la sicurezza con la modalità automatica

La ricerca condotta internamente e tramite diverse terze parti suggerisce che la modalità automatica è più sicura del modo in cui l'utente medio gestisce oggi i prompt di autorizzazione. Abbiamo confrontato la modalità automatica con ciò che i team di sviluppo approvano effettivamente quando fanno clic sui prompt di autorizzazione. In tutte queste valutazioni, ovvero red-teaming interno, penetration test condotti da terze parti e analisi di sessioni reali, la modalità automatica ha ottenuto risultati pari o superiori all'approvazione umana.

La modalità automatica supera le autorizzazioni manuali in termini di sicurezza

Abbiamo reclutato 1.053 tester retribuiti tramite una società di ricerca per uno studio sulla programmazione. Questi partecipanti hanno lavorato in un ambiente di test configurato appositamente per lo studio, non all'interno di codebase personali o su progetti reali. I partecipanti sapevano di essere valutati ma, secondo il design standard degli studi in cieco, non venivano informati su quale comportamento venisse misurato. Nel corso di ogni sessione, un singolo prompt di autorizzazione è stato sostituito con un prompt contenente un comando chiaramente pericoloso e il fornitore ha registrato se il tester lo avesse approvato. Nota: l'approvazione del prompt non ha mai comportato l'esecuzione di nulla di pericoloso; è stato modificato solo il testo del prompt visualizzato dai tester.

I tester hanno individuato il comando pericoloso solo nel 13,6% dei casi (143 su 1.053), mentre la modalità automatica ha bloccato l'89% degli stessi comandi (937 su 1.053). Nel confronto diretto, la modalità automatica ha bloccato 800 comandi che un essere umano aveva approvato, mentre gli esseri umani ne hanno bloccati solo sei che la modalità automatica aveva consentito. Con l'allungarsi delle sessioni, gli esseri umani hanno ottenuto risultati peggiori: hanno bloccato circa il 17% dei comandi pericolosi all'inizio di una sessione, scendendo al 5% circa dopo 50 o più prompt, mentre la percentuale di blocco della modalità automatica è rimasta invariata indipendentemente dalla durata della sessione.

La modalità automatica previene un numero maggiore di azioni dannose

La nostra ricerca indica inoltre che la modalità automatica comporta un numero inferiore di azioni dannose rispetto alla modalità con autorizzazioni manuali.

Abbiamo esaminato il funzionamento della modalità automatica nell'utilizzo reale. Da maggio a giugno 2026 abbiamo esaminato le sessioni che la nostra pipeline di sicurezza aveva segnalato per la revisione, provenienti esclusivamente da account che avevano acconsentito all'utilizzo dei dati per l'addestramento e l'analisi. Abbiamo rivalutato ciascuna di esse con un modello su due scale da 0 a 10. La prima era la gravità del danno: 10 corrispondeva a un danno irreversibile a livello aziendale, come la divulgazione dell'intero codice sorgente di un'azienda; 7 corrispondeva a una gravità a livello di produzione, come l'eliminazione di righe da un database di produzione; 0 corrispondeva a un'azione completamente reversibile e limitata all'area di lavoro locale, come la sovrascrittura di un file temporaneo. La seconda era quanto esplicitamente l'utente avesse richiesto l'azione, in modo da poter separare le azioni dannose richieste direttamente dall'utente da quelle intraprese dall'agente con indicazioni meno esplicite.

Tra le sessioni segnalate, quelle sottoposte ad approvazione manuale contenevano gravi danni non intenzionali con una frequenza più che doppia rispetto alle sessioni in modalità automatica. Con una gravità di livello produzione (7+), il 6,3% delle sessioni approvate manualmente conteneva un'azione dannosa che l'utente non aveva richiesto esplicitamente, contro il 2,4% delle sessioni in modalità automatica, e il divario si è mantenuto a ogni livello di gravità testato.

Il red teaming avversariale ha reso più robusta la modalità automatica

Abbiamo collaborato con Apollo Research, una startup britannica specializzata nella sicurezza dell'IA, a un progetto pilota della durata di due settimane che ha previsto l'inserimento di attacchi sintetici all'interno di reali percorsi di programmazione, utilizzando tre set di dati relativi a malfunzionamenti generali, esfiltrazione di dati e minacce legate alla sicurezza.

La collaborazione ha seguito un ciclo standard di individuazione-correzione-verifica. Apollo ha condiviso una serie di attacchi riusciti, insieme a raccomandazioni per rafforzare la modalità automatica. Abbiamo rafforzato il classificatore contro questi attacchi, principalmente fornendogli più contesto sull'ambiente che protegge: visibilità dei repository, stato git e regole di gestione dei dati descritte di seguito.

Dopo il rafforzamento, Apollo ha ripetuto i test su un set separato di attacchi riservato, a cui non abbiamo mai avuto accesso. La modalità automatica ha intercettato circa la metà degli attacchi che in precedenza non aveva rilevato, a fronte della mancata rilevazione di circa il 2% degli attacchi rilevati in precedenza. Dato che non abbiamo potuto eseguire la messa a punto sul set riservato, ciò suggerisce che il rafforzamento si generalizzi a nuovi attacchi anziché limitarsi a correggere quelli specifici condivisi da Apollo. Considerando sia il set condiviso sia quello riservato, il tasso di mancato rilevamento del classificatore è sceso dal 12% al 7%.

Si tratta di attacchi sintetici e avversariali per progettazione, concepiti per individuare i punti in cui il classificatore fallisce, e più dannosi di qualsiasi azione che Claude compirebbe di propria iniziativa. Il tasso di mancato rilevamento del 7% è misurato su questo set e non deve essere considerato il tasso di mancato rilevamento sul traffico reale.

La modalità automatica riduce il rischio di prompt injection

Il classificatore della modalità automatica aggiunge un ulteriore livello di difesa contro gli attacchi di prompt injection che cercano di costringere l'agente a discostarsi dalle istruzioni dell'utente. Con la modalità automatica attiva, i risultati degli strumenti vengono analizzati da sonde alla ricerca di istruzioni potenzialmente dannose e la modalità automatica verifica che le azioni siano allineate all'intento dell'utente. Abbiamo testato la modalità automatica rispetto a un modello non protetto per illustrare l'efficacia di questo approccio di difesa in profondità.

Abbiamo commissionato una valutazione a una terza parte, Trajectory Labs, che ha testato diversi modelli all'interno delle versioni più recenti di Claude Code e Codex disponibili pubblicamente al 17 luglio 2026.1 Sono stati testati 72 scenari di prompt injection indiretta non condivisi con Anthropic. Ogni scenario è stato testato 10 volte. Gli attacchi riusciti, in un ambiente non destinato ai test, comporterebbero azioni irreversibili che potrebbero danneggiare l'utente, come l'esfiltrazione di dati sensibili, frodi finanziarie o phishing delle credenziali. Gli attacchi sono stati ottimizzati contro Claude Opus 4.7, che non fa parte dell'insieme di modelli riportati, quindi ogni modello oggetto della valutazione li ha affrontati come attacchi mai visti prima. Oltre alla modalità automatica, le valutazioni hanno preso in considerazione la modalità bypassPermissions di Claude Code e la modalità Full Access di Codex.

Sia Codex che Claude Code sono stati valutati utilizzando un'integrazione browser identica prodotta da Trajectory Labs, PBC. Questa integrazione fornisce un insieme di strumenti MCP che fungono da wrapper leggero per le API di Chrome più comuni, come `navigate`. Le misure di sicurezza incluse nelle integrazioni browser proprietarie, come le estensioni per Chrome fornite da OpenAI e Anthropic, non sono state testate. Pertanto, questi risultati dovrebbero essere considerati una misurazione del modello sottostante, anziché dell'insieme completo di misure di sicurezza che potrebbero esistere in una determinata implementazione.

In questa valutazione, nessuno dei 720 tentativi di attacco ha avuto successo contro Claude Fable 5, Opus 5 o Sonnet 5 in esecuzione in modalità automatica. D'altro canto, il 5,83% degli attacchi ha avuto successo contro GPT-5.6 Sol utilizzando la modalità di revisione automatica di Codex. In particolare, si tratta di un valore superiore al tasso di successo medio degli attacchi dello 0,09% registrato contro i nostri modelli più recenti eseguiti in modalità bypassPermissions senza misure di sicurezza aggiuntive. I test hanno mostrato un tasso di successo degli attacchi del 19,03% contro GPT-5.6 Sol quando eseguito in modalità Full Access. I tassi di successo degli attacchi variano a seconda delle attività in cui gli strumenti restituiscono risultati sotto forma di testo e delle attività che richiedono un'interazione con un browser tramite screenshot, come illustrato di seguito.

Tre incidenti prevenuti dalla modalità automatica all'interno di Anthropic

La modalità automatica è inoltre quella predefinita per tutti gli usi interni di Claude Code in Anthropic. Ecco tre azioni che il classificatore ha impedito internamente:

• Una fuga di dati fuori dalla rete: quando un caricamento su un'unità interna non è riuscito, la soluzione di riserva di Claude è stata quella di pubblicare lo stesso report su un sito pubblico di condivisione di codice. La modalità automatica ha negato il fallback e ha chiesto all'utente come procedere.
• Un'operazione di massa distruttiva: in una sessione di lunga durata, Claude ha tentato di terminare in massa i processi su circa 2.000 pod e ha messo in coda eliminazioni che avrebbero interrotto job di addestramento in corso su centinaia di GPU. La modalità automatica ha segnalato i comandi distruttivi prima dell'esecuzione.
• Escalation dei privilegi eccessivamente ampia: quando ha ricevuto la richiesta di configurare un accesso in sola lettura alla fatturazione, Claude ha optato per un ruolo cloud che concede il pieno controllo amministrativo a livello root dell'account. La modalità automatica ha individuato la discrepanza tra ciò che veniva richiesto e i ruoli che sarebbero stati concessi.

In ciascun caso, Claude ha individuato un percorso più sicuro in autonomia oppure ha contattato l'utente prima di procedere.

Rendere la modalità automatica ancora più sicura

Investiamo costantemente in nuove funzionalità della modalità automatica che rendono più semplice e sicura la distribuzione del codice in produzione. Esempi recenti includono:

• Diniego rigido: l'esfiltrazione dei dati, come l'invio del codice o dei segreti verso destinazioni esterne, rientra in una categoria che il classificatore è progettato per non approvare mai. Per eseguire un'azione del genere, devi disattivare la modalità automatica o eseguire il comando manualmente. Le regole di diniego rigido sono personalizzabili tramite le impostazioni; è quindi possibile aggiungere ulteriori regole per impedire azioni che non si desidera consentire, anche qualora fossero richieste dagli utenti dell'organizzazione.
• Regole per l'accesso e la condivisione dei dati: il classificatore ora include regole esplicite che distinguono i segreti dalle informazioni potenzialmente sensibili/riservate, indicando dove è possibile accedere a ciascuna categoria e condividerla. Per rendere applicabili tali regole, verifica inoltre se la destinazione di un git push o di una pull request è pubblica, privata o attendibile prima che l'azione venga eseguita. Lo stesso push può essere un'operazione di routine o un'esfiltrazione a seconda della destinazione: il codice che appartiene al repository privato del tuo team non dovrebbe finire in uno pubblico, e il classificatore è ora progettato per segnalare quando ciò potrebbe accadere.
• Verifica dello stato git prima di azioni git distruttive: prima di un comando che potrebbe eliminare modifiche non sottoposte a commit, come git reset --hard, il classificatore esamina lo stato git attuale del repository, così la modalità automatica sa cosa viene reimpostato.
• Screening della prompt injection: quando Claude estrae contenuti da fonti esterne, come pagine web, contenuti di file o output di strumenti, un controllo lato API verifica che tali contenuti non contengano tentativi di dirottare il comportamento di Claude. Quando qualcosa sembra un tentativo di iniezione, viene aggiunto un avviso al contesto di Claude prima che il risultato venga condiviso con l'utente.

Modalità automatica in produzione

I team stanno già utilizzando la modalità automatica come impostazione di produzione predefinita:

• Il team della piattaforma di merchandising di Adobe ha la responsabilità di garantire che le pagine dei prezzi e delle promozioni siano accurate e aggiornate in oltre 90 Paesi e in oltre 30 lingue su Adobe.com. Il team ha realizzato un ciclo agentico per creare e verificare queste pagine, eseguendolo in modalità automatica affinché i team di sviluppo ricevano PR completate da revisionare.
• Nuro utilizza la modalità automatica in tutte le sue organizzazioni di ricerca e ingegneria, sfruttandola per alimentare agenti di ricerca notturni che eseguono algoritmi di hill-climbing sulle metriche di valutazione e restituiscono PR completate da revisionare entro la mattina.
• Gusto ha adottato la modalità automatica per porre fine alla stanchezza legata ai permessi che spingeva i team di sviluppo a bypassare completamente i controlli sulle autorizzazioni. Da metà maggio, circa il 10% delle sessioni include un rifiuto da parte del classificatore, a prova del fatto che il sistema svolge un lavoro concreto senza rallentare le attività legittime.
• Garner Health ha distribuito la modalità automatica come impostazione predefinita a tutti i 550 dipendenti tramite impostazioni gestite, standardizzando a livello aziendale un ciclo di vita dello sviluppo del software (SDLC) che non dipende più da elenchi di comandi consentiti curati manualmente.

Scopri come questi clienti utilizzano la modalità automatica in produzione.

Per iniziare

Per chi utilizza Pro, Max e Team: se non hai impostato una modalità di autorizzazione predefinita, riceverai una notifica nel prodotto e le nuove sessioni si avvieranno direttamente in modalità automatica. Se hai impostato un valore predefinito diverso, potrebbe comparire un prompt una tantum che ti chiede se desideri impostare la modalità automatica come predefinita. Se chi amministra il tuo Team ha impostato un valore predefinito nelle impostazioni gestite, per te non cambia nulla.

Per gli utenti Enterprise e gli utenti che accedono a Claude Code tramite Claude API, la modalità automatica rimane per il momento attivabile su richiesta. Abbiamo in programma di rendere la modalità automatica l'impostazione predefinita nel prossimo mese e, prima di farlo, informeremo i team di amministrazione Enterprise.

Per cambiare modalità, premi Maiusc+Tab nella CLI o utilizza il menu a discesa delle modalità nell'app desktop. Gli amministratori possono impostare un valore predefinito a livello di organizzazione con `defaultMode` nelle impostazioni gestite oppure disattivare completamente la modalità automatica con `disableAutoMode`.

Infine, sebbene riteniamo che la modalità automatica riduca il rischio per la maggior parte degli utenti, questa si basa su sistemi di classificazione e, di conseguenza, non elimina il rischio. Per modifiche di grande rilevanza all'infrastruttura di produzione, consigliamo comunque di esaminare personalmente le azioni compiute da Claude. Consulta la documentazione sulla modalità automatica per le istruzioni complete sulla configurazione.

‍

Questo articolo è stato scritto da Conner Phillippi con il contributo di Nicholas Carlini, Isaac Fung, John Hughes, Alex Isken, Shawn Moore, Javier Rando e Molly Vorwerck. Gli autori desiderano inoltre ringraziare Yacine Azmi, Chandler Bair, Kefan Chen, Boris Cherny, Ian Grunert, Lydia Hallie, Alex Kleiman, Lauren Polansky, Deon Poncini, Robert Schonberger, Marie Vachovsky, Qing Wang, Cat Wu, Daniel Xu e Alice Zhao.

‍

1 Abbiamo valutato Claude Code v2.1.205 e Codex v0.144.5. La settimana scorsa OpenAI ha rilasciato una nuova versione di Auto-review che potrebbe modificare i risultati.