Sikkerhetsselskapet Tenet Security demonstrerte et angrep de kaller «agentjacking», der en falsk feilrapport får en KI-kodingsagent til å kjøre angriperens kode på utviklerens egen maskin, med utviklerens egne rettigheter. Ifølge The Hacker News og The Next Web kreves ingen skadevare, ingen stjålet passord og ingen kompromittering av offerets infrastruktur. Angrepet lyktes i 85 % av forsøkene mot over 100 organisasjoner, og Tenet fant 2 388 organisasjoner med sårbare oppsett, fra en solo-utvikler til et selskap verdt 250 milliarder dollar.
Mekanismen utnytter et arkitektonisk svakt punkt i hvordan agenter henter data via Model Context Protocol (MCP). Sentry lar hvem som helst sende inn feilrapporter med en DSN, en offentlig skrivenøkkel som ligger åpent i nettstedets kode by design. Angriperen POSTer en falsk feil til dette endepunktet og gjemmer en kommando i en «Resolution»-seksjon, formatert med markdown så den ser identisk ut med Sentrys egne råd. Når utvikleren ber agenten «fikse de uløste Sentry-sakene», henter agenten den falske feilen gjennom MCP og kjører kommandoen som om den var betrodd veiledning.
«Angriperen berører aldri offerets infrastruktur. Den skadelige instruksjonen ankommer forkledd som en legitim ‘Resolution’ inne i en helt vanlig feilmelding.» — Ron Bobrov, Barak Sternberg og Nevo Poran, Tenet Security
Det farligste er hva som ikke fanger angrepet. Fordi hvert steg i kjeden er autorisert, glir det forbi EDR, brannmurer, IAM, VPN og Cloudflare. Tenet kaller det «Authorised Intent Chain». Selv prompt-forsvar hjelper ikke: agentene kjørte koden også når de eksplisitt fikk beskjed om å ignorere utrustede data. Ett injisert feilobjekt kan nå miljøvariabler, AWS-nøkler, GitHub-tokens, git-legitimasjon og private repo-URLer, og derfra videre inn i CI/CD-pipelines og skyinfrastruktur.
Tenet varslet Sentry 3. juni 2026. Sentry erkjente problemet, men avslo å fikse roten, med begrunnelsen at det er «teknisk ikke forsvarbart». Selskapet la i stedet inn et globalt filter som blokkerer én bestemt nyttelast-streng, altså symptombehandling. Kjernen sitter ikke i Sentry alene: den ligger i at agenter behandler all ekstern data som betrodd, så samme risiko går gjennom support-tickets, GitHub-issues og dokumentasjon.
For deg som kobler en agent mot et prosjekt du selv bygger, er dette den praktiske lærdommen: en agent koblet til verktøyene dine er også en ny vei inn. Det siste stedet å stoppe angrepet er øyeblikket agenten bestemmer seg for å handle.
Hva bør du gjøre?
Behandle alt en agent henter via MCP fra Sentry, GitHub-issues eller andre eksterne kilder som utrustet inndata, og gi den ikke stående tillatelse til å kjøre shell-kommandoer på slikt innhold uten et manuelt bekreftelses-steg. Husk at en Sentry-DSN er en skrivenøkkel hvem som helst kan poste til: sjekk om oppsettet ditt aksepterer vilkårlige feilobjekter, og begrens hva agenten får lov å gjøre med dem. Kjør kodingsagenter med minst mulig privilegier, slik at et kapret kall ikke automatisk når miljøvariabler, AWS-nøkler og git-legitimasjon.