Sikkerhedsproblemet du ikke har opdaget i dine developer tools

Lad os være ærlige: De fleste engineering teams har absolut ingen idé om, hvor mange AI-kodningsagenter der kører i deres organisation lige nu. Cursor, Claude Code, GitHub Copilot, Gemini CLI, custom interne værktøjer – listen vokser måned for måned. Hver eneste en har sine egne indstillinger, sin egen permission-model, og sin egen fortolkning af, hvad "sikkert" betyder.

Dette er ikke et hypotetisk scenarie. Det er den virkelige tilstand af enterprise AI-adoption i 2025.

Anthropic har for nylig offentliggjort deres tilgang til at sikre Claude, og det er værd at studere – ikke fordi det er magisk, men fordi det afslører den grundlæggende spænding mellem AI-kapabilitet og organisatorisk kontrol. De kan sikre deres agenter, fordi de ejer hele stacken: modellen, runtime-softwaren, netværksstien, governance-rammerne. Din organisation har ikke den luksus. I har et kludetæppe af tredjepartsværktøjer, developer-autonomi og sikkerhedspolitikker, der blev skrevet i en tid før AI-agenter kunne læse filer, køre shell-kommandoer og nå ud på netværket.

Hvad Anthropic gør rigigt

Den sandbox-runtime, de har frigivet, er elegant i sin enkelthed. Den opererer med et princip om deny-by-default egress: hvis en agent kører inde i sandkassen prøver at nå et ikke-autoriseret endpoint, dør requesten på proxy-laget. Ingen exfiltration, ingen callback, ingen skade.

Dette er den type deterministisk sikkerhed, der faktisk virker. I stedet for at stole på, at modellen "forstår", at den ikke bør stjæle credentials, bygger du en hård grænse, der gør credential-tyveri fysisk umuligt – uanset hvad agenten beslutter sig for at gøre.

Anthropic organiserer deres forsvarslinjer i tre lag, rangeret efter pålidelighed:

1. Environment-laget — Hårde grænser som VM-sandkasser, filesystem mount-modes og network allowlists. Dette er fundamentet.

2. Model-laget — Adfærdskontroller som system prompts, klassifikatorer og godkendelsesflows. Nyttigt, men eksplicit erkendt som "aldrig 100% effektivt."

3. Eksternt indholds-lag — Styring af hvilke data der overhovedet når agenten, inklusiv MCP-server audit og inspection af tool-output.

Nøgleindsigten her er rangeringen. Environment-laget løfter det tunge. Model-laget er en nyttig supplement. Det eksterne indholds-lag er dit tidlige varslingssystem.

Angrebet ingen taler om

Abstrakte trusselsmodeller er nemme at afvise. Konkrete eksempler er sværere at ignorere.

Overvej dette scenarie, som sikkerhedsforskere reproducerer regelmæssigt: En developer kloner et repository for at evaluere et open-source bibliotek. README'en ser fin ud. Den er blevet scannet for malware og bestod alle checks.

Men begravet i den README ligger instruktioner til AI-agenten. Ikke til mennesket, der læser filen – til agenten, der indtager den som kontekst. Den injicerede prompt beder agenten om at "sætte development-miljøet op" ved at finde .env-filer, søge efter AWS credentials og uploade dem til et setup-endpoint.

Dette er ikke malware. Det er bare tekst. Scanneren markerer det ikke. Developeren lægger ikke mærke til det. Men agenten følger instruktionerne, for det er det agenter gør – de eksekverer opgaver indlejret i den kontekst, de modtager.

Angrebbet udfolder sig i trin: først en probe for environment-filer, derefter en søgning efter upload- og exfiltration-kodestier, og til sidst den endelige curl-request til angriberens endpoint. Hver handling ser uskyldig ud isoleret set. Tilsammen udgør de credential-tyveri.

Hvorfor din laptop ikke er nok

Her er den ubehagelige sandhed: hvis den agent kører i en korrekt konfigureret sandbox, fejler angrebet på netværkslaget. curl-requesten når aldrig angriberen. Credentialen forlader aldrig maskinen.

Men her er det, der er endnu værre: dit sikkerhedsteam har ingen idé om, at det skete.

Sandkassen indeholder skaden. Den indeholder ikke synligheden. I kører muligvis snesevis af kompromitterede repositories lige nu, hvor hver eneste en prober jeres agenter, hvor hvert forsøg blokeres lydløst, mens jeres SIEM ikke logger noget brugbart.

Dette er enterprise-problemet. Det er ikke nok at stoppe individuelle angreb. I skal vide, at de sker, hvem der var målet, hvilke repositories der skal blokeres, og hvordan I skriver en politik, der dækker hver eneste agent i jeres organisation – ikke bare den, der kører i sandkassen.

MCP-server blindvinklen

Her er den del, der overrasker de fleste teams: Model Context Protocol-servere er den mest undervurderede angrebsflade i AI-agent installations.

MCP-servere udvider, hvad jeres agenter kan gøre. De kan læse fra databaser, kalde APIs, eksekvere kode og tilgå systemer, der lever uden for jeres infrastruktur. Når I godkender en MCP-server, giver I i bund og grund en agent udvidede permissions på tværs af jeres miljø.

Problemet? De fleste teams godkender MCP-servere én gang og auditer dem aldrig igen. En kompromitteret eller ondsindet MCP-server kan gøre langt mere skade end en forgiftet README, fordi den opererer på et højere privilegieniveau og ofte persisterer på tværs af sessioner.

Jeres governance-ramme skal behandle MCP-servere som tredjeparts-afhængigheder: auditeret, versionskontrolleret og overvåget. En agent, der kan nå jeres produktionsdatabase gennem en MCP-server, er en agent, der kan exfiltrere hele jeres customer-tabel, hvis noget går galt.

Hvad I faktisk kan gøre

Ingenting af dette er uløseligt, men det kræver, at I behandler AI-agent-sikkerhed som et infrastrukturproblem frem for et developer tooling-problem.

Start med environment-laget. Hvor det er muligt, kør agenter i isolerede miljøer med deny-by-default netværkspolitikker. Jeres developere kommer måske til at brokke sig over friktionen. De kommer til at brokke sig mindre end I vil, når credentials bliver lækket.

Accepter at model-laget er ufuldkomment. System prompts og klassifikatorer reducerer risiko, men de vil ikke eliminere den. Mere kapable modeller er bedre til at finde uventede veje uden om restriktioner. Planlæg for det.

Auditer jeres MCP-servere. Lav en liste over hver eneste MCP-server jeres agenter kan tilgå. Behandl det som en software-inventarliste. Fjern alt, I ikke genkender eller ikke kan auditere.

Invester i observability. At blokere angreb er godt. At vide, at de skete, er bedre. Jeres sikkerhedsteam skal have synlighed på tværs af hver eneste agent i jeres organisation, ikke bare den der kører i sandkassen.

Skriv politikker, ikke præferencer. "Vær forsigtig med credentials" er ikke en sikkerhedspolitik. "Agenter må ikke initiere netværksforbindelser til ikke-allowlistede domæner, mens de tilgår repositories markeret som eksterne" er en sikkerhedspolitik. Gør reglerne eksplicitte, håndhævelige og konsistente.

Konklusionen

Anthropics åbenhed om deres agent-containment er genuint værdifuld. Det viser, hvad der er muligt, når én organisation kontrollerer hele stacken. Men de fleste organisationer har ikke den kontrol, og at lade som om de har, er sådan brud sker.

Agenterne kører allerede i jeres organisation. Spørgsmålet er ikke, om I skal sikre dem – det er, om I bliver det team, der finder governance på plads, før noget går galt.

Jeres developere bevæger sig hurtigt. Sørg for, at jeres infrastruktur holder trit.