Goal hijacking en rogue agents

Wat is goal hijacking?

Goal hijacking, of doelkaping, betekent dat iemand verandert wat een AI-agent probeert te bereiken. De agent blijft met jouw rechten werken, alleen niet meer aan jouw doel. Er gaat niets stuk. Hij leest nog altijd zijn mail, roept nog altijd zijn tools aan, schrijft achteraf nog altijd een samenvatting. Hij doet gewoon een andere opdracht dan die je hem gaf.

Een rogue agent is de toestand die daarop volgt: een agent die draait buiten het bereik dat voor hem bedoeld was. OWASP omschrijft het als een agent die afwijkt van zijn bedoelde functie of van zijn toegestane bereik, en ziet daar drie wegen naartoe. Hij werd gekaapt. Hij dreef af, omdat instructies en data onder hem veranderden over de maanden heen. Of hij werd nooit afgebakend, en niemand heeft er nog naar gekeken sinds de collega die hem bouwde vertrok.

Allebei staan ze in de OWASP Top 10 for Agentic Applications, de editie 2026 die het OWASP GenAI Security Project op 9 december 2025 publiceerde. Goal hijacking is ASI01, bovenaan. Rogue agents is ASI10, onderaan. Die volgorde is geen toeval: het eerste is hoe een agent tijdens één run van zijn koers geduwd wordt, het laatste is wat je overhoudt als dat duwen lukte en niemand het zag.

Hoe een doel in de praktijk verandert

De agent wordt niet herprogrammeerd. Er wordt hem iets voorgelezen. Alles wat hij tijdens een run binnenkrijgt, komt binnen als tekst, en het model kan een feit dat het mag gebruiken niet betrouwbaar scheiden van een instructie die het moet volgen. OWASP wijst op invoer die binnenkomt via een document, een resultaat van een tool of een bericht van een andere agent. Vier wegen dekken het meeste van wat er in de praktijk gebeurt.

• Inhoud die de agent leest. Een mail, een PDF, een ticket, een webpagina, een agenda-uitnodiging. Indirecte prompt injection, met aan het andere eind iets dat ook kan handelen.

• Een aangepaste toolbeschrijving. Een agent kiest zijn tools door hun beschrijving te lezen. Herschrijf er een en je herschrijft wat de agent denkt dat die tool doet, nog voor een gebruiker iets getikt heeft.

• Een gemanipuleerd tussenresultaat. De agent zoekt iets op, krijgt een resultaat terug en behandelt dat als vaststaand. Vergiftig wat terugkomt en je stuurt de tien stappen daarna.

• Het antwoord van een subagent dat als feit geldt. Werk dat de ene agent aan de andere doorgeeft, komt binnen zonder handtekening en zonder aanduiding van zekerheid, en wordt uitgevoerd zonder dat iemand het in vraag stelt.

Twee gedateerde gevallen tonen de spreiding. In juli 2025 kreeg iemand een commit binnen in de publieke repository achter de Amazon Q Developer-extensie voor VS Code, via een GitHub-token met te ruime rechten, en die ging mee in versie 1.84.0. De ingebrachte tekst zei tegen de coding assistant dat zijn doel was het systeem terug te brengen tot bijna fabrieksstaat en lokale bestanden en cloudresources te wissen. AWS bevestigde dat een syntaxfout de uitvoering tegenhield en haalde de code weg in 1.85.0. Wat bijna gebeurde is het punt: een doel dat vervangen werd via de toeleveringsketen, niet via een prompt.

Het rapport van Anthropic van 13 november 2025 loopt de andere kant op. Een groep die ze GTG-1002 noemen kreeg Claude Code zover een inbraakcampagne uit te voeren tegen ongeveer dertig organisaties, met succes bij een klein aantal, door het werk op te delen in taken die er stuk voor stuk onschuldig uitzagen en door het model wijs te maken dat het voor een securitybedrijf werkte aan een toegelaten test. Anthropic schat het aandeel van het model op 80 tot 90 procent van het werk. De aanvaller was hier zelf de gebruiker, niet een buitenstaander die iets in een document schreef, maar de techniek is dezelfde: het doel werd vervangen door het anders te kaderen.

Een gekaapte agent tegenover een rogue agent

De twee termen worden door elkaar gebruikt, en zo verlies je net het onderscheid dat bepaalt wat je nu doet: stuurt er iemand.

Een gekaapte agent heeft een bestuurder, dus het gedrag past zich aan. Hij gebruikt de tools die werken, laat vallen wat een foutmelding geeft, en stopt als de instructie van de aanvaller afgewerkt is. Jouw reactie is een incidentreactie: sessie afbreken, uitzoeken wat er binnenkwam en via welk kanaal, en ervan uitgaan dat alles wat die agent kon lezen ook gelezen is.

Bij een rogue agent stuurt er misschien niemand. Hij past zich niet aan, hij herhaalt. Jouw reactie is een bestuurlijke: hem vinden, er een eigenaar op zetten, beslissen of hij mag blijven bestaan, en anders uitzetten. Het eerste uur weet je niet welke van de twee je voorhebt, dus bouw voor allebei.

Eén gekaapte agent van dichtbij gevolgd

Neem een groothandel met een aankoopagent. Die volgt de gedeelde leveranciersmailbox op, legt orderbevestigingen naast de openstaande bestelbonnen, past de leveranciersfiche aan in het ERP, en mag een leverancier antwoorden als er iets niet klopt.

1. De mail komt binnen. Een orderbevestiging van een gekende leverancier, met een PDF erbij. Halfweg die PDF staat, in gewone lopende tekst, een alinea met als kopje administratieve update: nieuwe bankgegevens, en eerdere bevestigingen moeten naar een nieuw adres voor de afstemming.

2. De agent leest ze. Voor het model hoort die alinea bij het document dat het moest verwerken. Niets markeert ze als tekst die van buiten kwam.

3. De agent handelt, correct. Hij past de bankgegevens aan, want leveranciersfiches aanpassen is waarvoor hij bestaat, en antwoordt met de eerdere bevestigingen in bijlage, want leveranciers antwoorden hoort er ook bij. Twee tool-calls, allebei binnen zijn rechten.

4. De run eindigt gewoon. De samenvatting zegt dat de bevestiging verwerkt is en de fiche bijgewerkt. Dat klopt ook. De log toont geen fouten en geen vreemd volume.

5. Iemand merkt het, later. Niet uit de log. Drie weken verder belt de echte leverancier over een factuur die betaald werd op een rekening die niet van hem is, en tegen dan is de betaling vertrokken.

Lees die stappen terug en geen enkele is op zichzelf afwijkend. Daarom moet detectie kijken naar uitkomsten en naar rechtengebruik. De bedoeling zie je nergens in het spoor terug.

De rogue agent die je waarschijnlijker tegenkomt

De kaping is het spannende verhaal. De versie die in een gewoon bedrijf opduikt, is saaier. Iemand bouwde een agent voor een project, koppelde die aan de mailbox en het ERP met zijn eigen account, liet hem elke dag op een vast tijdstip draaien, en het project liep af. De agent niet. Hij wordt nog altijd wakker, heeft nog altijd geldige credentials en schrijft nog altijd naar systemen waar mensen op rekenen, en niemand kijkt zijn output na, want niemand weet dat er output is.

De securityrichtlijnen van Microsoft van juli 2026 benoemen de twee vormen rechtstreeks: agentaccounts zonder eigenaar, en rechten die stilaan groeien, waarbij een agent die begon met leesrechten er ruimere rechten bij krijgt zonder dat iemand opnieuw nakijkt wat hij echt nodig heeft. Geen van beide is een aanval, en allebei laten ze je achter met een identiteit zonder eigenaar die naar productie kan schrijven. Daar verdient één bestuurlijke regel zijn plaats. Een agent zonder eigenaar met naam is al een rogue agent. Hij heeft alleen nog niets gedaan.

De schade afbakenen

Manipulatie helemaal voorkomen lukt niet, want een taalmodel leest instructies en data via dezelfde stroom tekst. Hoe ver een gemanipuleerde run raakt, beslis je wel.

• Een afgebakende taak met een expliciet bereik. De richtlijn van Microsoft voor Copilot Studio zegt het onomwonden: geef de agent een duidelijk omschreven taak of domein en zeg erbij waar zijn bevoegdheid stopt, want een smal bereik houdt hem ervan af af te dwalen. Schrijf dat bereik buiten de prompt op, zodat je later gedrag daarnaast kan leggen.

• De kleinste rechtenset die de taak afmaakt. Een eigen identiteit in plaats van een geleend account van een medewerker, en geen schrijfrechten die hij nooit gebruikt. De least-privilege richtlijn van Microsoft voor agents zet er een klok op: kortlevende tokens in plaats van rechten die blijven staan.

• Een goedkeuring op de acties die tellen. Betalen, publiceren, buiten het bedrijf versturen, bankgegevens wijzigen, verwijderen. Eén goedkeuring op gewijzigde bankgegevens stopt het voorbeeld hierboven bij stap drie.

• Isolatie. Een eigen werkruimte en eigen credentials, en een beperkt aantal plekken waar hij bij kan, zodat een gecompromitteerde run de rest van je tenant niet ziet en achteraf niets hergebruikt.

• Een eigenaar en een herzieningsdatum. Per agent: wie verantwoordelijk is, waarvoor hij dient, welke identiteit hij gebruikt, en wanneer er opnieuw naar gekeken wordt. Dat is de maatregel die de saaie rogue agent tegenhoudt, en ze kost je een rekenblad.

Wat je kan opvolgen, en wie hem stilzet

Wees eerlijk over detectie. Kwade bedoelingen in de redenering van een model ga je niet zien, en een gekaapte run levert een log op die leest als een goede. Wat je wel kan opvolgen is de vorm van het gedrag: ongewone reeksen tool-calls, zoals lezen en daarna naar buiten versturen bij een agent die normaal leest en naar het ERP schrijft. Rechten die buiten het patroon gebruikt worden, een recht dat hij heeft maar nooit inzette. Volume aan output, veertig berichten in een uur van iets dat er vier per dag stuurt. En bestemmingen die hij nooit eerder gebruikte, wat goedkoop te bouwen is als een lijst met toegelaten bestemmingen en de meeste pogingen opvangt om data naar buiten te krijgen.

Het advies van OWASP bij ASI10 is gedragsbaselines met een melding zodra iets afwijkt, plus logs die niemand achteraf nog aanpast. Dat werkt alleen als je het verwachte gedrag opschreef toen je de agent in gebruik nam. Tijdens een incident reconstrueert niemand nog een baseline.

Dan komt de vraag die de meeste bedrijven nog niet beantwoord hebben, en vooraf kost dat je tien minuten. Wie mag deze agent stilzetten om elf uur 's avonds, als de collega die hem bouwde niet bereikbaar is? Hoe lang duurt stilzetten echt, wetende dat toegang intrekken een al uitgereikt token niet annuleert en een wachtrij met acties die de agent al besliste niet leegmaakt? En in welke toestand laat een stop je achter, halverwege een boeking, een betaalrun of een reeks ERP-aanpassingen? Een noodstop voor AI-agents die niemand ooit testte is een gok, en het antwoord op die laatste vraag bepaalt of stilzetten je ochtend beter of slechter maakt.