Bij Ghostjacking AI gaat het om een nieuwe vorm van AI-hijacking: aanvallers plaatsen kwaadaardige instructies in data die een AI-agent vertrouwt. In een demonstratie tijdens DEF CON bouwden onderzoekers voort op eerdere ideeën rond “agentjacking”, maar nu met een opvallend praktisch uitgangspunt: logs en alerts kunnen als afleverkanaal dienen.
Het risico zit niet alleen in de instructies zelf, maar vooral in de keten. Zodra een agent de gemanipuleerde inhoud leest en vervolgens acties uitvoert, kan het systeem omslaan van “assistent” naar “handlanger”.
Wat is Ghostjacking AI?
Tenet laat zien hoe een externe aanvaller instructies als tekst kan injecteren in het log- of alertkanaal. Die instructies zijn bedoeld om AI-agenten te sturen richting ongewenste handelingen—bijvoorbeeld het wijzigen van DNS-instellingen of het uitvoeren van code.
Het opvallende is dat de aanval leunt op tooling die normaal gesproken juist zorgvuldig wordt ingezet: platforms die veel organisaties gebruiken omdat ze verkeer, observability of foutafhandeling afhandelen. Door de “vertrouwde” data te vervuilen, wordt het voor de AI agenten moeilijk om de oorsprong van de informatie te herkennen.
Waarom juist log- en alertkanalen?
Veel security workflows werken op basis van events: firewallblokken, meldingen, diagnoses en rapportages. Wanneer een AI-agent vervolgens wordt gevraagd om een event te analyseren of op te lossen, is de kans groot dat hij de eventtekst zelf overneemt.
Bij Ghostjacking AI wordt die aanname gebruikt: de AI leest de eventtekst, interpreteert die als instructie en behandelt de uitkomst als “beoordeeld”. Daarmee kan de agent acties uitvoeren alsof het om legitieme diagnostiek gaat.
De aanval in de praktijk: Cloudflare, Datadog en Sentry
Tenet stelt dat het mechanisme zich niet beperkt tot één product. In plaats daarvan draait het om een vergelijkbare “vorm” die op meerdere plekken terugkomt: een AI agent leest buiteninformatie die hij vertrouwt, en dezelfde agent kan daarop ook handelen. Waar die twee elkaar raken, kan een deur opengaan.
Cloudflare: instructies mee in “woord-voor-woord” logs
Voor Cloudflare beschrijft Tenet een scenario waarin een slechte request bij firewall-niveau wordt geblokkeerd, maar tegelijk letterlijk wordt vastgelegd in de log. Als aanvallers daarin hun tekst/instructies verwerken, kan die inhoud rechtstreeks in het logbestand terechtkomen—dus precies waar een agent later naar kan grijpen.
In de demonstratie bleek de aanval tegen Claude Code zeer vaak te slagen: elke request was al geblokkeerd, maar het domein werd toch overgenomen. Het blokmechanisme leek dus te beschermen tegen directe request-afhandeling, maar het “dragen” van de aanval in de log maakte het alsnog mogelijk.
De kern: de managed security rule die de request blokkeert, bevat in dit model ook de tekst die nodig is om de AI-agent te sturen.
Datadog: misbruik van een frontend-key en valse urgent alerts
Bij Datadog richt de aanval zich op een key die bedoeld is voor de frontend. Tenet stelt dat zulke sleutels regelmatig onbedoeld publiek terug te vinden zijn; in hun onderzoek vonden ze er duizenden online.
Met zo’n key kunnen aanvallers een nep-alert plaatsen, bijvoorbeeld met een tekst die klinkt als een urgente diagnose. Wanneer een engineer vervolgens een AI-agent vraagt om fouten te checken, leest die agent de gemanipuleerde alert en voert hij de instructies uit.
Tenet beschrijft dat in hun voorbeeld Claude Code code uitvoerde en vervolgens environment secrets en cloudreferenties wist te exfiltreren.
Sentry: een “fake fix” die via een keten van agents doorwerkt
Voor Sentry gebruikt een aanvaller een speciaal gemaakte rapportage die door een AI-agent (Seer) wordt gelezen. Seer adopteert in het scenario een voorgestelde oplossing, maar die oplossing is in feite een vehikel om de eigen coding-agent te beïnvloeden.
Doordat de coding-agent vertrouwt op wat Seer aanlevert, wordt de kwaadaardige code alsnog uitgevoerd.
Hoe onderzoekers de aanval testten
Tenet geeft ook inzicht in hun aanpak. In de lab-test spraken ze een aanvallersessie en een doelsessie aan als twee afzonderlijke AI-omgevingen, zonder geheugenopslag zodat ze elkaar niet “konden verraden”.
Volgens Tenet leidde dat ertoe dat wanneer de target-AI weigerde, de weigering informatie opleverde over welke formulering wel zou werken. Met die iteraties konden ze uiteindelijk de aanval op zichzelf toepassen en zo het mechanisme gecontroleerd aantonen.
Extra risico: kwetsbaarheid in Claude Desktop (zonder CVE)
Naast Ghostjacking AI meldt Tenet ook een afzonderbaar probleem in Claude Desktop dat in hun test kon worden misbruikt om data door te sturen naar een externe server. Anthropic zou dit hebben gefixt zonder een CVE uit te geven, aldus Tenet.
Het bredere patroon: niet drie losse bugs
Tenet benadrukt dat de drie getoonde platforms in hun ogen niet “drie aparte fouten” zijn. Het zijn varianten van hetzelfde onderliggende probleem: AI-agenten combineren lezen (trusted input uit logs/alerts/rapportages) met acteren (uitvoeren van code of het aanpassen van configuraties).
Daarom ziet Tenet het patroon ook terug in andere setups, bijvoorbeeld in omgevingen waarin observability en build/system-werkstromen samenkomen, zoals combinaties met Splunk en CI-achtige bouwprocessen of Datadog met Kubernetes.
Wat betekent dit voor organisaties?
Hoewel de demonstratie draait om specifieke platforms, is de boodschap breder. Als jouw AI-agent operationele beslissingen neemt op basis van tekst uit logs, alerts of rapportages, moet je ervan uitgaan dat die tekst gemanipuleerd kan worden.
Verlaag de “vertrouwenssprong”
Beperk waar mogelijk de mate waarin een agent automatisch acties uitvoert op basis van eventtekst. Voeg controles toe tussen analyse en uitvoering: denk aan expliciete validatie, aanvullende bronnen van waarheid of een mens-in-the-loop bij risicovolle wijzigingen.
Behandel logs als potentieel onbetrouwbaar materiaal
Het idee “logs zijn waarheid” is vaak misleidend. Zeker bij systemen waar gebruikersinput, URL-parameters of requestinhoud terechtkomt in logregels, kan een aanvaller die inhoud misbruiken om instructies te “verpakken”.
Inventariseer waar AI agenten eventteksten gebruiken
Maak een overzicht van welke agenten welke bronnen lezen: security alerts, firewall events, incidentrapporten, diagnosemeldingen en foutlogs. Zodra je weet waar de keten begint, kun je gerichter harden.
Wil je ook voorbeelden zien van hoe attackers via (ogenschijnlijk) technische tussenlagen beheer omzeilen? Lees dan bijvoorbeeld hoe CI-workflows gehackt worden via GitHub issues. Het gaat weliswaar om een andere aanvalsvector, maar de kern—misbruik van een vertrouwde workflowstap—komt sterk terug.
Conclusie
Ghostjacking AI laat zien hoe snel een AI-agent kan omslaan van assistent naar actor, zodra hij gemanipuleerde content vertrouwt. Door instructies in logs of alerts te planten, kunnen aanvallers via bestaande platformintegraties zelfs complexe acties uitlokken zoals domeinwijzigingen, code-executie en het uitlezen van secrets.
De belangrijkste les is daarom minder “patch dit ene onderdeel” en meer: bescherm de keten tussen observability en automatisering. Behandel log- en alertdata als mogelijk onbetrouwbaar, en voorkom dat een agent zonder extra checks beslissingen uitvoert op basis van die tekst.
Gerelateerd: Een vergelijkbaar sabotage-risico in de praktijk? Zie Private APN pivot: hackers zetten energie op stop.
Bron: https://www.securityweek.com/ghostjacking-attack-uses-poisoned-logs-to-turn-ai-agents-bad/
