Slik kan andres repository kapre Claude Code: 7 beskyttelsesregler

Ailoot-dokumentasjon: API, nøkler og oppsett.

Fire dokumenterte ruter fra ubetrodd tekst til agenthandlinger#

Formelt kalles dette indirekte prompt injection: En ondsinnet instruksjon kommer ikke direkte fra deg, men via data som agenten behandler mens den utfører en oppgave – en fremmed README, en feilmelding, en GitHub-kommentar eller et svar fra en ekstern tjeneste. Du kan glemme begrepet rett etter dette avsnittet; herfra bruker jeg et vanlig språk.

Fire forskningseksempler omtales nedenfor:

1. Et repository som ser harmløst ut, kan bli til et omvendt skall.
2. En Pull Request-tittel ble vist å kapre tre forskjellige AI-agenter samtidig.
3. En agent ble vist å godta en falsk feilrapport fra Sentry i stedet for en ekte.
4. MCP-verktøymetadata ble vist å kunne påvirke agentens verktøyhandlinger; dette tilsvarer ikke automatisk systempromptfullmakt.

Hvordan blir README-filen i et harmløst repository til et omvendt skall?#

Mekanismen er utformet slik at ingen enkelt del virker mistenkelig:

1. Du kloner et vanlig repository og ber Claude Code om å kjøre det.
2. Repositoryet henter inn en Python-pakke som er laget for å feile første gang den brukes.
3. Feilmeldingen foreslår høflig «rettingskommandoen» python3 -m axiom init.
4. Kommandoen init kjører setup.sh.
5. Skriptet spør etter en DNS TXT-post (vanligvis brukt til domenenotater, men feltet godtar vilkårlig tekst). Angriperen legger en base64-kodet kommando der (en måte å gjøre vilkårlige data om til ren tekst uten mellomrom eller spesialtegn) og sender den rett videre til bash.
6. Verdien i DNS-posten kan endres når som helst – noe som gir angriperen et interaktivt omvendt skall med dine brukertillatelser og tilgang til alle hemmelighetene på maskinen.

Den demonstrerte nyttelasten ble hentet fra DNS under kjøring. Skanning bare av repositoryets byte viste derfor ikke siste nyttelast. Det beviser ikke at alle skannere eller kjøretidskontroller er maktesløse. Inspeksjon av hentet innhold, prosessovervåking og nettverksbegrensninger kan avdekke eller avbryte kjeden. Kilden er et proof of concept, ikke en måling av utbredelse i virkelige hendelser.

Hvordan kapret en Pull Request-tittel tre forskjellige AI-agenter?#

Forskeren beskriver disse rutene og svarene. Dette er en historisk rapport, ikke verifikasjon av hver nåværende produktversjon:

Det gikk nesten fem måneder mellom den første og den siste rapporten i denne offentliggjøringssyklusen (den første rapporten om Claude Code kom 17. oktober 2025; den siste feilrettingen for GitHub Copilot kom 9. mars 2026). Endret alvorlighetsgrad og tiltak i rapporten fastslår ikke fullstendig lukking av alle nyttelaster. Forskerens PoC-repository dokumenterer demonstrert Claude-rute. Ikke kjør angrepsnyttelasten mot virkelige systemer. Verdien for deg ligger i selve angrepsmønsteret: ubekreftede data fra GitHub kommer inn i agenten, agenten kjører kommandoer, og hemmeligheter lekker ut gjennom det samme GitHub – angriperen trenger ingen ekstern server.

To analyser er nok til å se mønsteret: Det er ikke gjennomførbart å rette opp hvert nye funn enkeltvis; sårbarheter av denne typen dukker opp annenhver uke. Å skrive sikkerhetsregler uttrykkelig i CLAUDE.md og settings.json i stedet for å ha dem i hodet, er en del av kontekstutvikling: Sett dem én gang, så virker de automatisk i hver nye Claude Code-økt, uten påminnelser. Tre grunnpilarer virker sammen: AI-klone + Andre hjerne + Kontekstutvikling – denne kombinasjonen gjør Claude Code fra en utfører som stoler på alt, til en agent med uttrykkelige regler.

Kan en falsk Sentry-feilrapport ta over agenten din?#

Angrepet krever ikke mer enn en Sentry DSN-nøkkel – en offentlig identifikator som mange prosjekter legger rett inn i klientkode:

Mekanismen er enkel: En utvikler ber agenten undersøke åpne Sentry-feil; agenten henter dem gjennom MCP-serveren, mottar en ondsinnet hendelse blandet med ekte hendelser og leser kommandoen som er innebygd i den, som en pålitelig instruksjon for å rette feilen – for formelt sett er det akkurat dette agenten ble bedt om å gjøre.

Tenet rapporterer at eksisterende kontroller ikke varslet i de testede miljøene. Det fastslår ikke sporløs kjøring i alle utrullinger. Agent-/verktøylogger, endepunkttelemetri og nettverksregistreringer kan fange senere handlinger. Angrepet begynner gjennom eksternt innsendt telemetri og avhenger deretter av agentens faktiske verktøy og tillatelser.

Hvorfor er en MCP-verktøybeskrivelse like farlig som en systemprompt?#

Microsofts formulering er den mest presise jeg har funnet om dette temaet:

Denne teknikken kalles verktøyforgiftning: En instruksjon skjult i beskrivelsen av et harmløst verktøy får agenten til å handle etter den.

Modellresultater i MCPTox må leses med benchmarkens oppsett og angrepsmål. Rapportert mottakelighet varierer med modell og verktøymiljø. Det etablerer ikke en universell regel om at bedre instruksjonsfølging alltid gir dårligere beskyttelse i enhver installasjon.

Hva har angrepene til felles, og hva kan deteksjon overse?#

Konklusjonen gjelder alle de fire funnene: Du kan ikke stole på at «koden ser normal ut» – hvert enkelt trinn i et angrep er faktisk harmløst. Begrens agentens faktiske evner og undersøk foreslåtte handlinger. Deteksjon og avgrensing håndterer ulike deler av angrepet.

Hvilke beskyttelser har Claude Code allerede – og hvorfor er de ikke nok?#

Anthropic erkjenner problemet direkte i dokumentasjonen sin, i stedet for å skjule det:

Ifølge dokumentasjonen analyserer agenten hele prompten for mistenkelige instruksjoner, godkjenner ikke automatisk curl og wget, holder nettinnhold i et separat kontekstvindu slik at det ikke blandes med hovedvinduet, og krever bekreftelse på tillit første gang du starter den i en ny kodebase eller kobler til en ny MCP-server.

Men Anthropic oppgir én tydelig begrensning:

Hvis du noen gang har startet Claude Code med --dangerously-skip-permissions av irritasjon, slik at den skulle «slutte å mase med spørsmål», slo du av alle mekanismene som kunne ha stoppet nettopp de fire angrepene som er omtalt ovenfor. Jeg lar bevisst dette flagget være av, selv når Claude Code spør for tiende gang i løpet av en økt – det er irriterende, men spørsmålene utgjør grensen mellom «agenten leste mistenkelig tekst» og «agenten utførte den». Et fornuftig oppsett for en som ikke programmerer, er standard tillatelsesmodus (default eller acceptEdits) pluss aktivert sandbox: Vanlige filendringer skjer uten ekstra spørsmål, mens terminalkommandoer fysisk ikke kan komme seg ut av sandboxen, selv om agenten er blitt lurt.

Hvordan aktiverer du sandbox-modus og lukker sikkerhetshullet som er åpent som standard?#

For å aktivere den permanent for alle prosjekter gjør du én endring i ~/.claude/settings.json:

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

Som standard kan kommandoer i sandboxen bare skrive til prosjektets arbeidskatalog og øktens midlertidige katalog. Nettverkstilgang går gjennom en proxy – ingen domener er forhåndsgodkjent, og Claude Code ber om bekreftelse første gang den kontakter et nytt domene. Anthropic sier at dette reduserer antallet tillatelsesspørsmål kraftig – med 84% i selskapets interne målinger – fordi sandboxen håndterer noen trygge tilfeller selv i stedet for å spørre deg hver gang.

Sikkerhetshullet som standardinnstillingene lar stå åpent: Sandboxen begrenser skriving som standard, men hindrer ikke lesing av filer som ~/.aws/credentials og ~/.ssh. Det er nettopp disse filene og miljøvariablene som ble rettet mot i angrepene ovenfor. Lukk sikkerhetshullet med en egen blokk i 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" }
      ]
    }
  }
}

Poenget er at selv om det omvendte skallet fra den første analysen åpnes inne i sandboxen, fjernes disse variablene og filene fysisk fra prosessmiljøet før den starter – det er ingenting igjen å stjele.

Hvilke permissions.deny-regler bør du legge til i dag?#

Et minimalt sett for en som ikke programmerer, og som dekker de viktigste målene for alle de fire angrepene samtidig:

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

Ifølge Claude Code-dokumentasjonen har deny-regler alltid prioritet over allow-regler. Så selv om du (eller agenten selv) ved et uhell tillater bredere tilgang et annet sted, gjelder en spesifikk deny-regel fortsatt først. Denne regelprioriteten gjelder matchende verktøyforespørsler. Den beviser ikke at en hemmelighet er utilgjengelig gjennom alle underprosesser eller verktøy. Bruk håndhevede filsystem- og miljøbegrensninger også.

Claude Code har også en auto-modus, der en separat klassifiseringsmodell kontrollerer handlinger før de kjøres – det er ikke den samme modellen som snakker med deg. Som standard blokkerer den blant annet akkurat mønsteret «last ned kode og kjør den med en gang» (curl | bash). Anthropic advarer uttrykkelig om at dette er en forskningsmodus som reduserer antallet spørsmål, men ikke garanterer sikkerhet på egen hånd – betrakt 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 agenten din?#

For repositories er dette en kort sjekkliste du kan bruke før du gir dem til agenten:

1. Ikke gå rett til installasjon fra en lenke i en e-post, et innlegg eller en anmeldelse fra en ukjent kilde.
2. Hvis installasjonen gir en feil med en instruksjon om å «kjøre kommando X for å fikse det», bør du lese hva X faktisk gjør før du lar Claude Code kjøre den. Instruksjonen i analysen ovenfor så helt rutinemessig ut – det var poenget.
3. Sjekk hvor gammelt repositoryet er og commit-historikken, ikke bare antallet stjerner – nye repositories kan lett få falske stjerner nettopp for denne typen angrep.
4. Hvis repositoryet er ukjent, bør du kjøre installasjonen i en virtuell maskin, ikke på arbeidsmaskinen din med ekte nøkler. Dette er Anthropics egen direkte anbefaling for arbeid med eksterne tjenester.

Anthropics standpunkt til MCP-servere er åpent formulert:

Det betyr at du, og ikke plattformen der du installerte dem, er ansvarlig for å kontrollere MCP-servere fra tredjeparter. Noen team – stort sett sikkerhetsoppstartsbedrifter – lager allerede verktøy for dette: MCP-konfigurasjonsskannere som leter etter forgiftede beskrivelser, og «pinning» av verktøy, som lagrer hashverdien til beskrivelsen ved første installasjon og varsler om senere endringer. Denne teknologien er ny, så det er for tidlig å stole på den som eneste beskyttelse – men den er verdt å følge med på, særlig hvis du kobler MCP-servere til produksjonsmiljøer. For slike tilkoblinger kan du låse hver pakkeversjon og registrere fingeravtrykket til verktøybeskrivelsene i en revisjonslogg.

7 regler for beskyttelse: dagens sjekkliste#

1. Aktiver sandbox-modus (/sandbox eller "sandbox": {"enabled": true} i ~/.claude/settings.json) og legg til en credentials-blokk som hindrer lesing av ~/.ssh og ~/.aws/credentials.
2. Legg til permissions.deny-regler for lesing av hemmelige filer og for farlige bash-kommandoer (curl, wget, sudo) – deny overstyrer alltid allow.
3. Kjør aldri --dangerously-skip-permissions på fremmed eller ubekreftet kode – det deaktiverer alle beskyttelsene samtidig, også dem som kunne ha stoppet nettopp disse angrepene.
4. Ikke la Claude Code automatisk kjøre en «rettingskommando» fra en feilmelding – les først hva den faktisk gjør.
5. Installer MCP-servere bare fra kilder du stoler på, og husk at Anthropic ikke kontrollerer dem for sikkerhet på dine vegne.
6. Skill øktene etter tillatelser: Én jobber med personopplysningene dine og ser ikke eksterne data; en annen undersøker andres e-poster, repositories og saker, men har ikke tilgang til hemmeligheter; en tredje publiserer eksternt – og bare det du selv har godkjent. Jeg er nøye med dette i mine egne prosjekter: En økt med tilgang til betalingsnøkler leser aldri vilkårlige eksterne saker eller repositories, og en økt som analyserer andres kode, ser ingen hemmeligheter i det hele tatt. Ikke bland disse rollene i én chat.
7. Hold Claude Code og tilkoblede automatiseringsskript oppdatert, og kontroller konkrete tiltak for valgt versjon. Historiske leverandørsvar og endret alvorlighetsgrad beviser ikke at hele injeksjonsklassen er lukket.

Hva nå?#

Ingen av disse lagene er en garanti – Anthropic sier selv ærlig at ingen beskyttelse gir fullstendig immunitet. Jeg forventer ikke at Claude Code på egen hånd skal gjenkjenne et triks i en feilmelding eller issue-kommentar. For meg er sandboxen og permissions.deny en del av måten jeg styrer prosjektkonteksten på: hva agenten ser, hva den stoler på som standard, og hva som skjer når den gjør en feil.

Hvis du trenger tilgang til nevrale nettverk via Ailoot, kan du ta en titt på Ailoot.