Was tun, wenn Secrets in KI-Agenten gelangen: Zugriffswiderruf, Auditing und Wiederanlauf

Anweisungen abgeglichen mit der Dokumentation am 16. September 2026.

Wenn ein autonomer Agent Befehle wie git diff ausführt, lokale Konfigurationsdateien liest oder versehentlich Dumps von Umgebungsvariablen direkt im Prompt des Modells übergibt, verlassen Secrets den vertrauenswürdigen Bereich. In dieser Situation müssen Sie Hintergrundskripte stoppen, kompromittierte Zugangsdaten sperren, Systemprotokolle unter Berücksichtigung ihrer Grenzen auditieren und die Umgebung nach dem Prinzip der geringsten Berechtigungen (Least Privilege) neu starten.

Unterscheidung zwischen regulärer Konfiguration und Kontext-Leaks

Vor Beginn der Incident-Response ist es wichtig, zwischen regulärer API-Nutzung und einer tatsächlichen Kompromittierung zu unterscheiden.

Der reguläre Betrieb sieht vor, dass ein API-Schlüssel ausschließlich in den Autorisierungsfeldern des vorgesehenen Modellanbieters übergeben wird (beispielsweise über die Variablen OPENAI_API_KEY oder ANTHROPIC_API_KEY), um Anfragen des Werkzeugs an das Sprachmodell zu authentifizieren. Variablen wie ANTHROPIC_BASE_URL oder OPENAI_BASE_URL definieren die Netzwerkadresse des Endpunkts (Endpoint/Base URL) und stellen weder ein Secret noch ein Authentifizierungs-Token dar.

Ein Leak über das Modell liegt vor, wenn unbeteiligte Infrastruktur-Secrets – persönliche GitLab-Tokens, langlebige AWS-IAM-Schlüssel, private SSH-Schlüssel, Datenbank-Credentials oder Tokens für Unternehmensnetzwerke – in den Prompt des Nutzers, den Dialogkontext, angehängte Dateien oder den Ausgabestrom von Dienstprogrammen (stdout/stderr) gelangen und tatsächlich an einen externen Dienst übertragen werden. Man sollte zwar nicht a priori von einer Bösartigkeit aller zwischengeschalteten Proxys oder Gateways ausgehen, doch das Senden eines Secrets über die Grenzen der isolierten Umgebung hinaus erfordert eine unverzügliche Eindämmung.

Erste Schritte: Prozesse stoppen und den Vorfall dokumentieren

Oberste Priorität hat die Verhinderung einer weiteren Datenübertragung:

1. Beenden Sie den lokalen Prozess des Agenten und deaktivieren Sie zugehörige Hintergrundaufgaben (Cron-Jobs, CI/CD-Automatisierungsskripte).
2. Erfassen Sie die Metadaten des Vorfalls in einem lokalen Bericht, ohne das Secret selbst zu duplizieren: Art des kompromittierten Zugangs, ungefährer Zeitpunkt der ersten Anfrage, Aufgaben-/Sitzungs-ID und die Netzwerkadresse (Endpoint) des Empfängers.
3. Übermitteln Sie den Klartext-Schlüssel keinesfalls in Support-Chats oder in Folgeanfragen an neuronale Netze zur Überprüfung.

Alle Vorgänge zum Widerruf und Austausch von Schlüsseln müssen ausschließlich von einer vertrauenswürdigen Workstation über die offiziellen Management-Konsolen der Provider durchgeführt werden.

Zugriffswiderruf nach Diensttyp

Verschiedene Plattformen setzen Isolierung und den Entzug von Berechtigungen nach unterschiedlichen architektonischen Regeln um.

Modell-Zugriffsschlüssel (OpenAI API)

Gemäß den offiziellen OpenAI-Sicherheitsempfehlungen für API-Schlüssel erfordert der Verdacht auf eine Kompromittierung die Rotation des Schlüssels und eine Überprüfung des Ressourcenverbrauchs.

Besteht der Verdacht auf ein Leak, muss der kompromittierte Schlüssel an erster Stelle widerrufen werden:

1. Navigieren Sie unverzüglich zur Web-Oberfläche für die OpenAI-API-Schlüsselverwaltung und widerrufen (Revoke/Delete) Sie den kompromittierten Schlüssel. Dies blockiert weitere unbefugte Aufrufe um den Preis einer kontrollierten temporären Ausfallzeit abhängiger Dienste; der Widerruf sollte nicht bis zum Abschluss eines vollständigen Audits oder langwieriger Aktualisierungen bei allen Verbrauchern aufgeschoben werden.
2. Generieren Sie einen neuen Schlüssel und tragen Sie ihn in die Konfigurationen der Dienste ein.
3. Öffnen Sie das Dashboard Usage und analysieren Sie die Aktivität innerhalb des ermittelten Expositionsfensters, indem Sie sie mit den erwarteten Operationen abgleichen.

GitLab Personal Access Tokens

Gemäß der GitLab-Dokumentation zu Personal Access Tokens macht der Widerruf eines persönlichen Tokens diesen mit sofortiger Wirkung ungültig:

1. Klicken Sie in der GitLab-Benutzeroberfläche auf das Profilbild oben rechts > Edit profile > Access > Personal access tokens.
2. Suchen Sie in der Tabelle der aktiven Tokens die kompromittierte ID und klicken Sie auf Revoke.

Die Funktion Rotate in GitLab annulliert das alte Token, behält jedoch den bisherigen Berechtigungsumfang (Scopes) bei. Hatte das kompromittierte Token übermäßige Rechte, sollte es vollständig widerrufen und durch ein neues mit minimalem Scope ersetzt werden. Auf der Detailseite des Tokens werden das Datum der letzten Verwendung sowie die letzten fünf eindeutigen IP-Adressen angezeigt. Beachten Sie, dass diese Metriken mit einer systembedingten Verzögerung aktualisiert werden.

AWS-Zugriffsschlüssel (IAM Access Keys)

Das Verfahren zur Deaktivierung von IAM-Schlüsseln wird durch den AWS-Leitfaden zum Sichern von Zugriffsschlüsseln und die Dokumentation zur Verwaltung von IAM-Zugriffsschlüsseln geregelt:

1. Melden Sie sich in der AWS Management Console an, navigieren Sie zu IAM > Users und öffnen Sie den Reiter Security credentials.
2. Suchen Sie im Bereich Access keys die ID des kompromittierten Schlüssels und setzen Sie dessen Status auf Deactivate.
3. Sobald die Kontrolle wiederhergestellt ist, entfernen Sie den Schlüssel durch Klick auf Delete.

[!IMPORTANT] Das Setzen eines Schlüssels auf Deactivate stoppt die Annahme neuer Anfragen, die mit diesem langlebigen Schlüssel signiert sind, annulliert jedoch nicht zuvor ausgestellte temporäre Zugangsdaten (AWS STS tokens) und beendet aktive Sitzungen nicht automatisch. Die Aktion Revoke active sessions gilt nur für Sitzungen der entsprechenden IAM-Rolle; aktive Sitzungen des IAM Identity Center und andere STS-Token-Typen erfordern einen separaten Widerruf gemäß ihren jeweiligen Authentifizierungsmechanismen. Der Sicherheitsadministrator muss zudem Aufrufe über AWS CloudTrail und die Funktion get-access-key-last-used abgleichen. Führen Sie während eines laufenden Vorfalls keine ungetesteten, destruktiven Befehle zur Massenlöschung über das CLI aus.

OpenSSH-Schlüssel und Autorisierung

Das Autorisierungsverfahren von OpenSSH ist in den Handbüchern man sshd(8) und sshd_config(5) beschrieben:

1. Der Administrator muss den kompromittierten öffentlichen Schlüssel aus der Autorisierungsdatei auf allen Servern entfernen. Der Dateipfad wird über die Direktive AuthorizedKeysFile festgelegt (standardmäßig ~/.ssh/authorized_keys, in Infrastrukturen kann jedoch eine zentralisierte Datei oder eine Zertifikatsprüfung über eine SSH CA konfiguriert sein).
2. Stellen Sie vor Änderungen sicher, dass ein unabhängiger Backup-Zugangsweg vorhanden ist (z. B. Webkonsole des Providers oder Out-of-Band-Management), um ein Aussperren zu verhindern.
3. Das Entfernen des öffentlichen Schlüssels verhindert das Zustandekommen neuer Verbindungen, unterbricht jedoch keine bereits aktiven Sitzungen.

Der Befehl who zeigt nur Benutzer mit zugewiesenem Pseudoterminal (TTY) an und stellt kein vollständiges Sitzungsinventar dar: Tunnel, Portweiterleitungen oder nicht-interaktive Befehle werden nicht erfasst. Das blinde Beenden des Root-Prozesses von sshd ist unzulässig, da dies den Abbruch von Kindprozessen nicht garantiert und den Administrator vom Server trennen kann. Administratoren müssen den Prozessbaum, aktive Netzwerkverbindungen und Authentifizierungsprotokolle gezielt prüfen und verdächtige Sitzungen einzeln beenden. Das lokale Löschen des privaten Schlüssels oder das Ändern der Passphrase hat keinerlei Auswirkung auf einen Schlüssel, der bereits nach außen kopiert wurde.

Tailscale-Netzwerke und Unternehmens-VPNs

Laut Tailscale-Dokumentation zu Auth Keys dient ein Authentifizierungsschlüssel ausschließlich der Registrierung von Nodes:

1. Navigieren Sie in der Tailscale-Konsole zum Bereich Keys und widerrufen Sie den kompromittierten Auth-Key. Dies verhindert die Registrierung neuer Geräte.
2. Der Widerruf eines Auth-Keys trennt bereits registrierte Nodes nicht. Der Administrator muss den Reiter Machines aufrufen, das Geräteinventar prüfen und alle unautorisierten Systeme manuell entfernen (Remove/Delete).

Für klassische Unternehmens-VPNs (IPsec, OpenVPN, WireGuard und proprietäre Lösungen) gibt es kein einheitliches, universelles Widerrufsverfahren via CRL: Der konkrete Mechanismus hängt vom verwendeten Autorisierungsschema ab (x509-Zertifikate, statische Pre-Shared Keys, RADIUS/IdP-Tokens). Die Änderung des Kontopassworts führt bei vielen Gateways keineswegs zu einer sofortigen Trennung des Tunnels. Der Vorgang muss an einen Netzwerkadministrator übergeben werden, um das Zertifikat bzw. das Konto zu sperren und aktive Sitzungen über die Verwaltungsoberfläche des jeweiligen VPN-Gateways zwangsweise zu trennen.

Analyse der Folgen: Logs, Zeitfenster und irreversible Risiken

Berücksichtigen Sie beim Abgleich des Vorfalls mit Systemprotokollen die technischen Grenzen der Telemetrie:

• Expositionsfenster: Erfassen Sie das genaue Zeitintervall zwischen der ersten Übermittlung des Secrets an den Agenten und dem bestätigten Schlüsselwiderruf samt Beendigung aktiver Sitzungen.
• Grenzen von Logs: Beachten Sie Verzögerungen bei der Ereigniserfassung (Ingestion Delay), Aufbewahrungsfristen von Logs (Retention Period) und tote Winkel (fehlende detaillierte Parameterprotokollierung in bestimmten APIs, fehlendes Logging für Sitzungen ohne TTY).
• Grundsatz des fehlenden Gegenbeweises: Das Fehlen auffälliger Einträge oder ein Token-Verbrauch von null innerhalb des einsehbaren Protokollfensters beweist nicht, dass das Secret nicht abgefangen oder von Dritten für eine spätere Verwendung gespeichert wurde.

Der Widerruf von Schlüsseln blockiert künftige Anfragen, holt jedoch keine Daten, Quellcodes oder Umgebungsvariablen zurück, die bereits an einen externen Dienst übertragen wurden. Das Löschen einer Konversation in der Web-Oberfläche des Agenten oder der Plattform blendet den Verlauf zwar aus, stellt jedoch keinen technischen Nachweis dar, dass die Daten aus den Logs oder Caches des Downstream-Providers bereinigt wurden.

Sicherer Neustart: Risiken minimieren und Isolation überprüfen

Die Wiederaufnahme des Betriebs des Agenten muss das Risiko eines erneuten Vorfalls minimieren:

1. Kurzlebige Tokens: Nutzen Sie zeitlich begrenzte Sitzungsdaten (Session Credentials), wo immer Plattformen und Infrastruktur dies unterstützen.
2. Eingrenzung des Arbeitsbereichs: Schließen Sie .env-Dateien, private Schlüssel und Verzeichnisse mit Secrets aus dem Arbeitsbereich des Agenten aus; das Auslagern von Secrets nach außen garantiert keine vollständige Isolation und ersetzt keine Zugriffsbeschränkungen auf Betriebssystemebene.
3. Überprüfung von Grenzen ohne Netzwerk-Canaries: Erstellen Sie zum Testen von Berechtigungen ein temporäres, isoliertes Verzeichnis, das frei von echten Secrets ist. Platzieren Sie dort eine Dummy-Datei mit einem Platzhaltertext und prüfen Sie, ob der Agent den Zugriff auf die Datei, das Ausführen von Shell-Befehlen und das Auslesen von Variablen über env blockiert. Verwenden Sie keine externen Netzwerk-Dienste für Canary-Tokens zur grundlegenden Validierung von Berechtigungen.
4. Ganzheitlicher Schutz (Defense in Depth): Das erfolgreiche Abfangen von Lesezugriffen auf einen einzelnen Pfad beweist keine vollständige Prozessisolation, wenn der Agent weiterhin uneingeschränkten Zugriff auf das Terminal oder das Netzwerk hat.

Detaillierte architektonische Ansätze zur Einschränkung von Systemaufrufen und zur Rechte-Trennung werden im Leitfaden zur Verwaltung von Berechtigungen und Secrets in Claude Code behandelt. Die Minimierung von Kontoberechtigungen und der Verzicht auf statische Secrets senken das Risiko bei der Übertragung von Aufgaben an autonome KI-Werkzeuge.