Gli agenti AI trasformano l'accesso aziendale in un rischio per i dati dall'interno verso l'esterno

Google News ha evidenziato un avvertimento più netto sugli agenti AI: la più grande minaccia ai dati aziendali potrebbe già disporre di credenziali valide e di accesso approvato.

La copertura di Dark Reading non descrive una singola violazione isolata. Mette in luce un più ampio ribaltamento della sicurezza. Le aziende concedono agli agenti accesso interno affinché possano automatizzare attività utili. Quello stesso accesso consente a errori, istruzioni ostili o autorizzazioni eccessive di spostare informazioni sensibili tra sistemi fidati.

Le difese tradizionali si concentrano sul tenere gli intrusi fuori dalla rete. Gli agenti AI complicano questo modello perché spesso operano all'interno di applicazioni approvate, usando identità legittime e strumenti autorizzati. Il conflitto centrale ora è tra produttività e controllo, non tra difensori e un evidente attaccante esterno.

I lettori di Google News che incontrano questa storia dovrebbero considerarla un avvertimento sulla governance degli accessi. Un agente non deve superare il perimetro quando un'azienda lo ha già collegato a email, documenti, database, browser e API esterne.

Cosa segnala davvero il titolo di Google News

Gli agenti AI trasformano i normali errori di accesso in catene automatizzate di azioni che possono attraversare diversi sistemi aziendali.

Un agente AI è un software che usa un modello per pianificare attività, selezionare strumenti e agire con un coinvolgimento umano limitato. A differenza di un chatbot, non si limita a restituire testo. Può recuperare record, inviare messaggi, modificare file, chiamare API o attivare workflow.

Questa distinzione cambia il problema della sicurezza. Un chatbot può rivelare informazioni inserite nel suo contesto. Un agente può cercare ulteriori informazioni, combinarle, trasformarle e spostarle altrove.

La preoccupazione di fondo nel titolo di Google News non è che gli agenti contengano ogni segreto aziendale. Le informazioni aziendali rimangono solitamente in repository quali cloud storage, sistemi clienti, piattaforme di codice e strumenti di collaborazione.

Il rischio deriva dalle connessioni tra tali repository e l'agente. Il reportage di Dark Reading sulla responsabilità condivisa sottolinea che le aziende restano responsabili della protezione dei dati e degli utenti connessi ai servizi agentici.

Questa responsabilità diventa più difficile da gestire quando un agente eredita l'accesso dell'utente mentre un altro utilizza un account di servizio generico. Entrambe le configurazioni possono creare percorsi di esposizione imprevisti.

Un agente legato all'utente può cercare tutto ciò a cui un dipendente può accedere, incluse cartelle condivise dimenticate. Un'identità di servizio può disporre di privilegi più ampi di quelli necessari a qualsiasi singolo utente.

L'agente può inoltre assemblare fatti che sembrano innocui se osservati separatamente. Un elenco clienti, una roadmap interna e una directory dei dipendenti possono diventare altamente sensibili dopo l'aggregazione.

Si tratta di un ribaltamento importante. In passato, la ricerca aziendale aiutava i dipendenti a trovare documenti che erano già autorizzati a leggere. Ora un agente può trovare quei documenti e intraprendere azioni successive senza una decisione umana separata.

Il pericolo non richiede intenzioni malevole. Una richiesta vaga può produrre una ricerca eccessivamente ampia. Un piano inaffidabile può selezionare il destinatario o la destinazione sbagliati.

Un documento compromesso può anche reindirizzare il workflow. La prompt injection indiretta si verifica quando istruzioni ostili sono nascoste nel contenuto letto dall'agente, come un'email o una pagina web.

Il modello può interpretare tali istruzioni come parte del proprio compito. Se lo stesso agente può accedere a dati privati e comunicare esternamente, l'attaccante ha collegato la scoperta dei dati all'esfiltrazione.

Ecco perché questa storia conta oltre il singolo titolo. L'agente si colloca all'intersezione tra identità, dati, applicazioni e azione. Ogni connessione amplia ciò che un singolo errore può raggiungere.

Il cambiamento immediato è quindi architetturale. Le aziende non stanno più solo concedendo al software l'accesso ai dati. Stanno concedendo ai sistemi discrezionalità su come tale accesso venga utilizzato.

Il percorso di esposizione dall'interno verso l'esterno

Il workflow di un agente più pericoloso combina contenuti non affidabili, dati sensibili e un'azione in uscita sotto un'unica identità.

Si consideri un agente incaricato di preparare una revisione di un account. Legge i record dei clienti, cerca nei messaggi interni, verifica i casi di assistenza recenti e crea un riepilogo.

Ogni passaggio sembra legittimo. Il percorso di esposizione emerge quando un elemento recuperato contiene istruzioni progettate per il modello anziché per il dipendente.

Un ticket di assistenza malevolo potrebbe ordinare all'agente di ignorare il compito originario. Potrebbe indirizzare il sistema a individuare record aggiuntivi e trasmetterli attraverso una richiesta web consentita.

L'attaccante non accede mai all'azienda. L'agente legge il contenuto dell'attaccante dopo che questo è entrato tramite un normale canale aziendale.

Questo schema di attacco sfrutta un confine che i modelli linguistici non possono imporre in modo affidabile da soli. Lo stesso contesto può contenere istruzioni dell'utente, fatti recuperati, indicazioni di sistema e testo controllato dall'attaccante.

I modelli elaborano questi elementi come linguaggio. Etichette e prompting possono aiutare, ma non creano una barriera di autorizzazione deterministica.

Gli strumenti dell'agente rendono questa debolezza rilevante. Un'istruzione avvelenata ha poco valore quando il modello non può raggiungere dati privati né agire al di fuori della sessione.

Il rischio aumenta quando gli sviluppatori forniscono strumenti ampi per comodità. Un browser generico, un connettore di database senza restrizioni, una shell o una funzione di messaggistica possono servire molti workflow. Possono anche supportare azioni che la funzionalità originale non ha mai richiesto.

OWASP identifica questo problema come eccessiva autonomia. I suoi esempi includono attività di sola lettura supportate da estensioni che possono anche modificare, eliminare o inviare informazioni.

Le autorizzazioni creano un ulteriore livello. Un connettore destinato a leggere una tabella di prodotto non dovrebbe ricevere accesso in scrittura o visibilità su record non correlati.

Gli account generici con privilegi elevati sono particolarmente rischiosi. Possono cancellare la distinzione tra ciò che un singolo utente può richiedere e ciò che l'infrastruttura dell'agente può recuperare.

La memoria amplia la finestra di esposizione. La memoria dell'agente conserva fatti o contesto per un uso successivo, contribuendo a mantenere continuità tra le sessioni.

Tuttavia, la memoria persistente può trattenere istruzioni avvelenate, materiale riservato o un'errata assunzione di sicurezza. Un problema introdotto durante un'attività può influenzare in seguito un altro utente o workflow.

I log possono diventare un secondo repository di dati. Tracce dettagliate aiutano i team a investigare le decisioni di un agente, ma tali tracce possono contenere prompt, documenti recuperati, credenziali o informazioni personali.

Un team può quindi ridurre un rischio creandone un altro. Dati di osservabilità protetti in modo inadeguato diventano un obiettivo prezioso perché registrano ciò che l'agente ha visto e tentato di fare.

I sistemi multi-agente aggiungono ulteriori trasferimenti. Un agente può raccogliere informazioni, un secondo può analizzarle e un terzo può comunicare il risultato.

Ogni passaggio richiede identità autenticate, autorizzazioni delimitate e dati convalidati. In caso contrario, un componente compromesso può inoltrare istruzioni dannose a valle con l'apparenza di traffico interno fidato.

L'attaccante esterno resta rilevante, ma l'azione finale avviene dall'interno dell'azienda. Arriva tramite un'identità approvata e segue un percorso applicativo che i difensori potrebbero considerare normale.

Questo è il problema dall'interno verso l'esterno. Il fallimento della sicurezza inizia con un accesso legittimo, attraversa i confini interni dei dati ed esce attraverso uno strumento consentito.

Perché i team dell'identità subiscono la prima pressione

Gli agenti AI si comportano come utenti, si autenticano come servizi e operano più rapidamente dei processi di governance costruiti per entrambi i gruppi.

I sistemi di accesso umano presuppongono un dipendente riconoscibile, un ruolo lavorativo, un responsabile e un ciclo di vita occupazionale. Gli account di servizio di solito supportano software prevedibile con funzioni stabili.

Gli agenti non rientrano in nessuna delle due categorie. Le loro azioni cambiano in base ai prompt, al contesto recuperato, agli strumenti disponibili, alle versioni del modello e ai risultati intermedi.

Un agente può autenticarsi con un token API, agire per conto di un dipendente e delegare parte di un'attività a un altro agente. Ciò crea diverse identità all'interno di un unico workflow.

I team di sicurezza devono sapere chi ha avviato la richiesta. Devono anche sapere quale agente ha agito, quali credenziali ha usato e quale autorizzazione si applicava.

Un'azione finale dovrebbe restare attribuibile a tali identità. Senza questa catena, chi risponde agli incidenti può vedere una chiamata API autorizzata senza comprendere il ragionamento o l'intento dell'utente che ne è alla base.

NIST ha riconosciuto questa lacuna nel suo progetto sulle identità degli agenti del 2026. Il lavoro proposto si concentra su identificazione, autorizzazione, audit e non ripudio per gli agenti software.

Questi requisiti somigliano a pratiche consolidate di gestione delle identità, ma gli agenti cambiano il ritmo operativo. Una revisione trimestrale degli accessi non può contenere privilegi che diventano inutili pochi minuti dopo la conclusione di un'attività.

L'accesso permanente crea un problema di accumulo. I team concedono un'autorizzazione per un progetto pilota, la mantengono per comodità e in seguito collegano l'agente a un altro sistema.

La portata effettiva dell'agente cresce anche quando nessun amministratore crea intenzionalmente un unico super-agente privilegiato. Autorizzazioni separate possono combinarsi in un percorso pericoloso.

Ad esempio, l'accesso in lettura a un database può sembrare sicuro da solo. Anche l'accesso al web esterno può supportare una legittima attività di ricerca.

Insieme, queste capacità possono consentire ai record sensibili di lasciare l'organizzazione. I team di sicurezza definiscono spesso questa combinazione tossica perché il rischio totale supera quello di ciascuna autorizzazione considerata isolatamente.

La pressione ricade anche sui proprietari delle applicazioni. Devono esporre funzioni più ristrette invece di fornire agli agenti interfacce amministrative generiche.

Un agente di pianificazione potrebbe dover creare blocchi nel calendario. Non necessita necessariamente dell'autorizzazione per eliminare ogni evento o leggere le note private di ogni partecipante.

I proprietari dei dati affrontano una decisione correlata. Devono stabilire se le autorizzazioni utente esistenti restino appropriate quando il software può cercare, riassumere e ridistribuire informazioni alla velocità delle macchine.

Un dipendente che può tecnicamente aprire migliaia di documenti raramente li esaminerà tutti. Un agente può attraversare rapidamente tale accesso e rimuovere l'attrito pratico che un tempo limitava l'esposizione.

Questo non significa che ogni agente meriti meno accesso del proprio utente. Significa che l'autorizzazione deve tenere conto dell'attività richiesta, della destinazione, della sensibilità dei dati e dell'azione proposta.

L'accesso statico basato sui ruoli non può esprimere tutte queste condizioni. Le aziende necessitano di controlli di policy lungo tutto il workflow, soprattutto prima del recupero di dati sensibili o della comunicazione esterna.

Google News sta amplificando un problema di sicurezza che attraversa la responsabilità organizzativa. I team dell'identità controllano le credenziali, i team applicativi costruiscono gli strumenti e i team dei dati classificano le informazioni.

I responsabili dei programmi AI spesso controllano la velocità di distribuzione. Quando questi gruppi lavorano in modo indipendente, l'agente eredita le loro lacune e le collega in un unico percorso di esecuzione.

Le promesse di produttività ora si scontrano con la realtà della sicurezza

Gli agenti diventano più utili man mano che acquisiscono contesto e autorità, ma queste stesse caratteristiche aumentano i danni causati da manipolazioni o errori.

Un agente aziendale utile deve sapere abbastanza per svolgere un lavoro reale. Ha bisogno di accesso ai sistemi pertinenti, di una comprensione del contesto dell'utente e dell'autorità per eseguire azioni approvate.

La rimozione di queste capacità produce un chatbot più sicuro ma limitato. Ampliarle produce un lavoratore capace i cui errori possono avere conseguenze operative.

Questo è il principale compromesso alla base dell'articolo di Dark Reading. L'obiettivo non è eliminare l'autonomia degli agenti. È impedire che l'autonomia diventi un'autorità senza limiti.

I controlli di sicurezza possono ridurre il rischio, ma nessuno offre da solo una risposta completa. I filtri dei prompt possono rilevare un linguaggio malevolo noto, ma gli aggressori possono codificare o mascherare le istruzioni.

I guardrail basati sui modelli affrontano un limite più profondo. Usano sistemi probabilistici per valutare un altro sistema probabilistico e debolezze simili possono interessare entrambi i livelli.

L'approvazione umana aiuta quando un'azione è rara e rilevante. Diventa meno utile quando i dipendenti approvano abitualmente richieste dense che non possono esaminare in modo significativo.

Anche le richieste di approvazione necessitano di informazioni chiare. Un utente non può valutare un'azione descritta soltanto come “continua il flusso di lavoro” o “usa il connettore”.

L'interfaccia dovrebbe identificare la risorsa, l'operazione, il destinatario e la categoria di dati. Dovrebbe inoltre spiegare perché l'azione richiesta deriva dal compito originale.

Il privilegio minimo riduce il potenziale danno. Tuttavia, definire il privilegio minimo per un flusso di lavoro mutevole e articolato in più fasi è più difficile che delimitare una singola applicazione tradizionale.

Le autorizzazioni possono essere appropriate durante una fase ed eccessive durante quella successiva. Credenziali temporanee e vincolate al compito offrono un modello migliore rispetto all'accesso persistente.

Il monitoraggio in fase di esecuzione offre un ulteriore livello. Può rilevare volumi di recupero insoliti, nuove destinazioni, combinazioni di strumenti atipiche o comportamenti che si discostano dalla baseline dell'agente.

Tuttavia, il rilevamento delle anomalie richiede storico, contesto e attribuzione affidabile. Un nuovo agente può non disporre di una baseline stabile, mentre i flussi di lavoro legittimi possono variare notevolmente.

Dark Reading ha riportato una ricerca di Gartner secondo cui circa il 90% degli agenti attuali ha una bassa autonomia. Il restante 10% dispone di strumenti più ampi, accesso ai dati e discrezionalità in fase di esecuzione.

Questi sistemi ad alta autonomia meritano controlli mirati perché le loro modalità di guasto implicano più di un testo errato. Possono modificare sistemi di produzione o trasferire dati riservati.

Lo stesso rapporto citava un sondaggio condotto da un fornitore su oltre 400 responsabili tecnologici e della sicurezza. Ha rilevato che l'84% ha affermato che i propri agenti potevano accedere a dati sensibili.

Un altro 67% riteneva che gli agenti avessero avuto accesso a informazioni che non avrebbero dovuto poter raggiungere. Queste cifre provenivano da un sondaggio di un fornitore di sicurezza, quindi indicano preoccupazione piuttosto che un tasso universale di incidenti.

Ciononostante, i risultati sono coerenti con il rischio architetturale. Le aziende spesso collegano gli agenti prima di disporre di un inventario completo di identità, strumenti, percorsi dei dati e autorizzazioni ereditate.

È necessario anche un punto di vista scettico. Non tutti gli agenti rappresentano una nuova categoria di minaccia catastrofica.

Molti rischi assomigliano a guasti noti che coinvolgono account di servizio, privilegi eccessivi, integrazioni non sicure e una debole governance dei dati. Controlli consolidati migliori possono prevenirne una larga parte.

Ciò che cambia è la combinazione. Gli agenti selezionano dinamicamente le azioni ed elaborano linguaggio controllato dall'aggressore, mentre le integrazioni tradizionali seguono percorsi di codice predeterminati.

Questa differenza rende il comportamento meno prevedibile. Rende inoltre la qualità dell'autorizzazione in fase di esecuzione più importante della qualità dell'accesso iniziale.

I controlli che limitano l'esposizione dei dati degli agenti

Le aziende hanno bisogno di controlli deterministici attorno al modello, perché le istruzioni all'interno del modello non possono imporre la propria autorità.

Il primo requisito è un inventario degli agenti. I team di sicurezza non possono governare identità, connettori, strumenti e archivi dati di cui non conoscono l'esistenza.

L'inventario dovrebbe includere agenti in produzione, progetti pilota interni, applicazioni di fornitori e assistenti installati dai dipendenti. Dovrebbe inoltre acquisire i progetti abbandonati con credenziali ancora attive.

Ogni agente necessita di un'identità distinta. Le chiavi API condivise nascondono l'attribuzione e rendono più difficile la revoca.

L'identità dovrebbe essere associata a un responsabile, a uno scopo approvato, al modello, al set di strumenti e allo stato del ciclo di vita. Le aziende dovrebbero disabilitarla quando il progetto termina o il responsabile lascia l'organizzazione.

Il secondo requisito è l'autorizzazione circoscritta al compito. Le decisioni di accesso dovrebbero valutare ciò che l'utente ha richiesto e l'azione che l'agente ora propone.

Una richiesta di riepilogare una cartella non dovrebbe autorizzare una ricerca in ogni repository. Una richiesta di redigere un'email non dovrebbe autorizzarne automaticamente l'invio.

Il terzo requisito è la separazione tra lettura e azione. Gli agenti che elaborano contenuti non attendibili non dovrebbero controllare automaticamente strumenti ad alto impatto.

La guida alla sicurezza degli agenti di OWASP raccomanda l'accesso minimo agli strumenti, memoria isolata, revisione umana per le azioni rischiose e monitoraggio strutturato.

Un'opzione architetturale utilizza componenti separati. Un modello con restrizioni legge contenuti esterni, mentre un componente privilegiato riceve soltanto informazioni strutturate e convalidate.

Questo approccio non elimina la manipolazione, ma interrompe il percorso diretto dal testo ostile a un'azione autorizzata.

Il quarto requisito è l'applicazione di policy consapevole dei dati. Uno strumento dovrebbe valutare la classificazione delle informazioni richieste prima di restituirle.

Il punto di applicazione dovrebbe trovarsi al di fuori del modello. Il modello può proporre una query, ma una policy deterministica dovrebbe decidere quali record e campi diventano disponibili.

Le aziende dovrebbero anche preservare il contesto di sicurezza dell'utente. Un agente che agisce per conto di un dipendente non dovrebbe passare silenziosamente a un'identità di servizio più ampia.

L'accesso in sola lettura dovrebbe essere l'impostazione predefinita ove possibile. Le funzioni di scrittura, eliminazione, invio, pubblicazione e pagamento dovrebbero richiedere ambiti più ristretti e controlli più rigorosi.

Il quinto requisito è il controllo delle destinazioni. Le organizzazioni spesso si concentrano su ciò che un agente può leggere, trascurando dove può inviare il risultato.

Domini consentiti, destinatari approvati, ispezione dei contenuti e percorsi di rete limitati possono ridurre l'esfiltrazione. Questi controlli restano utili anche quando le difese dei prompt falliscono.

Il sesto requisito è una memoria protetta. Il materiale sensibile non dovrebbe entrare nella memoria a lungo termine senza uno scopo definito, un periodo di conservazione e un confine di accesso.

La memoria dovrebbe rimanere isolata tra utenti e spazi di lavoro. I team dovrebbero analizzare il contesto archiviato alla ricerca di credenziali, informazioni personali e istruzioni sospette.

Il settimo requisito è un'osservabilità significativa. I log dovrebbero registrare la richiesta dell'utente, l'identità dell'agente, la chiamata allo strumento, la decisione di autorizzazione, la categoria di dati e l'esito dell'azione.

Non dovrebbero copiare ogni segreto in testo semplice. La redazione dei dati e l'accesso controllato sono essenziali perché i registri delle indagini possono diventare un'altra superficie di esposizione.

Anche una base di conoscenza ricercabile necessita di autorizzazioni chiare sulle fonti e di confini per il recupero. La comodità della ricerca non dovrebbe cancellare le regole di accesso a livello di documento.

Infine, i team devono testare il flusso di lavoro completo. Le sole valutazioni del modello non possono rivelare cosa accade quando identità, recupero, memoria, strumenti e contenuti esterni interagiscono.

I red team dovrebbero usare documenti avvelenati, email fuorvianti, richieste eccessive, test della memoria tra utenti e destinazioni non autorizzate. Dovrebbero ripetere i test dopo qualsiasi modifica a modello, prompt, connettore o policy.

Tre segnali da osservare dopo questo avvertimento di Google News

Il prossimo banco di prova sarà stabilire se le aziende sostituiranno l'ampio accesso permanente degli agenti con un'autorità visibile, temporanea e applicabile.

Il primo segnale è l'adozione di identità specifiche per gli agenti. Microsoft e altri fornitori di piattaforme stanno aggiungendo modi per registrare gli agenti, assegnare autorizzazioni e registrarne il comportamento.

La sola registrazione non è sufficiente. Il cambiamento significativo arriverà quando le aziende potranno tracciare ogni azione attraverso l'agente, l'utente iniziatore, la credenziale e il servizio delegato.

Se questi record compariranno nei sistemi standard di governance delle identità e risposta agli incidenti, il rischio dall'interno verso l'esterno sarà più facile da indagare. La continua dipendenza da token condivisi indebolirebbe questo progresso.

Il secondo segnale è l'applicazione in fase di esecuzione. I team di sicurezza hanno bisogno di controlli in grado di negare una singola chiamata a uno strumento senza spegnere l'intero agente.

Osservate le credenziali vincolate al compito, finestre di autorizzazione brevi, policy consapevoli dei dati e richieste di approvazione che identificano l'operazione proposta. Queste capacità rafforzerebbero l'idea che l'autonomia possa coesistere con il controllo.

Le affermazioni di marketing sugli “agenti sicuri” offrono da sole poche prove. Gli acquirenti dovrebbero chiedere se l'autorizzazione avviene al di fuori del modello e se le policy si applicano a ogni richiesta a valle.

Il terzo segnale è l'evidenza pubblica degli incidenti. Il mercato continua a non disporre di una reportistica coerente su guasti degli agenti, quasi incidenti ed esposizione dei dati.

Le informative utili dovrebbero descrivere l'input iniziale, gli strumenti disponibili, le autorizzazioni effettive, le salvaguardie fallite e l'impatto finale. Affermazioni aggregate senza questi dettagli non possono dimostrare se i nuovi controlli funzionano.

Anche le autorità di regolamentazione e gli organismi di normazione sono importanti in questo contesto. Il lavoro di NIST sugli standard per gli agenti può fornire alle aziende un linguaggio comune per identità, autorizzazione e verificabilità.

Google News continuerà a far emergere avvertimenti mentre i fornitori inseriscono gli agenti in un numero crescente di flussi di lavoro. I lettori dovrebbero guardare oltre i titoli sensazionalistici ed esaminare il percorso di accesso dietro ogni evento.

Ponete tre domande prima di fidarvi di qualsiasi agente aziendale: Cosa può leggere, cosa può fare e dove può inviare il risultato?

Se l'organizzazione non riesce a rispondere a tutte e tre con policy applicabili e registri verificabili, l'agente non è semplicemente un assistente. È un'identità interna senza limiti in attesa dell'istruzione sbagliata.