# Dienstkonten für KI-Agenten ohne geteilte Verantwortlichkeit

KI-Agenten brauchen Dienstkonten. Ein Dienstkonto darf aber nie zum Namen werden, den man verwendet, wenn niemand weiß, wer eine Aktion freigegeben hat. Gib jedem dauerhaften Workflow eine eigene Identität, ordne dieser Identität eine namentlich genannte Person zu und entferne sie, sobald der Workflow endet. Alles andere schafft geteilte Verantwortlichkeit. Anders gesagt: Nach einer problematischen Aktion kann niemand eine vollständige Antwort geben.

Ich habe dieses Problem schon oft gesehen. Ein Team legt ein Konto namens `automation` an, gibt ihm genug Rechte, um mehrere Programmieraufgaben freizugeben, und nennt die Einrichtung vorübergehend. Monate später verwenden ein Deployment-Job, ein Abhängigkeits-Update und ein Agent zur Infrastrukturänderung dasselbe Konto. Es bleibt aktiv, weil seine Deaktivierung etwas kaputtmachen könnte. Wenn es eine Einstellung in der Produktion ändert, weisen die Protokolle `automation` eindeutig aus und erklären fast nichts.

Die Lösung ist kein großes Identitätsprogramm. Es braucht einige klare Grenzen: eine Workflow-Identität für einen Berechtigungszweck, einen menschlichen Besitzer, der sie freigeben oder stoppen kann, Nachweise für jede Nutzung eines bestimmten Laufs und einen Stilllegungsweg, der feststeht, bevor das Konto Zugriff erhält.

## Ein Dienstkonto bezeichnet eine Berechtigung, nicht den Handelnden

Ein Dienstkonto zeigt, welches Berechtigungspaket eine API oder ein System akzeptiert hat. Es beweist nicht, welcher Agent, Prompt, Code-Stand oder Mensch die Anfrage verursacht hat. Teams vermischen diese Aufgaben häufig und stellen dann fest, dass ihr Auditverlauf einen Vorfall nicht erklären kann.

Angenommen, `release-publisher` darf Build-Artefakte veröffentlichen. Eine erfolgreiche, mit diesem Konto authentifizierte Anfrage zeigt, dass die Publisher-Berechtigung verwendet wurde. Sie zeigt nicht, ob ein freigegebener Release-Workflow, ein lokales Skript eines Entwicklers oder ein Agent die Anfrage ausgelöst hat, der eine alte Aufgabe wiederholte, nachdem sein Besitzer den Arbeitsplatz verlassen hatte. Der Authentifizierungsnachweis beantwortet «Welche Berechtigung?». Er beantwortet nicht «Warum dieser Aufruf, in diesem Lauf, jetzt?»

Halte die Ebenen getrennt:

- Die Workflow-Identität besitzt eng definierte Berechtigungen.
- Die Agentensitzung bezeichnet eine bestimmte Prozessausführung.
- Die menschliche Freigabe oder der Automatisierungstrigger erklärt, wer diese Ausführung gestartet oder erlaubt hat.
- Der Aktionsnachweis erfasst Ziel, angeforderte Operation, Ergebnis und Zeitpunkt.

Diese Unterscheidung verändert die Untersuchung. Wenn ein Deployment-Aufruf verdächtig aussieht, deaktiviere zuerst die Workflow-Identität, damit keine weiteren Berechtigungen genutzt werden können. Prüfe danach den Sitzungsnachweis, um den verwendeten Prozess, den ausgeführten Code-Stand und die Person oder das System zu finden, die beziehungsweise das die Sitzung autorisiert hat. Ein einzelner Kontoname kann diese gesamte Geschichte nicht tragen, ohne zu einem gemeinsamen Sammelbecken zu werden.

RFC 6749 trifft in der Beschreibung des OAuth-2.0-Client-Credentials-Grants eine nützliche, aber begrenzte Aussage: Ein Client kann seine Zugangsdaten als Autorisierungsgewährung verwenden, wenn er in eigenem Namen handelt. Das passt zu einem begrenzten maschinellen Workload. Es bedeutet nicht, dass jeder Prozess, der die Zugangsdaten vorlegen kann, denselben legitimen Zweck hat. Wer diese Gewährung mit vollständiger Verantwortlichkeit gleichsetzt, bekommt Probleme.

Ein Agent hat außerdem ein anderes Risikoprofil als ein gewöhnlicher Job. Ein gewöhnlicher Job folgt meist einem festen Codepfad. Ein Agent kann Befehle auswählen, Anfragen erstellen, Argumente verändern, Wiederholungen ausführen oder durch Inhalte aus einem Repository beeinflusst werden. Das Dienstkonto braucht trotzdem einen stabilen Zweck, selbst wenn sich die Entscheidungen des Aufrufers ändern. Wenn sich dieser Zweck nicht in einem einfachen Satz beschreiben lässt, hat das Konto wahrscheinlich verschiedene Aufgaben angesammelt.

## Ein Workflow braucht eine eigene, begrenzte Identität

Ein Workflow verdient eine eigene Identität, wenn er einen anderen Zweck, eine andere Berechtigungsgrenze, einen anderen Besitzer, eine andere Umgebung oder eine eigene Endbedingung hat. Lege kein Konto für jeden Prompt oder jede kurze Aufgabe an. Das erzeugt Lärm, aber keine bessere Kontrolle. Erstelle Identitäten dort, wo du eine Berechtigungseinheit widerrufen kannst, ohne unabhängige Arbeit zu stoppen.

«Abhängigkeitsdateien in freigegebenen Repositories aktualisieren» und «signierte Artefakte in die Produktion veröffentlichen» sollten nicht dieselbe Identität verwenden. Der erste Workflow ändert Quelldateien und eröffnet Review-Anfragen. Der zweite ändert einen Release-Kanal. Auch wenn derselbe Agent beide Vorgänge starten kann, unterscheiden sich Berechtigungen, Genehmiger und Reaktion auf eine verdächtige Aktion.

Der umgekehrte Fehler kostet ebenfalls Zeit: Manche Teams teilen einen einzigen engen Workflow in Dutzende Kontonamen auf, weil jeder Agentenlauf ein neues Konto erzeugt. Lauf-IDs beschreiben bereits kurzlebige Ausführungen. Dienstkonto-Identitäten sollten einen dauerhaften Autorisierungszweck beschreiben. Verwende Sitzungsnachweise für einzelne Läufe und Konten für Berechtigungen, die über mehrere Läufe bestehen.

Ein brauchbares Namensschema ist:

```text
<umgebung>.<produkt-oder-repository>.<workflow-zweck>

prod.payments.release-publisher
dev.docs.dependency-updater
prod.data.backfill-reader
```

Namen helfen Menschen, erzwingen aber keinen begrenzten Umfang. Binde jede Identität nur an die Aktionen, die ihr Workflow braucht. Gib dem Abhängigkeits-Updater die Erlaubnis, einen Branch zu erstellen und eine Review-Anfrage zu stellen, wenn das alles ist, was er tut. Gewähre keine Release-Berechtigungen, nur weil er sie irgendwann brauchen könnte. Dieses «irgendwann» hat mehr dauerhaften Zugriff geschaffen als jede echte Anforderung.

Verwende getrennte Identitäten für getrennte Umgebungen. Ein Entwicklungsagent kann experimentieren, aggressiv wiederholen und mit wegwerfbaren Daten arbeiten. Dieses Verhalten gehört nicht unter eine Produktionsidentität. Wer ein Produktionsgeheimnis in eine Entwicklungskonfiguration kopiert, kehrt die Grenze um: Die am wenigsten kontrollierte Umgebung besitzt nun die stärkste Berechtigung.

Zwei Aufrufe dürfen dieselbe Identität verwenden, wenn sie denselben dokumentierten Workflow bilden, denselben Besitzer haben, denselben Berechtigungssatz nutzen und unter derselben Stilllegungsbedingung enden. Der praktische Test lautet: Wenn die Deaktivierung des Kontos die Frage «Welche voneinander unabhängigen Jobs sind gerade kaputtgegangen?» auslösen würde, deckt das Konto zu viel ab.

## Ein Besitzer muss eine Person sein, die die Arbeit stoppen kann

Jede Workflow-Identität braucht einen namentlich genannten menschlichen Besitzer mit der Befugnis und Pflicht, für sie einzustehen. Ein technischer Kontakt kann den Betrieb unterstützen, und ein Team kann für Kontinuität sorgen. Beides ersetzt keinen bestimmten Besitzer.

Ein Besitzer tut vier konkrete Dinge: Er bestätigt, dass der Workflow noch einen Zweck hat, genehmigt Änderungen an seinen Berechtigungen, reagiert auf verdächtige Aufrufe und stilllegt die Identität, wenn die Arbeit endet. Kann der eingetragene Besitzer diese Aufgaben nicht erfüllen, ist der Eintrag nur Dekoration.

NIST SP 800-53 Revision 5, Kontrolle AC-2 zur Kontoverwaltung, verlangt, Kontotypen zu definieren, Bedingungen für Gruppen- und Rollenzugehörigkeit festzulegen und Konten zu deaktivieren, wenn sie keiner Person mehr zugeordnet oder nicht mehr benötigt werden. Das gilt ebenso für nicht menschliche Konten, auch wenn es oft nur als Vorgabe für Mitarbeiterkonten gelesen wird. Eine Maschinenidentität ohne verantwortlichen Verwalter hat niemanden, der diese Bedingungen festlegt oder entscheidet, dass das Konto nicht mehr gebraucht wird.

Lege den Kontoeintrag in einem Repository oder Register ab, das der Zugriffsprüfungsprozess verwendet. Verstecke ihn nicht in einer Wiki-Seite, die vom tatsächlichen Binding abweicht. Dieses minimale Beispiel enthält genügend Felder für eine ernsthafte Prüfung:

```yaml
identity: prod.payments.release-publisher
owner: "Morgan Lee"
technical_contact: "Release engineering on-call"
purpose: "Publish approved signed payment service artifacts to production"
allowed_actions:
  - "upload signed artifact to production release repository"
  - "read release metadata for the payment service"
environments:
  - production
permission_bindings:
  - "artifact-repository/publish-payments-prod"
credential_method: "short lived workload token"
source_repository: "payments-service"
review_after: "2026-06-30"
retire_when: "The payment service stops using this release workflow"
incident_contact: "Release engineering on-call"
```

Der Eintrag macht Unklarheiten sichtbar. Wenn `allowed_actions` zu einem Absatz mit mehreren Systemen und vagen Verben wie «verwalten» oder «administrieren» wird, teile den Workflow auf. Wenn `retire_when` «nie» lautet oder keine Bedingung enthält, ist das Konto in den Bestand des dauerhaften Zugriffs geraten. Nennt das Besitzerfeld eine Verteilerliste, muss vor der Freigabe eine Person zugewiesen werden.

Besitzerwechsel brauchen eine eigene Kontrolle. Ein ausscheidender Mitarbeiter sollte nicht formell Besitzer bleiben, nur weil die Übertragung mühsam ist. Der neue Besitzer muss das Konto übernehmen, Zweck und Bindings lesen und den nächsten Prüfungstermin setzen. Übernimmt niemand das Konto, wird es deaktiviert. Systeme sind nicht von Verantwortung ausgenommen, nur weil sie weiterlaufen.

## Gemeinsame Konten machen aus einem kleinen Vorfall ein Ratespiel

Ein gemeinsames Konto versagt am deutlichsten bei einem scheinbar normalen Vorfall, nicht erst bei einem spektakulären Angriff. Nehmen wir ein Team, das `prod.agent-ops` für drei Workflows verwendet: einen Release-Agenten, einen Agenten für Vorfallzusammenfassungen und einen Agenten zur Infrastrukturreparatur. Das Konto kann den Deployment-Status lesen, eine Umgebungsvariable ändern und ein Rollback auslösen.

Um 16:20 Uhr bemerkt jemand, dass eine Umgebungsvariable auf einen ungültigen Wert geändert wurde. Das API-Protokoll sagt, `prod.agent-ops` habe die Anfrage gestellt. Das Release-Team sagt, sein Lauf sei früher beendet gewesen. Das Incident-Team sagt, sein Agent habe nur den Status gelesen. Der Infrastrukturverantwortliche sagt, am Nachmittag sei ein Reparatur-Prompt getestet worden, aber die genaue Sitzung sei nicht gespeichert worden. Alle drei Aussagen können stimmen, doch das Kontoprotokoll kann den Widerspruch nicht auflösen.

Die übliche Reaktion besteht darin, Chatnachrichten, Repository-Verlauf, Shell-Historien und Modelltranskripte zu durchsuchen. Das kann eine Antwort liefern, ist aber langsam und unvollständig. Noch schlimmer: Dasselbe Konto bleibt aktiv, weil seine Deaktivierung die Release-Wiederherstellung stoppen könnte. Der Vorfall verbindet damit Erkennung, Eindämmung und unabhängige Produktionsabläufe.

Getrennte Identitäten ändern die Reihenfolge. Wenn `prod.payments.release-publisher` einen unerwarteten Aufruf macht, deaktivierst du genau diese Identität. Das Konto für Vorfallzusammenfassungen und das Reparaturkonto behalten ihre eigenen Berechtigungen. Der Aktionsnachweis sollte Workflow-Identität und Laufreferenz enthalten, damit Ermittler die konkrete Sitzung finden können, ohne aus Erinnerungen zu argumentieren. Deshalb ist «ein Konto pro Team» kein Kompromiss, sondern eine Zusammenlegung von Fehlerdomänen.

Manche Teams verteidigen gemeinsame Konten mit dem Argument, eine zentrale Lösung mache die Rotation einfacher. Das wirkt plausibel, weil nur ein Geheimnis ersetzt werden muss. Die Einsparung ist gering. Die Kosten zeigen sich bei gezieltem Widerruf, Berechtigungsprüfungen und Erklärungen. Automatisiere die Ausstellung von Zugangsdaten und das Verwalten von Bindings, statt die Kontogrenze aus Bequemlichkeit zu verbreitern.

Verwechsle ein gemeinsames Konto nicht mit einer gemeinsamen Berechtigungsrolle. Mehrere Identitäten können dieselbe eng definierte Rolle erhalten, wenn sie dieselbe erlaubte Aktion ausführen. Die Identitäten bleiben getrennt, sodass Protokollierung und Widerruf funktionieren. Eine wiederverwendete Rolle erleichtert die Verwaltung. Eine wiederverwendete Identität zerstört die Zuordnung.

## Der Berechtigungsumfang muss den Aktionen folgen, nicht den Ambitionen des Agenten

Gewähre Zugriff für genau den vorgesehenen Aktionsweg und verlange vom Agenten einen Nachweis, wenn er etwas Weiteres braucht. Die allgemeine Fähigkeit eines Agenten rechtfertigt keine allgemeine Berechtigung.

Beginne mit den Verben und Objekten des Workflows. «Offene Issues in Repository A lesen und in Repository A einen Branch erstellen» beschreibt konkrete Aktionen. «Repository A betreuen» tut das nicht. Die erste Aussage führt zu einem Lesebereich und einer Berechtigung zum Erstellen von Branches. Die zweite endet meist mit weitreichendem Schreibzugriff.

Dasselbe gilt für API-Berechtigungen. Wenn ein Workflow einen Bericht liest und einen Kommentar schreibt, gib ihm keinen Kontoverwaltungszugriff, nur weil die API diese Endpunkte in einer attraktiven großen Rolle bündelt. Erstelle einen kleineren Berechtigungssatz, sofern der Anbieter das zulässt. Ist das nicht möglich, setze einen aktionsbezogenen Vermittler vor die umfassende Zugangsdaten oder überlege, ob der Agent die Aktion unbeaufsichtigt ausführen sollte.

Viele Agenteneinführungen machen hier einen feinen Fehler. Sie vergeben weitreichenden Zugriff, weil der Agent Kontext prüfen muss, bevor er handelt. Kontext lesen und ein Ziel ändern sind unterschiedliche Befugnisse. Gewähre möglichst Lesezugriff und verlange für Zustandsänderungen eine separate Identität oder einen Genehmigungsweg. Ein Modell, das eine Produktionskonfiguration lesen kann, braucht nicht automatisch die Erlaubnis, sie zu bearbeiten.

Teste die Grenze mit absichtlich falschen Anfragen, bevor der Workflow regelmäßig läuft. Für einen Release-Publisher kannst du versuchen, ein Artefakt für ein anderes Produkt zu veröffentlichen, einen Release zu löschen und Repository-Einstellungen zu ändern. Jede Anfrage sollte auf der Autorisierungsebene scheitern. Ein erfolgreicher Normalfall beweist nur, dass genug Zugriff vorhanden ist. Abgelehnte benachbarte Aktionen zeigen, dass nicht zu viel Zugriff vergeben wurde.

Halte das Testergebnis beim Verantwortlichkeitsnachweis fest:

| Versuch | Erwartetes Ergebnis | Prüfergebnis |
| --- | --- | --- |
| Freigegebenes Payment-Artefakt veröffentlichen | Erlaubt | Bestätigt |
| Artefakt für einen anderen Dienst veröffentlichen | Verweigert | Bestätigt |
| Produktions-Release löschen | Verweigert | Bestätigt |
| Repository-Mitgliedschaft ändern | Verweigert | Bestätigt |

Lass einen Agenten keine Identität aus einem Menü mächtiger Konten wählen. Der Workflow-Runner sollte die zum Job gehörende Identität anhängen. Ein Agent, der zwischen unabhängigen Befugnissen wählen kann, kann die entworfene Grenze oft umgehen.

## Zugangsdaten sollten ablaufen, bevor vergessene Workflows verschwinden

Langlebige Zugangsdaten erschweren die Stilllegung, weil eine vergessene Kopie weiter funktionieren kann, nachdem ein sichtbarer Job deaktiviert wurde. Bevorzuge kurzlebige Workload-Zugangsdaten für eine verifizierte Laufzeit oder lass eine kontrollierte Komponente die authentifizierte Aktion ausführen, während der Agent nur das Ergebnis erhält.

Das ist eine andere Frage als die Identitätsgestaltung. Ein Dienstkonto kann gut benannt und einem Besitzer zugeordnet sein und trotzdem außer Kontrolle geraten, wenn sein Geheimnis in einem Repository, einer lokalen Umgebungsdatei, einem Agentenprotokoll oder einem Build-Log liegt. Der Kontoeintrag sagt, wer die Berechtigung verwenden darf. Der Umgang mit Zugangsdaten entscheidet, wer sie tatsächlich vorlegen kann.

Die bevorzugte Abfolge ist einfach:

1. Verifiziere die aufrufende Laufzeit oder Agentensitzung.
2. Stelle ein kurzlebiges Geheimnis mit dem begrenzten Umfang des Workflows aus oder führe die angeforderte Aktion stellvertretend aus.
3. Zeichne die angeforderte Aktion und die Autorisierungsentscheidung auf.
4. Beende die Sitzung und entziehe Berechtigungen, die nur zu dieser Sitzung gehören.

Übergib dem Agenten kein Klartextgeheimnis, nur weil er eine API aufrufen muss. Dadurch werden jeder Prompt, jede Tool-Ausgabe, jede Spur und jedes versehentliche Log zu einem möglichen Verteilungsweg für das Geheimnis. Das Maskieren von Geheimnissen in der Konsolenausgabe hilft nach einer Offenlegung, verhindert aber nicht, dass der Agent sie erhält und wiederverwendet.

Sallyport verfolgt für seine unterstützten HTTP- und SSH-Kanäle den zweiten Weg: Der Agent fordert über seine MCP-Verbindung eine Aktion an, während die App API- und SSH-Zugangsdaten in ihrem verschlüsselten Tresor aufbewahrt und die Aktion selbst ausführt. Dadurch können Zugangsdaten aus dem Agentenkontext herausgehalten werden. Die getrennte Gestaltung von Workflow-Identitäten und Besitzern bleibt trotzdem notwendig.

Für Systeme, die ein Geheimnis direkt verwenden müssen, dokumentiere, wo es ausgestellt und wie es übermittelt wird, wie lange es höchstens gültig ist und wer es widerrufen kann. Die Rotation sollte nicht davon abhängen, dass jemand einen Kalendereintrag erinnert. Mache Ausgabe und Ersetzung zu einem Teil des Deployment-Prozesses und teste eine Rotation, bevor das Konto wichtig wird.

Ein kurzlebiges Geheimnis ist kein Grund, Protokolle zu vernachlässigen. Ein Agent kann auch in einer kurzen Sitzung erheblichen Schaden anrichten. Der Ablauf begrenzt die Dauer eines Missbrauchs. Umfang, Genehmigung und Aktionsaufzeichnung begrenzen, was während der Sitzung passiert.

## Auditnachweise müssen Berechtigung und konkreten Lauf verbinden

Ein brauchbarer Auditverlauf ermöglicht die Rekonstruktion einer Aktion, ohne das Dienstkonto als vollständige Erklärung zu behandeln. Speichere Workflow-Identität, Lauf-ID des Agenten, auslösenden Trigger, Autorisierungsentscheidung, Ziel, Operation, Ergebnis und Zeitstempel in miteinander verknüpfbaren Datensätzen.

Verwende eine einheitliche Ereignisform. Dieses JSON ist an keinen Anbieter gebunden, enthält aber die Felder, die nachträglich meist fehlen:

```json
{
  "event_id": "act_01J8Q7M6K4",
  "time": "2026-04-14T16:20:31Z",
  "workflow_identity": "prod.payments.release-publisher",
  "run_id": "run_8f3c1d",
  "trigger": {
    "type": "approved_ci_job",
    "initiator": "morgan.lee",
    "source_revision": "a1b2c3d4"
  },
  "authorization": {
    "decision": "approved",
    "approved_by": "morgan.lee",
    "approval_ref": "apr_31fa"
  },
  "action": {
    "target": "production artifact repository",
    "operation": "publish",
    "resource": "payments-service/2.4.1"
  },
  "result": "success"
}
```

Lege keine Zugangsdaten, vollständigen Prompts mit vertraulichen Inhalten oder uneingeschränkte Nutzdaten in einen Auditnachweis, nur weil du möglichst viele forensische Details möchtest. Zeichne genügend stabilen Kontext auf, um die Ursache zu belegen, und wende dann dieselben Regeln für den Umgang mit Daten an wie bei jedem anderen Betriebsprotokoll. Ein Auditsystem, das zu einem zweiten Geheimnisspeicher wird, schafft seinen eigenen Vorfallspfad.

Auch die Integrität ist wichtig. Protokolle, die ein Agent oder ein kompromittierter Workflow ändern kann, lösen keine Streitfragen. Verwende nur anhängbare Speicherung, trenne Schreibberechtigungen von Lese- und Administrationsrechten und prüfe die Integrität regelmäßig. Halte die Nachweise auch nach der Stilllegung eines Kontos verfügbar. Die Stilllegung entfernt künftige Berechtigungen, darf aber die für vergangene Aktionen benötigte Geschichte nicht löschen.

Die Sitzungs- und Aktivitätsjournale von Sallyport werden aus einem schreibgeschützten, verschlüsselten und hashverketteten Auditprotokoll erzeugt. Der Befehl `sp audit verify` prüft diese Kette offline, ohne eine Tresorberechtigung zu benötigen. Das liefert nützliche Nachweise für Aktionen, die Sallyport vermittelt. Die umgebenden Systeme müssen trotzdem Besitzer, Trigger und geschäftlichen Genehmigungskontext bewahren.

Richte die Prüfung an Fragen aus, die sich innerhalb weniger Minuten beantworten lassen: Welcher Workflow hatte diese Berechtigung? Wer war zu diesem Zeitpunkt Besitzer? Welcher Lauf hat sie verwendet? Was hat diesen Lauf genehmigt? Welche genaue Operation war erfolgreich oder ist fehlgeschlagen? Wenn eine Antwort aus dem Chatverlauf rekonstruiert werden muss, sind die Nachweise unvollständig.

## Stilllegung ist ein Workflow, keine jährliche Aufräumarbeit

Stelle ein Dienstkonto still, wenn sein Workflow endet, sein Besitzer nicht ersetzt werden kann oder eine wesentliche Änderung seinen ursprünglichen Zweck unwahr macht. Jährliche Prüfungen finden veraltete Konten, sind für bereits bekannte Ereignisse aber zu langsam.

Lege die Stilllegungsbedingungen bereits im ursprünglichen Kontoeintrag fest. Ein Migrationsworkflow kann nach Abschluss der Migration stillgelegt werden. Eine Repository-Automatisierung kann enden, sobald das Repository archiviert wird. Eine Lieferantenintegration kann enden, wenn der Vertrag ausläuft. Ein vereinbartes Ende macht die Entscheidung weniger politisch.

Verwende bei der Stilllegung diese Reihenfolge:

1. Deaktiviere die weitere Nutzung des Kontos und widerrufe aktive Zugangsdaten oder Bindings.
2. Beobachte während eines festgelegten Zeitraums erwartete Fehler und suche nach undokumentierten Abhängigkeiten.
3. Stelle nur die für eine bestätigte Abhängigkeit unbedingt nötige Berechtigung wieder her, mit neuem Besitzer und neuem Eintrag, wenn der Workflow weiterhin legitim ist.
4. Bewahre Verantwortlichkeitsnachweis, Zugriffshistorie und Aktionsprotokolle nach deinen Aufbewahrungsregeln auf.
5. Entferne Identität und verbleibende Zugangsdaten, wenn der Beobachtungszeitraum endet.

Beginne nicht mit dem Löschen des Kontos. Durch das Löschen können nützliche Konfigurationen verschwinden und Fehler schwerer zu diagnostizieren sein. Die Deaktivierung schafft Eindämmung und lässt die normale Überwachung verborgene Aufrufer sichtbar machen. Sie erzwingt außerdem eine wichtige Frage: Wenn ein Workflow ausfällt, wer beansprucht ihn und warum fehlte er im Register?

Der Weggang des Kontobesitzers verlangt sofortige Aufmerksamkeit. Übertrage die Verantwortung vor dessen letztem Arbeitstag erst, wenn der Nachfolger sie übernommen hat. Gibt es keinen Nachfolger, deaktiviere das Konto. Ein Team kann es später für einen dokumentierten betrieblichen Bedarf wieder aktivieren. Ein verwaistes Konto sollte seine Berechtigung aber nicht behalten, nur weil es vielleicht gebraucht werden könnte.

Das gilt auch, wenn ein Workflow wächst. Beginnt ein Abhängigkeits-Updater, Code zu deployen, ändere nicht einfach seinen Zweck, bis er zwei unabhängige Aufgaben beschreibt. Reduziere oder stilllege die alte Identität und erstelle anschließend eine Deployment-Identität mit eigenem Besitzer, Umfang, Tests und Prüfdatensatz. So bleibt die Bedeutung beider Konten im Auditverlauf erhalten.

## Verantwortlichkeit bleibt nur erhalten, wenn Prüfungen Zugriff widerrufen können

Eine Dienstkontoprüfung hat nur dann einen Wert, wenn Prüfer die tatsächlichen Bindings sehen, den aktuellen Besitzer feststellen und den Zugriff ohne eine Woche Verhandlung deaktivieren können. Baue diese Befugnis in den Betriebsprozess ein, bevor du sie brauchst.

Prüfe Workflows mit hohem Risiko häufiger, aber mache aus jeder Prüfung kein Papierritual. Frage, ob der angegebene Zweck noch besteht, ob der Besitzer noch befugt ist, ob die jüngsten Aktionen zum Zweck passen und ob der Umfang weiterhin zur tatsächlichen Nutzung passt. Ist die Antwort unklar, reduziere oder deaktiviere das Konto, während der Besitzer die Situation klärt.

Miss den Zustand mit Fakten, die vernachlässigte Berechtigungen sichtbar machen: Konten ohne Besitzer, überfällige Prüfungen, über längere Zeit fehlende Aktionshistorie, Zugangsdaten nahe oder jenseits ihrer vorgesehenen Lebensdauer und Workflows, deren jüngste Aktionen außerhalb ihres dokumentierten Zwecks liegen. Das sind Prüfwarteschlangen, keine Eitelkeitsmetriken.

Der erste praktische Schritt ist, die vorhandenen Agentenidentitäten zu exportieren und neben jede einen Satz zu schreiben: «Dieser Workflow darf X für Y tun, gehört Z und läuft bis zur Bedingung W.» Konten, die sich gegen diesen Satz sträuben, tragen meist verborgene geteilte Verantwortlichkeit. Deaktiviere oder teile sie auf, bevor du weitere Agentenfähigkeiten hinzufügst.