AGENTS.md sikkerhed: Sådan styrer fremmede filer AI-agenter

I ét tilfælde var en uanselig tekstfil i mappen Overførsler (Downloads) nok til, at en AI-kodeagent ville installere en ondsindet pakke. Artiklen handler om AGENTS.md sikkerhed: hvad der skete, hvilke instruktionsfiler Codex, Claude Code og Cursor indlæser, og hvilke indstillinger og tiltag der kan forhindre skaden.

Et fund på en kundes computer og følgerne

Sikkerhedsleverandøren Forever Security har fundet følgende: På en kundes computer lå der i Downloads-mappen en instruktionsfil ved navn AGENTS.md, som skulle få en AI-kodeagent til at installere en npm-pakke. Filen er ikke et program, men den virker som en handlingsanvisning.

Hvad der skete: fund i Downloads-mappen, gentest og succesrater

Udgangspunktet var et reelt fund. Filen lå i en udviklers Downloads-mappe. Denne mappe var samtidig agentens arbejdsmappe. Agenten ville installere npm-pakken function-color. Ifølge Forever Security selv stoppede de agenten, før der blev kørt kode. Hvordan filen kom ind i mappen, kunne forskerne ikke afklare.

Pakken function-color trækker en yderligere pakke ved navn function-flag med sig. Den henter et stykke Windows-malware og starter det. CloudSEK og Checkmarx kalder kampagnen MALFEX.

Gentest med Codex

Forever Security genskabte angrebet i en isoleret virtuel maskine. Den ægte fil instruerede Codex i at registrere en server i filen ~/.codex/config.toml og at køre en kommando, der installerer pakken. Da denne konfiguration gælder for alle Codex-sessioner på computeren, virker ændringen permanent og i alle mapper. Succesraten lå på ca. 90 procent.

Gentest med Claude Code

Hos Claude Code var det en anden fil. En manipuleret CLAUDE.md udgav sig for at være opsætningen af en intern gateway og skulle få agenten til at skrive en fremmed adresse som API-mål i en projektindstillingsfil. Dermed ville API-trafikken gå til en server hos forskerne. Det afslører sessionens login-token, og serveren kan sende kommandoer tilbage, som agenten udfører. Claude Code kræver normalt en bekræftelse ved den slags skriveadgang og afviser ofte mistænkelige forsøg. Først den lange begrundelse, der næsten lød som udviklerdokumentation, gav godkendelse i omkring halvdelen af tilfældene.

De to tal kan ikke sammenlignes direkte. Det drejer sig om forskellige agenter, forskellige filer og forskellige mål. Stikprøvestørrelse og testkonfiguration (sandbox, godkendelsestilstand) er uklare.

Telemetri: Hvor udbredt er det at starte i Downloads-mappen?

Omkring halvdelen af Forever Securitys kunder starter en kodeagent i Downloads-mappen, og cirka en fjerdedel af sessionerne åbner en browser. BleepingComputer nævner mere end 1.300 Claude Code-sessioner fra denne mappe. Begge dele er leverandørens oplysninger om egne kunder, og der findes ingen uafhængig kontrol. Om angribere i praksis faktisk lægger sådanne filer via browserdownloads, er ikke dokumenteret. Proof of concept-angrebet downloadede kun en harmløs fil.

AGENTS.md sikkerhed: Hvorfor fremmede instruktionsfiler er en risiko

Kodeagenter læser instruktionsfiler fra arbejdsmappen, når de starter. De indeholder byggevejledninger, stilregler eller testkommandoer. Agenten behandler dette indhold som instruktioner fra brugeren. Den skelner ikke pålideligt mellem, om filen stammer fra teamet eller fra en fremmed kilde. Det er kernen i en indirekte prompt injection mod en kodeagent: Instruktionen kommer ikke fra indtastningsfeltet, men fra konteksten.

To egenskaber, der hver for sig er harmløse, danner tilsammen kæden. For det første stoler agenter på filerne i den åbnede mappe. For det andet kan websider lægge filer i Downloads-mappen uden at spørge, hvis browseren er indstillet sådan. Chrome, Edge og Firefox gemmer som standard i denne mappe uden at spørge om placering og viser kun en meddelelse. Brave spurgte først i testen. Filen får det navn og indhold, som siden bestemmer.

Dokumentationen til Claude Code beskriver CLAUDE.md som kontekst og ikke som håndhævet konfiguration. Til spærringer anbefaler den hooks. Heraf følger grundreglen for alt det følgende: Det, der kun står i teksten i en fil, kan en agent følge eller ignorere. Det, der står i rettighederne, håndhæver programmet.

Browseren er ikke den eneste vej

Downloads-mappen står i centrum i denne sag, men ikke alene. NVIDIA Developer Blog beskriver en beslægtet vej: En kompromitteret afhængighedspakke opretter selv en AGENTS.md. Også klonede repositories, udpakkede arkiver og build-scripts kan bringe fremmede instruktionsfiler ind i en projektmappe. Startstedet gør altså angrebsfladen mindre, men fjerner den ikke.

Vurdering: Hvad forskere og leverandører siger

Forskerne fra Forever Security forklarer, at der ikke er noget at patche for OpenAI og Anthropic. Agenten følger sin instruktionsfil som tilsigtet, på samme måde som en browser, der viser en phishingside. Det er forskernes vurdering. De to rapporter indeholder ingen egen udtalelse fra leverandørerne om dette angreb. BleepingComputer nævner kun, at begge leverandører anbefaler at starte agenter i den pågældende projektmappe. Ansvaret ligger dermed hos brugerne og hos de organisationer, der tager agenter i brug.

Risiciene ved autonome agenter er et større emne. Artikler om magt uden kontrol hos AI-agenter og om AI-agenternes tidsalder forklarer, hvorfor agenter med egne handlerettigheder har brug for andre beskyttelsesforanstaltninger end klassisk software.

Hvilke instruktionsfiler Codex, Claude Code og Cursor indlæser

Det afgørende er, hvad der gælder som projektmappe: den mappe, som agenten startes i. Den, der starter i Downloads-mappen, gør hver fil derinde til projektkontekst. Følgende oversigt sammenfatter leverandørernes dokumentation (status 26.10.2026). Dokumentationen ændrer sig hurtigt, og i tvivlstilfælde gælder den aktuelle version.

Codex

Ifølge dokumentationen læser Codex først en global fil i Codex-mappen (~/.codex, kan ændres via CODEX_HOME), nemlig AGENTS.override.md eller AGENTS.md. Derefter følger filer fra projektroden, som regel Git-rodmappen, ned til den aktuelle mappe. Pr. mappe tages højst én fil i betragtning: AGENTS.override.md, AGENTS.md eller et konfigureret erstatningsnavn. Den samlede grænse er 32 KiB. Findes der ingen projektrod, tæller kun den aktuelle mappe. Netop det rammer Downloads-mappen, for dér findes der som regel intet Git-repository.

Claude Code og CLAUDE.md sikkerhed

Ifølge hukommelsesdokumentationen indlæser Claude Code CLAUDE.md og CLAUDE.local.md fra arbejdsmappen og fra alle mapper over den og efter behov også fra undermapper. Dertil kommer ~/.claude/CLAUDE.md, systemets administrerede politik og filer i .claude/rules/. For CLAUDE.md sikkerhed betyder det: Også et for højt startpunkt, for eksempel hjemmemappen, gør angrebsfladen større, fordi filer over og ved siden af også bliver læst.

Claude Code læser AGENTS.md (ifølge dokumentationen siden version 2.1.277). Som standard sker det kun, hvis der ikke ligger en CLAUDE.md eller CLAUDE.local.md i arbejdsmappen eller over den. Det kan ændres via indstillingen for projektinstruktioner: claude-md-or-agents-md er standard, claude-md-and-agents-md læser begge, managed-only tillader kun centralt administrerede instruktioner.

Cursor

Ifølge dokumentationen kender Cursor projektregler i .cursor/rules/ (filer i formatet .mdc, også i undermapper) og AGENTS.md i projektroden samt i undermapper. Indlejrede filer gælder for deres område, og den mest specifikke vinder. Dertil kommer personlige User Rules i indstillingerne og Team Rules via dashboardet.

Konfigurationsfiler som det egentlige mål

Sagen viser, at instruktionsfilen ofte kun er værktøjet. Målet er konfigurationsfiler, hvor en ændring virker permanent. Hos Codex er det ~/.codex/config.toml, hvor en ændring påvirker alle sessioner. Hos Claude Code er det indstillingsfilen .claude/settings.json, hvor API-målet kan sættes via en miljøvariabel. Begge filer hører derfor med på listen over filer, som en agent ikke må ændre uden at spørge.

Sådan sikrer du AI-kodeagenter: rettigheder, hooks og Codex sandbox

Det oplagte spørgsmål er, om det er nok at undgå Downloads-mappen.

Tiltagene sætter ind tre steder: hvad agenten må gøre uden at spørge, hvad en hook blokerer uafhængigt af modellen, og hvad sandboxen begrænser teknisk.

Rettighedsregler i Claude Code

Claude Code kender regler på niveauerne allow, ask og deny pr. værktøj (dokumentation om rettigheder). Som standard spørger agenten ved shell-kommandoer og filændringer. En deny-regel gælder også, når agenten gerne vil følge en instruktionsfil. Et eksempel på filen .claude/settings.json:

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

Skrivemåden følger eksemplerne i dokumentationen: Bash-regler sammenligner kommandoteksten med * som pladsholder, stiregler for læsning og redigering bruger gitignore-syntaksen, og ~/ står for hjemmemappen. Filændringer styres via Edit(…), og regler for Write bliver ifølge dokumentationen ikke kontrolleret mod stier. En kommandospærring er desuden ingen garanti, for det samme mål kan ofte nås via et andet kald. Til det uundgåelige er hooks og sandbox tænkt.

To komfortfunktioner kræver forsigtighed. Godkendelse med »spørg ikke igen« gælder afhængigt af værktøjet permanent for et repository, og i auto-tilstandene er det ikke længere mennesket, der beslutter hver handling. Ingen af delene hører hjemme i miljøer med fremmed kode.

Hooks: spærringer uafhængigt af modellen

En PreToolUse-hook kører før værktøjskaldet og kan blokere det, også selvom modellen mener, at det er rigtigt. Hooks-vejledningen viser mønsteret: Scriptet læser input som JSON fra standardinput og afslutter med en exitkode for at blokere. Det registreres i indstillingsfilen:

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

Scriptet block-installs.sh læser med jq kommandoen fra feltet tool_input.command, kontrollerer den mod en spærreliste (for eksempel npm install eller kombinationen af curl og shell) eller bedre mod en allowlist og melder ved et træf en begrundelse på fejludgangen med exit 2. Et andet, lidt kendt greb er hooken InstructionsLoaded. Den logger indlæste instruktionsfiler. Ifølge dokumentationen udløses den dog ikke for en AGENTS.md, der indlæses via indstillingen, men kun når en CLAUDE.md importerer den. Et team bør derfor ikke stole på den alene.

Centrale krav med Managed Settings

For teams er administrerede indstillinger det mest effektive greb. Ifølge dokumentationen om Managed Settings kan permissions.deny, sandbox.enabled og env gennemtvinges centralt. Dermed ville et API-mål, der er smuglet ind via en instruktionsfil som i Claude Code-testen, være langt sværere at få igennem. Som vurdering gælder: Det er en konklusion ud fra dokumentationen, ikke en dokumenteret virkning i Forever Security-sagen.

Codex: godkendelser, tillidsniveau og sandbox-tilstande

For Codex sandbox og rettigheder gælder ifølge dokumentationen om godkendelser og sikkerhed to niveauer. Godkendelsespolitikken bestemmer, hvornår Codex spørger (for eksempel on-request eller never). Sandbox-tilstanden bestemmer, hvad der teknisk er muligt: read-only, workspace-write eller danger-full-access. I tilstanden workspace-write er netværket slået fra som standard.

Dertil kommer et tillidsniveau pr. projekt i ~/.codex/config.toml (trust_level). Ifølge dokumentationen gælder tilstanden Auto i mapper under versionsstyring, altså skrivning i arbejdsområdet med bekræftelse. I mapper uden versionsstyring gælder read-only, indtil mappen markeres som betroet. En mappe som Downloads gælder uden markering som ikke betroet. Risikoen opstår, når brugere bekræfter tillidsdialogen. Flaget –yolo fjerner sandbox og godkendelser og hører ikke hjemme i teamets regler. Hvilken konfiguration Forever Security testede med, blev ikke oplyst, og det er derfor ukendt, om standardbeskyttelsen virkede i testen.

Cursor

Om terminalgodkendelser i Cursor findes der ingen entydig oplysning fra leverandøren. Derfor her kun rådet om at lade godkendelser for terminalkommandoer være slået til og at tjekke leverandørens aktuelle dokumentation.

Sandbox og isolation: begræns skaden, også når agenten følger filen

En sandbox begrænser, hvad en agent kan gøre, selv når den følger en fremmed instruktion. Sandboxen i Claude Code tillader skriveadgang til arbejdsmappen og midlertidige mapper. Netværksadgang går via en proxy med en liste over tilladte domæner, som er tom som standard. Beskyttede stier som Claude Codes indstillinger, shell-startfilen .bashrc og Git-hooks forbliver skrivebeskyttede. Et eksempel:

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

Dokumentationen nævner også begrænsninger. Sandboxen er slået fra som standard. Læseadgangen er bred, og adgangsoplysninger skal spærres målrettet. Beskyttelsen gælder kun shell-kommandoer og deres underprocesser, ikke de indbyggede filværktøjer, MCP og hooks. Uden allowUnsandboxedCommands: false kan en mislykket kommando gentages uden for sandboxen. Under Windows kører den ikke direkte, her bruges WSL2. Over for ondsindet kode er den ikke en fuldstændig grænse. Til stærk isolation er containere eller virtuelle maskiner det bedre valg.

Netværks-allowlist og engangsmiljø

En sådan allowlist ville have gjort pakkedownload og API-omdirigering sværere. Det er en vurdering, ikke et bevis i sagen. Ukendt kode hører hjemme i et engangsmiljø: container, VM eller dev container, uden adgangsoplysningerne fra hovedprofilen. Tokens bør være kortlivede. Ved mistanke anbefales det at betragte login-tokenet som lækket og forny det.

Browserindstilling for downloads

Mod stille downloads hjælper indstillingen om at spørge om placering før hver lagring. I Chrome hedder den nogenlunde »Spørg, hvor hver fil skal gemmes, før den downloades« og findes i indstillingerne under Downloads. Edge og Firefox tilbyder noget tilsvarende, men betegnelserne varierer efter version (Firefox: Indstillinger, Generelt, Filer og programmer). Brave spurgte af sig selv i BleepingComputers test. Alternativt kan download-mappen placeres et sted, der aldrig bruges som arbejdsmappe. Et shell-alias eller en hook, der nægter start i ~/Downloads, er en ekstra mulighed.

Tjekliste for teams og retningslinje for brug af kodeagenter

Følgende liste sammenfatter tiltagene. Listen supplerer anbefalingerne fra de to rapporter med konfigurationerne fra leverandørernes dokumentation.

• Agenter startes kun i rodmappen af et betroet repository. Downloads, Skrivebord og hjemmemappen er forbudt område.
• Fremmede filer som AGENTS.md, CLAUDE.md eller .cursor/rules læses, før et nyklonet eller udpakket projekt åbnes.
• Rettighedsforespørgsler og sandbox forbliver aktive. Auto-tilstande og flag som –yolo kører kun i isolerede miljøer.
• Netværksadgang går via en allowlist, adgangsoplysninger ligger uden for rækkevidde, og tokens er kortlivede.
• Pakkeinstallationer foretaget af agenter sker kun efter godkendelse, med lockfile og kontrol af registret. Hvor hurtigt en pakke trækker flere pakker med sig, viser sagen med function-color og function-flag.
• Indstillinger administreres centralt. Ændringer i ~/.codex/config.toml og .claude/settings.json overvåges.
• Indlæste instruktionsfiler logges, så vidt værktøjerne tillader det.
• Hændelsesplan: stop sessionen, forny tokens og nøgler, kontrollér konfigurationsfiler, spor pakkeinstallationer.

Organisationer med forpligtelser inden for informationssikkerhed tager sådanne agenter med i deres risikostyring. Det gælder tilladelsen, konfigurationen og dokumentationen for, at reglerne overholdes. En artikel om agentic coding beskriver, hvordan brugen kan organiseres i udviklingsteams.

Skabelon til retningslinje

En kort retningslinje kan formuleres i få sætninger. Den gælder for alle medarbejdere og leverandører, der bruger AI-kodeagenter på virksomhedens enheder eller med virksomhedens data. Agenter startes kun i rodmappen af et kontrolleret repository, aldrig i Downloads-, Skrivebords- eller hjemmemapper. Auto-tilstande og deaktivering af sandbox eller godkendelser er kun tilladt i isolerede engangsmiljøer uden adgangsoplysninger. Pakkeinstallationer og ændringer i konfigurationsfiler kræver godkendelse fra udviklerne. IT-sikkerheden er ansvarlig for de centrale indstillinger, projektledelsen for overholdelsen i projektet. Mistanke om hændelser meldes straks til IT-sikkerheden, og berørte tokens fornyes omgående.

Tjek egne websites og systemer

Sagen vedrører først og fremmest udvikleres computere. Den, der selv tilbyder filer til download, er med sit eget website en del af kæden. Et website-tjek viser, hvilke scripts og headere en side leverer, men det kontrollerer kun siden, ikke udvikleres computere. Til en systematisk sikkerhedskontrol i teams er Web Security Checks et godt sted at begynde.

Konklusion

Ansvaret ligger hos brugeren, teknikken sætter grænsen!

En fremmed tekstfil kan styre en kodeagent, fordi agenten behandler filer i arbejdsmappen som instruktioner. Beskyttelsen bliver først pålidelig gennem håndhævede grænser: rettigheder, hooks, sandbox, netværks-allowlist og centralt administrerede indstillinger.

Det står stadig åbent, om angribere bruger vejen via browserdownloads i praksis, og hvordan filen endte hos kunden. Under alle omstændigheder virker det vigtigt at gøre medarbejdere og udviklere opmærksomme på problemet (indtil de uddør).