Claude Code en privacy: wat er met je code gebeurt en hoe je het dichtzet

Datastromen

Wat er van je machine af gaat, en wat blijft staan

Begin bij de basis, want hier gaan de meeste discussies mis. Claude Code is een programma op jouw computer dat jouw bestanden leest. Het model dat de antwoorden geeft, draait niet op jouw computer. Om te kunnen werken moet Claude Code dus tekst versturen: jouw prompts, de stukken code die het nodig heeft en de antwoorden die terugkomen.

Het verkeer naar het model

Alle prompts en modeloutputs gaan versleuteld via TLS 1.2 of hoger naar de provider die in je configuratie staat. Dat is standaard de Anthropic API, maar het kan ook Amazon Bedrock, Google Vertex AI of Microsoft Foundry zijn. Dat is meteen de belangrijkste knop voor organisaties met eisen over waar hun data landt: kies je die route, dan gaat je verkeer naar dat platform onder de afspraken die je daar al hebt liggen.

Je transcripts staan lokaal, in leesbare tekst

Elke sessie wordt op je eigen schijf bewaard onder ~/.claude/projects/, als platte tekst. Niet versleuteld, niet afgeschermd. Standaard blijft dat 30 dagen staan; je verandert dat met cleanupPeriodDays in je settings. Dat klinkt als een detail, maar het is het meest onderschatte lek in de hele keten: alles wat Claude in je repo las, staat leesbaar in je thuismap. Op een laptop met volledige schijfversleuteling en een goed wachtwoord is dat prima. In een gedeelde back-up naar een cloudmap is het dat niet.

Drie dingen die je vandaag kunt regelen

Zet cleanupPeriodDays op een termijn die past bij je werk, in plaats van de standaard 30. Zorg dat je schijf versleuteld is, want dat is de enige echte bescherming van die transcripts. En sluit ~/.claude/ uit van back-ups die naar een plek gaan waar je klantcode niet hoort te staan.

Training

Traint Anthropic op jouw code?

Het antwoord hangt volledig af van het type account waarmee je bent ingelogd, en niet van het feit dat je Claude Code gebruikt. Dit is de vraag waar bureaus en zzp'ers met klantcode het vaakst op struikelen.

Op een persoonlijk account ligt de keuze bij jou

Werk je met Free, Pro of Max, dan bepaal jij of Anthropic je gegevens mag gebruiken om toekomstige modellen te verbeteren. Die instelling staat op claude.ai/settings/data-privacy-controls en geldt ook voor je gebruik van Claude Code vanaf dat account. Zet je hem aan, dan geldt een bewaartermijn van vijf jaar. Zet je hem uit, dan is het dertig dagen.

Zakelijke accounts worden niet getraind

Bij Team, Enterprise, de API, platforms van derden en Claude Gov traint Anthropic niet op je code of je prompts. De uitzondering is een expliciete opt-in door de klant zelf, bijvoorbeeld via het Development Partner Program. Dat is een bewuste handeling van je organisatie, geen standaardstand. Wat dat programma precies inhoudt en wat er tegenover staat, staat niet in de documentatie die wij hebben gelezen; check dat bij Anthropic voordat iemand tekent.

Twee privacybeleiden, en je account bepaalt welke geldt

Anthropic splitst het beleid bewust in twee documenten: één voor de consumentenproducten (Free, Pro en Max) en één voor de commerciële producten (Claude for Work, de Anthropic API en Claude Gov). Welk beleid op jou van toepassing is, hangt niet af van welke knoppen je in Claude Code indrukt, maar van het account waarmee je bent ingelogd. Het commerciële artikel is daar ondubbelzinnig over: "By default, we will not use your inputs or outputs from our commercial products (e.g. Claude for Work, Anthropic API, Claude Gov, etc.) to train our models." Stuur je Claude Code via de API aan, dan val je onder diezelfde commerciële voorwaarden.

Op een persoonlijk account zijn er drie routes, niet één

De schakelaar is de bekendste route, maar niet de enige. Het consumentenartikel noemt er drie: je zet model improvement zelf aan in je Privacy Settings, een gesprek wordt gemarkeerd voor een safety-review, of je doet mee aan een expliciet opt-in-programma zoals de Trusted Tester. Ook aan de commerciële kant bestaat één handeling die je werk alsnog in de trainingsdata kan brengen: "If you explicitly report feedback or bugs to us (e.g. via our thumbs up/down feedback button), or otherwise choose to allow us to use your data, then we may use your chats and coding sessions to train our models." Feedback insturen is dus niet alleen een kwestie van bewaartermijn, zoals verderop bij feedback staat, maar ook van toestemming geven.

Incognito staat altijd buiten training

Eén uitzondering stelt vaak gerust: "Your Incognito chats are not used to improve Claude, even if you have enabled Model Improvement in your Privacy Settings." Incognito is wel een chatmodus op claude.ai en geen modus binnen Claude Code, dus het helpt je bij een losse vraag over een stuk code dat je plakt, niet bij een sessie waarin de agent zelf je repository leest. Laat je een terminal-agent los op de codebase van je bedrijf of je klanten, dan blijft een commercieel plan de enige echte oplossing.

De conclusie voor bureaus en freelancers

Schrijf je code voor klanten op een persoonlijk Pro-account met de trainingsschakelaar aan, dan is dat het slechtste van twee werelden: je klantcode kan worden gebruikt om modellen te verbeteren en blijft vijf jaar staan. De eenvoudigste oplossing is niet een discussie over de schakelaar, maar een Team-abonnement. Daar is niet trainen de standaard en heb je een zakelijke overeenkomst waar je in een audit naar kunt wijzen. Het bredere kader staat op privacy en zakelijk gebruik.

Retentie

Bewaartermijnen: dertig dagen, vijf jaar of nul

Drie regimes, en je zit vrijwel altijd in het eerste. Weten in welk regime je zit, is het halve werk van een verwerkingsregister.

Dertig dagen is de standaard

Voor zakelijke accounts (Team, Enterprise en de API) geldt standaard een bewaartermijn van dertig dagen. Voor persoonlijke accounts zonder trainings-opt-in geldt hetzelfde. Dat is de situatie waar de meeste teams in zitten zonder er iets voor te doen.

Vijf jaar als je opt-int

Zet je op een persoonlijk account de trainingsschakelaar aan, dan springt de bewaartermijn naar vijf jaar. Dat is geen straf maar logica: gegevens die worden gebruikt om modellen te verbeteren, moeten langer beschikbaar blijven. Het is wel een groot verschil om te weten voordat je die knop omzet in een repo met klantwerk.

Nul, maar alleen op aanvraag

Zero Data Retention bestaat, maar staat niet standaard aan bij Enterprise. Het is beschikbaar voor gekwalificeerde Claude for Enterprise-accounts en wordt per organisatie geactiveerd door het accountteam van Anthropic. Wie een aanbesteding of een DPIA voor zich heeft waarin nul retentie als eis staat, moet dat dus expliciet regelen. Let op de consequentie verderop: organisaties met Zero Data Retention kunnen geen cloudsessies gebruiken.

En je eigen schijf telt ook mee

Vergeet bij het opstellen van je bewaarbeleid niet dat de sessietranscripts ook lokaal staan, standaard dertig dagen. Dat is een tweede kopie op een plek waar jouw organisatie zelf verantwoordelijk voor is, niet Anthropic.

Feedback

Eén commando met een bewaartermijn van vijf jaar

Dit is het detail dat vrijwel niemand kent en dat in een zakelijke omgeving het meest kan kosten. De algemene bewaartermijn is dertig dagen, maar er is een uitzondering.

Wat er precies vijf jaar blijft staan

Transcripts die je verstuurt met /feedback, /bug of /share worden vijf jaar bewaard. Dat is geen typefout en het staat los van je abonnement of je trainingsinstelling. Vrijwillig gedeelde transcripts uit vragenlijsten worden maximaal zes maanden bewaard.

Waarom dat uitmaakt

Een feedbackcommando voelt als "even melden dat iets niet werkt". In de praktijk stuur je het gesprek mee, en dat gesprek bevat de code die op dat moment op je scherm stond. Loopt Claude vast op een bug in de betaalmodule van je klant en druk je op /bug, dan verhuist een stuk van die betaalmodule naar een systeem met een bewaartermijn van vijf jaar.

Wat je eraan doet

Maak er een afspraak van in je AI-beleid: geen feedback vanuit repo's met klantcode of persoonsgegevens. Wil je het harder afdwingen, dan zet je DISABLE_FEEDBACK_COMMAND=1 en CLAUDE_CODE_DISABLE_FEEDBACK_SURVEY=1 in je omgeving, en leg je die via managed settings vast zodat ontwikkelaars ze niet kunnen overschrijven. Werk je via Bedrock, Vertex of Foundry, dan staat het feedbackkanaal standaard al uit.

Permissies

Het permissiemodel: zes modi en waar de grens ligt

Claude Code start met strikte leesrechten en vraagt toestemming voor alles wat verandert. Hoeveel het zelfstandig mag doen, regel je met de permissiemodus. Er zijn er zes, en het verschil tussen de eerste en de laatste is enorm.

Wisselen doe je met Shift+Tab

In een lopende sessie schakel je met Shift+Tab door de modi heen. Wil je vastleggen waar een sessie in start, dan geef je --permission-mode mee op de commandoregel. Voor dagelijks werk is dit de meest waardevolle gewoonte die je kunt aanleren: begin in plan mode, lees het plan, en zet daarna pas de modus open die bij het werk past.

De paden die nooit automatisch worden vrijgegeven

Er is een lijst met beschermde paden waar schrijfacties nooit automatisch worden goedgekeurd, behalve in bypassPermissions. Daar staan onder meer .git, .claude (met uitzondering van .claude/worktrees), .vscode, .idea, .husky en .devcontainer in, plus losse bestanden als .bashrc, .zshrc, .npmrc, .mcp.json en .pre-commit-config.yaml. Belangrijk: allow-regels in je settings kunnen die bescherming niet omzeilen. Het is precies de lijst met bestanden waarmee een aanvaller anders je hele omgeving zou kunnen kapen.

De modus met de waarschuwing erbij

bypassPermissions (bekend als --dangerously-skip-permissions) slaat prompts én veiligheidschecks over. De officiële instructie is ondubbelzinnig: gebruik dit alleen in een geïsoleerde container of VM zonder internettoegang, en verwacht geen bescherming tegen prompt injection. Op Linux en macOS weigert Claude Code de modus als je root of sudo gebruikt, en rm -rf op je root- of thuismap vraagt altijd om bevestiging als laatste noodrem. Beheerders zetten de modus helemaal uit met disableBypassPermissionsMode.

Controleer je eigen regels

Allow-regels stapelen zich op zonder dat je het merkt: één keer "altijd toestaan" klikken bij een commando en het staat er voorgoed in. Loop je regels periodiek na met /permissions en gooi weg wat je niet meer herkent. Dat is de goedkoopste beveiligingsmaatregel in deze hele gids.

Auto mode

Auto mode: wat de classifier tegenhoudt, en wat het kost

Auto mode is de modus waarin Claude doorwerkt zonder je om routinegoedkeuring te vragen. Anders dan bypassPermissions is het geen vrijbrief: er zit een aparte beoordelaar tussen.

Een tweede model kijkt mee

Elke actie wordt vooraf beoordeeld door een aparte classifier, standaard Claude Sonnet 5. Die kijkt niet naar of het werk goed is, maar of het gevaarlijk is. Geblokkeerd worden onder meer: scripts binnenhalen en direct uitvoeren via curl naar de shell, force pushes, deploys naar productie, het naar buiten sturen van secrets, terraform destroy en het mergen van pull requests die geen mens heeft goedgekeurd.

De ingebouwde rem

Blokkeert de classifier drie keer achter elkaar, of twintig keer in totaal, dan pauzeert auto mode zichzelf en komen de gewone prompts terug. Dat is een fijn signaal om serieus te nemen: als Claude in korte tijd drie keer tegen een muur loopt, klopt er iets niet aan de opdracht of aan de omgeving.

Het kost tokens

De aanroepen van de classifier tellen mee in je tokenverbruik. Auto mode is dus niet alleen losser, maar ook duurder dan handmatig goedkeuren. Wie zich afvraagt waarom het gebruikstegoed sneller op is dan verwacht, heeft hier vaak een deel van het antwoord.

De combinatie die het beste werkt

Plan mode en auto mode zijn elkaars natuurlijke paar. Je laat Claude eerst read-only onderzoek doen en een plan opstellen. Bij het goedkeuren kies je dan bewust: doorgaan met auto mode, of edits handmatig goedkeuren. Je leest dan precies één keer aandachtig, op het moment dat het uitmaakt. Beheerders die deze modus organisatiebreed willen uitsluiten, gebruiken disableAutoMode in managed settings.

Sandbox

De Bash-sandbox: hoe commando's worden ingeperkt

Naast het permissiemodel zit er een tweede laag: shellcommando's kunnen op besturingssysteemniveau worden opgesloten. Dat is een andere soort bescherming, want die werkt ook als Claude iets probeert wat jij per ongeluk hebt goedgekeurd.

Hoe het technisch werkt

Op macOS gebruikt Claude Code Seatbelt, op Linux en WSL2 bubblewrap in combinatie met socat. Native Windows wordt niet ondersteund. Je zet het op met het /sandbox-commando. Standaard mag een commando in de sandbox alleen schrijven in je werkdirectory en in de tijdelijke map van de sessie, en die grens geldt ook voor alle processen die het commando zelf start. Een buildscript dat een ander script aanroept, komt er dus niet onderuit.

Netwerk gaat via een proxy, standaard dicht

Netwerktoegang van de sandbox loopt via een proxy die buiten de sandbox draait. Standaard is geen enkel domein toegestaan en vraagt Claude Code per nieuw domein om goedkeuring. Wil je dat voor zijn, dan zet je de domeinen die je vertrouwt vooraf in sandbox.network.allowedDomains. Dat is het moment om zuinig te zijn met wat je toevoegt.

Auto-allow en de escape hatch

In auto-allow mode draaien commando's die in de sandbox passen zonder dat je iets hoeft te bevestigen. Dat maakt de combinatie sandbox plus auto-allow praktisch werkbaar. Er bestaat een uitweg om een commando bewust buiten de sandbox te draaien (dangerouslyDisableSandbox), en die uitweg kan een organisatie dichtzetten met allowUnsandboxedCommands: false.

De grenzen

Wat de sandbox niet tegenhoudt

Anthropic is hier opvallend open over, en die eerlijkheid verdient het om doorgegeven te worden in plaats van weggelaten. De documentatie noemt sandboxing zelf risicoreductie, geen volledige isolatiegrens.

Domain fronting: de belangrijkste beperking

De proxy beslist op basis van de hostname die de client zelf opgeeft, en inspecteert standaard geen TLS-verkeer. Code die in de sandbox draait kan daardoor via domain fronting mogelijk hosts bereiken die niet op je toestemmingslijst staan. In gewone taal: de deurwachter gelooft wat er op het naamkaartje staat en kijkt niet in de tas.

Brede domeinen zijn een uitgang

De docs waarschuwen er expliciet voor: iets breeds als github.com toestaan kan een pad naar buiten creëren voor gegevens die niet naar buiten horen. Iedereen kan daar immers naartoe schrijven. Hoe smaller je lijst, hoe meer die lijst waard is.

Je sleutels blijven standaard leesbaar

Dit verrast veel mensen: standaard kan een commando in de sandbox nog steeds credentialbestanden lezen, bijvoorbeeld in ~/.ssh. Wil je dat niet, dan moet je dat zelf regelen met sandbox.credentials of met denyRead-regels. Doe dat, en doe het meteen: dit is een van de weinige instellingen die het verschil maakt tussen "ongemakkelijk" en "onherstelbaar".

Wat dit betekent voor risicovol werk

Voor werk waarbij Claude onbekende externe bronnen leest, is de sandbox een goede extra laag maar geen garantie. De officiële aanbeveling voor dat soort werk is een aparte VM of dev container. Combineer dat met de vuistregel uit het permissiehoofdstuk: laat Claude niet tegelijk onbetrouwbare inhoud lezen én schrijfrechten hebben op iets dat pijn doet.

Telemetrie

Telemetrie uitzetten: de variabelen op een rij

Claude Code stuurt standaard een aantal signalen terug naar Anthropic die los staan van je gesprekken. Ze zijn allemaal uit te zetten, en dit zijn de exacte namen. Zet ze in je omgeving of in je settings, en leg ze via managed settings vast als je het organisatiebreed wilt regelen.

Wanneer foutrapportage überhaupt aanstaat

Foutrapportage staat alleen standaard aan als alle vier deze voorwaarden gelden: je bent ingelogd met Claude Pro of Max, je draait Claude Code v2.1.198 of nieuwer, je hebt een directe verbinding met de Claude API, en er ligt geen Zero Data Retention- of HIPAA-overeenkomst. Valt één daarvan weg, dan staat het al uit. Voordat er iets wordt verstuurd, redigeert Claude Code bekende patronen van secrets, paden en e-mailadressen.

Via Bedrock, Vertex of Foundry staat het al uit

Werk je via Amazon Bedrock, Google Vertex AI of Microsoft Foundry, dan staan telemetrie, foutrapportage en het feedbackkanaal standaard uit. Dat is een van de redenen dat organisaties met strenge eisen die route kiezen, los van de vraag waar het model draait.

Leg het vast in plaats van te vragen

Variabelen in managed settings hebben voorrang op alles wat een gebruiker zelf instelt en zijn niet lokaal te overschrijven. Een beleidsregel die je niet kunt afdwingen, is geen beleid. Zie de sectie over managed settings verderop voor waar dat bestand staat.

De uitzondering

Waarom Claude Code ook zonder telemetrie contact maakt

Er is één verzoek dat overblijft, ook als je alles hierboven uitzet. Het is klein, het is verdedigbaar, en je moet het weten voordat iemand het in een netwerklog ontdekt en er vragen over stelt.

De hostnamecheck vóór elke WebFetch

Voordat Claude Code een webpagina ophaalt, stuurt het alleen de hostname naar api.anthropic.com voor een controle tegen een veiligheidsblocklist. Niet de volledige URL, niet de inhoud van de pagina, en niet je prompt. Dit gebeurt ongeacht welke provider je gebruikt, dus ook via Bedrock, Vertex of Foundry.

Deze valt buiten de grote schakelaar

Dit verzoek wordt niet uitgeschakeld door CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC. De enige manier om het uit te zetten is skipWebFetchPreflight: true in je settings. Dat staat er expliciet zo in de documentatie, en het is precies het soort detail waar een security-audit over valt als je het niet hebt gedocumenteerd.

Zou je het uitzetten?

Meestal niet. Je ruilt dan een minimale gegevensstroom (een domeinnaam) in voor het verlies van een blocklist die bedoeld is om kwaadaardige sites tegen te houden, terwijl webinhoud juist het grootste kanaal voor prompt injection is. Zit je in een omgeving waar geen enkel verzoek naar Anthropic mag, dan zet je hem uit én zet je WebFetch zelf op slot via je permissieregels. Half werk is hier het slechtste van beide.

Voor bedrijven

Managed settings: wat je als organisatie kunt afdwingen

Alles hierboven is een instelling die een ontwikkelaar zelf kan wijzigen. Managed settings zijn het niveau daarboven: beleid dat lokaal niet te overschrijven is. Dit is het antwoord op de vraag "hoe weet ik zeker dat iedereen zich eraan houdt".

Uitrollen kan ook zonder handmatig bestand

Naast het bestand op schijf kun je beleid uitrollen via MDM (op macOS met com.anthropic.claudecode, op Windows via het register) en server-managed vanuit de admin console op claude.ai. Voor een team van vijf is het bestand prima. Voor honderd machines wil je MDM of de admin console.

De volgorde bij conflicten

Als instellingen elkaar tegenspreken, geldt deze rangorde van hoog naar laag: managed settings, dan argumenten op de commandoregel, dan .claude/settings.local.json, dan .claude/settings.json, en als laatste ~/.claude/settings.json. Managed wint dus altijd, ook van een vlag die iemand meegeeft bij het starten.

De knoppen die het meest uitmaken

Voor privacy en beveiliging zijn dit de instellingen die je wilt kennen: allowedMcpServers en deniedMcpServers (welke MCP-servers zijn toegestaan), allowManagedPermissionRulesOnly (ontwikkelaars kunnen geen eigen permissieregels toevoegen), allowManagedHooksOnly (blokkeert user-, project- en plugin-hooks), disableAutoMode, disableBypassPermissionsMode, disableRemoteControl, availableModels (een lijst met toegestane modellen), forceLoginOrgUUID (alleen inloggen met een account van jouw organisatie) en claudeMd (een organisatiebrede CLAUDE.md met je eigen regels).

Sandboxing afdwingen

Wil je dat er niets buiten de sandbox draait, dan zet je sandbox.enabled: true en failIfUnavailable: true, zodat Claude Code weigert te starten als de sandbox niet beschikbaar is. Met allowUnsandboxedCommands: false haal je de uitweg weg, en met allowManagedDomainsOnly en allowManagedReadPathsOnly voorkom je dat ontwikkelaars de domeinlijst of leesrechten oprekken.

Let op de stille correctie

Zet je een instelling verkeerd in het beleidsbestand, dan wordt die entry gestript met een waarschuwing en blijft de rest van je policy gewoon gelden. Dat is prettig voor de beschikbaarheid en riskant voor je aannames: je denkt dat iets geregeld is terwijl het eruit is gehaald. Controleer je beleid dus na elke wijziging op een testmachine voordat je het uitrolt.

Monitoring

OpenTelemetry: wat je werkgever kan zien

Deze sectie is voor twee lezers tegelijk. Voor beheerders die moeten kunnen aantonen wat er gebeurt, en voor ontwikkelaars die willen weten wat er meekijkt. De eerlijke samenvatting: pas als iemand het bewust aanzet, en dan kun je nog kiezen hoe ver het gaat.

Het staat uit tot je het aanzet

Bedrijfsmonitoring loopt via OpenTelemetry en begint met CLAUDE_CODE_ENABLE_TELEMETRY=1. Daarna exporteert Claude Code naar OTLP, Prometheus of je console. Dit staat los van de telemetrie naar Anthropic uit de vorige sectie: dit gaat naar jouw eigen systemen.

Wat er dan gemeten wordt

Aan metrics krijg je onder meer claude_code.token.usage, cost.usage in dollars, lines_of_code.count en session.count. Aan gebeurtenissen krijg je onder meer user_prompt, tool_decision en api_request. Daarmee kun je kosten toewijzen, gebruik volgen en zien welke tools worden goedgekeurd of geweigerd.

De knop waar het echt om draait

De inhoud van prompts wordt standaard geredigeerd. Met OTEL_LOG_USER_PROMPTS=1 neemt de organisatie die inhoud wél op. Dat is de grens tussen "we meten gebruik" en "we lezen mee". Zet je die om, dan verwerk je personeelsgegevens en moet je vastleggen waarom, en je mensen erover informeren. Het bredere kader daarvoor staat op privacy en zakelijk gebruik.

Niet te omzeilen door de gebruiker

Zet je deze variabelen via managed settings, dan hebben ze voorrang en kan een gebruiker ze lokaal niet uitzetten. Dat is precies wat je wilt als beheerder, en precies wat medewerkers moeten weten. Wees er dan ook open over: monitoring die niemand kent, kost je later meer vertrouwen dan ze aan inzicht oplevert.

Prompt injection

Prompt injection, MCP-servers en derden in je permissiemodel

Het grootste restrisico bij een agent die zelf commando's uitvoert, is niet dat het model iets doms doet. Het is dat iemand anders het via de inhoud die het leest iets laat doen. Anthropic bouwt daar veel tegen, en zegt er zelf bij dat geen enkel systeem volledig immuun is.

Wat er ingebouwd zit

Het permissiesysteem voor gevoelige acties, aparte contextvensters voor opgehaalde webinhoud, detectie van command injection (verdachte bash-commando's vragen om handmatige goedkeuring, ook als je ze eerder had toegestaan), fail-closed matching bij regels, een vertrouwenscheck bij de eerste keer dat je Claude Code in een codebase draait en bij elke nieuwe MCP-server, en netwerkcommando's als curl en wget die nooit automatisch worden goedgekeurd.

MCP-servers zijn geen gecontroleerde app-store

De officiële waarschuwing is duidelijk: verifieer dat je een MCP-server vertrouwt voordat je verbindt, en besef dat servers die externe content ophalen een injectierisico vormen. Anthropic beoordeelt connectors in de Directory tegen listingcriteria, maar voert daarop geen beveiligingsaudit uit. Dat verschil is groot genoeg om in je beleid vast te leggen. Hoe MCP werkt en wat je ermee kunt, staat op skills en MCP en in de functies van Claude Code.

Een gekloonde repo kan zichzelf niet vertrouwen

MCP-servers uit een .mcp.json in de repo vragen expliciet om jouw goedkeuring. Sinds v2.1.196 is dat dichtgetimmerd: een gekloonde repo kan zijn eigen servers niet goedkeuren, want enableAllProjectMcpServers in een meegecommitte .claude/settings.json wordt genegeerd in een map die je nog niet hebt vertrouwd. Dat is een klein zinnetje met grote waarde: het sluit de aanval waarbij je een repo kloont en er ongemerkt een server meestart.

De vuistregel die overblijft

Zorg dat de twee voorwaarden voor een aanval niet tegelijk waar zijn. Laat Claude ofwel onbekende externe inhoud lezen, ofwel schrijfrechten hebben op iets dat pijn doet, maar niet allebei in dezelfde sessie. Pipe nooit onbetrouwbare inhoud rechtstreeks naar Claude, lees voorgestelde wijzigingen voordat je goedkeurt, en gebruik een wegwerp-VM voor werk met externe webdiensten.

Cloudsessies

Cloudsessies: waar je code draait als je niet lokaal werkt

Claude Code op het web draait niet op jouw machine maar op een virtuele machine bij Anthropic. Dat verandert je privacyplaatje, en het is beter afgeschermd dan veel mensen aannemen. Op één punt na, en dat is precies het punt waar Nederlandse organisaties naar vragen.

Voor wie het beschikbaar is

Claude Code op claude.ai/code is een research preview voor Pro, Max en Team, en voor Enterprise met premium seats of met Chat plus Claude Code-seats. Sessies draaien door als je je browser sluit en zijn te volgen vanuit de mobiele app.

Hoe het is afgeschermd

Elke sessie krijgt een eigen geïsoleerde VM die Anthropic beheert. Netwerktoegang is standaard beperkt en kan helemaal uit. Je git-credentials en signing keys komen nooit in de sandbox terecht: authenticatie loopt via een beveiligde proxy met beperkte rechten. Een push kan alleen naar de branch waaraan wordt gewerkt. Alle operaties worden gelogd voor audit, en VM's die stilstaan worden opgeruimd.

De uitsluiting die je moet kennen

Organisaties met Zero Data Retention kunnen geen cloudsessies gebruiken. Dat is logisch (een sessie op een beheerde VM valt niet te rijmen met nul retentie) maar het betekent wel dat je die twee wensen niet allebei kunt hebben. Kies bewust welke van de twee zwaarder weegt.

Het open punt: dataresidentie

In welke regio's die VM's draaien, staat niet in de documentatie die wij hebben gelezen. Voor een organisatie met harde eisen over verwerking binnen de EU is dat geen detail. Vraag het na bij Anthropic of kies voor lokaal werken via een EU-regio bij Bedrock of Vertex. Wij vermelden het liever als open punt dan dat we er een geruststellend antwoord van maken.

En let op automatisering die reageert op comments

Laat je Claude via de GitHub-integratie reageren op pull requests, houd er dan rekening mee dat die reacties onder jouw GitHub-account verschijnen (herkenbaar gelabeld) en dat ze automatisering kunnen activeren die op comments reageert. Dat is documentatie van Anthropic zelf, en het is precies het soort onbedoelde kettingreactie waar je in een release-proces geen zin in hebt.

AVG

Het AVG-kader voor Nederlandse teams

De Europese diensten van Claude worden geleverd door Anthropic Ireland Limited. Voor Claude Code gelden dezelfde regels als voor de rest van Claude, met één verzwaring: je stuurt hier geen losse vragen maar je broncode, en die bevat vaker persoonsgegevens dan mensen denken (testdata, migratiescripts, logbestanden, seeds).

Claude Code zit in je abonnement

Je hebt geen apart product nodig: Claude Code zit in Pro, Max, Team en Enterprise. Een Team-abonnement kan vanaf twee gebruikers en loopt tot 150. Dit zijn de bedragen zoals claude.com/pricing ze vanuit Nederland toont; kijk je vanuit een ander land, dan kan de valuta afwijken.

Via de API reken je in dollars

Kies je de API-route in plaats van een abonnement, dan betaal je per token in dollars. Per miljoen invoer- en uitvoertokens: Fable 5 kost $10 en $50, Opus 5 kost $5 en $25, Sonnet 5 kost $2 en $10 als introductieprijs tot en met 31 augustus 2026 en daarna $3 en $15, en Haiku 4.5 kost $1 en $5. Batchverwerking scheelt 50 procent. Voor een team met wisselend gebruik is dat vaak duurder dan het lijkt, maar het geeft je wel de meeste controle over waar het verkeer heen gaat.

De vier dingen die je moet vastleggen

Welk accounttype je gebruikt en dus welk trainingsbeleid geldt. Welke bewaartermijn er staat, inclusief de vijf jaar voor feedbacktranscripts en de lokale kopie op de laptops van je mensen. Welke provider je gebruikt en waar die het verkeer verwerkt. En of je monitoring aanstaat, want dat is verwerking van personeelsgegevens. Het volledige verhaal over verwerkersovereenkomst, certificeringen en Europese verwerking staat op privacy en zakelijk gebruik.

Praktisch advies voor code met persoonsgegevens

Behandel je repo niet als één blok. Werk je aan een module met echte klantdata in de fixtures, zet die dan buiten bereik met denyRead-regels in plaats van te vertrouwen op de belofte dat Claude er niet in kijkt. Het is een van de weinige maatregelen die werkt zonder dat iemand hoeft op te letten.

Governance

Shadow AI: het risico dat niet in je instellingen zichtbaar is

Alles op deze pagina gaat ervan uit dat je weet met welke accounts je mensen werken. Precies daar zit in de praktijk het gat. Een ontwikkelaar heeft Claude Code in tien minuten draaien en logt in met een persoonlijk account, buiten IT en buiten inkoop om. Dan is je permissiemodel niet het probleem, maar het feit dat je niet weet onder welk beleid je code valt.

Waarom dit meer is dan een inkoopkwestie

Bij shadow AI koppelen medewerkers ongecontroleerd hun eigen account aan bedrijfscode. Het verschil met gewone schaduw-IT is dat het antwoord op "wordt er op onze code getraind?" per account anders uitvalt: op een persoonlijk plan ligt die keuze bij de individuele gebruiker, op Team en Enterprise bij je organisatie. Zolang je niet weet wie op welk account werkt, kun je die vraag in een audit of een DPIA niet beantwoorden. Centrale inkoop van zitjes lost dat in één keer op, en is meestal ook goedkoper dan losse abonnementen die mensen achteraf declareren.

Drie afspraken die het meeste opleveren

Eén: een Team- of Enterprise-plek is de norm voor iedereen die met bedrijfs- of klantcode werkt, en persoonlijke Pro-accounts blijven daarbuiten. Twee: leg de afspraken vast op de plek waar mensen ze tijdens het werk tegenkomen, dus in een gedeelde CLAUDE.md en in managed settings, niet in een beleidsdocument dat niemand opent. Drie: met forceLoginOrgUUID dwing je af dat Claude Code alleen werkt met een account van jouw organisatie. Dat is de snelste technische rem op shadow AI die je hebt.

Waar dit in je AI-governance thuishoort

Het patroon van deze hele pagina, veilig als standaard en risico pas na een bewuste keuze, is precies de houding die je in je eigen AI-governance wilt verankeren. Leg naast het accountbeleid vast wat een agent zelfstandig mag: welke permissiemodus de norm is, of sandboxing verplicht is en welke MCP-servers zijn toegestaan. Dat zijn de drie knoppen die bepalen hoeveel schade een verkeerde beslissing kan aanrichten.

Checklist

Claude Code dichtzetten in tien stappen

Alles van deze pagina, in de volgorde waarin je het het beste doet. Dit is de lijst die je aan een nieuwe collega geeft, of afvinkt voordat je Claude Code op een klantproject loslaat.

Wat je hiermee wint

Deze tien stappen kosten je ongeveer een half uur en halen de drie grootste risico's weg: code die in trainingsdata belandt, sleutels die leesbaar blijven voor een commando dat je niet las, en een bewaartermijn van vijf jaar die je per ongeluk aanzet met één commando. De rest van de beveiliging is gedrag, en dat leer je het snelst door het samen een keer te doen. Daar is onze Claude Code-training voor gemaakt.