Microsoft-angrep viser ny risiko i AI-kodeagenter

Microsoft har midlertidig stengt en rekke egne åpne GitHub-repositorier etter at sikkerhetsforskere fant skadevare i pakker knyttet til Azure og utviklerverktøy for AI-koding. Selskapet bekreftet overfor TechCrunch at noen repositorier ble fjernet mens det undersøkte «potential malicious content». Flere er tilbake etter gjennomgang, mens andre fortsatt er offline.

Dette er ikke en vanlig npm-skandale i en tilfeldig hobby-pakke. Det rammer Microsoft-kontoer, GitHub, Azure-relaterte prosjekter og verktøykjeden rundt Claude Code, Gemini CLI, Cursor og VS Code. Ars Technica skriver at 73 pakker ble flagget som skadelige, og at koden kunne kjøres når en utvikler åpnet pakkene i AI-kodeagenter.

For norske teknologiledere er poenget enkelt: AI-kodeagenter flytter supply-chain-risikoen fra «hvilken kode installerte vi?» til «hvilken kode lot vi agenten lese, analysere og kjøre?». Den forskjellen er stor. En agent har ofte tilgang til terminal, repo, token-lager, skyløsninger, CI/CD, dokumentasjon og utviklerens lokale miljø. Da blir et kompromittert repo mer enn en dårlig dependency. Det blir et mulig startpunkt inn i produksjonslinjen.

Hva som skjedde

Ifølge TechCrunch kuttet Microsoft tilgang til dusinvis av åpne prosjekter på GitHub etter at angripere tilsynelatende hadde fått inn passordstjelende skadevare. Flere av prosjektene var knyttet til Microsoft Azure og utviklerverktøy brukt sammen med AI-kodeapper.

Microsofts talsperson Ben Hope sa til TechCrunch at selskapet midlertidig fjernet noen repositorier mens det undersøkte mulig ondsinnet innhold. Han sa også at Microsoft varslet et lite antall kunder som kan ha lastet ned innhold fra de berørte repositoriene.

Ars Technica beskriver angrepet som andre kjente kompromittering av en offisiell Microsoft-repo-konto på få uker. I mai ble Microsofts Durable Task Python SDK kompromittert. Den pakken brukes til å bygge robuste arbeidsflyter og orkestreringer, og skal ifølge Ars ha rundt 400 000 nedlastinger i måneden.

Skadevaren omtales som Miasma. Den skal være nært beslektet med Mini Shai-Hulud, et verktøy knyttet til aktøren TeamPCP. Cloudsmith beskriver ifølge Ars at Miasma ikke utnytter en klassisk sårbarhet i GitHub eller npm. Den utnytter tillitsmodellen i moderne utvikling: stjålne legitime publiseringsrettigheter, gyldig provenance og pakker som ser ut som normale oppdateringer.

Hvorfor AI-agentene gjør dette farligere

Tradisjonell supply-chain-sikkerhet har ofte vært bygget rundt låste versjoner, signaturer, scanning og manuell kodegjennomgang. Det hjelper fortsatt. Men AI-kodeagenter endrer flyten.

En utvikler kan be agenten forklare en pakke, refaktorere et repo, kjøre tester, installere avhengigheter eller foreslå integrasjon. I flere moderne verktøy er veien kort fra tekst til terminal. Hvis koden i repoet er laget for å lure agenten, er ikke risikoen bare at et menneske overser noe. Risikoen er at agenten leser instruksjoner, følger dem og gjør skade raskere enn en utvikler rekker å reagere.

Ars skriver at den credential-stealing-funksjonen i Miasma kunne trigges når en utvikler åpnet de infiserte pakkene i AI-agenter som Claude Code, Gemini CLI, Cursor og VS Code. Det gjør saken relevant langt utenfor Microsoft. Mange virksomheter ruller nå ut nettopp slike verktøy fordi de gir høyere utviklerfart. Den samme farten kan også gi angripere mindre friksjon.

Straiker publiserte samtidig research på NomShub, en sårbarhetskjede i Cursor der et ondsinnet repo kunne kombinere indirekte prompt injection, sandbox-escape og tunnel-funksjonalitet for å gi angripere vedvarende shell-tilgang. Det er en annen sak, men peker samme vei: AI-agentens kontekst og verktøytilgang er nå en sikkerhetsflate, ikke bare en produktivitetsfunksjon.

Lederkonsekvensen

CIO og CISO bør ikke lese dette som et argument mot AI-koding. Det toget har gått. Spørsmålet er hvordan verktøyene tas inn i styrt drift.

Første tiltak er å behandle AI-kodeagenter som privilegerte klienter. De bør ikke få bredere tilgang enn rollen krever. Token, SSH-nøkler, skylagring og produksjonsnære hemmeligheter bør ikke ligge åpent i utviklermiljøer som agenten kan lese eller bruke.

Andre tiltak er å stramme inn hvor agenter får kjøre kommandoer. «Approve all» og YOLO-modus er fristende i demoer. I en virksomhet er det en snarvei rundt kontrollene. Agentkjøring bør logges, isoleres og begrenses til arbeidsområdet. Kommandoer som skriver til dotfiles, starter tunneler, leser credential stores eller gjør nettverkskall ut av miljøet må behandles som røde flagg.

Tredje tiltak er å modernisere dependency-kontrollene. Hash-basert scanning alene er svakere når skadevaren lager unike krypterte payloads per infeksjon. Virksomheter bør kombinere lockfiles, forsinket utrulling av nye pakkeversjoner, provenance-sjekk, reputasjonssignaler, sandboxing og hurtig tilbakekalling av tokens. VS Code har allerede varslet en to timers forsinkelse på automatiske extension-oppdateringer for å redusere eksponeringen ved supply-chain-angrep. Det er et lite, men fornuftig eksempel på friksjon som sikkerhetsmekanisme.

Fjerde tiltak er beredskap. Hvis en utvikler har åpnet en berørt pakke eller et mistenkelig repo i en AI-agent, holder det ikke å slette katalogen. Hemmeligheter må roteres, GitHub- og cloud-logger må sjekkes, CI/CD-runnere må vurderes, og maskinen bør behandles som mulig kompromittert.

Hva norske virksomheter bør gjøre nå

Lag en enkel policy for AI-kodeagenter før bruken blir usynlig. Den bør svare på fem spørsmål: Hvilke agenter er godkjent? Hvilke repoer kan de åpne? Hvilke kommandoer kan de kjøre uten ekstra godkjenning? Hvilke hemmeligheter kan miljøet eksponere? Hvem får varsel hvis agenten starter tunnel, skriver til shell-profiler eller forsøker å lese credentials?

Det viktigste er ikke å stoppe utviklere fra å bruke gode verktøy. Det viktigste er å fjerne antakelsen om at en AI-agent bare er en teksteditor med litt bedre autofullføring. Den er en aktør i utviklingsmiljøet. Da må den inn i IAM, endpoint-sikkerhet, logging og leverandørstyring på samme måte som andre privilegerte verktøy.

Microsoft-hendelsen viser at selv store leverandører kan få legitime repoer og pakker brukt som angrepsvei. Når agentene blir standardgrensesnittet for utvikling, blir repoet ikke bare kildekode. Det blir instruksjonsflate. Det må sikkerhetsmodellen ta høyde for.

Kilder og medier

Primærkilde: TechCrunch, «Microsoft's open source tools were hacked to steal passwords of AI developers», https://techcrunch.com/2026/06/08/microsofts-open-source-tools-were-hacked-to-steal-passwords-of-ai-developers/

Tilleggskilder: Ars Technica, «For the 2nd time in weeks, Microsoft packages laced with credential stealer», https://arstechnica.com/security/2026/06/for-the-2nd-time-in-weeks-microsoft-packages-laced-with-credential-stealer/ ; 404 Media, «Microsoft Hacked to Deliver Malware to Claude and Gemini Users», https://www.404media.co/microsoft-hacked-to-deliver-malware-to-claude-and-gemini-users/ ; Straiker, «NomShub: Weaponizing Cursor's Remote Tunnel Through Indirect Prompt Injection and Sandbox Breakout», https://www.straiker.ai/blog/nomshub-cursor-remote-tunneling-sandbox-breakout

Thumbnail: OpenAI Image 2 / hogby.ai