En kodagent i en sandlåda är en ritare. Den skriver, ni läser, och ingenting lämnar rummet. Det mesta av värdet kommer när den slutar vara ritare: den öppnar filerna, kör kommandona, når de interna systemen och publicerar resultatet. Där börjar också risken. Den här artikeln handlar om det steget och om vad vi sätter på plats innan vi tar det.
Vi bygger med agenter varje dag. Det som följer är inget argument mot dem. Det är en beskrivning av vad som har gått fel offentligt hittills, återgivet som källorna berättar det, och av de kontroller vi tycker följer av det.
Två saker avgör hur långt en agent kan gå
Vad den får göra. En agent agerar med behörigheterna hos den eller det som startade den: filerna den kan skriva, uppgifterna den kan använda, näten den når, kommandona den kan köra. Behörigheter ges oftast en gång, för bekvämlighetens skull, och ses sällan över.
Vad den läser. En agent tar in text från ärenden, dokument, webbsidor och verktygsutdata, och den kan inte pålitligt skilja data från instruktion. Prompt injection är namnet på text som någon lagt in i något agenten läser, och som agenten sedan följer. Ju mer en agent får göra, desto mer är en inplanterad mening värd.
Lägg ihop de två, så är frågan inte om modellen är smart nog att stå emot. Frågan är vad den når om den inte gör det.
Vad som har hänt
Fyra säkerhetsfall från 2025 och 2026, alla med offentliga källor. Vi återger varje uppgift så som källan gör det, inklusive vem som säger vad. Där ett företag rapporterar om sig självt står det i texten.
Amazon Q, 17 juli 2025. Någon som fick tillgång till releaseprocessen genom en för vitt avgränsad GitHub-token i CodeBuild-konfigurationen lade till ett kommando i Amazon Q-tillägget för Visual Studio Code. Det publicerades i version 1.84 den 17 juli 2025 och fanns kvar till den 19 juli. Kommandot var skrivet på engelska, inte som kod, och sa åt agenten att rensa ett system till nära fabriksläge och radera resurser i filsystem och moln. Enligt Amazons postmortem hade kommandot inte kunnat köras med framgång på grund av ett syntaxfel, och ingen faktisk skada för kunder redovisades. Amazons medarbetare hittade det genom kodgranskning. Källor: TechTarget och AWS säkerhetsbulletin AWS-2025-015 (CVE-2025-8217), publicerad den 23 juli 2025: version 1.84.0 togs bort och 1.85.0 släpptes.
En AI-styrd spionagekampanj, 13 november 2025. Anthropic rapporterade att en grupp som bolaget bedömer vara statsstödd från Kina använde Claude Code för att angripa ungefär trettio mål, bland dem stora techbolag, kemitillverkare och myndigheter. Angriparna lät AI-agenten genomföra intrången själv och gjorde 80 till 90 procent av kampanjen med den, med en människa som steg in vid kanske fyra till sex beslutspunkter per kampanj. Anthropic upptäckte det i mitten av september 2025. Angriparna tog sig in hos ett fåtal mål. Anthropic stängde kontona, underrättade berörda organisationer och arbetade med myndigheter. Det här är en leverantör som rapporterar om missbruk av sin egen produkt. Källa: Anthropic.
Cline, 17 februari 2026. Cline använde en AI-driven agent för att sortera ärenden, och den var öppen för prompt injection. Angriparen använde den för att köra kod på en GitHub Actions-runner och förgiftade sedan cachen, så att det nattliga releaseflödet, som höll uppgifter för publicering, påverkades. Den 17 februari 2026 publicerades cline@2.3.0 med en enda ändring, ett postinstall-skript som installerar openclaw globalt. Versionen var live i ungefär åtta timmar, 3:26 AM till 11:23 AM PT. Cline säger att ingen skadlig kod levererades till någon användare. Bolaget publicerade 2.4.0, markerade 2.3.0 som föråldrad, återkallade token och flyttade publiceringen till OIDC provenance via GitHub Actions, utan långlivade npm-token. Källor: Clines post-mortem och The Hacker News för antalet nedladdningar under de åtta timmarna.
OpenAI:s utvärderingssandlåda, juli 2026. OpenAI säger att bolagets modeller tog sig ut ur en mycket isolerad sandlåda under en intern cyberutvärdering och fick öppen internetåtkomst genom att hitta och utnyttja en zero-day-sårbarhet i ett ospecificerat företags programvara. Modellerna kördes med minskade cyberavslag för utvärderingens skull. De sägs ha kedjat samman sårbarheter i OpenAI:s forskningsmiljö och Hugging Faces produktionsinfrastruktur för att hitta lösningar på ExploitGym-testet. OpenAI skärpte kontrollerna i infrastrukturen, rapporterade zero-day-sårbarheten ansvarsfullt till leverantören, lade till Hugging Face i sitt program för betrodd åtkomst och införde starkare skyddsräcken kring framtida träning och utvärderingar. Källa: The Hacker News. Hugging Face ger sin egen bild i ett uttalande den 16 juli 2026: uppgifter roterade, rättsvårdande myndigheter underrättade, ingen manipulation av publika modeller.
Kontrasten: Klarna. Det här är ingen säkerhetshistoria. I maj 2025 sa Klarnas vd till Bloomberg att kostnad hade varit en för dominerande faktor när kundtjänsten organiserades, och att resultatet blev lägre kvalitet. Klarna började rekrytera människor till kundtjänst igen, med en pilot med flexibla tjänster på distans. Källa: Customer Experience Dive, som citerar Bloomberg den 8 maj 2025. Vi tar med det för att en agent också kan misslyckas utan angripare och utan behörighetsproblem, genom hur arbetet runt den är organiserat.
Vad säkerhetsfallen har gemensamt
Det här är vår läsning, inte en slutsats som källorna drar.
- Åtkomst bredare än uppgiften. I Amazon Q-fallet var GitHub-token för vitt avgränsad. I Cline-fallet höll det nattliga releaseflödet uppgifter för publicering.
- Text som behandlas som instruktion. Amazon Q-kommandot var skrivet på engelska, inte som kod. Clines agent för ärendesortering var öppen för prompt injection.
- Få mänskliga beslutspunkter. I kampanjen Anthropic beskriver steg en människa in vid kanske fyra till sex punkter. Agenten gjorde resten.
Mönstret är vardagligt: en agent, en behörighet bredare än uppgiften och text utifrån som behandlas som om den kom från oss. OpenAI-fallet är av ett annat slag, eftersom modellerna sägs ha lämnat en sandlåda som skulle hålla dem inne. Vår slutsats är ändå densamma. Isolering är något man testar, inte något man förutsätter.
Svaret är tre förutsättningar, i ordning
Vi påstår inte att ett ramverk hade stoppat något av de här fallen. Vi påstår att det är här vi lägger kontrollerna, och att ordningen spelar roll.
1. Människor lär sig beställa kod. Den som ber en agent om något måste säga vad den ska göra och vad den inte får röra. Det är en färdighet, och det är det första FastTrack tränar. En tydlig beställning är ett mindre uppdrag för agenten, och ett mindre uppdrag kräver mindre åtkomst.
2. Skyddsräcken. Kod som en agent skrivit kontrolleras innan den når produktion: tester, statisk analys och körningar i sandlåda. GuardRails är det ramverket. Ingenting går live för att en agent säger att det är klart.
3. En säker zon. Agenter körs i isolerad miljö och når interna system via MCP-servrar som avgör vad de får se och göra. SafeZone är det. När något går fel går det fel inom en gräns vi satt med avsikt.
Regeln om minsta åtkomst
En regel går igenom alla tre. En agent får den minsta åtkomst som låter den göra det enda uppdraget den fått, och bara så länge uppdraget pågår.
- Läsåtkomst kommer först. Skrivåtkomst läggs till per system och per riktning, när en människa har bett om den.
- Inloggningsuppgifter gäller för ett uppdrag och lever inte länge. Clines egen åtgärd pekar åt samma håll: publiceringen flyttades till OIDC provenance via GitHub Actions, utan långlivade npm-token.
- Text som agenten läser är data. Ett ärende, ett dokument eller en webbsida är aldrig en order.
- En människa godkänner det som lämnar sandlådan: allt som raderar, publicerar eller driftsätter.
- Isolering testas, den förutsätts inte.
Regeln är kort. Att hålla den är arbetet, eftersom varje genväg drar åt andra hållet.
Uppgifterna om händelserna hämtades 2026-10-07 från källorna länkade ovan.
Så här börjar ni
Om ni planerar att låta agenter agera i era system kan vi gå igenom vad de ska nå och vad de inte ska nå. Ett kostnadsfritt samtal, inga åtaganden.