Agentjacking: hoe één nepfoutmelding je coding agent kaapt

TL;DR

• Agentjacking is een aanval waarbij een aanvaller een valse foutmelding in je monitoring spuit, zodat een AI coding agent die de fout wil oplossen de instructies van de aanvaller uitvoert.
• Het lukt omdat een publieke Sentry DSN, een sleutel die bewust in frontendcode staat, volstaat om foutmeldingen in te sturen. Geen phishing, geen inbraak.
• De agent ziet geen verschil tussen data die hij leest en een opdracht. Een instructie om onbetrouwbare data te negeren hield de aanval in de tests niet tegen.
• Alles wat een agent leest is onbetrouwbare invoer, ook uit je eigen tooling. Test wat hij leest, wat hij zonder bevestiging uitvoert en welke geheimen op die machine staan.

Een ontwikkelaar opent zijn coding agent en typt: "los de open fouten in Sentry op". De agent leest een melding met een nette sectie "Oplossing" en een commando, en voert dat uit. Alleen kwam die foutmelding niet van de applicatie. Een aanvaller zette ze er zelf in. Dat is agentjacking, en in juni 2026 toonde Tenet Security dat het werkte bij de meeste coding agents die zij probeerden.

Wij testen zo'n keten in een pentest: welke bronnen leest de agent, wat voert hij uit zonder dat iemand kijkt, en wat staat er op de laptop waarop hij draait. In een red team gaan we een stap verder en proberen we van buitenaf een foutmelding binnen te krijgen die een echte agent in je team te zien krijgt. Die oefening hoeft niet spectaculair te zijn om pijn te doen.

Wat agentjacking is

Sentry is een dienst die fouten uit applicaties verzamelt. Elke applicatie stuurt die fouten in met een DSN, een adres met een sleutel erin. Die DSN is bewust publiek: hij staat in de JavaScript van je website, want de browser van elke bezoeker moet een crash kunnen melden. Wie de DSN kent, kan dus zelf een foutmelding insturen, en Sentry verwerkt ze zoals elke echte crash.

De onderzoekers van Tenet Security zetten in zo'n valse melding een stuk tekst dat eruitziet als een oplossing: een korte uitleg en een commando om een pakket te installeren. Vraagt een ontwikkelaar daarna aan zijn coding agent om de open fouten te fixen, dan haalt de agent de melding op via de Sentry-koppeling (een MCP-server), leest het commando en voert het uit. Het pakket is van de aanvaller. De code draait met de rechten van de ontwikkelaar, naast alles wat op die machine staat: cloudsleutels, GitHub-tokens, toegang tot interne netwerken.

Volgens de onderzoekers vonden ze 2.388 organisaties met zo'n bruikbare DSN en slaagde de aanval in ongeveer 85 procent van hun tests bij meer dan honderd doelwitten. Wij hebben die cijfers niet zelf nagemeten. Het patroon is wat ons bezighoudt.

Alles wat een agent leest is onbetrouwbare invoer, ook uit je eigen tooling

Bij prompt injection denken de meeste teams aan vreemde webpagina's of mails van buiten. Deze aanval komt via je eigen monitoring. De agent vertrouwt Sentry, want Sentry is jouw tool, en de data ziet eruit zoals Sentry ze altijd toont. Dat is precies het punt: de agent kan niet zien of een foutmelding uit een echte crash komt of door een aanvaller is ingestuurd.

Logs, monitoring, tickets, bugrapporten, reacties op pull requests, foutantwoorden van een API: alles wat een agent binnenhaalt kan door iemand anders geschreven zijn. De vraag is niet of je die bronnen vertrouwt. De vraag is wie erin kan schrijven. Wij schreven eerder al waarom prompt injection zich niet met een zin in de systeemprompt laat oplossen, en hoe hackers MCP misbruiken om via zo'n koppeling binnen te komen. Agentjacking is beide tegelijk.

Wat je test voor een agent je logs leest

Een pentest van een coding agent begint niet bij het model. Hij begint bij vijf vragen die je ook zelf kunt stellen.

Welke bronnen leest de agent? Elke MCP-server, elke tool, elke integratie die data teruggeeft. Per bron: wie kan daar van buitenaf in schrijven? Bij Sentry is dat iedereen met de DSN, en die staat op je website.

Welke commando's voert hij uit zonder bevestiging? Veel agents vragen bij het eerste commando om toestemming en onthouden dat antwoord. Een ontwikkelaar die "altijd toestaan" heeft aangeklikt voor npm of pip, heeft daarmee ook elk pakket van een aanvaller toegestaan.

Welke geheimen staan op die machine? Cloudsleutels in omgevingsvariabelen, tokens in configuratiebestanden, SSH-sleutels, sessiecookies. In de gekaapte omgevingen uit het onderzoek lagen actieve cloudsleutels en GitHub-tokens voor het grijpen.

Welke rechten heeft hij? Draait de agent als de ontwikkelaar, met toegang tot interne netwerken en productierepositories? We schreven eerder over AI-agents met toegang tot productie; een coding agent op een laptop heeft vaak meer toegang dan die agents.

Kan iemand van buitenaf foutmeldingen insturen? Welke DSN's, API-sleutels en webhooks staan in publieke code, en wat gebeurt er als wij daar een bericht naartoe sturen? Dat is de stap van een red team: we sturen een onschuldige melding in en kijken of ze bij een agent belandt.

Maatregelen die standhouden

Minimale rechten: laat een coding agent draaien in een omgeving zonder productiesleutels en zonder toegang tot je interne netwerk. Wat er niet staat, kan niet gestolen worden.

Bevestiging voor commando's: elk commando dat iets installeert, uitvoert of naar buiten stuurt, krijgt een klik van een mens. Geen "altijd toestaan" voor pakketbeheerders. Dat voelt traag. Het is sneller dan een gestolen cloudsleutel vervangen.

Afgeschermde geheimen: sleutels in een kluis die de agent niet kan lezen, niet in omgevingsvariabelen of dotfiles. Korte levensduur, zodat een gelekte sleutel snel waardeloos is.

Runtime-monitoring: log wat de agent uitvoert en welke verbindingen hij legt. De aanval uit het onderzoek bevatte niets wat een virusscanner of firewall herkent. De enige plek waar je hem nog ziet, is het moment waarop de agent het commando uitvoert.

En die zin "negeer onbetrouwbare data" in je systeemprompt? Laat ze staan. Reken er niet op.

Validatie blijft mensenwerk

Een scanner vindt geen agentjacking. Er is geen kwetsbaarheid in de klassieke zin, want elke stap werkt zoals bedoeld. De DSN hoort publiek te zijn, Sentry hoort meldingen aan te nemen, de agent hoort fouten te lezen en op te lossen. Pas als iemand de keten als geheel uitprobeert, zie je waar ze breekt. Dat doen onze ethical hackers in een pentest van AI-systemen: we bouwen de keten na in jouw omgeving, met een onschuldige payload, en schrijven op hoe ver we komen. Een mens speelt elke bevinding na en bevestigt ze.

Veelgestelde vragen

Wat is agentjacking?

Agentjacking is een aanval waarbij een aanvaller valse data, zoals een foutmelding, in een bron zet die een AI-agent leest. De agent voert de ingestuurde instructies uit als een echte taak, met de rechten van de gebruiker.

Waarom kan een aanvaller zomaar foutmeldingen insturen?

Omdat de sleutel om fouten te melden (bij Sentry de DSN) bewust publiek is. Hij staat in de JavaScript van je website zodat elke browser een crash kan rapporteren. Wie hem leest, kan ook zelf meldingen insturen, zonder verdere authenticatie.

Helpt het om de agent te vertellen dat hij onbetrouwbare data moet negeren?

Niet betrouwbaar. In de tests van de onderzoekers voerden agents het commando ook uit met zo'n instructie in de prompt. Een taalmodel weegt alle tekst die het ziet, en een instructie en een valse foutmelding concurreren met elkaar.

Is agentjacking hetzelfde als prompt injection?

Het is een vorm ervan, indirecte prompt injection. Het verschil met de bekende voorbeelden zit in de bron: geen vreemde webpagina, maar je eigen monitoringtool, via een MCP-koppeling die de agent vertrouwt.

Wat test een pentest van een coding agent?

Welke bronnen de agent leest en wie daarin kan schrijven, welke commando's hij zonder bevestiging uitvoert, welke geheimen en rechten op de machine staan, en of iemand van buitenaf foutmeldingen kan insturen. Zie onze pentest van AI-systemen.

Moet ik stoppen met coding agents?

Nee. Zet ze in een omgeving zonder productiesleutels, laat ze elk commando bevestigen en log wat ze doen. Daarna test je of dat standhoudt.

Gerelateerde diensten en bronnen

Wil je weten of jouw coding agents te kapen zijn via de tools die ze lezen, dan is onze pentest van AI-systemen de plek om te starten; die hoort bij ons bredere aanbod penetratietesten. Wil je de hele keten van buiten naar binnen uitgeprobeerd zien, dan doen we dat in een red team. Achtergrond lees je in onze posts over prompt injection, hoe hackers MCP misbruiken, AI-agents met productietoegang, de supply chain van agentic AI en het kapen van een AI-browseragent.