AGENTS.md säkerhet: Hur främmande filer styr AI-agenter

I ett fall räckte det med en oansenlig textfil i Downloads-mappen för att en AI-kodagent skulle försöka installera ett skadligt paket. Den här artikeln handlar om AGENTS.md säkerhet: vad som hände, vilka instruktionsfiler Codex, Claude Code och Cursor läser in och vilka inställningar och åtgärder som kan förhindra skadan.

Ett fynd på en kunds dator och dess följder

Säkerhetsföretaget Forever Security har upptäckt följande: På en kunds dator låg i Downloads-mappen en instruktionsfil med namnet AGENTS.md, som skulle få en AI-kodagent att installera ett npm-paket. Filen är inget program, men den fungerar som en handlingsinstruktion.

Vad som hände: fyndet i Downloads-mappen, omtest och andel lyckade försök

Utgångspunkten var ett verkligt fynd. Filen låg i en utvecklares Downloads-mapp. Den mappen var samtidigt agentens arbetskatalog. Agenten ville installera npm-paketet function-color. Enligt egen uppgift stoppade Forever Security agenten innan någon kod kördes. Hur filen hamnade i mappen kunde forskarna inte klarlägga.

Paketet function-color drar in ytterligare ett paket som heter function-flag. Det laddar ner skadlig programvara för Windows och startar den. CloudSEK och Checkmarx kallar kampanjen MALFEX.

Omtest med Codex

Forever Security återskapade attacken i en isolerad virtuell maskin. Den verkliga filen instruerade Codex att registrera en server i filen ~/.codex/config.toml och att köra ett kommando som installerar paketet. Eftersom den konfigurationen gäller för alla Codex-sessioner på datorn blir ändringen permanent och verkar i varje mapp. Andelen lyckade försök låg på cirka 90 procent.

Omtest med Claude Code

I Claude Code var det en annan fil. En preparerad CLAUDE.md utgav sig för att vara konfigurationen av en intern gateway och skulle få agenten att skriva in en främmande adress som API-mål i en inställningsfil för projektet. Då skulle API-trafiken gå till en server som forskarna kontrollerade. Det röjer sessionens inloggningstoken, och servern kan skicka tillbaka kommandon som agenten kör. Claude Code kräver vanligtvis en bekräftelse för sådana skrivåtgärder och avvisar ofta misstänkta. Först en lång motivering som nästan lät som utvecklardokumentation ledde till ett godkännande i ungefär hälften av fallen.

De två siffrorna är inte direkt jämförbara. Det rör sig om olika agenter, olika filer och olika mål. Urvalets storlek och testkonfigurationen (sandlåda, godkännandeläge) är oklara.

Telemetri: Hur vanligt är det att starta i Downloads-mappen?

Ungefär hälften av Forever Securitys kunder startar en kodagent i Downloads-mappen, och omkring en fjärdedel av sessionerna öppnar en webbläsare. BleepingComputer nämner mer än 1 300 Claude Code-sessioner från den mappen. Båda är leverantörens uppgifter om den egna kundkretsen, någon oberoende granskning finns inte. Att angripare i praktiken faktiskt placerar sådana filer via nedladdningar i webbläsaren är inte belagt. Proof of concept laddade bara ner en harmlös fil.

AGENTS.md säkerhet: Varför främmande instruktionsfiler är en risk

Kodagenter läser instruktionsfiler från arbetskatalogen när de startar. Där står bygginstruktioner, stilregler eller testkommandon. Agenten behandlar innehållet som instruktioner från användaren. Den skiljer inte på ett tillförlitligt sätt mellan filer från teamet och filer från en främmande källa. Det är kärnan i en indirekt prompt injection mot en kodagent: instruktionen kommer inte från inmatningsfältet utan från kontexten.

Två egenskaper som var för sig är harmlösa bildar tillsammans kedjan. För det första litar agenter på filerna i den öppnade mappen. För det andra kan webbplatser lägga filer i Downloads-mappen utan att fråga, om webbläsaren är inställd så. Chrome, Edge och Firefox sparar som standard i den mappen utan att fråga efter plats och visar bara en avisering. Brave frågade först i testet. Filen får det namn och innehåll som webbplatsen bestämmer.

Dokumentationen för Claude Code beskriver CLAUDE.md som kontext och inte som upprätthållen konfiguration. För spärrar rekommenderar den hooks. Av det följer grundregeln för allt som kommer: Det som bara står i texten i en fil kan en agent följa eller ignorera. Det som står i behörigheterna upprätthåller programmet.

Webbläsaren är inte den enda vägen

Downloads-mappen står i centrum i det här fallet, men inte ensam. NVIDIA Developer Blog beskriver en närliggande väg: Ett komprometterat beroendepaket skapar själv en AGENTS.md. Även klonade repositories, uppackade arkiv och byggskript kan föra in främmande instruktionsfiler i en projektmapp. Startplatsen minskar alltså attackytan, men tar inte bort den.

Bedömning: Vad forskare och tillverkare säger

Forskarna på Forever Security förklarar att det inte finns något för OpenAI och Anthropic att patcha. Agenten följer sin instruktionsfil som avsett, jämförbart med en webbläsare som visar en nätfiskesida. Det är forskarnas bedömning. Något eget uttalande från tillverkarna om attacken finns inte i de två rapporterna. BleepingComputer påpekar bara att båda tillverkarna rekommenderar att agenter startas i respektive projektkatalog. Ansvaret ligger därmed hos användarna och hos de organisationer som använder agenter.

Riskerna med autonoma agenter är ett större ämne. Artiklar om makt utan kontroll hos AI-agenter och om AI-agenternas tidsålder förklarar varför agenter med egna handlingsrättigheter behöver andra skyddsåtgärder än traditionell programvara.

Vilka instruktionsfiler Codex, Claude Code och Cursor läser in

Avgörande är vad som räknas som projektmapp: den mapp där agenten startas. Den som startar i Downloads-mappen gör varje fil där till projektkontext. Följande översikt sammanfattar tillverkarnas dokumentation (per den 26 oktober 2026). Dokumentationen ändras snabbt, vid tveksamhet gäller den aktuella versionen.

Codex

Enligt sin dokumentation läser Codex först en global fil i Codex-katalogen (~/.codex, kan ändras via CODEX_HOME), nämligen AGENTS.override.md eller AGENTS.md. Därefter följer filer från projektroten, oftast Git-rotkatalogen, ner till den aktuella mappen. Per mapp beaktas högst en fil: AGENTS.override.md, AGENTS.md eller ett konfigurerat reservnamn. Den totala gränsen ligger på 32 KiB. Hittas ingen projektrot räknas bara den aktuella mappen. Just det gäller Downloads-mappen, eftersom det oftast inte finns något Git-repository där.

Claude Code och CLAUDE.md säkerhet

Enligt minnesdokumentationen läser Claude Code in CLAUDE.md och CLAUDE.local.md från arbetskatalogen och från alla kataloger ovanför, vid behov även från undermappar. Till det kommer ~/.claude/CLAUDE.md, systemets hanterade policy och filer i .claude/rules/. För CLAUDE.md säkerhet betyder det: Även en för högt satt startpunkt, till exempel hemkatalogen, ökar attackytan, eftersom filer ovanför och bredvid också läses in.

AGENTS.md läser Claude Code enligt dokumentationen sedan version 2.1.277. Som standard sker det bara om det inte finns någon CLAUDE.md eller CLAUDE.local.md i arbetskatalogen eller ovanför. Det kan ändras via inställningen för projektinstruktioner: claude-md-or-agents-md är standard, claude-md-and-agents-md läser båda, managed-only tillåter bara centralt hanterade instruktioner.

Cursor

Enligt sin dokumentation stöder Cursor projektregler i .cursor/rules/ (filer i formatet .mdc, även i undermappar) och AGENTS.md i projektroten och i underkataloger. Nästlade filer gäller för sitt område, den mer specifika vinner. Därtill kommer personliga User Rules i inställningarna och Team Rules via dashboarden.

Konfigurationsfiler som det egentliga målet

Fallet visar att instruktionsfilen ofta bara är verktyget. Målet är konfigurationsfiler där en ändring får bestående verkan. För Codex är det ~/.codex/config.toml, där en ändring påverkar alla sessioner. För Claude Code är det inställningsfilen .claude/settings.json, där API-målet kan sättas via en miljövariabel. Båda filerna hör därför hemma på listan över filer som en agent inte får ändra utan att fråga.

Säkra AI-kodagenter: behörigheter, hooks och Codex sandbox

Den självklara frågan är om det räcker att undvika Downloads-mappen.

Åtgärderna sätts in på tre ställen: vad agenten får göra utan att fråga, vad en hook blockerar oberoende av modellen och vad sandlådan tekniskt begränsar.

Behörighetsregler i Claude Code

Claude Code har regler på nivåerna allow, ask och deny per verktyg (dokumentation om behörigheter). Som standard frågar agenten vid skalkommandon och filändringar. En deny-regel gäller även när agenten vill följa en instruktionsfil. Ett exempel för filen .claude/settings.json:

{
  "permissions": {
    "deny": [
      "Bash(npm install *)",
      "Read(~/.ssh/**)",
      "Read(~/.aws/**)",
      "Edit(.claude/**)",
      "Edit(~/.codex/**)"
    ]
  }
}

Skrivsättet följer exemplen i dokumentationen: Bash-regler jämför kommandotexten med * som jokertecken, sökvägsregler för läsning och redigering använder gitignore-syntax, ~/ står för hemkatalogen. Filändringar styrs via Edit(…), regler för Write kontrolleras enligt dokumentationen inte mot sökvägar. En kommandospärr är dessutom ingen garanti, eftersom samma mål ofta kan nås via ett annat anrop. För det som inte går att undvika finns hooks och sandlåda.

Två bekvämlighetsfunktioner kräver försiktighet. Godkännandet med ”fråga inte igen” gäller beroende på verktyg permanent för ett repository, och i autolägena är det inte längre en människa som beslutar om varje åtgärd. Inget av det hör hemma i miljöer med främmande kod.

Hooks: spärrar oberoende av modellen

En PreToolUse-hook körs före verktygsanropet och kan blockera det, även om modellen anser att det är rätt. Hooks-guiden visar mönstret: Skriptet läser indata som JSON från standard input och avslutas med en exit-kod för att blockera. Det registreras i inställningsfilen:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/block-installs.sh"
          }
        ]
      }
    ]
  }
}

Skriptet block-installs.sh läser med jq kommandot från fältet tool_input.command, kontrollerar det mot en spärrlista (till exempel npm install eller kombinationen av curl och ett skal) eller hellre mot en allowlist och rapporterar vid träff en motivering på standard error med exit 2. En andra, föga känd hävstång är hooken InstructionsLoaded. Den loggar inlästa instruktionsfiler. Enligt dokumentationen utlöses den dock inte för en AGENTS.md som läses in via inställningen, utan bara när en CLAUDE.md importerar den. Ett team bör därför inte förlita sig enbart på den.

Centrala regler med Managed Settings

För team är hanterade inställningar den mest verkningsfulla hävstången. Enligt dokumentationen om Managed Settings kan permissions.deny, sandbox.enabled och env tvingas fram centralt. Då skulle ett API-mål som smugglats in via en instruktionsfil, som i testet med Claude Code, bli betydligt svårare att genomdriva. Som bedömning gäller: Det är en slutsats utifrån dokumentationen, ingen belagd effekt i fallet Forever Security.

Codex: godkännanden, förtroendenivå och sandlådelägen

För Codex sandbox och behörigheter gäller enligt dokumentationen om godkännanden och säkerhet två nivåer. Godkännandepolicyn bestämmer när Codex frågar (till exempel on-request eller never). Sandlådeläget bestämmer vad som är tekniskt möjligt: read-only, workspace-write eller danger-full-access. I läget workspace-write är nätverket avstängt som standard.

Därtill finns en förtroendenivå per projekt i ~/.codex/config.toml (trust_level). Enligt dokumentationen gäller läget Auto i mappar under versionshantering, alltså skrivning i arbetsytan med bekräftelse. I mappar utan versionshantering gäller read-only tills katalogen markeras som betrodd. En mapp som Downloads räknas utan markering som inte betrodd. Risken uppstår när användare bekräftar förtroendedialogen. Flaggan –yolo tar bort sandlåda och godkännanden och hör inte hemma i teamets regler. Vilken konfiguration Forever Security testade med redovisades inte, därför är det okänt om standardskydden slog till i testet.

Cursor

Om terminalgodkännanden i Cursor finns ingen entydig uppgift från tillverkaren. Därför här bara rådet att låta godkännanden för terminalkommandon vara aktiva och att kontrollera tillverkarens aktuella dokumentation.

Sandlåda och isolering: begränsa skadan även om agenten följer filen

En sandlåda begränsar vad en agent kan göra, även om den följer en främmande instruktion. Sandlådan i Claude Code tillåter skrivåtkomst till arbetskatalogen och temporära mappar. Nätverksåtkomst går via en proxy med en lista över tillåtna domäner, som är tom som standard. Skyddade sökvägar som inställningarna för Claude Code, skalets startfil .bashrc och Git-hooks förblir skrivskyddade. Ett exempel:

{
  "sandbox": {
    "enabled": true,
    "network": {
      "allowedDomains": ["github.com", "*.npmjs.org"]
    },
    "allowUnsandboxedCommands": false
  }
}

Dokumentationen nämner också begränsningar. Sandlådan är avstängd som standard. Läsåtkomsten är bred, inloggningsuppgifter måste spärras uttryckligen. Skyddet gäller bara skalkommandon och deras barnprocesser, inte de inbyggda filverktygen, MCP och hooks. Utan allowUnsandboxedCommands: false kan ett misslyckat kommando köras om utanför sandlådan. Under Windows körs den inte nativt, där används WSL2. Mot skadlig kod är den ingen fullständig gräns. För stark isolering är containrar eller virtuella maskiner det bättre valet.

Allowlist för nätverket och engångsmiljö

En sådan allowlist hade försvårat både paketnedladdningen och omdirigeringen av API-trafiken. Det är en bedömning, inget belägg för fallet. Okänd kod hör hemma i en engångsmiljö: container, VM eller dev container, utan huvudprofilens inloggningsuppgifter. Token bör vara kortlivade. Vid misstanke rekommenderas att betrakta inloggningstoken som läckt och förnya den.

Webbläsarinställning för nedladdningar

Mot tysta nedladdningar hjälper inställningen att fråga efter plats före varje sparande. I Chrome heter den ungefär ”Fråga var varje fil ska sparas innan den laddas ned” och finns i inställningarna under Nedladdningar. Edge och Firefox erbjuder motsvarande, beteckningarna skiljer sig beroende på version (Firefox: Inställningar, Allmänt, Filer och program). Brave frågade i BleepingComputers test självmant. Alternativt kan nedladdningsmappen läggas på en plats som aldrig används som arbetskatalog. Ett skalalias eller en hook som vägrar att starta i ~/Downloads är ett ytterligare alternativ.

Checklista för team och riktlinje för användning av kodagenter

Följande lista sammanfattar åtgärderna. Den kompletterar rekommendationerna från de två rapporterna med konfigurationerna från tillverkarnas dokumentation.

• Agenter startas bara i rotkatalogen för ett betrott repository. Downloads, skrivbordet och hemkatalogen är tabu.
• Främmande filer som AGENTS.md, CLAUDE.md eller .cursor/rules läses innan ett nyklonat eller nyuppackat projekt öppnas.
• Behörighetsfrågor och sandlåda förblir aktiva. Autolägen och flaggor som –yolo körs bara i isolerade miljöer.
• Nätverksåtkomst går via en allowlist, inloggningsuppgifter ligger utom räckhåll, token är kortlivade.
• Paketinstallationer av agenter sker bara efter godkännande, med lockfil och kontroll av registret. Hur snabbt ett paket drar in fler paket visar fallet med function-color och function-flag.
• Inställningar hanteras centralt. Ändringar i ~/.codex/config.toml och .claude/settings.json övervakas.
• Inlästa instruktionsfiler loggas, i den mån verktygen tillåter det.
• Incidentplan: stoppa sessionen, förnya token och nycklar, kontrollera konfigurationsfiler, spåra paketinstallationer.

Organisationer med skyldigheter inom informationssäkerhet tar med sådana agenter i sin riskhantering. Det gäller tillståndet att använda dem, konfigurationen och beviset för att reglerna gäller. En artikel om agentic coding beskriver hur användningen kan organiseras i utvecklingsteam.

Mall för en riktlinje

En kortfattad riktlinje kan formuleras på några få meningar. Tillämpningsområdet omfattar alla anställda och tjänsteleverantörer som använder AI-kodagenter på företagets enheter eller med företagets data. Agenter startas bara i rotkatalogen för ett granskat repository, aldrig i mappar för nedladdningar, skrivbord eller hem. Autolägen och avstängning av sandlåda eller godkännanden är bara tillåtna i isolerade engångsmiljöer utan inloggningsuppgifter. Paketinstallationer och ändringar i konfigurationsfiler kräver godkännande av utvecklarna. Ansvarig för de centrala inställningarna är IT-säkerheten, för efterlevnaden i projektet projektledningen. Misstänkta fall rapporteras omedelbart till IT-säkerheten, berörda token förnyas utan dröjsmål.

Granska egna webbplatser och system

Fallet gäller främst utvecklares datorer. Den som själv erbjuder filer för nedladdning är med sin webbplats en del av kedjan. En webbplatskontroll visar vilka skript och headers en sida levererar, men den granskar bara sidan, inte utvecklarnas datorer. För en systematisk säkerhetsgranskning i team är Web Security Checks en bra början.

Slutsats

Ansvaret ligger hos användaren, tekniken sätter gränsen!

En främmande textfil kan styra en kodagent eftersom agenten behandlar filer i arbetsmappen som instruktioner. Skyddet blir tillförlitligt först genom upprätthållna gränser: behörigheter, hooks, sandlåda, allowlist för nätverket och centralt hanterade inställningar.

Det är fortfarande öppet om angripare använder vägen via webbläsarnedladdningar i praktiken och hur filen hamnade hos kunden. Viktigt är i alla fall att medarbetare och utvecklare blir medvetna om riskerna (tills de dör ut).