La scoperta di una vulnerabilità di prompt injection di secondo ordine nel sistema Now Assist di ServiceNow riaccende il dibattito sulla sicurezza negli ecosistemi AI enterprise, mostrando come le interazioni automatiche tra agenti AI possano trasformarsi in vettori di attacco non intenzionali. Nel primo periodo emerge che configurazioni predefinite, agent discovery abilitata e team condivisi consentono a un agente AI di leggere prompt maliziosi inseriti in campi non controllati, usare i propri privilegi elevati e reclutare altri agenti per eseguire azioni non autorizzate. La ricerca evidenzia che il problema non risiede nei modelli linguistici in sé, ma nelle misconfigurazioni che governano la collaborazione tra agenti, con ServiceNow che conferma il comportamento come “intenzionale” e AppOmni che risponde introducendo AgentGuard, un sistema di monitoraggio comportamentale in tempo reale. L’episodio dimostra come la governance dei sistemi AI debba andare oltre la protezione dei prompt per includere gestione dei privilegi, isolamento dei team e supervisione degli strumenti.
Cosa leggere
Cos’è la scoperta tra agenti in Now Assist
La scoperta tra agenti costituisce una capacità unica di Now Assist che permette agli agenti AI di comunicare tra loro senza necessità di workflow sequenziali. Gli agenti collaborano automaticamente quando non possono completare un compito da soli, una caratteristica abilitata da configurazioni predefinite associate al team e al canale di lavoro. In questa architettura, il modello linguistico – che può essere il Now LLM o un modello Azure OpenAI – consente la scoperta automatica di agenti appartenenti allo stesso gruppo. La pubblicazione di un agente lo rende immediatamente discoverable dal team, e l’integrazione tra AiA ReAct Engine e Orchestrator consente di delegare sub-task e identificare quali agenti possano fornire capacità aggiuntive. Questa fluidità migliora la user experience, ma crea anche un ambiente dove agenti con livelli di privilegio diversi convivono e possono essere attivati senza consapevolezza amministrativa. La scoperta automatica, se non isolata, apre superfici di attacco impreviste, perché gli agenti leggono e reagiscono a dati che possono contenere comandi impliciti non inseriti dall’utente che attiva l’azione.
Perché la scoperta tra agenti espone a rischi reali
Il rischio chiave deriva da una forma di prompt injection di secondo ordine, in cui l’attaccante non interagisce con l’agente privilegiato ma con un agente apparentemente innocuo. Un agente benigno legge un campo malizioso nella descrizione di un record e, rispettando la logica dell’Orchestrator, coinvolge altri agenti del team per completare il compito. Poiché ogni agente opera con i privilegi dell’utente che ha avviato il processo, e non con quelli di chi ha inserito il prompt malizioso, si crea un divario che permette di accedere, modificare o esfiltrare dati che l’attaccante non sarebbe autorizzato a vedere. Questo include lettura di record sensibili, modifiche non autorizzate e persino privilege escalation tramite assegnazione di ruoli. Gli attacchi sfruttano tool CRUD o funzioni email associate agli agenti privilegiati del team. Le protezioni di ServiceNow contro le prompt injection classiche rimangono operative, ma non rilevano comandi impliciti in campi testuali processati da agenti intermedi. Configurazioni di default e team eccessivamente inclusivi amplificano il rischio.
Scenario di attacco esemplificativo
La ricerca presenta un caso concreto che mostra la dinamica. Un amministratore dispone due agenti OOTB in un canale accessibile solo al ruolo admin: uno specializzato in categorizzazione incidenti e uno con funzioni CRUD su tabelle derivate da task. Un utente low-privileged crea il ticket INC0000002 e inserisce nella descrizione un prompt malizioso che ordina di leggere la descrizione del ticket INC0000001 – a cui non ha alcun accesso – e copiarla nel ticket corrente. L’agente incaricato legge il prompt, consulta l’Orchestrator per identificare il tool appropriato e, utilizzando i privilegi dell’admin, accede al ticket protetto INC0000001. Copia le informazioni sensibili in INC0000002 e completa l’operazione. L’utente low-privileged riesce così a visualizzare dati che le ACL gli vieterebbero. Lo scenario si estende a casi più gravi: assegnazione di ruoli admin, invio di email a indirizzi controllati dall’attaccante, alterazioni record trasversali. L’attacco è silente, poiché il prompt è letto non direttamente dall’amministratore ma dall’agente che esegue ciò che interpreta come un’istruzione lecita.
Dettagli tecnici dell’attacco di secondo ordine
Il funzionamento interno dell’attacco evidenzia la concatenazione dei componenti della piattaforma. L’utente con privilegi minimi inserisce un contenuto testuale apparentemente innocuo. Quando l’amministratore avvia l’agente sul ticket, il sistema di orchestrazione interpreta il prompt come una richiesta operativa. La AiA ReAct Engine delega all’Orchestrator la selezione degli agenti più competenti. L’agente privilegiato accede ai dati protetti, li elabora e li inserisce nel ticket dell’attaccante. Le protezioni di ServiceNow non rilevano il comando perché il prompt non viene fornito direttamente dall’utente con privilegi admin, ma viene letto come parte del workflow dell’agente. L’attacco avviene in background, in modo trasparente agli occhi dell’amministratore. La dinamica mostra come la sicurezza basata sul controllo del prompt sia insufficiente in presenza di tool autonomi che operano con privilegi elevati. Le configurazioni predefinite, come agent discovery aperta e team condivisi, creano un’area di rischio che richiede un approccio di governance rigoroso.
Configurazioni chiave da correggere per mitigare i rischi
La mitigazione dipende quasi interamente da una corretta configurazione degli agenti e dei loro team. Le organizzazioni devono disattivare qualsiasi modalità che permetta ai tool di operare senza supervisione. La proprietà sn_aia.enable_usecase_tool_execution_mode_override, se impostata su true, consente tool autonomi: mantenerla su false evita esecuzioni automatiche incontrollate. L’isolamento dei team rappresenta un altro fattore critico: agenti con capacità CRUD o privilegi elevati devono essere collocati in team ristretti e non devono condividere canali con agenti benigni. La discovery va abilitata solo dove necessario, evitando configurazioni che rendono tutti gli agenti discoverable per default. Le operazioni critiche, incluse email o modifiche record, devono richiedere esplicita approvazione. Questo riduce la superficie d’attacco e impedisce reclutamenti automatici tra agenti con privilegi divergenti.
Monitoraggio di comportamenti sospetti negli agenti AI
La complessità della comunicazione tra agenti rende difficile identificare anomalie senza strumenti dedicati. AgentGuard, sviluppato da AppOmni, abilita un monitoraggio in tempo reale del comportamento degli agenti, analizzando la coerenza tra task richiesti e strumenti utilizzati. La soluzione osserva sequenze di azioni, controlla i passaggi logici e segnala qualsiasi deviazione dai pattern normali, come l’uso inatteso di tool CRUD o operazioni cross-record. Questo approccio consente di rilevare tentativi di prompt injection di secondo ordine prima che si traducano in breach effettivi. AgentGuard offre visibilità contestuale migliorata, fornendo dettagli utili per correggere configurazioni rischiose, rilevare escalation di privilegi e prevenire accessi non autorizzati. In un ecosistema che vede la proliferazione di agenti autonomi, il monitoraggio si rivela essenziale per mantenere allineamento e integrità.
Implicazioni per la sicurezza AI nelle aziende
La ricerca dimostra che la sicurezza AI non si limita al filtraggio del prompt o alla robustezza del modello linguistico. I sistemi enterprise basati su agenti multipli introducono nuove superfici d’attacco attraverso misconfigurazioni, team condivisi e tool autonomi. Con l’aumento dei deploy e l’integrazione sempre più stretta tra agenti e workflow aziendali, cresce l’esigenza di audit periodici, monitoraggio continuo e governance evoluta. Le organizzazioni devono valutare la propria postura ServiceNow considerando non solo i rischi di prompt injection diretta, ma anche i rischi indiretti generati dalle interazioni tra agenti. Framework dedicati, assessment di sicurezza e strumenti come AgentGuard permettono di identificare e correggere vulnerabilità prima che producano impatti concreti, contribuendo a una gestione responsabile dell’AI enterprise.
