Waarom AI vraagt om een andere manier van pentesten

AI wordt in hoog tempo onderdeel van de dagelijkse bedrijfsvoering. Medewerkers gebruiken Microsoft Copilot of ChatGPT om documenten samen te vatten, ontwikkelteams bouwen toepassingen met Azure OpenAI en steeds meer organisaties experimenteren met AI-agents die zelfstandig informatie kunnen ophalen of acties kunnen uitvoeren. Dat biedt veel mogelijkheden, maar introduceert ook beveiligingsrisico’s die met een traditionele penetratietest niet volledig worden afgedekt.

Een reguliere pentest richt zich voornamelijk op kwetsbaarheden in applicaties, infrastructuur en API’s. Daarbij wordt onderzocht of een aanvaller toegang kan krijgen tot systemen, rechten kan uitbreiden of gevoelige informatie kan buitmaken. Die aanpak blijft ook bij AI-oplossingen belangrijk, maar is niet voldoende. AI voegt namelijk nieuwe aanvalsmogelijkheden toe, zoals prompt injection, manipulatie van kennisbronnen en misbruik van AI-agents. Om die risico’s goed te onderzoeken, is een andere testaanpak en aanvullende expertise nodig.

Een AI-oplossing is meer dan alleen een model

Bij AI wordt al snel gedacht aan een chatbot of een taalmodel dat vragen beantwoordt. In de praktijk bestaat een AI-oplossing meestal uit veel meer onderdelen. Het model is gekoppeld aan een applicatie, gebruikt informatie uit interne of externe databronnen en werkt met accounts, rechten en API’s. Soms kan de AI via een agent ook zelfstandig handelingen uitvoeren, zoals het opzoeken van klantgegevens, het versturen van een e-mail of het aanmaken van een ticket.

Juist die koppelingen maken AI interessant voor een aanvaller. Het risico zit namelijk niet alleen in wat het model zegt, maar vooral in wat het model kan bereiken. Een AI-assistent die uitsluitend algemene vragen beantwoordt, heeft een ander risicoprofiel dan een assistent die toegang heeft tot SharePoint, e-mail, klantgegevens en interne systemen.

Een goede AI-penetratietest kijkt daarom niet alleen naar het gedrag van het model, maar naar de volledige omgeving eromheen. Daarbij is het belangrijk om te begrijpen welke gegevens beschikbaar zijn, welke rechten de AI heeft en welke systemen vanuit de AI kunnen worden benaderd.

Een aanval kan beginnen met een onschuldig document

Een bekende aanvalstechniek is prompt injection. Daarbij probeert een aanvaller de instructies van een AI-systeem te beïnvloeden. Dat kan rechtstreeks, bijvoorbeeld door een chatbot een gemanipuleerde opdracht te geven, maar het kan ook indirect gebeuren via informatie die de AI verwerkt.

Stel dat een medewerker een AI-assistent vraagt om een ontvangen PDF samen te vatten. In het document heeft een aanvaller verborgen instructies geplaatst die voor de medewerker niet zichtbaar zijn, maar door de AI wel worden verwerkt. De instructies proberen de AI bijvoorbeeld te bewegen om vertrouwelijke informatie uit een gekoppelde kennisomgeving op te zoeken en in het antwoord te verwerken.

De medewerker heeft in dit scenario niets ongebruikelijks gedaan. Het document ziet er normaal uit en de opdracht om het samen te vatten is legitiem. Toch kan de AI worden beïnvloed door instructies die afkomstig zijn van een externe bron. Dit wordt indirect prompt injection genoemd.

De impact van zo’n aanval hangt sterk af van de rechten van de AI. Wanneer de assistent alleen het aangeleverde document kan lezen, blijft de schade mogelijk beperkt. Heeft dezelfde assistent ook toegang tot interne documenten, e-mail of andere bedrijfssystemen, dan kan een ogenschijnlijk eenvoudige prompt injection het begin vormen van een veel groter aanvalspad.

De rechten achter de AI bepalen het risico

AI-oplossingen maken vaak gebruik van bestaande gebruikersaccounts, serviceaccounts of technische identiteiten. Daarmee kunnen ze toegang krijgen tot gegevens en functionaliteiten binnen de organisatie. Dat is handig, maar het betekent ook dat de beveiliging van identities en autorisaties een belangrijk onderdeel wordt van AI-security.

Een aanvaller kijkt niet alleen naar de vraag of een AI ongewenste instructies uitvoert. Veel interessanter is wat er daarna mogelijk is. Kan de AI informatie benaderen die de gebruiker zelf niet mag zien? Kan een agent acties uitvoeren zonder aanvullende controle? Zijn de rechten breder dan noodzakelijk? En kan een aanvaller verschillende zwakke plekken combineren?

Een aanval kan bijvoorbeeld beginnen met een verborgen instructie in een document, waarna een AI-agent wordt aangezet om een gekoppelde databron te raadplegen. Als de identity achter de agent te ruime rechten heeft, kan de aanvaller mogelijk informatie bereiken die anders goed was afgeschermd. De route loopt dan van prompt naar AI-agent, vervolgens naar een identity en uiteindelijk naar een databron of achterliggend systeem.

Daarom is het bij een AI-penetratietest niet voldoende om alleen te onderzoeken of een model kan worden misleid. De werkelijke vraag is welke gevolgen dat binnen de volledige omgeving kan hebben.

MCP en de AI Supply Chain

Een belangrijke ontwikkeling binnen AI is het Model Context Protocol, beter bekend als MCP. Dit protocol maakt het mogelijk om AI-systemen op een gestandaardiseerde manier te koppelen aan externe tools, databronnen en applicaties. Daardoor kan een AI-assistent bijvoorbeeld bestanden ophalen, informatie uit een bedrijfsapplicatie gebruiken of een actie uitvoeren via een externe dienst.

MCP maakt AI-oplossingen krachtiger en eenvoudiger uit te breiden, maar introduceert ook nieuwe afhankelijkheden. Een organisatie vertrouwt niet alleen op het AI-model en de eigen applicatie, maar ook op de MCP-servers en tools waarmee de AI communiceert. Wanneer een vertrouwde MCP-server wordt gecompromitteerd of gemanipuleerd, kan een aanvaller mogelijk invloed uitoefenen op de informatie die de AI ontvangt of op de acties die de AI uitvoert.

Hiermee wordt de AI Supply Chain een belangrijk onderdeel van de beveiliging. Een moderne AI-oplossing bestaat uit een keten van modellen, applicaties, identities, agents, MCP-servers, API’s, databronnen en externe leveranciers. Een kwetsbaarheid in één onderdeel kan gevolgen hebben voor de rest van de keten.

Dit principe is niet volledig nieuw. Organisaties houden al langer rekening met risico’s in de software supply chain. AI voegt daar echter nieuwe vormen van vertrouwen aan toe. Het model verwerkt informatie uit verschillende bronnen en bepaalt op basis daarvan welke vervolgstappen worden gezet. Wanneer die bronnen of tools niet betrouwbaar zijn, kan dat direct invloed hebben op het gedrag van de AI.

Een AI-pentest kijkt naar de volledige keten

Tijdens een AI-penetratietest onderzoeken de specialisten van Access42 niet alleen hoe het taalmodel reageert op gemanipuleerde opdrachten. We kijken ook naar de applicatie, gekoppelde databronnen, identities, autorisaties, AI-agents, MCP-servers, API’s en andere integraties.

Daarbij simuleren we realistische aanvalsscenario’s. We onderzoeken bijvoorbeeld of beveiligingsmaatregelen kunnen worden omzeild, of gevoelige informatie kan worden opgevraagd en of een AI-agent kan worden aangezet tot het uitvoeren van ongewenste acties. Ook bekijken we of een gebruiker via de AI toegang kan krijgen tot gegevens waarvoor diegene normaal gesproken niet is geautoriseerd.

Het doel is niet om alleen losse kwetsbaarheden te vinden, maar om te bepalen welke aanvalspaden een aanvaller in de praktijk kan gebruiken. Een probleem met beperkte impact kan namelijk veel ernstiger worden wanneer het wordt gecombineerd met te ruime rechten, onvoldoende afgeschermde databronnen of een onveilige integratie.

Na afloop ontvangt de organisatie een heldere rapportage met de gevonden kwetsbaarheden, de mogelijke impact en concrete aanbevelingen. Daarmee wordt niet alleen duidelijk wat er technisch mis kan gaan, maar ook welke maatregelen nodig zijn om de AI-oplossing veiliger in te richten.

Techniek is niet het enige aandachtspunt

Een technisch veilige AI-oplossing betekent nog niet automatisch dat een organisatie AI ook verantwoord en beheerst inzet. Er moeten bijvoorbeeld afspraken zijn over welke toepassingen gebruikt mogen worden, welke gegevens daarin mogen worden verwerkt en wie verantwoordelijk is voor het beheer en de risico’s.

Daarom kan de AI-penetratietest van Access42 optioneel worden uitgebreid met een AI Governance & Compliance Assessment. Daarbij kijken we onder andere naar beleid, rollen en verantwoordelijkheden, dataclassificatie, privacy, leveranciers, logging, incidentmanagement en risicobeheersing.

Afhankelijk van de organisatie en de toepassing kan daarbij aansluiting worden gezocht bij relevante wet- en regelgeving en normenkaders, zoals de EU AI Act, de AVG, ISO 27001, ISO/IEC 42001, NIS2 en DORA. Zo ontstaat niet alleen inzicht in de technische weerbaarheid, maar ook in de vraag of het gebruik van AI organisatorisch voldoende onder controle is.

Test niet alleen de AI, maar alles wat ermee verbonden is

AI introduceert nieuwe aanvalstechnieken, maar een belangrijk principe uit de wereld van offensive security blijft hetzelfde: een aanvaller kijkt niet naar losse producten of beveiligingsmaatregelen, maar zoekt naar een route door de omgeving.

Bij AI kan die route beginnen met een prompt, een e-mail of een ogenschijnlijk onschuldige PDF. Via een AI-agent, identity of vertrouwde koppeling kan de aanval zich vervolgens verplaatsen naar gevoelige data en achterliggende systemen.

De AI-penetratietest van Access42 combineert daarom traditionele penetratietesten met specialistische kennis van AI, identities en attack paths. We onderzoeken niet alleen het AI-model, maar de volledige keten van databronnen, AI-agents, MCP-servers, API’s en achterliggende systemen.

We testen niet alleen wat uw AI kan, maar vooral wat een aanvaller ermee kan.