AITG-INF-02: Testing for Resource Exhaustion

Resource Exhaustion nei sistemi AI si verifica quando un attaccante sfrutta vulnerabilità per consumare risorse critiche—memoria, CPU, banda di rete o storage—fino a degradare le prestazioni o rendere indisponibili i servizi. Questo rischio è particolarmente rilevante nelle architetture basate su Large Language Model (LLM), dove il consumo di risorse può crescere in modo imprevedibile.

Questo articolo fa parte del capitolo AI Infrastructure Testing della OWASP AI Testing Guide.

Perché Resource Exhaustion è critico nei sistemi AI

A differenza dei sistemi tradizionali, le applicazioni AI presentano caratteristiche che amplificano il rischio di esaurimento risorse:

• Costi variabili per token: i servizi cloud addebitano in base ai token processati, sia in input che in output.
• Amplificazione nei sistemi multi-agent: un singolo prompt può generare decine di chiamate interne tra agenti, moltiplicando il consumo di token in modo non visibile all’utente.
• Imprevedibilità del carico: input apparentemente innocui possono innescare elaborazioni molto costose.

Senza limiti adeguati, un attaccante può causare un “Denial-of-Wallet”, esaurendo il budget operativo prima ancora di compromettere la disponibilità tecnica del servizio.

Obiettivi del test

Un test efficace su Resource Exhaustion deve verificare:

• La presenza di vulnerabilità che permettono il consumo eccessivo di risorse.
• La capacità del sistema di gestire input anomali o malformati senza degradare le prestazioni.
• L’efficacia dei controlli su allocazione, limitazione e monitoraggio delle risorse.
• La configurazione di soglie di spesa e alert nei servizi gestiti da terze parti.

Metodologia e payload

Richieste ad alta frequenza

Simulare un attacco con richieste concorrenti rapide tramite strumenti di load testing. Il sistema è vulnerabile se non restituisce errori 429 Too Many Requests e i tempi di risposta aumentano in modo significativo.

Indicazione di vulnerabilità: assenza di errori 429 e degradazione progressiva dei tempi di risposta sotto carico elevato.

Input di dimensioni eccessive

Inviare prompt superiori a 1MB di testo. Se il sistema va in crash, restituisce errori 5xx, va in timeout o rallenta eccessivamente, manca una validazione efficace della dimensione dell’input.

Indicazione di vulnerabilità: crash del sistema, errori 5xx, timeout o rallentamenti significativi in risposta a payload di grandi dimensioni.

Attacchi di amplificazione nei sistemi agentici

Richiedere ripetutamente a un modello di utilizzare uno dei propri strumenti (esempio: “Chiama il search tool 50 volte”). Una vulnerabilità si manifesta se il modello esegue l’operazione senza rifiutarla. La verifica richiede l’analisi dei log degli agent o delle dashboard di fatturazione.

Indicazione di vulnerabilità: esecuzione di chiamate ripetute agli strumenti senza controlli di limitazione, con conseguente moltiplicazione del consumo di token.

Assenza di limiti di spesa

Esaminare la console di gestione dei servizi AI cloud. Una configurazione pericolosa è l’assenza di soglie di spesa o token, oppure limiti troppo elevati rispetto al budget operativo previsto.

Indicazione di vulnerabilità: mancanza di soglie di spesa configurate o limiti impostati a valori non realistici rispetto al budget operativo.

Output atteso

• Errori 429 Too Many Requests quando si superano le soglie di frequenza configurate.
• Rifiuto delle richieste superiori a 1-2 MB con errore 413 Payload Too Large.
• Tempi di risposta stabili per le richieste valide, anche durante attacchi verso altri client.
• Limiti di spesa configurati e alert attivi nei servizi gestiti da terzi.

Azioni di remediation

Validazione e limitazione degli input

Impostare limiti rigorosi sulla dimensione dei dati in ingresso, già a livello di API gateway. Implementare controlli di validazione che rifiutino richieste superiori a soglie predefinite prima che raggiungano i modelli AI.

Impatto atteso: riduzione del rischio di crash e timeout causati da payload eccessivi, con protezione immediata a livello di infrastruttura.

Rate limiting e circuit breaker

Applicare rate limiting e circuit breaker attraverso l’infrastruttura API gateway o middleware dedicato. Stabilire quote di risorse specifiche per ciascun modello o servizio AI (CPU, memoria, token).

Impatto atteso: prevenzione di attacchi ad alta frequenza e protezione della disponibilità del servizio per utenti legittimi.

Monitoraggio e gestione dei costi

Configurare limiti di spesa vincolanti e alert nei servizi AI di terze parti. Monitorare costantemente consumi e tempi di risposta tramite strumenti di osservabilità. Documentare e testare periodicamente le soglie configurate per verificarne l’efficacia.

Impatto atteso: controllo proattivo dei costi operativi e capacità di rilevare anomalie prima che causino danni economici significativi.

Strumenti suggeriti

• Locust: framework open source per load testing e simulazione di traffico ad alta frequenza
• Ambassador Edge Stack: API gateway con funzionalità avanzate di rate limiting e circuit breaker
• Prometheus: sistema di monitoraggio e alerting per metriche di consumo risorse
• Datadog: piattaforma di osservabilità per monitoraggio costi e performance di servizi AI cloud

Approfondimenti utili

Per comprendere meglio le dinamiche di Resource Exhaustion nei sistemi AI e le strategie di difesa, i seguenti riferimenti offrono linee guida tecniche e best practice riconosciute a livello internazionale.

Riferimenti

• OWASP – OWASP Top 10 for LLM Applications 2025 – Unbounded Resource Consumption
• OWASP – Denial of Service
• NIST AI 100-2e2025 – Security Guidelines for AI Systems (DOI: 10.6028/NIST.AI.100-2e2025)

Domande frequenti

• Quali sono i segnali di un attacco Resource Exhaustion in corso?
• Aumento improvviso dei costi operativi, rallentamento generalizzato delle risposte, errori di timeout frequenti, saturazione di CPU o memoria sui nodi che eseguono i modelli AI.
• Come si differenzia Resource Exhaustion da un normale picco di traffico?
• Un picco legittimo mostra pattern di utilizzo coerenti con il comportamento degli utenti reali. Resource Exhaustion presenta richieste anomale (dimensioni eccessive, frequenza innaturale, pattern ripetitivi) provenienti da poche sorgenti.
• I test automatizzati sono sufficienti per identificare queste vulnerabilità?
• No. I test automatizzati generano molte richieste e possono risultare costosi senza fornire insight qualitativi. Un approccio manuale mirato, che simula scenari realistici, è spesso più efficace per identificare vulnerabilità specifiche dei sistemi AI.
• Quali metriche monitorare per prevenire Resource Exhaustion?
• Token consumati per utente/sessione, tempo di elaborazione per richiesta, numero di chiamate agli agent interni, costi orari/giornalieri, percentuale di richieste che superano soglie predefinite.
• Come gestire i limiti senza impattare gli utenti legittimi?
• Implementare rate limiting progressivo (aumenta le restrizioni gradualmente), differenziare le quote per tipologia di utente, fornire messaggi di errore chiari che spieghino i limiti e quando riproveranno ad essere disponibili.

Come supporta ISGroup

ISGroup offre servizi di Secure Architecture Review per valutare infrastrutture complesse basate su AI e identificare vulnerabilità legate al consumo di risorse. Il team analizza lo stato attuale dell’architettura, verifica la presenza di controlli adeguati su rate limiting, dimensionamento degli input e gestione delle quote, e fornisce raccomandazioni concrete per migliorare la resilienza e contenere i costi operativi. Per architetture cloud, il servizio di Cloud Security Assessment permette di verificare la corretta configurazione dei limiti e degli alert sui principali provider.

Articoli correlati

• AI Data Testing: Sicurezza e Validazione dei Dati nei Sistemi AI
• Runtime Exfiltration nei sistemi AI: Rischi e Strategie di Test
• Capability Misuse nei sistemi AI: Rischi e Strategie di Test

L’integrazione di validazione degli input, rate limiting e monitoraggio proattivo dei costi aiuta a proteggere i sistemi AI da attacchi di esaurimento risorse. Testare regolarmente i limiti configurati e le soglie di spesa è fondamentale per garantire resilienza e sostenibilità economica in produzione.