KI-Agenten greifen auf externe Dienste zu – und brauchen dafür Zugangsdaten. API-Schlüssel, OAuth-Token, Datenbankpasswörter, Webhook-Secrets: In LLM-basierten Automatisierungsworkflows häufen sich Credentials schneller an als in klassischen Anwendungen. Gleichzeitig sind die Sicherheitsrisiken höher, weil Agenten dynamisch Aktionen ausführen, oft autonomer agieren als traditionelle Software und die Angriffsfläche durch Prompt-Injection-Risiken erweitert wird. Secrets-Management ist deshalb keine optionale Ergänzung, sondern ein strukturelles Sicherheitserfordernis für jeden, der KI-Agenten produktiv betreibt.
Warum KI-Agenten besondere Anforderungen stellen
Klassische Anwendungen laden Zugangsdaten beim Start einmalig, verwenden sie für klar definierte Operationen und beenden die Verbindung. KI-Agenten funktionieren anders: Sie entscheiden zur Laufzeit, welche Tools und APIs sie aufrufen, kombinieren Informationen aus verschiedenen Quellen und führen mehrstufige Aktionsfolgen aus. Das bedeutet:
- Zugangsdaten werden zu unterschiedlichen Zeitpunkten im Ausführungsgraph benötigt
- Der Scope eines Credentials ist oft breiter als für eine einzelne Operation nötig
- Ein kompromittierter Agenten-Kontext kann Zugriff auf mehrere Systeme ermöglichen
- Prompt-Injection-Angriffe können versuchen, Credentials aus dem Kontext zu extrahieren oder für unbeabsichtigte Operationen zu verwenden
Das Grundprinzip bleibt dasselbe wie in jeder sicheren Anwendungsarchitektur: Zugangsdaten gehören nicht in Code, nicht in Umgebungsvariablen in Logs und nicht in Prompt-Templates. Die Umsetzung erfordert jedoch für KI-Agenten spezifisch angepasste Kontrollen.
Secrets nicht in den Prompt – niemals
Der kritischste Fehler in KI-Agenten-Implementierungen ist das direkte Einbetten von Credentials in System-Prompts oder Tool-Beschreibungen. Es mag verlockend erscheinen, einem Agenten seinen API-Key direkt im Kontext mitzugeben – aber das bedeutet, dass der vollständige Prompt-Kontext den Credential enthält. Dieser Kontext kann in Logs landen, in Debug-Ausgaben erscheinen, durch Prompt-Injection extrahiert werden oder beim Aufruf externer APIs als Teil des Payloads mitgesendet werden.
Die korrekte Vorgehensweise: Der Agent erhält keinen direkten Zugriff auf Credentials. Stattdessen ruft er ein Tool auf, das serverseitig das Secret abruft und die gesicherte Operation durchführt – ohne den Key selbst je in den Agenten-Kontext zurückzuliefern. Das Credential bleibt im Vault, der Agent erhält nur das Ergebnis der autorisierten Aktion.
Zentrale Secrets-Stores: Die technische Grundlage
Für produktive KI-Agenten-Umgebungen empfiehlt sich ein dedizierter Secrets-Store. Die verbreiteten Optionen:
HashiCorp Vault
Vault ist der etablierte Standard für zentrale Secrets-Verwaltung in der Unternehmensinfrastruktur. Relevante Features für KI-Agenten-Umgebungen sind dynamische Secrets (Credentials werden on-demand generiert und nach Ablauf automatisch invalidiert), fein granulare Zugriffsrichtlinien pro Pfad und Audit-Logging jedes Zugriffs. Vault lässt sich über eine API ansprechen und gut in Orchestrierungssysteme integrieren.
Cloud-native Lösungen
AWS Secrets Manager, Google Cloud Secret Manager und Azure Key Vault bieten ähnliche Funktionalität mit nativer Integration in die jeweilige Cloud-Infrastruktur. Für Teams, die bereits auf einem der großen Cloud-Anbieter arbeiten, ist der Overhead gering. Workload Identity Federation ermöglicht es, Agenten-Prozessen ohne statische Zugangsdaten automatisch kurzzeitige Credentials aus dem Cloud-IAM-System zuzuweisen.
Kubernetes Secrets mit Operator-Unterstützung
Für containerisierte Agenten-Umgebungen auf Kubernetes bietet die Kombination aus externen Secret-Providern (External Secrets Operator) und Kubernetes Secrets eine bewährte Alternative. Secrets werden aus dem zentralen Store synchronisiert und als gemountete Volumes oder Umgebungsvariablen in Pods bereitgestellt – ohne dass der Source-Code den Provider kennen muss.
Least Privilege konsequent umsetzen
Jeder KI-Agent sollte ausschließlich die Berechtigungen erhalten, die er für seine spezifischen Aufgaben benötigt – und nicht mehr. Das klingt selbstverständlich, wird aber in der Praxis häufig vernachlässigt: Oft erhalten Agenten weitreichende API-Keys, weil das die einfachere initiale Lösung ist.
Konkret bedeutet Least Privilege für KI-Agenten:
- Separate Credentials pro Agent und pro Umgebung (Dev/Staging/Prod)
- Scope-eingeschränkte API-Tokens statt Master-Keys (z.B. read-only wo Schreibzugriff nicht benötigt wird)
- Kurze TTLs für automatisch rotierte Credentials
- Explizite Deny-Regeln für kritische Operationen wie Datenlöschung oder Rechtevergabe
- Regelmäßige Überprüfung, welche Credentials tatsächlich genutzt werden
Audit-Logging und Anomalieerkennung
Zugangsdaten für KI-Agenten sollten vollständig auditiert werden. Jeder Abruf eines Secrets, jede API-Anfrage mit einem Agenten-Credential und jede unerwartete Zugriffsanfrage sollten protokolliert sein – nicht nur für Compliance-Zwecke, sondern als Frühwarnsystem.
Konkrete Anomalien, auf die Alerting konfiguriert werden sollte:
- Credential-Abrufe außerhalb normaler Betriebszeiten
- Ungewöhnlich hohe API-Aufruffrequenzen durch einen Agenten
- Zugriffe auf Secrets, die dem Agenten nicht zugewiesen sein sollten
- Fehlerhafte Authentifizierungsversuche mit bekannten Agenten-Identitäten
Prompt-Injection: Zugangsdaten als Angriffsziel
Prompt-Injection-Angriffe versuchen, einen KI-Agenten durch manipulierte Eingaben zu Aktionen zu verleiten, die nicht vorgesehen sind – einschließlich des Exfiltrierens von Informationen aus dem Kontext. Wenn ein Agent Zugangsdaten im Kontext trägt, ist das Risiko entsprechend hoch.
Schutzmaßnahmen umfassen: strenge Input-Validierung vor dem Einbetten in Agenten-Kontexte, Tool-Implementierungen, die Credentials nie zurück in den Agenten-Kontext schreiben, Ausgabe-Filter, die Muster wie API-Key-Formate in Agent-Outputs erkennen, und regelmäßige Red-Team-Tests mit Injection-Versuchen.
Secrets Rotation als operativer Standard
Statische Langzeit-Credentials sind ein strukturelles Risiko. Wenn ein Key kompromittiert wird, ist der Schaden potenziell dauerhaft, bis er manuell rotiert wird. Automatische Rotation löst dieses Problem: Credentials werden in konfigurierbaren Intervallen neu generiert, alte werden invalidiert. Vault und Cloud-Secrets-Manager unterstützen das nativ.
Für Teams, die Rotation implementieren, gilt: Der Agenten-Code muss so geschrieben sein, dass er Credentials dynamisch abruft und nicht im Arbeitsspeicher cached. Ein Prozess, der beim Start einen Key lädt und diesen stundenlang verwendet, profitiert kaum von Rotation. Die Secrets-Store-Integration muss dem Agenten erlauben, beim nächsten Credential-Bedarf einen frischen Key zu erhalten.
Fazit: Secrets-Management ist Pflicht, keine Kür
KI-Agenten sind keine blackboxen Software-Schichten, die Credentials intern verwalten. Sie sind dynamische Systeme, die zur Laufzeit entscheiden, was sie tun – und dafür brauchen sie zuverlässige, sichere Zugangsdaten-Infrastruktur. Wer Agenten in Produktion betreibt, ohne ein durchdachtes Secrets-Management-Konzept, riskiert nicht nur Datenverlust, sondern auch kompromittierte nachgelagerte Systeme.
Die gute Nachricht: Die notwendigen Werkzeuge sind ausgereift und gut dokumentiert. Ein dedizierter Secrets-Store, konsequentes Least-Privilege, vollständiges Audit-Logging und Schutz gegen Prompt-Injection sind umsetzbare Maßnahmen, die den Sicherheitsstatus von KI-Agenten-Deployments fundamental verbessern.
Quellen: HashiCorp Vault Dokumentation, OWASP Top 10 for LLM Applications, AWS Secrets Manager Best Practices, NIST SP 800-204B (Securing Microservices).
