Agent-beveiligingsmaatregelen in kaart gebracht met het NIST AI RMF

Waarom ik AgentGuard heb gebouwd

Ik ben begonnen met AgentGuard nadat ik een team had gezien dat een LLM-aangedreven agent had gemaakt die een database kon lezen, een betalings-API kon aanroepen en een e-mail kon verzenden, allemaal met één prompt. De agent werkte in de demo, maar een eenvoudige typefout in de gebruikersquery zorgde ervoor dat het geld naar het verkeerde account overmaakte. Niemand had gecontroleerd wat de agent mocht doen voordat de aanroep werd gedaan, en er was geen manier om het te stoppen nadat de fout was gebeurd.

Ik realiseerde me dat het probleem niet het model zelf was, maar de ontbrekende grenzen rond zijn acties. Ik wilde een herhaalbare manier hebben om elk instrument te lijsten dat een agent kan bereiken, te beslissen wie elk instrument kan inschakelen, de agent te testen tegen de machtigingen die we denken dat het heeft, en te reageren wanneer iets misgaat. Het NIST AI Risk Management Framework gaf me de vier functies die exact overeenkomen met die stappen.

Kernconcepten: invoerfilters, toolmachtigingen, uitvoercontroles

Invoerfilters

Dit zijn controles die worden uitgevoerd op de gebruikersprompt of de interne redenering van de agent voordat een tool wordt aangeroepen. Voorbeelden zijn:

- Het detecteren van invoerinjectiepatronen die proberen om eerder gegeven instructies te negeren.

- Het controleren op niet-toegestane trefwoorden of zinnen die aangeven dat er een verzoek is om toegang te krijgen tot een beperkt systeem.

- Het valideren dat de prompt een vereiste goedkeurings-token bevat wanneer een tool met een hoog risico wordt verwezen.

We implementeren invoerfilters als lichtgewicht regex-motoren in combinatie met een kleine lijst van veilige patronen. Ze voegen minder dan twee milliseconden latentie per oproep toe.

Toolmachtigingen

Toolmachtigingen definiëren welke gegevens een tool kan lezen, schrijven of verwijderen en welke externe diensten deze kan benaderen. We slaan elke machtiging op als een tuple:

- Tool-identificator

- Toegestane gegevensbronnen (bijv. alleen-lezen-toegang tot de klantentabel, schrijftoegang tot de audit_log)

- Netwerkbestemmingen (bijv. api.paymentprovider.com op poort 443)

- Vereiste goedkeuringsniveau (geen, peer review, manager-goedkeuring)

Wanneer de agent vraagt om een tool te gebruiken, controleert de machtigingsdienst de tuple tegen de huidige context en staat de oproep toe, wijzigt de parameters of blokkeert deze.

Uitvoercontroles

Nadat een tool een resultaat heeft geretourneerd, controleren uitvoercontroles of het antwoord binnen de verwachte grenzen blijft. Voorbeelden zijn:

- Ervoor zorgen dat een SQL-query niet meer dan 100 rijen retourneert.

- Het bevestigen dat een e-mailpayload geen externe URLs bevat.

- Het scannen van gelekte geheimen zoals API-sleutels of wachtwoorden in het antwoord.

Als een controle faalt, kan het systeem het resultaat afkappen, gevoelige delen maskeren of een waarschuwing activeren.

Toewijzing van guardrails aan NIST AI RMF-functies

Het kader met vier functies biedt een duidelijke structuur voor het organiseren van guardrail-werk. Hieronder staat een tabel die aangeeft welke guardrail bij elke functie hoort, het concrete artifact dat we produceren en een kort voorbeeld.

NIST-functie | Guardrail-type | Artifact | Voorbeeld Govern | Goodkeuringsworkflow | Tool-inschakelingsrecord | Een ondertekend document dat aangeeft wie de send_email-tool heeft goedgekeurd, de datum en de vereiste MFA voor de goedkeurder. Map | Tool-inventaris | Machtigingsmatrix | Een spreadsheet die elk tool opsomt, de tabellen die het kan lezen/schrijven en de externe eindpunten die het kan bellen. Measure | Testset | Set van tegenwerkende prompts | Een verzameling prompts ontworpen om privilege-escalatie, data-exfiltratie of ongeautoriseerde externe oproepen te activeren. Manage | Runtime-reactie | Kill-switch-log | Een getijdstemplede vermelding die registreert wanneer de agent heeft geprobeerd een productierecord te verwijderen, de actie die werd geblokkeerd en de operator die werd verwittigd.

Elke functie bouwt voort op de vorige. Govern beslist wie een nieuwe tool aan de inventaris mag toevoegen. Map maakt de inventaris die Measure zal testen. Measure levert bewijs dat Manage kan activeren. De cyclus herhaalt zich telkens wanneer de toollijst of de prompt van de agent verandert.

Hoe we een toolaanroep beoordelen

Stap 1: Identificeer de tool en zijn machtigingsklasse

We beginnen met het opzoeken van de tool in de machtigingsmatrix. De matrix wijst een basisrisiconiveau toe:

- Alleen-lezen opzoeken (bijv. ophalen van een productcatalogus) → laag - Schrijven naar een intern logboek → medium - Externe actie met neveneffecten (bijv. geld verzenden, een record verwijderen) → hoog

Als de tool een goedkeuringstoken vereist, voegen we één niveau toe aan het basisrisico.

Stap 2: Analyseer de prompt voor injectierisico

We voeren de gebruikersprompt uit via de invoerfilterengine. Als de engine een patroon detecteert uit de OWASP-promptinjectie-kaart (https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html), verhogen we het risico met één niveau.

Stap 3: Controleer gegevensgevoeligheid

We onderzoeken de gegevensbronnen die de tool kan aanraken. Als een bron persoonlijk identificeerbare informatie (PII) of financiële gegevens bevat, voegen we nog een niveau toe.

Stap 4: Produceer de definitieve beoordeling en aanbevolen filters

De definitieve beoordeling is de som van het basisniveau, promptniveau en dataniveau. Op basis van de beoordeling raden we aan:

- Laag → geen extra filter, log alleen de aanroep. - Medium → voeg een invoerfilter toe dat niet-toegestane trefwoorden verwijdert en een uitvoercontrole die de rijtelling beperkt. - Hoog → vereis een mens-in-de-lus-goedkeuring, dwing een strikte toegestane lijst van parameters af en schakel volledige uitvoerredactie in.

Wat dit niet is

Ik wil duidelijk zijn over de beperkingen van guardrails, zodat je ze niet verwart met een zilveren kogel.

- Guardrails garanderen niet dat een agent nooit schade zal veroorzaken. Ze verminderen de omvang van een fout, maar een vastberaden aanvaller of een slecht gescopeerde tool kan nog steeds ongewenste effecten produceren binnen de toegestane grenzen. - Ze zijn geen vervanging voor veilige programmeertechnieken. Als de onderliggende tool een kwetsbaarheid heeft (bijvoorbeeld een SQL-injectiekwetsbaarheid zoals beschreven in de SQL-injectie cheat sheet https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html), kan de guardrail deze kwetsbaarheid niet verhelpen. - Ze bieden geen 100 % veiligheidscertificering. Denk aan ze als beslissingsondersteunende hulpmiddelen die je helpen bij het maken van geïnformeerde keuzes over het gebruik van tools. - Ze zijn geen set-and-forget-configuratie. Telkens wanneer de agentprompt, de toollijst of de gegevens die een tool kan bereiken, verandert, moet je het beoordelingsproces opnieuw uitvoeren.

In de praktijk brengen: een stap-voor-stap review workflow

1. Verzamel de systeemprompt en de toollijst van de agent

Exporteer de exacte tekst die de agent bij opstarten ontvangt en het JSON- of YAML-bestand dat elke tool verklaart die het kan aanroepen.

2. Vul de machtigingsmatrix in

Voor elke tool noteer:

- Toegestane leestoewijzingen - Toegestane schrijfdoelen - Externe eindpunten en vereiste authenticatie - Eventuele goedkeuringstoken of rollen die nodig zijn

3. Voer de basisklasse risicobeoordeling uit

Pas het vierstappenbeoordelingsproces toe zoals eerder beschreven. Noteer het initiële risicolevel voor elke tool.

4. Genereer suggesties voor invoer- en uitvoerfilters

Op basis van het risicolevel, produceer concrete filterregels (regex-patronen, rijlimieten, redactieregels). Sla ze op naast de tooldefinitie.

5. Voer de adversarial test suite uit

Voer de agent uit tegen de promptset uit de Meetkolom van de tabel. Verifieer dat de filters de verwachte foutmodi blokkeren of mitigeren.

6. Documenteer het resultaat

Maak een kort rapport dat de volgende punten bevat:

- Toolnaam - Initiële risicobeoordeling - Toegepaste filters - Testresultaten (geslaagd/mislukt) - Eventuele vereiste handmatige goedkeuringsstappen

7. Stel monitoring en waarschuwingen in

Configureer de runtime-omgeving van de agent om elke toolaanroep, de toegepaste filters en de uitvoercontroleresultaten te loggen. Routeer afwijkingen naar uw incidentresponskanaal.

8. Plan een reviewtrigger in

Markeer de workflow om te herhalen wanneer een van de volgende gebeurtenissen plaatsvindt:

- Een nieuwe tool wordt toegevoegd aan de lijst - De systeemprompt wordt bewerkt - De machtiging van een tool wijzigt (bijvoorbeeld een database krijgt een nieuwe kolom met PII)

Gangbare valkuilen en hoe we deze vermijden

Valkuil 1: Te veel vertrouwen op een enkel filtertype

Teams denken soms dat het toevoegen van een keyword-blocker voldoende is. Wij counteren dit door zowel invoer- als uitvoercontroles voor elk medium- of hoogrisicogereedschap te vereisen, en we loggen wanneer een van deze controles wordt geactiveerd.

Valkuil 2: Vergeten om de machtigingsmatrix bij te werken

Wanneer een gereedschap een nieuwe functionaliteit krijgt (bijv. een betalings-API die nu ook refunds ondersteunt), moet de matrix worden bewerkt voordat de agent het kan gebruiken. Wij dwingen dit af door de matrix een versiebeheerde bestand te maken dat de CI-pipeline valideert bij elke push.

Valkuil 3: Laagrisicogereedschappen die in context hoogrisico worden, negeren

Een alleen-lezen-zoekopdracht die een gebruikers e-mailadres retourneert, kan gevaarlijk worden als de agent later dat adres gebruikt in een wachtwoord-herstelstroom. Wij behandelen gegevensgevoeligheid als een aparte beoordelingsfactor, zodat een laagwaardig gereedschap dat PII aanraakt, automatisch wordt geüpgraded.

Valkuil 4: Het mens-in-de-lus-stap overslaan voor hoogrisicogereedschappen

Voor gereedschappen die geld kunnen overmaken of records kunnen verwijderen, vereisen wij een expliciete goedkeuringsstap die niet kan worden omzeild door automatisering. De goedkeuring wordt opgenomen in een onveranderlijke log.

Valkuil 5: De guardrail-instelling behandelen als een eenmalige taak

Wij integreren de review-workflow in de teams definitie van klaar voor elke functionaliteit die het gedrag van de agent verandert. Dit maakt het proces herhaalbaar in plaats van een vergeten checklist-item.

Referenties

- https://genai.owasp.org/llmrisk/-prompt-injectie - https://owasp.org/www-project-top-10-ci-cd-security-risks/CICD-SEC-06-Onvoldoende-Credential-Hygiëne - https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injectie_Preventie_Cheat_Sheet.html - https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injectie_Preventie_Cheat_Sheet.html

Vaak gestelde vragen

Zorgen guardrails ervoor dat een agent veilig is?

Nee. Ze beperken de omvang van een fout. Een vastberaden aanvaller, een verkeerd geconfigureerd hulpmiddel of een slechte prompt kunnen nog steeds schade veroorzaken binnen de grenzen die u hebt toegestaan.

Wat hebben we nodig om een review uit te voeren?

De systeemprompt van de agent en zijn toollijst. Dat is voldoende om aanroepen te beoordelen en filters voor te stellen.

Is de EU AI Act-toewijzing juridisch advies?

Nee. Het is een toewijzing om u te helpen de juiste verplichtingen te vinden. Het classificeren van uw systeem en het nakomen van de verplichtingen heeft nog steeds een gekwalificeerde reviewer nodig.

Hoe vaak moeten we het opnieuw uitvoeren?

Telkens wanneer de toollijst, de systeemprompt of de gegevens die een tool kan bereiken, verandert.

Test het de agent tijdens runtime?

Het beoordeelt de prompt en de toolconfiguratie. Runtime-bewaking is een aparte laag die u nog steeds nodig heeft.

Wat als een tool echt een hoog risico heeft?

Een goedkeuringsstap vereisen, de parameters verkleinen en elke oproep loggen. Hulpmiddelen met een hoog risico hebben meestal een mens in de lus nodig in plaats van een filter.

Referenties

- OWASP — Top 10 voor Large Language Model-toepassingen

- — Richtlijnen voor het gebruik van AI

Probeer het product: AgentGuard

Gerelateerde artikelen

- AI-agenttool-allowlists: waarom deny-by-default wint - Verken de volledige AI micro-SaaS-onderwerpmatrix →