Sichere Bereitstellung von KI-Agenten

Ein Leitfaden zur Sicherung von Claude Code und Agent SDK-Bereitstellungen mit Isolation, Verwaltung von Anmeldedaten und Netzwerkkontrollen

Claude Code und das Agent SDK können Code ausführen, auf Dateien zugreifen und externe Dienste in Ihrem Namen nutzen.

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.

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: Berechtigungsregeln entscheiden, ob ein Tool-Aufruf ausgeführt wird, blockiert wird oder zuerst um Genehmigung bittet. Welche Formen eine Bash-Regel nicht erfasst und wie Regeln mit Berechtigungsmodi zusammenwirken, erfahren Sie unter Was eine Bash-Regel nicht erfasst und Berechtigungen konfigurieren. Administratoren können Regeln außerdem in verwalteten Einstellungen festlegen.
• Entfernen kritischer Pfade: Wenn der Berechtigungsmodus auf default gesetzt ist, erfordert ein rm- oder rmdir-Befehl, der als Entfernen Ihres Arbeitsverzeichnisses oder eines anderen kritischen Pfads erkannt wird, eine Genehmigung. Eine passende allow-Regel überspringt diese Genehmigung nicht. Dies ist ein Berechtigungsgate, keine Sandbox. Um zu steuern, was der Agent schreiben darf, verwenden Sie Dateisystemkontrollen.
• 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:

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.

[!NOTE]

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.

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.

Funktionsweise:

• Dateisystem: Verwendet OS-Primitive (bubblewrap auf Linux, sandbox-exec auf macOS), um Lese-/Schreibzugriff auf konfigurierte Pfade zu beschränken
• Netzwerk: Führt Befehle in einem eigenen Netzwerk-Namespace (Linux) oder unter einem Seatbelt-Profil (macOS) aus und leitet ihren Verkehr durch einen integrierten Proxy, der die konfigurierten Domänen zulässt. Eine Verbindung zu einem externen Host, die den Proxy umgeht, schlägt fehl.
• Konfiguration: JSON-basierte Zulassungslisten für Domänen und Dateisystempfade

Setup:

Die Schritte zur Installation, Konfiguration und zum Start finden Sie unter Laufzeit einrichten und starten.

Sicherheitsüberlegungen:

1. 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.

2. Keine TLS-Inspektion: Standardmäßig lässt der Proxy Domänen anhand des vom Client bereitgestellten Hostnamens per Allowlist zu 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 Allowlist zu erreichen. Wenn Ihr Bedrohungsmodell stärkere Garantien erfordert, verwenden Sie einen TLS-terminierenden Proxy, der den Verkehr inspiziert, wie unter Weiterleitung des Datenverkehrs beschrieben. Weitere Informationen finden Sie in den Sandboxing-Sicherheitsbeschränkungen.

3. Anmeldedaten für zulässige Domänen: Wenn der Agent über weitreichende Anmeldedaten für eine zulässige Domäne verfügt, stellen Sie sicher, dass er diese Domäne nicht nutzen kann, 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 bewirkt:

Unix-Socket-Architektur:

Mit --network none schlagen eine DNS-Abfrage oder eine direkte Verbindung zu einem anderen Host innerhalb des Containers fehl. Damit Code im Container andere Hosts erreichen kann, führen Sie einen Proxy auf dem Host aus und binden dessen Unix-Socket in den Container ein. Wenn Sie ANTHROPIC_BASE_URL oder HTTP_PROXY auf einen Port auf localhost verweisen lassen, wie unter Claude Code für die Verwendung eines Proxys konfigurieren gezeigt, leiten Sie diesen Port innerhalb des Containers an den Socket weiter.

Sie können diesen Proxy so einrichten, dass er Domain-Allowlists erzwingt, Anmeldedaten injiziert und den gesamten Verkehr protokolliert.

[!WARNING]

Innerhalb der Allowlist Ihres Proxys kann der Agent Daten an jede zulässige Domäne senden. Lassen Sie nur die Domänen zu, die der Agent benötigt.

Zusätzliche Härtungsoptionen:

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:

{
  "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-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:

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-Zulassungslisten erzwingt, Anmeldedaten injiziert und an externe APIs weiterleitet
4. Weisen Sie dem Service-Konto des Agenten 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

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:

1. Der Agent sieht niemals die tatsächlichen Anmeldedaten
2. Der Proxy kann eine Zulassungsliste 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 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"

Dies teilt Claude Code und dem Agent SDK mit, Sampling-Anfragen an Ihren Proxy anstatt direkt an die Claude API zu senden. Ihr Proxy empfängt Klartext-HTTP-Anfragen, kann diese inspizieren und ändern (einschließlich Injizieren 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 durch 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 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:

Benutzerdefinierte Tools

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:

1. Ausführen des Proxy außerhalb des Agent-Containers
2. Installieren des CA-Zertifikats des Proxy im Vertrauensspeicher des Agenten (damit der Agent den Zertifikaten des Proxy vertraut)
3. 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. Um Tools abzudecken, die diese Variablen ignorieren, können Sie proxychains verwenden, um Netzwerkaufrufe abzufangen, oder iptables konfigurieren, um ausgehenden Verkehr zu einem transparenten Proxy umzuleiten.

[!NOTE]

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.

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

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

[!WARNING]

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

Erwägen Sie, nur die benötigten Quelldateien zu kopieren, oder verwenden Sie .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

Wenn Sie Änderungen überprüfen möchten, bevor Sie sie beibehalten, 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 binden Sie ein dediziertes Volume ein, halten Sie es aber separat von sensiblen Verzeichnissen.

Weitere Lektüre

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