Agentic denial of service trasforma l’automazione AI in un rischio

Agentic denial of service è il termine usato da Infoblox per indicare un’interruzione in cui gli AI agent consumano risorse, sovraccaricano i sistemi di supporto o eseguono azioni automatizzate dannose. A differenza di un attacco denial-of-service convenzionale, che rende un sistema indisponibile sommergendolo di traffico, questo rischio prende di mira la capacità di un’organizzazione di utilizzare i propri AI agent, la relativa infrastruttura o i servizi che proteggono. L’analisi di Infoblox del 20 ottobre 2026 non documenta alcun incidente ADoS confermato. Gli scenari descritti sono illustrativi, sebbene le tecniche sottostanti siano già catalogate.

Un AI agent è un software in grado di pianificare autonomamente attività, utilizzare strumenti e compiere azioni per raggiungere un obiettivo. In un security operations centre, o SOC, gli AI agent possono raccogliere dati sulle attività degli endpoint, cercare nei record delle identità, consultare la threat intelligence, riassumere le prove e aprire casi di indagine. Un flusso di alert plausibili potrebbe rallentare progressivamente questi workflow, consumare i budget di token che limitano la quantità di testo elaborabile da un sistema AI e lasciare agli analisti code sempre più lunghe. Nell’esempio di Infoblox, diventa più difficile individuare un’intrusione reale, mentre una risposta automatizzata isola la parte sbagliata della rete e disabilita un servizio essenziale per i ricavi. Non è necessario inondare alcun server né che un firewall smetta di funzionare, perché è la stessa automazione difensiva a creare l’interruzione.

La portata potenziale va ben oltre i team di sicurezza. Gli AI agent del service desk possono gestire richieste relative ad account, dispositivi e software, con conseguenze su identità ed endpoint. Gli AI agent di sicurezza possono interagire con sistemi di security information and event management, che raccolgono gli alert, e con strumenti di security orchestration, automation and response, che coordinano le risposte. Possono inoltre accedere a sistemi di endpoint detection, threat intelligence e controlli di sicurezza. Gli AI agent di site reliability engineering e delle operazioni IT possono diagnosticare interruzioni o modificare applicazioni di produzione, capacità di calcolo e percorsi del traffico. Gli AI agent cloud effettuano il provisioning dei workload e gestiscono quote, account, budget e scaling.

Altri AI agent scrivono, testano e distribuiscono codice tramite repository e pipeline di continuous integration e continuous delivery, che automatizzano la creazione e il rilascio del software. Gli AI agent dedicati alla conoscenza interrogano documenti, database e informazioni aziendali sensibili. Gli AI agent per le identità possono modificare directory, sistemi di single sign-on, accessi privilegiati e autorizzazioni. Gli AI agent per le operazioni di rete possono modificare il DNS, il Domain Name System che converte nomi come quelli dei siti web in indirizzi di rete, oltre ai servizi Dynamic Host Configuration Protocol che assegnano le impostazioni di rete, ai sistemi di IP address management, ai firewall e alle route di rete. La loro utilità deriva da questo accesso, ma lo stesso vale per i potenziali danni se vengono manipolati, sovraccaricati o dotati di autorità eccessiva.

Infoblox suddivide ADoS in tre forme. La prima, denial of security, prende di mira il processo investigativo del difensore. Ogni evento apparentemente significativo può attivare AI inference, arricchimento tramite threat intelligence, sandbox analysis, chiamate API, ossia richieste scambiate tra servizi software, utilizzo delle code e revisione umana. L’attaccante può spendere poco per creare ogni evento, mentre il difensore sostiene un costo in ogni fase dell’indagine. Infoblox sostiene che il costo aumenti con ogni evento aggiuntivo e si accumuli man mano che le indagini si approfondiscono. L’obiettivo non è necessariamente mandare in crash un sistema, ma rendere la difesa troppo lenta, costosa o distratta per identificare l’intrusione importante.

Il volume non è l’unica strada. Gli attaccanti potrebbero contaminare le informazioni recuperate da un assistente di sicurezza AI, inducendolo a generare riepiloghi convincenti ma errati. Gli analisti dovrebbero quindi verificare o contestare i risultati dell’automazione, anziché affidarsi a essa per ridurre il proprio carico di lavoro. Si tratta di un problema di integrità dei dati oltre che di capacità, perché l’AI agent può restare disponibile pur producendo conclusioni inaffidabili.

La seconda forma, denial of infrastructure, si verifica quando l’attività degli AI agent sovraccarica dipendenze condivise come DNS, API, risorse cloud, percorsi di rete o altri AI agent. Un AI agent operativo potrebbe tentare ripetutamente la stessa remediation, oppure un input appositamente predisposto potrebbe indurre un orchestrator a distribuire il lavoro a una dozzina di AI agent specializzati, ognuno dei quali richiama strumenti aggiuntivi. Il risultato probabile è un brownout, ossia una situazione in cui un servizio rimane parzialmente disponibile ma diventa lento o inaffidabile. I sintomi possono includere ritardi intermittenti, API soggette a limitazioni e un forte aumento della spesa cloud, invece di un’unica interruzione evidente. Ciò rende l’evento difficile da diagnosticare e ricostruire in seguito.

La terza forma, denial by response, si verifica quando un rimedio automatizzato causa più danni del problema originale. Infoblox cita un’osservazione del team di threat intelligence di Google, secondo cui un attaccante ha pianificato, creato e gestito una campagna di credential harvesting guidata da un AI agent in meno di sei ore. Attacchi più rapidi aumentano la pressione affinché agli AI agent difensivi venga concessa maggiore indipendenza, ma aggiornare una policy di blocco per un indicatore ad alta affidabilità comporta conseguenze molto diverse rispetto a mettere in quarantena un data centre, disattivare il DNS o reimpostare migliaia di credenziali.

Un esempio riguarda un AI agent del service desk che risponde a un’impennata di ticket per accessi non riusciti reimpostando le password e ricreando gli account. Se la vera causa è un’interruzione dell’identity provider, ogni tentativo di riparazione rende più difficile il ripristino. Un attaccante potrebbe creare deliberatamente una confusione simile tramite prompt injection, cioè input progettato per indurre un sistema AI a seguire istruzioni non previste, oppure tramite informazioni contestuali manipolate. Non è necessario che l’AI agent sia esso stesso malevolo. È la sua risposta autorizzata a diventare l’azione dannosa.

Gli elementi fondamentali non sono del tutto nuovi. MITRE ATLAS, una knowledge base dedicata agli attacchi contro i sistemi AI, include denial of AI service, cost harvesting con una sottotecnica per agentic resource consumption e AI-agent tool invocation. L’etichetta ADoS di Infoblox raggruppa queste tecniche attorno ad AI agent dotati di autorità sui sistemi operativi aziendali.

Quattro caratteristiche aumentano la preoccupazione. Le organizzazioni distribuiscono AI agent più velocemente di quanto riescano a censirli. Un singolo AI agent può eseguire migliaia di azioni mentre una persona sta ancora valutando il primo alert. Input economici possono avviare sequenze costose di calcolo, arricchimento e revisione. Poiché gli AI agent pianificano mentre sono in esecuzione e operano oltre i confini organizzativi, un singolo evento può incidere contemporaneamente su sicurezza, networking, servizi cloud, finanze e compliance. Le aziende devono quindi identificare i propri AI agent, limitarne l’autonomia e preservare la visibilità sul loro comportamento man mano che aumentano i deployment.

Infoblox raccomanda di prendere decisioni prima che inizino workflow costosi, osservare il comportamento anziché singoli alert isolati, basare l’automazione su record affidabili di asset e connessioni e stabilire limiti rigorosi.