Checkliste für das Offboarding von KI-Agenten bei kontrollierten Austritten

Ein Mitarbeiteraustritt gehört zu den wenigen Situationen, in denen sich die Zugriffskontrolle unter Zeitdruck bewähren muss. Das übliche Runbook zum Deaktivieren eines Kontos reicht bei KI-Agenten nicht aus. Die nützliche Arbeit läuft häufig über lokale Prozesse, unbeaufsichtigte Jobs, gemeinsam genutzte API-Anmeldedaten, SSH-Material und kopierte Konfigurationen außerhalb der Identität des ausscheidenden Mitarbeiters.

Betrachten Sie das Offboarding als kontrollierte Übertragung von Befugnissen und nicht als IT-Aufräumarbeit. Sie müssen neue Aktionen stoppen, laufende Arbeiten ermitteln, gemeinsam genutzte Berechtigungen ersetzen und Aufzeichnungen bewahren, bevor jemand die Belege löscht, die erklären, was geschehen ist.

Eine deaktivierte Identität widerruft nicht jeden Weg zur Produktion

Die Deaktivierung eines Verzeichnis-Kontos stoppt nur Zugriffswege, die dieses Verzeichnis zum Zeitpunkt der Nutzung tatsächlich abfragen. Sie widerruft kein API-Token in einer lokalen Konfigurationsdatei, keinen privaten SSH-Schlüssel in einem Agent-Arbeitsbereich, kein zuvor ausgestelltes Cloud-Zugriffstoken und keine gemeinsam genutzte Dienstberechtigung, die ein CI-Job einfügt.

Diese Unterscheidung wird oft verwischt, weil eine Person, ein Agent-Prozess und eine Berechtigung in einem Dashboard unter demselben Mitarbeiternamen erscheinen können. Es handelt sich um verschiedene Dinge, für die unterschiedliche Maßnahmen nötig sind:

• Eine menschliche Identität beantwortet die Frage, wer sich authentifiziert hat.
• Ein lokaler Agent-Prozess zeigt, was auf dem Rechner des Mitarbeiters gerade handeln kann.
• Eine Berechtigung bestimmt, was ein Remotedienst akzeptiert.
• Eine Sitzung oder ein Job zeigt, was möglicherweise bereits arbeitet.
• Ein Audit-Datensatz beantwortet die Frage, was Sie später belegen können.

Wer diese Unterscheidung falsch trifft, erlebt einen typischen Fehler. HR markiert den Mitarbeiter um 09:00 Uhr als ausgeschieden. Die IT deaktiviert um 09:05 Uhr Single Sign-on. Um 09:20 Uhr läuft auf einem noch nicht abgeholten Laptop ein geplanter Agent-Job. Er verwendet ein gemeinsam genutztes Deployment-Token aus seiner Umgebung und ändert eine Produktionseinstellung. Jedes beteiligte Team kann wahrheitsgemäß sagen, dass es das Mitarbeiterkonto entfernt hat. Keines hat die Berechtigung entfernt, die der Agent verwendet hat.

Beginnen Sie das Austrittsticket mit einer festen Frage: «Welche Aktionen könnten weiterhin erfolgreich sein, wenn die normale Anmeldung des Mitarbeiters nicht mehr funktioniert?» Akzeptieren Sie «Das Konto ist deaktiviert» nicht als Antwort.

NIST SP 800-53 ordnet verwandte Kontrollen aus gutem Grund getrennten Familien zu. AC-2 behandelt die Kontoverwaltung, IA-5 die Verwaltung von Authentifikatoren und AU-9 den Schutz von Audit-Informationen. Teams, die alle drei Punkte zu einer einzigen Checkbox zusammenfassen, entdecken die fehlende Arbeit meist erst nach einem Vorfall.

Aktionswege vor der Abholung des Laptops einfrieren

Stoppen Sie zuerst die entfernten Berechtigungen, denn die physische Abholung kann Stunden dauern und ein eingeschalteter Laptop weiterlaufen. Die für den Austritt zuständige Person sollte den Sicherheitsverantwortlichen und die Dienstverantwortlichen informieren und dann automatisierte Aktionen, die dem ausscheidenden Mitarbeiter oder seinem Arbeitsplatz zugeordnet werden können, kurzzeitig anhalten.

Der erste Durchgang sollte diese Wege abdecken:

1. Widerrufen Sie aktive Remote-Sitzungen, sofern der Identitätsanbieter, die Cloud, der Quellcode-Host oder das System für privilegierten Zugriff dies unterstützt.
2. Deaktivieren oder isolieren Sie registrierte Build-Runner, geplante Agent-Jobs und Remote-Entwicklungssitzungen, die dem Mitarbeiter gehören.
3. Entfernen Sie das Gerät aus dem Zugriff über vertrauenswürdige Geräte, VPN und Verwaltung, soweit es Ihr Betriebsprozess zulässt.
4. Pausieren Sie unbeaufsichtigte Aufgaben, die Deployments ausführen, Infrastruktur ändern, Nachrichten senden oder in Kundensysteme schreiben können.
5. Holen Sie den Rechner ab oder stellen Sie ihn unter verwaltete Netzwerkbeschränkungen, bevor der Mitarbeiter die Kontrolle darüber verliert.

Beginnen Sie nicht damit, lokale Dateien zu löschen. Wenn der Austritt umstritten, ungewöhnlich oder mit einem Sicherheitsproblem verbunden ist, bewahren Sie den Gerätezustand nach Ihrem Vorfallprozess auf. Ein vorschnelles Löschen zerstört Shell-Verlauf, Agent-Transkripte, lokale Konfiguration, Job-Warteschlangen und Zeitstempel, die zeigen könnten, ob eine Aktion autorisiert war.

Bei einem regulär geplanten Austritt kann der Sicherheitsverantwortliche entscheiden, dass die normalen Regeln für Rückgabe und Neuinstallation des Geräts gelten. Diese Entscheidung sollte im Ticket stehen. Sie darf nicht nur im Gedächtnis einer Person existieren.

Ein nützlicher Kontrollpunkt ist die Prozessgrenze des Agenten. Erfassen Sie vor der Beendigung eines lokal laufenden Agenten den Pfad zur ausführbaren Datei, den Elternprozess, die Prozess-ID, die Startzeit, das Arbeitsverzeichnis und die Codesignatur. Unter macOS kann ein Bediener eine grundlegende Prozessaufnahme wie folgt erstellen:

ps -axo pid,ppid,user,lstart,command | grep -i '[a]gent'

# Output shape:
# 8421   611 alice  Tue Mar 12 09:14:22 2025 /usr/local/bin/agent-run --task release

Der Befehl ist allein kein Beweis. Er liefert einem Ermittler einen zeitlich eingegrenzten Hinweis und verhindert, dass die vage Aussage «Ein Agent lief» zum gesamten Datensatz wird.

Ein Verzeichnis der Berechtigungen statt ein Softwareverzeichnis erstellen

Eine Liste installierter KI-Tools zeigt nicht, wer einen Dienst ändern kann. Erfassen Sie jeden Berechtigungsweg, auch Tools, die Sie möglicherweise nicht als KI bezeichnen. Der Mitarbeiter kann einen Agenten über ein Terminal, eine Editor-Erweiterung, einen CI-Runner, ein lokales Skript oder eine Remote-Umgebung verwendet haben. Der Weg ist wichtiger als die Bezeichnung.

Verwenden Sie eine Zeile pro Berechtigung oder Identitätsbeziehung. Wenn ein Token auf drei Dienste zugreifen kann, führen Sie die drei Folgen im Feld «Umfang» auf, statt sie in Notizen zu verstecken.

Der schwierige Teil ist das Auffinden gemeinsam genutzter Berechtigungen. Stellen Sie Dienstverantwortlichen direkte Fragen: Kennt dieser Mitarbeiter ein Token, das sein Konto überdauert? Hat er ein Bot-Konto verwaltet? Kann sich sein Gerät mit einem SSH-Schlüssel verbinden? Lief ein Job unter einer generischen Identität? Wer erhält ab heute die Warnungen dieses Jobs?

Machen Sie den ausscheidenden Mitarbeiter nicht zur alleinigen Quelle für dieses Verzeichnis. Er kann helfen, aber Repositories, Geheimnisspeicher, Dateien mit autorisierten Schlüsseln, CI-Konfiguration, Aufzeichnungen zur Dienstverantwortung und Audit-Logs müssen die Antwort bestätigen. Menschen vergessen ein Token, das während eines Ausfalls erstellt wurde. Sie vergessen auch einen Test-Runner, der zwei Jahre später zur Produktionsinfrastruktur wurde.

Gemeinsam genutzte Anmeldedaten in Abhängigkeitsreihenfolge rotieren

Rotieren Sie alle gemeinsam genutzten Anmeldedaten, die die ausscheidende Person gelesen, kopiert, exportiert oder außerhalb eines zuverlässigen, an die Identität gebundenen Widerrufswegs verwendet haben könnte. Dazu gehören API-Schlüssel, Passwörter für Basic Auth, Webhook-Geheimnisse, Deployment-Tokens, Datenbankpasswörter, SSH-Schlüssel, Cloud-Zugriffsschlüssel und Wiederherstellungscodes.

Die verbreitete, aber falsche Empfehlung lautet, alles gleichzeitig zu rotieren. Das wirkt entschlossen und erzeugt eine beeindruckende Liste geänderter Geheimnisse. Gleichzeitig werden unbekannte Abhängigkeiten unterbrochen, die Fehlersuche wird chaotisch und Teams geraten unter Druck, das alte Geheimnis wiederherzustellen. Rotieren Sie in einer Reihenfolge, die einen verantworteten Ersatzweg offenlässt.

Gehen Sie für jede Berechtigung so vor:

1. Benennen Sie den Dienstverantwortlichen und die genauen Aufrufer, die diese Berechtigung verwenden.
2. Erstellen Sie eine Ersatzberechtigung mit dem kleinstmöglichen Umfang, den der Dienst unterstützt.
3. Aktualisieren Sie bekannte Aufrufer und weisen Sie nach, dass sie mit dem Ersatz funktionieren.
4. Widerrufen Sie die alte Berechtigung und testen Sie anschließend, dass sie fehlschlägt.
5. Halten Sie den Verwahrer des Ersatzes, seine Erstellungszeit, seinen Umfang und das Ergebnis des Widerrufs fest.

Ein Fehlschlagtest ist wichtig. «Rotation abgeschlossen» bedeutet oft nur, dass jemand ein neues Token erstellt und eine Anwendung aktualisiert hat. Es bedeutet nicht, dass das alte Token nicht mehr funktioniert. Führen Sie eine harmlose authentifizierte Anfrage aus, die die alte Berechtigung früher erlaubt hat. Erfassen Sie die erwartete Ablehnungsantwort des Dienstes, etwa HTTP 401 oder 403, statt Geheimnisse in das Ticket zu kopieren.

Entfernen Sie bei SSH-Zugriffen den öffentlichen Schlüssel der ausscheidenden Person aus jeder Quelle autorisierter Schlüssel auf jedem Ziel und aus jedem zentralen Zugriffssystem. Suchen Sie anschließend nach Automatisierungen, die denselben privaten Schlüssel verwenden. Wenn ein Agent eine gemeinsam genutzte SSH-Identität verwendet hat, erstellen Sie ein neues Schlüsselpaar, ersetzen Sie den öffentlichen Teil auf den Zielen, aktualisieren Sie den zugelassenen Aufrufer und ziehen Sie den alten öffentlichen Schlüssel zurück. Das Entfernen eines Schlüssels vom Arbeitsplatz bewirkt nichts gegen eine kopierte Version.

Senden Sie den Ersatz niemals im Rahmen der Übergabe per Chat oder E-Mail. Geben Sie dem neuen Verantwortlichen über den zugelassenen Geheimnis-Mechanismus die Berechtigung, ihn abzurufen oder zu verwenden. Der Zweck der Rotation ist, die Zahl der nicht nachvollziehbaren Kopien zu verringern.

Gemeinsam genutzte Konten brauchen einen namentlich benannten Verantwortlichen

Ein Dienstkonto kann legitim sein. Ein gemeinsam genutztes Konto ohne benannten Bediener verbirgt jedoch ein Verantwortungsproblem. Die Übergabe muss eine Person benennen, die Verantwortung für Zweck, Umfang, Abrechnung, Wiederherstellungsweg und künftige Rotation der Anmeldedaten übernimmt.

Trennen Sie die operative Verantwortung von den Anmeldedaten selbst. Ein Release-Bot muss möglicherweise weiter deployen, nachdem ein Mitarbeiter gegangen ist. Das bedeutet nicht, dass der Nachfolger das persönliche Token oder die lokale Konfiguration des ehemaligen Mitarbeiters übernehmen sollte. Geben Sie dem Bot, sofern der Dienst dies erlaubt, eine eigene Identität, statten Sie ihn nur mit den nötigen Berechtigungen aus und machen Sie den neuen Verantwortlichen dafür zuständig.

Erstellen Sie eine kurze Übergabeaufzeichnung mit Antworten auf fünf Punkte:

• Welchen Dienst oder Workflow unterstützt das Konto?
• Welche Umgebungen und Aktionen kann es erreichen?
• Welche Systeme rufen es heute auf?
• Wer kann seine Anmeldedaten ändern oder es wiederherstellen?
• Wann prüft jemand, ob dieser Zugriff noch nötig ist?

Hier finden Teams auch Annahmen eines Agenten, die sich als Bequemlichkeit tarnen. Eine lokale Konfiguration kann einen Agenten anweisen, eine generische Deployment-Identität zu verwenden, weil der ursprüngliche Entwickler keine Zeit hatte, eine eigene einzurichten. Bewahren Sie diese Abkürzung nicht im Namen der Kontinuität auf. Ersetzen Sie sie durch einen verantworteten Zugriffsweg, bevor Sie die Arbeit wieder aufnehmen.

Aufzeichnungen bewahren, bevor Aufbewahrungsjobs sie löschen

Bewahren Sie Aufzeichnungen auf, mit denen sich Berechtigungen und Aktionen rekonstruieren lassen, ohne auf die Erklärung des ausscheidenden Mitarbeiters angewiesen zu sein. Erfassen Sie das Austrittsticket, das Berechtigungsverzeichnis, das Ereignis der Identitätsdeaktivierung, Sitzungswiderrufe, Rotationsereignisse, die CI-Job-Historie, Agent-Läufe, die Entscheidung zur Gerätesammlung und Audit-Exporte der Dienste. Halten Sie Zeitzone und Zeitquelle fest, wenn sich Systeme unterscheiden.

Die Beweissicherung besteht nicht darin, ein paar Screenshots zu kopieren. Ein Screenshot lässt Felder weg, verbirgt Filter und kann nur selten verifiziert werden. Exportieren Sie Originalaufzeichnungen möglichst in ihrer nativen Form, bewahren Sie Hashes für gesammelte Dateien auf, beschränken Sie den Zugriff auf die Fallgruppe und dokumentieren Sie, wer jede Kopie bearbeitet hat.

Die folgende Sammelnotiz ist kurz genug für den praktischen Einsatz und konkret genug für ein Audit:

Case: OFF-2025-041
Collected by: security-operator
Collected at: 2025-03-12T09:37:16Z
Source: build-service job history export
Range: 2025-03-01T00:00:00Z to 2025-03-12T09:37:16Z
File: build-jobs.json
SHA-256: <recorded digest>
Storage: restricted evidence repository
Reason: employee exit and agent authority review

Bewahren Sie den Original-Export unverändert auf. Wenn ein Ermittler ihn filtert oder annotiert, speichern Sie dies als separate Arbeitskopie. Diese einfache Trennung hat mehr Streit verhindert als ausgefeilte Forensik-Werkzeuge: Menschen können die Analyse prüfen, ohne den Quelldatensatz unbemerkt zu verändern.

NIST SP 800-92 beschreibt das Log-Management als Prozess aus Erzeugung, Übertragung, Speicherung, Analyse und Entsorgung. Beim Offboarding liegt die Schwachstelle meist bei der Entsorgung. Eine kurze Standardaufbewahrung kann genau den Laufdatensatz löschen, der zeigen würde, ob ein Agent vor oder nach der Zugriffsänderung gehandelt hat. Setzen Sie für Aufzeichnungen, die Ihre Richtlinie aufbewahren darf, einen Aufbewahrungshalt und heben Sie ihn anschließend über den normalen Prozess wieder auf.

Die Autorisierung von Agenten pro Prozess widerrufbar machen

Die Genehmigung eines Entwicklers für einen Agent-Prozess darf nicht zu einer pauschalen Erlaubnis für jeden Prozess werden, der auf seinem Rechner auftauchen kann. Ein Prozess kann ersetzt, aus einem anderen Arbeitsverzeichnis neu gestartet oder nach dem Ausscheiden der Person durch eine Editor-Erweiterung aufgerufen werden. Der Autorisierungsdatensatz braucht eine Identität für den Prozess und einen sofortigen Widerrufsweg.

Hier kann ein Gateway helfen, aber nur, wenn es sich weigert, dem Agenten Anmeldedaten zu übergeben. Sallyport bewahrt API- und SSH-Anmeldedaten in einem verschlüsselten lokalen Tresor auf, autorisiert neue Agent-Prozesse standardmäßig pro Sitzung und zeichnet Sitzungen und einzelne Aktionen getrennt auf.

Exportieren oder bewahren Sie beim Offboarding die relevanten Sitzungs- und Aktivitätsaufzeichnungen auf, widerrufen Sie aktive Sitzungen und sperren Sie den Tresor vor der Geräteübergabe. Diese Reihenfolge schafft eine klare Grenze: Der Agent kann keinen neuen externen Aufruf ausführen, während die Aufzeichnungen seiner früheren Aufrufe für die Prüfung verfügbar bleiben.

Verwechseln Sie die Genehmigung pro Sitzung nicht mit der Genehmigung jeder folgenreichen Aktion. Ein Agent kann eine Sitzung benötigen, um ein Repository zu lesen, während jede Berechtigung für Änderungen an der Produktion bei jeder Nutzung bestätigt werden muss. Legen Sie die strengere Kontrolle auf Anmeldedaten, deren Missbrauch eine Reaktion auf einen Vorfall erzwingen würde, und nicht auf harmlose Nur-Lese-Aufrufe, die zu Genehmigungsmüdigkeit führen.

Genehmigungsmüdigkeit ist ein Designfehler. Wenn Menschen für jede Routineanfrage eine Aufforderung erhalten, lesen sie diese irgendwann nicht mehr. Wenn eine Aufforderung stillschweigend den Zugriff auf voneinander unabhängige Produktionssysteme abdeckt, ist sie zu weit gefasst. Eine gute Autorisierung schafft eine klare Grenze, die ein Bediener im Nachhinein erklären kann.

Laufende Arbeiten und verzögerte Auslöser prüfen

Der Widerruf eines Kontos stoppt Arbeiten, die ein Remotedienst bereits angenommen hat, nicht zuverlässig. Prüfen Sie wartende Builds, Remote-Shells, Automatisierungspläne, Workflow-Ausführungen in Repositories, Jobs zur Paketveröffentlichung, Infrastrukturpläne und Nachrichtenwarteschlangen, die später Arbeit starten können.

Entscheiden Sie für jedes laufende oder wartende Element, ob Sie es abbrechen, unter Beobachtung fertig laufen lassen oder an einen neuen Verantwortlichen übertragen. Die Entscheidung sollte von der Aktion, dem Schadensradius und der Reproduzierbarkeit der Aufgabe abhängen. Ein Deployment mit einem bekannten Änderungsdatensatz kann möglicherweise fertig laufen. Eine Aufgabe, die Zugriffskontrollen ändern oder Daten verschieben kann, sollte normalerweise stoppen, bis der Verantwortliche die Absicht bestätigt.

Erfassen Sie IDs vor dem Abbruch. Eine Job-URL allein ist ein schlechter Beleg, wenn der Dienst Jobdetails nach Ablauf der Aufbewahrungsfrist löscht. Speichern Sie Job-ID, auslösende Identität, Commit- oder Aufgabenreferenz, Start- und Endzeit, verwendete Berechtigungen und Ergebnis. Wenn die Aufgabe während des Austritts fehlschlug, vermerken Sie, ob der Fehler durch Ihren Widerruf verursacht wurde. Andernfalls könnte ein späterer Ermittler einen Erfolg bei der Zugriffskontrolle als Betriebsfehler missverstehen.

Prüfen Sie außerdem verzögerte Ausführung. Cron-Einträge, Launch Agents, CI-Zeitpläne, Cloud-Ereignisregeln und Repository-Workflows können ihre Aktivität wieder aufnehmen, wenn das Team den Austritt bereits für abgeschlossen hält. Eine wiederkehrende Aufgabe sollte an einen verwalteten Verantwortlichen übertragen oder deaktiviert werden. Sie unter einem aufgegebenen Konto aktiviert zu lassen, macht den nächsten Fehler vorhersehbar und schwer zu diagnostizieren.

Erst schließen, wenn eine unabhängige Person das Ergebnis prüfen kann

Die Person, die Änderungen vornimmt, sollte nicht allein den Abschluss des Austritts erklären. Bitten Sie einen Sicherheitskollegen, Dienstverantwortlichen oder Manager, die wichtigsten Punkte zu prüfen: Die frühere Identität kann sich nicht anmelden, alte gemeinsam genutzte Anmeldedaten schlagen fehl, unter dem früheren Verantwortlichen gibt es keine geplante Agent-Arbeit mehr und die Beweissammlung ist lesbar und geschützt.

Verwenden Sie eine Abschlussnotiz, die geprüfte Fakten statt vager Vollständigkeit nennt:

Former identity: disabled and active sessions revoked
Shared credentials: 6 inventoried, 6 replacement paths tested, 6 prior credentials revoked
Agent work: 2 scheduled jobs transferred, 1 queued job canceled
Evidence: exports and collection hashes stored under case OFF-2025-041
Exceptions: none
Verified by: service owner and security reviewer

Wenn eine Berechtigung nicht sofort rotiert werden kann, lassen Sie das Ticket offen und halten Sie die kompensierende Einschränkung, den verantwortlichen Eigentümer und die Frist fest. «Das machen wir später» ist keine Kontrolle. Eine Firewall-Einschränkung, ein deaktivierter Workflow oder eine vorübergehende Dienstsperre kann eine Kontrolle sein, wenn jemand sie prüft und weiß, wann sie ausläuft.

Die erste sinnvolle Änderung ist einfach: Ergänzen Sie das bestehende HR-Austrittsticket um ein Berechtigungsverzeichnis und eine Entscheidung zum Beweishalt. Diese beiden Felder erzwingen das richtige Gespräch, bevor ein Laptop verschwindet, ein Token bestehen bleibt oder ein Aufbewahrungsjob den einzigen Datensatz einer Agent-Aktion löscht.