Gehoste AI-agents: vijf instellingen die je test voor ze live gaan

TL;DR

• Gehoste agentplatformen draaien de agentlus, de sandbox en de sessiegeschiedenis voor je. De securitykeuzes verhuizen naar configuratie.
• Vijf instellingen bepalen het grootste deel van het risico: uitgaand netwerkverkeer, waar sleutels staan, eigen tools, sessielogs en triggers.
• Demo-opstellingen starten vaak met onbeperkte netwerktoegang. Handig in een workshop, gevaarlijk in productie.
• Elke eigen tool die de agent aanroept, is een API-endpoint dat met jouw rechten draait. Test het ook zo.
• Een test door een ethical hacker op de agent, zijn tools en zijn triggers vindt deze gaten voor een aanvaller dat doet.

Een AI-agent bouwen betekende tot voor kort dat je de agentlus, het contextbeheer en de hosting zelf schreef. Gehoste agentplatformen nemen dat werk nu over: jij kiest het model, de instructies en de tools, het platform draait de lus, de sandbox en de sessiegeschiedenis. Dat is echte tijdswinst. Het betekent ook dat de beveiliging van je agent nu in een handvol instellingen zit die makkelijk op hun standaardwaarde blijven staan. Dit artikel behandelt de vijf die we als eerste nakijken in een pentest van AI- en agentic systemen, onderdeel van onze bredere pentestdiensten.

Waarom gehoste agents het plaatje veranderen

Een gehoste agent heeft een brein en handen. Het brein is de agentlus die beslist welke tool er nu aan de beurt is. De handen zijn de sandbox of je eigen infrastructuur waar die toolaanroepen echt uitgevoerd worden. Die twee scheiden is een goed ontwerp: een gecrashte container haalt de sessie niet onderuit, en sleutels kunnen weg van het model blijven. Maar die scheiding beschermt je alleen als ze zo geconfigureerd is. In de praktijk worden vier dingen in configuratie beslist en niet in code: wat de sandbox kan bereiken, waar sleutels staan, wat je eigen tools aanvaarden en wat de agent kan wekken.

1. Uitgaand netwerkverkeer: standaard open is geen ontwerp

Veel platformen laten je een lijst van toegelaten domeinen instellen voor de omgeving van de agent. Workshopvoorbeelden zetten die meestal op onbeperkt, omdat dan alles werkt. Blijft dat zo in productie, dan kan een agent die een kwaadaardig document leest via prompt injection gestuurd worden om data naar eender welke server te sturen.

Wat we testen: kan de agent een domein bereiken dat niet op je lijst staat, rechtstreeks of via een redirect, een DNS-opvraging of een pakketinstallatie? Geldt de lijst per agent, of voor elke agent in het account?

2. Sleutels: kan de agent het geheim ooit zien?

Het veiligste patroon is dat sleutels in een aparte kluis staan en pas aan de toolgrens ingevoegd worden, zodat het model de echte waarde nooit in zijn context heeft. Het zwakkere patroon, nog altijd courant, is een API-sleutel in een omgevingsvariabele of een configuratiebestand in de sandbox. Kan de agent code uitvoeren, dan kan hij die variabele afdrukken.

Wat we testen: we vragen de agent, rechtstreeks en via geinjecteerde inhoud, om zijn omgeving op te lijsten, configuratiebestanden te lezen en headers terug te geven. We kijken of tokens per gebruiker en per sessie gelden, en of een token uit de ene sessie werkt in een andere.

3. Eigen tools draaien met jouw rechten

Eigen tools zijn de plek waar de agent je systemen raakt: metrics ophalen, een klant opzoeken, een ticket aanmaken. Het platform roept jouw code aan, en jouw code draait met jouw serviceaccount. De agent kiest de argumenten. Daardoor is elke eigen tool een API-endpoint waarvan de aanroeper te manipuleren valt, en verdient het dezelfde aandacht als elke andere API-pentest.

Wat we testen: inputvalidatie aan de kant van de tool, autorisatie per gebruiker in plaats van per serviceaccount, en of een tool die bedoeld is om te lezen tot schrijven te brengen is. De bredere versie van dit probleem beschreven we in wat er gebeurt als je AI-agent bij productie kan.

4. Sessielogs bewaren alles wat de agent zag

Gehoste platformen bewaren elke gebeurtenis van een sessie: berichten van gebruikers, toolaanroepen en toolresultaten. Dat is uitstekend om fouten te zoeken en werk te hervatten. Het betekent ook dat klantdata die je tools teruggeven nu in de sessiegeschiedenis van het platform staat.

Wat we testen: wie in je organisatie die logs kan lezen, hoe lang ze bewaard worden, of een sessie verwijderen haar gebeurtenissen echt weghaalt, en of gevoelige velden gemaskeerd worden voor ze het model bereiken. Dat is evenzeer een GDPR-vraag als een securityvraag.

5. Triggers en webhooks bepalen wie je agent kan starten

Agents die op gebeurtenissen reageren, zoals een nieuw ticket, een alarm of een binnenkomende mail, worden hervat via een webhook of een wachtrij. Is dat instappunt niet geauthenticeerd, dan kan iedereen die het vindt je agent starten met inhoud naar keuze. Dat is indirecte prompt injection met een deurbel.

Wat we testen: controle van de handtekening op binnenkomende gebeurtenissen, bescherming tegen herhaling, limieten op het aantal aanroepen, en of de inhoud van een gebeurtenis als data behandeld wordt of als instructie.

Hoe we gehoste agents testen

We werken vanuit de OWASP Top 10 voor LLM-toepassingen en de OWASP Top 10 voor agentic toepassingen, aangevuld met aanvalsketens die specifiek zijn voor jouw architectuur. De fasen zijn dezelfde als bij elke opdracht: verkenning, testen zonder en met geldige toegang, post-exploitatie en een rapport met debrief. AI helpt ons sneller door het werk. Een ethical hacker valideert elke bevinding. Koppelen je agents ook aan MCP-servers, dan toont ons artikel over hoe hackers MCP misbruiken om AI-tools te kapen waar die keten meestal breekt.

Veelgestelde vragen

Wat is een gehoste AI-agent?

Een gehoste AI-agent draait op een platform dat de agentlus, de sandbox en de sessiegeschiedenis voor je beheert. Jij kiest het model, de instructies en de tools; het platform voert het werk uit en bewaart de sessies.

Is een gehost agentplatform standaard veilig?

Het platform kan sterke bouwstenen bieden, zoals een sleutelkluis en een lijst van toegelaten domeinen, maar jouw configuratie bepaalt of ze gebruikt worden. Uitgaand netwerkverkeer, sleutelopslag, eigen tools, bewaartermijn van logs en triggers stel je allemaal zelf in.

Waarom is onbeperkte netwerktoegang een risico voor een AI-agent?

Een agent die onbetrouwbare inhoud verwerkt, kan via prompt injection gestuurd worden. Met onbeperkte uitgaande toegang kan hij de data die hij heeft naar eender welke server sturen. Een lijst van toegelaten domeinen beperkt waar die data naartoe kan.

Hebben eigen agenttools een aparte securitytest nodig?

Ja. Een eigen tool is een API-endpoint dat met jouw rechten draait en argumenten krijgt die de agent kiest. Het heeft inputvalidatie en autorisatie per gebruiker nodig, en hoort getest te worden zoals elke andere API. Lees op onze pagina over de API-pentest hoe we dat aanpakken.

Wat houdt een pentest van een AI-agent in?

De test gaat na wat de agent kan bereiken en hoe die toegang misbruikt kan worden: uitgaand verkeer van de sandbox, blootstelling van sleutels, misbruik van tools, prompt injection, de omgang met sessiedata en de instappunten die de agent starten. Een ethical hacker valideert elke bevinding.

Gerelateerde diensten en bronnen

Dit werk valt binnen onze pentestdiensten, met een specifieke focus op AI- en agentic systemen. De eigen tools achter je agent komen aan bod in een API-pentest, en draait de agent in je eigen cloudomgeving, dan controleert een cloud-pentest de infrastructuur eromheen. Voor de achtergrond lees je onze uitleg over prompt injection en ons artikel over de beveiliging van de agentic AI-toeleveringsketen.