Säkerhetsproblemet du inte visste att du hade i dina utvecklarverktyg

Låt mig ställa en fråga: Vet du hur många AI-kodande agenter som körs i din organisation just nu? Jag menar inte de officiella verktygen. Jag pratar om varenda Cursor, Claude Code, GitHub Copilot, Gemini CLI och alla interna verktyg som någon utvecklare har installerat på sin laptop.

De flesta svarar nej på den frågan. Och det är problematiskt.

Det här är inte teoretiskt. Det här är verkligheten för företag som adopterar AI verktyg i snabb takt. Varje agent har sina egna inställningar, sin egen behörighetsmodell, och sin egen tolkning av vad "säkert" betyder.

Anthropic publicerade nyligen sitt tillvägagångssätt för att begränsa Claude. Det är värt att studera – inte för att det är magi, utan för att det avslöjar den grundläggande spänningen mellan AI-kapacitet och organisatorisk kontroll. De kan säkra sina agenter eftersom de äger hela stacken: modellen, körmiljön, nätverksvägen, styrningsramverket.

Din organisation har inte den lyxen.

Tre lager som faktiskt fungerar

Anthropics sandbox-körning är elegant i sin enkelhet. Principen är enkel: deny-by-default för nätverksutgångar. Om en agent inuti sandlådan försöker nå en oauktoriserad endpoint, så dör förfrågan vid proxy-lagret. Ingen exfiltrering, inga callbacks, inga skador.

Det här är deterministisk säkerhet som faktiskt fungerar. Istället för att lita på att modellen "förstår" att den inte ska stjäla uppgifter, bygger du en hård gräns som gör uppgiftsstöld fysiskt omöjligt – oavsett vad agenten väljer att göra.

Försvaret är organiserat i tre lager, rangordnade efter tillförlitlighet:

1. Miljölagret – Hårda gränser som VM-sandlådor, filsystemsmount-lägen och nätverks-whitelistor. Det här är grunden.

2. Modellagret – Beteendemässiga kontroller som systemprompts, klassificerare och godkännandeflöden. Användbart, men erkänt som "aldrig 100% effektivt."

3. Externt innehållslager – Styr vilken data som når agenten överhuvudtaget, inklusive MCP-serverrevision och verktygsoutput-inspektion.

Nyckeln är rangordningen. Miljölagret gör grovjobbet. Modellagret är ett komplement. Det externa innehållslagret är ditt tidiga varningssystem.

Attacken ingen pratar om

Abstrakta hotmodeller är lätta att avfärda. Konkreta exempel är svårare att ignorera.

Tänk dig det här scenariot, som säkerhetsforskare reproducerar regelbundet: En utvecklare klonar ett repo för att utvärdera ett open source-bibliotek. README:n ser bra ut. Den har skannats för skadlig kod och klarat varje kontroll.

Men begravd i den README:n finns instruktioner för AI-agenten. Inte för människan som läser filen – för agenten som kan tugga den som kontext. Den injicerade prompten ber agenten att "sätta upp utvecklingsmiljön" genom att hitta .env-filer, söka efter AWS-uppgifter och ladda upp dem till en setup-endpoint.

Det här är inte skadlig kod. Det är bara text. Skannern flaggar inget. Utvecklaren märker inget. Men agenten följer instruktionerna för att det är vad agenter gör – de exekverar uppgifter inbäddade i den kontext de tar emot.

Attacken utvecklas steg för steg: först en sondering efter miljöfiler, sedan en sökning efter upload- och exfiltreringsvägar, sedan det slutliga curl-anropet till angriparens endpoint. Varje enskild handling ser oskyldig ut. Tillsammans utgör de uppgiftsstöld.

Varför din laptop inte räcker

Här är den obekväma sanningen: om den agenten kör i en korrekt konfigurerad sandlåda, så misslyckas attacken på nätverkslagret. Curl-anropet når aldrig angriparen. Uppgifterna lämnar aldrig maskinen.

Men här är det värre: din säkerhetsgrupp har ingen aning om att det hände.

Sandlådan begränsar skadan. Den begränsar inte insynen. Du kanske kör dussintals komprometterade repos just nu, var och en som sonderar dina agenter, varje försök blockerat tyst medan ditt SIEM loggar inget användbart.

Det här är företagsproblemet. Det räcker inte att stoppa enskilda attacker. Du behöver veta att de händer, vem som var målet, vilka repos som ska blockeras, och hur du skriver en policy som täcker varje agent i din organisation – inte bara den som kör i sandlådan.

Den blindfläck de flesta missar

Model Context Protocol-servrar är den mest underskattade attackytan i AI-agentdistributioner. Det här överraskar de flesta team.

MCP-servrar utökar vad dina agenter kan göra. De kan läsa från databaser, anropa API:er, exekvera kod och nå system som lever utanför din infrastruktur. När du godkänner en MCP-server, beviljar du i praktiken en agent utökade behörigheter i din miljö.

Problemet? De flesta team godkänner MCP-servrar en gång och granskar dem aldrig igen. En komprometterad eller elakartad MCP-server kan göra betydligt mer skada än en förgiftad README eftersom den opererar på en högre privilegienivå och ofta fortsätter mellan sessioner.

Ditt styrningsramverk behöver behandla MCP-servrar som tredjepartsberoenden: granskade, versionshanterade och övervakade. En agent som kan nå din produktionsdatabas genom en MCP-server är en agent som kan exfiltrera hela din kundtabell om något går fel.

Vad du faktiskt kan göra

Inget av det här är olösligt, men det kräver att du behandlar AI-agent-säkerhet som ett infrastrukturproblem snarare än ett utvecklarverktygsproblem.

Börja med miljölagret. Kör agenter i isolerade miljöer med deny-by-default nätverkspolicys, överallt där det är möjligt. Dina utvecklare kanske klagar på friktionen. De kommer klaga mindre än du när uppgifter läcker.

Acceptera att modellagret är ofullkomligt. Systemprompts och klassificerare minskar risk, men de eliminerar den inte. Mer kapabla modeller är bättre på att hitta oväntade vägar runt begränsningar. Planera för det.

Granska dina MCP-servrar. Gör en lista över varje MCP-server som dina agenter kan komma åt. Behandla det som en mjukvaruinventering. Ta bort allt du inte känner igen eller inte kan granska.

Investera i observabilitet. Att blockera attacker är bra. Att veta att de hände är bättre. Din säkerhetsgrupp behöver insyn över varje agent i din organisation, inte bara den som kör i sandlådan.

Skriv policies, inte preferenser. "Var försiktig med uppgifter" är inte en säkerhetspolicy. "Agenter får inte initiera nätverksanslutningar till icke-whitelistade domäner vid åtkomst av repos markerade som externa" är en säkerhetspolicy. Gör reglerna explicita, verkställbara och konsekventa.

Sammanfattning

Anthropics transparens kring sin agentbegränsning är genuint värdefull. Den visar vad som är möjligt när en organisation kontrollerar hela stacken. Men de flesta organisationer har inte den kontrollen, och att låtsas annars är hur intrång händer.

Agenterna kör redan i din organisation. Frågan är inte om du ska säkra dem – det är om du blir teamet som löser styrningen innan något går fel.

Dina utvecklare rör sig snabbt. Se till att din infrastruktur hänger med.