Hur någon annans repository kan kapa Claude Code: 7 skyddsregler

Ailoot-dokumentation: API, nycklar och konfiguration.

Fyra dokumenterade vägar från opålitlig text till agentåtgärder#

Formellt kallas detta indirekt promptinjektion: en skadlig instruktion kommer inte direkt från dig, utan via data som agenten behandlar medan den utför en uppgift – ett främmande README, ett felmeddelande, en GitHub-kommentar eller ett svar från en extern tjänst. Du kan glömma termen direkt efter det här stycket; hädanefter använder jag vanliga ord.

Fyra forskningsexempel som diskuteras nedan:

1. Ett harmlöst utseende repository visades kunna förvandlas till en reverse shell.
2. En Pull Request-titel visades kunna kapa tre olika AI-agenter samtidigt.
3. En agent visades kunna matas med en falsk felrapport från Sentry i stället för en riktig.
4. Förgiftad MCP-verktygsmetadata visades kunna påverka agentens verktygsanvändning i testade konfigurationer.

Hur kan ett harmlöst repositorys README förvandlas till en reverse shell?#

Mekaniken är utformad så att inget enskilt lager verkar misstänkt:

1. Du klonar ett repository som ser vanligt ut och ber Claude Code att köra det.
2. Repositoryt hämtar ett Python-paket som är utformat för att misslyckas vid första användningen.
3. Felmeddelandet föreslår artigt ett ”fix”-kommando: python3 -m axiom init.
4. Kommandot init kör setup.sh.
5. Skriptet frågar efter en DNS TXT-post (som vanligtvis används för domänrelaterade anteckningar, men fältet godtar vilken text som helst). Angriparen lägger in ett base64-kodat kommando där (ett sätt att omvandla data till vanlig text utan mellanslag eller specialtecken) och skickar det direkt vidare till bash.
6. DNS-postens värde kan ändras när som helst – vilket ger angriparen en interaktiv reverse shell med dina användarbehörigheter och åtkomst till alla hemligheter på datorn.

Den demonstrerade nyttolasten hämtades under körning från DNS, så en skanning av enbart repositoryts bytes avslöjade inte slutlig nyttolast. Det bevisar inte att varje skanner eller körningskontroll är maktlös: granskning av hämtat innehåll, processövervakning och nätverksbegränsningar kan synliggöra eller avbryta kedjan. Källan är ett proof of concept, inte en mätning av verkliga incidenters förekomst.

Hur kunde en Pull Request-titel kapa tre olika AI-agenter?#

Forskaren beskriver följande vägar och svar; det är en historisk rapport, inte verifiering av varje aktuell produktversion:

Nästan fem månader gick mellan den första och den sista rapporten i den här rapporteringscykeln (den första rapporten om Claude Code kom den 17 oktober 2025; den sista buggfixen för GitHub Copilot kom den 9 mars 2026). Rapportens ändrade allvarlighetsgrad och begränsningsåtgärder fastställer inte fullständig stängning av varje tänkbar nyttolast. Forskarens PoC-repository dokumenterar den demonstrerade Claude-vägen; kör inte attacknyttolasten mot riktiga system. Värdet för dig ligger i själva attackmönstret: overifierad data från GitHub kommer in i agenten, agenten kör kommandon och hemligheter läcker via samma GitHub – angriparen behöver ingen extern server.

Det räcker med två analyser för att se mönstret: det är inte hållbart att åtgärda varje nytt fynd ett i taget; sårbarheter av den här typen dyker upp varannan vecka. Att uttryckligen skriva säkerhetsregler i CLAUDE.md och settings.json i stället för att ha dem i huvudet är en del av kontextutformning: ställ in dem en gång så fungerar de automatiskt i varje ny Claude Code-session, utan påminnelser. Tre grundpelare samverkar: AI-klon + Andra hjärnan + Kontextutformning – den kombinationen gör Claude Code till en agent med uttryckliga regler i stället för en exekverare som litar på allt.

Kan en falsk felrapport från Sentry ta över din agent?#

Attacken kräver inget annat än en Sentry DSN-nyckel – en offentlig identifierare som många projekt inkluderar direkt i klientkod:

Mekaniken är enkel: en utvecklare ber agenten granska öppna Sentry-fel; agenten hämtar dem via MCP-servern, får en skadlig händelse bland de riktiga och läser kommandot som är inbäddat i den som en betrodd instruktion för att åtgärda felet – eftersom det formellt sett är exakt den uppgift den fick.

Tenet rapporterar att befintliga kontroller inte larmade i testade miljöer. Det fastställer inte spårlös körning överallt: agent-/verktygsloggar, ändpunktstelemetri och nätverksloggar kan fånga senare åtgärder. Attacken börjar via externt inskickad telemetri och beror sedan på agentens faktiska verktyg och behörigheter.

Hur kan en MCP-verktygsbeskrivning påverka agenten?#

Microsofts formulering är den mest precisa jag har hittat i ämnet:

Den här tekniken kallas tool poisoning: en instruktion som gömts i beskrivningen av ett oskyldigt verktyg får agenten att agera på den.

I det citerade benchmarktestet presterade Claude 3.7 Sonnet bäst i motståndskraft, men även den vägrade följa en förgiftad instruktion i färre än 3% av fallen. Det gäller testets förutsättningar och är inget generellt säkerhetsmått. Benchmarkens observation om mer kapabla modellers mottaglighet får inte användas som en universell lag för andra modeller, verktyg eller behörigheter.

Vad har attackerna gemensamt — och vad kan upptäckt missa?#

Slutsatsen gäller alla fyra fynden: du kan inte lita på att ”koden ser normal ut” – varje enskilt steg i en attack är faktiskt harmlöst. Begränsa agentens faktiska förmågor och granska föreslagna åtgärder; upptäckt och begränsning hanterar olika delar av attacken.

Vilket skydd har Claude Code redan – och varför räcker det inte?#

Anthropic erkänner problemet direkt i sin dokumentation, i stället för att dölja det:

Enligt dokumentationen analyserar agenten hela prompten efter misstänkta instruktioner, godkänner inte automatiskt curl och wget, håller webbinnehåll i ett separat kontextfönster så att det inte blandas med huvudfönstret och kräver bekräftelse av förtroende första gången du startar den i en ny kodbas eller ansluter en ny MCP-server.

Men det finns en tydlig reservation som Anthropic uttrycker rakt på sak:

Om du någon gång har startat Claude Code med --dangerously-skip-permissions av irritation för att den skulle ”sluta tjata med frågor”, då stängde du av alla mekanismer som hade kunnat stoppa just de fyra attacker som diskuteras ovan. Jag låter medvetet den här flaggan vara avstängd, även när Claude Code frågar för tionde gången under en session – det blir irriterande, men frågorna är gränsen mellan ”agenten läste misstänkt text” och ”agenten körde den”. En rimlig konfiguration för en icke-programmerare är standardläget för behörigheter (default eller acceptEdits) plus aktiverad sandbox: vanliga filändringar sker utan extra frågor, medan sandboxens faktiska fil- och nätverksgränser behöver verifieras för den konfiguration du använder, även om agenten har lurats.

Hur aktiverar du sandboxläget och täpper till luckan som standardinställningen lämnar öppen?#

Aktivera det permanent för alla projekt genom att göra en ändring i ~/.claude/settings.json:

{
  "sandbox": { "enabled": true }
}

Som standard kan sandboxade kommandon bara skriva till projektets arbetskatalog och sessionens temporära katalog. Nätverksåtkomst går via en proxy – inga domäner är tillåtna i förväg, och Claude Code ber om bekräftelse första gången den kontaktar en ny domän. Anthropic säger att detta minskar antalet behörighetsfrågor kraftigt – med 84% enligt företagets interna mätningar – eftersom sandboxen hanterar vissa säkra fall själv i stället för att fråga dig varje gång.

Luckan som standardinställningarna lämnar öppen: sandboxen begränsar skrivning som standard, men förhindrar inte läsning av filer som ~/.aws/credentials och ~/.ssh. Det är just de filer och miljövariabler som riktas in i de analyserade attackerna ovan. Täpp till den luckan med ett separat block i samma fil:

{
  "sandbox": {
    "enabled": true,
    "credentials": {
      "files": [
        { "path": "~/.aws/credentials", "mode": "deny" },
        { "path": "~/.ssh", "mode": "deny" }
      ],
      "envVars": [
        { "name": "GITHUB_TOKEN", "mode": "deny" },
        { "name": "NPM_TOKEN", "mode": "deny" }
      ]
    }
  }
}

Poängen är att även om reverse shellen från den första analysen öppnas inne i sandboxen, tas dessa variabler och filer rent fysiskt bort från processmiljön innan den startar – det finns inget kvar att stjäla.

Vilka permissions.deny-regler bör du lägga till i dag?#

En minimal uppsättning för en icke-programmerare som täcker huvudmålen för alla fyra attacker samtidigt:

{
  "permissions": {
    "deny": [
      "Read(~/.ssh/**)",
      "Read(~/.aws/credentials)",
      "Read(.env)",
      "Bash(curl *)",
      "Bash(wget *)",
      "Bash(sudo *)"
    ]
  }
}

Enligt Claude Code-dokumentationen har deny-regler alltid företräde framför allow-regler. Så även om du (eller agenten själv) av misstag tillåter bredare åtkomst någon annanstans, tillämpas en specifik deny-regel först. Regelföreträdet gäller matchande verktygsförfrågningar. Det bevisar inte att en hemlighet är oåtkomlig via varje underprocess eller verktyg; använd även upprätthållna filsystems- och miljöbegränsningar.

Claude Code har också ett auto-läge, där en separat klassificeringsmodell granskar åtgärder innan de körs – det är inte samma modell som pratar med dig. Som standard blockerar den bland annat exakt mönstret ”hämta kod och kör den direkt” (curl | bash), vilket är hur den första attacken ovan avslutas. Anthropic varnar uttryckligen för att detta är ett forskningsläge som minskar antalet frågor men inte garanterar säkerhet på egen hand – betrakta det som ett extra lager, inte som en ersättning för sandboxen och permissions.deny.

Hur kontrollerar du ett repository och en MCP-server innan du låter agenten lita på dem?#

För repositoryn är här en kort checklista innan du lämnar över dem till agenten:

1. Gå inte direkt till installation från en länk i ett mejl, inlägg eller en recension från en okänd källa – enligt 0Dins varning är det precis så dessa repositoryn sprids.
2. Om installationen ger ett fel med en instruktion om att ”köra kommando X för att fixa det”, läs vad X faktiskt gör innan du låter Claude Code köra det. Instruktionen i analysen ovan såg helt rutinmässig ut – det var själva poängen.
3. Kontrollera repositoryts ålder och commit-historik, inte bara antalet stjärnor – nya repositoryn kan lätt få falska stjärnor just för den här typen av attack.
4. Om repositoryt är obekant, kör installationen i en virtuell maskin, inte på din arbetsdator med riktiga nycklar. Detta är Anthropics egen uttryckliga rekommendation för arbete med externa tjänster.

Anthropics ståndpunkt om MCP-servrar är tydligt uttryckt:

Det innebär att det är ditt ansvar att kontrollera MCP-servrar från tredje part, inte plattformen där du installerade dem. Vissa team – mestadels säkerhetsstartups – bygger redan verktyg för detta: skannrar för MCP-konfiguration som letar efter förgiftade beskrivningar och ”pinnade” verktyg som sparar beskrivningens hash vid den första installationen och flaggar senare ändringar. Den här tekniken är ny, så det är för tidigt att förlita sig på den som enda skydd – men den är värd att följa, särskilt om du ansluter MCP-servrar till produktion. För sådana anslutningar kan du låsa varje paketversion och registrera fingeravtrycket för verktygsbeskrivningarna i en granskningslogg.

7 regler för skydd: dagens checklista#

1. Aktivera sandboxläget (/sandbox eller "sandbox": {"enabled": true} i ~/.claude/settings.json) och lägg till ett credentials-block som förhindrar läsning av ~/.ssh och ~/.aws/credentials.
2. Lägg till permissions.deny-regler för läsning av hemliga filer och farliga bash-kommandon (curl, wget, sudo) – en deny-regel åsidosätter alltid en allow-regel.
3. Kör aldrig --dangerously-skip-permissions med främmande eller overifierad kod – flaggan inaktiverar alla skydd på en gång, även dem som kunde ha stoppat just dessa attacker.
4. Låt inte Claude Code automatiskt köra ett ”fix”-kommando från ett felmeddelande – läs först vad kommandot faktiskt gör.
5. Installera MCP-servrar endast från källor du litar på, och kom ihåg att Anthropic inte säkerhetsgranskar dem åt dig.
6. Separera sessioner efter behörighet: en arbetar med dina personuppgifter och ser inte externa data; en andra granskar andras mejl, repositoryn och ärenden men har inte åtkomst till hemligheter; en tredje publicerar externt – och endast sådant som du personligen har godkänt. Jag tillämpar detta strikt i mina egna projekt: en session med åtkomst till betalningsnycklar läser aldrig godtyckliga externa ärenden eller repositoryn, och en session som analyserar andras kod ser inga hemligheter alls. Blanda inte dessa roller i en och samma chatt.
7. Håll Claude Code och anslutna automatiseringsskript uppdaterade och kontrollera specifika leverantörsåtgärder för din version; historiska åtgärder bevisar inte att varje nytt injektionsförsök är blockerat.

Vad händer härnäst#

Inget av dessa lager är en garanti – Anthropic säger själv ärligt att inget skydd ger fullständig immunitet. Jag förväntar mig inte att Claude Code själv ska känna igen ett trick i ett felmeddelande eller en ärendekommentar. För mig är sandboxen och permissions.deny en del av hur jag hanterar projektkontext: vad agenten ser, vad den litar på som standard och vad som händer när den gör ett misstag.

Om du behöver åtkomst till neurala nätverk via Ailoot kan du ta en titt på Ailoot.