Claude Code-beveiligingsgids: Machtigingen, MCP, sandboxing

Traditionele chatbots draaien achter een API, dus het ergste wat ze kunnen doen is hallucineren. Maar een AI-codeagent zit in je repo, je terminal en (vaak) je cloud-credentials, waardoor hij veel dichter op bevoorrechte ontwikkelomgevingen zit dan wat we vroeger een chatbot noemden.

De vraag is hoe je Claude Code veilig gebruikt zonder jezelf te vertragen. Met machtigingen, MCP-controles en sandboxing kom je er — mits je ze goed afstelt.

In dit artikel laat ik je zien hoe het beveiligingsmodel van Claude Code in de praktijk werkt, waar je op moet letten en welke werkwijzen het nuttig houden zonder meer toegang te geven dan je van plan was.

Als je helemaal nieuw bent met Claude en Claude Code, schrijf je dan in voor onze gratis Claude Code 101-cursus om de basis in één middag te leren.

Het beveiligingsmodel van Claude Code begrijpen

Voor je ook maar één regel afstelt, heb je een mentaal model nodig van wat Claude Code daadwerkelijk beheerst.

Er zijn vijf bewegende delen: een machtigingssysteem dat bepaalt wat mag, toegangscontroles per tool die individuele mogelijkheden afbakenen, MCP-machtigingen voor externe integraties, sandboxing voor OS-niveau-isolatie en auditbaarheid voor achterafcontrole. Elk lost een ander probleem op, maar ze stapelen op elkaar.

Machtigingssysteem

Het machtigingssysteem is de statische laag.

Je verklaart wat Claude mag doen in settings.json, met drie lijsten: allow, ask en deny. Regels worden geëvalueerd met eerst deny, dan ask, dan allow, en de eerste match wint. Een deny-regel blokkeert de aanroep zelfs als een bredere allow-regel deze ook zou matchen.

Als geen enkele regel matcht, valt Claude terug op de defaultMode van de sessie (meer over modi in de volgende sectie).

Toegangscontroles voor tools

Machtigingen zijn gekoppeld aan tools, niet aan de agent als geheel.

Claude Code heeft een eigen set ingebouwde tools, bijvoorbeeld Bash voor shell-commando's, Read en Edit en Write voor bestandsoperaties, WebFetch voor HTTPS-verzoeken, WebSearch voor zoekopdrachten en nog een paar. Elke regel noemt een tool en (optioneel) een specificatie tussen haakjes, zoals Bash(git commit:*) of Read(./.env).

Dit is wat least privilege mogelijk maakt. Je kunt Bash(npm run:*) toestaan voor tests zonder Claude volledige shelltoegang te geven.

MCP-machtigingen

MCP-servers breiden Claude Code uit met tools waarvoor het niet is ontworpen.

Elke server brengt een eigen set tools mee (een GitHub-server voegt pull request-tools toe, een databaseserver voegt querytools toe, enzovoort). Het machtigingssysteem dekt die ook, maar met een andere syntax — regels gebruiken de vorm mcp__servername__toolname in plaats van de specificatie tussen haakjes.

Het punt om te onthouden is dat MCP de vraag grofweg verdubbelt, omdat je niet alleen beslist wat Claude met je shell mag, maar ook wat hij mag met elk extern systeem dat je eraan hebt gekoppeld.

Sandboxing

Sandboxing is de OS-niveau-veiligheid onder de Bash-tool.

Machtigingsregels vertellen Claude wat hij zou moeten doen. Sandboxing handhaaft wat hij kan doen, door bestands- en uitgaande netwerktoegang op het besturingssysteemniveau te beperken. Op macOS werkt het out-of-the-box via Seatbelt. Op Linux en WSL2 moet je eerst bubblewrap en socat installeren.

De twee lagen werken vergelijkbaar maar dekken verschillende scenario's. Machtigingen voorkomen dat Claude iets probeert, en sandboxing voorkomt dat de poging slaagt als een prompt-injectie Claude toch zover krijgt.

Auditbaarheid

Het laatste onderdeel is kunnen zien wat er is gebeurd.

Het commando /permissions somt elke actieve regel en het bijbehorende settingsbestand op, zodat je kunt antwoorden op "waarom voerde Claude dat uit?" Hooks (PreToolUse, PostToolUse en andere) laten je elke toolaanroep naar je eigen systeem loggen. Voor teams sturen OpenTelemetry-exporters gebruiks- en toolaanroepgegevens naar de observability-stack die je al hebt.

Claude Code-machtigingen en toegangscontrole

Het meeste van de veiligheid komt uit de machtigingsinstellingen, dus hier zul je de meeste tijd aan sleutelen.

Bestandstoegang

Claude kan standaard bestanden lezen en bewerken in de map waaruit je hem startte.

Lezen wordt geregeld door de Read-tool, en bewerken door Edit en Write. Elke tool accepteert een padpatroon tussen haakjes, met gitignore-achtige syntax; bijvoorbeeld Read(**/.env) matcht elk .env-bestand op elke diepte, en Edit(src/**) matcht alles onder src/.

Een deny op Read dekt de eigen bestands-tools van Claude Code (Read, Grep, Glob, LS), maar het is slechts best effort. Een Python- of Node-script dat via Bash draait kan het bestand nog steeds openen, omdat dat lezen via de shell gebeurt en niet via Claude's Read-tool. Als een geheim ertoe doet, combineer de Read-deny dan met een Bash-deny op cat, head en tail voor die paden.

Om toegang buiten de werkmap uit te breiden, gebruik je additionalDirectories in settings.json. Zo geef je Claude toegang tot een gedeelde bibliotheek buiten je repo of een configbestand in je homedirectory, zonder de grens van de werkmap volledig te laten vallen.

Commando-uitvoering

De Bash-tool is degene die je het nauwkeurigst moet afbakenen.

Een kale Bash-regel staat elk commando toe. Een afgebakende regel zoals Bash(npm run:*) staat alleen overeenkomende aanroepen toe. Het dubbelepunt-sterpatroon is wat je hier moet gebruiken, en Claude Code begrijpt shell-operatoren, dus een regel als Bash(safe-cmd:*) matcht niet met safe-cmd && rm -rf /.

Sommige commando's draaien zonder prompt in elke modus, omdat ze standaard als read-only worden behandeld. De lijst omvat ls, cat, echo, pwd, head, tail, grep, find, wc, which, diff, stat, du, cd en read-only vormen van git. Je kunt deze lijst niet handmatig verkleinen, maar je kunt wel een ask- of deny-regel toevoegen om de standaard te overrulen.

Voor alles wat niet vooraf is goedgekeurd, vraagt Claude om toestemming in de standaardmodus. De prompt toont het exacte commando en laat je het eenmalig goedkeuren, alle toekomstige aanroepen die een patroon matchen goedkeuren, of weigeren.

Machtigingsmodi

Machtigingsregels zijn statisch, maar machtigingsmodi bepalen hoe niet-gematchte aanroepen zich gedragen.

Er zijn er vijf:

• default: vraagt bij het eerste gebruik van elke tool.

• acceptEdits: keurt bestandsbewerkingen in de werkmap automatisch goed en blijft shell-commando's controleren. Handig als je de edits vertrouwt maar de shell niet.

• plan: Claude leest en analyseert, maar kan geen bestanden bewerken of commando's uitvoeren. De juiste modus voor code review of planningssessies.

• dontAsk: weigert automatisch alles wat niet expliciet in de allow-lijst staat.

• bypassPermissions: slaat elke prompt over. Alleen veilig in volledig geïsoleerde omgevingen zoals een container of VM.

Je kunt tijdens een sessie met Shift+Tab door de drie hoofdmodi bladeren, of er één als standaard kiezen in settings.json:

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

Voor teams geven beheerde instellingen je een laag die de gebruiker niet kan overschrijven. Het bestand volgt hetzelfde JSON-formaat en staat op een systeempad:

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

• /etc/claude-code/managed-settings.json op Linux

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

Deny-regels in beheerde instellingen gelden in elk project op de machine, zodat je regels als "niemand leest .env-bestanden" of "niemand draait bypassPermissions" organisatiebreed kunt afdwingen.

Het principe achter dit alles is least privilege, hetzelfde dat je op elk service-account zou toepassen. 

Begin met de kleinste set machtigingen waarmee het werk kan gebeuren, en verbreed ze alleen als je ergens op stukloopt. De richtlijnen van Anthropic wijzen dezelfde kant op — beoordeel de wijzigingen die Claude maakt, audit je regels met /permissions, en hou project-specifieke settings in versiebeheer zodat het team het eens is over waar Claude aan mag werken.

Claude Code-sandboxing

Hoe autonomer je Claude laat draaien, hoe logischer sandboxing wordt.

De Bash-tool heeft de grootste exposure, omdat shell-commando's elk bestand kunnen lezen dat jij kunt lezen en alles kunnen wijzigen waarvoor ze schrijfrechten hebben. Sandboxing legt OS-grenzen op aan elk Bash-commando en zijn childprocessen, zodat Claude vrijer binnen de grens kan draaien zonder dat jij elke aanroep hoeft goed te keuren. Anthropic heeft dit specifiek ingebouwd om veiligere autonome runs te ondersteunen.

Een belangrijk detail is dat de sandbox alleen Bash en zijn childprocessen dekt. Hij beperkt Read, Edit of Write niet; die gaan nog steeds via het machtigingssysteem.

Native sandboxing

De native sandbox zit ingebouwd in Claude Code en gaat aan met /sandbox.

Op macOS gebruikt sandboxing het ingebouwde Seatbelt-framework en hoef je niets te installeren. Op Linux en WSL2 installeer je bubblewrap voor filesystem-isolatie en socat voor de netwerkproxy. Native Windows wordt niet ondersteund, dus draai je Claude Code in een WSL2-distributie.

De bestandsgrens is makkelijk te begrijpen. Lezen werkt overal behalve op geweigerde paden, en schrijven werkt alleen binnen de werkmap en de extra paden die je toestaat. Als je vanuit de sandbox naar ~/.bashrc probeert te schrijven, krijg je "Operation not permitted" voordat Claude überhaupt weet dat het mislukte.

De netwerkgrens werkt iets anders. Uitgaand verkeer loopt via een proxyserver buiten de sandbox, die elk verzoek checkt tegen je allowedDomains-lijst. Nieuwe domeinen triggeren in plaats daarvan een machtigingsprompt, zodat je precies ziet waar Claude naartoe wil.

Een werkende configuratie ziet er zo uit:

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

Bij intern gebruik door Anthropic verlaagt sandboxing het aantal machtigingsprompts met 84%.

Developmentcontainers

Devcontainers zijn de volgende stap in isolatie.

Anthropic heeft een referentie-devcontainer voor Claude Code die een Ubuntu-omgeving opzet, je repo mount en de agent een shell geeft om in te werken. Het voordeel boven native sandboxing is reproduceerbaarheid, omdat iedereen in het team dezelfde omgeving krijgt, met dezelfde tools en dezelfde setup.

Maar het nadeel is de overhead. 

Je voegt containerbuilds, bestandsmounts en (soms) tragere feedbackloops toe wanneer je containers gebruikt. Voor een enkele ontwikkelaar is de native sandbox meestal genoeg. Voor team- of CI-gebruik is deze setup de moeite waard.

Docker-gebaseerde isolatie

Voor langlopende autonome agentsessies kan Docker de sandboxgrens verder vergroten.

De setup ziet er meestal zo uit:

• Minimale basisimage: verwijder pakketmanagers en netwerktools die de taak niet nodig heeft.
• Niet-rootgebruiker: Claude draait nooit als root, zodat hij geen systeembestanden kan wijzigen of globale pakketten kan installeren.
• Alleen-lezen rootfilesystem: mount de container-root als alleen-lezen, met slechts specifieke uitvoermappen beschrijfbaar.
• Egress-proxy: routeer uitgaand netwerk via een proxy die het pakketregister (npm, PyPI) toestaat en al het andere weigert, zodat commando's als npm install werken maar een willekeurige curl-opdracht niet.
• Resource-limieten: stel limieten in voor CPU, geheugen en I/O zodat een proces de host niet kan omver trekken.

Docker Sandboxes geven elke sandbox zijn eigen microVM met een privé Docker-daemon. De host-daemon kan de sandboxes niet eens zien in docker ps. De grens ligt dichter bij een VM dan bij een container, wat de meeste container-escape-paden waar ontwikkelaars zich zorgen over maken afsluit.

Sandboxingstrategieën voor enterprises

Voor organisaties is de vraag hoe je sandboxtechnieken stapelt, niet of je ze gebruikt.

Zo pakken de meesten het aan:

• Machtigingsregels gaan in managed-settings.json en kunnen niet door individuele ontwikkelaars worden overschreven.

• Native sandboxing draait onder de machtigingslaag.

• Devcontainers of Docker draaien daar weer onder.

• Voor scenario's met het hoogste vertrouwensniveau (productietoegang, omgaan met geheimen) is een dedicated VM zonder hostfilesystem-mount de laatste laag.

Claude Code op het web is een beheerde versie van hetzelfde idee. Elke sessie draait in een door Anthropic beheerde VM, gevoelige credentials zoals git-tokens staan buiten de sandbox in een proxy, en de grens wordt afgedwongen door infrastructuur.

MCP-beveiliging in Claude Code

MCP is het deel van Claude Code dat het snelst groeit.

Elke MCP-server die je koppelt, vermenigvuldigt grofweg wat Claude kan, maar vergroot ook het oppervlak dat een prompt-injectie of gecompromitteerde dependency kan bereiken. 

Bijvoorbeeld:

• Een GitHub-MCP-server geeft Claude toegang tot pull requests.
• Een database-MCP-server geeft hem je schema en queries.
• Een Slack-server geeft hem je kanalen.

Geen van dit is een probleem, maar het betekent wel dat MCP eigen governance nodig heeft. Content die via een MCP-tool wordt opgehaald (een webpagina of een API-respons) kan geïnjecteerde instructies bevatten die Claude uitvoert alsof jij ze typt. Bovendien voegt elke server een credential en een authenticatiepad toe die afzonderlijk beheerd moeten worden.

Toolmachtigingen

MCP-tools gebruiken een andere naamgevingsconventie dan ingebouwde tools.

Het regel formaat is mcp__servername__toolname, zonder specificatie tussen haakjes. Bijvoorbeeld, mcp__github__create_pull_request laat Claude precies die tool aanroepen, en een deny op mcp__github__delete_repo blokkeert de gevaarlijke. Allow-, ask- en deny-lijsten werken hetzelfde als voor Bash of Read.

Dezelfde precedentieregels gelden ook — eerst deny, dan ask, dan allow. Een deny in managed settings op mcp__github__delete_* geldt voor elk project op de machine.

Resource-machtigingen

MCP-servers kunnen naast tools ook resources blootstellen.

Een resource is een stukje data dat de server beschikbaar stelt voor Claude om te lezen (een bestand in een projectmanagementserver of een rij in een databaseserver). Resource-toegang volgt dezelfde trustcheck als toolaanroepen, en een eerste verbinding met een MCP-server doorloopt een trustverificatie voordat tools of resources bereikbaar zijn.

De juiste default is om resources als een andere tool te behandelen. Als je de credential niet zou verlenen, verleen dan ook geen resource-toegang.

Goedgekeurde MCP-servers

De Anthropic Directory vermeldt connectors die Anthropic heeft beoordeeld aan de hand van zijn opnamecriteria.

Voor organisaties werkt een interne allowlist goed. Er zijn twee instellingen die je daarvoor de controle geven:

• allowedMcpServers: een glob-patroon van servers die ontwikkelaars aan hun projecten mogen toevoegen (bijvoorbeeld company-* om alleen intern onderhouden servers toe te staan).

• deniedMcpServers: een patroon van servers die niet kunnen worden toegevoegd, zelfs niet als de ontwikkelaar het probeert.

Voor verplichte servers die in elke sessie aanwezig moeten zijn, is een managed-mcp.json-bestand in de beheerde instellingen de manier om ze te distribueren. Ontwikkelaars kunnen de entries niet verwijderen of aanpassen.

Eén instelling om te vermijden in gedeelde repo's is enableAllProjectMcpServers, die elke in .mcp.json gedefinieerde MCP-server automatisch goedkeurt. Dat is handig voor solowerk en gevaarlijk voor alles wat ingecheckt is, omdat een kwaadaardige PR een nieuwe server aan .mcp.json kan toevoegen en die zonder prompt kan laten draaien.

Least-privilege-toegang tot tools

Zelfde principe als Bash-machtigingen, alleen toegepast op MCP.

De startvraag is welke credential elke server heeft. Een database-MCP-server moet verbinden met een read-replica met alleen-lezen-toegang, niet met de primary met schrijfrechten. Een API-MCP-server moet een token gebruiken dat is afgebakend tot de kleinst noodzakelijke set endpoints, niet een persoonlijk token met volledige org-toegang. Enzovoort.

Subagents zijn een andere manier om MCP-toegang af te bakenen. Een subagentdefinitie in .claude/agents/ kan exact aangeven tot welke tools hij toegang heeft (met de syntax mcp:<server>:<tool>), zodat een "deploy-agent" de infrastructuurserver krijgt en een "review-agent" alleen Read, Grep en Glob. De agent kan geen tools aanroepen die hij niet heeft gekregen.

MCP-governance

Voor een team of organisatie die Claude Code op schaal draait, heeft MCP dezelfde governancevorm nodig als elke andere productie-integratie.

Dat betekent een register van goedgekeurde servers met benoemde eigenaren, end-to-end audittrails van toolaanroepen (welke MCP-tools zijn aangeroepen, door wie, met welke parameters) en een periodieke review van de goedkeuringslijst. OpenTelemetry-exporters in Claude Code geven je auditdata in een formaat dat in elke observability-stack past die je al draait.

Voor grotere organisaties is een gecentraliseerde MCP-gateway de schoonste versie hiervan. 

Ontwikkelaars verbinden met de gateway in plaats van individuele servers te registreren. De gateway verzorgt authenticatie, dwingt op toolniveau rolgebaseerde toegang af en geeft één audittrail uit. Het lost ook credential-sprawl op, omdat één set credentials bij de gateway elke ontwikkelaar met een kopie van elke API-sleutel vervangt.

Secretsbeheer en gevoelige data

Claude Code kan alles lezen wat jij kunt lezen, wat geheimen bereikbaar maakt.

Standaard kan Claude Code elk bestand lezen waar jouw gebruikersaccount bij kan. Dat omvat .env-bestanden in je project, AWS-credentials in ~/.aws/, SSH-privésleutels in ~/.ssh/, de GitHub-tokens in je shell-rc-bestand en de omgevingsvariabelen in elk subprocess dat Claude aanmaakt. Dat is volkomen normaal en met opzet zo.

Hou geheimen uit de werkruimte

De eerste stap is zorgen dat geheimen niet in de map staan die Claude leest.

.env-bestanden zijn de meest voorkomende. Ze staan in de projectroot, worden door elke devtool geladen en bevatten precies de waarden die je niet in een Claude-context wilt hebben (database-URL's en API-sleutels). 

Hier zijn een paar patronen die je kunt gebruiken:

• Verplaats geheimen naar een map buiten de werkboom, bijvoorbeeld ~/.config/myapp/secrets.env, en laad ze via een omgevingsmanager of een direnv-setup die naar het externe bestand wijst.

• Bewaar voor gecontaineriseerd werk een map .secrets/ buiten de bind-mount zodat het bestand onzichtbaar is vanuit de container.

• Voeg Read(**/.env) en Read(**/.env.*) toe aan je permissions.deny-lijst en koppel ze aan Bash(cat:*/.env)-denies zodat een shellscript niet kan lezen wat de Read-tool niet mag.

Gebruik een secretmanager

Voor alles buiten demoprojecten is de juiste plek voor geheimen een secretmanager.

Het patroon is hetzelfde ongeacht de leverancier (1Password, AWS Secrets Manager, HashiCorp Vault, Doppler, Infisical). Geheimen worden in de manager geplaatst. Je shell of runtime haalt ze on demand op en stelt ze alleen bloot aan het proces dat ze nodig heeft. Claude ziet de daadwerkelijke waarde nooit.

Specifiek voor Claude Code betekent dit het instellen van CLAUDE_CODE_SUBPROCESS_ENV_SCRUB om Anthropic- en cloudprovider-credentials uit subprocessen te strippen, of sandbox.credentials gebruiken om specifieke variabelen voor gesandboxte commando's te unsetten. Het eerste voorkomt dat Claude je ANTHROPIC_API_KEY doorgeeft aan een buildscript, en het tweede dekt het bredere geval van elke gevoelige omgevingsvariabele die in een shell-commando terechtkomt.

Beperk repository-toegang

De derde optie is op repolniveau.

Als een ontwikkelaar geen schrijfrechten nodig heeft op configuratie die alleen voor productie is, heeft zijn Claude Code-sessie die ook niet. Dat klinkt vanzelfsprekend, maar de default voor de meeste teams is dat ontwikkelaars bredere toegang hebben dan ze routinematig gebruiken, en Claude erft dat allemaal.

Hier zijn twee stappen die je kunt nemen:

• Splits productconfiguratie af in een aparte repo met striktere toegang, zodat de dev-omgeving waarin Claude werkt de productiesecretens überhaupt niet bevat.

• Gebruik afgebakende tokens voor elke service waarmee Claude interacteert. Een GitHub-token voor code review heeft bijvoorbeeld geen repo:delete nodig.

Claude Code-beveiliging voor teams

Een solodev kan settings.json naar wens aanpassen. Een team niet, want de algehele beveiliging is maar zo goed als de zwakste config op de zwakste machine. Voor team- en organisatie-uitrol heeft Claude Code een aparte laag controles die een admin uitrolt en die individuele gebruikers niet kunnen overschrijven.

Beheerde instellingen

Beheerde instellingen zijn de basis.

Het bestand staat op een systeempad waarvoor adminrechten nodig zijn om te schrijven:

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

• /etc/claude-code/managed-settings.json op Linux

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

Instellingen in dit bestand hebben voorrang op gebruikers- en projectniveau. Een deny-regel die je hier plaatst, geldt als deny in elk project op de machine, en de ontwikkelaar kan die niet verwijderen door zijn eigen settings.json te bewerken. De meeste organisaties distribueren het bestand via MDM (Mobile Device Management) of hetzelfde configuratiekanaal dat ze voor andere devtools gebruiken.

Hier zijn wat instellingen die op beheerd niveau de moeite waard zijn:

• permissions.deny-regels voor gevoelige paden en gevaarlijke commando's

• defaultMode ingesteld op default of plan (nooit bypassPermissions)

• allowManagedPermissionRulesOnly: true om de set machtigingen vast te zetten

• enableAllProjectMcpServers: false om expliciete MCP-goedkeuring te vereisen

• OpenTelemetry-exporterconfiguratie voor logging

Gedeelde machtigingsbeleid

Een team dat het eens is over wat Claude mag doen, zou die afspraak in versiebeheer moeten zetten.

Projectinstellingen staan in .claude/settings.json in de root van de repo. Alles wat hier wordt ingecheckt, geldt voor iedereen die Claude in die repo draait. Dit bestand is de plek voor repo-specifieke allows en denies.

Met dat in gedachten is er een splitsing tussen beheerde en projectinstellingen die je moet kennen:

• Beheerde instellingen bevatten organisatiebeleid (niemand draait bypassPermissions, niemand leest .env).

• Projectinstellingen bevatten workflowconventies (in deze repo draai je tests met npm test; het deployscript van deze repo is off-limits).

Teamgovernance

Voor een teamuitrol heeft de beleidslaag een eigenaar nodig.

De meeste teams die Claude Code op schaal draaien, eindigen met een kleine groep — meestal security en platform engineering — die de beheerde instellingen, de MCP-allowlist, de hook-scripts en de OpenTelemetry-pijplijn beheert. Dezelfde groep beoordeelt uitzonderingsverzoeken en past beleid aan naarmate nieuwe use-cases opkomen.

Zorg dat je deze onderdelen op papier hebt:

• Welke repo's in scope zijn en welke niet, met risicogelaagde modi (een repo met gereguleerde data draait Claude waarschijnlijk in plan-modus, terwijl een marketing-siterepo in acceptEdits kan draaien).
• Wie uitzonderingen kan verlenen en hoe die worden bijgehouden.
• Een reviewcadans (per kwartaal is gebruikelijk) waarin het team machtigingsregels, MCP-servers en incidentdata opnieuw bekijkt.

Auditlogging

Claude Code zendt OpenTelemetry-events uit voor elke toolbeslissing, MCP-serververbinding, wijziging van machtigingsmodus en API-verzoek. Er stroomt geen data totdat een admin het OTLP-endpoint in beheerde instellingen configureert.

Hier is een minimaal blok met beheerde instellingen voor telemetry:

{
  "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"
  }
}

Standaard zijn promptinhoud en toolparameters uitgesloten van de export, dus de events die je verzamelt zijn metadata, niet het volledige gesprek. Om prompttekst mee te nemen, stel je OTEL_LOG_USER_PROMPTS=1 in. Om toolargumenten mee te nemen (wat je meestal wilt voor audit), stel je OTEL_LOG_TOOL_DETAILS=1 in. Beide keuzes hebben privacy-implicaties, dus de meeste teams behandelen ze als bewuste beleidskeuzes en configureren hun telemetry-backend om te filteren of te redigeren vóór opslag.

Gebruiksmonitoring

Dezelfde OpenTelemetry-stroom achter audit is ook de basis voor gebruiksmonitoring.

Claude Code exporteert metrics voor tokengebruik, kosten per verzoek, sessietellingen en toolbeslissingspercentages. Geaggregeerd laten die je zien welke teams de meeste waarde halen, welke workflows de meeste afwijzingen opleveren en welke modellen de kosten aanjagen. Backends zoals Datadog, Honeycomb, SigNoz, Elastic en Splunk slikken het standaard OTLP-formaat in.

Een piek in permission_decision-events met decision=deny kan betekenen dat Claude te veel probeert, maar ook dat de allow-regels van het team te strak staan.

Veelvoorkomende beveiligingsfouten met Claude Code

Een kleine set misconfiguraties duikt op in de meeste incidenten met Claude Code. Ik laat je nu zien welke dat zijn en wat je eraan doet.

Te brede machtigingen

De snelste manier om het machtigingssysteem bot te maken is te veel toestaan.

Prompts per commando voegen frictie toe, en de makkelijke fix is een brede Bash(*)-allow of een instelling defaultMode: bypassPermissions. Beide maken het meeste van het machtigingssysteem ongedaan.

Je moet allow-regels afbakenen tot specifieke tools en commando's die je daadwerkelijk gebruikt (bijvoorbeeld Bash(npm test:*) en Bash(git status)), en laat de rest terugvallen op een prompt. Je krijgt in het begin meer prompts, maar binnen een paar sessies heb je de commando's die je gebruikt op de allowlist gezet en stoppen de prompts grotendeels.

Onbeperkte MCP-toegang

De tweede fout is MCP-servers koppelen zonder te checken welke credentials ze gebruiken of waar ze bij kunnen.

Dit gebeurt meestal omdat iemand enableAllProjectMcpServers aanzet, een paar servers uit de openbare MCP-directory koppelt en nooit meer terugkomt om ze te beoordelen. Tegen de tijd dat een server met zwakke credentials iets gevoeligs lekt, zit de verbinding zo ver terug in de configuratie dat niemand zich herinnert dat deze is goedgekeurd.

De oplossing is dezelfde als voor machtigingen. Gebruik een expliciete allowlist via allowedMcpServers, een interne managed-mcp.json voor de servers die iedereen nodig heeft, en een reviewcadans voor de lijst.

Geen sandboxing

Als sandboxing uit staat, is het machtigingssysteem het enige tussen Claude en je filesystem.

Dat is prima voor korte interactieve sessies waar je elk commando toch goedkeurt. Het is niet oké voor autonome runs, voor sessies waarin je allow-regels hebt verbreed, of voor werk aan code uit externe bronnen.

/sandbox zet het aan. Als de dependencies niet zijn geïnstalleerd, toont het menu welke je voor jouw platform moet installeren. Eenmaal aan, dalen de prompts en vangt het OS de gevallen die jouw allow-regels niet afdekken.

Wijzigingen blindelings accepteren

acceptEdits is zowel handig als gevaarlijk.

Als Claude een functie herschrijft en jij meekijkt, is auto-accept prima. Als Claude een uur lang over 30 bestanden iterereert, stop je vaak met het lezen van de diffs en ga je de agent vertrouwen. Dat is waar problemen kunnen ontstaan.

Twee gewoontes die je zou moeten hebben:

• Commit altijd voordat je Claude autonoom laat draaien, zodat de rollback één git reset weg is.

• Beoordeel de diff vóór elke commit van Claude, niet de cumulatieve diff aan het einde van een sessie.

Audittrails negeren

Een team dat Claude Code zonder telemetry draait, kan de vraag "welke sessie deed dat?" niet beantwoorden. De events stapelen lokaal op elke machine op en blijven daar. De eerste keer dat je een audittrail nodig hebt, is ook het slechtste moment om te ontdekken dat je er geen hebt geconfigureerd.

Het minimale nuttige basisniveau is het exporteren van tool_decision-, permission_decision- en api_request-events naar welke observability-stack het team ook al draait. Van daaruit bouw je dashboards en alerts zodra use-cases opkomen.

Conclusie

Een worstcasescenario voor een chatbot is een fout antwoord. Maar voor een codeagent is het een shell-commando dat met jouw credentials tegen productie draait.

Daarom zijn de drie pijlers belangrijk:

• Machtigingen bepalen wat Claude mag doen
• MCP-controles bepalen welke externe systemen hij kan bereiken
• Sandboxing bepaalt wat er gebeurt als de eerste twee niet genoeg zijn

Elk dekt een faalmodus die de anderen niet dekken. Samen definiëren ze de werkelijke grens waarbinnen Claude werkt.

Als je een certificering in generatieve AI zoekt, vind je hier de vergelijkingen, topcursussen, voorbereidingstips en FAQ's voor de Beste Generatieve AI-certificeringen in 2026.