Sichere Bereitstellung von KI-Agenten

Claude Code und das Agent SDK sind leistungsstarke Tools, die Code ausführen, auf Dateien zugreifen und externe Services in Ihrem Namen nutzen können. Wie jedes Tool mit diesen Fähigkeiten stellt eine durchdachte Bereitstellung sicher, dass Sie von den Vorteilen profitieren 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 Prompt Injection genannt. Wenn beispielsweise die README eines Repositories 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 reduzieren.

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 Defense in Depth. 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.

Wogegen schützen wir uns?

Agenten können unbeabsichtigte Aktionen aufgrund von Prompt Injection (Anweisungen, die in Inhalte eingebettet sind, die sie verarbeiten) oder Modellfehlern durchführen. Claude-Modelle sind so konzipiert, dass sie dagegen resistent sind, und wie wir in unserer Modellkarte analysiert haben, glauben wir, dass Claude Opus 4.6 das robusteste Frontier-Modell ist, das verfügbar ist.

Defense in Depth 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 Zugriffskontrolle und Berechtigungen.
• Statische Analyse: Vor der Ausführung von Bash-Befehlen führt Claude Code eine statische Analyse durch, um potenziell riskante Operationen zu identifizieren. Befehle, die Systemdateien ändern oder auf sensible Verzeichnisse zugreifen, werden gekennzeichnet und erfordern explizite Benutzerbestätigung.
• Web-Suchzusammenfassung: Suchergebnisse werden zusammengefasst, anstatt rohe Inhalte direkt in den Kontext zu übergeben, was das Risiko von Prompt Injection aus bösartigen Webinhalten reduziert.
• 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 Agent-Umgebung schiefgeht, bleiben Ressourcen außerhalb dieser Grenze geschützt.

Anstatt einem Agent direkten Zugriff auf einen API-Schlüssel zu geben, könnten Sie beispielsweise einen Proxy außerhalb der Agent-Umgebung ausführen, der den Schlüssel in Anfragen einfügt. Der Agent kann API-Aufrufe tätigen, sieht aber die Anmeldedaten selbst nie. 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 für seine spezifische Aufgabe erforderlichen Fähigkeiten beschränken:

Defense in Depth

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.

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 Domains und Pfade angibt.

Wie es funktioniert:

• 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 Allowlists für Domains und Dateisystempfade

Setup:

npm install @anthropic-ai/sandbox-runtime

Erstellen Sie dann eine Konfigurationsdatei, die zulässige Pfade und Domains angibt.

Sicherheitsüberlegungen:

1. Gemeinsamer Host-Kernel: Im Gegensatz zu VMs teilen sich Sandbox-Prozesse den Host-Kernel. Eine Kernel-Sicherheitslücke könnte theoretisch einen Escape ermöglichen. Für einige Bedrohungsmodelle ist dies akzeptabel, aber wenn Sie Kernel-Level-Isolation benötigen, verwenden Sie gVisor oder eine separate VM.

2. Keine TLS-Inspektion: Der Proxy erstellt eine Allowlist von Domains, inspiziert aber keinen verschlüsselten Verkehr. Wenn der Agent permissive Anmeldedaten für eine zulässige Domain hat, stellen Sie sicher, dass es nicht möglich ist, diese Domain zu verwenden, 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

Hier ist, was jede Option tut:

Unix-Socket-Architektur:

Mit --network none hat der Container überhaupt keine Netzwerkschnittstellen. Die einzige Möglichkeit für den Agent, die Außenwelt zu erreichen, ist über den bereitgestellten Unix-Socket, der mit einem Proxy auf dem Host verbunden ist. Dieser Proxy kann Domain-Allowlists erzwingen, Anmeldedaten einfügen 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 keine Daten zu willkürlichen Servern exfiltrieren – er kann nur über den Proxy kommunizieren, der kontrolliert, welche Domains erreichbar sind. Für weitere Details siehe den Claude Code Sandboxing Blog-Beitrag.

Zusätzliche Härtungsoptionen:

gVisor

Standard-Container teilen den Host-Kernel: Wenn Code in einem Container einen Systemaufruf tätigt, geht er direkt zum gleichen Kernel, der den Host ausführt. Dies bedeutet, dass eine Kernel-Sicherheitslücke 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 Syscalls ohne Beteiligung des echten Kernels handhabt.

Wenn ein Agent bösartigen Code ausführt (vielleicht aufgrund von Prompt Injection), läuft dieser Code im Container 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"
    }
  }
}

Führen Sie dann Container mit aus:

docker run --runtime=runsc agent-image

Leistungsüberlegungen:

Für Multi-Tenant-Umgebungen oder bei der Verarbeitung nicht vertrauenswürdiger Inhalte ist die zusätzliche Isolation oft den Aufwand wert.

Virtuelle Maschinen

VMs bieten Hardware-Level-Isolation durch CPU-Virtualisierungserweiterungen. Jede VM führt ihren eigenen Kernel aus und schafft eine starke Grenze – eine Sicherheitslücke im Guest-Kernel kompromittiert nicht direkt den Host. VMs sind jedoch nicht automatisch „sicherer" als Alternativen wie gVisor. VM-Sicherheit hängt stark vom Hypervisor und dem Device-Emulation-Code ab.

Firecracker ist für leichte MicroVM-Isolation konzipiert – es kann VMs in unter 125ms mit weniger als 5 MiB Speicher-Overhead booten 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 Allowlists erzwingt und Anmeldedaten einfügt, bevor Anfragen weitergeleitet werden.

Cloud-Bereitstellungen

Für Cloud-Bereitstellungen können Sie jede der oben genannten Isolationstechnologien mit Cloud-nativen Netzwerkkontrollen kombinieren:

1. Führen Sie Agent-Container in einem privaten Subnetz ohne Internet-Gateway aus
2. Konfigurieren Sie Cloud-Firewall-Regeln (AWS Security Groups, GCP VPC-Firewall), um den gesamten Ausgangsverkehr außer zu Ihrem Proxy zu blockieren
3. Führen Sie einen Proxy aus (wie Envoy mit seinem credential_injector-Filter), der Anfragen validiert, Domain-Allowlists erzwingt, Anmeldedaten einfügt und an externe APIs weiterleitet
4. Weisen Sie dem Service-Konto des Agents minimale IAM-Berechtigungen zu und leiten Sie sensiblen Zugriff nach Möglichkeit über den Proxy
5. Protokollieren Sie den gesamten Verkehr beim Proxy für Audit-Zwecke

Credential-Management

Agenten benötigen oft Anmeldedaten, um APIs aufzurufen, auf Repositories zuzugreifen oder mit Cloud-Services zu interagieren. Die Herausforderung besteht darin, diesen Zugriff bereitzustellen, ohne die Anmeldedaten selbst freizugeben.

Das Proxy-Muster

Der empfohlene Ansatz besteht darin, einen Proxy außerhalb der Sicherheitsgrenze des Agents auszuführen, der Anmeldedaten in ausgehende Anfragen einfügt. Der Agent sendet Anfragen ohne Anmeldedaten, der Proxy fügt sie hinzu und leitet die Anfrage an ihr Ziel weiter.

Dieses Muster hat mehrere Vorteile:

1. Der Agent sieht die tatsächlichen Anmeldedaten nie
2. Der Proxy kann eine Allowlist zulässiger Endpunkte erzwingen
3. Der Proxy kann alle Anfragen für Audit-Zwecke protokollieren
4. 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 Routing von Sampling-Anfragen über einen Proxy:

Option 1: ANTHROPIC_BASE_URL (einfach, aber nur für Sampling-API-Anfragen)

export ANTHROPIC_BASE_URL="http://localhost:8080"

Dies weist Claude Code und das Agent SDK an, Sampling-Anfragen an Ihren Proxy statt direkt an die Anthropic API zu senden. Ihr Proxy empfängt Klartext-HTTP-Anfragen, kann diese inspizieren und ändern (einschließlich Einfügen von Anmeldedaten) und leitet dann an die echte API weiter.

Option 2: HTTP_PROXY / HTTPS_PROXY (systemweit)

export HTTP_PROXY="http://localhost:8080"
export HTTPS_PROXY="http://localhost:8080"

Claude Code und das Agent SDK respektieren diese Standard-Umgebungsvariablen und leiten den gesamten HTTP-Verkehr über den Proxy. Für HTTPS erstellt der Proxy einen verschlüsselten CONNECT-Tunnel: Er kann Anfrageinhalte ohne TLS-Inspektion nicht sehen oder ändern.

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 Credential-Injection und Rate-Limiting

Anmeldedaten für andere Services

Neben dem Sampling von der Anthropic API benötigen Agenten oft authentifizierten Zugriff auf andere Services – Git-Repositories, Datenbanken, interne APIs. Es gibt zwei Hauptansätze:

Benutzerdefinierte Tools

Stellen Sie Zugriff über einen MCP-Server oder ein benutzerdefiniertes Tool bereit, das Anfragen an einen Service weiterleitet, der außerhalb der Sicherheitsgrenze des Agents läuft. Der Agent ruft das Tool auf, aber die tatsächliche authentifizierte Anfrage erfolgt außerhalb – das Tool ruft einen Proxy auf, der die Anmeldedaten einfügt.

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 die Anmeldedaten nie.

Vorteile:

• Keine TLS-Inspektion: Der externe Service tätigt authentifizierte Anfragen direkt
• Anmeldedaten bleiben außen: Der Agent sieht nur die Tool-Schnittstelle, nicht die zugrunde liegenden Anmeldedaten

Verkehrsweiterleitung

Für Anthropic-API-Aufrufe ermöglicht ANTHROPIC_BASE_URL das Routing von Anfragen zu einem Proxy, der diese im Klartext inspizieren und ändern kann. Aber für andere HTTPS-Services (GitHub, npm-Registries, 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 einfügen.

Um HTTPS-Verkehr zu willkürlichen Services 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:

1. Ausführen des Proxy außerhalb des Agent-Containers
2. Installieren des CA-Zertifikats des Proxy im Agent-Vertrauensspeicher (damit der Agent den Zertifikaten des Proxy vertraut)
3. Konfigurieren von HTTP_PROXY/HTTPS_PROXY zum Routing von Verkehr über den Proxy

Dieser Ansatz handhabt jeden HTTP-basierten Service 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.

Beide Ansätze erfordern immer noch den TLS-terminierenden Proxy und das vertraute CA-Zertifikat – sie stellen nur sicher, dass Verkehr tatsächlich den Proxy erreicht.

Dateisystem-Konfiguration

Dateisystem-Kontrollen bestimmen, welche Dateien der Agent lesen und schreiben kann.

Schreibgeschütztes Code-Mounting

Wenn der Agent Code analysieren, aber nicht ändern muss, mounten Sie das Verzeichnis schreibgeschützt:

docker run -v /path/to/code:/workspace:ro agent-image

Beschreibbare Orte

Wenn der Agent Dateien schreiben muss, haben Sie je nachdem, ob Sie möchten, dass Änderungen persistieren, einige Optionen:

Für ephemere Workspaces in Containern verwenden Sie tmpfs-Mounts, die nur im Speicher existieren 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

Wenn Sie Änderungen überprüfen möchten, bevor Sie sie persistieren, ermöglicht ein Overlay-Dateisystem dem Agent zu schreiben, ohne zugrunde liegende Dateien zu ändern – Änderungen werden in einer separaten Schicht gespeichert, die Sie inspizieren, anwenden oder verwerfen können. Für vollständig persistente Ausgabe mounten Sie ein dediziertes Volume, halten Sie es aber getrennt von sensiblen Verzeichnissen.

Weitere Lektüre

• Claude Code Sicherheitsdokumentation
• Hosting des Agent SDK
• Berechtigungen handhaben
• Sandbox-Laufzeit
• The Lethal Trifecta for AI Agents
• OWASP Top 10 for LLM Applications
• Docker Security Best Practices
• gVisor Documentation
• Firecracker Documentation