Claude Code veilig uitvoeren op een server

Wat het veilig uitvoeren van Claude Code op een server inhoudt

Om Claude Code veilig op een server uit te voeren, moet u de toestemmingsvragen ingeschakeld laten, het programma uitvoeren als een toegewezen gebruiker zonder privileges, en onbeheerde runs voorzien van een echte grens in plaats van vertrouwen: de ingebouwde sandbox, een container of een wegwerpbare VPS die geen gevoelige gegevens bevat. De --dangerously-skip-permissions-vlag verwijdert de goedkeuringsstap tussen het model en uw shell. Die afweging kan redelijk zijn voor onbeheerd werk, maar alleen binnen een grens die beperkt wat één foutief commando kan bereiken. Deze handleiding legt uit wat de vlag daadwerkelijk wijzigt en hoe u die grens opbouwt in stappen van toenemende isolatie.

Wat Claude Code op uw systeem kan doen

Claude Code is een coding-agent die in uw terminal draait. De tool leest bestanden, schrijft bestanden en voert shell-commando's uit als de gebruiker die de tool heeft gestart. Dat is de volledige waarde van de tool: het kan een repository klonen, code bewerken, tests uitvoeren, de foutmelding lezen en de code in een lus herstellen, zonder dat u elk commando zelf hoeft te typen. Als u de tool nog niet op een server heeft ingesteld, behandelt Claude Code draaien op een VPS met tmux de installatie en het sessiebeheer. Deze pagina behandelt de bevoegdheden die u de tool geeft zodra deze actief is.

Het risico is hetzelfde als wanneer u deze zin voor de tweede keer leest. Een proces dat shell-commando's uitvoert als uw gebruiker, kan alles doen wat uw gebruiker kan doen. Het kan ~/.ssh/id_ed25519, ~/.aws/credentials en elk .env-bestand lezen dat uw gebruiker kan openen. Het kan curl uitvoeren en gegevens versturen naar elke host die de server kan bereiken. Het kan git push --force uitvoeren. De agent heeft geen eigen motieven. Het gevaar is dat een taak misloopt, of dat tekst die de agent tijdens het werk las, instructies bevatte die door iemand anders waren geschreven: een webpagina die de agent ophaalde, of een opmerking in een issue dat de agent moest oplossen. Dat tweede geval wordt prompt injection genoemd, en dat is de reden waarom "het model is meestal verstandig" geen beveiligingsplan is. Instructies kunnen ook dichter bij huis vandaan komen, omdat twee Claude Code-sessies op hetzelfde systeem tekst naar elkaar kunnen sturen, en een bericht van een zustersessie is simpelweg meer tekst die de ontvangende agent leest. U plant voor de foutieve uitvoering, niet voor de gemiddelde.

Het permissiesysteem in begrijpelijke taal

In de Manual-modus vraagt Claude Code om toestemming voordat er actie wordt ondernomen. Het lezen van bestanden binnen het project gebeurt geruisloos, maar bij het bewerken van een bestand of het uitvoeren van een shell-commando krijgt u eerst de exacte wijziging of het commando te zien en wordt er gewacht op een bevestiging. U kunt één actie goedkeuren of aangeven dat er niet opnieuw gevraagd hoeft te worden. Die tweede keuze geldt voor bestandsbewerkingen tot het einde van de sessie, maar voor een shell-commando wordt dit permanent opgeslagen voor die repository en dat commando; een snelle bevestiging op een server blijft dus langer geldig dan de sessie zelf. Voor regels die u bewust wilt behouden, bevat het instellingenbestand persistente lijsten voor toestaan (allow), vragen (ask) en weigeren (deny). Bijvoorbeeld: toestaan van git status, vragen bij git push, weigeren van het lezen van .env. Weigeringsregels hebben altijd voorrang. Deze basislijn is ook veranderd. De Auto-modus, waarbij een classifier in plaats van u de acties beoordeelt, werd op 14 augustus 2026 de standaard voor nieuwe sessies op Pro-, Max- en Team-abonnementen. Vanaf Claude Code v2.1.283 is dit de ingebouwde startmodus voor interactieve terminal- en VS Code-sessies op elk abonnement, tenzij u een standaardmodus heeft vastgezet. Het is daarom de moeite waard om te weten wat elke permissiemodus daadwerkelijk toestaat voordat u beslist welke modus een server die u niet kunt monitoren moet draaien.

Dit ontwerp gaat ervan uit dat een mens de terminal in de gaten houdt, wat op een laptop klopt. Op een server is het punt vaak juist dat er niemand meekijkt. U start een langdurige taak binnen tmux en gaat slapen; een agent die om 02:00 uur stopt om een vraag te stellen, boekt tot de ochtend geen vooruitgang. Deze pauze kost zowel geld als tijd, omdat een inactieve Claude Code-sessie de warme prompt-cache verliest en de volgende interactie moet betalen voor het opnieuw opbouwen daarvan. Dat is de eerlijke reden waarom mensen op servers naar de skip-vlag grijpen, en het probleem dat dit oplost is reëel. De rest van deze handleiding gaat over het oplossen hiervan zonder alle veiligheidsmaatregelen op te geven.

Wat --dangerously-skip-permissions wijzigt

claude --dangerously-skip-permissions schakelt de goedkeuringsstap uit. Bewerkingen worden uitgevoerd zonder prompt. Shell-commando's worden uitgevoerd zonder prompt. De controles op beschermde paden die normaal gesproken gevoelige locaties beveiligen, worden eveneens overgeslagen. Uw expliciete weigeringsregels blijven van kracht en een paar extreme acties vereisen nog steeds een bevestiging, maar de samenvatting is simpel: alles wat het model besluit uit te voeren, wordt uitgevoerd.

Twee feiten over deze flag zijn van belang op een server. Ten eerste is deze geblokkeerd wanneer Claude Code wordt uitgevoerd als root of onder sudo op Linux en macOS, omdat root zonder prompts elk bestand of elke service op de machine kan wijzigen. De agent heeft sowieso een eigen account zonder privileges nodig, en de flag dwingt dit af. Ten tweede verandert de flag het gedrag van het model op geen enkele wijze. Het verwijdert de mens uit de lus en verandert verder niets, waardoor elke fout die door een prompt zou zijn opgemerkt, nu direct wordt uitgevoerd.

Dit is de eerlijke afweging. Als u permissies overslaat, verandert de beveiligingsvraag van "zal de agent iets schadelijks doen" naar "hoeveel schade kan één verkeerde actie aanrichten". U stopt met het proberen te controleren van elke beslissing en begint met het beheersen van de impact. Inperking is het antwoord, en dit gebeurt in stappen.

De ingebouwde Claude Code sandbox

Voordat u de onderstaande stappen doorloopt, is het belangrijk te weten dat Claude Code nu een sandbox op OS-niveau bevat voor de opdrachten die het uitvoert. Dit neemt de meeste redenen weg waarom gebruikers voorheen de skip-vlag gebruikten. Op Linux gebruikt het bubblewrap voor bestandssysteemisolatie, aangevuld met socat om netwerkverkeer via een proxy te leiden. Binnen de sandbox kan een opdracht alleen schrijven naar de projectmap en een tijdelijke sessiemap. Het netwerk is alleen toegankelijk via een proxy die elk domein toetst aan een toegestane lijst. De eerste keer dat een opdracht een nieuw domein aanvraagt, vraagt Claude Code u om toestemming; in de auto-modus beoordeelt de classifier de nieuwe host in plaats daarvan.

Schakel dit in met de /sandbox opdracht binnen een sessie. Installeer op Ubuntu en Debian eerst de twee benodigde pakketten:

sudo apt install bubblewrap socat

Op Ubuntu 24.04 en later voorkomt het standaard AppArmor-beleid dat bubblewrap de benodigde user namespaces aanmaakt. Het sandbox-paneel geeft aan wanneer er iets ontbreekt en de documentatie over Claude Code sandboxing bevat het korte AppArmor-profiel dat dit verhelpt.

De sandbox beschikt over een auto-allow modus: gesandboxte opdrachten worden uitgevoerd zonder enige prompt, omdat de afgedwongen grens nu het werk doet waar de prompt voorheen voor diende. Opdrachten die niet binnen de sandbox kunnen draaien, vallen terug op de normale toestemmingsprocedure, waardoor er bij werkelijk ongebruikelijke acties nog steeds om bevestiging wordt gevraagd. Voor de meeste serverworkflows is dit de juiste vervanging voor de skip-vlag, omdat u met een door het OS afgedwongen grens veel minder vragen krijgt in plaats van helemaal geen.

Wees u bewust van de beperkingen. Standaard kan een gesandboxte opdracht nog steeds het grootste deel van het bestandssysteem lezen, inclusief inloggegevens, tenzij u die paden blokkeert; de sandbox.credentials instelling is precies hiervoor bedoeld. De netwerkproxy controleert domeinnamen en inspecteert het verkeer zelf niet, dus een ruime toelating zoals github.com biedt nog steeds ruimte om gegevens naar buiten te sturen. Docker werkt niet binnen de sandbox. De sandbox verhoogt het beveiligingsniveau aanzienlijk. Het is geen volledige isolatiegrens, en daarom blijven de onderstaande stappen relevant.

De isolatieladder

Drie treden, in oplopende mate van isolatie. Kies de laagste trede die past bij wat er nog meer op de server draait.

Trede 1: een toegewezen gebruiker zonder privileges. De agent krijgt een eigen account, een eigen home-directory, een eigen projectmap en geen sudo-rechten:

sudo adduser --disabled-password --gecos "" agent

De accountgrens houdt de agent weg bij uw bestanden: uw SSH-keys en elk ander project op de machine. Het maakt ook het gebruik van de skip-vlag mogelijk, aangezien de vlag weigert te draaien als root. Dit is hetzelfde principe als elke service draaien als een gebruiker zonder privileges, toegepast op een agent. Wat trede 1 niet begrenst: het netwerk en alles op de machine dat voor iedereen leesbaar is.

Trede 2: een container. Anthropic publiceert een referentie-devcontainer die Claude Code uitvoert als een niet-rootgebruiker, met firewallregels die beperken welke hosts de agent kan bereiken; een container die u zelf bouwt, doet hetzelfde. Het bestandssysteem krimpt tot de volumes die u koppelt, en uitgaand verkeer wordt beperkt tot wat de regels van de container toestaan. Dit is de juiste middelste trede wanneer de server andere services host die voor u van belang zijn. De beperking is dat containers de kernel van de host delen, en één onvoorzichtige mount heft de grens op; geef de container /var/run/docker.sock en deze kan de gehele host bereiken.

Trede 3: een toegewezen VPS. De sterkste trede is de meest botte: geef de agent een volledige machine waar niets op staat dat voor u van belang is. Een kleine VPS kost een paar dollar per maand. Richt deze in met de runbook voor de eerste tien minuten op een nieuwe VPS, maak een snapshot van de schone status en laat de agent zijn werk doen. Er draait niets anders. Geen persoonlijke SSH-key, alleen een deploy-key die beperkt is tot de ene repository. Geen cloud-inloggegevens, geen productiedata. Wanneer een run misgaat, of wanneer u simpelweg een schone lei wilt, herstelt u de snapshot of vernietigt en herbouwt u de machine in enkele minuten. De blast radius is de huurprijs. Dit is de opstelling waarbij --dangerously-skip-permissions niet langer beangstigend is, omdat de ergste realistische uitkomst een opnieuw opgebouwde server en één ingetrokken token is.

De treden stapelen. Een gesandboxte agent, draaiend als een gebruiker zonder privileges op een wegwerpbare VPS, kost bijna niets extra en maakt de verhalen over fouten saai. Saai is het doel.

Beveilig de inloggegevens

De regel die de basis vormt voor alle andere: de gebruiker van de agent mag geen geheimen kunnen lezen die bij andere processen horen.

Verstrek de API-sleutel uitsluitend aan de agent. Plaats deze in een bestand waarvan de agent-gebruiker de eigenaar is met modus 600, en laad het bestand bij het starten van een shell:

install -m 600 /dev/null /home/agent/claude.env
echo 'export ANTHROPIC_API_KEY=your-key-here' >> /home/agent/claude.env
echo 'source ~/claude.env' >> /home/agent/.bashrc

Sluit vervolgens de andere richting af. Op oudere Debian- en Ubuntu-installaties, en voor het account dat tijdens de installatie is aangemaakt, kunnen home-directories leesbaar zijn voor elke gebruiker op het systeem. Beperk de rechten daarom met: chmod 750 /home/youruser. Controleer dit met ls -ld /home/* en corrigeer alles wat het account van de agent kan inzien.

Beperk de reikwijdte van elk token. Een fijnmazig GitHub-token dat beperkt is tot één repository, of een deploy-key per repository, zorgt ervoor dat bij een gelekt credential slechts één project verloren gaat en niet uw volledige account. Als u de sandbox gebruikt, voeg dan de instellingen voor inloggegevens toe zodat ~/.ssh en ~/.aws zelfs voor leesacties worden geweigerd. Houd productie-credentials volledig buiten de server, want een agent kan geen geheim lekken dat niet aanwezig is. Als deze geheimen in een zelfgehoste wachtwoordmanager staan, bewaar deze dan op een andere server dan de agent en voer een eigen audit uit, aangezien de zwakke punten van Vaultwarden het admin-token en het back-upbestand zijn en niet de versleutelde kluis zelf.

Git is het vangnet

Elke wijziging die de agent doorvoert is controleerbaar en terugdraaibaar. Git biedt beide functies standaard aan als de agent op een branch werkt en gaandeweg commits maakt:

git switch -c agent/refactor-auth

Werk dat de agent niet commit, geniet deze bescherming niet: een git reset --hard verwijdert niet-gecommitteerde wijzigingen aan gevolgde bestanden, en Git dekt niets buiten de repository af. Controleer de uitvoering achteraf met git diff main...agent/refactor-auth om te zien wat er is gecommit, en gebruik daarna git status en git diff HEAD op de branch voor alles wat niet is gecommit. Merge wat bruikbaar is en verwijder de branch als de uitvoering geen resultaat opleverde. Een uitvoering die drie bestanden heeft aangepast is tijdens het ontbijt veel eenvoudiger te beoordelen dan een uitvoering die de helft van de module heeft herschreven. Dit is het praktische argument voor een vaardigheid die de agent dwingt tot de kleinst mogelijke werkende wijziging. Beveilig de main branch aan de kant van de git-server, zodat het token van de agent niet naar deze branch kan pushen en nergens een force-push kan uitvoeren. De commit-historie fungeert tevens als audit-log van wat er is gebeurd terwijl u sliep; dit is waardevoller dan welke terminal-scrollback dan ook.

Het netwerk maakt deel uit van de blast radius

Een agent kan curl uitvoeren. Die zin vormt de kern van het egress-probleem: alles wat de agent kan lezen, kan hij ook ergens naartoe sturen, en een agent die slachtoffer is van prompt-injection zou dat kunnen doen. Een standaard gebruiker zonder privileges beperkt dit op geen enkele wijze, omdat elke gebruiker alles kan bereiken wat de server kan bereiken. De sandbox begrenst dit per domein via zijn proxy. Een container kan dit begrenzen met eigen firewallregels. Een dedicated VPS beperkt wat er überhaupt gelekt kan worden, wat van deze drie de meest robuuste oplossing is.

Probeer egress niet enkel met ufw op te lossen. ufw staat standaard al het uitgaande verkeer toe, en het schrijven van uitgaande regels die nog wel apt, npm, git en de Claude API toelaten is complex werk dat ongemerkt kan falen. Kies in plaats daarvan voor de grens op sandbox-, container- of machineniveau, waar een allow-list voor domeinen of een kale machine hetzelfde werk op een schone manier doet.

Als u uw eigen agent bouwt op basis van de API in plaats van Claude Code te draaien, geldt dezelfde denkwijze ongewijzigd. Een AI-agent bouwen met Claude op een VPS behandelt dat pad, en een dergelijke agent verdient dezelfde toegewezen gebruiker, dezelfde beperkte tokens en dezelfde wegwerpomgeving.

Beveilig eerst de server

Ongeacht de gekozen methode, moet de machine zelf aan de basisvereisten voldoen voordat de agent wordt geïnstalleerd: alleen SSH-keys, geen root-login, een default-deny firewall en automatische beveiligingsupdates. Stel hier uw checklist op en werk deze één voor één af:

FAQ

Is --dangerously-skip-permissions veilig om te gebruiken op een server?

Niet op zichzelf. De flag verwijdert elke bevestigingsvraag, waardoor het eerste foutieve commando direct wordt uitgevoerd zodra het model dit genereert. Het wordt een verdedigbare afweging wanneer de blast radius wordt beperkt: minimaal door een toegewezen gebruiker zonder privileges, en voor volledig onbeheerd werk door een container of een wegwerpbare VPS die slechts één project en één specifiek token bevat. Gebruik deze optie nooit op een machine die productiegegevens of data bevat die u niet kunt verliezen.

Bevat Claude Code een sandbox?

Ja. Claude Code wordt geleverd met een ingebouwde sandbox voor shell-commando's, die wordt geopend met het /sandbox commando. Deze maakt gebruik van bubblewrap op Linux en Seatbelt op macOS, beperkt schrijfrechten tot de projectmap en leidt netwerkverkeer via een proxy die alleen goedgekeurde domeinen toestaat. De auto-allow modus voert gesandboxte commando's uit zonder vragen, waardoor onderbrekingen worden verminderd op dezelfde wijze als bij de skip-flag, terwijl een door het besturingssysteem afgedwongen grens behouden blijft. Het is geen volledige isolatiegrens, dus combineer dit met een toegewezen gebruiker of een toegewezen machine voor onbeheerde taken.

Waarom weigert de skip-flag om als root te draaien?

Omdat root zonder toestemmingsvragen elk bestand en elke service op het systeem kan wijzigen, blokkeert Claude Code --dangerously-skip-permissions wanneer het als root of onder sudo op Linux en macOS wordt uitgevoerd. De oplossing is niet om de controle te omzeilen. Maak een gebruiker zonder privileges aan voor de agent en voer deze daar uit; die accountgrens is de eerste en goedkoopste laag van beveiliging.

Kan Claude Code mijn SSH-keys en .env-bestanden lezen?

Het kan alles lezen wat de gebruiker waaronder het draait kan lezen, en zelfs het standaardbeleid van de sandbox staat het lezen van paden met inloggegevens toe totdat u dit weigert. Voer de agent daarom uit als zijn eigen gebruiker, houd uw eigen home-directory op mode 750 of strikter, weiger paden met inloggegevens in de sandbox-instellingen en houd productiegeheimen volledig van de machine af. Een geheim dat de box nooit heeft bevat, kan niet worden gelezen of gelekt.

Wat is de veiligste manier om Claude Code onbeheerd uit te voeren?

Een goedkope, toegewezen VPS die alleen voor agent-werk wordt gebruikt: in tien minuten gehard, voorzien van een schone snapshot, waarbij Claude Code draait onder een gebruiker zonder privileges met de sandbox ingeschakeld, een bestand met mode 600 dat de API-key bevat, een deploy-key per repository, en al het werk op branches die u controleert voordat u ze merkt. Als een uitvoering misgaat, trekt u één token in en herstelt u de snapshot, waardoor niets anders dat u bezit wordt aangetast.