Google ha recentemente spiegato come intende rendere sicure le nuove capacità agentic di Chrome, ovvero quelle che permetteranno al browser di “agire per conto tuo”: prenotare biglietti, fare acquisti, compilare moduli.
Il cuore del sistema è un modello critico: il cosiddetto User Alignment Critic, basato su Gemini, che verifica ogni azione proposta dal planner: se la critica ritiene che l’azione non serva allo scopo dichiarato dall’utente la blocca — e tutto ciò basandosi su metadati delle azioni, non sui contenuti completi della pagina.

In parallelo viene estesa l’idea della “same-origin policy” (isolamento delle origini) al contesto agentic: con gli Agent Origin Sets si definisce per ogni task un insieme di origini “read-only” da cui leggere dati, e “read‑writable” su cui l’agente può cliccare o scrivere. Contenuti irrilevanti o potenzialmente pericolosi (ads, iframe non correlati, widget esterni) vengono esclusi.

Inoltre prima di azioni “sensibili” come pagamenti, invio messaggi o login su siti critici (bancari, sanitari, etc.), l’agente si ferma e richiede un’esplicita conferma da parte dell’utente. Anche i dati delle password non sono visibili al modello.

Ci sono infine sistemi secondari: un modello che osserva la navigazione per evitare che l’agente generi URL malevoli, un classificatore di “prompt injection indiretta” che tenta di intercettare contenuti malevoli nascosti in pagine web — insomma un’architettura a più livelli per limitare i vettori di attacco.

Perché Google non può (ancora) dormire sonni tranquilli

La strategia ha senso e dimostra maturità: guardare a un’AI agentic e contemporaneamente chiedere “ma come la rendiamo sicura?” — è un buon segnale. Però il “di per sé” non basta, perché la superficie di attacco cambia radicalmente.

Per cominciare c’è il problema noto come “indirect prompt injection”: pagine apparentemente innocue (o IFrame, contenuti generati da utenti, annunci) possono nascondere comandi che LLM come Gemini “leggono” e interpretano come istruzioni da eseguire. In scenari reali questi attacchi possono spingere l’agente a effettuare transazioni non autorizzate o esfiltrare dati sensibili.

Questo rischio è stato formalizzato da recenti ricerche accademiche. Uno studio — In-Browser LLM-Guided Fuzzing for Real-Time Prompt Injection Testing in Agentic AI Browsers — mostra che i browser con agenti LLM sono vulnerabili a vulnerabilità scoperte in tempo reale tramite fuzzing guidato, evidenziando quanto sia concreta la minaccia.

Un’altra ricerca — A Whole New World: Creating a Parallel-Poisoned Web Only AI-Agents Can See — descrive un attacco molto più subdolo: “cloaking” di pagine, cioè contenuto diverso servito all’agente rispetto a quello umano. Una pagina per l’utente sembra innocua, per l’agente nasconde istruzioni malevole. Questo mina alle fondamenta l’intera logica di “sicurezza dal browser”.

Infine le debolezze di fondo dell’“agentic AI” (o “autonomous web agents”) restano: mancanza di spiegabilità, possibilità di bias, errori accumulabili, rischi legali e di responsabilità, difficoltà a gestire fallimenti o casi limite. Tutti lati oscuri evidenziati nella letteratura sull’Agentic AI.

Difese di Chrome: robuste… ma solo per ora

La struttura a strati proposta da Google — modello planner + critic + gating origin + prompt‑injection classifier + conferme sensibili — è una strategia di “defence in depth” ragionevole. Se implementata correttamente può ridurre significativamente la “attack surface”.

La scelta di far sì che il critic lavori solo su metadati (non contenuti completi), e quella di isolare le origini, indicano che Google ha studiato attentamente i problemi di sicurezza. La “gating” delle origini è un’estensione naturale al mondo agentic della Site‑Isolation e della same-origin policy, cardini della sicurezza browser da anni.

Il blocco di azioni sensibili fino a una conferma manuale è forse la parte più efficace nella pratica: evita che l’agente, anche se “compromesso”, possa comprare, trasferire dati o effettuare login senza il tuo consenso.

Ma si tratta di un compromesso: l’agente è solo “semi-autonomo”: utile per automatizzare compiti semplici e ripetitivi, ma ogni azione con implicazioni reali rimane sotto il controllo umano.

Perché la cautela rimane obbligatoria

Anche con le misure di sicurezza promesse, non c’è garanzia che tutto fili liscio. Le ricerche accademiche documentano che gli attacchi di tipo “prompt injection” o “cloaking per agenti” sono reali, replicabili, e già usate come proof‑of‑concept.

Chi volesse abusare di un agentic browser può contare su un’arma potente: l’automazione, la fiducia implicita dell’agente, la complessità tecnica nascosta. E basta un solo iframe malevolo, un widget pubblicitario, un contenuto generato da utente o nascosto, per far deragliare tutto.

Inoltre il modello critico (critic) e le gating origin — per quanto intelligenti — non sono silver bullet. Qualsiasi errore di design nell’identificare le origini, qualsiasi bug nella logica di gating o nel classifier di prompt‑injection, può spalancare la porta.

E infine resta una questione di fiducia e trasparenza: l’utente non vede “il dietro le quinte” di Gemini, e spesso non saprà né come né perché un’azione è stata approvata o bloccata.

Il verdetto di chi guarda da fuori

Un gruppo di ricercatori e analisti vede l’arrivo dell’agentic browsing come una delle più grandi sfide di cyber‑security del prossimo decennio. Il crescente interesse della comunità accademica attorno a “fuzzing per agentic AI” e strumenti di analisi delle vulnerabilità prova che la paura è concreta — non teoria da white‑paper.

A livello pratico: se usassi oggi un browser con agentic AI attivo, probabilmente lo tratterei come un turbo‑bot: comodo per attività ripetitive, utile per risparmiarmi tempo ma con la consapevolezza che non è un sostituto del mio controllo. Ogni acquisto sensibile, login, inserimento dati, resterebbe sotto la mia supervisione.

Per te, che vieni dal mondo della trasformazione digitale e hai un occhio clinico su rischi e innovazione, la lezione è semplice: guardare all’agentic come a uno “strumento potenziale”, non come a una panacea. Il rischio non è che “funzioni piano piano”, è che “funzioni male, piano piano, in modo invisibile”.

Blog Google: https://security.googleblog.com/2025/12/architecting-security-for-agentic.html?utm_source=chatgpt.com