Checkliste zur Übergabe des KI-Agentenzugriffs bei Rollenwechseln

Ein Rollenwechsel zeigt, ob ein Zugriffsmodell für KI-Agenten funktioniert oder still auseinanderfällt. Teams übertragen oft die Berechtigungen für ein Repository und vergessen den Zugangspfad, über den ein Agent Produktions-APIs aufrufen, eine SSH-Sitzung öffnen oder eine Bereitstellung auslösen kann. Der Agent arbeitet weiter, aber niemand kann sagen, wer ihn genehmigen darf, wer seine Aufzeichnungen liest oder wer ihn um zwei Uhr morgens stoppen kann.

Eine Checkliste für die Übergabe des KI-Agentenzugriffs muss vier getrennte Aufgaben übertragen: die Verwahrung der Zugangsdaten, die Befugnis zur Genehmigung von Aktionen, die Verantwortung für die Audit-Prüfung und die Befugnis zum Eingreifen während eines Vorfalls. Wer diese Aufgaben unter dem vagen Begriff «Eigentümerschaft» zusammenfasst, sorgt dafür, dass ein ausgeschiedener Entwickler noch lange nach dem Rollenwechsel praktisch für einen Produktionszugang zuständig bleibt.

Ein Rollenwechsel überträgt Befugnisse, nicht nur Geheimnisse

Das Team muss die Möglichkeit übertragen, Agentenaktionen zu genehmigen und nachzuvollziehen, selbst wenn die Zugangsdaten ihren sicheren Speicher nie verlassen. Ein Geheimnis kann im selben Tresor bleiben, während sich sein Eigentümer, die erlaubte Nutzung, die genehmigende Person und der Prüfer ändern. Das sind unterschiedliche Sachverhalte, für die jeweils eine dokumentierte Antwort nötig ist.

Beginne damit, die Personen zu unterscheiden, die sonst leicht unter einem Namen zusammengefasst werden:

• Die für Zugangsdaten zuständige Person kann das Geheimnis rotieren, deaktivieren oder ersetzen.
• Der Serviceverantwortliche entscheidet, ob der Agent den Zugriff auf das System behalten soll.
• Die genehmigende Person nimmt eine angeforderte Aktion an oder lehnt sie ab, wenn eine Genehmigung erforderlich ist.
• Der Audit-Prüfer kontrolliert, was der Agent tatsächlich getan hat, und verfolgt Ausnahmen weiter.
• Die Person für den Notfall-Widerruf kann den Zugriff stoppen, wenn der normale Verantwortliche nicht erreichbar ist.

In kleinen Teams liegen oft alle fünf Aufgaben bei einem Ingenieur. Für einen eng begrenzten Entwicklungszugang kann das sinnvoll sein. Halte es dann ausdrücklich fest und benenne eine Vertretung. Sonst wird ein Urlaub, ein unerwartetes Ausscheiden oder ein Berechtigungsstreit aus einer abwesenden Person eine schwerwiegende betriebliche Abhängigkeit.

Verwechsle die Zuständigkeit für ein Repository nicht mit der Befugnis, Aktionen auszuführen. Ein Entwickler kann den Schreibzugriff auf ein Repository verlieren, während ein von ihm eingerichteter Agentenprozess weiterhin einen Issue-Tracker, eine Cloud-API oder einen Produktionshost erreicht. Umgekehrt kann ein neuer Teamleiter für das Repository zuständig sein, ohne die Nutzung eines Release-Zugangs durch den Agenten genehmigen zu dürfen. Prüfe beide Ebenen getrennt.

Ich habe Übergaben scheitern sehen, weil die neue Person eine Liste von API-Namen erhielt, aber nicht den Grund, aus dem die einzelnen Zugangsdaten existierten. Ein Eintrag wie «Deployment-Token» sagt dem Nachfolger fast nichts. Halte den Zieldienst, die erlaubte Aktion, die Umgebung, den Eigentümer, den Genehmigungsmodus und die Rotationsmethode fest. Wenn niemand den Zweck einer Zugangsdaten in einem Satz erklären kann, deaktiviere sie, bis das möglich ist.

Änderungen einfrieren, bevor du die Verantwortung überträgst

Pausiere neue Änderungen am Agentenzugriff, solange die Übergabe läuft. Ein bewegliches Ziel führt zu einem Übergabedokument, das schon falsch war, als es jemand unterschrieb.

Das Einfrieren bedeutet nicht, dass eine Woche lang jeder Agentenlauf beendet werden muss. Es bedeutet, dass niemand Zugangsdaten hinzufügt, Berechtigungsbereiche erweitert, Genehmigungseinstellungen ändert oder einem neuen Rechner Zugriff gibt, ohne dass der bisherige und der neue Verantwortliche die Änderung dokumentieren. Halte das Zeitfenster kurz und eindeutig. Beginne bei einem geplanten Rollenwechsel, sobald das Datum bekannt ist, und schließe die Übergabe ab, bevor die Person ihren Zugriff verliert. Bei einem plötzlichen Ausscheiden widerrufst du zuerst den Zugriff und stellst das Verzeichnis anschließend aus den vorhandenen Aufzeichnungen wieder her.

Definiere die Grenze schriftlich. Berücksichtige Agentenprozesse auf Entwicklerrechnern, geplante Automatisierungen, CI-Jobs, die einen Agenten aufrufen, und Testumgebungen mit echten Zugangsdaten. Teams vergessen lokale Werkzeuge regelmäßig, weil sie in der Cloud-Konsole nicht sichtbar sind. Lokaler Zugriff kann weiterhin externe Systeme erreichen.

Eine gute Mitteilung zum Einfrieren beantwortet vier praktische Fragen:

1. Welche Zugangsdaten und Endpunkte gehören zur Übergabe?
2. Wer darf während des Einfrierens eine Ausnahme genehmigen?
3. Wo liegen das aktuelle Verzeichnis und die Aktionsaufzeichnungen?
4. Wann übernimmt der neue Verantwortliche die Aufgabe?

Akzeptiere bei Zugangsdaten für Produktionssysteme oder Kundendaten kein «Das räumen wir später auf». Später entdecken die Leute, dass ein Agent noch einen Token besitzt, von dem sich kein Mitarbeiter mehr an die Erstellung erinnert. Ein kurzes Einfrieren kostet weniger als eine Notfallrotation, bei der niemand weiß, welche Automatisierungen ausfallen werden.

Eine Unterscheidung ist hier wichtig: Das Sperren des Benutzerkontos einer Person ist nicht dasselbe wie der Entzug der Befugnisse eines Agenten. Zugangsdaten können zu einem gemeinsam genutzten Servicekonto gehören. Eine Genehmigung kann an einen lokalen Agentenprozess gebunden sein. Ein öffentlicher SSH-Schlüssel kann einen Host unabhängig vom Identitätskonto des ausscheidenden Entwicklers autorisieren. Die Übergabe muss jeden Weg finden und darf nicht nur das Mitarbeiterkonto schließen.

Ein Verzeichnis erstellen, das die Nutzung und nicht die Geheimnisse beschreibt

Das Übergabeverzeichnis sollte Zugangsdaten identifizieren, ohne geheimes Material in eine Tabelle oder ein Ticket zu kopieren. Der neue Verantwortliche braucht eine operative Übersicht, keinen zweiten, schlechter geschützten Tresor voller Token.

Verwende einen undurchsichtigen Bezeichner, einen Fingerabdruck oder den Namen des Tresoreintrags. Bei SSH-Material hältst du den Fingerabdruck des öffentlichen Schlüssels und die autorisierten Hosts fest. Ein Team kann einen öffentlichen Fingerabdruck prüfen, ohne den privaten Schlüssel offenzulegen:

ssh-keygen -lf ~/.ssh/agent_deploy.pub
256 SHA256:exampleFingerprint agent-deploy (ED25519)

Der genaue Fingerabdruck wird abweichen. Entscheidend ist, dass das Verzeichnis den resultierenden Bezeichner, das Hostkonto und den Grund für die Existenz des Schlüssels festhält. Füge niemals einen privaten Schlüssel oder ein Bearer-Token in das Übergabeartefakt ein, nur damit es «vollständig» wirkt. Dadurch entsteht eine neue Stelle für Datenlecks und die Überprüfung der Rotation wird schwieriger.

Übernimm diese Struktur für jede Zugangsdaten oder jeden Zugriffsweg in die geschützte operative Dokumentation des Teams:

access_id: prod-release-api-01
channel: HTTP
service_and_environment: release API / production
allowed_action: create approved release
secret_reference: encrypted-vault record prod-release-api-01
credential_custodian: incoming platform owner
service_owner: release engineering lead
approval_mode: every use
approver_backup: operations manager
audit_reviewer: security duty engineer
emergency_revoker: platform on-call
rotation_method: replace token in service console, then test read-only endpoint
last_verified: 2025-03-08

Die oben genannten Daten und Namen sind Platzhalter. Ersetze sie durch echte Personen und Daten und schütze den Eintrag anschließend wie operative Metadaten. Er enthält kein Geheimnis, verrät einem Angreifer aber, wo die Befugnisse liegen.

Halte den Berechtigungsumfang fest, nicht nur ein Etikett. «Cloud-Token» kann Lesezugriff auf ein Testkonto oder Administratorzugriff auf mehrere Produktionskonten bedeuten. Bitte den Serviceverantwortlichen, den Umfang zu bestätigen, statt dich auf die Erinnerung des bisherigen Entwicklers zu verlassen. Herstellerkonsolen ändern sich, alte Integrationen bleiben bestehen, und der Name, den jemand einer Zugangsdaten vor zwei Jahren gegeben hat, hat oft wenig mit ihren heutigen Möglichkeiten zu tun.

Das Verzeichnis braucht außerdem eine klare Entscheidung: behalten, rotieren, Umfang reduzieren oder widerrufen. «Übertragen» ist keine Entscheidung. Wenn eine Zugangsdaten nicht mehr verwendet wird, widerrufe sie. Teams behalten ungenutzten Zugriff, weil eine Rotation riskant wirkt. Unbenutzter Zugriff lässt sich schwerer überwachen und gerät leichter in Vergessenheit.

Genehmigungserwartungen brauchen eine benannte menschliche Entscheidung

Eine Genehmigungseinstellung schafft nur dann Kontrolle, wenn das Team vereinbart, wofür die genehmigende Person Verantwortung übernimmt. «Irgendjemand klickt auf Erlauben» ist keine Erwartung, sondern eine Lücke, die auf eine Person unter Zeitdruck wartet.

Lege fest, ob der Agent einmal pro Lauf oder bei jeder Nutzung der Zugangsdaten eine Erlaubnis benötigt. Eine Sitzungsgenehmigung bedeutet: «Ich erkenne diesen Agentenprozess an und erlaube ihm während dieses Laufs die ihm zugewiesene Klasse von Aktionen.» Eine Genehmigung pro Aufruf bedeutet: «Ich habe genau diese angeforderte Nutzung jetzt geprüft.» Beide Entscheidungen adressieren unterschiedliche Risiken.

Verwende eine Sitzungsgenehmigung für begrenzte Aufgaben, bei denen wiederholte Aufforderungen dazu führen würden, dass Menschen blind bestätigen. Ein Agent, der beispielsweise eine Testsuite repariert, kann eine Reihe von Lese- und Schreibaufrufen an einen Entwicklungsdienst benötigen. Die genehmigende Person sollte trotzdem wissen, welcher Prozess den Zugriff angefordert hat und wann die Autorisierung endet.

Verlange eine Genehmigung pro Aufruf, wenn eine einzelne Aktion erhebliche Folgen haben kann: eine Bereitstellung in der Produktion, das Löschen von Daten, eine Änderung von Berechtigungen, das Senden von Nachrichten außerhalb der Organisation oder die Nutzung weitreichender Zugangsdaten. Die zusätzliche Pause ist beabsichtigt. Wenn eine Aktion zu routinemäßig für eine menschliche Entscheidung ist, reduziere den Berechtigungsumfang oder verschiebe sie in einen geprüften Automatisierungsweg. Löse die Ermüdung durch Aufforderungen nicht, indem du jeder sensiblen Zugangsdaten eine weitreichende Sitzungsgenehmigung gibst.

Halte bei der Übergabe folgende Erwartungen in klarer Sprache fest:

• Die Person oder Rolle, die jede Aktionsklasse genehmigen darf.
• Die Situationen, in denen eine Genehmigung pro Aufruf erforderlich ist.
• Welche Nachweise die genehmigende Person vor der Erlaubnis prüfen muss.
• Wann eine Sitzungsgenehmigung abläuft.
• Die Vertretung, wenn der normale Verantwortliche abwesend ist.

Die Nachweise können knapp, müssen aber konkret sein: Zielumgebung, angeforderter Vorgang, Identität der Zugangsdaten, auslösender Agentenprozess und erwartetes Ergebnis. Eine genehmigende Person kann keine fundierte Entscheidung treffen, wenn eine allgemeine Nachricht nur sagt, dass ein Agent Zugriff möchte.

Eine häufige schlechte Empfehlung lautet, Genehmigungen auszuschalten, sobald das Team dem Agenten «vertraut». Sie ist beliebt, weil Aufforderungen die Arbeit unterbrechen. Sie ist falsch, weil Vertrauen in die Codegenerierung eines Agenten ihm nicht automatisch die Befugnis gibt, jede externe Zugangsdaten zu verwenden. Reduziere Genehmigungen, wenn der Aktionsweg eng begrenzt und gut getestet ist. Behalte sie bei, wenn die Konsequenz eine Person braucht, die erklären kann, warum sie die Aktion erlaubt hat.

Die Audit-Prüfung gehört zu einer Person und einem Zeitplan

Logs schaffen keine Verantwortlichkeit, nur weil sie existieren. Bei der Übergabe muss feststehen, wer die Agentenaktivität prüft, wonach diese Person sucht und was sie tut, wenn ein Eintrag keinen Sinn ergibt.

NIST Special Publication 800-53 trennt die Kontenverwaltung in der Kontrolle AC-2 von der Audit-Prüfung in AU-6. Diese Trennung passt gut zum Zugriff von Agenten. Wer Zugangsdaten verwaltet, ist nicht unbedingt die richtige Person, um zu beurteilen, ob die Nutzung des Agenten der genehmigten Arbeit entsprach. Eine unabhängige Prüfung erkennt Fehler und bequeme Annahmen.

Lege einen Prüfzyklus fest, der zum Zugriff passt. Eine für Bereitstellungen verwendete Produktionszugangsdaten kann eine Prüfung nach jeder Bereitstellung sowie nach jedem fehlgeschlagenen oder abgelehnten Versuch erfordern. Für eine wenig kritische Entwicklungsintegration kann eine planmäßige Prüfung ausreichen. Schreibe nicht «regelmäßig». Dieses Wort überlebt jedes verpasste Treffen, weil es nichts verspricht.

Der Prüfer sollte anhand der Aktionsaufzeichnung einige Fragen beantworten:

• Welcher Agentenprozess hat die Anfrage gestellt, und wer hat den Lauf genehmigt?
• Welche Zugangsdaten oder welcher Zugriffsweg wurde verwendet?
• Welches Ziel wurde erreicht, und welches Ergebnis kam zurück?
• Passte die Anfrage zu einer benannten Aufgabe oder einem Änderungsdatensatz?
• Muss eine abgelehnte, wiederholte oder unerwartete Aktion untersucht werden?

Verlange, dass der Prüfer für ungewöhnliche Ereignisse eine Entscheidung festhält: erwartet, korrigiert, eskaliert oder ungeklärt. Für jeden harmlosen API-Lesezugriff braucht das Team keinen feierlichen Bericht. Es braucht aber eine sichtbare Entscheidung, wenn ein Agent außerhalb eines geplanten Zeitfensters auf die Produktion zugreift oder wiederholt Zugangsdaten anfordert, die er nicht benötigen sollte.

Bewahre Aufzeichnungen vor einer Rotation oder einem Widerruf auf, wenn ein Vorfall möglich ist. Eine Rotation behebt die künftige Gefährdung, erklärt aber keine vergangenen Aktionen. Stelle sicher, dass der neue Prüfer den Aufbewahrungsort kennt, weiß, wer Aufzeichnungen exportieren kann, und ihre Integrität prüfen kann. Eine Audit-Spur, die nur ein ausscheidender Entwickler interpretieren kann, ist ein privates Tagebuch und kein operativer Datensatz.

Den Widerruf vor dem Ausscheidungsdatum einüben

Ein Widerrufsplan ist unvollständig, bis das Team ihn anhand einer harmlosen Anfrage getestet hat. Der erste Versuch sollte nicht während eines Vorfalls stattfinden, wenn alle raten müssen, ob eine Ablehnung bedeutet, dass die Kontrolle funktioniert oder der Dienst kaputt ist.

Spiele einen häufigen Fehlerfall durch. Ein Entwickler wechselt das Team und verliert den Zugriff auf die Quellcodeverwaltung. Seine alte Agentenkonfiguration läuft weiterhin auf einem verwalteten Laptop mit gemeinsam genutzten Bereitstellungszugangsdaten. Die Zugangsdaten bleiben gültig, weil sie zum Release-Servicekonto und nicht zum Entwickler gehören. Ein Kollege bittet den Agenten, den «Release-Status zu prüfen», und der Agent kann den Produktionsendpunkt weiterhin aufrufen. Das Team hielt die Deaktivierung des Mitarbeiterkontos für ein abgeschlossenes Offboarding. Der gemeinsam genutzte Zugriffsweg war jedoch noch offen.

Teste stattdessen den tatsächlichen Weg. Der Serviceverantwortliche kann eine nicht destruktive Anfrage an ein Testziel organisieren, etwa das Lesen eines Status, die unter der bisherigen Autorisierung ausgeführt wird. Widerrufe anschließend die alte Autorisierung, deaktiviere die Zugangsdaten oder entferne den erlaubten Weg, wie es die Übergabe verlangt. Wiederhole die Anfrage und bestätige drei Dinge: Der Zugriff schlägt fehl, der Fehler hat den erwarteten Grund, und die Audit-Aufzeichnung identifiziert den Versuch.

Dieser Test findet mehr als vergessene Zugangsdaten. Er entdeckt veraltete lokale Konfigurationen, eine zweite Kopie einer SSH-Autorisierung, eine Automatisierung mit einem unerwarteten Servicekonto und einen Prüfer, der den zugehörigen Eintrag nicht findet.

Halte den Test eng begrenzt. Du musst keine destruktiven Vorgänge ausführen, um den Widerruf nachzuweisen. Ein abgelehnter Statusaufruf oder ein zurückgewiesener Verbindungsversuch liefert genügend Belege, wenn das Zugriffs-Gateway ihn ordnungsgemäß aufzeichnet. Dokumentiere den verwendeten Befehl oder die Anfrage, das erwartete Ergebnis, das tatsächliche Ergebnis und die Person, die den Test beobachtet hat.

Wenn der Test fehlschlägt, schließe die Übergabe nicht mit dem Versprechen ab, die Sache zu untersuchen. Behandle die Zugangsdaten als aktiv und die Zuständigkeit als ungeklärt. Eskaliere an die Person für den Notfall-Widerruf, beschränke den Zugriffsweg und ermittle alle Stellen, an denen die Autorisierung zwischengespeichert oder wiederverwendet wurde. Der fehlgeschlagene Test erfüllt seine Aufgabe, weil er den Weg offenlegt, solange der bisherige Verantwortliche noch Fragen beantworten kann.

Notfallkontakte brauchen Befugnis und einen funktionierenden Weg

Notfallkontakte sind kein Feld im Verzeichnis. Es sind die Personen, die eine zeitkritische Entscheidung treffen können, wenn ein Agent eine unsichere Aktion versucht oder der normale Verantwortliche nicht reagieren kann.

Benenne für jede sensible Zugriffsgruppe einen primären Kontakt und eine Vertretung. Nenne den Weg, über den sie während eines Vorfalls erreichbar sind, den Umfang, in dem sie widerrufen dürfen, und den Serviceverantwortlichen, der später über eine Wiederherstellung entscheidet. Führe kein allgemeines Teampostfach als einzigen Notfallkontakt auf. Postfächer sammeln Nachrichten, übernehmen aber keine Verantwortung.

Definiere die Auslöser in operativen Begriffen. Beispiele sind eine Agentenaktion außerhalb einer genehmigten Änderung, wiederholte fehlgeschlagene Autorisierungen, ein unerwarteter neuer Agentenprozess, der Produktionszugangsdaten anfordert, oder eine Audit-Aufzeichnung, die keiner Arbeit zugeordnet werden kann. Der Kontakt sollte wissen, ob alle Agentenaktionen pausiert, eine einzelne Zugangsdaten widerrufen, ein einzelnes Hostkonto deaktiviert oder der Serviceverantwortliche angerufen werden muss.

Eine gute Übergabe berücksichtigt auch den unangenehmen Fall, dass die Person für den Notfall-Widerruf selbst die Rolle wechselt. Übertrage diese Fähigkeit, bevor der Rollenwechsel wirksam wird, und teste anschließend, ob die neue Person handeln kann. Vermeide ein gemeinsam genutztes «Break-Glass»-Geheimnis, das per Chat weitergegeben wird. Es zerstört die Nachvollziehbarkeit und bleibt meist noch lange nach dem Ende des Notfalls im Verlauf einer Person erhalten.

Halte auch die Regel für die Wiederherstellung fest. Der Notfall-Widerruf sollte einfach sein. Für die Wiederherstellung müssen jedoch der Serviceverantwortliche den Umfang bestätigen, der Audit-Prüfer das Ereignis untersuchen und die neue verwahrende Person die Zugangsdaten übernehmen. Teams, die diese Regel überspringen, stellen oft weitreichenden Zugriff wieder her, nur damit eine blockierte Aufgabe verschwindet.

Ein Gateway sollte die Übergabe sichtbar machen

Ein lokales Aktions-Gateway kann die Zahl der Stellen verringern, an denen diese Übergabe scheitert. Es ersetzt jedoch nicht die Entscheidungen über Zuständigkeiten. Sallyport bewahrt Zugangsdaten in einem verschlüsselten Tresor auf, verlangt, dass der Tresor vor dem Ausführen von Aktionen geöffnet ist, und zeichnet sowohl Agentenläufe als auch einzelne Aufrufe auf. Dadurch hat ein Prüfer der Übergabe konkrete Stellen zur Kontrolle.

Die Unterscheidung zwischen Sitzungsgenehmigung und Genehmigung pro Aufruf ist beim Festlegen der oben beschriebenen Erwartungen hilfreich. Der neue Verantwortliche sollte entscheiden, welche Zugangsdaten bei jeder Nutzung eine neue menschliche Entscheidung erfordern, statt die bequeme Einstellung des bisherigen Entwicklers zu übernehmen.

Für die verschlüsselte, hashverkettete Prüfspur kann ein neuer Prüfer diesen Offline-Prüfbefehl ausführen:

sp audit verify

Ein erfolgreiches Ergebnis sollte melden, dass die Prüfung erfolgreich abgeschlossen wurde. Ein fehlgeschlagenes Ergebnis sollte ausdrücklich angeben, dass die Prüfung fehlgeschlagen ist, statt die Aufzeichnung stillschweigend als vertrauenswürdig zu behandeln. Führe den Befehl als Teil der Übergabenachweise aus und speichere das Ergebnis zusammen mit dem Übergabedatensatz. Der Befehl prüft die Kette über den Chiffretext und benötigt den Tresorschlüssel nicht. Das ist nützlich, wenn der Prüfer Aufzeichnungen kontrollieren muss, ohne Zugriff auf die Zugangsdaten zu erhalten.

Mache aus einem Gateway kein allgemeines Richtlinienprojekt. Ein langes Regelwerk mit Ausnahmen für jedes Team altert schlecht und erschwert Übergaben. Halte die Entscheidungspunkte verständlich: Darf der Tresor irgendeine Aktion erlauben, ist dieser Agentenlauf autorisiert und benötigt diese Zugangsdaten jedes Mal eine Person? Sorge anschließend dafür, dass benannte Personen für die Antworten zuständig sind.

Die Abnahme sollte zeigen, dass das Team ohne die ausscheidende Person arbeiten kann

Schließe die Übergabe erst ab, wenn das neue Team die Kontrolle über jeden aktiven Zugriffsweg nachgewiesen hat. Ein unterschriebenes Dokument ohne Widerrufstest, benannten Prüfer und funktionierenden Eskalationsweg ist Papierkram und kein Beleg.

Verwende diese Abschluss-Checkliste für jede betroffene Gruppe von Zugangsdaten:

1. Das Verzeichnis nennt Dienst, Umfang, verwahrende Person, genehmigende Person, Prüfer, Vertretung und Person für den Notfall-Widerruf.
2. Der Serviceverantwortliche hat «behalten», «rotieren», «Umfang reduzieren» oder «widerrufen» gewählt, und das Team hat das Ergebnis festgehalten.
3. Die neue genehmigende Person hat die Erwartungen für Sitzungs- und Aufrufgenehmigungen schriftlich übernommen.
4. Der Audit-Prüfer hat aktuelle Aktionsaufzeichnungen gefunden und, sofern verfügbar, die Integritätsprüfung bestätigt.
5. Das Team hat den Widerruf oder die Ablehnung mit einer harmlosen Anfrage getestet und das Ergebnis dokumentiert.

Lass den bisherigen Entwickler nur für die Richtigkeit der offengelegten Informationen unterschreiben, nicht für künftige Aktionen nach dem Ende seiner Rolle. Die neue verwahrende Person und der Serviceverantwortliche sollen ihre Aufgaben getrennt übernehmen. Diese Aufteilung ist wichtig, wenn ein späterer Vorfall einen veralteten Zugriffsweg offenlegt: Das Team kann erkennen, ob die Ursache eine nicht offengelegte Zugangsdaten, eine nicht durchgeführte Rotation oder ein Verantwortlicher war, der die Aufgabe nie übernommen hatte.

Der abschließende Test ist einfach. Bitte die neuen Verantwortlichen, ohne den ausscheidenden Entwickler anzurufen, zu beantworten: Welcher Agent kann diesen Dienst erreichen, wer darf ihn genehmigen, wer liest die Aufzeichnung und wer kann ihn heute Nacht stoppen? Wenn eine Antwort vage bleibt, ist die Übergabe noch nicht abgeschlossen.