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

Standaard vraagt Claude Code om toestemming voordat het actie onderneemt. Het lezen van bestanden binnen het project gebeurt geruisloos, maar voor 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 dat type actie voor de rest van de sessie toestaan. Deze goedkeuringen zijn sessiegebonden: zodra u de CLI afsluit, begint de volgende sessie weer in de voorzichtige modus. Voor regels die u wilt behouden, bevat het instellingenbestand persistente lijsten voor toestaan (allow), vragen (ask) en weigeren (deny). Bijvoorbeeld: sta git status toe, vraag bij git push, en weiger het lezen van .env. Weigeringsregels hebben altijd voorrang. Deze basislijn verandert, aangezien de automatische modus vanaf 14 augustus 2026 de standaard wordt. Het is daarom de moeite waard om te weten wat elke permissiemodus daadwerkelijk toestaat voordat u besluit welke modus een server die u niet kunt monitoren moet draaien.

Dit ontwerp gaat ervan uit dat er een mens naar de terminal kijkt, wat op een laptop klopt. Op een server is het punt vaak 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 voortgang. Deze pauze kost zowel tijd als geld, omdat een inactieve Claude Code-sessie zijn warme prompt-cache verliest en de volgende beurt betaalt 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 hoe u dit oplost zonder alle vangrails 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 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 maakt het gebruik van bubblewrap voor bestandssysteemisolatie, aangevuld met socat om netwerkverkeer via een proxy te routeren. 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.

Schakel dit in met de opdracht /sandbox 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: opdrachten in de sandbox 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 opdracht in de sandbox nog steeds het grootste deel van het bestandssysteem lezen, inclusief inloggegevens, tenzij u die paden blokkeert; de instelling sandbox.credentials is precies hiervoor bedoeld. De netwerkproxy controleert domeinnamen, maar inspecteert het verkeer zelf niet. Een ruime toestemming zoals github.com biedt daarom nog steeds ruimte om gegevens te versturen. Docker werkt niet binnen de sandbox. De sandbox verhoogt het beveiligingsniveau aanzienlijk. Het is geen volledige isolatiegrens, en daarom blijven de onderstaande stappen van belang.

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 alles: de gebruiker van de agent mag geen geheimen kunnen lezen die bij andere processen horen.

Geef de API-sleutel uitsluitend aan de agent. Plaats deze in een bestand dat eigendom is van de gebruiker van de agent met modus 600, en laad het bestand wanneer een shell start:

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 Debian en Ubuntu zijn home-directories vaak leesbaar voor elke gebruiker op het systeem; beperk daarom de rechten van uw eigen directory: 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 gehele account. Als u de sandbox gebruikt, voeg dan de instellingen voor credentials 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 controle uit, omdat 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, moet controleerbaar en terugdraaibaar zijn. Git biedt beide functies standaard als de agent op een aparte branch werkt:

git switch -c agent/refactor-auth

Controleer de uitvoering achteraf met git diff main...agent/refactor-auth, merge wat correct 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-provider, 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 impact beperkt blijft: minimaal een toegewezen gebruiker zonder privileges, en voor volledig onbeheerd werk een container of een tijdelijke VPS die slechts één project en één beperkt token bevat. Gebruik dit nooit op een machine die productie-inloggegevens of data bevat die u niet kunt verliezen.

Heeft 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 manier als met de skip-flag, terwijl een door het besturingssysteem afgedwongen grens behouden blijft. Het is geen volledige isolatiegrens, dus combineer het 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 wordt uitgevoerd als root of onder sudo op Linux en macOS. 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 waar de gebruiker waaronder het draait toegang toe heeft, 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 bewaar productiegeheimen helemaal niet op de machine. 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, en al uw andere bezittingen blijven onaangetast.