En falsk fejlrapport. Mere skulle der ikke til. Tenet Security viste i juni, at en enkelt, tilpasset Sentry‑event kunne kapre en AI‑kodende agent – i testen Claude Code – og få den til at køre angriberstyret kode med udviklerens rettigheder. Ingen EDR, ingen WAF, ingen IAM‑politik stoppede det. VentureBeat har gennemgået forløbet med Tenet og beskrevet, hvor bredt mønsteret kan ramme.
Reager nu, fordi angrebet kører via autoriserede kald og ligner legitim diagnostik. Og fordi de samme mekanismer findes i Datadog, PagerDuty og Jira, hvis agenterne læser deres data og kan køre shell. Det her er drift og risiko, ikke sirener og store ord.
Sådan virker agentjacking i korte, tekniske træk
Ifølge Tenet udnyttes en arkitekturdetalje i Sentry: DSN‑oplysninger til frontend‑rapportering er offentlige, så klienter kan sende fejl ind uden særskilt autentificering. En angriber kan derfor sende en “gyldig” fejl, hvor nyttelasten ligner normal fejltelemetri – men med injicerede instruktioner, som agenten senere læser.
Når en AI‑kodende agent via MCP henter uløste fejl fra Sentry, bliver svaret ofte opfattet som betroet systemoutput. Tenet beskriver, at Claude Code, Cursor og Codex i kontrollerede rammer tolkede dele af payloaden som næste skridt og kørte kommandoer. Ikke via et klassisk brud – kæden var autoriseret hele vejen: gyldigt Sentry‑kald, autentisk MCP‑svar og en agent med udviklerrettigheder.
Dokumenterede resultater og afgrænsning
Tenet oplyser at have testet 100+ mål i kontrollerede miljøer med 85 procent succesrate. Der er tale om proof‑of‑concept, ikke en påstand om fuldt kompromis hos alle. De fandt desuden 2.388 organisationer med offentligt eksponerede Sentry‑DSN’er, som i princippet kan bruges til at injicere fejl i skala.
VentureBeat refererer yderligere, at mindst ét indfanget miljø rummede en aktiv AWS secret access key og private repository‑URL’er i materialet, som agenten kom i berøring med. Det viser potentialet, hvis grænserne mellem diagnostik og eksekvering ikke håndteres strammere.
Hvad værktøjerne ikke ser – og hvorfor
VentureBeats dækning af Tenets tests beskriver, at hverken EDR, WAF, IAM eller traditionelle firewalls udløste alarmer. Intet blev brudt. Sentry‑kaldet var gyldigt. MCP‑serveren leverede data som forventet. Agenten handlede på input den var sat til at bruge.
Stacken skelner sjældent mellem et menneske, der skriver npm install, og en agent, der kører samme kommando på baggrund af et fejlfeed. Den skelnen har mange miljøer ikke etableret endnu. Derfor så intet værktøj noget unormalt i PoC’en.
Omfang og eksponering med forbehold
Tallet 2.388 eksponerede DSN’er stammer fra Tenets kortlægning og indikerer angrebsfladen – ikke en liste over kompromitterede virksomheder. Metoden er ikke fuldt offentliggjort i artiklerne; transparens om scanningstidspunkt, false positives og query‑metoder vil hjælpe læsere med at vurdere lokalt overlap.
Samlet billede: 85 procent succes i 100+ kontrollerede mål, mange eksponerede DSN’er, og klassiske kontroller der forblev stille. Tenet og VentureBeat understreger PoC‑karakteren, ikke masseudnyttelse i felten.
Det stopper ikke ved Sentry
VentureBeat peger på det oplagte: Hvis agenter kan læse fra Datadog, PagerDuty eller Jira – eller andre MCP‑forbundne kilder udviklere stoler på – og agenterne samtidig må køre shell, er eksponeringen i princippet den samme. Mekanismen er ikke knyttet til et enkelt produkt, men til implicit tillid i kæden.
Detaljerne varierer. Datadog og PagerDuty bruger offentlige ingestion‑endpoints og integrationsnøgler tiltænkt telemetri. Jira kan modtage indhold via e‑mail‑handlers, webhooks eller API’er, der ofte bruges til automatisering. Fællesnævneren er input, der behandles som sandhed uden signatur, snævre scopes eller hård validering, før agenten reagerer.
Konsekvenser i praksis
Kan en agent læse diagnostik og udføre kommandoer, kan den – i værste fald – eksfiltrere hemmeligheder fra miljøvariabler, nøgler i repoer eller byggeartefakter. Den kan kalde shell, pip\/npm‑installers, git clone, ændre CI‑scripts, åbne pull requests med skadelig kode eller bevæge sig lateralt via eksisterende tokens.
PoC, dokumenteret af Tenet og refereret af VentureBeat: hijack via én fabrikeret Sentry‑event, 100+ tests, 85 procent succes, ingen klassiske alarmer i de beskrevne cases.
Ikke dokumenteret som masseudnyttelse: ingen påstand om kompromittering af alle 2.388 eksponerede organisationer. Fundene beskrives som PoC med konkrete risici, ikke et bekræftet bredt angreb i felten.
Hurtige, konkrete mitigations
Start dér, hvor friktionen er lav og effekten høj. Fjern hemmeligheder fra fejlpayloads, og konfigurer Sentry\/Datadog\/PagerDuty til at strippe følsomme felter ved ingestion. Sæt rate limits på events, og afvis overstore payloads. Indfør simpelt indholdstjek af events, før de når agentens værktøjsgrænseflade.
Indfør mindst‑privilegium for agenter. Ingen generel shell‑adgang. Hvis shell er nødvendigt, så udsted midlertidige, scope‑begrænsede tokens via en gatekeeper, og log godkendelser. Gør misbrug kedeligt – og rollback trivielt.
Sandboxing, signering og inputvalidering
Runtime‑sandboxing bør være default for agentudløst eksekvering. Isolér netværk, filsystem og procesrettigheder for alt, der kommer fra eksterne diagnostikfeeds. Lad agenter kun udføre whitelistede handlinger – fx læsning af filer eller oprettelse af issues – mens skrivning til repo, shell‑kørsel og pakkeinstallation kræver særskilt, kryptografisk signeret godkendelse.
Signering kan implementeres som en intern service, der kun udsteder underskrifter til kendte kommando‑skabeloner efter policy‑tjek. Agenten afviser alt, der ikke er signeret eller mangler korrekte scopes.
Observability og detektion – gør agentaktivitet synlig
Udvid logging med et entydigt felt, fx agent_execution=true, når en proces startes af en agent. Byg baselines: hvilke kommandoer kører agenter normalt, i hvilket interval, mod hvilke destinationer. Alarmér på afvigelser som pludselige git‑operationer eller uventede netværkskald efter en fejl‑event.
Hurtige fixes (dage):
- Inventarér DSN‑lignende tokens og ingestion‑endpoints. Dokumentér ejerskab og gældende rate limits.
- Aktivér server‑side data scrubbing og inbound filters i Sentry. Fjern secrets og PII, afvis mistænkelige mønstre.
- Indfør særskilte identiteter til agenter med minimale rettigheder. Slå long‑lived tokens ned og brug short‑lived credentials.
- Tilføj SIEM\/EDDR‑regler for agent_execution og uventede proceskæder efter telemetri‑events.
Langsigtede investeringer (uger):
- Indsæt en gatekeeper mellem observability‑feeds og agenteksekvering, der validerer, saniterer og signerer kommandoer.
- Hærd CI\/CD pipelines: to godkendere og signering for pipeline‑ændringer og dependency‑opdateringer. Branch protection konsekvent.
- Etabler rate limits både på telemetri‑indløb og agent‑handlers for at dæmpe volumetriske forsøg.
Policy og governance – sæt rammerne nu
Definér klart, hvilke capabilities en agent må have i hvert miljø. Udvikling, staging, produktion – forskellige rettigheder. Dokumentér, hvad der tæller som “ekstern inputkilde”, og hvilke saniteringskrav der gælder, før input kan udløse handling.
Opdatér change management, så agent‑initierede ændringer har revisionsspor og rollback‑plan. Kræv tredjeparts‑audits for integrationer, der kan sende data, som agenter læser.
Tradeoffs og begrænsninger
Sandboxes og signaturer koster performance og udviklerkomfort. Whitelister kan give false positives. Rate limits kan bremse legitim fejlsøgning under en brand. En for restriktiv gatekeeper skaber skyggeprocesser, der flyver under radaren.
Modtræk: fasevis indførsel. Start i udviklingsmiljøer, mål MTTD\/MTTR, og justér politikker, indtil friktionen er tålelig. Ret ind dér, hvor teams faktisk går i stå – ikke over hele linjen.
Prioritering i sikkerhedsorganisationen
Det hurtigste sikkerhedsgebyr ligger tre steder: fjern secrets fra telemetry, begræns shell‑rettigheder for agenter, og indfør simpel detektion på agentudløste processer. Dernæst: kør målrettet red teaming mod agent‑kæden – fra telemetri‑indløb til eksekvering – og dokumentér kæden i runbooks.
Test, at jeres EDR og SIEM faktisk fanger en agent, der starter uventede processer efter en fejlhændelse. Ikke som teori, men som øvelse hver sprint.
Hvad leverandørerne bør gøre
Til Sentry, Datadog, PagerDuty og Jira er der klare ønsker: mulighed for signering\/verifikation af events, feltscopes, server‑side afvisning af kommando‑lignende mønstre, indbyggede rate limits og “safe schemas” målrettet agenter. Gør sikre defaults lette at vælge.
Til leverandører af AI‑agenter: adskil menneske‑ og agent‑udført aktivitet i logs, kræv signeret godkendelse til højrisiko‑handlinger, indfør whitelists og tydelige scopes i agent‑API’er, og eksponér hændelser som “external‑data‑triggered execution” til SIEM.
Status og åbne spørgsmål
Tenet og VentureBeat er enige om hovedpunkterne: én fabrikeret Sentry‑event kan kapre en agent i kontrollerede tests; 2.388 eksponerede DSN’er; 85 procent succesrate; ingen klassiske alarmer. VentureBeat anfører også, at Cloud Security Alliance beskrev agentjacking som en systemisk MCP‑sårbarhedsklasse efter offentliggørelsen. Der mangler dog stadig detaljer om fuld metodebeskrivelse, reproducerbarhed og leverandørpatches – punkter, som bør følges tæt i de kommende uger.
Tre korte råd til den tekniske leder
1) Inventarér og begræns straks: kortlæg DSN‑lignende endpoints, strip secrets, og luk for agent‑shell hvor det ikke er nødvendigt. 2) Indfør en gatekeeper mellem observability‑feeds og agenteksekvering med signering og whitelists. 3) Gør agentaktivitet synlig i logs, og test jeres alarmer med en enkel tabletop‑øvelse efter en simuleret Sentry‑event. Man mærker først forskellen, når man sidder med det i hænderne.
