Elenco di strumenti consentiti per gli agenti AI: perché il metodo deny-by-default vince

Perché il deny-by-default funziona meglio del tentativo di bloccare ogni cattiva chiamata

Quando si inizia con un approccio deny-by-default, si deve solo pensare a ciò di cui l'agente ha realmente bisogno. Ogni altra chiamata viene fermata automaticamente, senza dover prevedere ogni possibile abuso. Ciò riduce il carico mentale sul revisore e diminuisce la possibilità che una dimenticanza pericolosa sfugga.

Considera un agente che scrive report. Ha bisogno di leggere un file modello, estrarre dati da un database e inviare il PDF finito a una casella di posta interna. Se si elencano solo quelle tre chiamate, ogni tentativo di eseguire un comando shell, interrogare un'API esterna o eliminare una tabella viene negato istantaneamente. Non è mai necessario scrivere una regola che dica 'blocca rm -rf', 'blocca curl su evil.com' o 'blocca DROP TABLE'. La regola deny-by-default copre tutti questi casi.

Nella pratica, ho visto team spendere settimane per costruire lunghe liste di blocco che comunque non riescono a coprire un nuovo vettore di attacco, mentre un breve elenco di cinque elementi consentiti ha fermato gli stessi attacchi fin dal primo giorno. Il risparmio di sforzo nella manutenzione è reale: si revisiona l'elenco dei consentiti quando uno strumento cambia, non quando appare una nuova minaccia.

Come costruisco un elenco di controllo per un nuovo agente

Seguo una checklist ripetibile che mantiene l'elenco compatto e verificabile.

- Scrivo le mansioni esatte che l'agente deve eseguire oggi. Ignoro le idee "potrebbero essere utili in futuro".

- Per ogni mansione, trovo lo strumento singolo che esegue il lavoro con i parametri più stretti possibili. Se uno strumento offre una flag che allarga la portata, non la attivo a meno che la mansione non lo richieda esplicitamente.

- Registro il nome dello strumento, il comando esatto o l'endpoint dell'API e i valori dei parametri consentiti in un file YAML semplice. Questo file si trova accanto al codice dell'agente in modo che i revisori possano vederlo a colpo d'occhio.

- Eseguo l'agente in una sandbox e verifico che ogni chiamata elencata abbia esito positivo e che ogni chiamata non presente nel file restituisca un errore.

- Chiedo a un collega di rivedere l'elenco. Il lavoro del revisore è confermare che ogni voce corrisponda a una mansione reale e che non ci siano capacità extra nascoste dietro i valori predefiniti.

- Archivio il file nel controllo di versione. Etichetto ogni commit con la versione dell'agente in modo da poter tracciare quale elenco di controllo è stato spedito con quale versione.

- Configuro un passaggio di CI che fa fallire la build se il file YAML è mancante o se contiene uno strumento non approvato nel registro degli strumenti del progetto.

Questo processo mi richiede circa un'ora per un agente semplice e produce un documento che chiunque può verificare.

Classificare gli strumenti in base a cosa possono modificare

Non tutti gli strumenti presentano lo stesso livello di rischio. Ho suddiviso gli strumenti consentiti in tre classi di impatto in modo da sapere dove aggiungere controlli extra.

Classe di impatto | Cosa significa | Esempio di strumento | Safeguard tipico Sola lettura | Può recuperare dati ma non può alterare lo stato | Lettura file, database SELECT, API GET pubblica | Registra la chiamata, nessun approvazione extra necessaria Scrittura o mutabile | Può creare, aggiornare o eliminare dati | Scrittura file, database INSERT/UPDATE/DELETE, pubblicazione di messaggi interni | Richiede un secondo approvatore per il primo utilizzo, registra con ID utente Effetto esterno irreversibile | Può influenzare sistemi al di fuori del confine di trust | Invio di email, pubblicazione su social media, inizializzazione di pagamento, chiamata a webhook esterno | Approvazione manuale obbligatoria, traccia di audit dettagliata, timeout sulla chiamata

Quando esamino uno strumento nuovo, chiedo: "Se questa chiamata viene eseguita, qual è la cosa peggiore che potrebbe accadere?" La risposta mi dice quale riga della tabella si applica. Per gli strumenti di sola lettura, aggiungo solo una riga di log. Per gli strumenti di scrittura, aggiungo un workflow di approvazione leggero. Per gli effetti irreversibili, attivo una porta manuale e tengo breve la finestra di chiamata.

Accoppiare liste di controllo con filtri di input e output

Una lista di controllo rimuove capacità non necessarie. I filtri catturano dati dannosi che sfuggono alle chiamate consentite. Li tratto come strati complementari, non come sostituti.

Sul lato di input eseguo un controllo di iniezione di prompt che cerca modelli di jailbreak noti. Utilizzo la OWASP LLM Prompt Injection Prevention Cheat Sheet (link) come riferimento per le regole che attivo. Se il controllo segnala un prompt, lo rifiuto o sanifico il segmento offensivo prima che l'agente lo veda.

Sul lato di output scansiono il testo generato dall'agente per segreti, tentativi di iniezione SQL o URL non consentiti. La Secrets Management Cheat Sheet (link) mi aiuta a costruire modelli regex per chiavi API, password e token. La SQL Injection Prevention Cheat Sheet (link) guida i modelli che utilizzo per catturare stringhe di query pericolose che potrebbero essere riportate indietro in una risposta., Entrambi i set di filtri funzionano come middleware leggero. Aggiungono alcuni millisecondi di latenza, ma bloccano molti attacchi a basso sforzo prima che raggiungano lo strato dello strumento. Poiché la lista di controllo ha già rimosso intere classi di chiamate, i filtri hanno una superficie di ispezione più piccola, il che mantiene bassi i falsi positivi.

Cosa non è

Voglio essere chiaro sui limiti di un allowlist in modo che non ci si aspetti che risolva problemi che non era destinato ad affrontare.

- Non è una garanzia che l'agente non si comporterà mai in modo dannoso. Un attaccante determinato che trova un modo per invocare uno strumento consentito con parametri dannosi può ancora causare danni. - Non sostituisce le pratiche di codifica sicure. Se il codice dell'agente contiene una vulnerabilità, l'allowlist non può impedire lo sfruttamento di quel difetto. - Non è un sostituto della gestione appropriata dei segreti. Anche se l'agente non può chiamare uno strumento di esfiltrazione dei segreti, i segreti che fuoriescono nei log o nell'output rappresentano ancora un rischio. - Non ferma l'iniezione di prompt indiretta che manipola l'agente per utilizzare uno strumento consentito in un modo inaspettato. Avete ancora bisogno di convalida dell'input e filtraggio dell'output. - Non è un compito una tantum. Ogni volta che viene aggiunto uno strumento, i suoi parametri cambiano o lo scopo dell'agente si sposta, è necessario rivedere l'elenco. - Non è una soluzione miracolosa per la conformità. Regolamenti come l'EU AI Act richiedono la documentazione, le valutazioni dei rischi e la supervisione umana che vanno al di là di un semplice allowlist.

Sfide comuni che ho visto e come le evito

Anche con un processo chiaro, i team a volte scivolano in abitudini che indeboliscono l'elenco delle autorizzazioni. Di seguito sono riportati i modelli che controllo e i passi concreti che intraprendo per mantenere l'elenco onesto.

- Parametri troppo ampi – Qualcuno aggiunge uno strumento con un flag come "--recursive" o "--all" perché sembra conveniente. Io contrasto questo chiedendo: "Qual è l'insieme minimo di opzioni che soddisfa il compito?" Se la risposta è un subset, blocco il flag su quel subset nel file YAML. - Aggiornamenti di strumenti dimenticati** – Una libreria si aggiorna e aggiunge un nuovo comando che viene esposto automaticamente. Io mitigo questo bloccando la versione esatta dello strumento nel file di dipendenza dell'agente e aggiungendo un passaggio di CI che fallisce se una nuova versione introduce comandi non documentati. - Mescolare politica con prompt** – Uno sviluppatore tenta di applicare limiti aggiungendo istruzioni come "non chiamare delete" all'interno del prompt. Io ricordo al team che i controlli a livello di prompt possono essere bypassati attraverso una riformulazione astuta; il vero guardiano deve essere collocato al livello del registro degli strumenti o dell'esecuzione. - Logging mancante** – L'elenco delle autorizzazioni blocca una chiamata ma nessuno lo sa. Io assicuro che ogni tentativo bloccato scriva una voce di log strutturata con timestamp, ID agente e nome dello strumento rifiutato. Questo log alimenta il nostro sistema di allarme in modo che possiamo rilevare la scansione di un...

Riferimenti

- OWASP LLM Prompt Injection Prevention Cheat Sheet - OWASP SQL Injection Prevention Cheat Sheet - OWASP Secrets Management Cheat Sheet - AgentGuard - Guida ai file di configurazione di Agent Squads

Domande frequenti

È sufficiente un istruzione di prompt per limitare gli strumenti?

No. Le restrizioni a livello di prompt possono essere aggirate. Applica l'elenco di controllo accessi al registro degli strumenti o al livello di esecuzione.

Cosa costituisce un effetto esterno irreversibile?

Inviare email o messaggi, spostare denaro, eliminare record, pubblicare contenuti — tutto ciò che non puoi annullare.

Quanti strumenti sono troppi?

Non c'è un numero. Il test è se puoi spiegare, per ogni strumento nella lista, quale compito lo richiede e cosa può distruggere.

I filtri sostituiscono l'elenco di controllo accessi?

No. I filtri catturano contenuti dannosi; gli elenchi di controllo accessi rimuovono capacità non necessarie. Utilizza entrambi.

Ciò copre l'iniezione di prompt indiretta?

Limita il danno che si può fare. Rilevare e bloccare l'iniezione stessa è un controllo separato sul lato di input.

La revisione è un audit di sicurezza?

No. È un supporto decisionale che valuta le chiamate e suggerisce filtri. Una valutazione completa del deploy ancora necessita di una revisione di sicurezza.

Riferimenti

- OWASP — Top 10 per Applicazioni di Modelli Linguistici di Grande Portata - — Quadro di Riferimento per la Gestione dei Rischi dell'Intelligenza Artificiale

Prova il prodotto: AgentGuard

Articoli correlati

- Le barriere di protezione dell'agente mappate sul NIST AI RMF - Esplora la matrice completa dei temi di AI micro-SaaS →