Claude Code und das Agent SDK sind leistungsstarke Tools, die Code ausführen, auf Dateien zugreifen und externe Dienste in Ihrem Namen nutzen können. Wie bei jedem Tool mit diesen Funktionen stellt eine durchdachte Bereitstellung sicher, dass Sie die Vorteile nutzen und gleichzeitig angemessene Kontrollen beibehalten.
Im Gegensatz zu traditioneller Software, die vordefinierten Code-Pfaden folgt, generieren diese Tools ihre Aktionen dynamisch basierend auf Kontext und Zielen. Diese Flexibilität macht sie nützlich, aber es bedeutet auch, dass ihr Verhalten durch den Inhalt beeinflusst werden kann, den sie verarbeiten: Dateien, Webseiten oder Benutzereingaben. Dies wird manchmal als Prompt-Injection bezeichnet. Wenn beispielsweise die README eines Repositorys ungewöhnliche Anweisungen enthält, könnte Claude Code diese auf Weise in seine Aktionen einbeziehen, die der Operator nicht erwartet hat. Dieser Leitfaden behandelt praktische Wege, um dieses Risiko zu verringern.
Die gute Nachricht ist, dass die Sicherung einer Agent-Bereitstellung keine exotische Infrastruktur erfordert. Die gleichen Prinzipien, die für die Ausführung von halbvertrautem Code gelten, gelten auch hier: Isolation, Prinzip der geringsten Berechtigung und Verteidigungstiefe. Claude Code enthält mehrere Sicherheitsfunktionen, die bei häufigen Bedenken helfen, und dieser Leitfaden behandelt diese zusammen mit zusätzlichen Härtungsoptionen für diejenigen, die sie benötigen.
Nicht jede Bereitstellung benötigt maximale Sicherheit. Ein Entwickler, der Claude Code auf seinem Laptop ausführt, hat andere Anforderungen als ein Unternehmen, das Kundendaten in einer Multi-Tenant-Umgebung verarbeitet. Dieser Leitfaden präsentiert Optionen, die von Claude Codes integrierten Sicherheitsfunktionen bis zu gehärteten Produktionsarchitekturen reichen, damit Sie wählen können, was zu Ihrer Situation passt.
Bedrohungsmodell
Agenten können unbeabsichtigte Aktionen aufgrund von Prompt-Injection (Anweisungen, die in Inhalte eingebettet sind, die sie verarbeiten) oder Modellfehler durchführen. Claude-Modelle sind so konzipiert, dass sie dagegen resistent sind; siehe die Modellübersicht und die Systemkarte für das Modell, das Sie bereitstellen, für Bewertungsdetails.
Verteidigungstiefe ist dennoch eine gute Praxis. Wenn beispielsweise ein Agent eine bösartige Datei verarbeitet, die ihn anweist, Kundendaten an einen externen Server zu senden, können Netzwerkkontrollen diese Anfrage vollständig blockieren.
Integrierte Sicherheitsfunktionen
Claude Code enthält mehrere Sicherheitsfunktionen, die häufige Bedenken adressieren. Siehe die Sicherheitsdokumentation für vollständige Details.
- Berechtigungssystem: Jedes Tool und jeder Bash-Befehl kann so konfiguriert werden, dass er erlaubt, blockiert oder der Benutzer zur Genehmigung aufgefordert wird. Verwenden Sie Glob-Muster, um Regeln wie „alle npm-Befehle erlauben” oder „jeden Befehl mit sudo blockieren” zu erstellen. Organisationen können Richtlinien festlegen, die für alle Benutzer gelten. Siehe Berechtigungen.
- Befehlsanalyse für Berechtigungen: Vor der Ausführung von Bash-Befehlen analysiert Claude Code diese in einen AST und gleicht das Ergebnis mit Ihren Berechtigungsregeln ab. Befehle, die nicht sauber analysiert werden können oder die keine Erlaubnisregel erfüllen, erfordern explizite Genehmigung. Eine kleine Reihe von Konstrukten wie
eval erfordern immer Genehmigung, unabhängig von Erlaubnisregeln. Dies ist ein Berechtigungsgate, kein Sandbox; es leitet nicht ab, ob ein Befehl basierend auf seinem Zielpfad oder seinen Auswirkungen gefährlich ist.
- Web-Suche-Zusammenfassung: Suchergebnisse werden zusammengefasst, anstatt rohe Inhalte direkt in den Kontext zu übergeben, was das Risiko von Prompt-Injection aus bösartigen Webinhalten verringert.
- Sandbox-Modus: Bash-Befehle können in einer Sandbox-Umgebung ausgeführt werden, die Dateisystem- und Netzwerkzugriff einschränkt. Siehe die Sandboxing-Dokumentation für Details.
Sicherheitsprinzipien
Für Bereitstellungen, die zusätzliche Härtung über Claude Codes Standardeinstellungen hinaus erfordern, leiten diese Prinzipien die verfügbaren Optionen.
Sicherheitsgrenzen
Eine Sicherheitsgrenze trennt Komponenten mit unterschiedlichen Vertrauensstufen. Für hochsichere Bereitstellungen können Sie sensible Ressourcen (wie Anmeldedaten) außerhalb der Grenze platzieren, die den Agent enthält. Wenn etwas in der Umgebung des Agenten schiefgeht, bleiben Ressourcen außerhalb dieser Grenze geschützt.
Beispielsweise könnten Sie anstatt einem Agent direkten Zugriff auf einen API-Schlüssel zu geben, einen Proxy außerhalb der Umgebung des Agenten ausführen, der den Schlüssel in Anfragen injiziert. Der Agent kann API-Aufrufe tätigen, sieht aber niemals die Anmeldedaten selbst. Dieses Muster ist nützlich für Multi-Tenant-Bereitstellungen oder bei der Verarbeitung nicht vertrauenswürdiger Inhalte.
Prinzip der geringsten Berechtigung
Bei Bedarf können Sie den Agent auf nur die Funktionen beschränken, die für seine spezifische Aufgabe erforderlich sind:
| Ressource | Einschränkungsoptionen |
|---|
| Dateisystem | Nur benötigte Verzeichnisse einbinden, schreibgeschützt bevorzugen |
| Netzwerk | Auf spezifische Endpunkte über Proxy beschränken |
| Anmeldedaten | Über Proxy injizieren anstatt direkt freizulegen |
| Systemfunktionen | Linux-Funktionen in Containern entfernen |
Verteidigungstiefe
Für hochsichere Umgebungen bietet das Schichten mehrerer Kontrollen zusätzlichen Schutz. Optionen umfassen:
- Container-Isolation
- Netzwerkbeschränkungen
- Dateisystemkontrollen
- Anfrageverifizierung bei einem Proxy
Die richtige Kombination hängt von Ihrem Bedrohungsmodell und den operativen Anforderungen ab.
Isolationstechnologien
Verschiedene Isolationstechnologien bieten unterschiedliche Kompromisse zwischen Sicherheitsstärke, Leistung und operativer Komplexität.
In all diesen Konfigurationen wird Claude Code (oder Ihre Agent SDK-Anwendung) innerhalb der Isolationsgrenze (der Sandbox, des Containers oder der VM) ausgeführt. Die unten beschriebenen Sicherheitskontrollen beschränken, worauf der Agent von innerhalb dieser Grenze zugreifen kann.
| Technologie | Isolationsstärke | Leistungsaufwand | Komplexität |
|---|
| Sandbox-Laufzeit | Gut (sichere Standardeinstellungen) | Sehr niedrig | Niedrig |
| Container (Docker) | Abhängig von Setup | Niedrig | Mittel |
| gVisor | Ausgezeichnet (mit korrektem Setup) | Mittel/Hoch | Mittel |
| VMs (Firecracker, QEMU) | Ausgezeichnet (mit korrektem Setup) | Hoch | Mittel/Hoch |
Sandbox-Laufzeit
Für leichte Isolation ohne Container erzwingt sandbox-runtime Dateisystem- und Netzwerkbeschränkungen auf OS-Ebene.
Der Hauptvorteil ist Einfachheit: keine Docker-Konfiguration, Container-Images oder Netzwerk-Setup erforderlich. Der Proxy und die Dateisystembeschränkungen sind integriert. Sie stellen eine Einstellungsdatei bereit, die zulässige Domänen und Pfade angibt.
Funktionsweise:
- Dateisystem: Verwendet OS-Primitive (
bubblewrap auf Linux, sandbox-exec auf macOS), um Lese-/Schreibzugriff auf konfigurierte Pfade zu beschränken
- Netzwerk: Entfernt Netzwerk-Namespace (Linux) oder verwendet Seatbelt-Profile (macOS), um Netzwerkverkehr durch einen integrierten Proxy zu leiten
- Konfiguration: JSON-basierte Zulassungslisten für Domänen und Dateisystempfade
Setup:
npm install @anthropic-ai/sandbox-runtime
-
Gleicher Host-Kernel: Im Gegensatz zu VMs teilen sich Sandbox-Prozesse den Host-Kernel. Eine Kernel-Schwachstelle könnte theoretisch einen Escape ermöglichen. Für einige Bedrohungsmodelle ist dies akzeptabel, aber wenn Sie Kernel-Isolation benötigen, verwenden Sie gVisor oder eine separate VM.
-
Keine TLS-Inspektion: Der Proxy erstellt Zulassungslisten für Domänen basierend auf dem vom Client bereitgestellten Hostnamen und terminiert oder inspiziert keinen verschlüsselten Verkehr. Code, der in der Sandbox ausgeführt wird, kann möglicherweise Domain Fronting oder ähnliche Techniken verwenden, um Hosts außerhalb der Zulassungsliste zu erreichen. Wenn Ihr Bedrohungsmodell stärkere Garantien erfordert, konfigurieren Sie einen TLS-terminierenden Proxy. Siehe die Sandboxing-Sicherheitsbeschränkungen für weitere Details. Stellen Sie separat sicher, dass der Agent mit zulässigen Domänen keine Berechtigungen hat, um andere Netzwerkanfragen auszulösen oder Daten zu exfiltrieren.
Für viele Single-Developer- und CI/CD-Anwendungsfälle erhöht sandbox-runtime die Messlatte erheblich mit minimalem Setup. Die folgenden Abschnitte behandeln Container und VMs für Bereitstellungen, die stärkere Isolation erfordern.
Container
Container bieten Isolation durch Linux-Namespaces. Jeder Container hat seine eigene Ansicht des Dateisystems, des Prozessbaums und des Netzwerk-Stacks, während er den Host-Kernel teilt.
Eine sicherheitsgefestigte Container-Konfiguration könnte so aussehen:
docker run \
--cap-drop ALL \
--security-opt no-new-privileges \
--security-opt seccomp=/path/to/seccomp-profile.json \
--read-only \
--tmpfs /tmp:rw,noexec,nosuid,size=100m \
--tmpfs /home/agent:rw,noexec,nosuid,size=500m \
--network none \
--memory 2g \
--cpus 2 \
--pids-limit 100 \
--user 1000:1000 \
-v /path/to/code:/workspace:ro \
-v /var/run/proxy.sock:/var/run/proxy.sock:ro \
agent-image
| Option | Zweck |
|---|
--cap-drop ALL | Entfernt Linux-Funktionen wie NET_ADMIN und SYS_ADMIN, die Privilegienerweiterung ermöglichen könnten |
--security-opt no-new-privileges | Verhindert, dass Prozesse Privilegien durch setuid-Binärdateien erhalten |
--security-opt seccomp=... | Beschränkt verfügbare Systemaufrufe; Dockers Standard blockiert ~44, benutzerdefinierte Profile können mehr blockieren |
--read-only | Macht das Dateisystem des Containers unveränderlich und verhindert, dass der Agent Änderungen beibehält |
--tmpfs /tmp:... | Stellt ein beschreibbares temporäres Verzeichnis bereit, das gelöscht wird, wenn der Container stoppt |
--network none | Entfernt alle Netzwerkschnittstellen; der Agent kommuniziert über den unten eingebundenen Unix-Socket |
--memory 2g | Begrenzt die Speichernutzung, um Ressourcenerschöpfung zu verhindern |
--pids-limit 100 | Begrenzt die Prozessanzahl, um Fork-Bomben zu verhindern |
--user 1000:1000 | Wird als nicht-root-Benutzer ausgeführt |
-v ...:/workspace:ro | Bindet Code schreibgeschützt ein, damit der Agent ihn analysieren, aber nicht ändern kann. Vermeiden Sie das Einbinden sensibler Host-Verzeichnisse wie ~/.ssh, ~/.aws oder ~/.config |
-v .../proxy.sock:... | Bindet einen Unix-Socket ein, der mit einem Proxy verbunden ist, der außerhalb des Containers ausgeführt wird (siehe unten) |
--network none hat der Container überhaupt keine Netzwerkschnittstellen. Die einzige Möglichkeit für den Agent, die Außenwelt zu erreichen, ist über den eingebundenen Unix-Socket, der mit einem Proxy auf dem Host verbunden ist. Dieser Proxy kann Domain-Zulassungslisten erzwingen, Anmeldedaten injizieren und den gesamten Verkehr protokollieren.
Dies ist die gleiche Architektur, die von sandbox-runtime verwendet wird. Selbst wenn der Agent über Prompt-Injection kompromittiert wird, kann er Daten nicht zu beliebigen Servern exfiltrieren. Er kann nur über den Proxy kommunizieren, der kontrolliert, welche Domänen erreichbar sind. Weitere Details finden Sie im Claude Code Sandboxing Blog-Beitrag.
Zusätzliche Härtungsoptionen:
| Option | Zweck |
|---|
--userns-remap | Ordnet Container-Root einem nicht-privilegierten Host-Benutzer zu; erfordert Daemon-Konfiguration, begrenzt aber Schäden durch Container-Escape |
--ipc private | Isoliert Inter-Process-Kommunikation, um Container-übergreifende Angriffe zu verhindern |
gVisor
Standard-Container teilen den Host-Kernel: Wenn Code in einem Container einen Systemaufruf tätigt, geht dieser direkt an den gleichen Kernel, der den Host ausführt. Dies bedeutet, dass eine Kernel-Schwachstelle einen Container-Escape ermöglichen könnte. gVisor adressiert dies, indem es Systemaufrufe im Userspace abfängt, bevor sie den Host-Kernel erreichen, und seine eigene Kompatibilitätsschicht implementiert, die die meisten Systemaufrufe ohne Beteiligung des echten Kernels handhabt.
Wenn ein Agent bösartigen Code ausführt (möglicherweise aufgrund von Prompt-Injection), wird dieser Code im Container ausgeführt und könnte Kernel-Exploits versuchen. Mit gVisor ist die Angriffsfläche viel kleiner: Der bösartige Code müsste zuerst gVisors Userspace-Implementierung ausnutzen und hätte begrenzten Zugriff auf den echten Kernel.
Um gVisor mit Docker zu verwenden, installieren Sie die runsc-Laufzeit und konfigurieren Sie den Daemon:
// /etc/docker/daemon.json
{
"runtimes": {
"runsc": {
"path": "/usr/local/bin/runsc"
}
}
}
docker run --runtime=runsc agent-image
| Workload | Aufwand |
|---|
| CPU-gebundene Berechnung | ~0% (keine Systemaufruf-Abfangung) |
| Einfache Systemaufrufe | ~2× langsamer |
| Dateisystem-intensive E/A | Bis zu 10-200× langsamer für schwere Open/Close-Muster |
Virtuelle Maschinen
VMs bieten Hardware-Isolation durch CPU-Virtualisierungserweiterungen. Jede VM führt ihren eigenen Kernel aus und schafft eine starke Grenze. Eine Schwachstelle im Gast-Kernel kompromittiert nicht direkt den Host. VMs sind jedoch nicht automatisch „sicherer” als Alternativen wie gVisor. Die VM-Sicherheit hängt stark vom Hypervisor und dem Device-Emulationscode ab.
Firecracker ist für leichte MicroVM-Isolation konzipiert. Es kann VMs in unter 125 ms mit weniger als 5 MiB Speicheraufwand starten und entfernt unnötige Device-Emulation, um die Angriffsfläche zu reduzieren.
Mit diesem Ansatz hat die Agent-VM keine externe Netzwerkschnittstelle. Stattdessen kommuniziert sie über vsock (virtuelle Sockets). Der gesamte Verkehr wird über vsock zu einem Proxy auf dem Host geleitet, der Zulassungslisten erzwingt und Anmeldedaten injiziert, bevor Anfragen weitergeleitet werden.
Cloud-Bereitstellungen
Für Cloud-Bereitstellungen können Sie jede der oben genannten Isolationstechnologien mit Cloud-nativen Netzwerkkontrollen kombinieren:
- Führen Sie Agent-Container in einem privaten Subnetz ohne Internet-Gateway aus
- Konfigurieren Sie Cloud-Firewall-Regeln (AWS Security Groups, GCP VPC Firewall), um den gesamten Ausgangsverkehr außer zu Ihrem Proxy zu blockieren
- Führen Sie einen Proxy aus (wie Envoy mit seinem
credential_injector-Filter), der Anfragen validiert, Domain-Zulassungslisten erzwingt, Anmeldedaten injiziert und an externe APIs weiterleitet
- Weisen Sie dem Service-Konto des Agenten minimale IAM-Berechtigungen zu und leiten Sie sensiblen Zugriff nach Möglichkeit über den Proxy
- Protokollieren Sie den gesamten Verkehr beim Proxy für Audit-Zwecke
Verwaltung von Anmeldedaten
Agenten benötigen oft Anmeldedaten, um APIs aufzurufen, auf Repositorys zuzugreifen oder mit Cloud-Diensten zu interagieren. Die Herausforderung besteht darin, diesen Zugriff bereitzustellen, ohne die Anmeldedaten selbst freizulegen.
Das Proxy-Muster
Der empfohlene Ansatz ist, einen Proxy außerhalb der Sicherheitsgrenze des Agenten auszuführen, der Anmeldedaten in ausgehende Anfragen injiziert. Der Agent sendet Anfragen ohne Anmeldedaten, der Proxy fügt diese hinzu und leitet die Anfrage an ihr Ziel weiter.
Dieses Muster hat mehrere Vorteile:
- Der Agent sieht niemals die tatsächlichen Anmeldedaten
- Der Proxy kann eine Zulassungsliste zulässiger Endpunkte erzwingen
- Der Proxy kann alle Anfragen für Audit-Zwecke protokollieren
- Anmeldedaten werden an einem sicheren Ort gespeichert, anstatt an jeden Agent verteilt zu werden
Konfigurieren von Claude Code zur Verwendung eines Proxy
Claude Code unterstützt zwei Methoden zum Leiten von Sampling-Anfragen durch einen Proxy:
Option 1: ANTHROPIC_BASE_URL (einfach, aber nur für Sampling-API-Anfragen)
export ANTHROPIC_BASE_URL="http://localhost:8080"
export HTTP_PROXY="http://localhost:8080"
export HTTPS_PROXY="http://localhost:8080"
Implementieren eines Proxy
Sie können Ihren eigenen Proxy erstellen oder einen vorhandenen verwenden:
- Envoy Proxy: produktionsreifer Proxy mit
credential_injector-Filter zum Hinzufügen von Auth-Headern
- mitmproxy: TLS-terminierender Proxy zum Inspizieren und Ändern von HTTPS-Verkehr
- Squid: Caching-Proxy mit Zugriffskontrolllisten
- LiteLLM: LLM-Gateway mit Anmeldedaten-Injection und Rate Limiting
Anmeldedaten für andere Dienste
Über das Sampling aus der Claude API hinaus benötigen Agenten oft authentifizierten Zugriff auf andere Dienste wie Git-Repositorys, Datenbanken und interne APIs. Es gibt zwei Hauptansätze:
Stellen Sie Zugriff über einen MCP-Server oder ein benutzerdefiniertes Tool bereit, das Anfragen an einen Dienst leitet, der außerhalb der Sicherheitsgrenze des Agenten ausgeführt wird. Der Agent ruft das Tool auf, aber die tatsächliche authentifizierte Anfrage erfolgt außerhalb. Die Tool-Aufrufe gehen an einen Proxy, der die Anmeldedaten injiziert.
Beispielsweise könnte ein Git-MCP-Server Befehle vom Agent akzeptieren, diese aber an einen Git-Proxy auf dem Host weiterleiten, der Authentifizierung hinzufügt, bevor er das Remote-Repository kontaktiert. Der Agent sieht niemals die Anmeldedaten.
Vorteile:
- Keine TLS-Inspektion: Der externe Dienst tätigt authentifizierte Anfragen direkt
- Anmeldedaten bleiben außerhalb: Der Agent sieht nur die Tool-Schnittstelle, nicht die zugrunde liegenden Anmeldedaten
Verkehrsweiterleitung
Für Claude API-Aufrufe ermöglicht ANTHROPIC_BASE_URL das Leiten von Anfragen an einen Proxy, der diese im Klartext inspizieren und ändern kann. Aber für andere HTTPS-Dienste (GitHub, npm-Registrys, interne APIs) ist der Verkehr oft End-to-End verschlüsselt. Selbst wenn Sie ihn über einen Proxy über HTTP_PROXY leiten, sieht der Proxy nur einen undurchsichtigen TLS-Tunnel und kann keine Anmeldedaten injizieren.
Um HTTPS-Verkehr zu beliebigen Diensten zu ändern, ohne ein benutzerdefiniertes Tool zu verwenden, benötigen Sie einen TLS-terminierenden Proxy, der Verkehr entschlüsselt, inspiziert oder ändert und dann vor der Weiterleitung erneut verschlüsselt. Dies erfordert:
- Ausführen des Proxy außerhalb des Agent-Containers
- Installieren des CA-Zertifikats des Proxy im Vertrauensspeicher des Agenten (damit der Agent den Zertifikaten des Proxy vertraut)
- Konfigurieren von
HTTP_PROXY/HTTPS_PROXY zum Leiten von Verkehr durch den Proxy
Dieser Ansatz handhabt jeden HTTP-basierten Dienst ohne das Schreiben benutzerdefinierter Tools, fügt aber Komplexität um Zertifikatverwaltung hinzu.
Beachten Sie, dass nicht alle Programme HTTP_PROXY/HTTPS_PROXY respektieren. Die meisten Tools (curl, pip, npm, git) tun dies, aber einige können diese Variablen umgehen und direkt verbinden. Beispielsweise ignoriert Node.js fetch() diese Variablen standardmäßig; in Node 24+ können Sie NODE_USE_ENV_PROXY=1 setzen, um Unterstützung zu aktivieren. Für umfassende Abdeckung können Sie proxychains verwenden, um Netzwerkaufrufe abzufangen, oder iptables konfigurieren, um ausgehenden Verkehr zu einem transparenten Proxy umzuleiten.
Ein transparenter Proxy fängt Verkehr auf Netzwerkebene ab, sodass der Client nicht konfiguriert werden muss, um ihn zu verwenden. Reguläre Proxys erfordern, dass Clients explizit verbinden und HTTP CONNECT oder SOCKS sprechen. Transparente Proxys (wie Squid oder mitmproxy im transparenten Modus) können rohe umgeleitete TCP-Verbindungen handhaben.
Dateisystem-Konfiguration
Dateisystemkontrollen bestimmen, welche Dateien der Agent lesen und schreiben kann.
Schreibgeschützte Code-Einbindung
Wenn der Agent Code analysieren, aber nicht ändern muss, binden Sie das Verzeichnis schreibgeschützt ein:
docker run -v /path/to/code:/workspace:ro agent-image
Selbst schreibgeschützter Zugriff auf ein Code-Verzeichnis kann Anmeldedaten freigeben. Häufige Dateien, die ausgeschlossen oder bereinigt werden sollten, bevor sie eingebunden werden:| Datei | Risiko |
|---|
.env, .env.local | API-Schlüssel, Datenbankpasswörter, Geheimnisse |
~/.git-credentials | Git-Passwörter/Tokens im Klartext |
~/.aws/credentials | AWS-Zugangsschlüssel |
~/.config/gcloud/application_default_credentials.json | Google Cloud ADC-Tokens |
~/.azure/ | Azure CLI-Anmeldedaten |
~/.docker/config.json | Docker-Registry-Auth-Tokens |
~/.kube/config | Kubernetes-Cluster-Anmeldedaten |
.npmrc, .pypirc | Package-Registry-Tokens |
*-service-account.json | GCP-Service-Account-Schlüssel |
*.pem, *.key | Private Schlüssel |
.dockerignore-ähnliche Filterung. Beschreibbare Orte
Wenn der Agent Dateien schreiben muss, haben Sie je nachdem, ob Änderungen beibehalten werden sollen, einige Optionen:
Für ephemere Workspaces in Containern verwenden Sie tmpfs-Einbindungen, die nur im Speicher vorhanden sind und gelöscht werden, wenn der Container stoppt:
docker run \
--read-only \
--tmpfs /tmp:rw,noexec,nosuid,size=100m \
--tmpfs /workspace:rw,noexec,size=500m \
agent-image
Weitere Lektüre
