Claude Code-säkerhetsguide: Behörigheter, MCP, Sandboxing

Traditionella chatbotar körs bakom ett API, så det värsta de kan göra är att hallucinera. Men en AI-kodningsagent placeras i din kodbas, din terminal och (ofta) dina molnuppgifter, vilket gör den betydligt närmare privilegierade utvecklarmiljöer än något vi tidigare kallade en chatbot.

Frågan är hur du använder Claude Code säkert utan att bli långsammare. Behörigheter, MCP-kontroller och sandboxning med lagom mycket finjustering tar dig dit.

I den här artikeln går jag igenom hur Claude Codes säkerhetsmodell faktiskt fungerar, vad du behöver vara uppmärksam på och vilka arbetssätt som håller den användbar utan att ge den mer åtkomst än du tänkt dig.

Om du är helt ny till Claude och Claude Code kan du anmäla dig till vår kostnadsfria Claude Code 101-kurs för att få grunderna på en eftermiddag.

Förstå Claude Codes säkerhetsmodell

Innan du justerar en enda regel behöver du en mental modell av vad Claude Code faktiskt styr.

Det finns fem rörliga delar: ett behörighetssystem som avgör vad som är tillåtet, verktygsåtkomst som avgränsar enskilda funktioner, MCP-behörigheter för externa integrationer, sandboxning för isolering på OS-nivå och spårbarhet för efterhandsgranskning. Varje del löser ett eget problem, men de staplas på varandra.

Behörighetssystem

Behörighetssystemet är det statiska lagret.

Du deklarerar vad Claude får göra i settings.json med tre listor: allow, ask och deny. Regler utvärderas i ordningen deny, sedan ask, sedan allow, och första match vinner. En deny-regel blockerar anropet även om en bredare allow-regel skulle ha matchat.

Om ingen regel matchar faller Claude tillbaka på sessionens defaultMode (mer om lägen i nästa avsnitt).

Åtkomstkontroller för verktyg

Behörigheter knyts till verktyg, inte till agenten som helhet.

Claude Code har en uppsättning inbyggda verktyg, till exempel Bash för shell-kommandon, Read, Edit och Write för filsystemsåtgärder, WebFetch för HTTPS-anrop, WebSearch för sökningar och några andra. Varje regel namnger ett verktyg och (valfritt) en specifikation inom parentes, som Bash(git commit:*) eller Read(./.env).

Detta är grunden för minsta möjliga åtkomst. Du kan tillåta Bash(npm run:*) för tester utan att ge Claude full shell-åtkomst.

MCP-behörigheter

MCP-servrar utökar Claude Code med verktyg det inte var designat för att arbeta med.

Varje server tar med sig sin egen verktygsuppsättning (en GitHub-server lägger till verktyg för pull requests, en databasserver lägger till frågeverktyg osv.). Behörighetssystemet täcker även dessa, men med en annan syntax – regler använder formatet mcp__servername__toolname i stället för parentes-syntaxen.

Kom ihåg att MCP i praktiken fördubblar frågan, eftersom du inte bara avgör vad Claude får göra i din shell, utan vad den får göra i varje externt system du kopplat till den.

Sandboxning

Sandboxning är säkerheten på OS-nivå under Bash-verktyget.

Behörighetsregler talar om för Claude vad den bör göra. Sandboxning tvingar igenom vad den kan göra, genom att begränsa filsystemsåtkomst och utgående nätverk på operativsystemnivå. På macOS fungerar det direkt via Seatbelt. På Linux och WSL2 behöver du först installera bubblewrap och socat.

Lagren fungerar likartat men täcker olika scenarier. Behörigheter hindrar Claude från att försöka, och sandboxning hindrar att försöket lyckas om en prompt-injektion ändå får Claude att prova.

Spårbarhet

Den sista pusselbiten är att kunna se vad som hände.

/permissions-kommandot listar varje aktiv regel och vilken inställningsfil den kommer ifrån, så du kan svara på ”varför körde Claude det där?” Hooks (PreToolUse, PostToolUse och andra) låter dig logga varje verktygsanrop till ditt eget system. För team skickar OpenTelemetry-exporter användnings- och verktygsanropsdata till den observabilitetsstack ni redan kör.

Claude Code-behörigheter och åtkomstkontroll

Det mesta av säkerheten kommer från behörighetsinställningar, så det är här du kommer lägga mest tid på finjustering.

Filåtkomst

Claude kan som standard läsa och redigera filer i katalogen du startade den från.

Läsning styrs av Read-verktyget, och redigering av Edit och Write. Varje accepterar ett sökvägsmönster inom parentes med gitignore-liknande syntax; till exempel matchar Read(**/.env) varje .env-fil på valfritt djup, och Edit(src/**) matchar allt under src/.

En deny på Read täcker Claude Codes egna filverktyg (Read, Grep, Glob, LS), men det är bara ett försök i bästa fall. Ett Python- eller Node-skript som körs via Bash kan fortfarande öppna filen, eftersom läsningen sker via shell i stället för genom Claudes Read-verktyg. Om en hemlighet är viktig, kombinera Read-deny med en Bash-deny på cat, head och tail för de sökvägarna.

För att utöka åtkomsten bortom arbetskatalogen använder du additionalDirectories i settings.json. Så ger du Claude åtkomst till ett delat bibliotek utanför din repo eller en konfigurationsfil i din hemkatalog utan att helt släppa gränsen för arbetskatalogen.

Kommandoexekvering

Bash-verktyget är det du måste avgränsa mest noggrant.

En bar Bash-regel tillåter alla kommandon. En avgränsad regel som Bash(npm run:*) tillåter bara matchande anrop. Kolon-stjärn-mönstret är det du behöver här, och Claude Code förstår shell-operatorer, så en regel som Bash(safe-cmd:*) matchar inte safe-cmd && rm -rf /.

Vissa kommandon körs utan prompt i alla lägen eftersom de behandlas som skrivskyddade som standard. Listan omfattar ls, cat, echo, pwd, head, tail, grep, find, wc, which, diff, stat, du, cd och skrivskyddade former av git. Du kan inte krympa listan manuellt, men du kan lägga till en ask- eller deny-regel för någon av dem för att åsidosätta standarden.

För allt som inte är förgodkänt frågar Claude i standardläge. Prompten visar det exakta kommandot och låter dig godkänna det en gång, godkänna alla framtida anrop som matchar ett mönster eller neka.

Behörighetslägen

Behörighetsregler är statiska, men behörighetslägen ändrar hur omatchade anrop beter sig.

Det finns fem:

• default: frågar vid första användningen av varje verktyg.

• acceptEdits: godkänner automatiskt filändringar i arbetskatalogen och styr fortfarande shell-kommandon. Användbart när du litar på ändringarna men inte på shell:et.

• plan: Claude läser och analyserar men kan inte redigera filer eller köra kommandon. Rätt läge för kodgranskning eller planeringssessioner.

• dontAsk: nekar automatiskt allt som inte uttryckligen finns på allow-listan.

• bypassPermissions: hoppar över varje prompt. Endast säkert i helt isolerade miljöer som en container eller VM.

Du kan växla mellan de tre huvudsakliga lägena med Skift+Tab mitt i en session, eller välja ett som standard i settings.json:

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "deny": ["Read(**/.env)", "Read(**/.env.*)"]
  }
}

För team ger hanterade inställningar ett lager som användaren inte kan åsidosätta. Filen följer samma JSON-format och finns på en systemväg:

• /Library/Application Support/ClaudeCode/managed-settings.json på macOS

• /etc/claude-code/managed-settings.json på Linux

• C:\ProgramData\ClaudeCode\managed-settings.json på Windows

Deny-regler i hanterade inställningar gäller i alla projekt på datorn, vilket är hur du verkställer regler som ”ingen läser .env-filer” eller ”ingen kör bypassPermissions” i en organisation.

Principen bakom detta är minsta möjliga åtkomst, samma som du skulle tillämpa på vilket tjänstkonto som helst. 

Du bör börja med den minsta uppsättningen behörigheter som låter arbetet ske och bara vidga dem när du kör fast. Anthropics egna riktlinjer pekar åt samma håll – granska ändringarna Claude gör, granska dina regler med /permissions och håll projektspecifika inställningar under versionskontroll så att teamet är överens om vad Claude får arbeta med.

Claude Code-sandboxning

Ju mer du låter Claude köra autonomt, desto mer vettigt blir sandboxning.

Bash-verktyget har störst exponering eftersom shell-kommandon kan läsa alla filer du kan läsa och ändra allt de har skrivrättigheter till. Sandboxning tvingar in OS-gränser på varje Bash-kommando och dess barnprocesser, så Claude kan köra friare inom gränsen utan att du godkänner varje anrop. Anthropic byggde in detta specifikt för att stödja säkrare autonoma körningar.

En detalj värd att förstå är att sandboxen bara täcker Bash och dess barnprocesser. Den begränsar inte Read-, Edit- eller Write-verktygen, och de går fortfarande genom behörighetssystemet.

Inbyggd sandboxning

Den inbyggda sandboxen finns i Claude Code och aktiveras med /sandbox.

På macOS används det inbyggda Seatbelt-ramverket och inget behöver installeras. På Linux och WSL2 installerar du bubblewrap för filsystemsisolering och socat för nätverksproxyn. Native Windows stöds inte, så du kör Claude Code i stället i en WSL2-distribution.

Gränsen för filsystemet är lätt att förstå. Läsningar fungerar överallt utom på nekade sökvägar, och skrivningar fungerar bara i arbetskatalogen och de ytterligare sökvägar du tillåter. Om du försöker skriva till ~/.bashrc inifrån sandboxen får du ”Operation not permitted” innan Claude ens vet att det misslyckades.

Nätverksgränsen är något annorlunda. Utgående trafik går via en proxyserver utanför sandboxen, som kontrollerar varje begäran mot din allowedDomains-lista. Nya domäner triggar i stället en behörighetsprompt, så du ser exakt vad Claude försöker nå.

En fungerande konfiguration ser ut så här:

{
  "sandbox": {
    "enabled": true,
    "autoAllowBashIfSandboxed": true,
    "filesystem": {
      "allowWrite": ["/workspace", "/tmp"],
      "denyRead": ["~/.aws", "~/.ssh"]
    },
    "network": {
      "allowedDomains": ["github.com", "*.npmjs.org"]
    }
  }
}

I Anthropics interna användning minskar sandboxning behörighetsfrågorna med 84 %.

Utvecklingscontainrar

Dev-containrar är nästa steg i isolering.

Anthropic har en referensdevcontainer för Claude Code som sätter upp en Ubuntu-miljö, monterar din repo och ger agenten ett shell att arbeta i. Fördelen jämfört med inbyggd sandboxning är reproducerbarhet, eftersom alla i teamet får samma miljö med samma verktyg och samma setup.

Men nackdelen är overheaden. 

Du lägger på containerbygge, filmontering och (ibland) långsammare återkoppling när du använder containrar. För en enskild utvecklare räcker oftast den inbyggda sandboxen. För team- eller CI-bruk är den här setupen värd det.

Docker-baserad isolering

För långvariga autonoma agentsessioner kan Docker ytterligare förstora sandboxgränsen.

Setupen ser vanligtvis ut så här:

• Minimal basimage: ta bort pakethanterare och nätverksverktyg som uppgiften inte behöver.
• Icke-root-användare: Claude körs aldrig som root, så den kan inte ändra systemfiler eller installera globala paket.
• Skrivskyddat root-filsystem: montera container-roten som skrivskyddad, med endast specifika utdatakataloger skrivbara.
• Egress-proxy: routa utgående nätverkstrafik via en proxy som tillåter paketrepositorier (npm, PyPI) och nekar allt annat, så att kommandon som npm install fungerar men ett godtyckligt curl-kommando inte gör det.
• Resursbegränsningar: sätt gränser för CPU, minne och I/O så att en process inte kan slå ut värden.

Docker Sandboxes ger varje sandbox sin egen mikro-VM med en privat Docker-daemon. Värdens daemon kan inte ens se sandboxarna i docker ps. Gränsen ligger närmare en VM än en container, vilket stänger de flesta vägar för container-escape som utvecklare oroar sig för.

Sandboxningsstrategier för företag

För organisationer handlar frågan om hur man lager på lager använder sandboxtekniker, inte om man ska använda dem.

Så här brukar de flesta gå till väga:

• Behörighetsregler läggs i managed-settings.json och kan inte åsidosättas av enskilda utvecklare.

• Inbyggd sandboxning körs under behörighetslagret.

• Dev-containrar eller Docker körs under det.

• För de mest betrodda scenarierna (produktionsåtkomst, hantering av hemligheter) är en dedikerad VM utan värdfilsystem-mount sista lagret.

Claude Code på webben är en hanterad version av samma idé. Varje session körs i en VM som hanteras av Anthropic, känsliga uppgifter som git-tokens placeras utanför sandboxen i en proxy och gränsen upprätthålls av infrastrukturen.

MCP-säkerhet i Claude Code

MCP är den del av Claude Code som växer snabbast.

Varje MCP-server du ansluter multiplicerar ungefär vad Claude kan göra, men den multiplicerar också ytan som en prompt-injektion eller ett komprometterat beroende kan nå. 

Till exempel:

• En GitHub-MCP-server ger Claude åtkomst till pull requests.
• En databas-MCP-server ger den ditt schema och dina frågor.
• En Slack-server ger den dina kanaler.

Inget av detta är ett problem, men det betyder att MCP behöver egen styrning. Innehåll som hämtas via ett MCP-verktyg (en webbsida eller ett API-svar) kan innehålla injicerade instruktioner som Claude utför som om du hade skrivit dem. Dessutom lägger varje server till en uppgift och en autentiseringsväg som måste hanteras separat.

Verktygsbehörigheter

MCP-verktyg använder en annan namngivningskonvention än inbyggda verktyg.

Regelformatet är mcp__servername__toolname, utan parentes-specifikation. Till exempel låter mcp__github__create_pull_request Claude anropa just det verktyget, och en deny på mcp__github__delete_repo blockerar det farliga. Allow-, ask- och deny-listor fungerar på samma sätt som för Bash eller Read.

Samma prioritetsregler gäller också – deny först, sedan ask, sedan allow. En deny i hanterade inställningar på mcp__github__delete_* gäller i varje projekt på maskinen.

Resursbehörigheter

MCP-servrar kan exponera resurser tillsammans med verktyg.

En resurs är ett datapaket som servern gör tillgängligt för Claude att läsa (en fil i en projektledningsserver eller en rad i en databasserver). Resursåtkomst går genom samma förtroendekontroll som verktygsanrop, och en första anslutning till en MCP-server kör ett tillitsverifieringssteg innan något av dess verktyg eller resurser blir nåbara.

Rätt standard är att behandla resurser som ännu ett verktyg. Om du inte skulle ge uppgiften, ge inte resursåtkomst.

Godkända MCP-servrar

Anthropic Directory listar kontakter som Anthropic har granskat mot sina listningskriterier.

För organisationer är ett bra mönster att använda en intern allowlist. Det finns två inställningar som ger dig kontrollen:

• allowedMcpServers: ett glob-mönster för servrar som utvecklare kan lägga till i sina projekt (till exempel company-* för att bara tillåta internt underhållna servrar).

• deniedMcpServers: ett mönster för servrar som inte kan läggas till, även om utvecklaren försöker.

För obligatoriska servrar som ska finnas i varje session är en managed-mcp.json-fil i de hanterade inställningarna sättet att distribuera dem. Utvecklare kan inte ta bort eller ändra posterna.

En inställning att undvika i delade repos är enableAllProjectMcpServers, som auto-godkänner varje MCP-server definierad i .mcp.json. Det är bekvämt för soloprojekt men farligt för allt som checkas in, eftersom en skadlig PR kan lägga till en ny server i .mcp.json och få den att köras utan prompt.

Minsta möjliga verktygsåtkomst

Samma princip som för Bash-behörigheter, bara tillämpad på MCP.

Startfrågan är vilken uppgift varje server har. En databas-MCP-server bör ansluta till en läsreplika med skrivskyddad åtkomst, inte primären med skrivrättigheter. En API-MCP-server bör använda en token avgränsad till minsta nödvändiga uppsättning endpoints, inte en personlig token med full org-åtkomst. Och så vidare.

Underagenter är ett annat sätt att avgränsa MCP-åtkomst. En underagentdefinition i .claude/agents/ kan deklarera exakt vilka verktyg den har åtkomst till (med syntaxen mcp:<server>:<tool>), så en ”deploy-agent” får infrastrukturservern och en ”review-agent” får bara Read, Grep och Glob. Agenten kan inte anropa verktyg den inte har tilldelats.

MCP-styrning

För ett team eller en organisation som kör Claude Code i skala behöver MCP samma styrningsform som vilken annan produktionsintegration som helst.

Det betyder ett register över godkända servrar med namngivna ägare, end-to-end-spårbarhet av verktygsanrop (vilka MCP-verktyg som anropades, av vem, med vilka parametrar) och en periodisk översyn av godkännandelistan. OpenTelemetry-exporter i Claude Code ger dig auditdata i ett format som passar in i den observabilitetsstack ni redan kör.

För större organisationer är en centraliserad MCP-gateway den renaste versionen av detta. 

Utvecklare ansluter till gatewayen i stället för att registrera enskilda servrar. Gatewayen hanterar autentisering, upprätthåller rollbaserad åtkomst på verktygsnivå och skickar en samlad auditlogg. Den löser också spridning av uppgifter, eftersom en uppsättning uppgifter i gatewayen ersätter att varje utvecklare håller en kopia av varje API-nyckel.

Hantering av hemligheter och känslig data

Claude Code kan läsa allt du kan läsa, vilket gör hemligheter åtkomliga.

Som standard kan Claude Code läsa varje fil som ditt användarkonto kan. Det inkluderar .env-filer i ditt projekt, AWS-uppgifter i ~/.aws/, privata SSH-nycklar i ~/.ssh/, GitHub-tokens i din shell rc-fil och miljövariablerna i alla underprocesser som Claude skapar. Det är helt normalt och enligt design.

Håll hemligheter utanför arbetsytan

Första steget är att se till att hemligheter inte ligger i katalogen som Claude läser.

.env-filer är de vanligaste. De ligger i projektroten, laddas av varje utvecklarverktyg och innehåller exakt de värden du inte vill ha i ett Claude-sammanhang (databas-URL:er och API-nycklar). 

Här är ett par mönster du kan använda:

• Flytta hemligheter till en katalog utanför arbets­trädet, till exempel ~/.config/myapp/secrets.env, och ladda dem via en miljöhanterare eller en direnv-setup som pekar på den externa filen.

• För containeriserat arbete, håll en .secrets/-mapp utanför bind-mounten så att filen är osynlig inifrån containern.

• Lägg till Read(**/.env) och Read(**/.env.*) i din permissions.deny-lista och para ihop dem med Bash(cat:*/.env)-deny så att ett shell-skript inte kan läsa det som Read-verktyget inte får.

Använd en hemlighetshanterare

För allt utöver demoprojekt är rätt plats för hemligheter en hemlighetshanterare.

Mönstret är detsamma oavsett leverantör (1Password, AWS Secrets Manager, HashiCorp Vault, Doppler, Infisical). Hemligheter placeras i hanteraren. Ditt shell eller runtime hämtar dem vid behov och exponerar dem bara för processen som behöver dem. Claude ser aldrig det faktiska värdet.

För Claude Code specifikt innebär detta att sätta CLAUDE_CODE_SUBPROCESS_ENV_SCRUB för att ta bort Anthropic- och molnleverantörers uppgifter från underprocesser, eller använda sandbox.credentials för att avsätta specifika variabler för sandboxade kommandon. Det första hindrar Claude från att föra vidare din ANTHROPIC_API_KEY in i ett byggskript, och det andra täcker det bredare fallet där en känslig miljövariabel letar sig in i ett shell-kommando.

Begränsa arkivåtkomst

Det tredje alternativet ligger på repo-nivå.

Om en utvecklare inte behöver skrivrättigheter till produktions­konfiguration behöver deras Claude Code-session det inte heller. Det låter självklart, men standarden för de flesta team är att utvecklare har bredare åtkomst än de rutinmässigt använder, och Claude ärver allt detta.

Här är två steg du kan ta:

• Dela upp produktionskonfiguration i en separat repo med striktare åtkomst, så att utvecklingsmiljön Claude arbetar i inte har produktionshemligheterna från början.

• Använd avgränsade tokens för alla tjänster Claude interagerar med. Till exempel behöver en GitHub-token för kodgranskning inte repo:delete.

Claude Code-säkerhet för team

En ensam utvecklare kan ändra settings.json hur de vill. Ett team kan inte det, eftersom den övergripande säkerheten bara är lika stark som den svagaste konfigurationen på den svagaste datorn. För team- och organisationsutrullningar har Claude Code ett separat lager av kontroller som en admin trycker ned och enskilda användare inte kan åsidosätta.

Hanterade inställningar

Hanterade inställningar är grunden.

Filen ligger på en systemväg som kräver adminåtkomst för att skriva:

• /Library/Application Support/ClaudeCode/managed-settings.json på macOS

• /etc/claude-code/managed-settings.json på Linux

• C:\ProgramData\ClaudeCode\managed-settings.json på Windows

Inställningar i den här filen har företräde framför användar- och projektinställningar. En deny-regel här är en deny-regel i alla projekt på datorn, och utvecklaren kan inte ta bort den genom att redigera sin egen settings.json. De flesta organisationer distribuerar filen via MDM (Mobile Device Management) eller samma konfigurationskanal som de använder för andra utvecklarverktyg.

Här är några inställningar som är bra att känna till på den hanterade nivån:

• permissions.deny-regler för känsliga sökvägar och farliga kommandon

• defaultMode satt till default eller plan (aldrig bypassPermissions)

• allowManagedPermissionRulesOnly: true för att låsa behörighetsuppsättningen

• enableAllProjectMcpServers: false för att kräva uttryckligt MCP-godkännande

• Konfiguration av OpenTelemetry-exporter för loggning

Delade behörighetspolicys

Ett team som är överens om vad Claude får göra bör versionshantera den överenskommelsen.

Projektinställningar finns i .claude/settings.json i repo-roten. Allt som checkas in här gäller alla som kör Claude i den repot. Filen är rätt plats för projektspecifika allow- och deny-regler.

Med det i åtanke finns en uppdelning mellan hanterade och projektinställningar som du behöver känna till:

• Hanterade inställningar innehåller organisationspolicy (ingen kör bypassPermissions, ingen läser .env).

• Projektinställningar innehåller arbetsflödeskonventioner (det här repots tester körs med npm test; det här repots deploy-skript är förbjudet).

Teamstyrning

För en teamutrullning behöver policylagret en ägare.

De flesta team som kör Claude Code i skala landar i en liten grupp, oftast säkerhet och plattformsingenjörer, som äger de hanterade inställningarna, MCP-allowlisten, hook-skripten och OpenTelemetry-pipelinen. Samma grupp granskar undantagsförfrågningar och justerar policyn när nya användningsfall dyker upp.

Du bör sikta på att ha följande skriftligt:

• Vilka repos som är inom räckvidd och vilka som inte är det, med risknivåbaserade lägen (ett repo som hanterar reglerad data kör troligen Claude i plan-läge, medan ett marknadsföringssajt-repo kan köra i acceptEdits).
• Vem som kan bevilja undantag och hur de spåras.
• En granskningskadens (kvartalsvis är vanligt) där teamet går igenom behörighetsregler, MCP-servrar och incidentdata.

Auditloggning

Claude Code skickar OpenTelemetry-händelser för varje verktygsbeslut, MCP-serveranslutning, ändring av behörighetsläge och API-begäran. Ingen data flödar förrän en admin konfigurerar OTLP-endpoint i hanterade inställningar.

Här är ett minimalt block med hanterade inställningar för telemetri:

{
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_METRICS_EXPORTER": "otlp",
    "OTEL_LOGS_EXPORTER": "otlp",
    "OTEL_EXPORTER_OTLP_PROTOCOL": "grpc",
    "OTEL_EXPORTER_OTLP_ENDPOINT": "http://collector.internal:4317"
  }
}

Som standard exkluderas promptinnehåll och verktygsparametrar från exporten, så händelserna du samlar in är metadata, inte hela konversationen. För att inkludera prompttext sätter du OTEL_LOG_USER_PROMPTS=1. För att inkludera verktygsargument (vilket vanligtvis är det du vill ha för audit) sätter du OTEL_LOG_TOOL_DETAILS=1. Båda besluten har integritetsimplikationer, så de flesta team behandlar dem som genomtänkta policyställningstaganden och konfigurerar sin telemetribackend att filtrera eller maskera innan lagring.

Användningsövervakning

Samma OpenTelemetry-ström som ligger bakom audit ligger också bakom användningsövervakning.

Claude Code exporterar mätvärden för tokenanvändning, kostnad per begäran, antal sessioner och frekvens av verktygsbeslut. När de aggregeras kan du se vilka team som får mest värde, vilka arbetsflöden som ger flest avslag och vilka modeller som driver kostnaden. Backends som Datadog, Honeycomb, SigNoz, Elastic och Splunk tar alla emot standardformatet OTLP.

En topp i permission_decision-händelser med decision=deny kan betyda att Claude försöker för mycket, men det kan också betyda att teamets allow-regler är för snäva.

Vanliga säkerhetsmisstag i Claude Code

En liten uppsättning felkonfigurationer dyker upp i de flesta incidenter med Claude Code. Jag visar nu vilka dessa är och vad du kan göra åt dem.

Alltför breda behörigheter

Det snabbaste sättet att slöa ned behörighetssystemet är att tillåta för mycket.

Promptar per kommando ger friktion, och en enkel fix är en bred Bash(*)-allow eller en defaultMode: bypassPermissions-inställning. Båda gör ogjort det mesta av vad behörighetssystemet gör.

Du bör avgränsa allow-regler till specifika verktyg och kommandon du faktiskt använder (till exempel Bash(npm test:*) och Bash(git status)) och låta allt annat falla tillbaka till en prompt. Du får fler promptar i början, men inom några sessioner har du allow-listat kommandona du använder och promptarna upphör till stor del.

Obegränsad MCP-åtkomst

Det andra misstaget är att koppla MCP-servrar utan att kontrollera vilka uppgifter de använder eller vad de kan nå.

Detta händer oftast för att någon aktiverar enableAllProjectMcpServers, kopplar några servrar från det offentliga MCP-registret och aldrig återkommer för att granska dem. När en server med svaga uppgifter väl läcker något känsligt ligger kopplingen tillräckligt långt bak i konfigurationen för att ingen minns att den godkändes.

Lösningen är densamma som för behörigheter. Använd en uttrycklig allowlist via allowedMcpServers, en intern managed-mcp.json för servrarna alla behöver och en granskningskadens för listan.

Ingen sandboxning

Om sandboxning är avstängd är behörighetssystemet det enda som står mellan Claude och ditt filsystem.

Det är okej för korta interaktiva sessioner där du ändå godkänner varje kommando. Det är inte okej för autonoma körningar, för sessioner där du har breddat allow-regler eller för arbete som rör kod från externa källor.

/sandbox slår på det. Om beroenden inte är installerade visar menyn vilka som ska installeras för din plattform. När det är på minskar behörighetspromptarna och OS:et fångar de fall dina allow-regler inte gör.

Blint accepterande av ändringar

acceptEdits är både bekvämt och riskabelt.

När Claude skriver om en funktion och du övervakar det är auto-accept okej. När Claude itererar över 30 filer under en timme slutar du ofta läsa diffarna och börjar lita på agenten. Det är där problemen kan uppstå.

Här är två vanor du bör ha:

• Commit:a alltid innan du låter Claude köra autonomt, så att återställningsvägen är ett git reset bort.

• Granska diffen före varje commit som Claude gjort, inte den kumulativa diffen i slutet av en session.

Att ignorera auditspår

Ett team som kör Claude Code utan telemetri kan inte svara på frågan ”vilken session gjorde det där?” Händelserna ackumuleras lokalt på varje maskin och stannar där. Första gången du behöver ett auditspår är också sämsta tillfället att upptäcka att du inte konfigurerade ett.

Miniminivån som är användbar är att exportera händelserna tool_decision, permission_decision och api_request till den observabilitetsstack teamet redan kör. Därifrån bygger du dashboards och larm när behoven uppstår.

Slutsats

Ett värsta scenario för en chatbot är ett dåligt svar. Men för en kodningsagent är det ett shell-kommando som körs mot produktion med dina uppgifter.

Det är därför de tre pelarna spelar roll:

• Behörigheter avgör vad Claude får göra
• MCP-kontroller avgör vilka externa system den kan nå
• Sandboxning avgör vad som händer när de två första inte räcker

Varje del täcker ett fel-läge som de andra inte gör. Tillsammans definierar de den faktiska gräns Claude arbetar inom.

Om du vill bli certifierad inom generativ AI hittar du jämförelser, toppkurser, förberedelsetips och vanliga frågor för Bästa generativa AI-certifieringarna 2026.