Quando leggere una pagina significa anche poter agire

Un assistente che riassume un articolo deve soltanto interpretarne il contenuto. Un agente browser può fare di più: leggere pagine, spostarsi tra siti e, in base alle autorizzazioni, fare clic o digitare all’interno di una sessione in cui la persona ha già effettuato l’accesso. Questa differenza amplia ciò che può fare per conto dell’utente, ma aumenta anche le conseguenze di un errore. Google osserva che gli agenti possono operare in sessioni autenticate e che un’azione indesiderata potrebbe includere una transazione o l’esposizione di dati sensibili. https://developer.chrome.com/docs/agents/security https://blog.google/security/architecting-security-for-agentic/

Perciò la questione non è soltanto se il modello risponda bene a una richiesta, ma quali contenuti vede, quali azioni è autorizzato a eseguire e chi controlla che ogni passaggio corrisponda all’obiettivo della persona. Il confine tra leggere e agire è fondamentale: riassumere una recensione ha un impatto diverso dall’inviare un messaggio, accedere a un account o completare un pagamento. La documentazione di Chrome presenta le sue misure come difese a più livelli, non come una proprietà magica del modello che renda innocuo qualsiasi testo sul Web. https://blog.google/security/architecting-security-for-agentic/

Una pagina può contenere istruzioni rivolte all’agente

L’iniezione indiretta di istruzioni si verifica quando un comando diretto al modello compare nei dati che consulta, anziché arrivare come istruzione diretta della persona. Può trovarsi in una pagina manipolata, in contenuti di terze parti incorporati o nei contributi degli utenti, come commenti e recensioni. Google descrive due rischi specifici per gli strumenti Web: definizioni degli strumenti con istruzioni nascoste e risposte apparentemente normali che incorporano testo ostile. https://developer.chrome.com/docs/agents/security https://blog.google/security/architecting-security-for-agentic/

Il problema è che il modello elabora testi provenienti da fonti diverse mentre cerca di seguire un compito. Se scambia il contenuto di una pagina per un comando legittimo, può allontanarsi dall’obiettivo iniziale. Il sito non deve avere autorità sull’agente: basta che il testo ne influenzi la pianificazione. Google avverte esplicitamente che la natura probabilistica dei modelli impedisce di garantire la sicurezza all’interno del solo modello. Di conseguenza, anche un’istruzione nascosta o mescolata a informazioni utili va trattata come contenuto non attendibile, non come un’autorizzazione dell’utente. https://developer.chrome.com/docs/agents/security

La ricerca mostra quanto sia estesa questa superficie di attacco, anche se i risultati non vanno applicati automaticamente a tutti i browser. Uno studio pubblicato come preprint su arXiv nel maggio 2025 ha esaminato in modalità white-box un progetto open source di navigazione e ha segnalato iniezione di istruzioni, aggiramento della convalida dei domini ed esposizione di credenziali. Si tratta dell’analisi di un progetto e di una configurazione specifici: dimostra che i problemi sono possibili, ma non costituisce una misurazione universale degli agenti attuali né una prova relativa a Chrome. https://arxiv.org/abs/2505.13076

Livelli di protezione che riducono le possibilità di abuso

La guida di Chrome per gli agenti che usano WebMCP raccomanda diverse barriere deterministiche: limitare il volume degli input, restringere le origini Web con cui l’agente può interagire e chiedere conferma prima di agire. Consiglia anche di trattare le risposte degli strumenti come dati non attendibili. L’obiettivo è ridurre sia la quantità di materiale ostile che entra nel contesto sia le possibilità che un’istruzione manipolatoria provochi danni. Sono raccomandazioni di progettazione rivolte a chi crea agenti, non una garanzia che ogni estensione o browser le applichi automaticamente. https://developer.chrome.com/docs/agents/security

Un’altra tecnica descritta è lo spotlighting: contrassegnare o trasformare i contenuti non attendibili affinché il modello li interpreti come dati e non come ordini. Chrome avverte che le opzioni comportano compromessi. Delimitare il testo costa poco, ma può non funzionare se i delimitatori vengono manipolati; codificarlo in Base64 rende più difficili alcuni trucchi strutturali, ma aumenta il consumo di contesto. In entrambi i casi, il sistema deve spiegare al modello come trattare quei contenuti. Sono misure complementari, non un filtro infallibile in grado di riconoscere ogni intento malevolo. https://developer.chrome.com/docs/agents/security

Google descrive anche un’architettura per le capacità agentiche di Chrome: un modello pianificatore propone azioni e un componente separato, chiamato User Alignment Critic, verifica che siano coerenti con l’obiettivo dell’utente. L’azienda afferma che questo critico riceve metadati sulle azioni, non contenuti Web non filtrati, e può respingere le proposte. Inoltre, gli insiemi di origini intendono limitare i siti che l’agente può leggere e quelli su cui può agire. Il post indica che la prima implementazione di questa limitazione era più semplice e che il progetto avrebbe continuato a essere perfezionato. https://blog.google/security/architecting-security-for-agentic/

Conferme e limiti dichiarati

La conferma umana può fare da freno quando un’azione può avere conseguenze. Google afferma che il suo agente di Chrome chiede il permesso prima di accedere ad alcuni siti sensibili, prima di effettuare l’accesso tramite Google Password Manager e prima di azioni come acquisti, pagamenti o invio di messaggi. Cita inoltre un registro dei passaggi e la possibilità di mettere in pausa o interrompere il compito. Sono funzionalità descritte dal fornitore; ciò non significa che siano tutte disponibili in ogni regione, versione o prodotto, né che la persona debba approvare ogni dettaglio allo stesso modo. https://blog.google/security/architecting-security-for-agentic/

La documentazione riconosce anche dei limiti: i classificatori potrebbero non rilevare tutti i contenuti progettati per influenzare l’agente e le difese richiedono test e miglioramenti continui. Google spiega di utilizzare esercitazioni automatizzate di red team per generare siti di prova e verificare se le protezioni fermano gli attacchi. Questa valutazione aiuta a individuare regressioni, ma un tasso di successo misurato su un insieme di test non dimostra l’assenza di vulnerabilità future né copre tutte le pagine, le lingue, i flussi di lavoro e le combinazioni di strumenti. La conclusione prudente è che i livelli di protezione aumentano il costo di un attacco e possono limitarne l’impatto, non che lo rendano impossibile. https://blog.google/security/architecting-security-for-agentic/

Che cosa può fare chi usa l’agente

Prima di delegare un’attività, è opportuno controllare quali autorizzazioni richiede il browser o l’estensione e limitare l’accesso ai siti davvero necessari. Se una funzione può inviare dati, modificare un account o effettuare un acquisto, è ragionevole mantenere la supervisione e verificare destinatario, campi e risultato prima di confermare. La guida di Chrome consiglia di restringere le origini e richiedere conferma per le azioni; non si tratta di trasferire tutta la responsabilità alla persona, ma di mantenere un punto di controllo sugli effetti difficili da annullare. https://developer.chrome.com/docs/agents/security

È utile anche distinguere le attività a basso impatto — per esempio organizzare informazioni pubbliche — dalle operazioni che coinvolgono credenziali, dati medici, informazioni finanziarie o messaggi privati. Se l’agente trova un’istruzione inattesa in una pagina, non si dovrebbe presumere che faccia parte della richiesta originale. È preferibile fermarsi e verificare quale azione viene proposta. La supervisione riduce l’esposizione, ma non sostituisce i controlli tecnici: le indicazioni ufficiali insistono sulle restrizioni delle origini, sulle valutazioni periodiche e sulle conferme, mentre la ricerca disponibile mostra che possono verificarsi guasti in diversi componenti del sistema. Non ci sono basi per promettere una protezione assoluta. https://developer.chrome.com/docs/agents/security https://arxiv.org/abs/2505.13076