Gli agenti AI autenticati possono comunque deviare, esporre dati o conservare memoria avvelenata

Google News ha evidenziato un’analisi di VentureBeat con un avvertimento netto: un agente AI può superare l’autenticazione e compiere comunque l’azione sbagliata. La credenziale può essere valida. Anche la chiamata API può essere autorizzata. Eppure l’azione può violare il compito assegnato, esporre dati sensibili o conservare in memoria le istruzioni di un attaccante.

Questa distinzione mette in discussione un’assunzione di sicurezza consolidata. La gestione di identità e accessi verifica chi o cosa ha richiesto l’accesso. Non stabilisce automaticamente se un sistema autonomo stia ancora perseguendo lo scopo assegnato.

Il report del 30 agosto sostiene che le aziende stiano implementando gateway di enforcement prima di definire il contesto di cui tali gateway hanno bisogno. Il confronto non riguarda un fornitore di sicurezza rispetto a un altro. Riguarda autenticazione valida e comportamento valido, due condizioni che non significano più la stessa cosa.

Cosa ha realmente cambiato il report di Google News

Il report riformula la sicurezza degli agenti AI come un problema di sequenza, non semplicemente di autenticazione.

Il collaboratore di VentureBeat Nik Kale descrive un modello ricorrente nelle implementazioni aziendali. I team spesso iniziano con un gateway runtime che ispeziona il traffico degli agenti e applica policy di accesso.

Tuttavia, quel gateway spesso non dispone di informazioni a monte sull’agente. Potrebbe non conoscere il proprietario dell’agente, il compito assegnato, gli strumenti approvati, l’autorità delegata o la catena completa delle azioni.

Il punto cieco che ne deriva è facile da trascurare. Immaginate un agente di riconciliazione finanziaria che tenta di modificare un record di produzione. Un gateway può autenticare il token del dipendente e confermare che il token consente l’operazione API.

Entrambi i controlli possono superare la verifica mentre l’agente eccede il proprio incarico. Il dipendente potrebbe avere un ampio accesso alla produzione, mentre all’agente è stato delegato solo uno specifico compito di riconciliazione.

La sequenza di sicurezza di Kale colloca l’enforcement runtime al quinto posto di una catena di dipendenze composta da sei parti. Inventario, identità distinte, credenziali con ambito limitato e telemetria attribuibile devono venire prima.

Dopo l’enforcement seguono il monitoraggio comportamentale e un percorso di contenimento tra sistemi. Quest’ordine conta perché ogni controllo successivo dipende dal contesto creato da quelli precedenti.

L’articolo non sostiene che i gateway siano inutili. Sostiene che diventino utili solo dopo che un’organizzazione è in grado di rispondere ad alcune domande fondamentali.

Quale agente ha avviato la richiesta? Chi ha delegato il compito? Quale autorità sta utilizzando l’agente? Quale risultato dovrebbe produrre il compito?

Un gateway convenzionale spesso vede un token, una destinazione e un metodo di richiesta. Un piano di controllo consapevole degli agenti deve anche comprendere scopo, provenienza e conseguenze a valle.

Questo è il ribaltamento centrale dell’evento. L’autenticazione resta necessaria, ma un’autenticazione riuscita non fornisce più prove sufficienti per stabilire la fiducia.

Anche il momento è rilevante. Gli agenti AI stanno andando oltre la generazione di testo, entrando in flussi di lavoro che chiamano API, manipolano file, modificano database e si coordinano con altri sistemi.

Queste azioni producono effetti persistenti. Una risposta errata può essere corretta. Un pagamento completato, un dataset esportato, una credenziale revocata o un ambiente di produzione modificato richiedono contenimento e ripristino.

Questo elemento di Google News segnala quindi un cambiamento operativo più ampio. I team di sicurezza devono valutare il percorso completo dall’intento delegato all’effetto esterno.

Non possono fermarsi al confine dell’accesso. La domanda importante ora inizia dopo che l’agente è stato ammesso.

L’autenticazione prova l’identità, non l’intento

Una credenziale valida identifica un soggetto autorizzato, ma non dimostra che ogni azione dell’agente serva il compito attuale di quel soggetto.

I sistemi di identità tradizionali sono stati progettati attorno ad attori relativamente stabili. Una persona effettua l’accesso, riceve autorizzazioni e compie azioni che compaiono in una traccia di audit.

Gli agenti AI complicano ogni parte di questo modello. Un dipendente può avviare diversi agenti, mentre ciascun agente può richiamare più strumenti e creare attività aggiuntive.

Se tutti questi processi prendono in prestito un unico token del dipendente, i log comprimono diversi attori distinti in un’unica identità. Gli investigatori possono vedere la credenziale, ma non il vero decisore.

Gli account di servizio condivisi creano un problema simile. Nascondono la titolarità e rendono difficile una revoca mirata quando solo un agente diventa non sicuro.

Identità di agente distinte migliorano l’attribuzione, ma l’identità da sola resta incompleta. Il sistema deve conservare il contesto della delega, ossia la persona o il servizio che ha assegnato il compito e il suo scopo consentito.

Considerate un dipendente con accesso a buste paga, acquisti, record dei clienti e reportistica finanziaria. Un agente incaricato di riconciliare fatture non dovrebbe ereditare l’intero perimetro di accesso del dipendente.

L’autorità sicura è l’intersezione di tre limiti. Include le autorizzazioni del delegante, le capacità approvate dell’agente e le risorse necessarie per il compito corrente.

Kale chiama questo principio delega monotona. Ogni trasferimento di autorità dovrebbe preservare o ridurre l’accesso, mai ampliarlo.

Questo è più rigoroso dell’assegnazione di un ruolo. Richiede credenziali limitate al compito, che scadano e non possano raggiungere sistemi non correlati.

Le credenziali di breve durata riducono anche il valore dei segreti rubati. Un attaccante che ottiene un token non dovrebbe acquisire accesso indefinito a ogni risorsa disponibile per il dipendente.

La telemetria deve quindi collegare ogni invocazione di strumento alla sua origine. Un record utile identifica l’agente, il delegante, il compito, l’azione padre, la credenziale, lo strumento e il risultato.

Senza questa catena, chi risponde agli incidenti affronta due ritardi dannosi. Deve prima scoprire quale agente esiste, poi determinare quali sistemi a valle ha toccato.

Un agente autenticato può anche deviare senza un attaccante esterno. La deriva comportamentale si verifica quando le sue azioni divergono gradualmente dallo scopo assegnato o dal modello operativo approvato.

L’innesco potrebbe essere costituito da istruzioni ambigue, contesto mutevole, una risposta inattesa di uno strumento o una sequenza accumulata di decisioni individualmente consentite.

Questo comportamento differisce da un account convenzionale compromesso. L’agente potrebbe usare credenziali approvate e API approvate esattamente come previsto.

Il fallimento risiede nella relazione tra l’azione e il compito originale. L’autenticazione standard non valuta questa relazione.

Il sondaggio sull’impresa agentica di Okta illustra il divario di governance. Solo il 34% delle organizzazioni intervistate applicava gli stessi controlli di sicurezza alle forze lavoro digitali e umane.

Il sondaggio ha inoltre riportato una discrepanza di fiducia. Il novantacinque percento dei dirigenti si è detto fiducioso che le proprie organizzazioni potessero rilevare un’AI operante al di fuori del proprio ambito previsto.

Questi risultati provengono da una ricerca sponsorizzata da un fornitore, quindi non dovrebbero essere considerati una misurazione indipendente dell’intero mercato. Tuttavia, il contrasto individua una domanda operativa verificabile.

L’organizzazione è in grado di ricostruire un singolo compito di un agente dall’avvio fino a ogni effetto a valle? In caso contrario, la sua fiducia precede le sue prove.

L’autenticazione risponde se una credenziale può entrare. La sicurezza degli agenti deve anche rispondere se l’azione risultante rientra nello scopo delegato.

L’avvelenamento della memoria dell’agente rende persistente un singolo input dannoso

L’avvelenamento della memoria dell’agente trasforma contenuti non attendibili da un prompt temporaneo in istruzioni riutilizzabili che possono influenzare sessioni successive.

La memoria aiuta un agente a conservare preferenze, contesto di progetto, cronologia delle attività e decisioni precedenti. Questa continuità riduce le ripetizioni e rende più utili i flussi di lavoro di lunga durata.

Crea anche una superficie di attacco durevole. Un agente può memorizzare informazioni raccolte da pagine web, documenti, messaggi, risposte degli strumenti o altri agenti.

Se contenuti dannosi raggiungono tale archivio, l’agente può recuperarli in seguito come contesto attendibile. L’attaccante originale potrebbe non essere più presente quando si verifica l’azione dannosa.

OWASP definisce l’avvelenamento della memoria come informazioni dannose persistenti, volte a influenzare sessioni o utenti successivi. La sua guida alla sicurezza degli agenti elenca la minaccia insieme a dirottamento degli obiettivi, abuso degli strumenti, esposizione dei dati ed eccessiva autonomia.

Questa persistenza modifica la risposta agli incidenti. Eliminare il messaggio originale o bloccare la fonte non rimuove necessariamente l’istruzione memorizzata.

Una memoria avvelenata può sopravvivere tra conversazioni diverse. Può anche influenzare riepiloghi, record recuperati, piani e decisioni generati giorni dopo.

Uno scenario pratico inizia con un agente che legge un documento esterno. Un testo nascosto identifica falsamente un contatto controllato dall’attaccante come fornitore approvato per richieste urgenti.

L’agente memorizza tale affermazione come conoscenza organizzativa. In seguito, un utente legittimo chiede aiuto durante un’interruzione operativa.

L’agente recupera la voce avvelenata e raccomanda il contatto controllato dall’attaccante. Il suo output appare internamente coerente perché segue informazioni già accettate nella memoria.

L’autenticazione offre poca protezione in questo scenario. L’utente è legittimo, l’agente è legittimo e la richiesta successiva può essere ordinaria.

L’elemento corrotto è il contesto conservato dall’agente. Quel contesto determina il modo in cui viene completato un compito altrimenti consentito.

L’avvelenamento della memoria può anche creare percorsi di esposizione dei dati. Un’istruzione memorizzata può dire all’agente di includere file nascosti, trasmettere risultati a un endpoint non approvato o indebolire un futuro controllo di sicurezza.

L’effetto può diffondersi quando più agenti condividono un vector store o un livello di conoscenza. Una voce avvelenata può influenzare diversi flussi di lavoro senza compromettere separatamente ogni agente.

L’avvelenamento della memoria dell’agente complica anche l’attribuzione delle responsabilità. Un output dannoso può sembrare un’allucinazione o un fallimento del modello, quando la causa reale è uno stato persistente corrotto.

Questa distinzione influenza la correzione. Cambiare il modello o riscrivere il prompt immediato non riparerà un archivio di memoria avvelenato.

I team di sicurezza necessitano di provenienza per il contesto memorizzato. La provenienza registra da dove ha avuto origine un elemento, quando è entrato in memoria, quale processo lo ha approvato e come le attività successive lo hanno utilizzato.

La memoria dovrebbe anche avere etichette di fiducia. Contenuti forniti dagli utenti, testo recuperato esternamente, policy approvate dal sistema e record organizzativi verificati non dovrebbero entrare in un unico insieme indifferenziato.

Lo stesso principio è importante in una base di conoscenza AI personale. Il contesto persistente diventa più prezioso man mano che si accumula, ma diventano altrettanto importanti la sua origine e il suo ambito.

La discussione di OWASP sulla memoria persistente descrive un caso correlato di Claude Code chiamato MemoryTrap. I ricercatori di Cisco hanno scoperto che un normale flusso di sviluppo poteva collocare contenuti dannosi in superfici persistenti e attendibili.

Secondo OWASP, Anthropic ha successivamente modificato Claude Code per rimuovere le memorie degli utenti da un percorso di system prompt ad alta fiducia. Questa correzione ha affrontato il percorso identificato, non l’intera classe di rischi.

La lezione va oltre un singolo agente di coding. Qualsiasi sistema che scriva stato modificabile e successivamente lo tratti come guida necessita di controlli specifici per la memoria.

Tali controlli includono validazione prima della memorizzazione, verifiche di integrità, recupero con ambito limitato, monitoraggio delle modifiche e ripristino a uno stato noto e valido.

I team devono inoltre distinguere la memoria fattuale dalle istruzioni comportamentali. Una data di progetto memorizzata non dovrebbe avere la stessa autorità di una policy di sicurezza.

Questa separazione diventa particolarmente importante quando un agente può scrivere le proprie memorie. Un processo di pianificazione compromesso non dovrebbe ridefinire silenziosamente le future regole operative.

L'avvelenamento della memoria degli agenti dimostra perché la sicurezza non può concentrarsi solo sulle richieste che entrano nel modello. I difensori devono proteggere lo stato che transita tra una richiesta e l'altra.

Perché un gateway non può sostenere da solo l'intero modello di sicurezza

Un gateway può applicare policy, ma non può creare dati mancanti su identità, delega o attribuzione.

I gateway di runtime occupano una posizione interessante. Possono osservare le chiamate agli strumenti, ispezionare le richieste, applicare regole e bloccare destinazioni pericolose.

Questa visibilità li rende un acquisto logico per le organizzazioni preoccupate della sicurezza degli agenti AI. Eppure il gateway stesso diventa anche un'infrastruttura privilegiata.

Un incidente LiteLLM del giugno 2026 ha mostrato perché questa concentrazione merita attenzione. CISA ha aggiunto CVE-2026-42271 al proprio catalogo Known Exploited Vulnerabilities dopo aver rilevato prove di sfruttamento attivo.

La vulnerabilità interessava endpoint utilizzati per testare le configurazioni dei server Model Context Protocol. Model Context Protocol, o MCP, consente alle applicazioni AI di collegarsi a strumenti e fonti di dati esterne.

Secondo la divulgazione di LiteLLM, un utente autenticato poteva fornire dettagli di comando che il proxy vulnerabile eseguiva sul proprio host.

I ricercatori hanno inoltre concatenato la vulnerabilità con un difetto separato di validazione dell'host. Secondo quanto riportato, la combinazione permetteva l'esecuzione remota di comandi senza credenziali nelle configurazioni interessate.

LiteLLM ha corretto il problema di command injection nella versione 1.83.7. L'episodio non dimostra che ogni gateway sia insicuro.

Dimostra che un gateway fa parte della superficie d'attacco, non è un sostituto di un'architettura di sicurezza. Collocare più autorità in un singolo controllo aumenta le conseguenze della sua compromissione.

Anche un gateway non compromesso resta limitato dai propri input. Un motore di policy non può dedurre lo scopo da un bearer token che non contiene alcun contesto dell'attività.

Non può nemmeno distinguere venti agenti che condividono un unico account di servizio. Il traffico appare autorizzato perché il modello di identità sottostante ha cancellato le differenze prima ancora che inizi l'applicazione delle policy.

Questo è il principale compromesso. L'applicazione centralizzata può migliorare la coerenza, ma la centralizzazione non risolve l'ambiguità a monte.

Un gateway acquisisce valore dopo che l'organizzazione ha definito un inventario degli agenti. Ogni agente di produzione necessita di un proprietario, uno scopo definito, strumenti approvati, una fonte delle credenziali e uno stato del ciclo di vita.

La dipendenza successiva è un'identità distinta collegata alla delega. Uno strumento dovrebbe sapere sia quale agente lo ha chiamato sia di chi rappresenta l'autorità.

Le credenziali devono quindi avere ambiti ristretti e durate brevi. Un agente di riconciliazione dovrebbe accedere al registro necessario, non a ogni database disponibile per il suo sponsor umano.

Segue una telemetria attribuibile. I team di sicurezza devono poter tracciare un'attività completata attraverso ogni chiamata agli strumenti e ogni risultato a valle.

Solo allora una policy di runtime può prendere una decisione consapevole del contesto. La decisione diventa più specifica del semplice chiedere se il token consente una scrittura nel database.

Può chiedere se questo agente può eseguire questa scrittura per questo principal, durante questa attività, su questo record.

Quel contesto aggiuntivo supporta anche controlli rafforzati. Le operazioni ad alto impatto possono richiedere un'approvazione indipendente anche quando l'agente possiede credenziali valide.

Pagamenti, eliminazioni, modifiche in produzione, esportazioni di dati e modifiche alle policy di accesso rientrano in questa categoria. Le loro conseguenze giustificano un confine di autorizzazione esterno.

L'agente non dovrebbe approvare la propria azione. Altrimenti, un'istruzione iniettata può influenzare sia la proposta sia la salvaguardia.

Le aziende necessitano anche di un percorso di arresto che attraversi i sistemi. Disabilitare una singola identità è insufficiente se token attivi, attività in esecuzione e strumenti connessi restano disponibili.

Il contenimento dovrebbe revocare le credenziali primarie e derivate, interrompere le attività correnti, disabilitare l'accesso agli strumenti e isolare il carico di lavoro che ospita l'agente.

Questa capacità non può essere improvvisata durante un incidente. I team devono testarla prima di concedere a un agente autorità in produzione.

Il gateway rimane quindi prezioso, ma la sua posizione cambia. Diventa un livello di applicazione all'interno di una più ampia catena di dipendenze.

È una promessa più circoscritta rispetto a “proteggere ogni richiesta dell'agente”. È anche una promessa più difendibile.

Il principio del privilegio minimo aiuta, ma non ferma la deriva

Ridurre gli accessi limita i danni che un agente può causare, mentre i controlli comportamentali affrontano ciò che l'agente fa entro tale perimetro ridotto.

Il principio del privilegio minimo resta una delle protezioni più chiare disponibili. Un agente non può esporre un database che le sue credenziali non possono raggiungere.

Teleport ha commissionato una ricerca che ha coinvolto 205 responsabili della sicurezza e dell'infrastruttura. Le organizzazioni che hanno segnalato sistemi AI con privilegi eccessivi hanno registrato un tasso di incidenti del 76%, contro il 17% dei sistemi con privilegi minimi.

Si tratta di una differenza di 4,5 volte nei tassi riportati dal sondaggio. L'indagine sull'identità dell'azienda è stata condotta da Eleven Market Research nel dicembre 2025.

I sondaggi sponsorizzati dai fornitori presentano limiti. Le loro definizioni di sistemi AI, incidenti e livelli di privilegio possono differire dalle misurazioni interne di un'altra organizzazione.

I risultati sostengono comunque una proposizione pratica. Perimetri di autorizzazione più ridotti diminuiscono generalmente il numero di sistemi disponibili a un agente che commette un errore o viene compromesso.

Tuttavia, il privilegio minimo non dimostra un comportamento corretto. Un agente può usare impropriamente l'autorità limitata che possiede legittimamente.

Un agente di assistenza clienti può avere l'autorizzazione a leggere un singolo account. Può comunque esporre i dati di quell'account nel canale sbagliato.

Un agente di pianificazione può avere accesso in scrittura al calendario. Può comunque annullare una riunione approvata dopo aver interpretato erroneamente contenuti malevoli in un invito.

Un agente finanziario può accedere a un singolo registro contabile. Può comunque modificare il record sbagliato restando interamente entro l'ambito delle proprie autorizzazioni tecniche.

È qui che le baseline comportamentali diventano utili. Una baseline descrive gli strumenti, le destinazioni, la frequenza delle azioni, i domini di dati e i modelli di attività normali dell'agente.

I team di sicurezza possono quindi rilevare le deviazioni. Gli esempi includono accessi tra domini inattesi, ripetuti fallimenti di approvazione, esportazioni insolite o variazioni nella frequenza delle chiamate agli strumenti.

Le baseline devono basarsi su identità e telemetria affidabili. Altrimenti, i dati di agenti differenti vengono mescolati in un unico profilo fuorviante.

Anche il monitoraggio deve essere consapevole dell'attività. Una rara scrittura nel database potrebbe essere legittima per un'attività e pericolosa per un'altra.

Questo requisito rende insufficienti le regole statiche. Le decisioni di runtime necessitano di un contesto strutturato su scopo, iniziatore, risorse approvate e risultato previsto.

La domanda difficile riguarda quanto contesto il sistema di applicazione possa considerare affidabile. Se l'agente genera autonomamente la descrizione della propria attività, un agente compromesso può travisarne lo scopo.

Il contesto affidabile dell'attività dovrebbe quindi provenire da un orchestratore esterno, una definizione di workflow o un sistema di approvazione. L'agente può utilizzare quel contesto, ma non dovrebbe riscriverlo silenziosamente.

La memoria richiede un trattamento simile. Un modello non dovrebbe promuovere testo recuperato e non verificato a policy duratura senza una validazione indipendente.

Questi confini separano chi prende la decisione dall'autorizzazione della decisione. Riducono la probabilità che un unico modello manipolato controlli ogni fase.

L'approvazione umana può essere utile ai confini irreversibili, ma non è una risposta completa. Volumi elevati di richieste e prompt ripetitivi creano affaticamento da approvazione.

L'interfaccia di approvazione deve mostrare i fatti rilevanti. I revisori necessitano dell'attività che ha avviato l'azione, della risorsa interessata, della modifica proposta e della conseguenza attesa.

Un generico pulsante “consenti” trasferisce la responsabilità senza fornire informazioni sufficienti. Può trasformarsi in un'altra cerimonia di autenticazione che non coglie l'intento.

Una sicurezza efficace degli agenti AI combina quindi limiti e osservazione. Il privilegio minimo restringe il raggio d'azione, mentre telemetria e autorizzazione indipendente rendono visibile la deriva comportamentale.

I controlli di integrità della memoria affrontano la manipolazione persistente. Un percorso di arresto tra sistemi gestisce i casi che i controlli preventivi non riescono a intercettare.

Nessun singolo livello dimostra che un agente si comporterà correttamente. L'obiettivo è rendere il comportamento non sicuro visibile, circoscritto, reversibile e attribuibile.

I sei controlli che le aziende possono verificare subito

La sicurezza degli agenti AI diventa misurabile quando ogni controllo dispone di un test operativo anziché di una dichiarazione di policy.

Il primo test è l'inventario. Un'organizzazione dovrebbe poter nominare ogni agente di produzione e identificare il proprietario responsabile.

L'inventario dovrebbe includere scopo, strumenti approvati, domini di dati, fonti delle credenziali, fornitore del modello, posizione di distribuzione e stato del ciclo di vita.

Gli agenti ombra meritano lo stesso trattamento. Un sistema non diventa meno rischioso perché un reparto lo ha distribuito senza approvazione centrale.

Il secondo test è l'identità e la delega. I log dovrebbero distinguere l'agente dalla persona, dal servizio o dal workflow che gli ha assegnato l'attività.

Quel collegamento deve sopravvivere alle chiamate agli strumenti e ai passaggi di consegne tra agenti. Altrimenti, l'attribuzione scompare non appena il workflow lascia la prima applicazione.

Il terzo test è l'ambito delle credenziali. I team di sicurezza dovrebbero selezionare un agente e confermare che il suo token attivo non possa raggiungere risorse non correlate.

La credenziale dovrebbe inoltre scadere con l'attività. I segreti a lunga durata trasformano un accesso temporaneo dell'agente in un'esposizione persistente.

Il quarto test è la ricostruzione. Gli investigatori dovrebbero scegliere un'attività completata e tracciarla dall'avvio fino a ogni effetto a valle.

Una traccia completa include prompt, contesto recuperato, letture dalla memoria, scritture in memoria, chiamate agli strumenti, approvazioni, credenziali, output e modifiche esterne.

Questo record non dovrebbe dipendere interamente dal ragionamento auto-riferito dell'agente. Le prove più affidabili provengono da sistemi esterni al modello.

Il quinto test è l'applicazione consapevole del contesto. L'organizzazione dovrebbe tentare un'azione che lo sponsor umano può eseguire ma l'agente delegato non può eseguire.

Il gateway dovrebbe bloccare l'azione perché esula dall'attività. Bloccarla solo perché il token non dispone dell'accesso verifica le autorizzazioni ordinarie, non un controllo consapevole dell'agente.

Il sesto test è il contenimento. Un incidente simulato dovrebbe verificare che l'organizzazione possa arrestare l'agente in ogni sistema connesso.

I team dovrebbero revocare le credenziali, interrompere le esecuzioni attive, bloccare gli strumenti, isolare il carico di lavoro e impedire la ripresa automatica delle azioni in coda.

La memoria richiede test aggiuntivi lungo l'intera sequenza. I team di sicurezza dovrebbero identificare chi può scrivere contesto persistente e quali workflow successivi possono recuperarlo.

Dovrebbero inserire un record di test innocuo proveniente da una fonte non attendibile. Il sistema dovrebbe etichettarne la provenienza, limitarne l'ambito e impedirne la trasformazione in policy.

Altrettanto importante è un esercizio di rollback. La rimozione di una voce avvelenata non dovrebbe distruggere memorie valide né lasciare inalterati riepiloghi derivati.

Il contesto derivato crea un problema di ripristino sottile. Un record malevolo potrebbe aver già influenzato un riepilogo, un piano o un oggetto di conoscenza condivisa.

Eliminare solo l'originale lascia intatti quei discendenti. I sistemi di memoria necessitano quindi di una lineage tra record di origine e artefatti generati.

Gli acquirenti aziendali dovrebbero chiedere ai fornitori se le modifiche alla memoria sono verificabili tramite audit. Dovrebbero inoltre chiedere se le etichette di attendibilità sopravvivono a riepilogo e recupero.

Gli sviluppatori necessitano di controlli chiari sui confini degli strumenti. Un modello dovrebbe ricevere solo gli strumenti richiesti per l'attività corrente, non un intero catalogo di integrazioni.

I knowledge worker dovrebbero capire che il richiamo sicuro di un agente non ne stabilisce la provenienza. Il contesto persistente può essere obsoleto, errato o deliberatamente manipolato.

Questi controlli trasformano una preoccupazione di sicurezza astratta in evidenze osservabili. Rivelano inoltre dove si interrompe la catena di dipendenze di un deployment.

Un'azienda non deve sostituire l'intero stack di identità prima di iniziare. Può registrare gli agenti rispetto alle identità dei workload esistenti e aggiungere identificatori di attività attendibili.

Può quindi orientarsi verso credenziali di durata più breve, log più ricchi e approvazioni indipendenti per operazioni ad alto impatto.

La sequenza conta più del branding di ciascun controllo. Ogni livello a valle dovrebbe utilizzare le evidenze prodotte a monte.

Quando tali evidenze mancano, l'organizzazione dovrebbe ridurre l'autorità dell'agente. Non dovrebbe compensare riponendo maggiore fiducia in un gateway.

Cosa dovrebbero osservare ora i team di sicurezza

La prossima fase della sicurezza degli agenti AI sarà misurata attraverso i controlli di prodotto, le evidenze degli incidenti e gli standard specifici per la memoria.

Il primo segnale è un'identità nativa con ambito limitato all'attività sulle piattaforme di agenti. I fornitori devono esporre identificatori distinti degli agenti, catene di delega e credenziali a breve durata tramite interfacce standard.

Se queste capacità diventeranno predefinite, i gateway potranno applicare policy basandosi su elementi ulteriori rispetto alla sola validità del token. Ciò rafforzerebbe il modello basato sulle dipendenze descritto nel report di Google News.

Se le piattaforme continueranno a fare affidamento su account di servizio condivisi e token degli sviluppatori, il modello si indebolirà nella pratica. Le aziende avranno difficoltà a creare attribuzione dopo il deployment.

Il secondo segnale è il testing indipendente delle difese della memoria. Le linee guida attuali identificano chiaramente l'avvelenamento della memoria degli agenti, ma le implementazioni variano notevolmente.

Test utili dovrebbero misurare se il contenuto avvelenato persiste, attraversa gli utenti, influenza gli strumenti, sopravvive alla sintesi o rimane dopo un tentativo di eliminazione.

Dovrebbero inoltre valutare la riparazione. Rilevare una memoria dannosa ha un valore limitato se i team non riescono a identificare e rimuovere ogni artefatto derivato.

Risultati standardizzati aiuterebbero gli acquirenti a distinguere il filtraggio di base degli input da una protezione autentica dell'intero ciclo di vita. Rivelerebbero inoltre se le difese funzionano al di fuori di dimostrazioni controllate.

Il terzo segnale è la segnalazione pubblica di incidenti collegata alle catene di azioni degli agenti. I team di sicurezza hanno bisogno di evidenze che mostrino dove hanno fallito identità, delega, memoria o contenimento.

Un report che afferma “l'AI ha commesso un errore” non è sufficiente. Gli investigatori hanno bisogno dell'origine dell'attività, del contesto recuperato, del percorso degli strumenti, dell'ambito delle credenziali e dell'effetto esterno.

Una reportistica più dettagliata rafforzerebbe oppure metterebbe in discussione la tesi attuale. Fallimenti ripetuti dopo un'autenticazione valida confermerebbero che la sola identità è insufficiente.

Al contrario, una riduzione sostenuta degli incidenti nei deployment che utilizzano credenziali con ambito limitato e telemetria attribuibile sosterrebbe l'ordine dei controlli proposto.

I responsabili della sicurezza dovrebbero iniziare a raccogliere queste misurazioni ora. Attendere una categoria di fornitori matura lascia gli agenti odierni operare secondo le ipotesi di ieri.

Gli sviluppatori possono iniziare tracciando un'attività completa. Gli acquirenti aziendali possono richiedere evidenze per l'identità, la provenienza della memoria e il contenimento tra sistemi.

I knowledge worker possono chiedersi da dove provengano i fatti ricordati da un agente prima di agire sulla base di raccomandazioni sensibili.

La lezione chiave di questa storia di Google News non è che l'autenticazione abbia fallito. L'autenticazione svolge un compito più circoscritto rispetto a quello oggi richiesto dai workflow autonomi.

Il lavoro più difficile inizia dopo che l'accesso è stato concesso. La vostra organizzazione può dimostrare perché un agente ha agito, limitare ciò che può raggiungere, ispezionare ciò che ricorda e fermarlo ovunque?

Scegliete un agente in produzione questa settimana e ricostruite la sua ultima attività completata. Se manca un qualsiasi collegamento, quella lacuna identifica il prossimo controllo da implementare.