Zugangsdaten für KI-Agenten: Schlüssel, Tokens und Identitäten sicher verwalten

Von Wladimir Neuberger · Aktualisiert 27.10.2026

Warum Zugangsdaten bei Agenten besonders heikel sind

Ein Agent handelt mit den Rechten, die man ihm gibt. Seine Zugangsdaten bestimmen deshalb, wie groß der Schaden bei einem Fehler oder einem Angriff werden kann. Die OWASP-Liste für agentische Anwendungen führt das als „Identity and Privilege Abuse“ (ASI03). Nach der Zusammenfassung von Giskard besitzen Agenten oft keine eigene, geregelte Identität, ihre Berechtigungen wechseln dynamisch, und genau diese Lücke in der Zuordnung lässt sich missbrauchen.

Ein hypothetisches Beispiel: Ein Agent für Terminbuchung nutzt das persönliche Konto einer Mitarbeiterin, weil das am schnellsten einzurichten war. Wird er durch einen präparierten Kalendereintrag umgelenkt, handelt er mit allem, was dieses Konto darf, und im Protokoll des Zielsystems erscheint nur der Name der Mitarbeiterin. Wer was getan hat, lässt sich dann kaum noch trennen.

Eigene Identität statt geteilter Konten

Die folgenden Punkte sind unsere Empfehlung. Sie folgen dem Grundsatz des OWASP-Hinweises zu übermäßiger Handlungsfreiheit (LLM06:2025), Rechte auf das Nötige zu beschränken und Aktionen im Kontext des jeweiligen Nutzers mit minimalen Rechten auszuführen, etwa über OAuth mit engen Berechtigungen.

• Ein Agent, eine Identität: Jeder Agent bekommt ein eigenes Dienstkonto oder einen eigenen Schlüssel, nie das Konto einer Person und nie ein gemeinsames Administratorkonto.
• Kein Wiederverwenden: Dieselben Zugangsdaten werden nicht für mehrere Agenten, Umgebungen oder Zwecke genutzt. So bleibt sichtbar, wer gehandelt hat, und ein Widerruf trifft nur einen Agenten.
• Im Namen des Nutzers: Wo ein Agent für einen Menschen arbeitet, sollte er dessen eng begrenzte Berechtigung nutzen, statt mit einem Allzweck-Schlüssel mehr zu können als der Nutzer selbst.
• Prüfen im Zielsystem: Ob eine Aktion erlaubt ist, entscheidet das angebundene System, nicht das Sprachmodell. OWASP rät, Autorisierung in nachgelagerten Systemen umzusetzen, statt sie dem Modell zu überlassen.

Eng gefasst und kurzlebig

Der OWASP-Cheat-Sheet zum Secrets Management verlangt, dass Secrets nur die minimalen Rechte haben, die ihre Aufgabe erfordert. Er empfiehlt außerdem, wo möglich dynamische Secrets zu verwenden, um die Wiederverwendung von Zugangsdaten zu verringern, und Secrets regelmäßig zu rotieren, damit gestohlene Zugangsdaten nur kurz funktionieren.

• Minimal im Umfang: Lesen statt Schreiben, ein Postfach statt aller, eine Datenbanktabelle statt der ganzen Datenbank. Die MCP-Sicherheitshinweise warnen davor, breite Berechtigungen auf Vorrat zu vergeben, weil ein gestohlenes Token dann mehr Schaden anrichtet und sich schwerer widerrufen lässt.
• Kurze Laufzeit: Zugangsdaten, die nach Minuten oder Stunden ablaufen, sind für Angreifer weniger wert als dauerhafte. Secret-Manager wie HashiCorp Vault können zeitlich befristete Zugangsdaten für einen Dienst erzeugen und sie nach Ablauf automatisch widerrufen.
• Pro Aufgabe statt pro Dauerbetrieb: Ein Agent, der nur zeitweise Schreibrechte braucht, bekommt sie für diese Aufgabe und gibt sie danach zurück.
• Ablauf einplanen: Der Agent muss mit einem abgelaufenen Schlüssel sauber umgehen können, etwa durch Neuanforderung, statt abzustürzen oder auf einen Ersatzschlüssel mit mehr Rechten auszuweichen.

Secrets gehören nicht in Prompts, Kontext oder Logs

Alles, was im Kontext eines Modells steht, kann das Modell ausgeben und kann von Angreifern durch geschickte Eingaben herausgelockt werden. OWASP schreibt zum Risiko „System Prompt Leakage“ (LLM07:2025), sensible Daten wie Zugangsdaten und Verbindungszeichenfolgen gehörten nicht in den Systemprompt. Der Systemprompt solle weder als Geheimnis noch als Sicherheitskontrolle gelten. Solche Informationen sollen in Systeme ausgelagert werden, auf die das Modell nicht direkt zugreift.

• Werkzeug hält das Secret, nicht das Modell: Der Agent ruft ein Werkzeug auf, das Werkzeug authentifiziert sich selbst. Das Modell sieht nie den Schlüssel, sondern nur das Ergebnis.
• Nicht in Quellcode und Konfiguration: Der OWASP-Cheat-Sheet nennt hartkodierte Secrets im Quellcode und in Docker-ENV/ARG-Anweisungen als zu vermeiden und rät von Umgebungsvariablen ab, weil sie in Logs und Systemabzügen auftauchen können.
• Nie protokollieren: Secrets sollen nicht in Logs stehen, es sei denn verschlüsselt oder maskiert. Prüfen Sie auch Fehlermeldungen und Werkzeug-Rückgaben, die Schlüssel zurückspiegeln könnten.
• Rückgaben filtern: Schlüssel, die in Antworten auftauchen, werden maskiert, bevor sie in den Kontext oder ins Protokoll gelangen. Das ist unsere Empfehlung und ersetzt nicht die Trennung der Schlüssel vom Modell.

Ein Schlüssel im Prompt ist ein Schlüssel, den der Agent preisgeben kann. Halten Sie Zugangsdaten dort, wo das Modell sie nicht lesen kann.

Tresor, Rotation und Nachvollziehbarkeit

Der OWASP-Cheat-Sheet empfiehlt, Speicherung, Ausgabe, Prüfung, Rotation und Verwaltung von Secrets zu zentralisieren. Für Agenten heißt das, einen Secret-Manager zu nutzen, statt Schlüssel in Dateien und Chat-Verläufen zu verteilen.

• Zentraler Tresor: Ein Secret-Manager speichert Schlüssel, vergibt sie an Dienste und kennt ihren Lebenslauf. Der Zugriff ist je Secret begrenzt, nicht jeder Mitarbeiter und nicht jeder Agent sieht alles.
• Rotation: Schlüssel werden regelmäßig und nach jedem Verdacht erneuert. Dynamische Secrets, die der Tresor selbst anlegt und löscht, nehmen diese Arbeit ab.
• Audit: Der Cheat-Sheet verlangt, zu protokollieren, wer ein Secret angefordert, verwendet, geändert oder beendet hat, und die Protokolle gegen Manipulation zu schützen.
• Pipelines mitdenken: Der Cheat-Sheet rät, CI/CD-Werkzeuge wie eine Produktionsumgebung zu behandeln. Auch dort gelten minimale Rechte und Rotation.

Wenn ein Schlüssel abgeflossen ist

Planen Sie den Ernstfall, bevor er eintritt. Die Leitlinie von GitHub zu offengelegten Secrets ist eindeutig: Jedes geleakte Secret ist als sofort kompromittiert zu betrachten, und der wichtigste Schritt ist der Widerruf beim Anbieter des Secrets. Der OWASP-Cheat-Sheet fordert ebenfalls den sofortigen Widerruf offengelegter Schlüssel.

• Widerrufen vor Aufräumen: Zuerst den Schlüssel beim Anbieter sperren. Befürchten Sie Ausfälle, kann nach der GitHub-Leitlinie zuerst ein neues Secret mit gleichen Rechten bereitgestellt, die Anwendung umgestellt und danach das alte widerrufen werden.
• Ersetzen: Einen neuen Schlüssel über einen automatisierten Ablauf ausstellen und überall eintragen, wo der alte genutzt wurde.
• Nicht beim Löschen aus dem Code stehen bleiben: Laut GitHub verhindert das Entfernen aus dem Code, ein neuer Commit oder ein neu angelegtes Repository nicht, dass das Secret missbraucht wird. Es kann zudem im Verlauf stehen bleiben.
• Missbrauch prüfen: Nach der Umstellung in den Audit-Protokollen von Anbieter und Plattform nachsehen, ob der Schlüssel während der Offenlegung unbefugt genutzt wurde.
• Not-Aus üben: Der Weg, einen Agenten zu stoppen und seine Zugangsdaten zu sperren, muss bekannt sein und vorab ausprobiert werden. Das ist unsere Empfehlung.

Häufige Fragen

Quellen

• OWASP Cheat Sheet Series — Secrets Management Cheat Sheet
• OWASP GenAI Security Project — LLM07:2025 System Prompt Leakage
• OWASP GenAI Security Project — LLM06:2025 Excessive Agency
• Giskard — OWASP Top 10 for Agentic Applications 2026: Security Guide (u. a. ASI03 Identity and Privilege Abuse)
• GitHub Docs — Remediating a leaked secret
• HashiCorp — Vault Validated Designs: Dynamic secrets management
• Model Context Protocol — Security Best Practices (Abschnitt „Scope Minimization“)

Die Einordnung beruht auf den genannten Veröffentlichungen. Prüfen Sie bei Entscheidungen die Originalquelle.

Weiterlesen

• Rechte und Freigaben für KI-Agenten: Excessive Agency vermeiden
• MCP-Sicherheit: KI-Agenten und ihre Tool-Anbindungen absichern
• Cyber Security im Agentenzeitalter: Was sich ändert, wenn KI selbst handelt