Guardrail dell'agente mappati al NIST AI RMF

Perché ho costruito AgentGuard

Ho iniziato AgentGuard dopo aver visto un team rilasciare un agente alimentato da che poteva leggere un database, chiamare un'API di pagamento e inviare email, tutto con un singolo prompt. L'agente funzionava nella demo, ma un semplice errore di battitura nella query dell'utente lo ha portato a trasferire denaro al conto sbagliato. Nessuno aveva controllato cosa l'agente fosse autorizzato a fare prima della chiamata e non c'era modo di fermarlo una volta che l'errore era accaduto.

Mi sono reso conto che il problema non era il modello stesso, ma i limiti mancanti intorno alle sue azioni. Volevo un modo ripetibile per elencare ogni strumento che un agente può raggiungere, decidere chi può abilitare ogni strumento, testare l'agente contro le autorizzazioni che pensiamo abbia e reagire quando qualcosa va storto. Il framework di gestione del rischio dell'intelligenza artificiale di NIST mi ha dato le quattro funzioni che si allineano esattamente con quei passaggi.

Concetti fondamentali: filtri di input, autorizzazioni degli strumenti, controlli di output

Filtri di input

Si tratta di controlli che vengono eseguiti sul prompt dell'utente o sul ragionamento interno dell'agente prima che uno strumento venga richiamato. Esempi includono:

- Rilevamento di modelli di iniezione di prompt che tentano di ignorare le istruzioni precedenti. - Controllo di parole chiave o frasi non consentite che segnalano una richiesta di accesso a un sistema restrittivo. - Convalida che il prompt contenga un token di approvazione richiesto quando viene fatto riferimento a uno strumento ad alto rischio.

Implementiamo i filtri di input come motori di regex leggeri combinati con una piccola lista di pattern sicuri. Aggiungono meno di due millisecondi di latenza per chiamata.

Autorizzazioni degli strumenti

Le autorizzazioni degli strumenti definiscono quali dati uno strumento può leggere, scrivere o eliminare e quali servizi esterni può contattare. Memorizziamo ogni autorizzazione come una tupla:

- Identificatore dello strumento - Fonti di dati consentite (ad esempio, accesso in sola lettura alla tabella dei clienti, accesso in scrittura al registro di audit) - Destinazioni di rete (ad esempio, api.paymentprovider.com sulla porta 443) - Livello di approvazione richiesto (nessuno, revisione paritaria, firma del manager)

Quando l'agente chiede di utilizzare uno strumento, il servizio di autorizzazione controlla la tupla contro il contesto attuale e consente la chiamata, modifica i parametri o la blocca.

Controlli di output

Dopo che uno strumento restituisce un risultato, i controlli di output verificano che la risposta rimanga entro i limiti previsti. Esempi:

- Assicurarsi che una query SQL restituisca non più di 100 righe. - Confermare che un payload di posta elettronica non contenga URL esterni. - Scansione per secreti perduti come chiavi API o password nella risposta.

Se un controllo ha esito negativo, il sistema può troncare il risultato, oscurare bit sensibili o attivare un allarme.

Mappatura dei guardrail alle funzioni del framework NIST AI RMF

Il framework presenta quattro funzioni che forniscono una struttura chiara per organizzare il lavoro dei guardrail. Di seguito è riportata una tabella che mostra a quale funzione appartiene ogni guardrail, l'artefatto concreto che produciamo e un breve esempio.

Funzione NIST | Tipo di guardrail | Artefatto | Esempio Govern | Flusso di approvazione | Registro di abilitazione degli strumenti | Un documento firmato che elenca chi ha approvato lo strumento send_email, la data e l'autenticazione a più fattori richiesta per l'approvatore. Map | Inventario degli strumenti | Matrice dei permessi | Un foglio di calcolo che elenca ogni strumento, i dati che può leggere/scrivere e gli endpoint esterni che può chiamare. Measure | Suite di test | Set di prompt avversariali | Una raccolta di prompt progettati per attivare l'escalation di privilegi, l'esfiltrazione di dati o chiamate esterne non autorizzate. Manage | Risposta in fase di esecuzione | Registro del kill-switch | Un entry con timestamp che registra quando l'agente ha tentato di eliminare un record di produzione, l'azione che è stata bloccata e l'operatore che è stato notificato.

Ogni funzione si basa sulla precedente. Govern decide chi può aggiungere un nuovo strumento all'inventario. Map crea l'inventario che Measure testerà. Measure produce prove che Manage può utilizzare.

Come valutiamo una chiamata di strumento

Fase 1: Identificare lo strumento e la sua classe di autorizzazione

Iniziamo cercando lo strumento nella matrice di autorizzazioni. La matrice assegna un livello di rischio di base:

- Ricerca in sola lettura (ad esempio, recupero di un catalogo di prodotti) → basso - Scrittura su un registro interno → medio - Azione esterna con effetti collaterali (ad esempio, invio di denaro, cancellazione di un record) → alto

Se lo strumento richiede un token di approvazione, aggiungiamo un livello al rischio di base.

Fase 2: Analizzare il prompt per il rischio di iniezione

Eseguiamo il prompt dell'utente attraverso il motore di filtro dell'input. Se il motore rileva un pattern dalla scheda di truffe di iniezione di prompt di OWASP (https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html) aumentiamo il rischio di un livello.

Fase 3: Verificare la sensibilità dei dati

Esaminiamo le fonti di dati che lo strumento può toccare. Se alcuna fonte contiene informazioni personali identificabili (PII) o dati finanziari, aggiungiamo un altro livello.

Fase 4: Produrre la valutazione finale e i filtri suggeriti

La valutazione finale è la somma del livello di base, del livello del prompt e degli aggiustamenti del livello dei dati. In base alla valutazione, raccomandiamo:

- Bassa → nessun filtro aggiuntivo, solo registrare la chiamata. - Media → aggiungere un filtro di input che rimuova le parole chiave non consentite e un controllo di output che limiti il numero di righe. - Alta → richiedere un approvazione umana, applicare una lista di parametri consentiti e abilitare la redazione completa dell'output.

Cosa questo non è

Voglio essere chiaro sui limiti delle guardrails in modo che non le confondiate con una soluzione miracolosa.

- Le guardrails non garantiscono che un agente non causerà mai danni. Riducono il raggio d'azione di un errore, ma un attaccante determinato o uno strumento mal configurato può ancora produrre effetti indesiderati all'interno del limite consentito. - Non sono un sostituto delle pratiche di codifica sicure. Se lo strumento sottostante ha una vulnerabilità (ad esempio, una falla di iniezione SQL descritta nella scheda di riferimento https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html), la guardrail non può risolvere quel difetto. - Non forniscono una certificazione di sicurezza al 100 %. Pensatele come strumenti di supporto alle decisioni che aiutano a prendere scelte informate sull'utilizzo degli strumenti. - Non sono una configurazione set-and-forget.

Mettersi in pratica: un flusso di lavoro di revisione passo dopo passo

1. Raccogliere il prompt di sistema dell'agente e l'elenco degli strumenti

Esportare il testo esatto che l'agente riceve all'avvio e il file JSON o YAML che dichiara ogni strumento che può chiamare.

2. Popolare la matrice delle autorizzazioni

Per ogni strumento, registrare:

- Obiettivi di lettura consentiti - Obiettivi di scrittura consentiti - Endpoint esterni e autenticazione richiesta - Eventuali token di approvazione o ruolo necessari

3. Eseguire la valutazione del rischio di base

Applicare il processo di valutazione a quattro passaggi descritto in precedenza. Registrare il livello di rischio iniziale per ogni strumento.

4. Generare suggerimenti per i filtri di input e output

Sulla base del livello di rischio, produrre regole di filtro concrete (modelli di regex, limiti di numero di righe, regole di oscuramento). Memorizzarle accanto alla definizione dello strumento.

5. Eseguire la suite di test avversariali

Eseguire l'agente con il set di prompt dalla colonna Misura del tabella. Verificare che i filtri bloccano o mitigano i modi di guasto attesi.

6. Documentare l'esito

Creare un breve report che elenchi:

- Nome dello strumento - Valutazione del rischio iniziale - Filtri applicati - Risultati dei test (superato/non superato) - Eventuali passaggi di approvazione manuale richiesti

7. Configurare il monitoraggio e gli avvisi

Configurare l'ambiente di runtime dell'agente per registrare ogni chiamata di strumento, i filtri applicati e i risultati del controllo di output. Inoltrare le anomalie al canale di risposta agli incidenti.

8. Pianificare un trigger di revisione

Contrassegnare il flusso di lavoro per ripetersi quando si verificano una delle seguenti condizioni:

- Uno nuovo strumento viene aggiunto all'elenco - Il prompt di sistema viene modificato - Le autorizzazioni di uno strumento cambiano (ad esempio, un database acquisisce una nuova colonna con PII)

Errori comuni e come li evitiamo

Errore 1: eccessiva dipendenza da un unico tipo di filtro

I team a volte pensano che aggiungere un blocco delle parole chiave sia sufficiente. Noi contrastiamo questo requisito richiedendo controlli sia in ingresso che in uscita per qualsiasi strumento a rischio medio o alto, e registriamo quando uno di questi controlli si attiva.

Errore 2: dimenticare di aggiornare la matrice dei permessi

Quando uno strumento acquisisce una nuova funzionalità (ad esempio, un'API di pagamento ora supporta i rimborsi), la matrice deve essere modificata prima che l'agente possa utilizzarlo. Noi applichiamo questo requisito rendendo la matrice un file controllato dalle versioni che il pipeline CI convalida ad ogni push.

Errore 3: ignorare gli strumenti a basso rischio che diventano ad alto rischio nel contesto

Un'operazione di sola lettura che restituisce l'indirizzo e-mail di un utente può diventare pericolosa se l'agente utilizza successivamente quell'indirizzo in un flusso di reimpostazione della password. Noi trattiamo la sensibilità dei dati come un fattore di valutazione separato, quindi uno strumento di basso livello che tocca informazioni personali viene automaticamente aggiornato.

Errore 4: saltare il passaggio dell'intervento umano per gli strumenti ad alto rischio

Per gli strumenti che possono spostare denaro o eliminare record, noi richiediamo un passaggio di approvazione esplicito che non può essere bypassato dall'automazione. L'approvazione viene registrata in un registro immutabile.

Errore 5: trattare la configurazione delle barriere di sicurezza come un compito una tantum

Noi incorporiamo il flusso di lavoro di revisione nella definizione di done del team per qualsiasi funzionalità che modifica il comportamento dell'agente. Ciò rende il processo ripetibile piuttosto che un elemento di controllo dimenticato.

Riferimenti

- https://genai.owasp.org/llmrisk/-prompt-injection - https://owasp.org/www-project-top-10-ci-cd-security-risks/CICD-SEC-06-Insufficient-Credential-Hygiene - https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html - https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html

Domande frequenti

I guardrail rendono un agente sicuro?

No. Limitano il raggio di azione di un errore. Un attaccante determinato, uno strumento non correttamente configurato o una richiesta non valida possono ancora causare danni all'interno del limite che si è consentito.

Cosa ci serve per eseguire una revisione?

La richiesta di sistema dell'agente e l'elenco degli strumenti. Questo è sufficiente per valutare le chiamate e suggerire filtri.

La mappatura del regolamento UE sull'IA è un parere legale?

No. È una mappatura per aiutarti a trovare gli obblighi giusti. La classificazione del tuo sistema e il rispetto degli obblighi richiedono ancora un revisore qualificato.

Con quale frequenza dovremmo rieseguire la revisione?

Ogni volta che l'elenco degli strumenti, la richiesta di sistema o i dati a cui uno strumento può accedere cambiano.

Verifica l'agente in fase di esecuzione?

Esamina la richiesta e la configurazione degli strumenti. Il monitoraggio in fase di esecuzione è un livello separato che si deve ancora utilizzare.

Cosa succede se uno strumento è realmente ad alto rischio?

Richiedi un passaggio di approvazione, restringi i suoi parametri e registra ogni invocazione. Gli strumenti ad alto rischio richiedono generalmente un intervento umano piuttosto che un filtro.

Riferimenti

- OWASP — Top 10 per Applicazioni di Modelli Linguistici di Grande Portata

2026-09-20 · solo fonti primarie · nessuna metrica di traffico fabbricata · supporto alle decisioni solo con AgentGuard

Articoli correlati

- Le liste di controllo degli strumenti degli agenti di intelligenza artificiale: perché il deny-by-default vince - Esplora la matrice completa degli argomenti di micro-SaaS di intelligenza artificiale →