Ein Mitarbeiter verlässt das Unternehmen. Das Konto wird deaktiviert, die Gruppen werden entzogen, das Verzeichnis meldet Vollzug.
In den meisten Häusern läuft dieser Vorgang sauber. Er ist dokumentiert, er ist geprüft, und er tut genau das, was er soll.
Zwei Wochen später läuft der nächtliche Import immer noch. Mit einem Schlüssel, den dieser Mensch angelegt hat.
Das ist kein Bedienfehler. Es ist eine Lücke zwischen zwei Konzepten, die jedes für sich vollständig sind.
Warum Zugang und Schlüssel nicht dasselbe sind
Ihr Offboarding regelt den Zugang eines Menschen. Es beantwortet die Frage: Darf diese Person noch hinein?
Ein Schlüssel für eine Programmierschnittstelle, kurz API-Schlüssel, beantwortet eine andere Frage: Darf dieser Aufruf ausgeführt werden?
Solange beide Fragen an derselben Identität hängen, fällt der Unterschied nicht auf. Er fällt genau dann auf, wenn eine der beiden Fragen den Menschen verlässt.
Bei Anthropic, dem Anbieter von Claude, lässt sich das nachlesen. Der Fall ist in der Herstellerdokumentation nicht versteckt, er ist ausdrücklich beschrieben.
Drei Schlüsselarten, drei verschiedene Enden
Die Dokumentation führt eine eigene Spalte mit der Überschrift "Acts as": für wen oder wofür ein Schlüssel handelt.
| Schlüsselart | Handelt als | Hört auf zu wirken, wenn |
|---|---|---|
| Personal Key | die Person selbst, mit ihren Rollen | sie den Zugang zur Organisation verliert, bei einem Schlüssel für einen einzelnen Arbeitsbereich auch den Zugang zu diesem |
| Service Account Key | ein Dienstkonto | das Dienstkonto archiviert oder aus dem Arbeitsbereich entfernt wird |
| Workspace Key | niemand, er gehört dem Arbeitsbereich | er abläuft, deaktiviert oder gelöscht wird oder sein Arbeitsbereich archiviert wird |
Für die ersten beiden formuliert die Dokumentation ein klares Versprechen: "Personal keys and service account keys are identity-backed: each belongs to a user or service account your organization already manages, and every request acts as that identity. When that identity is removed from the organization, the key stops working."
Und weiter, als Begründung: "This means that keys won't accidentally outlive the people or workloads that own them."
Das ist genau das Verhalten, das Sie erwarten. Es gilt für die beiden Schlüsselarten, die an einer Identität hängen, und für die dritte nicht.
Zum Workspace Key heißt es ausdrücklich, er ende durch Ablauf, Deaktivierung, Löschung oder die Archivierung seines Arbeitsbereichs, "regardless of whether its creator leaves the organization". Er überlebt den Menschen, der ihn angelegt hat.
Der vierte, der in dieser Tabelle gar nicht steht
Es gibt eine weitere Schlüsselart, und sie hat die weitesten Rechte.
Der Admin API Key taucht in der Übersicht der Schlüsselarten nicht auf. Er wird in einer eigenen Rubrik zum Benutzermanagement behandelt.
Dort steht die Frage, um die es hier geht: Was passiert mit ihm, wenn die Person geht, die ihn angelegt hat?
Die Antwort steht wörtlich da: "The key keeps working. Admin API keys are scoped to the organization, not to individual users, and a key created in claude.ai does not expire. Removing the creator from the organization or deprovisioning them through your identity provider ends their own access, but not the keys they created."
Lesen Sie den letzten Halbsatz zweimal. Der Entzug über das Identitätsmanagement beendet den Zugang der Person, aber nicht die Schlüssel, die sie erzeugt hat.
Der Text nennt auch die Folge für die Rolle: "Downgrading their role does not change the keys either: each key stays active with its original scopes."
Und er nennt die Konsequenz für Ihren Prozess: "When you offboard someone who created Admin API keys, delete those keys in the Keys section of claude.ai > Organization settings > API and create replacements."
Das ist ein Handgriff. Er steht in der Herstellerdokumentation, und er steht in keinem Offboarding-Formular, das ich bisher gesehen habe.
Warum ein Schlüssel ohne Besitzer nicht auffällt
Das klingt nach einer Ordnungsfrage. Anthropic ordnet es in einem eigenen Bericht anders ein.
Im Bericht "Detecting and countering misuse of AI: September 2026" beschreibt der Hersteller, worauf es Angreifer abgesehen haben:
"Access to AI in the form of compromised API keys, session tokens, and devices has increasingly become the sole objective of multiple criminal groups."
Er nennt auch, woher diese Zugänge meistens stammen:
"Most commonly, this comes from legitimate customers who have inadvertently exposed their API keys and session tokens in their products, applications and public code such as GitHub, mobile application install files, Docker containers, websites, and chatbots."
In einem der beschriebenen Fälle blieb ein gestohlener Schlüssel lange im Einsatz:
"One of the stolen API keys was then used by the attacker for roughly three weeks to conduct secondary attacks […]"
Drei Wochen. Wem dieser Schlüssel gehörte, sagt der Bericht nicht.
Meine Lesart: Solange jemand für einen Schlüssel zuständig ist, gibt es auch jemanden, dem ein ungewöhnlicher Aufruf auffallen kann.
Bei einem Schlüssel, dessen Anleger das Haus verlassen hat, ist diese Person nicht mehr da.
Was Single Sign-on und SCIM abdecken, und was nicht
An dieser Stelle kommt der berechtigte Einwand: Dafür haben wir doch das Identitätsmanagement.
Single Sign-on, kurz SSO, ist die zentrale Anmeldung.
SCIM, System for Cross-domain Identity Management, ist das Verfahren, mit dem Ihr Verzeichnis Benutzer und Gruppen an einen Dienst weiterreicht.
Beides funktioniert, und die Dokumentation zieht die Grenze sehr scharf. Übernimmt Ihr Verzeichnis eine Aufgabe, verweigert die Schnittstelle sie.
Wörtlich: "If your identity provider provisions users automatically (JIT or SCIM), invite creation returns 400. If it manages roles (advanced SSO or advanced SCIM provisioning), role updates return 400. If it manages membership (SCIM provisioning), member removals return 400. Reads work regardless."
Das ist eine gute Arbeitsteilung. Sie hat nur eine Eigenschaft, die man kennen muss.
Die Doku zieht die Grenze über vier Fälle: Einladungen, Rollen, Mitgliedschaften und Lesevorgänge. Ein Schlüsselvorgang ist nicht darunter.
Ihr Verzeichnis entzieht also zuverlässig, was es verwaltet. Die Schlüssel gehören nicht dazu.
Warum das eine Governance-Frage ist
Für Unternehmen, die unter die NIS2-Umsetzung fallen, hat dieser Punkt einen Namen im Gesetz.
§ 30 Absatz 2 Nummer 9 BSIG verlangt die "Erstellung von Konzepten für die Sicherheit des Personals, die Zugriffskontrolle und für die Verwaltung von IKT-Systemen, -Produkten und -Prozessen".
Zugriffskontrolle und Verwaltung stehen dort in derselben Nummer, verbunden durch ein "und".
Meine Lesart: Ein Schlüssel, der auf einen Menschen ausgestellt ist und an einer Maschine hängt, liegt genau zwischen beiden.
Die Zugriffskontrolle sagt: Der Mensch ist raus. Die Verwaltung sagt: Der Automatismus läuft. Beide haben recht, und zusammen ergeben sie eine offene Tür.
Was stattdessen gilt
Die Empfehlung des Herstellers ist unmissverständlich: "Your own tooling should use a personal key."
Und für den Gegenfall: "A shared or unattended workload should use a service account key."
Ein Dienstkonto ist eine eigene Identität. Es hat keinen Urlaub, keinen Wechsel und keinen letzten Arbeitstag.
Wird es archiviert, endet auch der Schlüssel.
Es gibt inzwischen einen Schritt darüber hinaus. Er heißt Workload Identity Federation, die Föderation von Maschinenidentitäten.
Dabei tauscht der Automatismus ein kurzlebiges Token Ihres eigenen Identitätsanbieters gegen einen befristeten Zugang.
Die Dokumentation beschreibt das Ziel so: "There is no sk-ant-api... string to mint, distribute, or rotate." Es gibt keinen dauerhaften Schlüssel mehr, der irgendwo liegen könnte.
Für Workspace Keys werden ausdrücklich zwei Wege vorgezogen: "Workspace API keys still work but should be considered legacy; identity-backed keys or Workload Identity Federation are preferred."
Der Nachweis, den Sie danach brauchen
Zugriffskontrolle ohne Nachvollziehbarkeit ist eine Behauptung. Für Sitzungen mit KI-Werkzeugen gibt es dafür inzwischen eine eigene Schnittstelle.
Die Compliance-Schnittstelle listet Sitzungen und liefert deren Mitschriften, ausdrücklich auch für Werkzeuge, die auf dem Rechner des Mitarbeiters laufen: "such as Claude Cowork and Claude Code".
Zwei Einschränkungen sind für die Governance-Frage die wichtigsten, und beide stehen in der Dokumentation. Erstens: "The endpoints on this page are available only to Claude Enterprise organizations." Zweitens sind nur Cowork und Claude Code als stabil geführt, weitere Produkte gelten als Beta.
Bemerkenswert ist die Trennung der Schlüssel auch hier.
Ein Admin-Schlüssel erreicht nur die Aktivitätsübersicht, und auch das nur, wenn die Schnittstelle beim Anlegen des Schlüssels bereits freigeschaltet war.
Für die Mitschriften braucht es einen eigenen Compliance-Schlüssel mit passendem Recht. Diese Rechte lassen sich nach dem Anlegen nicht mehr ändern. Wer sie ändern will, legt einen neuen Schlüssel an und löscht den alten.
Das ist Least-Privilege im Werkzeug selbst. Wer alles lesen will, muss das vorher entscheiden und dokumentieren.
Der Prüfschritt für Montag
Sie brauchen keinen Konsolenzugang, um die Lage in Ihrem Haus zu klären. Sie brauchen drei Fragen und eine Person, die sie beantworten kann.
Erstens: Auf wessen Namen läuft der Schlüssel, mit dem unser nächtlicher Import arbeitet?
Zweitens: Was passiert mit diesem Schlüssel, wenn diese Person morgen kündigt?
Drittens: Wer hat bei uns Schlüssel angelegt, die den Anleger überleben, und wo ist die Liste?
Wenn die dritte Frage nicht in einer Minute beantwortet ist, haben Sie das Ergebnis.
Nicht als Vorwurf, sondern als Aufgabe für die nächste Fortschreibung Ihres Offboarding-Konzepts.
Wenn Sie wissen wollen, welche Schlüssel in Ihrem Haus den Menschen überleben, der sie angelegt hat: schreiben Sie mir. Ich gehe die Liste mit Ihnen durch.
Im zweiten Teil dieser Reihe geht es um die Ebene darüber.
Rollen, Schlüssel und Sitzungen lassen sich so verwalten, dass die dritte Frage das System beantwortet.
Und nicht aus der Erinnerung.
Quellen
- Authentication, Claude Platform Docs: https://platform.claude.com/docs/en/manage-claude/authentication
- User management, Claude Platform Docs: https://platform.claude.com/docs/en/manage-claude/user-management
- Set up the Compliance API, Claude Platform Docs: https://platform.claude.com/docs/en/manage-claude/compliance-api-access
- Retrieve session transcripts, Claude Platform Docs: https://platform.claude.com/docs/en/manage-claude/compliance-sessions
- Detecting and countering misuse of AI: September 2026, Anthropic: https://www.anthropic.com/threat-intelligence-report-september-2026
- § 30 BSIG: https://www.gesetze-im-internet.de/bsig_2025/__30.html
Belegabrufe am 10.09.2026, englische Zitate nachgelesen am 17.09.2026, Zitate aus dem Anthropic-Bericht nachgelesen am 18.09.2026.
