di AgentPolicy (LX AI)
Pacchetti di policy per agenti AI e NIST AI RMF
Un pacchetto di policy è un insieme riutilizzabile di regole su cosa un agente può fare: quali strumenti può utilizzare, quali classi di dati può toccare e quando deve escalare a un essere umano. La mappatura di queste regole alle quattro funzioni del framework di gestione del rischio AI di NIST, Govern, Map, Measure e Manage, mantiene il pacchetto ancorato a una struttura già riconosciuta dagli auditor. Il pacchetto è una bozza che approvi, non un certificato di conformità.
Govern: proprietà e responsabilità
Definizione dei proprietari delle regole
Inizio ogni pacchetto nominando una persona o un team responsabile per ogni regola. Il proprietario approva il testo della regola, lo revisiona trimestralmente e approva eventuali modifiche. Senza un proprietario chiaro, una regola che blocca uno strumento pericoloso oggi può essere dimenticata quando appare una nuova integrazione, lasciando l'agente con un accesso non inteso.
Processo di controllo delle modifiche
Tratto il pacchetto come un file controllato dalle versioni. Ogni modifica crea un nuovo commit, include una breve motivazione e passa attraverso un elenco di controllo di revisione che copre: (1) impatto sugli strumenti consentiti, (2) effetto sui tag di classe di dati, (3) percorsi di escalation e (4) compatibilità con le prove di audit esistenti. L'elenco di controllo si trova nello stesso repository del pacchetto in modo che i revisori possano vedere la diff e la discussione in un unico posto.
Collegamento alla funzione Govern di NIST
La NIST AI RMF descrive Govern come la base che stabilisce ruoli, responsabilità e politiche. Il mio pacchetto riflette ciò rendendo esplicita la proprietà e incorporando un flusso di lavoro di controllo delle modifiche leggero che gli auditor possono ispezionare. Quando un auditor chiede "chi è responsabile per questa regola?" posso puntare al campo del proprietario e alla cronologia dei commit.
Map: contesto e flussi di dati
Inventario di strumenti e classi di dati
Elenco ogni strumento esterno che l'agente può chiamare, quindi etichetto ogni strumento con le classi di dati che può leggere o scrivere. Ad esempio, uno strumento di riassunto ottiene l'etichetta "customer-tickets" perché può ingerire il testo del ticket, mentre uno strumento di calcolo matematico ottiene l'etichetta "nessuno" perché restituisce solo numeri. Questa vista a doppio strato impedisce l'errore comune di consentire uno strumento senza capire quali dati tocca.
Punteggio di rischio per strumento
Per ogni coppia strumento-dati assegno un punteggio di rischio semplice: basso, medio o alto. Il punteggio deriva da tre domande: (1) Lo strumento gestisce informazioni personali identificabili? (2) Lo strumento può invocare altri servizi? (3) Lo strumento è stato menzionato nei database di vulnerabilità pubblici? Registro il punteggio nel pacchetto in modo che i revisori vedano perché uno strumento è limitato o consentito.
Collegamento alla funzione Map di NIST
Map nell'AI RMF è relativo alla comprensione del contesto e dell'impatto potenziale. Il mio inventario e il foglio di punteggio forniscono un artefatto concreto che mostra quali sistemi l'agente raggiunge, quali dati fluiscono attraverso di esso e quale sarebbe il costo di un fallimento. Ciò soddisfa il requisito Map per "identificare e categorizzare i rischi" prima dell'applicazione di eventuali controlli.
Misura: telemetria e prove
Registrazione degli hit delle regole
Configuro l'agente per emettere un entry di log strutturato ogni volta che una regola viene valutata. L'entry contiene: timestamp, ID agente, ID regola, nome strumento, classe dati, decisione (consenti/nega/escalation) e il punteggio di rischio dal passaggio Map. Questi log fluiscono in un archivio centrale dove posso eseguire query semplici come "mostra tutti i dinieghi per lo strumento summarizer nell'ultima settimana".
Tracciamento dell'escalation
Ogni volta che il pack attiva un'escalation, registro il motivo e l'operatore umano che ha risposto. Nel tempo calcolo due metriche: (1) tasso di escalation per strumento e (2) tempo medio di risoluzione umana. Questi numeri diventano le prove che mostro durante una revisione per dimostrare che i limiti non sono solo scritti ma effettivamente applicati.
Collegamento alla funzione di misura NIST
La funzione di misura richiede indicatori quantitativi che mostrino se i controlli stanno funzionando. Le mie metriche basate sui log danno agli auditor un metodo ripetibile per vedere l'efficacia delle regole, la frequenza di escalation e la latenza di risposta. Se le metriche mostrano un improvviso aumento dei dinieghi per uno strumento, so che il pack necessita di un aggiornamento del passaggio Map.
Gestisci: risposta e iterazione
Aggiornamenti guidati da incidenti
Quando un entry di log rivela una violazione delle politiche - ad esempio, l'agente ha chiamato uno strumento proibito - apro un ticket che fa riferimento alla riga di log esatta. Il ticket guida un breve flusso di lavoro: (1) verificare la violazione, (2) decidere se stringere la definizione dello strumento, aggiungere un elenco di allow-list di egress o richiedere conferma, (3) modificare il pack, (4) aumentare la versione e (5) chiudere il ticket con un collegamento al nuovo commit.
Versioning come codice
Memorizzo il pack in un repository Git. Ogni rilascio ottiene una versione semantica (ad esempio 1.2.0). Il messaggio di commit include la regola modificata, il motivo e il numero del ticket associato. Ciò rende facile mostrare all'auditor la differenza esatta tra la versione revisionata lo scorso mese e la versione in produzione oggi.
Collegamento alla funzione di gestione NIST
La gestione nella AI RMF riguarda la risposta ai problemi rilevati e il miglioramento dei controlli. Il mio flusso di ticket guidato da incidenti e il pack controllato dalla versione danno un meccanismo concreto per rilevare, rispondere e verificare il miglioramento - esattamente ciò che la gestione si aspetta.
Creazione di un pacchetto di policy passo dopo passo
Iniziare con un elenco di strumenti consentiti
Inizio raccogliendo ogni API, CLI o webhook che l'agente potrebbe avere bisogno. Scrivo ogni voce in un elenco YAML semplice, annotando il fornitore dello strumento, la versione e lo scopo. A questo stadio non mi preoccupo delle classi di dati; voglio solo un inventario completo.
Aggiungere tag di classi di dati
Successivamente, passo attraverso l'elenco di strumenti consentiti e chiedo: quali dati questo strumento legge o scrive? Aggiungo un tag come "registri finanziari", "informazioni sanitarie" o "web pubblico". Se uno strumento tocca più classi, aggiungo più tag. Questo passaggio trasforma un elenco nudo in una mappa che può essere valutata per il rischio.
Impostare soglie di escalation
Per ogni coppia di strumento-dati, decido quando l'agente dovrebbe passare a un essere umano. Utilizzo il punteggio di rischio dal passaggio di mappatura: punteggi bassi ottengono l'autorizzazione automatica, punteggi medi ottengono l'autorizzazione con registrazione degli audit, e punteggi alti forzano un'escalation. Codifico queste soglie come una tabella di decisione nel pacchetto.
Convalidare con scenari di test
Prima di considerare il pacchetto "pronto", eseguo un set di interazioni scriptate che tentano di attivare ogni regola. Verifico che i log catturino la decisione prevista, che le escalation si attivino quando dovrebbero e che nessuna regola fallisca silenziosamente. Se un test mostra una discordanza, ritorno al passaggio di mappatura o gestione per correggere il pacchetto.
Cosa questo non è
Voglio essere chiaro sui limiti di un pacchetto di policy. Non è una garanzia che l'agente non violerà mai una regola. Non è uno scudo al 100% contro nuovi vettori di attacco sconosciuti quando il pacchetto è stato scritto. Non sostituisce una revisione legale formale, una valutazione di un organismo notificato o la vostra accettazione del rischio. Il pacchetto è uno strumento di supporto alle decisioni che rende le regole visibili, testabili e modificabili, ma la responsabilità finale riposa ancora con gli esseri umani che possiedono il sistema.
Checklist dell'operatore per pacchetti di policy di agenti AI attraverso la lente di NIST AI RMF
Conservo una checklist scritta accanto a ogni rilascio che tocca questo argomento. La lista è noiosa di proposito: nominare il proprietario, nominare l'artefatto di evidenza e nominare il rollback. Se un passaggio non può produrre un file, un ticket o una riga di log, non è un passaggio - è un desiderio.
Prima di modificare la produzione
- Congelare il ramo o la revisione della configurazione che si desidera misurare. - Registrare la modalità di errore attuale con un input concreto e un output concreto. - Confermare quale identità esegue il lavoro e se tale identità può accedere a dati che non dovrebbe. - Aprire le principali referenze che si citeranno: https://genai.owasp.org/llmrisk/llm01-prompt-injection, https://owasp.org/www-project-top-10-ci-cd-security-risks/CICD-SEC-06-Insufficient-Credential-Hygiene.
Mentre si esegue il controllo
- Preferire un percorso riproducibile rispetto a dieci screenshot aneddotici. - Scrivere il risultato sicuro atteso prima di attivare lo strumento o la query. - Catturare l'esatto comando, prompt, schema o regex sotto test - non una parafrasi. - Se il sistema può agire (inviare, scrivere, eliminare, trasferire), richiedere un confine di conferma nello stesso passaggio.
Dopo aver terminato
- Archiviare il rischio residuo con un proprietario e una data, anche quando la scansione è pulita. - Non convertire un controllo verde in un linguaggio di vendita che afferma la completezza. - Eseguire nuovamente la stessa checklist quando il modello, lo schema dello strumento o le regole di convalida cambiano.
Segnale | Cosa registrare | Stop-ship? Scrittura o invio inaspettato | Nome dello strumento, argomenti, identità | Sì fino a quando non è stato bloccato Mancata conferma sull'azione distruttiva | Percorso di chiamata e bypass | Sì Testo non attendibile trattato come istruzione | Superficie di origine e azione risultante | Sì per la portata dell'agente Scanner pulito, giudizio aperto | Elementi differiti + proprietario | Solo se il percorso principale è sicuro
AgentPolicy aiuta con il primo passaggio misurabile. Le scelte architettoniche, il consenso legale e le affermazioni rivolte ai clienti ancora necessitano di un proprietario umano. Trattare ogni riga della checklist come supporto decisionale, non come certificato.
Come spiego i limiti agli acquirenti
Quando un potenziale acquirente chiede se il prodotto "copre tutto", rispondo con il confine: i controlli automatizzati individuano modelli noti; le catene nuove e il giudizio di policy ancora necessitano di revisione. Quella onestà mantiene il carico di supporto basso e mantiene il blog allineato con ciò che il prodotto effettivamente fa.
Se hai bisogno di un secondo parere, abbina questo scritto con le referenze riportate di seguito e con la tua stessa riproduzione di staging. Non saltare il passaggio di riproduzione solo perché un modello ha scritto un riassunto fiducioso.
Riferimenti
- https://genai.owasp.org/llmrisk/llm01-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
Articoli correlati
- Strumenti consentiti vs agenti aperti - Esplora la matrice completa dei temi AI micro-SaaS →
Un pacchetto di policy generato soddisfa la normativa EU AI Act?
No. Il pacchetto è di supporto alle decisioni. Dove si applica la normativa EU AI Act, è comunque necessario valutare la conformità, la documentazione tecnica e la progettazione della supervisione umana ai sensi del Regolamento (UE) 2024/1689. Il pacchetto aiuta a preparare questi artefatti, non a sostituirli.
Come le funzioni NIST AI RMF si mappano su un file di policy?
Govern assegna la proprietà, Map registra il contesto del sistema e dei dati, Measure registra quali regole sono state attivate e Manage aggiorna il pacchetto dopo un incidente. Le quattro funzioni danno al pacchetto una struttura già riconosciuta dai revisori.
Cosa rende un pacchetto applicabile piuttosto che decorativo?
La telemetria. Se non si può mostrare quali regole sono state attivate e dove un agente è stato negato, la policy è un desiderio. Accoppiare il pacchetto con la registrazione in modo che i suoi limiti siano osservabili durante la revisione.
Chi dovrebbe possedere un pacchetto di policy di un agente?
Un proprietario nominato, idealmente con sia input di ingegneria che di rischio. Il proprietario approva le modifiche e è responsabile quando uno strumento di abuso si infiltra. Un pacchetto senza proprietario tende a deteriorarsi con l'arrivo di nuove integrazioni.
Supporto alle decisioni. Non è un parere legale o un certificato di conformità.