API-Schlüssel vor KI-Agenten schützen

Was es bedeutet, Geheimnisse von KI-Agenten fernzuhalten

Ein KI-Agent ist ein normaler Linux-Prozess, der Befehle ausführt. Jede Umgebungsvariable, die dieser Prozess enthält, kann von dem von ihm ausgeführten Code gelesen werden. Ein API-Schlüssel in der Umgebung des Agenten kann daher an jeden erreichbaren Host gesendet werden. Geheimnisse vom Agenten fernzuhalten bedeutet, ihm statt des Schlüssels einen Zugriff zu geben: ein kurzlebiges Token mit begrenztem Geltungsbereich oder einen Platzhalter, den ein anderes System an der Netzwerkgrenze gegen den echten Wert austauscht.

Dies ist keine Geschichte über ein feindselig werdendes Modell. Der Mechanismus ist nüchterner. Ein Agent liest eine Webseite, eine README-Datei oder einen Issue-Kommentar mit Anweisungen und befolgt sie, weil ein Sprachmodell nicht zwischen von Ihnen geschriebenem und abgerufenem Text unterscheidet. Das ist Prompt-Injection. Sobald sie auftritt, wird der Schaden genau durch eine Sache begrenzt: durch das, was der Prozess lesen kann. Wenn Sie noch keine Grenze eingerichtet haben, beschreibt einen Coding-Agenten sicher auf einem Server auszuführen die Isolationsstufen, auf denen dieser Leitfaden aufbaut.

Das Bedrohungsmodell in einfachen Worten

Führen Sie dies als der Benutzer aus, unter dem Ihr Agent läuft.

tr '\0' '\n' < /proc/self/environ | grep -iE 'key|token|secret|password'

Jede von diesem Befehl ausgegebene Zeile entspricht einer HTTP-Anfrage an den Server eines Fremden. Sehen Sie sich nun an, welche Daten sich auf dem Datenträger in der Nähe des Agents befinden.

grep -rIl --exclude-dir=.git -e 'API_KEY' -e 'SECRET' ~/projects
find ~ -maxdepth 3 -name '.env' -o -name 'credentials' -o -name '*.pem'

Ein Agent mit einer Shell benötigt keinen ausgefeilten Exploit, um diese Daten nach außen zu übertragen. Vier gewöhnliche Wege reichen aus. Alle vier sehen im Log wie normale Arbeit aus:

• Ein ausgehendes curl oder fetch zu einem beliebigen Host, wobei der Wert in einer Abfragezeichenfolge steht.
• Ein git commit und git push zu einem Repository, in das der Agent schreiben kann.
• Ein Installationsskript eines Pakets, das beliebigen Code unter dem Benutzer des Agents ausführt.
• Eine DNS-Abfrage für einen Hostnamen, der den Wert enthält. Diese verlässt das System auch dann, wenn HTTP-Egress blockiert ist.

Sie können dieses Problem nicht durch weitere Prüfungen lösen. Die Lösung besteht darin, sicherzustellen, dass sich keine wertvollen Daten in Reichweite befinden.

Ein Geheimnis im Arbeitsbaum ist ein Geheimnis im Kontextfenster

Ein Agent liest Dateien. Eine .env-Datei im Repository, in dem er arbeitet, wird gelesen. Sobald sie gelesen wurde, befindet sie sich im Kontextfenster. Damit steht sie im Transkript, in jedem von Ihnen geführten Protokoll und in allem, was der Agent anschließend schreibt.

Zuvor, als der Schlüssel im Arbeitsbaum lag, in dem der Agent arbeitet:

cd ~/projects/billing
cat .env
# STRIPE_SECRET_KEY=sk_live_...
# DATABASE_URL=postgres://app:hunter2@db.internal:5432/billing

Danach, als die Datei außerhalb seiner Reichweite verschoben wurde:

sudo install -d -m 750 -o root -g agent-review /etc/agent-review
sudo install -m 640 -o root -g agent-review ~/projects/billing/.env /etc/agent-review/billing.env
rm ~/projects/billing/.env

Der Benutzer des Agenten kann die Datei nicht mehr öffnen, weil der Arbeitsbaum sie nicht mehr enthält. Deny-Regeln in der eigenen Konfiguration des Agenten bilden eine zweite Schutzschicht, nicht die erste. Claude Code liest Berechtigungsregeln aus .claude/settings.json im Projekt:

{
  "permissions": {
    "deny": ["Read(./.env)", "Read(./secrets/**)", "Read(./**/*.pem)"]
  }
}

Damit wird verhindert, dass der Agent beim Erkunden versehentlich eine Datei öffnet. Eine eingeschleuste Anweisung, die base64 .env ausführt, wird dadurch nicht verhindert, weil es sich dabei um einen Shell-Befehl und nicht um einen Dateizugriff handelt. Betrachten Sie die Konfiguration als Schutzvorgabe und die Dateisystemberechtigung als Barriere. Dieselbe Trennung gilt innerhalb von Containern: Umgebungsdateien und Geheimnisse in Docker Compose behandelt die entsprechende Variante dieses Problems eine Ebene tiefer.

Geben Sie jedem Agenten einen eigenen Benutzer ohne privilegierten Zugriff

Wenn der Agent unter Ihrem Benutzerkonto ausgeführt wird, erbt er Ihre SSH-Schlüssel, Ihre Cloud-Anmeldedaten und Ihren Shell-Verlauf. Ein separater Benutzer erfordert einen Befehl und entfernt all diese Zugriffe.

sudo adduser --disabled-password --gecos "" agent-review
sudo chmod 700 /home/agent-review
sudo -u agent-review cat ~/.ssh/id_ed25519

Die letzte Zeile muss mit cat: /home/you/.ssh/id_ed25519: Permission denied fehlschlagen. Wenn sie stattdessen einen Schlüssel ausgibt, ist Ihr Home-Verzeichnis für die Gruppe oder für alle Benutzer lesbar. chmod 700 ~ behebt das. Fügen Sie den Agentenbenutzer nicht zu sudo hinzu. Geben Sie ihm keine NOPASSWD-Regel, die über den einen tatsächlich benötigten Befehl hinausgeht. Benutzer mit minimalen Berechtigungen auf einem VPS erläutert die Details zu Gruppen und sudoers.

Auf einem Cloud-VPS sollten Sie außerdem eine weitere Grenze einrichten. Der Instanzmetadatendienst antwortet unter einer festen Link-Local-Adresse. Häufig gibt er jedem anfragenden Prozess Anmeldedaten für Rollen aus.

sudo iptables -A OUTPUT -m owner --uid-owner agent-review -d 169.254.169.254 -j REJECT

Prüfen Sie dies von der Seite des Agenten. sudo -u agent-review curl -s --max-time 3 http://169.254.169.254/ sollte nichts ausgeben und mit einem Fehlercode ungleich null beendet werden, da das Paket verworfen wird, bevor es den Rechner verlässt.

Credentials an der Grenze injizieren

Das Muster, das dieses Problem tatsächlich löst, ist die Injektion von Credentials. Der Agent hält niemals einen echten Schlüssel. Er sendet seine Anfrage über ein lokales Gateway. Das Gateway ersetzt dabei einen Platzhalter durch das echte Secret. Das Secret liegt im Speicher des Gateways, in einem anderen Prozess und im Besitz eines anderen Benutzers.

OneCLI ist eine Open-Source-Implementierung dieses Ansatzes. Sie steht unter der Apache-2.0-Lizenz und läuft als Container neben dem Agenten. Im Juli 2026 dokumentiert das Projekt folgende Einrichtung:

git clone https://github.com/onecli/onecli.git
cd onecli
docker compose -f docker/docker-compose.yml up -d --wait

Das Dashboard lauscht an Port 10254 und das Gateway an Port 10255. Sie speichern das echte Credential einmal. Danach geben Sie jedem Agenten anstelle des Schlüssels einen Platzhalterwert sowie einen eigenen, eingeschränkten Zugriffstoken. Diesen sendet der Agent in einem Proxy-Authorization-Header. Das Gateway ordnet die ausgehende Anfrage anhand von Host und Pfad zu, entschlüsselt das passende Credential und ersetzt den Platzhalter. Die Umgebung des Agenten enthält keine verwertbaren Geheimnisse.

Der Vorteil liegt nicht in der Verschlüsselung. Entscheidend ist, dass die Frage „Was hat dieser Agent wann verwendet?“ zu einer Log-Abfrage wird. Sie lesen einen einzigen Audit-Trail, anstatt zu raten, in welcher von sechs Umgebungen eine Kopie des Schlüssels lag.

Übergeben Sie das Geheimnis an den Prozess, nicht an die Umgebung

Wenn Sie den Agent unter systemd ausführen, benötigen Sie überhaupt keine Umgebungsvariablen. LoadCredential= legt das Geheimnis in einem privaten Verzeichnis ab, das nur dieser Dienst lesen kann. In der Unit-Datei wird es als %d und innerhalb des Prozesses als $CREDENTIALS_DIRECTORY bereitgestellt. Der Wert erscheint nie in /proc/<pid>/environ. Daher kann ps eww ihn nicht anzeigen. Das Verzeichnis wird gelöscht, sobald der Dienst beendet wird.

Verschlüsseln Sie die Zugangsdaten zunächst für den Rechner. Diese Befehle stammen aus der systemd-Dokumentation und funktionieren mit systemd 250 oder neuer. Das umfasst Ubuntu 24.04 und Debian 13:

echo -n 'sk-example-value' > /tmp/plain.txt
sudo systemd-creds encrypt --name=api_key /tmp/plain.txt /etc/credstore/api_key.cred
shred -u /tmp/plain.txt
sudo systemd-run -P --wait -p LoadCredentialEncrypted=api_key:/etc/credstore/api_key.cred \
  systemd-creds cat api_key

Der letzte Befehl gibt sk-example-value aus. Damit ist bestätigt, dass die verschlüsselte Datei auf diesem Host entschlüsselt werden kann. Verweisen Sie anschließend in der Unit darauf:

[Service]
User=agent-review
LoadCredentialEncrypted=api_key:/etc/credstore/api_key.cred
Environment=AGENT_KEY_FILE=%d/api_key
ExecStart=/usr/local/bin/agent-worker

Ihr Agent-Code öffnet die Datei unter $AGENT_KEY_FILE, wenn er den Wert benötigt. Ein Dateizugriff ist nur kurzzeitig. Eine Umgebungsvariable bleibt während der gesamten Laufzeit des Prozesses und in jedem von ihm gestarteten Kindprozess bestehen.

Bevorzugen Sie kurzlebige Tokens gegenüber langlebigen Schlüsseln

Ein Schlüssel ohne Ablaufdatum bleibt gültig, sobald er Monate später in einem Log oder Transkript auftaucht. Wenn der Dienst ein Sitzungstoken anbietet, verwenden Sie das Sitzungstoken und legen Sie die kürzeste für die Aufgabe mögliche Gültigkeitsdauer fest.

aws sts assume-role \
  --role-arn arn:aws:iam::123456789012:role/agent-readonly \
  --role-session-name agent-review \
  --duration-seconds 900

Fünfzehn Minuten ist die kürzeste von AWS STS (security token service) akzeptierte Dauer. Für eine einzelne Agent-Aufgabe reicht sie normalerweise aus. Erstellen Sie für GitHub einen eigenen gh-Login für den Agent-Benutzer. Verwenden Sie dafür ein fein abgestuftes Token, das auf das einzelne Repository beschränkt ist, in dem der Agent arbeitet. Dadurch gibt gh auth token innerhalb dieser Sitzung etwas zurück, das auf keine anderen Ressourcen zugreifen kann. Schränken Sie zuerst nach Ressource und danach nach Zeit ein.

Prüfen und weiter prüfen

Führen Sie nach jeder Änderung an der Einrichtung eines Agents drei Prüfungen durch. Führen Sie sie als Benutzer des Agents aus, nicht als Sie selbst.

sudo -u agent-review env | grep -iE 'key|token|secret'
sudo -u agent-review ls -la /home/you/ 2>&1 | head -3
sudo -u agent-review curl -s -o /dev/null -w '%{http_code}\n' --max-time 5 https://api.github.com/user

Die erste Prüfung sollte überhaupt nichts ausgeben. Die zweite sollte ls: cannot open directory '/home/you/': Permission denied ausgeben. Die dritte zeigt, welche Identität der Netzwerkpfad des Agents präsentiert. Genau diese Frage soll das Gateway-Muster beantworten: Ein 401 bedeutet, dass der Agent keine eigenen GitHub-Anmeldedaten verwendet. Ein 200 bedeutet, dass er eigene verwendet. Sie müssen dann wissen, welches Token er verwendet. Wenn Sie Agents unbeaufsichtigt ausführen, beschreibt die Kontrolle der AI-Agent-Kosten auf einem VPS die zugehörigen Budgetgrenzen, die diese Zugriffsbeschränkungen ergänzen.

FAQ

Kann ich dem Modell einfach vertrauen, dass es meine Schlüssel nicht preisgibt?

Nein, denn in diesem Bedrohungsmodell ist das Modell nicht der Angreifer. Der Agent liest Text aus Webseiten, Repositories und Issue-Trackern. Dieser Text kann Anweisungen enthalten. Das Modell kann Ihre Anweisungen nicht zuverlässig von abgerufenem Text unterscheiden. Jede Kontrolle, die davon abhängt, dass das Modell die richtige Entscheidung trifft, versagt, sobald eine eingeschleuste Anweisung überzeugend ist. Die Kontrolle muss daher stattdessen im Betriebssystem oder im Netzwerk liegen.

Sind Umgebungsvariablen für Agent-Secrets wirklich so problematisch?

Sie sind in einer bestimmten Hinsicht problematisch: Sie werden vererbt. Jeder vom Agenten gestartete Kindprozess erhält eine Kopie. Dazu gehören ein Build-Skript, ein Test-Runner und jeder Installations-Hook eines Pakets. Die Variablen sind außerdem über /proc/<pid>/environ für denselben Benutzer lesbar. Alles, was der Agent ausführt, kann sie daher lesen, ohne dass der Agent sie weitergeben muss. Eine Datei, die erst zum Verwendungszeitpunkt mit LoadCredential= oder über ein Gateway gelesen wird, begrenzt die Offenlegung auf diesen Zeitpunkt.

Löst es dieses Problem von selbst, wenn ich Secrets in einem Vault ablege?

Nur teilweise. Ein Vault behebt die Speicherung. Er behebt nicht den letzten Schritt, bei dem etwas das Secret aus dem Vault abruft und es dem Agenten als Umgebungsvariable übergibt. Damit befinden Sie sich wieder am Ausgangspunkt. Entscheidend ist, wer die Ersetzung durchführt. Ruft der Agent das Secret ab, verfügt der Agent über das Secret. Führt ein Gateway oder das Init-System die Ersetzung außerhalb des Prozesses des Agenten durch, hält der Agent das Secret nie in seinem Prozess.

Wie erkenne ich, ob ein Agent bereits etwas preisgegeben hat?

Nachträglich können Sie das normalerweise nicht feststellen. Das spricht für ein Gateway. Ohne Gateway sind Ihre Hinweise über die Shell-History, das Transkript des Agenten und Protokolle ausgehender Verbindungen verteilt. Letztere zeichnen Sie wahrscheinlich nicht auf. Mit einem Credential-Gateway ist jede Verwendung eines Credentials eine einzelne Zeile mit einer Agentenidentität und einem Zeitstempel. Wenn Sie eine Offenlegung vermuten, rotieren Sie zuerst den Schlüssel und untersuchen Sie den Vorfall danach. Rotation ist günstig, Gewissheit nicht.

Was sollte ich heute mindestens tun?

Verschieben Sie jede .env-Datei aus den Verzeichnissen, in denen Ihre Agenten arbeiten, und erstellen Sie pro Agent einen unprivilegierten Benutzer. Diese beiden Änderungen dauern etwa zehn Minuten. Sie schließen den häufigsten Angriffsweg, nämlich dass ein Agent eine Credential-Datei liest, die keinen Grund hatte, neben dem Code zu liegen. Das Gateway und kurzlebige Tokens sind der nächste Schritt, nicht der erste. Dieser Ausgangspunkt gilt für jede Agenten-Laufzeitumgebung, einschließlich einen autonomen Agenten sicher auf einem VPS betreiben.