Skip to content
webvise
· 9 min di lettura

Perche Non Consegniamo Agenti AI che Leggono il Web Aperto

Il 5 aprile 2026, Google DeepMind ha pubblicato il piu grande studio empirico sulla manipolazione degli agenti AI mai condotto. 502 partecipanti, 8 paesi, 23 tipi di attacco, ogni difesa attualmente disponibile valutata insufficiente. Questa e la posizione ingegneristica che Webvise ha adottato la mattina seguente.

Argomenti
AI AgentsAISecurityB2B
Condividi

Il 5 aprile 2026, Google DeepMind ha pubblicato il piu grande studio empirico sulla manipolazione degli agenti AI mai condotto: 502 partecipanti reali in 8 paesi, 23 tipologie di attacco distinte, modelli frontier tra cui GPT-4o, Claude e Gemini. La singola frase che abbiamo estratto e fissato nel nostro canale ingegneristico la mattina successiva e l'unica che conta per chiunque stia rilasciando un chatbot aziendale nel 2026: se il vostro agente AI legge testo controllato da un aggressore e poi esegue qualsiasi azione con i privilegi dell'utente, avete già incorporato una vulnerabilità di esfiltrazione dei dati. Questo e il motivo per cui Webvise non costruira, per nessun cliente a nessun prezzo, un agente AI che naviga il web aperto.

Cosa Ha Misurato Davvero DeepMind

La maggior parte della copertura stampa dello studio ha riportato il numero headline, 23 tipi di attacco, e si e fermata li. I numeri sottostanti sono quelli che contano per chiunque gestisca una funzione AI in produzione:

  • 502 partecipanti in condizioni reali, non simulazioni di laboratorio

  • 8 paesi, quindi gli attacchi non erano ottimizzati per un unico contesto culturale o linguistico

  • 23 tipi di attacco in 10 categorie, tra cui prompt injection diretta, injection indiretta tramite contenuti web, pixel injection multimodale, document injection, manipolazione dell'ambiente, jailbreak embedding, memory poisoning, goal hijacking, exfiltration e cross-agent injection

  • Tutte e quattro le classi di difesa (sanificazione degli input, guardie a livello di prompt, sandboxing, supervisione umana) valutate insufficienti alla scala

La categoria a cui torniamo sempre e l'ottava, *goal hijacking tramite deriva graduale delle istruzioni nel corso delle interazioni.* Ogni demo di un sistema agente che abbiate mai visto sopravvive a un singolo prompt avversariale. Nessuna sopravvive a cento distribuiti con cura.

L'Insight a Cascata che la Maggior Parte dei Media Ha Mancato

Sepolto nello studio c'e il risultato che stabilisce se i prodotti multi-agente siano sicuri da rilasciare. In qualsiasi pipeline in cui l'agente A recupera contenuti, l'agente B li elabora e l'agente C esegue un'azione, una singola injection nel feed di dati dell'agente A si propaga attraverso ogni agente a valle. L'agente B si fida dell'output di A. L'agente C si fida dell'output di B. L'aggressore non aveva bisogno di compromettere il modello. Gli bastava compromettere i dati che il modello consumava, una sola volta.

Il nostro fondatore gestisce una configurazione multi-agente personale con Hermes, un agente NousResearch su Telegram che gestisce 14 cron jobs tra news quotidiane, riepiloghi di linee guida mediche e logistica personale. Ognuno di quei 14 job legge da una fonte esplicitamente approvata e curata a mano. Nessuno segue link. Nessuno esegue istruzioni esterne. Dopo la pubblicazione del paper di DeepMind ogni cron è stato verificato e la regola ha retto. Ha retto perché è stata scritta due anni fa e non è mai stata allentata. La maggior parte degli stack agente in produzione che vediamo nei brief dei clienti non ha questa regola, e gli ingegneri che li costruiscono non sono mai stati invitati a metterla per iscritto.

Come Appare 'Leggere il Web Aperto' in un Brief Cliente

Ogni mese vediamo tre varianti della stessa richiesta:

  • 'Fai rispondere al chatbot alle domande navigando il sito del mio concorrente.' In pratica, ciò concederebbe a un aggressore che controlla un post del blog della concorrenza un canale scrivibile nella sessione del cliente.

  • 'Permetti agli utenti di incollare qualsiasi URL e fai riassumere all'agente il contenuto.' In pratica, ciò consentirebbe a qualsiasi utente di incollare un URL il cui HTML contiene istruzioni nascoste che esfiltrano messaggi della conversazione.

  • 'Aggiungi RAG sulla documentazione di un fornitore esterno che non ospitiamo.' In pratica, ciò concederebbe i permessi di tool-calling dell'agente a chiunque modifichi quella documentazione.

Ognuna collega direttamente un canale di testo controllato da un aggressore a un sistema che ha dati utente, chiamate a strumenti e accesso alla rete in uscita dallo stesso lato del confine di fiducia. Nessuna di queste richieste e malintenzionata da parte del cliente. Ognuna e un'idea di prodotto difendibile. Sono tutte, pero, dopo il 5 aprile 2026, impossibili da rilasciare.

Ogni Difesa Attualmente Disponibile Fallisce

DeepMind ha testato tutte e quattro le famiglie di difesa ovvie. Ecco la loro valutazione, con il nostro commento su ciascuna:

DifesaVerdetto DeepMindPerche fallisce in pratica
Sanificazione degli inputInsufficienteNon e possibile sanificare pixel di immagini, metadati di documenti o note del relatore all'interno di un PDF al momento dell'inferenza. La superficie di attacco e il testo e ogni altra modalita che l'agente acquisisce.
Guardie a livello di promptInsufficienteIl contenuto iniettato e progettato per sembrare una parte legittima della pagina. Nel momento in cui il modello lo vede, la guardia lo ha gia ritenuto affidabile.
SandboxingRiduce il raggio d'azione, non previene l'injectionIl sandboxing aiuta se il risultato dell'attacco e contenuto. Non aiuta quando l'obiettivo dell'attacco e leggere i dati dell'utente e riscriverli tramite una chiamata API dall'aspetto legittimo.
Supervisione umanaInsufficiente alla scalaUn operatore che gestisce un agente su 50 fonti non puo revisionare ogni pagina alla ricerca di istruzioni nascoste. L'intero punto dell'agente era che l'essere umano uscisse dal ciclo.

Se si prende la tabella sul serio, non esiste un modo responsabile per rilasciare un agente che legge testo controllato da un aggressore e al tempo stesso esegue azioni con privilegi utente. L'unica mossa disponibile e rimuovere una di quelle due proprieta.

Cosa Consegniamo Invece

Webvise ha rilasciato funzionalita AI in produzione per i clienti, inclusa la landing page di costruzioni MP Bau, che instrada le chiamate al modello attraverso il Vercel AI Gateway per il routing dei provider e l'osservabilita. Le cinque regole seguenti sono cio che ha reso quella build difendibile, e sono ora precondizioni rigide per qualsiasi lavoro AI che accettiamo:

  • Solo agenti a input chiuso. L'agente legge da un insieme finito di fonti curate a mano che controlliamo. Nessun web aperto. Nessun URL incollato dagli utenti. Nessun RAG esterno su documentazione non controllata.

  • Sola lettura per default. Se l'agente deve leggere qualcosa di cui non ci fidiamo completamente, non puo anche chiamare strumenti, inviare email, scrivere su un database o generare richieste di rete in uscita nella stessa sessione. Si ottiene l'uno o l'altro, mai entrambi contemporaneamente.

  • Isolamento cross-agent. Quando l'output dell'agente A fluisce nell'agente B, B tratta l'output di A come input utente, non come istruzioni di sistema. E una riga di codice nel prompt ed e l'intera difesa contro l'attacco a cascata.

  • Budget di capacita per agente. Ogni agente ha un elenco fisso di strumenti e un limite di token. Il limite e sufficientemente piccolo da non consentire a un'injection riuscita di estrarre piu di un breve messaggio.

  • Isolamento del provider tramite gateway. Instradamo ogni chiamata al modello attraverso il Vercel AI Gateway cosi da poter cambiare provider, registrare ogni prompt e completamento, e revocare una chiave in pochi secondi. Se qualcosa sembra anomalo nei log, possiamo fermare il problema nello stesso minuto in cui lo notiamo.

Non sono pratiche esotiche. Costano qualche ora di lavoro di progettazione, prima che venga scritto qualsiasi codice. Il motivo per cui la maggior parte dei prodotti agente nel 2026 non le ha e che nessuno nel team e stato pagato per tracciare il confine di fiducia.

Perché Decliniamo Certe Funzionalità

Il paper di DeepMind consente a qualsiasi team con esperienza ingegneristica precedente al boom degli agenti di rifiutare specifiche richieste di funzionalità con una chiara giustificazione tecnica; i clienti in genere lo apprezzano a posteriori. I fornitori che costruiscono agenti senza questi vincoli si assumono un rischio di esfiltrazione significativo, sempre più visibile nei report sugli incidenti.

Il mercato sta assistendo a un rapido dispiegamento di chatbot privi di difese contro il prompt injection, simile alla recente proliferazione di contenuti di bassa qualità generati da LLM. Il vantaggio competitivo andrà ai team in grado di dimostrare, in anticipo, che il proprio prodotto non fa parte di questa tendenza.

Dove Tracciamo il Confine

La versione piu breve della regola, quella che ora scriviamo in ogni documento di avvio progetto, e questa: un agente puo leggere contenuti non attendibili, oppure agire con i privilegi dell'utente, ma non nella stessa sessione. Tutto il resto deriva da questo. Se una richiesta di funzionalita attraversa il confine, non viene costruita. Se puo essere riformulata per restare su un lato, la riformuliamo insieme al cliente e consegniamo la versione riformulata. Il paper di DeepMind non ha inventato questa disciplina. Ha solo tolto ogni scusa per non averla.

Da webvise costruiamo funzionalita AI per aziende in cui il costo di un singolo messaggio cliente trapelato e superiore al costo di dire no a una richiesta di funzionalita. Se questo descrive il vostro progetto, contattateci e tracceremo insieme il confine di fiducia prima che venga scritto qualsiasi codice.

Le pratiche di webvise sono allineate agli standard ISO 27001 e ISO 42001.