AI-agentbeleidspakketten en NIST AI RMF

Govern: eigendom en verantwoordelijkheid

Definitie van regel-eigenaren

Ik begin elke pack door een persoon of team te noemen dat verantwoordelijk is voor elke regel. Die eigenaar ondertekent de regeltekst, bekijkt deze elk kwartaal en keurt elke wijziging goed. Zonder een duidelijke eigenaar kan een regel die vandaag een gevaarlijk hulpmiddel blokkeert, worden vergeten wanneer een nieuwe integratie verschijnt, waardoor de agent onbedoeld toegang krijgt.

Wijzigingsbeheerproces

Ik behandel de pack als een versiebeheerde file. Elke bewerking maakt een nieuwe commit aan, bevat een korte onderbouwing en gaat door een controlelijst die de volgende punten dekt: (1) impact op toegestane hulpmiddelen, (2) effect op data-class-tags, (3) escalatiepaden en (4) compatibiliteit met bestaande auditbewijs. De controlelijst staat in hetzelfde repository als de pack, zodat reviewers de diff en de discussie op één plaats kunnen zien.

Link naar NIST Govern-functie

De NIST AI RMF beschrijft Govern als de basis die rollen, verantwoordelijkheden en beleid vaststelt. Mijn pack spiegelt dat door eigendom expliciet te maken en door een lichtgewicht wijzigingsbeheerworkflow in te bedden die auditors kunnen inspecteren. Wanneer een auditor vraagt "wie is verantwoordelijk voor deze regel?", kan ik naar het eigenaarveld en de commitgeschiedenis verwijzen.

Kaart: context en gegevensstromen

Inventaris van tools en gegevensklassen

Ik maak een lijst van alle externe tools die de agent kan aanroepen, en tag ik elke tool met de gegevensklassen die het kan lezen of schrijven. Bijvoorbeeld, een samenvattings-tool krijgt de tag "klant-tickets" omdat het ticket-tekst kan verwerken, terwijl een reken-tool de tag "geen" krijgt omdat het alleen nummers teruggeeft. Deze dubbele laag biedt een overzicht dat voorkomt dat een tool wordt toegestaan zonder te begrijpen welke gegevens het aanraakt.

Risicoscore per tool

Voor elk tool-gegevens-paar wijs ik een eenvoudige risicoscore toe: laag, medium of hoog. De score komt uit drie vragen: (1) Verwerkt de tool persoonlijk identificeerbare informatie? (2) Kan de tool andere services aanroepen? (3) Is de tool genoemd in openbare kwetsbaarheidsdatabases? Ik registreer de score in het pakket zodat reviewers zien waarom een tool wordt beperkt of toegestaan.

Link naar NIST Kaart-functie

Kaart in de AI RMF gaat over het begrijpen van context en potentieel impact. Mijn inventaris en scoresheet geven een concreet artifact dat laat zien welke systemen de agent bereikt, welke gegevens er doorheen stromen en wat een falen zou kosten. Dit voldoet aan de Kaart-eis om "risico's te identificeren en categoriseren" voordat er controles worden toegepast.

Maatregel: telemetrie en bewijs

Loggen van regelhits

Ik configureer de agent om een gestructureerd logboekrecord te verzenden telkens wanneer een regel wordt geëvalueerd. Het record bevat: tijdstempel, agent-ID, regel-ID, toolnaam, gegevensklasse, beslissing (toestaan/weigeren/escaleren) en de risicoscore van de Map-stap. Deze logboeken worden doorgestuurd naar een centrale opslag waar ik eenvoudige queries kan uitvoeren zoals 'toon alle weigeringen voor het summarizertool in de afgelopen week.'

Escalatievolging

Telkens wanneer de pack een escalatie activeert, log ik de reden en de mens die reageerde. Na verloop van tijd bereken ik twee metrieken: (1) escalatiefrequentie per tool en (2) gemiddelde tijd tot menselijke resolutie. Deze cijfers vormen het bewijs dat ik tijdens een review laat zien om aan te tonen dat limieten niet alleen zijn geschreven maar daadwerkelijk worden afgedwongen.

Link naar NIST Maatregelfunctie

De Maatregelfunctie vraagt om kwantitatieve indicatoren die aantonen of controles werken. Mijn logboekgebaseerde metrieken geven auditors een herhaalbare manier om de effectiviteit van regels, escalatiefrequentie en responstijd te zien. Als de metrieken een plotselinge stijging van weigeringen voor een tool laten zien, weet ik dat de pack een Map-update nodig heeft.

Beheer: respons en iteratie

Incident-gedreven updates

Wanneer een logboekregel een beleidsschending onthult - zeg, de agent heeft een verboden tool aangeroepen - open ik een ticket dat verwijst naar de exacte logboekregel. Het ticket drijft een korte workflow: (1) verifieer de schending, (2) beslis of de tooldefinitie moet worden aangescherpt, een egress-allowlijst moet worden toegevoegd of bevestiging moet worden vereist, (3) bewerk het pakket, (4) verhoog de versie en (5) sluit het ticket met een link naar de nieuwe commit.

Versiebeheer zoals code

Ik sla het pakket op in een Git-repository. Elke release krijgt een semantische versie (bijv. 1.2.0). Het commitbericht bevat de gewijzigde regel, de reden en het bijbehorende ticketnummer. Dit maakt het gemakkelijk om aan een auditor te laten zien wat het exacte verschil is tussen de versie die vorige maand is beoordeeld en de versie die vandaag in productie is.

Link naar NIST Beheerfunctie

Beheer in de AI RMF gaat over het reageren op gedetecteerde problemen en het verbeteren van controles. Mijn incident-gedreven ticketstroom en versiebeheerde pakket geven een concreet mechanisme om te detecteren, te reageren en te verifiëren van verbetering - precies wat Beheer verwacht.

Een beleidspakket stap voor stap opbouwen

Begin met een tool-allowlijst

Ik begin met het verzamelen van elke API, CLI of webhook die de agent mogelijk nodig heeft. Ik schrijf elke entry in een eenvoudige YAML-lijst, waarbij ik de leverancier, versie en doel van het hulpmiddel noteer. Op dit moment maak ik me geen zorgen over gegevensklassen; ik wil alleen een complete inventaris hebben.

Voeg gegevensklasse-tags toe

Vervolgens ga ik door de allowlijst en vraag ik: welke gegevens leest of schrijft dit hulpmiddel? Ik voeg een tag toe zoals 'financiële-gegevens', 'gezondheidsinformatie' of 'openbare website'. Als een hulpmiddel meerdere klassen aanraakt, voeg ik meerdere tags toe. Deze stap verandert een kale lijst in een kaart die kan worden beoordeeld op risico.

Stel escalatiedrempels in

Voor elk hulpmiddel-gegevenspaar besluit ik wanneer de agent het over moet dragen aan een mens. Ik gebruik de risicoscore uit de Kaart-stap: lage scores krijgen automatische toestemming, middelhoge scores krijgen toestemming met auditlogging en hoge scores dwingen een escalatie af. Ik codeer deze drempels als een beslissingstabel in het pakket.

Valideer met testsenario's

Voordat ik het pakket 'klaar' noem, voer ik een reeks van gescripte interacties uit die proberen elke regel te activeren. Ik verifieer dat logs de verwachte beslissing vastleggen, dat escalaties worden geactiveerd wanneer dat nodig is en dat geen enkele regel stilzwijgend faalt. Als een test een mismatch laat zien, ga ik terug naar de Kaart- of Beheerstap om het pakket te corrigeren.

Wat dit niet is

Ik wil duidelijk zijn over de beperkingen van een policy pack. Het is geen garantie dat de agent nooit een regel zal overtreden. Het is geen 100 % schild tegen nieuwe aanvalsvector die onbekend waren toen de pack werd geschreven. Het vervangt geen formele juridische beoordeling, een beoordeling door een aangemelde instantie, of uw eigen risicotoelating. De pack is een beslissingsondersteunend instrument dat regels zichtbaar, testbaar en veranderbaar maakt, maar de uiteindelijke verantwoordelijkheid rust nog steeds bij de mensen die het systeem bezitten.

Operator checklist voor AI-agentbeleidspakketten door een NIST AI RMF-bril

Ik hou een geschreven checklist bij elke release die deze onderwerpen aangaat. De lijst is saai om een goede reden: noem de eigenaar, noem het bewijsartefact en noem de rollback. Als een stap geen bestand, ticket of logregel kan produceren, is het geen stap - het is een wens.

Voordat u productie wijzigt

- Vries de branch of configuratieversie in die u wilt meten. - Registreer de huidige foutmodus met één concreet invoer- en één concreet uitvoerexemplaar. - Bevestig welke identiteit de taak uitvoert en of die identiteit toegang heeft tot gegevens die het niet zou moeten hebben. - Open de primaire referenties die u zal citeren: 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.

Terwijl u de controle uitvoert

- Geef de voorkeur aan één reproduceerbare pad boven tien anekdotische screenshots. - Schrijf het verwachte veilige resultaat voordat u het hulpmiddel of de query activeert. - Vang de exacte opdracht, prompt, schema of regex onder test - niet een parafrase. - Als het systeem kan handelen (versturen, schrijven, verwijderen, overdragen), vereist u een confirmatiegrens in hetzelfde doorvoeren.

Nadat u klaar bent

- Registreer het resterende risico met een eigenaar en een datum, zelfs als de scan schoon is. - Converteer geen groene controle naar verkoopstaal dat volledigheid claimt. - Voer dezelfde checklist opnieuw uit wanneer het model, het hulpmiddelschema of de validatieregels veranderen.

Signaal | Wat te registreren | Stop-ship? Onverwachte schrijf- of verzendactie | Hulpmiddelnaam, args, identiteit | Ja totdat het wordt geblokkeerd Ontbrekende confirmatie bij destructieve actie | Oproep-pad en omzeiling | Ja Onbetrouwbaar tekst behandeld als instructie | Bronoppervlak en resulterende actie | Ja voor agentbereik Scanner schoon, oordeel open | Uitgestelde items + eigenaar | Alleen als de kernweg veilig is

AgentPolicy helpt bij de meetbare eerste doorvoering. Architectuurkeuzes, juridische goedkeuring en klantgerichte claims hebben nog steeds een menselijke eigenaar nodig. Behandel elke rij in de checklist als beslissingsondersteuning, niet als certificaat. MailPilot, AIActRadar, AgentPolicy, AgentRedTeam en Waffo kunnen helpen bij het implementeren van de EU AI Act, OWASP en NIST-richtlijnen.

Hoe ik limieten uitleg aan kopers

Wanneer een potentiële koper vraagt of het product "alles dekt", antwoord ik met de grens: geautomatiseerde controles vangen bekende patronen; nieuwe ketens en beleidsbeoordeling hebben nog steeds een review nodig. Die eerlijkheid houdt de ondersteuningslast laag en houdt de blog in overeenstemming met wat het product daadwerkelijk doet.

Als u een tweede mening nodig heeft, combineer deze tekst dan met de onderstaande referenties en met uw eigen reproductie in een testomgeving. Sla de reproductiestap niet over alleen omdat een model een zelfverzekerde samenvatting heeft geschreven.

Referenties

- 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

Gerelateerde artikelen

- Toegestane tools vs open-ended agents - Verken de volledige AI micro-SaaS topic matrix →