I framework per agenti AI trasformano la prompt injection in una falla di sicurezza

Google News ha fatto emergere questa settimana un argomento di sicurezza netto: la prompt injection non è il difetto alla radice, nonostante anni di difese costruite attorno a essa. Il problema più profondo risiede nei framework per agenti AI che trasformano output incerti dei modelli in azioni privilegiate.

Questa distinzione cambia ciò che i team di ingegneria devono proteggere. Un chatbot manipolato può produrre assurdità. Un agente manipolato può leggere file privati, chiamare API, modificare codice, inviare messaggi o contaminare la memoria condivisa.

L'impostazione di The Register mette in discussione un'assunzione diffusa. Gli sviluppatori spesso trattano il testo maligno come la vulnerabilità e prompt più robusti come il rimedio. La domanda più importante è che cosa il sistema circostante consenta dopo che il modello ha accettato quel testo.

Questo non significa che la prompt injection sia innocua. Rimane un metodo affidabile per influenzare i modelli tramite richieste dirette o contenuti esterni non attendibili. Tuttavia, l'injection diventa una violazione operativa solo quando l'architettura fornisce autorità, dati e un percorso eseguibile.

Il confronto emergente è quindi chiaro. Da una parte ci si affida ai modelli affinché riconoscano istruzioni pericolose in un linguaggio ambiguo. Dall'altra si presume che il riconoscimento prima o poi fallirà e si limita ciò che qualunque modello compromesso può realizzare.

Google News mette il framework per agenti al centro

Il cambiamento importante è uno spostamento di responsabilità dal comportamento del modello all'architettura del sistema.

La prompt injection è stata generalmente descritta come un problema di sicurezza dei modelli. Un attaccante inserisce istruzioni in un prompt, documento, sito web, email, immagine o risposta di uno strumento. Il modello segue quindi tali istruzioni anziché la richiesta effettiva dell'utente.

Questa descrizione è accurata ma incompleta. Identifica il metodo usato per influenzare il modello senza individuare il fallimento dei controlli che produce danni concreti. Un testo non attendibile non può cancellare autonomamente un file, recuperare un record cliente o pubblicare codice sorgente.

Un framework per agenti fornisce queste capacità. Collega un modello a strumenti, credenziali, memoria, database, browser, interpreti di codice e altri agenti. Può anche decidere se il modello può agire senza una nuova autorizzazione umana.

L'architettura può trasformare una singola interpretazione errata in una sequenza di effetti collaterali. Una pagina web avvelenata diventa una richiesta a uno strumento. La richiesta diventa una query al database. Il materiale recuperato appare quindi in un messaggio in uscita generato dallo stesso agente.

La prompt injection indiretta è particolarmente importante in questo contesto. L'attaccante non ha bisogno di accedere all'interfaccia di chat. Le istruzioni malevole possono attendere all'interno di contenuti che l'agente incontra durante un incarico ordinario.

Un agente di ricerca potrebbe incontrare le istruzioni su una pagina web. Un assistente di programmazione potrebbe trovarle nella descrizione di un issue o in un file del repository. Un agente per l'ufficio potrebbe acquisirle da un'email, un invito in calendario o un documento condiviso.

In ogni caso, il modello affronta un difficile problema di classificazione. Deve distinguere il testo che descrive un'istruzione da quello che deve essere eseguito. Entrambi arrivano come token in linguaggio naturale nel contesto di lavoro del modello.

La definizione del rischio OWASP riconosce sia l'injection diretta sia quella indiretta. Osserva inoltre che l'impatto dipende fortemente dal contesto aziendale e dall'autonomia concessa al modello.

Quest'ultima condizione conta più di quanto possa sembrare a prima vista. La stessa frase malevola può produrre esiti radicalmente diversi in due implementazioni. Un sintetizzatore in sola lettura potrebbe generare un paragrafo corrotto, mentre un agente privilegiato potrebbe esporre informazioni riservate.

Google News è utile come canale di scoperta per questo dibattito, ma non è la fonte autorevole di base. Il titolo rimanda a un corpo più ampio di lavoro sulla sicurezza che considera sempre più il dirottamento degli agenti una minaccia architetturale.

NIST descrive il dirottamento degli agenti come una prompt injection indiretta che induce un agente a compiere azioni dannose non intenzionali. Le sue valutazioni sul dirottamento utilizzano ambienti di lavoro simulati, servizi di viaggio, sistemi di messaggistica e strumenti bancari.

Questi ambienti mostrano perché la sicurezza degli agenti differisce dalla sicurezza dei chatbot. Il modello non si limita a rispondere a una domanda. Seleziona azioni all'interno di un flusso di lavoro che comporta permessi e conseguenze reali.

Questa riformulazione rende anche più precisa la segnalazione delle vulnerabilità. “Prompt injection” descrive come l'influenza è entrata nel sistema. Una scoperta di sicurezza utile dovrebbe identificare anche l'impatto risultante, come l'accesso non autorizzato ai dati o l'esecuzione di codice non approvata.

I team di sicurezza tradizionali fanno già distinzioni simili. L'input controllato dall'utente non costituisce automaticamente una violazione. La vulnerabilità emerge quando il software passa quell'input a un interprete non sicuro o gli attribuisce fiducia oltre un confine di sicurezza.

I modelli linguistici complicano l'analogia perché istruzioni e dati condividono una rappresentazione flessibile. Non esiste un equivalente universale di una query al database parametrizzata per ogni attività in linguaggio naturale. Questo rende il contenimento attorno al modello ancora più importante.

L'evento chiave è quindi concettuale, ma ha rilevanza operativa. Il lavoro sulla sicurezza si sta allontanando dalle promesse di un filtraggio perfetto delle istruzioni. Si sta orientando verso limiti che restano efficaci dopo che il modello prende la decisione sbagliata.

La prompt injection è l'innesco, non il raggio d'impatto

Un'istruzione iniettata crea influenza, mentre il framework determina se tale influenza diventa un incidente.

Consideriamo un agente incaricato di esaminare i ticket di assistenza in arrivo. Ha bisogno di accedere al testo dei ticket, ai dettagli dei clienti e forse a una knowledge base interna. Potrebbe anche disporre di strumenti per emettere rimborsi o inviare messaggi relativi agli account.

Un attaccante inserisce un'istruzione nascosta in un ticket. L'istruzione dice all'agente di recuperare il record di un altro cliente e includerlo in una risposta. Il modello segue tale indicazione credendo di completare il flusso di lavoro assegnato.

Prima che i dati escano dall'azienda, devono verificarsi diversi fallimenti. L'agente deve ricevere un accesso più ampio di quanto richieda il ticket corrente. Il suo livello di strumenti deve accettare parametri generati dal modello. L'azione in uscita deve procedere senza autorizzazione indipendente.

Il testo malevolo ha avviato la catena. Non ha creato i permessi eccessivi, i confini dei dati mancanti o l'assenza di un passaggio di approvazione. Tali decisioni provenivano dall'applicazione e dal framework.

Questa distinzione è centrale per la sicurezza degli agenti AI. Un sistema dovrebbe presumere che il giudizio del modello sia fallibile, soprattutto quando elabora contenuti controllati da un attaccante. I controlli di sicurezza devono restare al di fuori di quel ciclo decisionale.

I soli schemi degli strumenti non risolvono il problema. Uno schema può richiedere un indirizzo email o un identificatore di documento validi. Non può stabilire se il modello abbia un motivo legittimo per contattare quell'indirizzo o recuperare quel documento.

Un'azione malevola ben formata rimane malevola. Il framework necessita di un'applicazione delle policy legata all'identità dell'utente, alla proprietà dei dati, all'ambito dell'attività, alla provenienza e allo stato di autorizzazione corrente.

Per provenienza si intende registrare da dove provengono le informazioni e mantenere tale etichetta durante l'intero flusso di lavoro. I contenuti provenienti da una pagina web sconosciuta non dovrebbero acquisire uno stato attendibile perché un agente li ha riassunti.

Questa regola diventa più difficile nei sistemi multi-agente. Un modello potrebbe ricercare un argomento, un altro pianificare una risposta e un terzo eseguire strumenti. Le istruzioni malevole possono trasformarsi mentre gli output passano tra loro.

L'agente ricevente potrebbe vedere una prosa rifinita senza vedere la fonte non attendibile che l'ha influenzata. Se il framework scarta la provenienza, riciclare l'istruzione attraverso un altro agente può aumentarne di fatto l'autorità.

La memoria persistente crea un altro percorso. Un attaccante può persuadere un agente a memorizzare una regola dannosa, un fatto falso o una preferenza alterata. Le sessioni successive possono recuperare quella voce dopo che il contenuto malevolo originale è scomparso.

I team che costruiscono una knowledge base personale affrontano una questione di fiducia correlata. Le informazioni recuperate dovrebbero conservare la propria fonte e il contesto di accesso, specialmente quando un agente può agire su di esse.

La memoria non dovrebbe diventare un piano di controllo invisibile. Le operazioni di scrittura richiedono vincoli, record di audit e una chiara separazione tra preferenze approvate dall'utente e osservazioni generate dal modello.

La navigazione aggiunge un proprio rischio. Una pagina può contenere istruzioni visibili, testo nascosto, metadati, contenuti d'immagine o materiale avversario progettato per un modello anziché per una persona. L'agente elabora quel contenuto perché la navigazione è la sua funzione prevista.

Google ha riferito di monitorare il web pubblico alla ricerca di pattern noti di injection indiretta. La sua ricerca sulle minacce web ha trattato tali pattern come una priorità, poiché gli agenti di navigazione consumano abitualmente pagine controllate da attaccanti.

Questo crea un compromesso strutturale. Più ampio diventa l'accesso alle informazioni di un agente, più contenuti non attendibili incontrerà. Maggiore è l'autorità che riceve, maggiore è il potenziale impatto di una singola interpretazione errata.

Eliminare tutti i contenuti esterni renderebbe inutili molti agenti. Conferire a tutti i contenuti esterni uguale influenza li renderebbe insicuri. I framework devono preservare l'utilità imponendo al contempo confini che il solo linguaggio non può garantire.

Ciò significa separare la pianificazione dall'autorizzazione. Un modello può proporre un'azione, spiegarne il motivo e preparare i parametri. Un servizio di policy deterministico dovrebbe decidere se l'azione è consentita.

La decisione dovrebbe tenere conto dell'utente corrente, dell'attività richiesta, della risorsa di destinazione, della sensibilità dei dati e della provenienza dei contenuti. Le azioni ad alto impatto dovrebbero richiedere una conferma che mostri chiaramente ciò che accadrà.

La conferma non deve essere scritta interamente dal modello potenzialmente compromesso. Altrimenti, un attaccante può influenzare sia l'azione proposta sia la descrizione mostrata all'utente.

Un'interfaccia affidabile dovrebbe costruire i dettagli critici a partire da parametri degli strumenti convalidati. Dovrebbe identificare la destinazione, i record interessati, i permessi richiesti e tutti i dati programmati per uscire dal sistema.

È così che il raggio d'impatto diventa misurabile. Anche se la prompt injection riesce a livello linguistico, l'attaccante incontra controlli separati a ogni confine rilevante.

Il risultato assomiglia più alla sicurezza applicativa matura che a un'ingegnosa progettazione dei prompt. Privilegio minimo, isolamento, autorizzazione esplicita, convalida dell'output, registrazione e risposta agli incidenti restano essenziali.

Perché prompt di sistema più robusti non possono sostenere il confine di sicurezza

L'irrobustimento dei prompt riduce gli attacchi riusciti, ma i fallimenti residui lo rendono inadatto come livello finale di autorizzazione.

I prompt di sistema possono dire a un agente di ignorare le istruzioni presenti nei contenuti esterni. Possono etichettare il materiale di origine come non attendibile e ricordare al modello di seguire soltanto l'obiettivo dell'utente.

Queste misure meritano di essere adottate. Possono bloccare attacchi semplici, ridurre deviazioni accidentali e costringere gli avversari a investire maggiore impegno. Aiutano inoltre i modelli a spiegare contenuti sospetti invece di agire immediatamente su di essi.

I ricercatori di Google hanno testato i prompt di sicurezza in un framework di programmazione multi-agente. Il loro studio multi-agente ha coperto oltre 150 scenari di attacco a turno singolo e 32 a più turni.

Un hardener di sicurezza di circa 500 token ha ridotto i tassi di fallimento a turno singolo dal 19,48% al 2,60%. I tassi di fallimento multi-turno sono scesi dal 75% al 46,88%.

Questi risultati supportano l’irrobustimento dei prompt, ma ne rivelano anche il limite. Un tasso di fallimento multi-turno del 46,88% resta inaccettabile quando l’agente può eseguire codice, accedere a credenziali o modificare risorse di produzione.

Anche il tasso più basso a turno singolo genera un rischio rilevante su larga scala. Le interazioni ripetute offrono agli avversari ulteriori opportunità e gli aggressori possono adattare il linguaggio dopo aver osservato il comportamento del modello.

Lo studio ha inoltre rilevato che gli attacchi riusciti si sono spostati verso wrapper funzionali. Questi attacchi nascondono intenti dannosi all’interno di attività che assomigliano a normali funzioni dell’agente. Le istruzioni statiche faticano a rifiutarli senza bloccare anche attività legittime.

Questo è il problema centrale nel collocare il confine di sicurezza all’interno del modello. Il modello deve interpretare una richiesta aperta prevedendo al tempo stesso se essa violi un’altra istruzione altrettanto aperta.

Non valuta una regola di autorizzazione stabile come fa un sistema operativo quando controlla l’accesso ai file. Produce una risposta probabilistica influenzata da ogni token pertinente nel suo contesto.

Spiegare il prompt injection soltanto come “ignorare le istruzioni precedenti” non coglie questa ambiguità. Gli attacchi efficaci non annunciano sempre un conflitto. Possono presentare contesto falso, imitare il linguaggio di un flusso di lavoro affidabile o distribuire l’intento in più passaggi.

Un agente che esamina del codice potrebbe incontrare testo che sembra descrivere un test richiesto. Il test scarica o esegue silenziosamente un componente esterno. Ogni singolo passaggio può apparire plausibile all’interno di un flusso di lavoro di sviluppo.

A un agente di navigazione potrebbe essere detto che una specifica azione è necessaria per accedere alla pagina richiesta. Un assistente d’ufficio potrebbe leggere un documento che afferma che la policy aziendale richiede l’inoltro di contenuti per una revisione di conformità.

Il modello non possiede una conoscenza indipendente delle policy effettive di ogni organizzazione. Se il framework consente che affermazioni generate dal modello autorizzino azioni generate dal modello, il sistema diventa circolare.

I filtri affrontano una limitazione simile. Un rilevatore può cercare frasi note o stimare se un testo sembri avversariale. Gli aggressori possono parafrasare le istruzioni, suddividere i payload, nasconderli in vari formati o farli sembrare dati normali.

Bloccare ogni frase imperativa distruggerebbe i flussi di lavoro comuni. Documenti, email, commenti nel codice e ticket di assistenza contengono legittimamente istruzioni. L’agente deve spesso comprenderle senza adottarle come propri obiettivi.

Il fine-tuning può migliorare la resistenza, ma non elimina il conflitto architetturale. I modelli devono comunque interpretare linguaggio non affidabile e nuovi schemi di attacco possono ricadere al di fuori della loro distribuzione di addestramento.

Nemmeno la generazione aumentata dal recupero elimina il conflitto. RAG recupera materiale esterno e lo aggiunge al contesto del modello. Se la fonte è avvelenata, il recupero può fornire l’istruzione dell’aggressore proprio quando sembra pertinente.

Gli aggiornamenti del modello possono persino modificare il rischio in modo inatteso. Un modello più capace potrebbe rilevare meglio gli attacchi, ma potrebbe anche usare gli strumenti in modo più efficace dopo il successo di un attacco.

Per questo i punteggi dei benchmark richiedono contesto. Un modello che respinge la maggior parte delle injection in una suite di test fissa non dimostra che un agente distribuito sia sicuro. I sistemi reali contengono strumenti personalizzati, autorizzazioni, memoria e integrazioni.

L’obiettivo difensivo dovrebbe essere il fallimento controllato. Quando il modello classifica erroneamente un contenuto, il sistema circostante dovrebbe contenere l’esito, rendere visibile il tentativo e conservare prove per la revisione.

Un agente in sola lettura può comunque fuorviare un utente, quindi la qualità dell’output è importante. Tuttavia, le conseguenze più gravi emergono di solito quando i framework combinano un ragionamento incerto con un’autorità senza limiti.

I prompt di sicurezza dovrebbero quindi far parte di una progettazione a livelli. Sono un controllo, non il controllo che decide se dati privati attraversano un confine o se codice eseguibile raggiunge una workstation.

La sicurezza degli agenti AI dipende da capacità, contesto e consenso

I framework dovrebbero trattare il modello come un pianificatore non affidabile le cui proposte richiedono controlli applicabili.

Il primo controllo architetturale è la minimizzazione delle capacità. Un agente dovrebbe ricevere soltanto gli strumenti necessari per il compito corrente, non ogni integrazione disponibile per l’utente o l’organizzazione.

Un riepilogatore di calendari raramente necessita dell’autorizzazione a inviare email. Un assistente di ricerca non necessita automaticamente dell’accesso alla shell. Un revisore di codice potrebbe aver bisogno di leggere il repository senza l’autorizzazione a unire le modifiche.

Il principio statico del privilegio minimo è utile, ma le concessioni specifiche per attività sono migliori. Uno strumento può diventare disponibile per una singola operazione delimitata e scomparire al termine di tale operazione.

Anche le credenziali dovrebbero restare fuori dal contesto del modello. Il modello dovrebbe richiedere un’operazione tramite un broker anziché gestire direttamente segreti riutilizzabili. I log dovrebbero oscurare i token sensibili nei prompt e nelle risposte degli strumenti.

Il secondo controllo è l’autorizzazione contestuale. I controlli di accesso tradizionali spesso rispondono alla domanda se un utente possa accedere a una risorsa. I sistemi di agenti devono anche chiedersi se tale accesso supporti la richiesta corrente dell’utente.

Un utente che può leggere due account cliente non ha necessariamente autorizzato un agente a combinarli. Uno sviluppatore con accesso al deployment non ha autorizzato ogni agente di revisione del codice a effettuare il deployment.

L’intento non può essere inferito perfettamente dal linguaggio, ma i framework possono circoscriverlo attraverso dichiarazioni esplicite dell’attività. Possono vincolare gli strumenti a un obiettivo dichiarato, a un insieme di risorse, a una finestra temporale e a un flusso di dati consentito.

Il terzo controllo è il consenso per azioni consequenziali. L’approvazione umana è particolarmente importante prima di inviare informazioni all’esterno, spendere denaro, modificare gli accessi, eliminare dati o eseguire codice non affidabile.

Il consenso deve essere significativo. Popup vaghi e ripetuti abituano gli utenti ad approvare senza esaminare. L’interfaccia dovrebbe identificare l’azione esatta ed evidenziare gli scostamenti rispetto all’attività originale.

Le azioni reversibili a basso rischio possono usare controlli più leggeri. Le azioni ad alto rischio o irreversibili richiedono una conferma più forte e, in contesti aziendali, potenzialmente un secondo approvatore.

Il quarto controllo è l’isolamento. L’esecuzione del codice dovrebbe avvenire in una sandbox con accesso limitato a rete, filesystem e credenziali. Le sessioni del browser dovrebbero separare le pagine non affidabili dallo stato delle applicazioni sensibili.

L’output degli strumenti dovrebbe essere trattato come dati anziché come istruzioni automaticamente affidabili. I framework dovrebbero convalidare dimensione, formato, destinazione e contenuto consentito dell’output prima di restituirlo al modello.

Il quinto controllo è la preservazione della provenienza. Ogni documento, messaggio, pagina web, elemento di memoria e risposta dell’agente dovrebbe riportare l’origine e la classificazione di affidabilità.

Quando un agente riassume una pagina non affidabile, il riepilogo dovrebbe restare non affidabile. La trasformazione non dovrebbe cancellare la discendenza. Un motore di policy a valle può quindi impedire che materiale a bassa affidabilità autorizzi azioni ad alto impatto.

Il sesto controllo è la separazione tra proposta ed esecuzione. Un pianificatore può decidere che debba essere inviata un’email, ma un componente distinto dovrebbe convalidare destinatari e allegati.

Questa separazione limita gli attacchi del vice confuso. Un vice confuso si verifica quando un sistema con autorità legittima viene manipolato per usare tale autorità allo scopo di qualcun altro.

Il settimo controllo è l’osservabilità. I team hanno bisogno di registri che mostrino quale fonte ha influenzato una decisione, quale modello ha proposto un’azione, quale policy l’ha consentita e quale strumento l’ha eseguita.

Senza questi registri, un’organizzazione non può ricostruire un incidente che coinvolge un agente. I normali log applicativi possono acquisire le chiamate API, ma non il prompt, il contenuto recuperato, lo stato della memoria e i messaggi tra agenti.

Il monitoraggio dovrebbe concentrarsi anche sul comportamento. I segnali di avviso includono combinazioni insolite di risorse, fallimenti di autorizzazione ripetuti, nuove destinazioni in uscita, scritture inattese in memoria o strumenti usati al di fuori della loro normale sequenza.

L’ottavo controllo è il test avversariale sull’intero flusso di lavoro. Testare soltanto il modello di base ignora il framework in cui risiedono autorizzazioni ed effetti collaterali.

L’approccio di NIST utilizza strumenti e attività realistici perché la sicurezza degli agenti è contestuale. Un modello potrebbe resistere a un attacco in una semplice chat, ma fallire quando la stessa istruzione compare all’interno di un oggetto aziendale dall’aspetto affidabile.

I red team dovrebbero inserire contenuti dannosi in ogni fonte consumata da un agente. Ciò include siti web, email, documenti, repository di codice, tracker di issue, metadati degli strumenti, risultati di ricerca e memoria condivisa.

Dovrebbero inoltre testare percorsi multi-turno e multi-agente. Un comando diretto bloccato potrebbe riuscire dopo essere stato riformulato da un agente intermediario o memorizzato per un recupero successivo.

L’obiettivo non è pubblicare un singolo tasso di successo delle prompt injection. È identificare quali injection riuscite raggiungono dati sensibili, strumenti privilegiati o operazioni irreversibili.

Questo favorisce una migliore definizione delle priorità. Un’injection frequente che corrompe soltanto una bozza temporanea merita attenzione. Un’injection più rara che raggiunge credenziali di produzione richiede prima controlli più forti.

OWASP raccomanda privilegio minimo, segregazione dei contenuti esterni, approvazione umana, convalida dell’output e test avversariali. Queste misure riflettono un modello di difesa in profondità anziché la fiducia in un unico rilevatore.

La più ampia tassonomia degli attacchi di NIST sottolinea inoltre la gestione delle conseguenze insieme all’identificazione degli attacchi. Questo approccio è adatto ai sistemi di agenti perché la prevenzione completa resta incerta.

Nessuno di questi controlli rende il modello affidabile. Rendono il sistema meno dipendente dall’affidabilità del modello, che è l’obiettivo ingegneristico più difendibile.

Cosa dovrebbero osservare i lettori di Google News

Le prove decisive arriveranno dalle impostazioni predefinite dei framework, da un contenimento misurabile e da una reportistica trasparente sugli incidenti.

Il primo segnale è se i principali framework rendono l’esecuzione limitata l’impostazione predefinita. Le sandbox opzionali e i controlli delle autorizzazioni aiutano i team esperti, ma le impostazioni predefinite modellano migliaia di deployment ordinari.

Osservate come le piattaforme per agenti gestiscono le concessioni degli strumenti, l’accesso alla rete, le scritture sul filesystem e le credenziali riutilizzabili. Un framework che espone prima capacità estese e documenta l’irrobustimento in seguito preserva il rischio sottostante.

L’impostazione predefinita più solida non concederebbe automaticamente alcuno strumento sensibile. Gli sviluppatori aggiungerebbero capacità con ambito ristretto, vedendo al contempo le conseguenze di ogni autorizzazione.

Il secondo segnale è se le valutazioni misurano l’impatto end-to-end. I tassi di rifiuto degli attacchi sono utili, ma non rivelano se un attacco riuscito abbia raggiunto dati riservati o completato un’azione pericolosa.

Valutazioni migliori riporteranno sia la compromissione del modello sia quella del sistema. Distingueranno una risposta manipolata da una lettura non autorizzata, un trasferimento in uscita, l’esecuzione di codice o una modifica persistente della memoria.

Dovrebbero inoltre pubblicare risultati relativi a tentativi ripetuti. Una difesa che riesce una volta ma fallisce dopo diverse variazioni offre una protezione limitata in un servizio esposto a Internet.

I risultati della ricerca di Google illustrano questa necessità. L’irrobustimento dei prompt ha migliorato sostanzialmente la resistenza, ma gli attacchi multi-turno hanno mantenuto un alto tasso di fallimento. I controlli architetturali determinano cosa significano questi fallimenti residui.

Il terzo segnale è la qualità della divulgazione. Gli incidenti specifici dell'AI spesso non includono gli artefatti familiari usati nella gestione convenzionale delle vulnerabilità. I team possono ricevere un post sul blog di un fornitore privo di un identificatore standard, di un intervallo di versioni interessate o di un chiaro percorso di mitigazione.

I fornitori di framework dovrebbero pubblicare avvisi di sicurezza che descrivano l'intera catena di attacco. Gli utenti devono conoscere la fonte di contenuto necessaria, il comportamento del modello, le autorizzazioni, gli strumenti, le versioni interessate e le mitigazioni disponibili.

Affermazioni vaghe secondo cui un modello ha ricevuto “ulteriori misure di sicurezza” non sono sufficienti. I clienti devono capire se il fornitore ha modificato il modello, le policy del framework, il sistema di autorizzazioni, il sandbox o il flusso di approvazione dell'utente.

Lo stesso standard dovrebbe applicarsi alle decisioni sui bug bounty. Se una segnalazione dimostra una prompt injection ma nessun effetto significativo, una gravità bassa può essere ragionevole. Se l'iniezione raggiunge un'azione privilegiata, liquidarla come comportamento previsto del modello evita la questione reale.

Google News continuerà a mettere in evidenza dimostrazioni di prompt injection perché sono vivide e facili da riprodurre. Alcune saranno jailbreak minori, mentre altre esporranno gravi fallimenti del framework.

I lettori dovrebbero distinguere tre domande. L'attaccante ha influenzato il modello? Quale capacità è diventata disponibile dopo tale influenza? Quale controllo indipendente avrebbe dovuto fermare l'azione risultante?

Questa sequenza produce una valutazione del rischio più utile rispetto al chiedersi se la prompt injection sia stata finalmente risolta. Le prove attuali non offrono alcuna base per presumere una soluzione universale.

Gli sviluppatori dovrebbero ispezionare ogni percorso tra contenuti non attendibili e strumenti sensibili. Gli acquirenti aziendali dovrebbero richiedere autorizzazioni limitate al compito, provenienza, sandboxing, controlli di approvazione e registri di esecuzione verificabili.

I knowledge worker dovrebbero verificare a cosa un agente può accedere prima di collegare email, file, calendari e sistemi aziendali. La comodità aumenta rapidamente quando queste fonti vengono combinate, ma aumenta anche il potenziale raggio d'impatto.

L'inversione centrale resta semplice. La prompt injection è l'innesco, mentre il framework fornisce portata, autorità e persistenza. Trattare solo l'innesco lascia invariati i meccanismi pericolosi.

La prossima volta che un titolo di Google News annuncia un altro dirottamento di un agente, guardate oltre le parole malevole. Chiedetevi quale strumento le abbia eseguite, quale autorizzazione lo abbia consentito e perché nessun controllo separato sia intervenuto.

Questo è il test che i costruttori di agenti devono ora superare. Il sistema può rimanere sicuro dopo che il suo modello è stato persuaso, confuso o semplicemente si è sbagliato? Se la risposta dipende soltanto da prompt migliori, il framework continua a contenere il bug.