Je AI-agent kan bij je productiedatabase. Heb je dat getest?

TL;DR

• Coding agents en MCP-integraties krijgen vaak veel ruimere permissies dan iemand bedoelt.
• Een prompt-instructie als "verwijder de database nooit" is geen beveiligingsmaatregel. Een agent kan een script schrijven dat het toch doet.
• Vertrek vanuit een aanname: alles wat een agent kan lezen of aanraken, doet hij vroeg of laat, ook als niemand het vroeg.
• Echte incidenten gebeuren al: gewiste databases, ongewenste massamails en secret keys die lekken in client-side code.
• Mensgestuurd testen van AI-agents, MCP-servers en hun integraties vindt die gaten voor een aanvaller of een ongeluk dat doet.

Teams koppelen AI-agents razendsnel aan hun werking: coding assistants, MCP-servers en geautomatiseerde workflows met toegang tot een CRM, een code-repository en soms een productiedatabase. De winst is echt, en het nieuwe aanvalsoppervlak ook, maar bijna niemand test het. Als je een agent hebt gekoppeld aan systemen die ertoe doen, is de vraag eenvoudig: weet je echt wat hij kan bereiken, en wat er gebeurt als hij iets doet waar je nooit om vroeg? Net dat dekt onze pentest voor AI- en agentic systemen, die deel uitmaakt van ons bredere aanbod pentestdiensten.

Een prompt is geen permissielaag

De meest gemaakte fout is instructies behandelen als guardrails. Een agent zeggen dat hij een database nooit mag wissen, houdt hem niet tegen. Blokkeer je delete-commando's, dan kan de agent nog steeds een script schrijven dat verwijdert en dat script vervolgens uitvoeren. Dat zijn twee stappen, geen nul. De maatregel hoort in het permissiemodel te zitten, niet in de formulering van een prompt. Scoped keys, beperkte tokens en expliciete allow-lists zijn maatregelen. Een zin in een system prompt is een suggestie.

Dat is dezelfde logica die onze ethical hackers op elk systeem toepassen. Je gaat niet uit van goed gedrag. Je gaat ervan uit dat het pad bestaat en test of het bewandeld kan worden.

Het assume-touch principe

Dit is de aanname die de ergste scenario's voorkomt: alles wat een agent kan lezen of aanraken, zal hij gebruiken. Niet uit kwade wil, maar omdat agents handelen op gedeeltelijke context en hun eigen takenlijst verkeerd lezen. Een echt voorbeeld dat de ronde doet: een agent die een taak verkeerd interpreteerde en een kortingsmail naar een volledige mailinglijst stuurde die nooit had mogen vertrekken. Niemand vroeg erom. Hij had de toegang, dus gebruikte hij ze.

Wanneer je een agent afbakent, vertrek vanuit die aanname. Elke credential die hij heeft, elk bestand dat hij kan lezen, elke tool die hij kan aanroepen is iets dat hij op het slechtst denkbare moment kan gebruiken. Als die gedachte je ongemakkelijk maakt over een specifieke permissie, dan is dat ongemak de bevinding.

Waar de echte gaten zitten

In de praktijk clusteren de gaten op een paar plaatsen. MCP-server-permissies die veel meer toekennen dan de workflow nodig heeft. Secret keys en tokens die in client-side JavaScript belanden door snelle, ongevalideerde builds. Hooks en validatiestappen die op beveiliging lijken maar in twee zetten te omzeilen zijn. Testomgevingen die als veilig worden beschouwd maar nog aan echte data hangen. En klassieke prompt injection, zowel direct als indirect, om instructies binnen te smokkelen via content die de agent leest. Geen van deze zaken komt boven als je enkel de output van de agent leest. Ze komen boven wanneer iemand de toegang actief probeert te misbruiken.

Wat we testen in een agentic SaaS-omgeving

Wanneer een AI-assistent namens een gebruiker handelt in een multi-tenant SaaS-platform, draaien de zwaarste problemen om bevoegdheid, niet om taal. We testen tenant isolation, autorisatie- en rechtencontroles binnen de assistent, privilege escalation via de AI-laag, excessive agency, ongeautoriseerde of onbedoelde toolaanroepen, en misbruik van resourceverbruik dat de platformstabiliteit kan raken. Het principe dat we verifieren is eenvoudig: de AI mag uitsluitend handelen binnen de rechten van de gebruiker die hem aanroept, en die grens moet standhouden onder actieve aanval.

We werken vanuit de OWASP Top 10 for LLM Applications en de OWASP Top 10 for Agentic Applications (2026), aangevuld met contextspecifieke aanvalsketens voor jouw architectuur. De fases zijn dezelfde als bij elke opdracht: reconnaissance, scanning, exploitation in zowel niet-geauthenticeerde als geauthenticeerde context, post-exploitation, en rapportage met een debriefing.

Validatie blijft mensenwerk

AI versnelt het werk. Het valideert het niet. Een coding agent haalt met goede verificatiechecks een hoge slaagkans, en veel minder zonder. Op eigen houtje haalt hij nooit zekerheid. De laatste laag, bevestigen dat een bevinding echt is en dat een fix het gat ook werkelijk dicht, is mensenwerk. Dat is de lijn die wij in elke opdracht aanhouden: AI mag de workflow ondersteunen, een menselijke ethical hacker valideert het resultaat. Geen AI-only scanning.

Veelgestelde vragen

Wat is pentesting van AI-agents?

Het is een security assessment van de AI-agents, modellen en integraties die je organisatie draait, gericht op wat die agents kunnen bereiken en hoe die toegang misbruikt kan worden. Het dekt permissie-afbakening, MCP-serverconfiguratie, blootstelling van secrets, misbruik van toolaanroepen en omzeilbare maatregelen.

Is een prompt-instructie genoeg om een AI-agent te controleren?

Nee. Een prompt is een suggestie, geen beveiligingsgrens. Een agent kan een instructie omzeilen, onder meer door een script te schrijven en uit te voeren dat doet wat hem rechtstreeks verboden werd. Echte maatregelen zitten in scoped permissies en beperkte credentials.

Wat zijn de meest voorkomende beveiligingsgaten bij AI-agents?

Te ruime MCP-server-permissies, secret keys gelekt in client-side code, maatregelen die in enkele stappen te omzeilen zijn, testomgevingen die nog aan echte data hangen, en prompt injection om instructies binnen te smokkelen via content die de agent leest.

Kunnen jullie AI-agents in een multi-tenant SaaS-platform testen?

Ja. We richten ons op tenant isolation, autorisatie- en rechtencontroles binnen de assistent, privilege escalation via de AI-laag, excessive agency, ongeautoriseerde toolaanroepen en misbruik van resourceverbruik. Lees meer op onze pagina over pentesting van AI- en agentic systemen.

Kan AI zijn eigen beveiliging testen?

AI kan mogelijke problemen en edge cases naar boven halen, wat nuttig is. Het kan niet betrouwbaar bevestigen of een bevinding echt is of dat een fix standhoudt. Die validatie is mensenwerk, en het is de kern van hoe wij werken.

Gerelateerde diensten en bronnen

Dit werk valt binnen onze pentestdiensten, met een specifieke focus op AI- en agentic systemen. Wil je de achtergrond bij een van de bovenstaande technieken, dan legt onze gids over prompt injection uit hoe aanvallers AI-systemen manipuleren. Rol je AI-agents uit over je werking, dan is een assessment nu veel goedkoper dan een incident later.