AI Blue Teaming spiegato: i tre livelli in cui un controllo può effettivamente risiedere

Chiedi a un team di sicurezza dove risiedono le sue barriere di sicurezza per l'AI e la risposta di solito cita un documento di policy, un prompt di sistema o una funzionalità di un fornitore. Nessuno di questi è un controllo. Un controllo è qualcosa che decide, nel momento di un'azione, se l'azione avviene — e per un agente AI ci sono solo tre luoghi che possono decidere: il modello, il gateway che gli sta davanti e l'ambiente che lo circonda. Tutto ciò che un blue team può promettere onestamente deriva dal secondo e dal terzo di questi. Questa è la questione del livello, ed è prioritaria rispetto a ogni altra decisione del blue team, incluso cosa registrare e chi chiamare. È anche il motivo per cui le prove sul campo contano: l'archivio degli incidenti AI contiene 400 incidenti di agenti da 2024-12 al 2026-10-17, e la maggior parte non sono storie di un modello che si comporta male. Sono storie di un deployment senza alcun livello che potesse dire no.

Il blue teaming nel senso dell’IA è il lavoro di inserire quei livelli, calibrare ciò che rilevano e avere una risposta preparata per il giorno in cui uno di essi scatta. È poco glamour, non produce un punteggio ed è l’unica metà della coppia red-team/blue-team che cambia il numero del rischio.

Cosa eredita un blue team e cosa no

Il blue teaming tradizionale si basa su una serie di presupposti che le distribuzioni di IA infrangono silenziosamente. Si presumeva che i log fossero completi, perché la rete vedeva ogni pacchetto. Si presumeva che gli asset fossero enumerabili, perché qualcuno doveva pur provvedere a fornirli. Si presumeva che il comportamento fosse deterministico, perché un programma fa la stessa cosa dato lo stesso input. Nessuno dei tre sopravvive al contatto con un agente.

Ciò che un blue team eredita, invece, è un sistema in cui le decisioni di maggiore impatto avvengono all'interno di una richiesta che il livello di rete tratta come normale traffico HTTPS verso un unico hostname. Il prompt, il contesto recuperato, le chiamate agli strumenti, la completion: tutto si trova dentro il corpo di una richiesta e, se nessuno cattura e analizza quel corpo, la distribuzione è di fatto non monitorata, indipendentemente da quanto sia valido il perimetro. Il primo compito del blue team, quindi, non è il rilevamento; è predisporre un sensore. Senza visibilità a livello di richiesta e a livello di strumento non c'è nulla su cui rilevare, e ogni controllo a valle è decorativo.

Chi può effettivamente far rispettare il controllo

Una volta che c’è un sensore, la questione diventa dove è consentito collocare ciascun controllo. Il modo utile di rappresentarlo è per proprietà anziché per tecnologia, perché è la proprietà a determinare se un controllo sopravvive alla release successiva.

Lo strato del modello appartiene a chi lo ha addestrato. Non lo configuri, non puoi vederne l'interno e il suo comportamento cambia quando il fornitore rilascia una nuova versione — che può arrivare di martedì qualsiasi. Quello che puoi fare è fissare una versione e trattare un cambio di versione come una modifica alla tua postura di rischio che richiede un nuovo test. Quello che non puoi fare è rivendicare un controllo qui. "Il modello rifiuta le richieste dannose" è una proprietà su cui fai affidamento, non un meccanismo che gestisci.

Il livello gateway è il punto in cui ogni prompt e ogni completamento attraversano un componente di tua proprietà. È qui che risiedono i limiti di budget e di frequenza, che vengono applicati gli elenchi di autorizzazione e i permessi degli strumenti, che il logging delle richieste e delle risposte è completo per costruzione, e che una richiesta può essere riscritta, bloccata o reindirizzata prima che venga fatturato qualsiasi token. I controlli del gateway sono anche gli unici che restano attivi quando si cambia modello, il che è più importante di quanto sembri: i team che mettono i propri controlli nei prompt li perdono del tutto il giorno in cui migrano.

Il livello dell'ambiente è quello che è interamente tuo: credenziali e i loro ambiti, l'egress di rete, l'accesso ai file, i limiti della sandbox sul tempo reale e sulla spesa. È anche il luogo in cui un'esecuzione compromessa fa i suoi danni. Un agente indotto ad agire in modo malevolo è pericoloso in esatta proporzione a ciò che l'ambiente ha consentito a quell'azione di raggiungere — e l'ambiente è l'unico posto in cui il "privilegio minimo" è una modifica di configurazione anziché un problema di ricerca.

Il test pratico per qualsiasi controllo proposto sull'IA si riduce a una domanda: quale di questi tre livelli lo applica? Se la risposta è il livello del modello, il controllo è una speranza. Se la risposta è "il system prompt", si tratta di un suggerimento interno al livello del modello, che è peggio di una speranza perché arriva con una documentazione che sostiene il contrario.

Rileva: cosa emette effettivamente un agente

Il rilevamento per gli agenti si basa su un insieme di segnali diverso da quello utilizzato per le persone. Non c'è alcuna anomalia di accesso da correlare. Quello che c'è invece è un flusso di richieste con una struttura insolitamente ricca, e quattro famiglie di segnali su cui vale la pena generare avvisi.

• Volume e forma delle chiamate agli strumenti. Un agente che all'improvviso chiama uno strumento di lettura dei file quaranta volte in un'unica attività, o la cui sequenza di strumenti passa da tre passaggi a trenta, merita uno sguardo — non perché sia malevolo, ma perché la distribuzione si è spostata.

• Provenienza del contenuto al confine. Quale testo nel prompt proviene dall'utente, quale dal recupero, quale da un risultato di uno strumento e quale dalla memoria. La maggior parte del rilevamento di prompt injection si riduce a "testo istruzionale apparso in un canale che dovrebbe veicolare solo dati", e non puoi calcolarlo a meno che il gateway etichetti la provenienza all'ingresso.

• Confini di egress e di ambito. Richieste verso destinazioni al di fuori dell'allow-list, letture di percorsi fuori ambito, tentativi di usare credenziali al di fuori del servizio previsto. Sono segnali ad alta precisione e a basso costo, perché l'ambiente sa già cosa era consentito.

• Spesa e latenza come proxy. Un ciclo impazzito e una compromissione appaiono entrambi come una curva dei costi che cambia pendenza. Gli avvisi di budget sono il rilevamento meno affascinante dello stack e tra i più rapidi a ripagarsi.

Ciò che è deliberatamente assente da quell’elenco è un classificatore incaricato di giudicare se un completamento fosse dannoso. È l’idea di rilevamento a cui i team ricorrono per prima e quella che invecchia peggio: va alla deriva con il modello, ha un tasso di falsi positivi che abitua i tuoi analisti a ignorarla e non ti dà nulla da inserire in un runbook.

Contenere: le tre manopole che fermano una serie negativa

Il contenimento per un agente è più semplice di quanto sembri, perché tre parametri coprono quasi tutto. Budget limita quanto può spendere un'esecuzione, il che circoscrive sia il danno finanziario sia il raggio d'azione di un ciclo. Scope limita ciò che un'esecuzione può toccare — gli strumenti abilitati per quel compito, i percorsi, i tenant. Sandbox limita per quanto tempo può essere eseguita e cosa può raggiungere mentre è in esecuzione. Tutti e tre sono impostazioni del gateway o dell'ambiente, il che è un altro modo per dire che sono applicabili.

Il principio di progettazione che conta è l'ambito per compito anziché l'ambito per agente. Un agente con un insieme di autorizzazioni permanenti è un agente le cui autorizzazioni si accumuleranno finché qualcuno non le verifica; un agente che riceve una credenziale con ambito limitato al compito per la durata di un compito ha un confine che scade da solo. Il secondo è più impegnativo da costruire e molto più economico da difendere.

È anche il luogo in cui un gateway si guadagna il proprio nome. I controlli che risiedono davanti a ogni chiamata al modello — chiamate a strumenti e MCP valutate prima che vengano eseguite, policy dei contenuti e mascheramento dei dati personali applicati prima che la richiesta venga fatturata — sono gli stessi controlli sia che il modello dietro di essi sia quello usato il trimestre scorso sia quello rilasciato la settimana scorsa. Quella continuità è il prodotto vero: non un filtro migliore, ma un luogo in cui il filtro risiede che non si sposta quando si sposta il modello.

Ripristino: riproduci, applica la patch, riesegui il test

Il ripristino in caso di incidenti AI ha un vantaggio rispetto al ripristino in caso di incidenti di rete: l'intera esecuzione viene di solito registrata. Prompt, contesto, chiamate agli strumenti, completamenti, tempistiche — se il gateway li ha registrati, l'incidente può essere riprodotto, che è un punto di partenza più solido di quanto la maggior parte delle analisi forensi riesca a ottenere.

Il Replay assolve a tre scopi in sequenza. Stabilisce ciò che è realmente accaduto, anziché ciò che il verbale suggerisce sia accaduto dopo che diverse persone lo hanno riassunto. Individua il controllo che avrebbe dovuto attivarsi, ovvero la differenza tra correggere un sintomo e correggere un confine. E produce il caso di regressione: un input registrato che ora deve essere bloccato, eseguito sulla nuova configurazione per dimostrare che lo è.

La fase di patching è quella in cui i team blu sbagliano più spesso la mira. Se la rilevazione riguardava un comportamento del modello, le mitigazioni disponibili sono tutte esterne al modello — una riduzione dello scope, un filtro al gateway, un permesso rimosso dall'ambiente. Se la rilevazione riguardava un comportamento di sistema, la correzione è nella configurazione e il test di regressione costa poco. In ogni caso, il retest non è facoltativo, perché sia la correzione sia la versione del modello cambiano, e un controllo verificato rispetto alla build del mese scorso è un'affermazione sul mese scorso.

Fare le prove del giorno in cui scatta

Un runbook che non è mai stato letto sotto pressione è un documento, non una capacità. La prova che vale la pena fare è ristretta e specifica: prendi un plausibile incidente di un agente, seguilo dall'inizio alla fine e cronometra ogni fase. Chi se ne accorge? Quanto tempo passa prima che una persona stia guardando la riga di log giusta? Chi può fermare l'esecuzione — una singola persona identificata, o un comitato? Chi può revocare la credenziale, e quanto tempo impiega la revoca a propagarsi? Chi decide se notificare qualcuno fuori dall'azienda?

Due di quelle domande mettono regolarmente in difficoltà i team. «Chi può fermare l'esecuzione» fallisce quando fermarla richiede qualcuno che sta dormendo, quindi la risposta deve essere un meccanismo anziché una persona — un limite di budget o un interruttore di emergenza che un ingegnere di turno possa azionare da solo. «Quanto tempo richiede la revoca» fallisce perché le credenziali sono spesso memorizzate nella cache in componenti che non erano nel diagramma.

Leggere l'archivio è la forma più economica di simulazione disponibile, perché ti consente di ereditare la struttura degli incidenti altrui invece di inventarne una tua. Prendi una manciata di voci simili al tuo deployment e, per ciascuna, poni le tre domande sopra. Le voci per cui non riesci a rispondere sono le lacune nel tuo runbook, e le hai trovate prima dell'incidente anziché dopo.

L'asimmetria che vale la pena dichiarare apertamente

Il red teaming e il blue teaming non sono attività simmetriche e non si dovrebbe destinare loro un budget come se lo fossero. Un ciclo di red team è vincolato a un calendario e produce una serie di riscontri che perdono validità al variare del target. I controlli di un blue team persistono, si cumulano e sono l'unica cosa che si frappone davvero tra un input dannoso e un esito negativo. Un ingaggio può individuare un confine; solo l'altro può difenderlo.

Il che rende lo standard onesto per un blue team poco glamour e verificabile. Per ogni controllo che dichiari, dovresti essere in grado di indicare il livello che lo applica, la riga di log che prova che è scattato, l’avviso che ti dice quando non è scattato e la persona che può disattivare l’esecuzione. Quattro frasi. Se una di esse manca, il controllo è un documento di policy, e i documenti di policy non leggono i corpi delle richieste.