Sicherheit von KI-Agenten: API-Schlüssel, Sandbox und Limits

Die Sicherheit von KI-Agenten läuft auf drei Dinge hinaus: Der Agent sieht nur, was er braucht, API-Schlüssel liegen nicht dort, wo der Agent (oder ein Angreifer) sie lesen kann, und jeder Schlüssel hat ein Ausgabenlimit. Unten stehen fünf Schritte, die wir an einem Nachmittag erledigen können: Berechtigungen, Sandbox, Ordnung bei den Schlüsseln, Limits und das Scannen von Repositorys.

Warum ist die Sicherheit von KI-Agenten jetzt so dringend?

Die letzten Wochen haben mehr als genug Beispiele geliefert. Nach dem Datenleck bei OpenCode zeigten Nutzer Rechnungen für die fremde Nutzung ihrer Schlüssel. Beim KI-Hackerangriff auf mehr als 100 Firmen brachen Agenten fast ohne menschliches Zutun ein, und auf offen erreichbaren Cairn-Panels lagen Hunderte Secrets. Dazu zeigte das Datenleck bei Meta Muse, dass selbst eine „Chat teilen“-Funktion mehr verraten kann, als man denkt.

Am 21. Oktober kam ein weiterer Fall hinzu: Laut SafeDep landete Version 1.107.0 der beliebten Bibliothek LiteLLM auf PyPI mit einem Stealer, der unter anderem SSH-Schlüssel, Cloud-Zugangsdaten, CI/CD-Secrets und Schlüssel für LLM-Anbieter sammelte, sowie mit einer Backdoor. Die Angreifer hatten die GitHub-CLI-Zugangsdaten von drei Entwicklern. PyPI entfernte diese Version noch am selben Tag; sauber ist unter anderem Version 1.106.2.

Ein Agent unterscheidet sich von einem Chat dadurch, dass er Aktionen ausführt: Er liest Dateien, startet Befehle, ruft Webseiten auf. OWASP beschreibt zwei Hauptrisiken:

1. Prompt Injection. Laut OWASP übernimmt das Modell in der indirekten Variante Anweisungen „from external sources, such as websites or files“. Eine README oder eine Webseite mit einer versteckten Anweisung genügt, damit der Agent etwas tut, worum wir ihn nie gebeten haben.
2. Übermäßige Handlungsfreiheit („Excessive Agency“). OWASP nennt drei Ursachen: zu viele Funktionen, zu viele Berechtigungen und zu viel Autonomie. In der Vorschau auf die Liste für 2026 ist dieses Risiko auf Platz drei aufgestiegen.

OWASP führt außerdem eine eigene Top-10-Liste für agentische Anwendungen, auf der „Agent Goal Hijack“ den ersten Platz belegt, also die Übernahme des Ziels eines Agenten.

Die goldene Regel beider Listen ist dieselbe: die geringsten Berechtigungen, die für die Aufgabe reichen, und die Zustimmung eines Menschen bei riskanten Aktionen.

Schritt 1: Wie richtet man Berechtigungen in Claude Code ein?

Ich zeige es an Claude Code (von Grund auf beschrieben in meiner Claude-Code-Anleitung), aber dieselbe Logik gilt für andere Agent-Harnesses.

Berechtigungen legen wir in settings.json als Regeln allow, ask und deny fest. Laut Dokumentation ist die Reihenfolge fest: „deny, then ask, then allow“, eine Ablehnung gewinnt also immer. Sperren wir zuerst den Zugriff auf Secrets. Dieses Beispiel stammt direkt aus der Settings-Referenz:

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Read(./config/credentials.json)",
      "Bash(curl *)"
    ]
  }
}

Wichtig: deny-Regeln haben Grenzen, und die Dokumentation nennt sie offen:

1. Sie greifen nicht bei Befehlen, die Dateien ohne Angabe des Namens lesen, etwa grep -r pattern ., und nicht bei beliebigen Unterprozessen.
2. Bash(curl *) passt wörtlich auf den Befehl, stoppt also weder /usr/bin/curl noch sh -c 'curl …'.
3. Eine .claudeignore-Datei hat keinerlei Wirkung; ihre Einträge gehören in Read-Regeln unter deny.

Deshalb sind Regeln die erste Schutzschicht, nicht der ganze Schutz. Die aktuellen Berechtigungen prüfen wir mit dem Befehl /permissions.

Das Zweite ist der Arbeitsmodus. Claude Code kennt die Modi default, acceptEdits, plan, auto, dontAsk und bypassPermissions. Über den letzten schreibt die Dokumentation: „Only use this mode in isolated environments like containers or VMs“. Auf einem geteilten Rechner können wir ihn ganz abschalten, indem wir permissions.disableBypassPermissionsMode auf "disable" setzen.

Schritt 2: Wie schaltet man die Sandbox ein?

Die Sandbox ist eine Grenze, die das Betriebssystem selbst durchsetzt, sie wirkt also dort, wo deny-Regeln nicht hinreichen. Laut Sandbox-Dokumentation ist sie standardmäßig aus. Wir schalten sie mit einem Befehl in der Sitzung ein:

/sandbox

oder indem wir sandbox.enabled in ~/.claude/settings.json auf true setzen. Unter macOS funktioniert sie sofort, unter Linux und WSL2 braucht sie zwei Pakete:

sudo apt-get install bubblewrap socat

Unter Windows ohne WSL2 gibt es keine Sandbox, Befehle laufen ohne Isolation.

Was die Sandbox nach dem Einschalten bringt:

1. Befehle schreiben nur ins Arbeitsverzeichnis und in temporäre Dateien.
2. Der Netzwerkverkehr läuft über einen lokalen Proxy, und die Liste erlaubter Domains (network.allowedDomains) ist zu Beginn leer.
3. Lesen können sie allerdings den Großteil der Festplatte, einschließlich ~/.ssh und ~/.aws/credentials. Diese Pfade müssen wir selbst über filesystem.denyRead oder den Abschnitt credentials sperren, denn, so die Doku: „There is no built-in credential deny list“.

Zwei Hinweise aus der Dokumentation. Erstens umfasst die Sandbox nur Shell-Befehle: Die Werkzeuge Read, Edit, Write und WebFetch, Hooks und lokale MCP-Server laufen außerhalb. Zweitens können breite Domains wie github.com auf der Erlaubnisliste einen Weg zum Abfluss von Daten öffnen. Wer alles auf einmal isolieren will, sollte den ganzen Agenten in einem Container oder einer virtuellen Maschine starten.

In Codex von OpenAI entsprechen dem die Modi read-only, workspace-write und danger-full-access, das Netzwerk ist standardmäßig aus. Das Flag --yolo (Alias für --dangerously-bypass-approvals-and-sandbox) schaltet Zustimmungen und Sandbox gleichzeitig ab, heben wir es uns also für Container auf.

Schritt 3: Wo bewahrt man API-Schlüssel auf?

Die einfachste Regel: Ein Schlüssel kommt nicht in den Code und nicht ins Repository. Anthropic empfiehlt, den Schlüssel nicht direkt in Code oder Konfigurationsdateien zu schreiben und .env-Dateien in .gitignore aufzunehmen. OpenAI rät, Schlüssel über Umgebungsvariablen oder einen Secrets-Manager zu übergeben und regelmäßig zu rotieren.

In der Praxis:

1. Getrennte Schlüssel für Entwicklung, Tests und Produktion (auch das steht in Anthropics Empfehlungen). Ein Leck legt dann nicht alles lahm.
2. Der Schlüssel für den Agenten ist ein eigener Schlüssel mit eigenem Limit, nicht unser Hauptschlüssel.
3. Nach einem Leck widerrufen wir den Schlüssel sofort und suchen erst danach die Ursache.

Interessant: GitHub fängt einen Teil der Lecks selbst ab. Landet ein Claude-Schlüssel in einem öffentlichen Repository, benachrichtigt GitHub Anthropic, und Anthropic deaktiviert den Schlüssel automatisch.

Schritt 4: Wie richtet man Ausgabenlimits ein?

Ein Limit verhindert kein Leck, begrenzt aber die Rechnung, wenn ein Schlüssel in falsche Hände gerät.

1. Anthropic. In der Claude Console gehen wir auf die Seite Billing (platform.claude.com/settings/billing) und klicken im Abschnitt Spend limits auf Adjust limit oder Set limit. Limits lassen sich auch pro Workspace setzen, mit Ausnahme des Standard-Workspace.
2. OpenAI. In den Projekteinstellungen öffnen wir Limits, setzen ein Monthly spend limit und aktivieren Enforce a hard limit. Achtung: Ausgabenwarnungen („Spend alerts do not enforce a cap“) blockieren nichts, und das Limit selbst greift mit Verzögerung, die Ausgaben können es also leicht überschreiten.

Eine gute Gewohnheit ist ein Projekt (oder Workspace) pro Agent, jeweils mit eigenem Schlüssel und Limit.

Schritt 5: Wie fängt man Secrets ab, bevor sie durchsickern?

Agenten schreiben viel Code und committen gern, deshalb lohnt sich eine Automatik, die einen Schlüssel vor dem Push stoppt.

1. Push Protection auf GitHub. Laut Dokumentation blockiert sie Pushes mit Secrets, bevor sie ins Repository gelangen. Für Benutzerkonten ist sie bei öffentlichen Repositorys standardmäßig an, auf Repository-Ebene ist sie standardmäßig aus und erfordert GitHub Secret Protection.
2. Gitleaks lokal. Installation mit brew install gitleaks, dann scannen wir ein Verzeichnis oder die Git-Historie (README):

gitleaks dir -v .
gitleaks git -v .

3. TruffleHog prüft zusätzlich, ob ein gefundenes Secret noch funktioniert (README). Mit diesem Werkzeug hat NorForge bestätigt, dass ein Teil der Secrets auf den Cairn-Panels aktiv war:

trufflehog filesystem path/to/dir

Worauf sollte man bei MCP-Servern achten?

Ein MCP-Server ist Code, der mit unseren Berechtigungen läuft. Die Claude-Code-Dokumentation empfiehlt, eigene Server zu schreiben oder nur solche von vertrauenswürdigen Anbietern zu nutzen, und weist darauf hin, dass Anthropic MCP-Server nicht prüft.

Die MCP-Sicherheitsempfehlungen (Entwurfsfassung der Spezifikation) ergänzen einige konkrete Punkte:

1. Der Client sollte den vollständigen Befehl zeigen, der einen lokalen Server startet, ungekürzt. Das Angriffsbeispiel aus der Spezifikation ist ein harmlos wirkendes npx, hinter dem ein curl steckt, das ~/.ssh/id_rsa an einen fremden Server schickt.
2. Lokale Server laufen am besten in einer Sandbox mit minimalen Berechtigungen und über den Transport stdio.
3. Ein Server darf keine Tokens annehmen, die nicht für ihn ausgestellt wurden („Token Passthrough“ ist verboten).
4. OAuth-Berechtigungen vergeben wir schrittweise, ohne breite Scopes wie *, all oder full-access.

FAQ

Reichen deny-Regeln in Claude Code, um eine .env-Datei zu schützen?

Nicht ganz. Sie blockieren die eingebauten Werkzeuge und erkannte Befehle wie cat, aber nicht grep -r oder beliebige Unterprozesse. Vollen Schutz auf Systemebene gibt erst die Sandbox mit filesystem.denyRead.

Was tun, wenn ein API-Schlüssel geleakt wurde?

Ihn sofort im Dashboard des Anbieters widerrufen, einen neuen erzeugen, ihn in allen Anwendungen austauschen und den letzten Verbrauch im Konto prüfen. Mehr dazu im Beitrag über das Datenleck bei OpenCode.

Was ist Prompt Injection bei KI-Agenten?

Versteckte Anweisungen in Inhalten, die der Agent liest (Webseiten, Dateien, E-Mails). Der Agent kann sie ausführen, als kämen sie von uns. Deshalb sollten riskante Aktionen unsere Zustimmung erfordern, und der Agent sollte keinen Zugriff auf Secrets haben.

Funktioniert die Sandbox unter Windows?

In Claude Code nur über WSL2. Unter nativem Windows laufen Befehle ohne Sandbox.