Gli agenti browser di Amazon e Google affrontano un problema di prompt injection senza una soluzione perfetta

Gli agenti browser di Amazon e Google affrontano ora lo stesso conflitto: una maggiore autonomia offre agli attacchi di prompt injection più spazio per causare danni. Nonostante le nuove misure di protezione, i ricercatori continuano a trovare modi per indirizzare gli agenti attraverso normali pagine web, email, moduli e post sui social. Questa debolezza sta diventando un vincolo duraturo nella progettazione dei browser AI, non l'ennesimo bug del browser in attesa di una singola correzione risolutiva.

La preoccupazione immediata riguarda la prompt injection indiretta, in cui istruzioni ostili si nascondono nei contenuti letti da un agente AI. Tali istruzioni possono entrare in conflitto con la richiesta dell'utente e influenzare l'azione successiva dell'agente. Un browser tradizionale visualizza il contenuto ostile. Un browser agentico può interpretarlo, passare a un altro servizio e agire con l'autorità dell'utente.

Questa distinzione colloca Amazon e Google in una più ampia competizione sulla sicurezza che coinvolge Microsoft, OpenAI, Anthropic, Perplexity e fornitori specializzati di browser. Ogni azienda vuole agenti in grado di completare attività utili sul web. Eppure, ogni autorizzazione aggiuntiva amplia le conseguenze di un agente che fraintende a chi debba obbedire.

La conclusione inquietante non è che gli agenti browser siano inutilizzabili. È che i fornitori non possono considerare il rilevamento delle prompt injection come un confine di sicurezza completo. Le imprese devono presumere che alcune istruzioni dannose riusciranno a passare e limitare ciò a cui un agente compromesso può accedere, che può modificare o divulgare.

Cosa è cambiato nella corsa alla sicurezza dei browser tra Amazon e Google

La prompt injection è passata dall'essere una debolezza teorica dei modelli a un problema operativo di sicurezza dei browser.

I ricercatori di sicurezza hanno dimostrato ripetutamente che contenuti malevoli possono reindirizzare un agente senza sfruttare il tradizionale percorso di esecuzione del codice del browser. L'attaccante prende invece di mira l'interpretazione dei contenuti da parte del modello. Un'istruzione nascosta può comparire in una pagina web, un'email, un documento o persino in un elemento dell'interfaccia utente.

L'attacco diventa grave quando l'agente può utilizzare sessioni browser autenticate. Potrebbe leggere una casella di posta, aprire un'altra scheda, inviare un modulo o recuperare informazioni da un servizio connesso. Azioni che sembrano comode durante un'attività normale diventano componenti utili di una catena d'attacco.

I ricercatori di Zenity hanno descritto questa più ampia classe di debolezze dei browser agentici con il nome PleaseFix. I loro test hanno preso di mira il modo in cui gli agenti seguono obiettivi espressi in linguaggio naturale mentre si muovono tra siti web e risorse locali. Secondo le ricerche sulla sicurezza dei browser, i ricercatori hanno riscontrato progettazioni e misure di protezione diverse, ma hanno comunque identificato percorsi d'attacco nei browser agentici commerciali.

Il cambiamento importante riguarda il percorso dell'attaccante. Gli attacchi tradizionali ai browser dipendono spesso da una vulnerabilità software, un'estensione dannosa, una credenziale rubata o un clic ingannevole. La prompt injection può iniziare con contenuti che l'agente era tenuto a elaborare durante una richiesta ordinaria.

Un utente potrebbe chiedere a un assistente di riassumere una pagina prodotto. La pagina potrebbe contenere istruzioni nascoste visivamente ma ancora disponibili al modello. Un attaccante potrebbe anche inserire istruzioni in un post pubblico, in un modulo per newsletter o in contenuti recuperati tramite uno strumento browser.

Questo non garantisce che ogni istruzione iniettata abbia successo. Modelli, classificatori, sistemi di autorizzazione e controlli sulle azioni possono fermare molti tentativi. Il problema è che questi controlli operano contro un avversario adattivo, in grado di rivedere formulazione, presentazione, tempistica e contesto.

Le stesse misurazioni di Google rafforzano questo cambiamento. I suoi team di sicurezza hanno analizzato contenuti web pubblici alla ricerca di schemi noti di prompt injection indiretta e hanno segnalato un aumento relativo del 32 per cento nelle rilevazioni dannose tra novembre 2025 e febbraio 2026. L'azienda ha inoltre trovato una quantità significativa di testo benigno simile agli attacchi, complicando una classificazione affidabile.

Questa ricerca sulle minacce web è rilevante perché una difesa del browser deve gestire due errori contrapposti. Se non intercetta contenuti ostili, un agente può essere manipolato. Se blocca in modo troppo aggressivo, pagine di routine e istruzioni legittime diventano inutilizzabili.

Amazon affronta il problema attraverso la sua piattaforma cloud per agenti anziché tramite un browser destinato al mercato di massa. Bedrock AgentCore Browser offre agli sviluppatori un ambiente isolato per agenti che navigano nei siti, completano moduli ed estraggono informazioni. Queste capacità espongono comunque gli agenti a contenuti non attendibili, anche quando la sessione browser sottostante è isolata.

Il confronto tra Amazon e Google riflette quindi due diversi modelli di distribuzione. Google aggiunge funzionalità agentiche a un browser utilizzato direttamente dalle persone. Amazon fornisce infrastruttura che le aziende usano per creare la propria automazione browser. Entrambe devono gestire lo stesso scontro tra contenuti del web aperto e azioni privilegiate degli agenti.

Perché gli agenti browser indeboliscono un vecchio confine di sicurezza

La debolezza centrale emerge quando un modello riceve istruzioni affidabili e dati non attendibili attraverso un processo di ragionamento condiviso.

I browser web hanno trascorso decenni a separare i siti web tra loro. La same-origin policy generalmente impedisce a un'origine di leggere liberamente informazioni sensibili da un'altra. Sandbox, richieste di autorizzazione, isolamento dei processi e content security policy aggiungono ulteriori barriere.

Un agente AI può oltrepassare questi confini perché l'utente lo autorizza a svolgere un'attività. Può leggere una pagina, consultare un altro servizio e combinare i risultati. Questa capacità è il vantaggio centrale del prodotto, ma crea anche un ponte che contenuti ostili possono tentare di controllare.

Il modello non deve violare direttamente la same-origin policy. Può utilizzare funzioni browser legittime disponibili all'utente. Se una pagina dannosa convince l'agente ad aprire una casella di posta, leggere un messaggio e trasmettere informazioni, ogni singolo passaggio potrebbe apparire autorizzato.

Questo viene talvolta chiamato problema del deputy confuso. Un componente affidabile dispone di un'autorità legittima, ma un attaccante lo manipola inducendolo a usare tale autorità per lo scopo sbagliato. Gli agenti browser rendono il deputy conversazionale, probabilistico e capace di pianificare più passaggi.

La ricerca sugli agenti browser open source ha dimostrato come questo schema possa portare all'esposizione di credenziali e ad azioni non autorizzate. Uno studio accademico ha segnalato prompt injection, aggiramento della convalida del dominio ed esfiltrazione di credenziali in un framework di automazione browser. La sua analisi degli agenti browser includeva anche una vulnerabilità divulgata e una proof of concept funzionante.

Il problema cresce quando un agente conserva memoria tra attività diverse. Un'istruzione ostile non deve sempre causare danni immediati. Può tentare di alterare il contesto memorizzato, creare una preferenza fuorviante o influenzare una decisione successiva quando diventano disponibili risorse sensibili.

La comprensione visiva introduce un'altra via. Un agente che interpreta screenshot può incontrare istruzioni incorporate in immagini o elementi dell'interfaccia. Filtrare soltanto il testo grezzo della pagina non intercetterà ogni messaggio che un modello multimodale può percepire.

Gli attaccanti possono anche evitare frasi ovvie come “ignora le istruzioni precedenti”. Possono presentare passaggi dannosi come parti necessarie dell'obiettivo originale dell'utente. Una richiesta di iscrizione a una newsletter, per esempio, può diventare un pretesto per recuperare dati o aprire un altro strumento.

Questa tecnica è importante perché molte difese cercano un conflitto tra l'obiettivo dell'utente e l'istruzione ostile. Un attaccante può invece far apparire l'azione dannosa coerente con quell'obiettivo. La formulazione diventa meno sospetta, mentre la capacità richiesta rimane pericolosa.

La prompt injection differisce dalla SQL injection sotto un aspetto critico. Il software può separare i comandi SQL dai dati attraverso una sintassi rigorosa e query parametrizzate. Gli agenti basati sul linguaggio naturale dipendono dall'interpretazione contestuale, quindi istruzioni e informazioni non hanno sempre un confine tecnico netto.

Messaggi strutturati ed etichette di provenienza possono migliorare tale separazione. Gli sviluppatori possono indicare quali contenuti provengono dall'utente, da una pagina web, da uno strumento o dall'applicazione. Tuttavia, il modello deve comunque interpretare contenuti esterni quando l'attività dipende dal loro significato.

La ricerca pubblicata come BrowseSafe ha valutato i rischi di prompt injection negli agenti browser ed esaminato le difese in ambienti realistici. Questo lavoro riflette un consenso emergente: il rilevamento aiuta, ma l'architettura del browser e la progettazione delle autorizzazioni determinano l'impatto finale.

Ecco perché un classificatore perfetto non risolverebbe l'intera questione. Anche i classificatori elaborano linguaggio ambiguo, e gli attaccanti possono testare nuove varianti. I difensori hanno bisogno di diversi controlli indipendenti, affinché un singolo errore di valutazione non sblocchi l'intera sessione browser dell'utente.

Le difese di Amazon e Google privilegiano il controllo rispetto al rilevamento perfetto

Amazon e Google stanno realizzando difese stratificate perché nessuna delle due aziende può fare affidamento su un singolo filtro contro la prompt injection.

Google ha descritto un'architettura che verifica le azioni degli agenti prima che raggiungano il browser. Il suo User Alignment Critic è un componente separato progettato per valutare se un'azione proposta corrisponda all'obiettivo dichiarato dall'utente. La separazione aiuta a evitare che l'agente principale approvi la propria interpretazione rischiosa.

Google utilizza inoltre informazioni sull'origine, conferme delle azioni, addestramento dei modelli e sistemi di rilevamento. Le operazioni sensibili possono richiedere l'approvazione esplicita dell'utente. Il browser può limitare quali informazioni raggiungono l'agente e preservare i confini di sicurezza attorno alle credenziali.

Nel suo progetto per Chrome agentico, Google riconosce che l'esposizione a contenuti web non attendibili crea un rischio intrinseco di prompt injection indiretta. Questa formulazione è significativa. L'azienda presenta il problema come una minaccia architetturale che richiede una mitigazione continua.

La conferma delle azioni è utile perché ripristina il giudizio umano prima di un passaggio con conseguenze rilevanti. Un utente può rifiutare un acquisto, messaggio, accesso o trasferimento di dati inatteso. Tuttavia, richieste frequenti possono anche diventare di routine, generando la stessa stanchezza osservata con gli avvisi sui cookie e le finestre di dialogo delle autorizzazioni.

Le conferme devono quindi concentrarsi sulle transizioni significative. L'invio di dati a un nuovo dominio merita un controllo maggiore rispetto allo scorrimento di una pagina. Aprire un gestore di password comporta un rischio maggiore rispetto all'estrazione di un titolo pubblico. Un modello di approvazione uniforme tratta azioni diseguali come se fossero equivalenti.

Amazon enfatizza l'applicazione di policy attorno al proprio ambiente browser gestito. Gli sviluppatori che utilizzano Bedrock AgentCore possono applicare policy aziendali di Chrome che limitano i siti in cui un agente può navigare. Queste regole operano a livello del browser, indipendentemente dal prompt o dal ragionamento dell'agente.

La distinzione è importante. Un modello può essere manipolato, ma una policy deterministica di rete o del browser blocca comunque una destinazione vietata. I controlli delle policy del browser di Amazon consentono ai responsabili della creazione di definire località consentite e bloccate prima che l'agente inizi il proprio lavoro.

Una allowlist può ridurre drasticamente l'esposizione per flussi di lavoro aziendali circoscritti. Un agente per gli acquisti potrebbe necessitare dell'accesso a un ristretto insieme di portali di fornitori approvati. Un agente del servizio clienti potrebbe richiedere soltanto la piattaforma di assistenza e un sistema di conoscenza interno.

Questi confini diventano più difficili da mantenere nella ricerca generalista. Un agente incaricato di confrontare prodotti o monitorare le notizie necessita di un ampio accesso al web. Più il compito è aperto, meno utile diventa una rigida allowlist di destinazioni.

L'isolamento fornisce un ulteriore livello di protezione. Una sessione browser gestita può separare l'attività dell'agente dal profilo browser quotidiano del dipendente. Se l'agente viene compromesso, non dovrebbe ereditare automaticamente ogni cookie, scheda aperta, credenziale salvata ed estensione a disposizione dell'utente.

L'isolamento non stabilisce se un'istruzione sia dannosa. Limita le risorse disponibili dopo una decisione errata. È la stessa logica pratica alla base di container, macchine virtuali e account di servizio con autorizzazioni ristrette.

Il principio del privilegio minimo estende questo approccio a strumenti e dati. Un agente che deve soltanto leggere pagine pubbliche non dovrebbe ricevere l'autorizzazione a inviare email. Un agente che prepara una transazione non dovrebbe poterla approvare. Un agente che legge documenti non dovrebbe ottenere automaticamente l'accesso a ogni cartella connessa.

I percorsi difensivi di Amazon e Google convergono quindi su un principio condiviso. I modelli continueranno a essere fallibili, perciò la sicurezza deve esistere al di fuori del modello. Policy del browser, confini di identità, controlli di approvazione, logging e sessioni isolate possono contenere un errore che il rilevamento non è riuscito a fermare.

Il vero compromesso è tra capacità e contenimento

Ogni difesa che riduce in modo affidabile l'impatto della prompt injection limita anche una parte dell'autonomia dell'agente.

Un agente browser diventa più utile quando può muoversi liberamente tra i servizi, ricordare il contesto e completare attività in più passaggi. Queste stesse capacità aumentano il numero di decisioni che un attaccante può influenzare. Il compromesso sulla sicurezza è intrinseco alla proposta di valore del prodotto.

Consideriamo un agente incaricato di organizzare un viaggio. Potrebbe cercare voli, confrontare hotel, controllare un calendario, recuperare informazioni sui programmi fedeltà e preparare una prenotazione. Se contenuti esterni reindirizzano il piano, l'agente potrebbe esporre dettagli personali o selezionare una destinazione controllata da un attaccante.

Un sistema fortemente contenuto potrebbe prevenire questo esito limitando l'agente alla ricerca in sola lettura. Tuttavia, non completerebbe più la prenotazione. Aggiungere l'autorità di acquisto ripristina la comodità, aumentando però l'impatto di un'azione errata.

Lo stesso schema si applica nelle aziende. Un agente di vendita potrebbe fare ricerche su un account e preparare messaggi di contatto con rischi limitati. Dargli il permesso di inviare messaggi, aggiornare i record dei clienti e allegare documenti interni crea un'automazione più preziosa e un raggio d'azione del guasto più ampio.

Per questo la prompt injection dovrebbe essere valutata come un problema di sicurezza delle capacità. I team dovrebbero chiedersi cosa possa fare l'agente dopo aver accettato un'istruzione dannosa. Il tasso di successo degli attacchi contro un modello conta, ma conta di più la conseguenza consentita.

Un riassuntore in sola lettura presenta un rischio diverso da un agente collegato ai sistemi di pagamento. Entrambi possono produrre output fuorvianti. Solo uno può trasformare una cattiva interpretazione in una transazione esterna senza un ulteriore controllo.

I fornitori talvolta promuovono tassi di rilevamento più elevati come prova di maggiore sicurezza. Questi risultati possono essere preziosi, ma dipendono dal set di test, dalla conoscenza dell'attaccante, dalla versione del modello e dagli strumenti consentiti. Un attacco adattivo può prendere di mira casi che un benchmark non includeva.

Anche i falsi positivi generano costi operativi. Un modello difensivo potrebbe rifiutare contenuti legittimi che somigliano a un tentativo di injection. I team di sicurezza possono ridurre le mancate rilevazioni aumentando la sensibilità, ma gli utenti incontrano così più attività bloccate e conferme non necessarie.

Il problema di progettazione non ha un punto di arrivo fisso, perché le capacità degli agenti continuano a evolversi. Una protezione testata contro la sintesi di pagine non copre automaticamente la navigazione visiva, il download di file, le finestre di dialogo del sistema operativo o le interazioni con un nuovo protocollo di strumenti.

Gli aggiornamenti del browser possono introdurre comportamenti aggiuntivi. Gli aggiornamenti del modello possono cambiare il modo in cui l'agente interpreta istruzioni ambigue. Un servizio connesso può esporre nuove azioni senza che il fornitore del browser controlli la sua interfaccia. I test di sicurezza devono seguire il sistema completo, non una singola istantanea del modello.

Estensioni e integrazioni di terze parti complicano ulteriormente il quadro. Possono ampliare i contenuti visibili all'agente o fornire nuovi percorsi di esecuzione. Un'azienda potrebbe configurare con cura il browser principale, trascurando però un'estensione con ampio accesso alle pagine.

È quindi necessaria una visione scettica. Le difese stratificate riducono il rischio, ma le dichiarazioni pubbliche sugli “agenti sicuri” non dovrebbero essere interpretate come immunità. Le aziende dovrebbero divulgare l'ambiente testato, le azioni bloccate, le regole di conferma dell'utente e la superficie d'attacco residua.

Allo stesso tempo, dichiarare ogni browser AI categoricamente non sicuro semplifica eccessivamente la decisione. Il rischio dipende dalle autorizzazioni dell'agente, dai dati accessibili, dall'isolamento e dall'attività. Un assistente di ricerca vincolato può adattarsi a un ambiente a minor rischio anche quando un agente di acquisto non può farlo.

I team di sicurezza necessitano di classi di distribuzione anziché di un'unica approvazione generica. Gli agenti a basso rischio possono operare in sessioni isolate e in sola lettura. I sistemi a rischio medio possono preparare azioni per la revisione umana. I flussi di lavoro ad alto rischio dovrebbero richiedere un'autorizzazione deterministica esterna al modello.

Questa struttura accetta il compromesso fondamentale anziché fingere che sia scomparso. Gli utenti ottengono comunque automazione, ma l'autonomia aumenta solo quando i controlli circostanti possono assorbire un fallimento del modello.

Chi subisce la pressione del problema della prompt injection

I fornitori di browser affrontano i titoli dei giornali, ma i team aziendali responsabili di identità e applicazioni sostengono gran parte dell'onere pratico.

Google deve proteggere gli utenti i cui profili browser contengono già sessioni di valore. Chrome può collegare un agente a email, calendari, documenti, account di acquisto e strumenti di lavoro. Una singola interfaccia può quindi esporre molti domini di fiducia diversi.

I clienti di Amazon affrontano una responsabilità differente. Bedrock AgentCore fornisce componenti e controlli gestiti, ma gli sviluppatori decidono comunque a quali destinazioni, identità, strumenti e dati un agente possa accedere. Un servizio sicuro può supportare una configurazione applicativa non sicura.

Microsoft, OpenAI, Anthropic e Perplexity affrontano la stessa pressione competitiva. Gli utenti si aspettano che gli agenti browser gestiscano più lavoro, mentre i ricercatori di sicurezza mettono alla prova ogni nuova capacità. Un progetto restrittivo può apparire meno utile accanto a un concorrente che consente un'automazione più ampia.

Questo ciclo competitivo può incoraggiare i fornitori ad ampliare le autorizzazioni più rapidamente di quanto le aziende aggiornino la governance. Nuove funzionalità degli agenti possono arrivare tramite browser e strumenti di produttività familiari, evitando la revisione degli acquisti richiesta per un'applicazione separata.

I team di sicurezza dovrebbero censire le funzionalità agentiche come capacità, non come nomi di prodotti. Le domande rilevanti riguardano l'accesso a sessioni autenticate, file locali, applicazioni connesse, memoria, messaggistica, download ed esecuzione di codice.

Anche i responsabili delle applicazioni devono riconsiderare i contenuti delle pagine web. Una dashboard interna era un tempo progettata principalmente per lettori umani. Se gli agenti ne consumano il testo sia come informazione sia come potenziale istruzione, la provenienza dei contenuti diventa parte della sicurezza applicativa.

I team responsabili delle identità devono decidere se gli agenti condividano credenziali umane o ricevano identità di servizio distinte. Le sessioni condivise sono comode, ma indeboliscono l'accountability. Identità separate favoriscono autorizzazioni più rigorose, log più chiari e una revoca più rapida.

Gli sviluppatori necessitano di registri degli eventi che spieghino cosa abbia visto l'agente e perché abbia agito. La cronologia convenzionale del browser mostra le pagine visitate, ma potrebbe non acquisire il contenuto esatto, la decisione del modello, la chiamata allo strumento e l'autorizzazione alla base dell'azione di un agente.

I responsabili della risposta agli incidenti affrontano un'altra difficoltà. Una prompt injection riuscita può sembrare normale attività dell'utente perché l'agente utilizza credenziali valide e funzioni browser legittime. Il rilevamento deve esaminare intenzione, sequenza, destinazione e movimento dei dati.

Anche i dipendenti necessitano di segnali più chiari. Dovrebbero sapere quando un agente legge una pagina, passa a un altro servizio, accede a informazioni private o prepara un'azione irreversibile. Una piccola icona animata non comunica l'intera transizione di fiducia.

Gli acquirenti aziendali dovrebbero chiedere ai fornitori come funzionino le difese quando i contenuti sono visivi, offuscati, multilingue o distribuiti su più passaggi. Dovrebbero inoltre chiedere se i controlli di sicurezza vengano eseguiti indipendentemente dall'agente principale e se le policy restino applicabili dopo modifiche al modello.

La valutazione più solida include test avversariali rispetto ai flussi di lavoro effettivi dell'organizzazione. Un benchmark generico non può riprodurre ogni applicazione interna, fonte di dati e combinazione di autorizzazioni. I red team dovrebbero testare obiettivi realistici variando al contempo i contenuti dannosi.

Anche i contratti di approvvigionamento necessitano di termini chiari sugli incidenti. Gli acquirenti dovrebbero comprendere la conservazione dei log, la divulgazione delle vulnerabilità, le pratiche di aggiornamento dei modelli e la responsabilità per configurazioni non sicure. La prompt injection attraversa i confini tra il comportamento del fornitore e la progettazione del cliente.

Nessuna azienda può risolvere questo problema di responsabilità condivisa con il solo aggiornamento di un modello. I fornitori devono fornire controlli applicabili, mentre i clienti devono configurarli attorno ad attività specifiche. Entrambe le parti necessitano di prove che i controlli funzionino insieme.

Cosa osservare in seguito da Amazon, Google e dai fornitori di browser AI

La fase successiva sarà giudicata dalle prove di contenimento, non dalle promesse che la prompt injection sia stata eliminata.

Il primo segnale è se i fornitori pubblicheranno valutazioni riproducibili che coprano flussi di lavoro browser completi. I test dovrebbero includere testo nascosto nelle pagine, immagini, azioni tra schede, memoria memorizzata, account connessi e manipolazione dell'intento in più passaggi. Un singolo benchmark di rifiuto offre una visione troppo limitata.

I risultati dovrebbero separare il rilevamento dall'impatto. Un attacco che influenza un riepilogo è diverso da uno che invia dati o completa un acquisto. Gli acquirenti devono sapere sia quanto spesso un agente segue contenuti ostili sia quali controlli fermano l'azione risultante.

Il secondo segnale è un uso più ampio di restrizioni deterministiche. Le policy browser di Amazon offrono un esempio perché possono bloccare le destinazioni indipendentemente dal ragionamento del modello. I controlli sulle azioni e i gate delle autorizzazioni di Google svolgono un ruolo correlato nell'allineamento con l'utente.

Occorre osservare se questi controlli diventeranno più facili da configurare a un livello granulare. Le aziende necessitano di policy basate su destinazione, sensibilità dei dati, tipo di azione, identità e attività. Un singolo interruttore browser globale acceso-spento non può rappresentare tali differenze.

Il terzo segnale è il modo in cui i fornitori gestiscono le catene di attacco appena divulgate. Le patch rapide restano importanti, anche quando la classe di vulnerabilità persiste. Le note di rilascio dovrebbero spiegare se una correzione modifica il rilevamento, l'ambito delle autorizzazioni, l'isolamento o l'architettura dell'agente sottostante.

I ricercatori continueranno a trovare varianti perché il comportamento degli agenti è non deterministico. Una patch che blocca una frase o uno schema di pagina web non affronta la collisione di intenti in contesti diversi. Miglioramenti duraturi dovrebbero rimuovere capacità dai percorsi non attendibili o aggiungere un'autorizzazione indipendente.

Il segnalato aumento di pattern web dannosi da parte di Google rende questo lavoro urgente. La sofisticazione degli attacchi era ancora limitata nella scansione dell'azienda, ma l'aumento dell'attività offre agli attaccanti maggiori opportunità di testare prodotti distribuiti. Una più ampia adozione degli agenti browser rende le tecniche riuscite più preziose.

La concorrenza tra Amazon e Google rivelerà anche quali compromessi di sicurezza gli utenti accettano. Google può inserire conferme direttamente in Chrome, dove gli utenti le vedono. Amazon può offrire agli sviluppatori policy infrastrutturali, ma ogni cliente deve decidere quanto tali policy debbano essere restrittive.

Per le distribuzioni aziendali, lo standard a breve termine dovrebbe essere semplice. Isolare l'agente, assegnargli un'identità distinta, limitare le destinazioni, ridurre al minimo gli strumenti e richiedere approvazione prima delle azioni rilevanti. Registrare ogni transizione tra contenuti non attendibili e comportamento privilegiato.

I lavoratori della conoscenza dovrebbero, quando possibile, mantenere gli account sensibili al di fuori delle sessioni sperimentali degli agenti. Dovrebbero inoltre controllare messaggi, transazioni, download e trasferimenti di dati proposti. Aggiornare il browser è importante, ma non può eliminare il problema interpretativo alla radice.

Gli sviluppatori dovrebbero trattare ogni pagina web, email, documento caricato e nota recuperata come input non attendibile. Dovrebbero presumere che il modello principale finirà per classificare erroneamente parte di questi contenuti. I controlli esterni al modello devono stabilire cosa accade dopo.

La conclusione che non esista una soluzione perfetta è scomoda perché cambia la domanda relativa al deployment. I team dovrebbero smettere di chiedersi se un agente browser sia immune alla prompt injection. Dovrebbero chiedersi se una singola iniezione riuscita possa raggiungere qualcosa che conta.

Prima di abilitare la prossima funzionalità autonoma, mappatene l'azione peggiore consentita e decidete se il beneficio giustifica tale esposizione. Se la risposta non è chiara, mantenete l'agente in sola lettura o richiedete l'approvazione umana. La corsa tra Amazon e Google produrrà difese migliori, ma un'adozione responsabile dipende comunque dal contenimento.