Il 26 agosto 2026 Anthropic ha annunciato la disponibilità generale di Claude in Chrome per i piani a pagamento e l’arrivo di un browser integrato in Claude Cowork. Questi strumenti possono leggere pagine, spostarsi tra le schede, inserire testo e compilare moduli con un’autonomia maggiore. Rendono accessibili portali interni o legacy privi di API, ma spostano anche il confine della sicurezza: il contenuto di una pagina diventa un’istruzione potenzialmente ostile collocata accanto a una sessione autenticata.
Da ricordare: un agente browser non deve mai ereditare implicitamente tutti i diritti del proprio utente. Occorre isolare il suo ambiente, limitare domini e account, classificare le azioni in base al rischio, richiedere una conferma per gli effetti sensibili, registrare le decisioni e verificare il risultato. Le protezioni del modello riducono il rischio di prompt injection, ma non lo eliminano.
1. Il browser diventa un ambiente di esecuzione
Le prime generazioni di assistenti si limitavano a rispondere alle domande. Ora un agente browser può osservare lo stato di una pagina, decidere una sequenza di passaggi e agire in un’applicazione. È quindi paragonabile a un utente automatizzato dotato di capacità di ragionamento.
Questa evoluzione è utile per i sistemi che non offrono né API né connettori: un extranet di fornitori, un’interfaccia di amministrazione storica, un CRM verticale o una dashboard interna. L’agente può raccogliere dati, preparare un inserimento, attraversare più schermate e restituire il risultato nella stessa conversazione.
Ma un’automazione classica segue uno scenario scritto in anticipo. L’agente sceglie il proprio percorso in base al contenuto visualizzato. La sua flessibilità costituisce anche la sua superficie di attacco: un’informazione incontrata durante il percorso può modificarne il piano.
Bisogna quindi trattare il browser come un runtime sensibile, con politiche di accesso, ambiente isolato, tracce, limiti delle risorse e meccanismi di arresto. Aggiungere un’estensione a un browser di lavoro senza rivedere questi elementi equivale a distribuire un nuovo robot software con i diritti di un dipendente, ma senza una governance adeguata.
2. Distinguere il browser personale dal browser isolato
I due annunci di Anthropic illustrano due modelli diversi.
Un’estensione come Claude in Chrome opera nel contesto del browser già in uso. Sfrutta le sessioni aperte e può intervenire sulla pagina visibile. Questa vicinanza facilita le attività quotidiane, ma aumenta l’impatto potenziale di un errore: l’agente può incontrare posta elettronica, CRM e area di amministrazione nella stessa sessione.
Il browser integrato in Cowork è separato dal browser personale. Secondo Anthropic, per impostazione predefinita non accede alle schede, ai preferiti o alle password dell’utente. Le connessioni possono essere importate sito per sito e alcune categorie sensibili, come banca, posta elettronica o SSO, sono escluse salvo scelta esplicita.
Per un’azienda, l’isolamento dovrebbe essere la modalità predefinita. Create un profilo dedicato, senza sincronizzazione del browser, con un vault dei segreti separato e account di servizio limitati. Il browser personale può restare utile per un’assistenza occasionale sotto supervisione, ma non deve diventare la base di un’automazione ricorrente.
La scelta dipende dall’esigenza: assistere una persona nella pagina che sta visualizzando oppure delegare un’attività a un ambiente controllato. Confondere questi due utilizzi espone inutilmente le sessioni.
3. Perché la prompt injection cambia la minaccia
In un’iniezione classica, un attaccante tenta di far eseguire un comando a un’applicazione. In una prompt injection inserisce istruzioni in una pagina, un’e-mail, un documento o un campo per influenzare il modello che le legge.
Il contenuto malevolo può essere visibile, discreto o integrato in un dato legittimo. L’utente può chiedere, per esempio, di sintetizzare le richieste dei clienti; uno dei messaggi contiene un’istruzione che chiede all’agente di aprire un’altra schermata e trasmettere informazioni. Per il modello, la richiesta dell’utente e il testo della pagina appartengono allo stesso contesto di lavoro, a meno che l’architettura non imponga una separazione netta.
Anthropic descrive sonde che analizzano il contenuto e un classificatore che verifica le azioni previste rispetto alla richiesta iniziale. L’azienda precisa inoltre che queste misure non possono eliminare il rischio e raccomanda di iniziare da siti affidabili.
Questa riserva deve guidare il design. Nessun punteggio di resistenza fornito da un vendor copre le vostre applicazioni, formulazioni, integrazioni e autorizzazioni. La prompt injection è un problema di sistema: modello, strumenti, sessioni, dati, policy e controllo umano devono essere progettati insieme.
4. Applicare il principio del privilegio minimo alle sessioni web
La prima protezione consiste nel ridurre i diritti accessibili all’agente.
Utilizzate un account distinto quando l’applicazione lo consente. Rimuovete i ruoli di amministrazione, le esportazioni globali, la gestione degli utenti e le funzioni finanziarie se l’attività non ne ha bisogno. Preferite un perimetro di dati limitato al team o alla pratica trattata.
Definite poi un elenco di domini autorizzati. Un’attività sul CRM non dovrebbe poter aprire un servizio arbitrario di condivisione file. Controllate reindirizzamenti, sottodomini e download, perché una pagina approvata può contenere un collegamento a un’origine non approvata.
Limitate anche i flussi di rete del browser isolato. L’accesso in uscita può passare da un proxy che registra le destinazioni e blocca le categorie vietate. I download devono essere analizzati e conservati in un’area temporanea senza esecuzione automatica.
I segreti non devono essere copiati nel prompt o in un file di configurazione leggibile dal modello. Utilizzate un meccanismo di autenticazione gestito dal browser o un vault che fornisca una sessione senza rivelare il valore in chiaro. Se il profilo viene compromesso, deve essere possibile una rotazione rapida.
Questo approccio estende i principi del nostro articolo sugli agenti IA zero-trust, la firma delle scritture e l’isolamento del codice generato: ogni capacità deve essere concessa esplicitamente e verificabile.
5. Controllare le azioni, non solo le risposte
Un agente può formulare una risposta corretta e al tempo stesso aver eseguito un’azione indesiderata. La policy deve quindi applicarsi al momento dell’azione.
Classificate le operazioni in quattro livelli. La lettura di pagine pubbliche può essere automatica. La preparazione di un modulo o di una bozza può essere autorizzata senza invio. Una modifica reversibile, come l’aggiunta di una nota interna, richiede la verifica del contenuto e del destinatario. Un’azione esterna o difficile da annullare—inviare un’e-mail, modificare un diritto, eliminare, ordinare, pagare o pubblicare—richiede una conferma esplicita e recente.
La conferma deve presentare elementi concreti: dominio, account, oggetto modificato, valore attuale, nuovo valore e conseguenze. Una domanda generica come «continuare?» non aiuta l’utente a rilevare una deviazione.
Dopo la convalida, l’agente deve eseguire esclusivamente l’azione approvata. Non deve approfittare della conferma per aggiungere altri passaggi. Gli strumenti possono imporre schemi rigidi, elenchi di campi autorizzati e limiti di volume.
Per i processi sensibili, separate preparazione ed esecuzione. L’agente prepara la transazione; un servizio deterministico o una persona verifica le regole di business ed esegue la scrittura.
6. Registrare, verificare e prevedere il ripristino
La tracciabilità non deve limitarsi a un video della sessione. Registrate l’identità del richiedente, l’attività iniziale, il modello e la sua versione, i domini visitati, gli strumenti chiamati, le decisioni della policy, le conferme, gli oggetti modificati e il risultato osservato.
Evitate tuttavia di registrare segreti o dati personali non necessari. Screenshot e contenuti delle pagine devono rispettare un periodo di conservazione, un controllo degli accessi e una finalità definita.
Dopo ogni scrittura, l’agente deve rileggere lo stato ottenuto. Un clic su un pulsante non dimostra che una modifica sia stata salvata. Verificate il messaggio di conferma, il valore persistito o un ID di transazione. Per un lotto, confrontate il numero di elementi attesi con quelli elaborati.
Preparate un meccanismo di annullamento: una bozza invece della pubblicazione diretta, il cestino invece della cancellazione definitiva, una transazione idempotente, la conservazione della versione precedente o un registro che permetta di riprodurre l’operazione inversa. Alcune operazioni, come un’e-mail inviata o un pagamento, non sono realmente reversibili; devono essere collocate dietro il livello di controllo più rigoroso.
7. Testare l’agente come un sistema non deterministico
I normali test funzionali non bastano. Un agente può scegliere percorsi diversi per la stessa richiesta e reagire a formulazioni inattese.
Costruite un set di valutazione con attività normali, ambiguità, errori di autenticazione, reindirizzamenti, pagine lente e contenuti che tentano di orientare l’agente. Verificate che si fermi quando manca un’informazione, che chieda conferma al momento giusto e che non allarghi il proprio perimetro.
Aggiungete casi di prompt injection adattati alle vostre applicazioni, senza esporre dati reali: istruzioni nella descrizione di un ticket, nel nome di un file, in un campo CRM, in un’e-mail o in una pagina di documentazione. Misurate il tasso di blocco, ma anche i falsi positivi che impediscono il lavoro legittimo.
Testate ogni nuova versione del modello e ogni modifica della policy. Un miglioramento generale del modello può cambiare la sua interpretazione delle istruzioni, la propensione a chiedere conferma o il modo in cui usa uno strumento.
Infine, realizzate una fase di osservazione in sola lettura. Confrontate le decisioni proposte dall’agente con le azioni di un operatore prima di autorizzare le scritture.
8. Distribuire per classi di utilizzo
Iniziate da attività a basso impatto: raccolta di informazioni pubbliche, verifica di uno stato, preparazione di un rapporto o inserimento di una bozza in un ambiente di test.
La seconda fase può coprire portali interni con un account limitato e azioni reversibili. Mantenete la validazione umana e misurate il tempo effettivamente risparmiato, compresi revisione e correzione.
Gli utilizzi che coinvolgono posta elettronica, dati sensibili, modifiche dei diritti, ordini o finanza devono restare in un perimetro separato. Richiedete un’analisi dei rischi, un responsabile business, un responsabile tecnico, log utilizzabili e un piano per gli incidenti.
Definite anche le esclusioni: domini non autorizzati, categorie di dati, fasce orarie, volumi e azioni che l’agente non eseguirà mai. Un elenco chiaro protegge meglio di un prompt generale che chieda di «fare attenzione».
Il passaggio alla scala deve dipendere da prove: tasso di attività completate, errori confermati, interventi umani, incidenti di policy, costi e soddisfazione degli utenti. L’autonomia è un livello di servizio da conquistare, non un’opzione da attivare globalmente.
Conclusione
Gli agenti browser rendono automatizzabili applicazioni che le integrazioni tradizionali lasciavano da parte. La loro capacità di utilizzare sessioni esistenti e interpretare pagine dinamiche offre un valore reale, ma avvicina anche dati non affidabili ad azioni autenticate.
La sicurezza deve essere costruita attorno al modello: browser isolato, diritti minimi, domini autorizzati, policy delle azioni, conferme informative, verifica del risultato e registrazione. Partitech accompagna la progettazione di queste architetture agentiche, la definizione delle protezioni e l’implementazione di progetti pilota misurabili prima di qualsiasi generalizzazione.