Agent-sikkerhedsforanstaltninger tilknyttet NIST AI RMF

Hvorfor jeg byggede AgentGuard

Jeg startede AgentGuard efter at have set en gruppe afskibe en LLM-dreven agent, der kunne læse en database, ringe til en betalings-API og sende e-mail, alt med en enkelt prompt. Agenten virkede i demoen, men en simpel tastefejl i brugerens forespørgsel fik den til at overføre penge til den forkerte konto. Ingen havde kontrolleret, hvad agenten havde lov til at gøre, før opkaldet, og der var ingen måde at stoppe det, når fejlen var sket.

Jeg indså, at problemet ikke var modellen i sig selv, men de manglende grænser omkring dens handlinger. Jeg ønskede en gentagen måde at liste alle værktøjer, en agent kan nå, beslutte, hvem der kan aktivere hvert værktøj, teste agenten mod de tilladelser, vi mener, den har, og reagere, når noget går galt.

I de følgende afsnit viser jeg, hvordan hver funktion afspejler sig i konkrete sikkerhedspraksis, hvordan vi vurderer risikoen for et værktøjskald, og hvad du faktisk kan gøre i dag med AgentGuard-produktet, med værktøjer som.

Kernecooncepts: inddatafiltre, værktøjsrettigheder, udgangskontroller

Inddatafiltre

Disse er kontroller, der køres på brugerens prompt eller agentens interne resonnering, før et værktøj aktiveres. Eksempler omfatter:

- At detektere promptinjektionsmønstre, der forsøger at ignorere tidligere instruktioner. - At kontrollere for ikke-tilladte nøgleord eller fraser, der signalerer en anmodning om adgang til et begrænset system. - At validere, at prompten indeholder en påkrævet godkendelsestoken, når et værktøj med høj risiko henvises til.

Vi implementerer inddatafiltre som letvægtige regex-motorer kombineret med en lille tilladt liste over sikre mønstre. De tilføjer mindre end to millisekunders forsinkelse per opkald.

Værktøjsrettigheder

Værktøjsrettigheder definerer, hvilke data et værktøj kan læse, skrive eller slette, og hvilke eksterne tjenester det må kontakte. Vi gemmer hver rettighed som en tuple:

- Værktøjsidentifikator - Tilladte datakilder (f.eks. kun læseadgang til kundetabel, skriveadgang til audit_log) - Netværksdestinationer (f.eks. api.paymentprovider.com på port 443) - Krævet godkendelsesniveau (ingen, peer-review, ledergodkendelse)

Når agenten beder om at bruge et værktøj, kontrollerer rettighedstjenesten tuplen mod den aktuelle kontekst og tillader enten opkaldet, ændrer parametrene eller blokerer det.

Udgangskontroller

Efter et værktøj returnerer et resultat, kontrollerer udgangskontrollerne, at svaret forbliver inden for de forventede grænser. Eksempler:

- At sikre, at en SQL-forespørgsel returnerer ingen mere end 100 rækker. - At bekræfte, at en e-mail-nyttestof ikke indeholder eksterne URL'er. - At scannere efter lækkede hemmeligheder, såsom API-nøgler eller adgangskoder i svaret.

Hvis en kontrol mislykkes, kan systemet afkorte resultatet, censurere følsomme dele eller udløse en alarm.

Tilordning af guardrails til NIST AI RMF-funktioner

Rammeværkets fire funktioner giver en klar struktur for at organisere guardrail-arbejdet. Nedenfor vises en tabel, der viser, hvilken guardrail der hører til hver funktion, det konkrete artifact, vi producerer, og et kort eksempel.

NIST-funktion | Guardrail-type | Artifact | Eksempel Styr | Godkendelsesworkflow | Værktøjsaktiveringsrecord | En underskrevet dokument, der nævner, hvem der godkendte send_email-værktøjet, dato og det krævede MFA for godkenderen. Kortlæg | Værktøjsinventar | Tilladelsesmatrix | En spreadsheet, der opregner hvert værktøj, de tabeller det kan læse/skrive, og de eksterne endepunkter det må ringe til. Mål | Testsuite | Adversarial prompt-sæt | En samling af prompts designede til at udløse privilegie-escalation, data-ekstraktion eller uautoriserede eksterne opkald. Styring | Runtime-svar | Kill-switch-log | En tidsstempel-indsætning, der optager, når agenten forsøgte at slette en produktionspost, den handling der blev blokeret, og den operatør, der blev underrettet.

Hver funktion bygger på den foregående. Styr beslutter, hvem der må tilføje et nyt værktøj til inventaret. Kortlægning opretter inventaret, som Mål vil teste imod. Mål producerer bevis, som Styring kan handle på. Løkken gentager sig, hver gang værktøjslisten eller agentens prompt ændres.

Hvordan vi vurderer et værktøjskald

Trin 1: Identificer værktøjet og dets tilladelsesklasse

Vi starter med at se værktøjet op i tilladelsesmatricen. Matricen tildeler en grundlæggende risikoniveau:

- Kun læs-adgang (f.eks. hentning af et produktkatalog) → lav - Skriv til en intern log → medium - Ekstern handling med sideeffekter (f.eks. sending af penge, sletning af en post) → høj

Hvis værktøjet kræver en godkendelsestoken, tilføjer vi et niveau til det grundlæggende risikoniveau.

Trin 2: Analyser prompten for injektionsrisiko

Vi kører brugerens prompt gennem inputfilter-motoren. Hvis motoren detekterer et mønster fra OWASP-prompt-injektions-cheatsheetet (https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html), øger vi risikoniveauet med ét.

Trin 3: Kontroller datafølsomhed

Vi undersøger datakilderne, som værktøjet kan berøre. Hvis en af kilderne indeholder personfølsomme oplysninger (PII) eller finansielle data, tilføjer vi endnu et niveau.

Trin 4: Producer den endelige vurdering og foreslåede filtre

Den endelige vurdering er summen af det grundlæggende niveau, prompt-niveau og data-niveau-justeringer. Baseret på vurderingen anbefaler vi:

- Lav → ingen yderligere filter, blot log kaldet. - Medium → tilføj et inputfilter, der fjerner ikke-tilladte nøgleord, og en outputkontrol, der begrænser rækkenummer. - Høj → kræv en menneske-i-løkken-godkendelse, gennemfør en streng tilladelsesliste over parametre, og aktiver fuld output-redigering.

Hvad dette ikke er

Jeg vil gerne gøre det klart, hvad guardrails ikke kan, så du ikke forveksler dem med en mirakelkur.

- Guardrails garanterer ikke, at en agent aldrig vil kunne forårsage skade. De reducerer skadens omfang, hvis der sker en fejl, men en fastbesluttet angriber eller et dårligt konfigureret værktøj kan stadig producere uønskede effekter inden for den tilladte grænse. - De er ikke en erstatning for sikker kodning. Hvis det underliggende værktøj har en sårbarhed (f.eks. en SQL-injektionssvaghed beskrevet i SQL-injektionsskemaet https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html), kan guardrails ikke fikse denne svaghed. - De giver ikke en 100 % sikkerhedscertificering. Tænk på dem som beslutningsstøttemidler, der hjælper dig med at træffe informerede valg om værktøjsbrug. - De er ikke en konfiguration, der kan sættes og glemmes.

Praktisk gennemførelse: en trin-for-trin gennemgang af workflow

1. Saml agentens systemsætning og værktøjsliste

Eksporter den præcise tekst, som agenten modtager ved opstart, og JSON- eller YAML-filen, der erklærer hver værktøj, det kan kalde.

2. Udfyld tilladelsesmatricen

For hvert værktøj, optegn:

- Tilladte læseobjekter - Tilladte skriveobjekter - Eksterne endepunkter og påkrævet godkendelse - Eventuelle godkendelsestoken eller roller, der er nødvendige

3. Kør baseline-risikovurdering

Anvend den firetrins vurderingsproces, der er beskrevet tidligere. Optegn den initiale risikoniveau for hvert værktøj.

4. Generér inddata- og uddatafilterforslag

Baseret på risikoniveauet, producér konkrete filterregler (regex-mønstre, rækkeantalbegrænsninger, redigeringsregler). Gem dem sammen med værktøjsdefinitionen.

5. Udfør adversarial-testsuite

Kør agenten mod systemsætningen fra Målepunkt-kolonnen i tabellen. Verificér, at filterne blokerer eller mildner de forventede fejltilstande.

6. Dokumentér resultatet

Opret en kort rapport, der listar:

- Værktøjsnavn - Initial risikovurdering - Anvendte filter - Testresultater (bestået/fejlet) - Eventuelle påkrævede manuelle godkendelsesstadier

7. Konfigurer overvågning og alarmer

Konfigurer agentens kørmiljø til at logge hver værktøjskald, de anvendte filter og outputkontrolresultaterne. Ruter afvigelser til din incidentrespons-kanal.

8. Planlæg en gennemgangsutløser

Marker workflow til at gentage, når en af følgende begivenheder indtræffer:

- Et nyt værktøj tilføjes til listen - Systemsætningen redigeres - Et værktøjs tilladelse ændres (f.eks. en database får en ny kolonne med PII)

Almindelige fælder og hvordan vi undgår dem

Fælde 1: Overafhængighed af en enkelt filtertype

Holdene tror nogle gange, at tilføjelse af en nøgleordsblokerer er nok. Vi modvirker dette ved at kræve både indtastnings- og udgangstjek for ethvert medium eller højrisikoværktøj, og vi logger, når enten tjek aktiveres.

Fælde 2: At glemme at opdatere tilladelsesmatricen

Når et værktøj får en ny funktion (f.eks. en betalings-API, der nu understøtter refunderinger), skal matricen redigeres, før agenten kan bruge den. Vi gennemtvinger dette ved at gøre matricen til en versionsstyret fil, som CI-pipeline-valideringen kontrollerer ved hver push.

Fælde 3: At ignorere lavrisikoværktøjer, der bliver højrisiko i kontekst

En skrivebeskyttet opslag, der returnerer en brugers e-mail-adresse, kan blive farlig, hvis agenten senere bruger den adresse i en adgangskode-nulstilling. Vi behandler datasensitivitet som en separat vurderingsfaktor, så et lavtniveau-værktøj, der berører personfølsomme oplysninger, automatisk opgraderes.

Fælde 4: At springe over menneske-i-løkkeskridtet for højrisikoværktøjer

For værktøjer, der kan flytte penge eller slette poster, kræver vi en eksplitt godkendelsesstep, der ikke kan omgås af automatisering. Godkendelsen optages i en uændelig log.

Fælde 5: At behandle sikkerhedsforanstaltningerne som en engangsgennemført opgave

Vi integrerer gennemgangsarbetsprocessen i holdets definition af færdig for enhver funktion, der ændrer agentens adfærd. Dette gør processen gentagenlig i stedet for en glemt checkliste-punkt.

Referencer

- https://genai.owasp.org/llmrisk/-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

Ofte stillede spørgsmål

Gør guardrails en agent sikker?

Nej. De begrænser skadeområdet af en fejl. En besluttet angriber, et værktøj med forkert omfang eller en dårlig prompt kan stadig forårsage skade inden for den grænse, du har tilladt.

Hvad har vi brug for for at køre en gennemgang?

Agentens systemsætning og dens værktøjsliste. Det er nok til at vurdere opkald og foreslå filtre.

Er EU's AI-lov en juridisk vejledning?

Nej. Det er en vejledning til at hjælpe dig med at finde de rigtige forpligtelser. Klassificering af dit system og opfyldelse af forpligtelserne kræver stadig en kvalificeret gennemgang.

Hvor ofte skal vi køre det igen?

Hver gang værktøjslisten, systemsætningen eller data, som et værktøj kan nå, ændres.

Tester det agenten på kørselstidspunktet?

Det gennemgår prompten og værktøjskonfigurationen. Overvågning på kørselstidspunktet er en separat lag, du stadig har brug for.

Hvad hvis et værktøj er ægte højrisiko?

Kræv en godkendelsesproces, begræns dets parametre og log hver aktivering. Højrisikoværktøjer har normalt brug for en menneskelig faktor i stedet for et filter.

Referencer

- OWASP — Top 10 for store sprogmodelapplikationer - NIST — Ramme for AI-risikostyring

Prøv produktet: AgentGuard

2026-09-20 · kun primærkilder · ingen fabrikerede trafikmålinger · beslutningsstøtte kun

Relaterede artikler

- Tilladelser til AI-agentværktøj: hvorfor deny-by-default sejrer - Udforsk det fulde AI mikro-SaaS emne matrix →