KI-Agenten-Anmeldedaten: 7 Regeln für sichere Zugriffskontrolle

KI-Agenten besitzen heute API-Schlüssel und Datenbank-Anmeldedaten, die früher nur Personen oder Pipelines gehörten. Sie verfügen auch über Service-Tokens, oft mit weniger Einschränkungen als ein menschlicher Benutzer jemals erhalten würde. Eine Palo Alto Networks-Umfrage von 2026 unter 2.930 Cybersicherheitsentscheidern in 20 Ländern ergab durchschnittlich 109 Maschinenidentitäten pro menschlicher Identität in den befragten Organisationen, wobei 79 dieser 109 KI-Agenten waren. Die Umfrage zeigt, wie schnell sich nicht-menschliche Identität zu einem Zugangsverwaltungsproblem entwickelt hat.

Die meisten Organisationen vergeben Agenten-Anmeldedaten auf die gleiche Weise wie einen Laptop an einen neuen Mitarbeiter: Account erstellen, breiten Zugriff gewähren, damit nichts kaputtgeht, und weitermachen. Dieser Ansatz funktioniert bei Menschen, weil ein menschlicher Mitarbeiter typischerweise innehält und prüft, bevor er eine Aktion ausführt, die Schaden verursachen könnte. Er funktioniert weniger gut bei einem System, das auf jede Anweisung reagiert, die im gerade gelesenen Text am überzeugendsten erscheint.

Dieser Artikel behandelt die Anmeldedaten-Seite der Agentensicherheit: wie man die Secrets, die ein autonomer Agent oder ein LLM-basiertes Tool benötigt, ausstellt, beschränkt und prüft, ohne ihm einen dauerhaften Hauptschlüssel zu übergeben. Er stützt sich auf Passworks DevOps-Secrets-Modell, das diese Frage für CI/CD-Pipelines bereits größtenteils beantwortet. Der Anmeldedaten-Fußabdruck eines Agenten liegt viel näher an dem einer Pipeline als an dem einer Person.

Warum KI-Agenten-Anmeldedaten andere Kontrollen benötigen

Ein Skript folgt jedes Mal demselben Codepfad, sodass Sie seinen Zugriff beschränken können, bevor es jemals ausgeführt wird. Ein KI-Agent wählt, welches Tool er aufrufen soll, basierend auf Text, den er zur Laufzeit liest, und ein Teil dieses Textes kann von einem Angreifer stammen. OWASP (Open Worldwide Application Security Project) benennt diesen Fehlermodus LLM06:2025, Excessive Agency: unerwartete, mehrdeutige oder manipulierte Modellausgabe kann schädliche Aktionen auslösen, wenn ein Agent über übermäßige Funktionalität, Berechtigungen oder Autonomie verfügt.

Prompt Injection ist Text, der darauf ausgelegt ist, die Anweisungen eines Agenten zu überschreiben. Es ist eine Möglichkeit, wie diese Manipulation geschieht, nicht die einzige. Zwei Enthüllungen aus dem vergangenen Jahr zeigen, wie das in der Praxis aussieht: Comment and Control (April 2026) exfiltrierte Live-Tokens von drei Coding-Agenten durch einen versteckten GitHub-Kommentar, und CamoLeak (Oktober 2025) nutzte einen versteckten Pull Request, um GitHub Copilot Chat dazu zu bringen, private Repository-Daten über einen Image-Proxy-Kanal zu leaken. In beiden Fällen hatte ein Agent Tool-Zugriff, ein Live-Anmeldedatensatz war in Reichweite, und nicht vertrauenswürdiger Text brachte den Agenten dazu, ihn als Anweisung zu behandeln. Regel 6 behandelt die Mechanik beider Fälle.

Die 7 Regeln zur Absicherung von KI-Agenten-Anmeldedaten

Diese Regeln wenden die Zugangsdisziplin, die DevOps-Teams bereits für Pipeline-Secrets verwenden, auf einen Akteur an, der seinen nächsten Schritt selbst entscheidet. Die meisten basieren auf Kontrollen, die ausgereifte Secrets- und Identitätsplattformen bereits bieten. Was sich ändert, ist, wo die Grenze zwischen dem gezogen wird, was der Agent anfordern kann und was er halten darf.

Regel 1: Jedem Agenten ein eigenes Service-Konto geben

Ein Service-Konto ist ein Login, das für ein automatisiertes System statt für eine Person erstellt wurde, mit eigener Rolle und eigenem Token-Paar, unabhängig von jedem Mitarbeiter. Jeder Produktions-Agent benötigt eines. Die gemeinsame Nutzung eines einzelnen Kontos über mehrere Agenten hinweg löscht die Zuordnung. Wenn etwas schiefgeht, sagt das Log „der Agent", anstatt Ihnen mitzuteilen, welcher Lauf, welche Aufgabe oder welches Deployment es verursacht hat.

Passworks Leitfaden zu Service-Konten und API-Tokens macht dies zur ersten Regel für jede Automatisierung, einschließlich Agenten: Authentifizieren Sie niemals ein Skript oder einen Agenten mit einem persönlichen Konto. Die Berechtigungen eines persönlichen Kontos sind in der Regel breiter als für die Aufgabe erforderlich. Seine Aktionen werden unter dem Namen eines Mitarbeiters statt dem der Automatisierung protokolliert, und das Widerrufen des Zugriffs bedeutet, das persönliche Profil einer Person zu bearbeiten, anstatt ein dediziertes Konto zu löschen.

Benennen Sie Konten nach Funktion, nicht nach Nummer. agent-support-triage-ro sagt einem Bereitschaftstechniker auch in sechs Monaten noch, was das Konto tut. agent-3 sagt ihm nichts.

Regel 2: Berechtigungen auf die Aufgabe beschränken

OWASPs Leitfaden zu Excessive Agency reduziert sich auf zwei Maßnahmen:

• Durchsetzung des Least-Privilege-Prinzips, indem der Agent auf die minimal erforderlichen Tools und Berechtigungen beschränkt und die Autorisierung unabhängig in nachgelagerten Systemen durchgesetzt wird;
• menschliche Genehmigung vor Aktionen mit hoher Auswirkung erfordern.

Bauen Sie in Passwork die Rolle des Agenten um eine einzige Berechtigung namens Use API auf, mit deaktivierter Benutzerverwaltung, LDAP-Integration und SSO-Administration — dasselbe API-gesteuerte Zugriffsmodell, das DevOps-Teams bereits für Secrets verwenden. Gewähren Sie Tresor- und Ordnerzugriff separat, auf der engsten Ebene, die die Aufgabe erfordert: Nur Lesen, es sei denn, die Aufgabe des Agenten ist das Schreiben, Ordnerebene statt Tresorebene, wenn er nur eine Teilmenge benötigt.

Ein Support-Bot, der einen Helpdesk-Anmeldedatensatz liest, hat keinen Grund, eine Rolle mit einem Deploy-Agenten zu teilen, der Produktionsdatenbank-Anmeldedaten berührt, selbst wenn eine gemeinsame Rolle einfacher einzurichten ist. Wenn ein Agent kompromittiert wird, trennt diese Beschränkungsentscheidung einen Ein-Anmeldedaten-Vorfall von einem flottenweiten.

Regel 3: Token-Lebensdauer an die Laufzeit des Agenten anpassen

Ein Agent, der einmal pro Aufgabe ausgelöst wird, um ein Ticket zu beantworten oder einen Pull Request zu prüfen, verhält sich wie ein kurzer CI-Job (Continuous Integration). Er verhält sich nicht wie eine Person, die sich für den Tag anmeldet, daher sollten seine Anmeldedaten nicht so lange halten wie die Sitzung einer Person.

Passwork stellt ein Token-Paar aus: ein accessToken, das bei jeder API-Anfrage verwendet wird, und ein refreshToken, das ein neues Paar anfordert, sobald das Access-Token abläuft. Empfohlene Lebensdauern skalieren mit der Aufgabe:

Dies sind Passworks eigene empfohlene Bereiche, kein universeller Standard. Prüfen Sie die Standard-Token-Lebensdauer Ihrer Plattform, bevor Sie davon ausgehen, dass sie diesen Zahlen entspricht. Standardeinstellungen sind in der Regel auf Komfort ausgelegt, nicht auf eine kurzlebige Agentenaufgabe, daher ist ihre Verkürzung ein bewusster Schritt, den Sie unternehmen, nicht einer, den Sie erben.

In Passwork 7.6.0 und später können Sie das vollständige Token-Paar, das Access-Token allein oder das Refresh-Token allein rotieren. Die Rotation des vollständigen Paares invalidiert beide vorherigen Tokens. Die Rotation nur des Refresh-Tokens invalidiert das vorherige Refresh-Token, lässt aber das aktuelle Access-Token gültig, bis es von selbst abläuft. Bauen Sie Ihre Widerrufstests um den Modus auf, den Sie verwenden. Speichern Sie Refresh-Tokens als hochwertige, langlebige Secrets in einem sicheren Secret Store oder einer plattformbereitgestellten sicheren Speicherung; RFC 9700 bietet nützliche Schutzprinzipien, obwohl Passwork diese als API-Sitzungstokens und nicht als OAuth-Tokens dokumentiert.

Regel 4: Anmeldedaten aus Repositories und MCP-Konfigurationsdateien fernhalten

Agenten-Anmeldedaten werden oft aus Klartextdateien geleakt, die im Arbeitsverzeichnis des Agenten liegen. GitGuardians Bericht State of Secrets Sprawl 2026 fand 24.008 einzigartige Secrets, die 2025 in MCP-Konfigurationsdateien (Model Context Protocol) auf öffentlichem GitHub exponiert waren. GitGuardians Scanner bestätigten, dass 2.117 davon zum Zeitpunkt der Erkennung noch funktionierten. Auf dem öffentlichen GitHub insgesamt erschienen 2025 28,6 Millionen hartcodierte Secrets in Commits, ein Anstieg von 34% gegenüber 2024. Secrets im Zusammenhang mit KI-Diensten wuchsen um 81% auf über 1,27 Millionen, darunter mehr als 113.000 geleakte DeepSeek-API-Schlüssel.

MCP ist ein Open-Source-Standard, der es KI-Anwendungen ermöglicht, sich mit externen Tools und Datenquellen zu verbinden. Trend Micros Forschung zu MCP-Serverkonfigurationen ergab, dass etwa 48% der überprüften Server empfehlen, Anmeldedaten über eine .env-Datei zu übergeben. Hartcodierung in eine Klartext-JSON-Konfiguration ist die gängige Alternative. Beide Ansätze legen mehrere Secrets in eine Datei, die der eigene Prozess des Agenten öffnen kann.

Referenzieren Sie den Variablennamen in der Konfiguration und holen Sie den tatsächlichen Wert beim Prozessstart von einer Secrets-Plattform ab, anstatt aus einer Datei, die der Agent direkt lesen kann:

{
  "mcpServers": {
    "internal-api": {
      "command": "node",
      "args": ["./server.js"],
      "env": { "API_TOKEN": "${API_TOKEN}" }
    }
  }
}

Dies behebt das Problem mit statischen Dateien, entscheidet aber nicht, wer den tatsächlichen Wert abruft oder wohin dieser Wert nach dem Abruf geht. Regel 5 behandelt diesen Teil.

Regel 5: Jeden Anmeldedatensatz durch eine isolierte Tool-Ausführungsschicht leiten

Das Entfernen eines Secrets aus einem Repository oder einer MCP-Konfigurationsdatei ist wichtig, aber es ist nicht die vollständige Lösung, wenn dieser Wert dann direkt in die eigene Laufzeit des Agenten gelangt. Ein Entwickler weiß, dass er einen API-Schlüssel nicht in ein Chat-Fenster einfügen sollte. Ein Agent hat keinen vergleichbaren Instinkt. Sobald ein Secret in eine Tool-Antwort, eine Debug-Zeile oder eine vom Modell produzierte Reasoning-Trace gelangt, kann es überall wieder auftauchen, wo dieser Text protokolliert, gecacht oder wiedergegeben wird.

Der sicherste Ansatz ist es, Secrets in der Tool-Ausführungsschicht zu halten, hier als Credential Broker oder Tool-Ausführungsdienst implementiert, wo das Modell sie nicht sehen kann. Der Agent bittet ein dediziertes Tool, eine bestimmte Aufgabe auszuführen, wie etwa den Deployment-Status zu prüfen oder einen Datensatz abzurufen. Das Tool verwendet das Secret, um die Aufgabe abzuschließen, und gibt nur das Ergebnis an den Agenten zurück.

Um Secrets bereitzustellen, wenn ein Prozess startet, ohne sie in Klartextdateien wie mcp.json oder .env zu speichern, verwenden Sie passwork-cli exec.

passwork-cli exec --folder-id "$PROD_SECRETS_FOLDER_ID" – ./start-agent.sh 

Das Dienstprogramm passwork-cli exec lädt Secrets nur während der Ausführung in einen Kindprozess. Es schreibt sie nicht auf die Festplatte und fügt sie nicht in die Befehlsausgabe ein. Das Schlüsselprinzip ist, Anmeldedaten auf der Tool-Ebene zu halten, wo sie außerhalb des Modellkontexts und jedes Textes bleiben, den das LLM lesen kann.

Das Secret aus dem Modellkontext fernzuhalten, schließt einen Offenlegungspfad. Ein prompt-injizierter Agent kann den Broker immer noch bitten, eine Operation auszuführen, zu der er technisch berechtigt ist, nur zum falschen Zeitpunkt oder am falschen Datensatz. Der Broker benötigt seine eigenen Richtlinienprüfungen vor dem Secret Store, und Regel 6 behandelt, was passiert, wenn eine Injection trotzdem so weit kommt.

Dies begrenzt auch den Schaden durch Dateisystemzugriff an sich. Ein Agentenprozess, der eine .env-Datei lesen kann, zieht den Anmeldedatensatz direkt in seinen Arbeitsspeicher, und keine Dateiberechtigung stoppt das, sobald der Agent selbst das Lesen durchführt. Die Weiterleitung durch einen Broker, den der Agent aufrufen, aber nicht inspizieren kann, erzwingt die Grenze, die Regel 4 beginnt.

Regel 6: Ausgabefilterung als Backstop behandeln, nicht als Hauptverteidigung

Am 15. April 2026 veröffentlichten der Forscher Aonan Guan und die Johns-Hopkins-Forscher Zhengyu Liu und Gavin Zhong Comment and Control: drei Proof-of-Concept-Demonstrationen gegen Claude Code Security Review, Gemini CLI Action und GitHub Copilot Agent. Jede nutzte eine andere Injection-Oberfläche — einen Pull-Request-Titel, einen Issue-Kommentar, einen versteckten HTML-Kommentar — um Runner-Secrets wie ANTHROPIC_API_KEY und GITHUB_TOKEN zu exponieren.

Anthropic bewertete seinen eigenen Fund mit 9.4 CVSS, über der kritischen Schwelle. Keiner der drei Anbieter vergab eine CVE oder veröffentlichte einen Sicherheitshinweis. Verlassen Sie sich nicht auf einen CVE-Feed, um den nächsten zu finden: Er lieferte nichts für ein bestätigtes, kritisches, aus der Ferne auslösbares Credential-Leak in drei weit verbreiteten Agenten.

Der Fall Copilot Agent zeigt, warum Filterung allein nicht standhält. Guans Bericht beschreibt drei Verteidigungslinien vor Copilot Agent: Variablenfilterung, diff-basiertes Secret-Scanning und eine Netzwerk-Allowlist. Die demonstrierte Kette umging alle drei, las Secrets über einen Weg, den der Filter übersah, kodierte Werte am Scanner vorbei und exfiltrierte über einen GitHub-Endpunkt, den die Allowlist bereits erlaubte.

CamoLeak, eine frühere Copilot-Chat-Schwachstelle, zeigt, dass dieses Risiko nicht auf Agenten-Runner oder CI-Secrets beschränkt ist. Der Forscher Omer Mayraz fand sie im Juni 2025 in Copilot Chat und veröffentlichte Details am 8. Oktober 2025: versteckte Pull-Request-Inhalte veranlassten Chat, private Repository-Daten in Bildanfragen zu kodieren, die über GitHubs Camo-Proxy geleitet wurden. Mayraz bewertete es mit CVSS 9.6. GitHub entschärfte das Problem, erfasst als CVE-2025-59145, bis zum 14. August 2025.

Ausgabefilter, Scanning und Egress-Allowlists reduzieren die Chance, dass ein Leak erfolgreich ist, aber keines von ihnen kann eine Tool-Anfrage allein autorisieren oder blockieren. Behandeln Sie sie als Backstops. Kombinieren Sie sie mit unabhängiger nachgelagerter Autorisierung, Argumentvalidierung, engen Einzweck-Tools und menschlicher Genehmigung für Aktionen mit hoher Auswirkung.

Regel 7: Jede Aktion protokollieren und Widerruf auf eine Identität isoliert halten

Passworks Aktivitätsprotokoll zeichnet Ereignisse im CEF-Format (Common Event Format) auf, geeignet für die Weiterleitung an ein SIEM (Security Information and Event Management Platform) über syslog. Dokumentierte Felder umfassen den Ereigniscode (zum Beispiel item_created), eine Schweregradbewertung, eine Beschreibung, die Benutzer-ID und das Login des handelnden Benutzers sowie die Client-IP. Passworks Ereignisweiterleitungsdokumentation behandelt die vollständige Feldliste sowohl für Linux-syslog als auch für Windows Event Viewer.

Ein dediziertes Service-Konto ordnet jede protokollierte Operation einer einzelnen Automatisierungsidentität zu. Das ist ein zuverlässiges Puzzleteil an einem schlechten Tag. Zu rekonstruieren, was ein bestimmter Agentenlauf tatsächlich getan hat, bedeutet immer noch, Ihre Broker-Logs, nachgelagerten Service-Logs und Egress-Logs im selben Zeitfenster zu korrelieren.

Der Wert zeigt sich unabhängig davon. Wenn ein Agent etwas tut, das niemand geplant hat, sei es, weil er einer injizierten Anweisung folgte oder eine Aufgabe falsch verstand, sagt Ihnen ein agentenspezifisches Service-Konto, welche Identität, welche Sitzung und welche Secrets berührt wurden, ohne ein gemeinsames Token mit Zeitstempeln abzugleichen. Auch der Widerruf bleibt isoliert: Deaktivieren Sie die Tokens dieses einen Kontos, und jeder andere Agent läuft weiter. Das ist ein stärkeres Argument für separate Konten als jedes Dashboard.

Aufbau von Agenten-Anmeldedaten-Kontrollen mit Passwork

Passwork bietet die Kernkontrollen für die Verwaltung des Agentenzugriffs. Für KI-Agenten können diese Kontrollen in fünf Bereichen organisiert werden:

1. Jeder Agentenfunktion ein dediziertes Service-Konto geben. Separate Konten halten den Agentenzugriff isoliert und die Aktivität zuordenbar.
2. Least Privilege durch Rollen und granulare ACLs anwenden. Beschränken Sie jedes Konto auf die Tresore, Ordner und Operationen, die für seine Aufgabe erforderlich sind. Standardisierte Rollen- und ACL-Vorlagen können die Bereitstellung im großen Maßstab vereinfachen.
3. Anmeldedaten-Rotation als End-to-End-Workflow behandeln. Ersetzen Sie den Anmeldedatensatz im Zielsystem, aktualisieren Sie ihn in Passwork, widerrufen Sie den alten Anmeldedatensatz und überprüfen Sie, dass der alte Zugriff beendet ist. GitGuardian fand, dass mehr als 64% der 2022 als gültig bestätigten Anmeldedaten im Januar 2026 noch gültig waren.
4. Dynamische Anmeldedaten verwenden, wo erforderlich. Workloads, die kurzlebige, auf Anfrage generierte Anmeldedaten benötigen, erfordern möglicherweise einen Dynamic-Secret- oder Credential-Leasing-Dienst neben dem Tresor.
5. Agentenaktivität mit dem breiteren Monitoring-Stack verbinden. Überprüfen Sie die Monitoring-Fähigkeiten der verwendeten Passwork-Edition und -Version und leiten Sie Aktivitätsdatensätze an ein SIEM weiter, wenn Ereigniskorrelation oder Near-Real-Time-Alerting erforderlich ist.

KI-Agenten-Anmeldedaten-Checkliste

Gehen Sie diese Acht-Punkte-Prüfung durch, bevor ein Agent in der Produktion einen echten Anmeldedatensatz berührt.

• Dedizierte Identität. Hat dieser Agent sein eigenes Service-Konto oder seine eigene Workload-Identität, getrennt von jedem anderen Agenten und jedem Menschen?
• Least Privilege. Haben Sie seine Rolle, seinen Tresor- oder Ordnerzugriff und seinen Ressourcenumfang auf das beschränkt, was die Aufgabe tatsächlich benötigt?
• Nur-Lesen-Standard. Haben Sie Schreiben, Löschen und externe Kommunikation deaktiviert, es sei denn, die Aufgabe erfordert sie ausdrücklich?
• Token-Lebenszyklus. Haben Sie die Access-Token-Lebensdauer an die Länge eines Laufs angepasst, mit geschützten und widerrufbaren Refresh-Tokens?
• Keine statische Exponierung. Haben Sie bestätigt, dass der Anmeldedatensatz in Repositories, .env-Dateien, MCP-Konfiguration und jeder anderen Datei im Arbeitsbaum des Agenten fehlt?
• Broker-Grenze. Hält ein separater, isolierter Broker das Secret, während der modellseitige Agent nur ein minimiertes Ergebnis erhält?
• Getestete Sicherheitskontrollen. Haben Sie die Ausgabebehandlung, Argumentvalidierung und Egress-Beschränkungen gegen adversarial Input getestet, anstatt anzunehmen, dass sie funktionieren?
• Überprüfbare Eindämmung. Können Sie Agenten-, Broker- und nachgelagerte Logs korrelieren und die betroffene Identität widerrufen, ohne einen anderen Agenten zu stören?

Was das für Ihr Team bedeutet

Die Rolle eines Agenten auf Use API und minimalen Tresorzugriff zu beschränken, ist eine Konfigurationsänderung. Die meisten Secrets-Plattformen unterstützen dies bereits. Die Engineering-Arbeit liegt in der Schicht darum herum: ein Broker zwischen dem Agenten und dem Secret Store, Ausgabefilterung als Backstop gegen Leaks und Audit-Logs, die es Ihnen ermöglichen, eine Identität zu widerrufen, ohne den Rest zu berühren.

Beginnen Sie mit dem Agenten, der heute den breitesten Zugriff in Ihrer Umgebung hat, und reduzieren Sie seine Rolle auf das, was die Aufgabe erfordert.

Häufig gestellte Fragen

Cybersicherheits-Nachrichtenrückblick: Der Monat, in dem KI-Agenten begannen, selbstständig anzugreifen

Ein GPT-5.6-Agent entkam seiner Sandbox und durchbrach die Hugging-Face-Infrastruktur. SonicWall lieferte zwei 0-Days aus, die ein vollständiges Passwort- und TOTP-Reset erzwangen. IBMs Breach-Cost-Report 2026 erreichte einen Rekord von 4,99 Millionen Dollar. Hier erfahren Sie, was diesen Juli in der Cybersicherheit passiert ist und was Ihr Team zuerst patchen muss.

PassworkPasswork Team

Passwork als „Best for User Interface" ausgezeichnet und als FrontRunner 2026 anerkannt

Passwork wurde in der Software-Advice-Auswahl 2026 für Passwort-Management-Software als „Best for User Interface" ausgezeichnet und erhielt das FrontRunners-2026-Badge.

PassworkPasswork Team

Cybersicherheits-Checkliste für kleine Unternehmen 2026

Eine praktische, NIST-konforme Sicherheits-Checkliste für kleine Unternehmen: 18 Schritte zu Richtlinien, MFA, Passwort-Management, Netzwerksicherheit, Backups und Incident Response, sortiert nach Kosten und Auswirkung.

PassworkPasswork Team