di AgentPolicy (LX AI)

Strumenti consentiti vs agenti open-ended

L'appeal di un agente open-ended è reale: dargli un shell, un browser e una casella di posta, e può risolvere problemi che non hai scriptato. Il costo è il raggio di azione. Ogni strumento che aggiungi è un percorso che un'istruzione iniettata può percorrere. La domanda di design non è se concedere la capacità, ma come concederla in modo sufficientemente ristretto in modo che un passo falso rimanga contenuto.

Definizioni di strumenti con privilegi minimi

Inizio scrivendo un contratto di strumento che specifica esattamente cosa l'agente può fare e cosa non può fare. Uno strumento "read ticket" dovrebbe esporre solo un'operazione GET su un identificatore di ticket specifico, senza la possibilità di modificare il ticket, allegare file o chiamare altri endpoint. Uno strumento "send email" dovrebbe accettare solo un elenco di destinatari predefinito, un modello di oggetto fisso e un corpo che è stato sanificato per l'iniezione di newline. Ristringendo il contratto, un singolo errore nell'output del modello diventa un evento limitato invece di una cascata.

Definire l'insieme dei verbi

Elencare ogni metodo HTTP, comando del database o operazione sul file che lo strumento necessita. Se lo strumento necessita solo di leggere, omettere POST, PUT, DELETE e qualsiasi comando amministrativo. Conservo un foglio di calcolo che mappa ogni nome di strumento ai verbi consentiti e lo rivedo ogni volta che viene aggiunto un nuovo endpoint.

Vincolare gli argomenti

Per ogni argomento, specifico un tipo, un limite di lunghezza e un set di caratteri consentiti. Un ID di ticket potrebbe essere un UUID, limitato a 36 caratteri. Un percorso di file potrebbe essere limitato a una sottodirectory sotto /var/agent/data e non deve contenere ".." o percorsi assoluti. Utilizzo una libreria di convalida dello schema che rifiuta qualsiasi richiesta che non sia conforme prima che lo strumento venga eseguito.

Versionare il contratto

Conservo la definizione dello strumento come file JSON nel controllo di versione. Qualsiasi modifica attiva una richiesta di pull che richiede l'approvazione di un revisore di sicurezza. Ciò crea un registro di audit che mostra quando la superficie di privilegio è stata ampliata e perché.

Per vedere come l'iniezione di prompt può abusare di strumenti eccessivamente ampi, consultare la guida OWASP LLM01: https://genai.owasp.org/llmrisk/llm01-prompt-injection. La scheda tecnica mostra esempi concreti in cui un modello è stato ingannato per invocare un comando shell perché lo strumento accettava input non restrittivi.

Nome strumento | Verbo consentito | Vincoli argomenti | Esempio di chiamata sicura read_ticket | GET | ticket_id: UUID, 36 caratteri | /tickets/123e4567-e89b-12d3-a456-426614174000 send_email | POST | a: elenco da approved_domains, oggetto: massimo 78 caratteri, corpo: sanificato | {"a":["utente@esempio.com"],"oggetto":"Aggiornamento","corpo":"Si prega di esaminare il rapporto allegato."} list_files | GET | percorso: deve iniziare con /var/agent/data/, no ".." | /var/agent/data/logs/2024-09-01.txt

Conferma su azioni irreversibili

Le azioni che modificano lo stato al di fuori della sandbox dell'agente - come l'invio di un messaggio, l'eliminazione di un record o la distribuzione di una build - devono essere controllate da un passaggio di approvazione separato che l'agente non può invocare su se stesso. Tratto queste come porte a senso unico e progetto la politica per richiedere un token umano o un servizio di approvazione a breve termine prima che lo strumento venga eseguito.

Endpoint di approvazione separato

Espongo un'API interna che accetta una richiesta firmata dall'agente, registra la richiesta e poi attende che un umano faccia clic su "approva" in una UI o risponda a un comando di chat. L'agente riceve solo un identificatore pendente; non può sondare l'endpoint di approvazione per forzare una concessione.

Token a tempo

Quando l'approvazione viene concessa, il sistema rilascia un token che è valido per un solo uso e scade dopo cinque minuti. L'endpoint dello strumento controlla la firma e la scadenza del token prima di procedere. Se il token è mancante o obsoleto, lo strumento restituisce un errore e il tentativo viene registrato.

Registrazione del cancello

Ogni richiesta di approvazione e decisione viene scritta in un registro immutabile con timestamp, l'identificatore dell'agente, il nome dello strumento e gli argomenti presentati. Questo registro mi consente di ricostruire se un'istruzione avvelenata è riuscita a bypassare il cancello o è stata fermata al passaggio di approvazione.

Per la guida sulla sicurezza dell'igiene delle credenziali nelle pipeline automatizzate, vedere la scheda di rischio di sicurezza CI/CD di OWASP: https://owasp.org/www-project-top-10-ci-cd-security-risks/CICD-SEC-06-Insufficient-Credential-Hygiene. Rafforza il principio che i segreti non dovrebbero mai essere archiviati in un luogo in cui un agente possa leggerli senza un flusso di approvazione esplicito.

I log delle audit come controllo, non come afterthought

Tratto i log delle audit come la principale prova che una policy è stata applicata. Senza un log affidabile, le affermazioni sulla gestione dei privilegi minimi sono solo affermazioni non verificabili. Progetto il layer di logging per essere write-only dalla prospettiva dell'agente e per essere archiviato in un sistema che l'agente non può alterare o eliminare.

Cosa registrare

- Timestamp con precisione al millisecondo - Identificatore dell'agente (versione del modello, ID di distribuzione) - Nome dello strumento e verbo esatto chiamato - Tutti gli argomenti passati allo strumento, dopo la convalida - Codice di stato del risultato e riassunto dei dati restituiti (dimensione, non contenuto completo) - Origine della richiesta (iniziativa dell'utente, trigger programmato o motore di policy)

Garanzie di archiviazione

Scrivo ogni voce di log in un archivio append-only come un log di anticipazione in un bucket di archiviazione cloud con la versioning degli oggetti abilitata. La policy del bucket nega qualsiasi operazione di eliminazione o sovrascrittura dall'account di servizio dell'agente. Ciò garantisce che anche se il modello è compromesso, la storia rimane intatta.

Richiesta per le indagini

Quando viene segnalato un incidente, eseguo una semplice query SQL-like contro l'indice del log per trovare tutte le esecuzioni di uno strumento particolare all'interno di una finestra temporale. Evito join complessi che potrebbero essere lenti; invece, mi affidò a tabelle partizionate per data e nome dello strumento. La query restituisce l'elenco degli identificatori che poi estraggo per un'analisi forense più approfondita.

Per comprendere come la convalida degli input possa prevenire argomenti maligni dal raggiungere uno strumento, consultare la scheda di cheat per la prevenzione delle iniezioni SQL: https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html. La scheda mostra query parametrizzate e tipizzazione rigorosa, che rispecchiano l'approccio di convalida degli argomenti che utilizzo per gli strumenti dell'agente.

Quando l'accesso aperto è giustificato

Ci sono casi legittimi in cui un agente necessita di un accesso più ampio, come ad esempio l'analisi dei dati exploratori o la caccia alle minacce in un ambiente isolato. In quelle situazioni, concedo l'apertura solo dopo aver collocato l'agente in una sandbox che blocca qualsiasi percorso per i dati di produzione o i sistemi di pagamento esterni.

Confini della sandbox

La sandbox fornisce un shell, un motore del browser e una casella di posta che può inviare messaggi solo a un dominio di test dedicato. La policy di rete blocca il traffico in uscita verso qualsiasi indirizzo IP che appartenga agli intervalli CIDR interni dell'azienda. La sola uscita consentita è verso un set di mirror pubblici approvati per l'installazione dei pacchetti.

Isolamento delle credenziali

Nessun segreto di produzione è montato nel file system della sandbox. Invece, l'agente riceve un token temporaneo che può leggere da un bucket di dataset pubblico. Se l'agente tenta di leggere un file al di fuori del punto di montaggio consentito, il kernel restituisce un errore di permesso e il tentativo viene registrato.

Sessioni a tempo

Ogni sessione della sandbox dura al massimo due ore. Dopo il timeout, l'ambiente viene smontato e viene avviata una nuova immagine. Ciò limita la finestra durante la quale un agente malintenzionato potrebbe esplorare o esfiltrare dati.

Tuttavia, applico ancora le definizioni degli strumenti con privilegi minimi all'interno della sandbox; la differenza è che le conseguenze di un errore sono contenute nell'ambiente disposable anziché nei sistemi di produzione. Inoltre, gli strumenti come MailPilot, AIActRadar, AgentPolicy, AgentRedTeam e Waffo possono essere utilizzati per monitorare e gestire l'accesso alla sandbox, assicurando che le linee guida dell'UE per l'AI Act, come l'Art. 12, siano rispettate e che le regole di sicurezza come quelle definite da NIST e OWASP siano applicate.

Trattare le policy generate come bozze

Quando un modello o un ingegnere junior produce un file di policy, lo esamino esattamente come esaminerei del codice non attendibile che sta per essere distribuito a un servizio critico. La checklist di revisione include la verifica di ogni regola contro le definizioni di strumento effettive, la conferma che esistano percorsi di diniego e la garanzia che il file sia versionato.

Mappatura regola-strumento

Creo un foglio di calcolo che elenca ogni strumento su un asse e ogni regola di policy sull'altro. Per ogni cella, segno se la regola consente, nega o è silente sull'operazione dello strumento. Qualsiasi cella silente attiva un commento che chiede all'autore di chiarire l'intento.

Controllo predefinito di diniego

Eseguo uno script di analisi statica che tenta di invocare ogni strumento con un set di argomenti non validi. Se lo script trova una combinazione che la policy consente ma che dovrebbe essere negata (ad esempio, uno strumento di "cancellazione" che accetta un identificatore con caratteri jolly), lo script fallisce la build e la policy deve essere rivista.

Controllo versione e revisione

Il file di policy vive in un repository Git con protezione del ramo che richiede due approvazioni prima di eseguire il merge. Etichetto ogni versione rilasciata con un numero semantico (ad esempio, v1.2.0) e allego lo snapshot della definizione dello strumento corrispondente. Ciò rende possibile tornare a uno stato noto-buono se una nuova versione introduce una regola eccessivamente permissiva.

Non considero mai una policy generata come definitiva fino a quando non ha superato questo ciclo di revisione. Una policy che non viene mai esaminata crea un falso senso di sicurezza e può nascondere lacune che appaiono solo sotto carico reale.

Cosa non è questo

Questa guida non promette che seguire i passaggi eliminerà ogni possibile modalità di fallimento. Non affermo una protezione del 100% contro l'iniezione di prompt, la perdita di credenziali o gli errori di logica. Non affermo inoltre che un agente non perderà mai un'istruzione maliziosa; la rilevazione dipende dalla qualità dei log, dalla tempestività della revisione umana e dalla correttezza dei contratti di strumento. Trattate i modelli come misure di riduzione del rischio, non come garanzia di sicurezza assoluta.