AI-agentpolitikpakker og NIST AI RMF

Govern: ejerskab og ansvar

Definering af regel-ejere

Jeg starter hver pakke ved at navngive en person eller team, der er ansvarlig for hver regel. Denne ejer godkender regelteksten, gennemgår den kvartalsvis og godkender eventuelle ændringer. Uden en klar ejer kan en regel, der blokerer et farligt værktøj i dag, blive glemt, når en ny integration dukker op, og efterlade agenten med uventet adgang.

Ændringskontrolproces

Jeg behandler pakken som en version-kontrolleret fil. Hver redigering skaber en ny commit, der inkluderer en kort begrundelse, og passerer gennem en gennemgangsliste, der dækker: (1) påvirkning af tilladte værktøjer, (2) effekt på data-klassetags, (3) eskalationsveje og (4) kompatibilitet med eksisterende revisionsbevis. Listen findes i samme repository som pakken, så gennemgangere kan se diff'en og diskussionen på ét sted.

Link til NIST Govern-funktion

NIST AI RMF beskriver Govern som den grund, der fastsætter roller, ansvar og politikker. Min pakke spejler dette ved at gøre ejerskab eksplitt og ved at indbygge en letvægts-ændringskontrol-arbejdsgang, som revisorer kan inspicere. Når en revisor spørger "hvem er ansvarlig for denne regel?", kan jeg pege på ejerfeltet og commit-historikken.

Map: kontekst og dataflader

Inventar af værktøjer og dataklasser

Jeg lister alle eksterne værktøjer, som agenten må kalde, og derefter tagger hver værktøj med de dataklasser, det kan læse eller skrive. For eksempel får en sammenfatningsværktøj tagget "kundebilletter", fordi det kan indtage billettekst, mens en matematik-værktøj får tagget "ingen", fordi det kun returnerer numre. Denne dobbelte lag-vision forhindrer den almindelige fejl at tillade et værktøj uden at forstå, hvilke data det berører.

Risikoscoring pr. værktøj

For hver værktøj-data-par tildeler jeg en simpel risikoscoring: lav, medium eller høj. Scoringen kommer fra tre spørgsmål: (1) Behandler værktøjet personfølsomme oplysninger? (2) Kan værktøjet kalde andre tjenester? (3) Er værktøjet blevet nævnt i offentlige sårbarhedsdatabaser? Jeg optager scoringen i pakken, så gennemgangere kan se, hvorfor et værktøj er begrænset eller tilladt.

Link til NIST Map-funktion

Map i AI RMF handler om at forstå kontekst og potentiel påvirkning. Min inventar og scoringsskema giver en konkrekt artifact, der viser, hvilke systemer agenten når, hvilke dataflader der går gennem det, og hvad en fejl ville koste. Dette tilfredsstiller Map-kravet til at "identificere og kategorisere risici" før nogen kontroller anvendes.

Measure: telemetri og bevis

Logging af regel-træffere

Jeg konfigurerer agenten til at udsende en struktureret log-indtastning hver gang en regel evalueres. Indtastningen indeholder: timestamp, agent-ID, regel-ID, værktøjsnavn, dataklasse, beslutning (tillad/afvis/ eskalere) og risikoscoringen fra Map-trinnet. Disse logs flyder til en central butik, hvor jeg kan køre simple forespørgsler som "vis alle afvisninger for sammenfatningsværktøjet i sidste uge."

Eskalations-sporing

Når pakken udløser en eskalation, logger jeg årsagen og den menneskelige, der reagerede. Over tid beregner jeg to målinger: (1) eskalationsrate pr. værktøj og (2) gennemsnitlig tid til menneskelig løsning. Disse tal bliver beviset, jeg viser under en gennemgang for at bevise, at begrænsninger ikke kun er skrevet, men faktisk gennemført.

Link til NIST Measure-funktion

Measure-funktionen kræver kvantitative indikatorer, der viser, om kontroller fungerer. Mine log-baserede målinger giver revisorer en gentagbar måde at se regel-effektivitet, eskalationsfrekvens og respons-forlængelse. Hvis målingerne viser en pludselig stigning i afvisninger for et værktøj, ved jeg, at pakken har brug for en Map-opdatering.

Manage: respons og iteration

Incident-drevne opdateringer

Når en log-indtastning afslører en politik-overtrædelse - f.eks. agenten kaldte et forbudt værktøj - åbner jeg en billet, der refererer til den præcise log-linje. Billetten driver en kort arbejdsgang: (1) verificér overtrædelsen, (2) beslut, om at stramme værktøjsdefinitionen, tilføje en udgående tilladelsesliste eller kræve bekræftelse, (3) rediger pakken, (4) øge versionsnummeret og (5) lukke billetten med en link til den nye commit.

Versionsstyring som kode

Jeg gemmer pakken i et Git-repository. Hver udgave får en semantisk version (f.eks. 1.2.0). Commit-beskedningen inkluderer den ændrede regel, årsagen og den tilknyttede billetnummer. Dette gør det let at vise en revisor den præcise forskel mellem den version, der blev gennemgået sidste måned, og den version, der er i produktion i dag.

Link til NIST Manage-funktion

Manage i AI RMF handler om at reagere på detekterede problemer og forbedre kontroller. Min incident-drevne billet-flow og versions-kontrollerede pakke giver en konkrekt mekanisme til at detektere, reagere og verificere forbedring - præcis, hvad Manage forventer.

Opbygning af en politikpakke trin-for-trin

Start med en værktøjs-tilladelsesliste

Jeg starter med at samle alle API'er, CLI'er eller webhooks, som agenten måtte have brug for. Jeg skriver hver indtastning i en simpel YAML-liste, noterer værktøjsleverandøren, versionen og formålet. På dette stadium bekymrer jeg mig ikke om dataklasser; jeg vil bare have en komplet inventar.

Tilføj data-klassetags

Derefter går jeg gennem tilladelseslisten og spørger: hvilke data berører dette værktøj? Jeg tilføjer en tag som "finansiel-regnskab", "sundhedsoplysninger" eller "offentlig-web". Hvis et værktøj berører flere klasser, tilføjer jeg flere tags. Dette skridt omdanner en nøgen liste til et kort, der kan scores for risiko.

Fastlæg eskalationsgrænser

For hver værktøj-data-par beslutter jeg, hvornår agenten skal overdrage til en menneskelig. Jeg bruger risikoscoringen fra Map-trinnet: lave scores får automatisk tilladelse, medium-scores får tilladelse med revisionslogging og høje scores tvinger en eskalation. Jeg kodificerer disse grænser som en beslutningstabel i pakken.

Valider med testscenarier

Før jeg kalder pakken "færdig", kører jeg en række skriptede interaktioner, der forsøger at udløse hver regel. Jeg verificerer, at logs fanger den forventede beslutning, at eskalationer udløses, når de skal, og at ingen regel stille og roligt fejler. Hvis en test viser en misligholdelse, returnerer jeg til Map- eller Manage-trinnet for at korrigere pakken.

Hvad dette ikke er

Jeg vil gerne være tydelig omkring grænserne for en politikpakke. Den er ikke en garanti for, at agenten aldrig vil overtræde en regel. Den er ikke en 100 % skærm mod nye angrebsvektorer, der var ukendte, da pakken blev skrevet. Den erstatter ikke en formel juridisk gennemgang, en vurdering af en anmeldt enhed eller din egen risikoaccept. Pakken er et beslutningsstøtteredskab, der gør regler synlige, testbare og ændringsbare, men endelig ansvar hviler stadig hos de mennesker, der ejer systemet.

Operatør-checkliste for AI-agentpolitikpakker gennem en NIST AI RMF-lins

Jeg holder en skrevet checkliste ved siden af hver udgave, der berører dette emne. Listen er kedelig med vilje: navngiv ejeren, navngiv bevis-artefakten og navngiv rollback. Hvis et skridt ikke kan producere en fil, en billet eller en log-linje, er det ikke et skridt - det er en ønsketænkning.

Før du ændrer produktion

- Fryse branchen eller konfigurationsrevisionen, du vil måle imod. - Optegn den nuværende fejltilstand med en konkretpunkt og en konkretpunkt. - Bekræft, hvilken identitet jobbet kører som, og om denne identitet kan nå data, den ikke skal nå. - Åbn de primære referencer, du vil citerer: 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.

Mens du kører checken

- Foretræk en reproducerbar vej over ti anekdotiske skærmbilleder. - Skriv den forventede sikre udfald, før du udløser værktøjet eller forespørgslen. - Fanget det præcise kommando, prompt, skema eller regex under test - ikke en omskrivning. - Hvis systemet kan handle (sende, skrive, slette, overføre), kræv en bekræftelsesgrænse i samme pass.

Efter du er færdig

- Fil residual risiko med en ejer og en dato, selv når scan er ren. - Omdøb ikke en grøn check til salgsprosa, der hævder fuldstændighed. - Kør samme checkliste, når modellen, værktøjs-skemaet eller valideringsreglerne ændres.

Signal | Hvad at optegne | Stop-ship? Uventet skriv eller send | Værktøjsnavn, args, identitet | Ja, indtil gated Manglende bekræftelse på destruktiv handling | Call-sti og omgåelse | Ja Ubetroet tekst behandlet som instruktion | Kildeoverflade og resulterende handling | Ja for agent-rækkevidde Scanner ren, dommer åben | Udsatte punkter + ejer | Kun hvis kernevej er sikker

AgentPolicy hjælper med den målbare første pass. Arkitekturvalg, juridisk godkendelse og kunde-orienterede krav har stadig brug for en menneskelig ejer. Behandle hver checkliste-række som beslutningsstøtte, ikke et certifikat.

Hvordan jeg forklarer grænser for købere

Når en prospekt spørger, om produktet "dækker alt", svarer jeg med grænsen: automatiserede kontroller fanger kendte mønstre; nye kæder og politikdom stiller krav om gennemgang. Den ærlighed holder supportbelastningen nede og holder bloggen i trit med, hvad produktet faktisk gør.

Hvis du har brug for en anden mening, par denne artikel med referencerne nedenfor og med din egen staging-reproduktion. Spring ikke reproductionsskridtet over, bare fordi en model skrev en selvbevidst sammenfatning.

Referencer

- 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

Relaterede artikler

- Tilladte værktøjer vs. åbne agenter - Udforsk det fulde AI-mikro-SaaS-emne-matrix →