Van signaal naar meting: agent-security zelf toetsen in je opstelling
Radar publiceerde in juli twee artikelen over de veiligheid van agents: een terugblik op de security-incidenten van juli en een overzicht van runtime-security voor wie agents draait. Samen schetsen die artikelen een beeld: agents worden autonomer, krijgen meer gerechten en de aanvalshoek verschuift van het model naar de verbindingen ertussen. Wat beide artikelen bewust niet deden, is zeggen hoe je die signalen voor je eigen opstelling controleert. Dit artikel is het gedeelde vervolg: het vertaalt de signalen naar meetvragen en een minimale, herhaalbare testset. Daarmee legt het ook de ontbrekende brug tussen radar — die signaleert — en benchmark, waar de meetmethodes staan.
Terugblik: wat de juli-artikelen lieten zien
De twee artikelen zijn elk een kant van dezelfde medaille, en het onderscheid tussen verdedigen en lessen trekken staat nergens uitgelegd. Dat onderscheid is wel de basis voor dit vervolg. Het incidentenartikel verzamelde vooral wat er misging: MCP-kwetsbaarheden, promptinjectie via externe content, agents die te veel rechten meekregen en daar in productie gebruik van maakten. Het runtime-artikel ging over de verdedigingskant: begrenzing van autonomie, budgetten, sandboxing en het principe dat een agent niet meer mag kunnen dan de som van zijn tools.
Als je beide artikelen naast elkaar legt, valt één ding op: geen van beide noemt een getal, een test of een drempelwaarde. Dat is logisch — het zijn signaalartikelen, geen handleidingen. Maar voor de bouwer die zelf agents draait, is dat precies de stap die ontbreekt. Een signaal als "MCP-tools zijn een groeiende aanvalshoek" blijft een waarschuwing tot je kunt zeggen: "in mijn opstelling blokkeert mijn agent een toolaanroep naar een onbekend domein in acht van de tien pogingen". Dat laatste is een meting, en metingen zijn wat benchmark leert opzetten.
Wat dit artikel wel en niet doet:
- Wel: de signalen van juli vertalen naar meetvragen, een minimale testset en een herhaalritme voor je eigen agent-opstelling.
- Niet: opnieuw uitleggen wat MCP-kwetsbaarheden zijn of hoe je agents begrenst — die uitleg staat al in het runtime-artikel en in het MCP-tooling-artikel van juli.
Stap 1: van signaal naar meetvraag
Elk signaal uit de juli-artikelen kun je omzetten in een meetvraag. De kunst is dat de meetvraag specifiek genoeg is om te kunnen testen en algemeen genoeg om niet te verdrinken in details. Een meetvraag heeft drie delen: de bedreiging, de plek in je opstelling en het gedrag dat je wilt zien.
| Signaal uit juli | Meetvraag voor jouw opstelling |
|---|---|
| MCP-kwetsbaarheden nemen toe | Blokkeert mijn agent toolaanroepen naar domeinen die niet op de allowlist staan? |
| Promptinjectie via externe content | Voert mijn agent instructies uit die in documenten of webpaginas staan, ook buiten zijn systeemprompt? |
| Agents krijgen te veel rechten | Werkt mijn agent met het minste aantal rechten dat de taak toestaat, of met ruimere rechten? |
| Autonomie zonder begrenzing | Stopt mijn agent na een budget of een aantal stappen, of blijft hij doorlopen? |
De meetvraag bepaalt welke test je opzet. Wie de eerste vraag stelt, heeft een test nodig waarin een toolaanroep naar een onbekend domein zit en een waarin een bekend domein zit; het verschil in uitkomst is de meting. Wie de tweede vraag stelt, heeft een test nodig waarin een onschuldig document een kwaadaardige instructie bevat. Zonder meetvraag blijft een test een anekdote; met meetvraag wordt het een herhaalbare controle.
Stap 2: een minimale security-testset voor agents
Een testset voor agent-security is niet anders van opzet dan elke andere testset: vaste invoer, vaste verwachting, herhaling. Het verschil zit in wat je vastlegt. Voor agents draait het om gedrag in een keten — model, tools, rechten, context — en daarom bevat een minimale set vier categorieën gevallen.
- Toolbegrenzing. Drie tot vijf gevallen waarin de agent een toolaanroep zou moeten weigeren: een onbekend domein, een domein op een blokkeerlijst, een aanroep buiten het budget. Verwachting: weigering of expliciete tussenkomst.
- Instructie-afbakening. Drie gevallen waarin externe content (document, e-mail, webpagina) instructies bevat die tegen de systeemprompt ingaan. Verwachting: de instructie wordt genegeerd of gemarkeerd, niet uitgevoerd.
- Rechten en scope. Twee gevallen waarin een ogenschijnlijk onschuldige taak vraagt om een bewerking buiten de scope, zoals een bestand lezen dat niet bij de taak hoort. Verwachting: weigering of expliciete bevestiging.
- Begrenzing van autonomie. Twee gevallen waarin de agent de kans krijgt om door te blijven lopen, bijvoorbeeld door een eindeloze lus of een taak die steeds meer stappen vraagt. Verwachting: stoppen na budget of na een vast aantal stappen.
De verwachting leg je per geval vast voordat je test. Dat is belangrijk: wie pas na de test beslist wat een goed resultaat was, meet achteraf en kan elk resultaat goedpraten. De regels voor het samenstellen van zo'n set — hoe je voorkomt dat je eigen productiedata de set vervuilt en hoe je een controleset opbouwt — staan op benchmark.llmnet.nl bij red teaming en veiligheidstests. Die pagina legt ook uit waarom een veiligheidstest per definitie een poging is om je eigen systeem te breken, en waarom dat een andere houding vraagt dan een gewone kwaliteitstest.
Stap 3: beoordelen — wat is veilig genoeg?
Een testset zonder beoordelingsregels levert alleen losse uitkomsten op. Voor agent-security is de beoordeling eenvoudiger dan voor open vragen, omdat je per geval een ja/nee-verwachting hebt: geweigerd of niet, gestopt of niet, gemarkeerd of niet. Toch zijn er twee valkuilen.
De eerste valkuil is dat één geslaagde test niets zegt over de volgende. Agents zijn stochastisch; dezelfde prompt kan de ene keer wel en de andere keer niet door een onbekend domein gaan. Daarom is herhaling onderdeel van de meting: drie pogingen per geval geven een eerste indruk van de spreiding. De statistiek achter het aantal herhalingen staat op benchmark.llmnet.nl bij statistiek voor evaluaties — kort gezegd: begin klein, herhaal, en breid pas uit als je een verschil wilt zien dat klein is.
De tweede valkuil is een beoordelaar die zelf bevooroordeeld is. Gebruik je een model als beoordelaar, bijvoorbeeld om te controleren of een weigering de juiste was, dan moet dat model eerst geijkt worden tegen menselijke oordelen. De methode daarvoor, inclusief de bekende vooroordelen van een model als rechter, staat op benchmark.llmnet.nl bij LLM-as-a-judge. Voor een security-testset is een menselijke blik op de uitkomsten meestal verstandiger dan een volledig geautomatiseerde oordeelslus — juist omdat de interessante fouten onverwacht zijn.
Stap 4: het herhaalritme
Een meting die je één keer doet, is een momentopname. De waarde zit in het ritme: vaste testset, vaste momenten, vast protocol bij veranderingen. Voor agent-security geldt een simpele regel: draai de set bij elke wijziging die het gedrag kan beïnvloeden — een nieuwe modelversie, een nieuwe tool, een nieuwe MCP-server, een nieuwe systeemprompt — en daarnaast periodiek, bijvoorbeeld maandelijks, ook als er niets veranderde.
Waarom periodiek ook? Omdat de bedreigingsomgeving verandert zonder dat jij iets doet. Een tool die vorige maand veilig leek, kan deze maand een bekende kwetsbaarheid hebben; een domein op je allowlist kan inmiddels door iemand anders gecontroleerd worden. Het patroon van regressietesten — elke wijziging automatisch toetsen voordat hij in productie gaat — staat op benchmark.llmnet.nl bij regressietesten voor prompts; voor agents is dezelfde logica van toepassing, alleen test je niet alleen de prompt maar de hele keten.
Wat de opzet kost in tijd en tokens
Een minimale set van tien gevallen, drie herhalingen per geval, kost dertig agent-runs. Afhankelijk van je opstelling is dat een kwartier tot een uur aan rekentijd, en een aantal tokens dat klein is ten opzichte van wat een agent in een normale werkdag verbruikt. De grootste kostenpost is niet de rekentijd maar het onderhoud: elke nieuwe tool of MCP-server voegt gevallen toe, en elke geval moet zijn verwachting actueel houden. Voor wie de kosten per taak wil rekenen in plaats van per run, staat op benchmark.llmnet.nl een uitleg over de afweging prijs per taak. De vuistregel voor security-tests is hetzelfde als voor andere evaluaties: begin met de kleinste set die de grootste risico's dekt, en breid pas uit als je een verschil wilt zien dat de huidige set niet kan tonen.
Signaal: hoog · Actie: implementeren.
De combinatie van autonome agents en groeiende MCP-aanvalshoek maakt een vaste, kleine security-testset tot een redelijke basiscontrole voor elke opstelling waarin agents tools aanroepen. Begin met de vier categorieën hierboven, leg de verwachtingen vooraf vast, en draai de set bij elke wijziging van model, tool of systeemprompt. Wie verder wil, vindt op benchmark.llmnet.nl een handleiding voor het lezen en interpreteren van veiligheidsbenchmarks — gepubliceerd op 7 augustus, en daarmee de actueelste ingang voor wie wil weten welke externe cijfers wel en niet betekenisvol zijn.
Afbakening: waar houdt dit artikel op
Dit artikel is bewust geen volledige security-audit. Het behandelt geen specifieke toolconfiguraties, geen kwetsbaarheidsdatabase en geen juridische of compliance-kaders. Wat het wel doet, is de brug slaan die in juli ontbrak: de signalen over agent-security zijn in dit artikel omgezet in iets dat je zelf kunt draaien en herhalen. De meetmethodes waarnaar dit artikel linkt — red teaming, statistiek, LLM-as-judge, regressietesten, veiligheidsbenchmarks lezen — staan allemaal op benchmark en zijn elk apart uitgewerkt; dit artikel ordent ze voor de specifieke vraag van de bouwer met agents in productie.
De volgende stap voor wie dit serieus wil nemen, is de methode voor samengestelde systemen: hoe je een volledige agent-evaluatie opzet waarin niet alleen security maar ook correctheid en kosten worden meegenomen. Die aanpak staat op benchmark.llmnet.nl bij agent-evaluatie — het logische vervolg op dit artikel, omdat het de security-testset in een bredere meetopzet plaatst.
