Sådan kan en andens repository kapre Claude Code: 7 beskyttelsesregler

Ailoot-dokumentation: API, nøgler og opsætning.

Fire dokumenterede veje fra ikke-betroet tekst til agenthandlinger#

Formelt kaldes dette indirekte promptinjektion: En skadelig instruktion kommer ikke direkte fra dig, men gennem data, som agenten behandler, mens den udfører en opgave – en fremmed README, en fejlmeddelelse, en GitHub-kommentar eller et svar fra en ekstern tjeneste. Du kan glemme udtrykket lige efter dette afsnit; fra nu af bruger jeg almindelige ord.

Fire forskningseksempler gennemgås nedenfor:

1. Et repository, der ser harmløst ud, blev vist at kunne blive til en reverse shell.
2. En Pull Request-titel blev vist at kunne kapre tre forskellige AI-agenter på én gang.
3. En agent blev vist at kunne acceptere en falsk fejlrapport fra Sentry i stedet for en rigtig.
4. En MCP-værktøjsbeskrivelse blev vist at kunne påvirke agentens handlinger; effekten afhænger af model og opsætning.

Hvordan kan et harmløst repositorys README blive til en reverse shell?#

Mekanikken er udformet, så intet enkelt lag ser mistænkeligt ud:

1. Du kloner et repository, der ser almindeligt ud, og beder Claude Code om at køre det.
2. Repositoryt henter en Python-pakke, der er designet til at fejle ved første brug.
3. Fejlmeddelelsen foreslår høfligt en “fix”-kommando: python3 -m axiom init.
4. Kommandoen init kører setup.sh.
5. Scriptet forespørger en DNS TXT-post (som normalt bruges til domænerelaterede noter, men feltet accepterer vilkårlig tekst). Angriberen lægger en base64-kodet kommando dér (en måde at omdanne data til almindelig tekst uden mellemrum eller specialtegn) og sender den direkte videre til bash.
6. DNS-postens værdi kan ændres når som helst – hvilket giver angriberen en interaktiv reverse shell med dine brugerrettigheder og adgang til alle hemmeligheder på maskinen.

Den demonstrerede nyttelast blev hentet under kørsel fra DNS, så scanning af repositoryets bytes alene afslørede ikke den endelige nyttelast. Det beviser ikke, at enhver scanner eller runtimekontrol er magtesløs: Inspektion af hentet indhold, procesovervågning og netværksbegrænsninger kan afsløre eller afbryde kæden. Kilden er et proof of concept, ikke en måling af virkelige hændelsers udbredelse.

Hvordan kaprede en Pull Request-titel tre forskellige AI-agenter?#

Forskeren beskriver disse veje og svar; det er en historisk rapport, ikke verifikation af enhver aktuel produktversion:

Der gik næsten fem måneder mellem den første og den sidste rapport i denne rapporteringscyklus (den første rapport om Claude Code kom den 17. oktober 2025; den sidste fejlrettelse til GitHub Copilot kom den 9. marts 2026). Rapportens alvorændring og begrænsninger dokumenterer ikke fuld lukning af enhver mulig nyttelast. Forskerens PoC-repository dokumenterer den demonstrerede Claude-vej; kør ikke angrebsnyttelasten mod rigtige systemer. Værdien for dig ligger i selve angrebsmønstret: ubekræftede data fra GitHub kommer ind i agenten, agenten kører kommandoer, og hemmeligheder lækkes gennem det samme GitHub – angriberen behøver ingen ekstern server.

To analyser er nok til at se mønstret: Det er ikke holdbart at rette hvert nyt fund enkeltvis; sårbarheder af denne type dukker op hver anden uge. At skrive sikkerhedsregler eksplicit i CLAUDE.md og settings.json i stedet for at have dem i hovedet er en del af kontekststyring: Indstil dem én gang, så fungerer de automatisk i hver ny Claude Code-session uden påmindelser. Tre grundpiller arbejder sammen: AI-klon + Anden hjerne + Kontekststyring – denne kombination gør Claude Code til en agent med eksplicitte regler i stedet for en eksekveringsmotor, der stoler på alt.

Kan en falsk fejlrapport fra Sentry overtage din agent?#

Angrebet kræver ikke andet end en Sentry DSN-nøgle – en offentlig identifikator, som mange projekter inkluderer direkte i klientkode:

Mekanikken er enkel: En udvikler beder agenten undersøge åbne Sentry-fejl; agenten henter dem gennem MCP-serveren, modtager en skadelig hændelse blandet med de rigtige og læser kommandoen, der er indlejret i den, som en betroet instruktion til at rette fejlen – for formelt set er det præcis den opgave, den blev bedt om at udføre.

Tenet rapporterer, at eksisterende kontroller ikke alarmerede i de testede miljøer. Det dokumenterer ikke sporløs udførelse i alle udrulninger: Agent-/værktøjslogs, endpointtelemetri og netværksregistreringer kan opfange efterfølgende handlinger. Angrebet begynder gennem eksternt indsendt telemetri og afhænger derefter af agentens faktiske værktøjer og tilladelser.

Hvordan kan en MCP-værktøjsbeskrivelse påvirke agenten?#

Microsofts formulering er den mest præcise, jeg har fundet om emnet:

Denne teknik kaldes tool poisoning: En instruktion, der er skjult i beskrivelsen af et uskyldigt værktøj, får agenten til at handle på den.

Værktøjsmetadata kan indeholde instruktioner, som påvirker modellen, men svarer ikke automatisk til systempromptbeføjelser. MCPTox, først indsendt 19. august 2025, evaluerer værktøjsforgiftning gennem realistiske MCP-værktøjer og rapporterer modtagelighed, der varierer med model og opsætning. Observationen om, at stærkere modeller kan være mere modtagelige, er et resultat inden for det benchmark, ikke en universel lov.

Hvad har angrebene til fælles – og hvad kan detektion overse?#

Konklusionen gælder alle fire fund: Du kan ikke stole på, at “koden ser normal ud” – hvert enkelt trin i et angreb er faktisk harmløst. Begræns agentens faktiske kapacitet, og undersøg foreslåede handlinger; detektion og begrænsning adresserer forskellige dele af angrebet.

Hvilken beskyttelse har Claude Code allerede – og hvorfor er den ikke nok?#

Anthropic anerkender problemet direkte i sin dokumentation i stedet for at skjule det:

Ifølge dokumentationen analyserer agenten hele prompten for mistænkelige instruktioner, godkender ikke automatisk curl og wget, holder webindhold i et separat kontekstvindue, så det ikke blandes sammen med hovedvinduet, og kræver bekræftelse af tillid, første gang du starter den i en ny kodebase eller opretter forbindelse til en ny MCP-server.

Men der er et hårdt forbehold, som Anthropic udtrykker direkte:

Hvis du nogensinde har startet Claude Code med --dangerously-skip-permissions af irritation, så den ville “holde op med at plage dig med spørgsmål”, var det dér, du slog alle de mekanismer fra, som kunne have stoppet netop de fire angreb, der er omtalt ovenfor. Jeg holder bevidst dette flag slået fra, selv når Claude Code spørger for tiende gang i en session – det bliver irriterende, men spørgsmålene er grænsen mellem “agenten læste mistænkelig tekst” og “agenten udførte den”. En fornuftig opsætning for en ikke-programmør er standardtilstanden for tilladelser (default eller acceptEdits) plus aktiveret sandbox: almindelige filændringer sker uden ekstra spørgsmål, mens terminalkommandoer fysisk ikke kan slippe ud af sandboxen, selv hvis agenten er blevet narret.

Hvordan aktiverer du sandbox-tilstand og lukker det hul, der som standard står åbent?#

Aktivér den permanent for alle projekter ved at foretage én ændring i ~/.claude/settings.json:

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

Som standard kan sandboxede kommandoer kun skrive til projektets arbejdsmappe og sessionens midlertidige mappe. Netværksadgang går gennem en proxy – ingen domæner er forhåndsgodkendt, og Claude Code beder om bekræftelse, første gang den kontakter et nyt domæne. Anthropic siger, at dette reducerer antallet af tilladelsesspørgsmål markant – med 84% i virksomhedens interne målinger – fordi sandboxen selv håndterer nogle sikre tilfælde i stedet for at spørge dig hver gang.

Hullet, som standardindstillingerne lader stå åbent: Sandboxen begrænser skrivning som standard, men forhindrer ikke læsning af filer som ~/.aws/credentials og ~/.ssh. Det er netop de filer og miljøvariabler, der er mål for angrebene ovenfor. Luk hullet med en separat blok i den samme 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" }
      ]
    }
  }
}

Pointen er, at selv hvis reverse shellen fra den første analyse åbnes inde i sandboxen, fjernes disse variabler og filer fysisk fra procesmiljøet, før det starter – der er intet tilbage at stjæle.

Hvilke permissions.deny-regler bør du tilføje i dag?#

Et minimalt sæt til en ikke-programmør, der dækker hovedmålene for alle fire angreb på én gang:

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

Ifølge Claude Code-dokumentationen har deny-regler altid forrang frem for allow-regler. Så selv hvis du (eller agenten selv) ved et uheld tillader bredere adgang et andet sted, træder en specifik deny stadig i kraft først. Regelforrangen gælder matchende værktøjsforespørgsler. Den beviser ikke, at en hemmelighed er utilgængelig gennem enhver underproces eller ethvert værktøj; brug også håndhævede filsystem- og miljøbegrænsninger.

Claude Code har også en auto-tilstand, hvor en separat klassifikationsmodel kontrollerer handlinger, før de udføres – det er ikke den samme model, som taler med dig. Som standard blokerer den blandt andet præcis mønstret “download kode og udfør den med det samme” (curl | bash). Anthropic advarer udtrykkeligt om, at dette er en forskningstilstand, der reducerer antallet af spørgsmål, men ikke i sig selv garanterer sikkerhed – betragt den som et ekstra lag, ikke som en erstatning for sandboxen og permissions.deny.

Hvordan kontrollerer du et repository og en MCP-server, før du stoler på dem med din agent?#

For repositories er her en kort tjekliste, før du overlader dem til agenten:

1. Gå ikke direkte til installation fra et link i en e-mail, et opslag eller en anmeldelse fra en ukendt kilde – det er præcis sådan, disse repositories distribueres ifølge 0Dins advarsel.
2. Hvis installationen giver en fejl med instruktion om at “køre kommando X for at rette det”, så læs, hvad X faktisk gør, før du giver Claude Code lov til at køre den. Instruktionen i analysen ovenfor så helt rutinemæssig ud – det var netop pointen.
3. Kontrollér repositoryts alder og commit-historik, ikke kun antallet af stjerner – nystartede repositories kan let få falske stjerner netop til denne type angreb.
4. Hvis repositoryt er ukendt, så kør installationen i en virtuel maskine, ikke på din arbejdsmaskine med rigtige nøgler. Dette er Anthropics egen direkte anbefaling til arbejde med eksterne tjenester.

Anthropics holdning til MCP-servere er fremlagt åbent:

Det betyder, at du er ansvarlig for at kontrollere tredjeparts MCP-servere, ikke platformen, hvor du installerede dem. Nogle teams – for det meste sikkerhedsstartups – bygger allerede værktøjer til dette: MCP-konfigurationsscannere, der leder efter forgiftede beskrivelser, og værktøjs-“pinning”, der gemmer beskrivelsens hash ved første installation og markerer senere ændringer. Denne teknologi er ny, så det er for tidligt at stole på den som din eneste beskyttelse – men den er værd at holde øje med, især hvis du forbinder MCP-servere til produktion. Til disse forbindelser kan du fastlåse hver pakkeversion og registrere fingeraftrykket af værktøjsbeskrivelserne i en auditlog.

7 regler til beskyttelse: dagens tjekliste#

1. Aktivér sandbox-tilstand (/sandbox eller "sandbox": {"enabled": true} i ~/.claude/settings.json), og tilføj en credentials-blok, der forhindrer læsning af ~/.ssh og ~/.aws/credentials.
2. Tilføj permissions.deny-regler for læsning af hemmelige filer og farlige bash-kommandoer (curl, wget, sudo) – en deny tilsidesætter altid en allow.
3. Kør aldrig --dangerously-skip-permissions med fremmed eller ubekræftet kode – det deaktiverer alle beskyttelser på én gang, herunder dem, der kunne have stoppet netop disse angreb.
4. Lad ikke Claude Code automatisk køre en “fix”-kommando fra en fejlmeddelelse – læs først, hvad den faktisk gør.
5. Installér kun MCP-servere fra kilder, du har tillid til, og husk, at Anthropic ikke kontrollerer deres sikkerhed for dig.
6. Adskil sessioner efter tilladelser: Én arbejder med dine personlige data og ser ikke eksterne data; en anden undersøger andres e-mails, repositories og tickets, men har ikke adgang til hemmeligheder; en tredje publicerer eksternt – og kun det, du personligt har godkendt. Jeg håndhæver denne adskillelse strengt i mine egne projekter: En session med adgang til betalingsnøgler læser aldrig vilkårlige eksterne tickets eller repositories, og en session, der analyserer andres kode, ser slet ingen hemmeligheder. Bland ikke disse roller i én chat.
7. Hold Claude Code og tilsluttede automatiseringsscripts opdaterede – de fleste af de huller, der omtales her, var allerede lukket med patches, da denne guide blev publiceret, og nye huller rettes på lignende måde.

Hvad nu?#

Ingen af disse lag er en garanti – Anthropic siger selv ærligt, at ingen beskyttelse giver fuldstændig immunitet. Jeg forventer ikke, at Claude Code selv genkender et trick i en fejlmeddelelse eller en issue-kommentar. For mig er sandboxen og permissions.deny en del af, hvordan jeg styrer projektkonteksten: hvad agenten ser, hvad den som standard stoler på, og hvad der sker, når den begår en fejl.

Hvis du har brug for adgang til neurale netværk via Ailoot, så tag et kig på Ailoot.