# Genehmiger für KI-Agent-Aktionen: Verantwortung nach Schicht Ein **Genehmiger für KI-Agent-Aktionen** sollte die Person sein, die während der jeweiligen Schicht für das betroffene System verantwortlich ist. Standardmäßig sollte das nicht der Entwickler sein, der zufällig die Codierungssitzung geöffnet hat. Oft sind das verschiedene Personen. Behandelt man sie als austauschbar, entstehen Genehmigungen, die so lange legitim aussehen, bis ein Produktionsproblem auftritt. Ich habe erlebt, wie das auf ganz gewöhnliche Weise schiefgeht, ohne dramatische Sabotage. Ein Entwickler bittet einen Agenten, ein Build-Problem zu untersuchen. Der Agent findet einen zugehörigen Produktionsendpunkt, fordert eine Schreibaktion zur Anpassung einer Einstellung an, und der Entwickler genehmigt sie, weil der Prompt in seinem Terminal erschienen ist. Der Dienstverantwortliche entdeckt die Änderung später während seiner Bereitschaftsschicht, ohne Kontext und ohne brauchbare Antwort auf die Frage: «Wer hat dieses Risiko akzeptiert?» Die Verantwortung muss dem System, seinem aktuellen Zustand und der Person folgen, die den Pager trägt. Ein gutes Genehmigungsdesign macht das sichtbar, bevor die Aktion ausgeführt wird. ## Der Starter einer Sitzung trägt nur selten die Folgen Die Person, die einen Agenten startet, ist für die eingegebene Anfrage verantwortlich. Dadurch ist sie nicht automatisch für die Datenbank, das Anbieter-Konto, das Bereitstellungsziel oder die Kundendaten verantwortlich, auf die der Agent möglicherweise zugreift. Diese Unterscheidung klingt kleinlich, bis eine Coding-Aufgabe eine Grenze überschreitet. Ein Repository kann Bereitstellungsskripte, operative Zugangsdaten, Migrationstools und Verweise auf Systeme enthalten, die von mehreren Teams betreut werden. Ein Agent kann solchen Pfaden schneller folgen als ein Mensch, der das Repository gut kennt. Die Vertrautheit des Starters mit einer Codebasis verleiht ihm keine operative Befugnis über jedes erreichbare System. Trennen Sie in Ihrem Design drei Rollen: - Der Anforderer bittet den Agenten, etwas zu untersuchen, zu ändern oder bereitzustellen. - Der Systemverantwortliche übernimmt während der zugewiesenen Schicht das operative Risiko für den Zieldienst. - Der Ausführende besitzt nach der Autorisierung die Fähigkeit, den Aufruf oder Befehl auszuführen. In einem kleinen Team kann eine Person alle drei Rollen übernehmen. Das ist in Ordnung, wenn es ausdrücklich festgelegt ist. Der Fehler besteht darin, sie stillschweigend zusammenzulegen, nur weil der Agent auf dem Rechner eines Entwicklers läuft. Damit wird auch ein häufiges Argument klarer: «Der Entwickler ist für seinen Agenten verantwortlich.» Er ist dafür verantwortlich, den Agenten zu steuern und den eingereichten Code zu verantworten. Der Bereitschaftsverantwortliche trägt die Verantwortung für das Verhalten des Dienstes, den Umgang mit Daten, Rollback-Entscheidungen und Auswirkungen auf Kunden. Ein Berechtigungs-Prompt sollte bei der Person landen, die diese zweite Entscheidung treffen kann. NIST SP 800-53 Rev. 5, Kontrolle AC-2, fordert benannte Kontenverwalter und Verfahren zur Kontenverwaltung. Die Kontrolle schreibt keine Genehmigungsoberfläche für Agenten vor, doch die zugrunde liegende Disziplin lässt sich direkt übertragen: Weisen Sie die Verantwortung für Zugriffe zu, statt Zugriff als selbstverständliche Eigenschaft der gerade angemeldeten Person zu behandeln. Bei Agent-Aktionen ist der relevante Kontenverwalter häufig der aktuelle Dienstverantwortliche, nicht der Benutzer des Arbeitsplatzes. ## Dienstverantwortung muss eine Schichtgrenze enthalten Ein belastbarer Verantwortungsdatensatz nennt sowohl den Dienst als auch die Person, die gerade zuständig ist. Ein statischer Teamname reicht um 02:00 Uhr, während einer Abwesenheit oder mitten in einem Incident nicht aus. Führen Sie für jedes System, das ein Agent beeinflussen kann, ein kleines Verzeichnis mit vier Angaben: primäres zuständiges Team, Verantwortlicher der aktiven Schicht, Vertretung und Eskalationsweg. Das Verzeichnis kann in einem Bereitschaftssystem, einem Repository oder einem internen Verzeichnis liegen. Der Ort ist weniger wichtig als die Aktualität und die Möglichkeit, dass ein Genehmigungssystem darauf zugreift. Verwenden Sie die Dienstgrenze, die auch die Betreiber bei einem Alarm verwenden. «Payments API Produktion» ist ein brauchbares Ziel. «Backend» ist es nicht. Ein einziger umfassender Teamname verbirgt unterschiedliche Datenbanken, Anbieter, Datenklassifizierungen und Rollback-Verfahren. Ein minimaler Datensatz kann so aussehen: ```yaml service: billing-api-production active_owner: billing-oncall backup_owner: payments-duty-manager escalation: incident-commander approval_rules: read_customer_records: session change_remote_configuration: per_call production_database_write: per_call create_vendor_credentials: prohibited ``` Das ist keine Richtliniensprache, die ein Agent interpretieren soll. Es ist eine von Menschen gepflegte Erklärung darüber, wer Entscheidungen treffen darf und wie viel Prüfung eine Aktion braucht. Sie verhindert einen bekannten Fehler: Eine Genehmigungsanfrage landet in einem allgemeinen Engineering-Kanal, jemand erkennt den Namen des Repositories, aber niemand erkennt das dahinterliegende Produktionssystem. Behandeln Sie das Verzeichnis als operative Daten. Eine Teamneustrukturierung, ein neuer verwalteter Dienst oder eine Änderung der Bereitschaftsrotation kann es ungültig machen. Wenn Ihre Genehmigungsweiterleitung von einer Tabelle abhängt, die nur ein Manager bearbeiten kann, haben Sie einen stillen zentralen Ausfallpunkt geschaffen. ## Das Risiko einer Aktion hängt vom Ziel ab, nicht vom Verb «Lesen» und «Schreiben» sind zu grob, um Genehmigungsrechte festzulegen. Ein Lesezugriff auf einen öffentlichen Statusendpunkt ist etwas anderes als ein Lesezugriff, der einen Kundenexport, ein Bereitstellungsgeheimnis oder eine vollständige Liste interner Hosts zurückgibt. Eine Schreibaktion, die einen temporären Branch erstellt, unterscheidet sich von einer Schreibaktion, die eine Einstellung beim Zahlungsanbieter verändert. Klassifizieren Sie Aktionen nach den Folgen eines erfolgreichen Ergebnisses. Beginnen Sie mit dem Zielsystem und den Daten. Berücksichtigen Sie danach Umkehrbarkeit und Schadensradius. So erhalten Verantwortliche eine sinnvolle Grundlage, um den Umfang einer Genehmigung festzulegen. Eine praktische Einteilung kann klein bleiben: - Routinemäßige operative Lesevorgänge geben keine sensiblen Inhalte zurück und ändern keinen Zustand. - Begrenzte Änderungen betreffen eine bekannte Ressource und haben ein dokumentiertes Rollback. - Änderungen mit großer Auswirkung betreffen Produktionskonfiguration, Kundendaten, Zugriffe oder externe Verpflichtungen. - Verbotene Aktionen sollten niemals über einen autonomen Agent-Kanal ausgeführt werden. Bezeichnen Sie eine Aktion nicht als risikoarm, nur weil die HTTP-Methode GET lautet. Ich habe Diagnoseendpunkte gesehen, die Umgebungsvariablen, signierte Links und operative Details zurückgaben, die niemals bei einem Coding-Agenten hätten landen dürfen. Die Person, die den Endpunkt versteht, muss ihn klassifizieren. Fordern Sie umgekehrt nicht für jede harmlose Statusabfrage eine manuelle Bestätigung. Dadurch entsteht Genehmigungsmüdigkeit. Irgendwann klicken Menschen eine Routineanfrage durch, weil sie eine Routine erwarten, und genehmigen dann den einen Aufruf, der keiner war. Verwenden Sie eine Genehmigung pro Aufruf für Zugangsdaten und Ziele, bei denen jede Ausführung eine bewusste Entscheidung verdient. Der Genehmigungstext muss das konkrete Ziel nennen. «Agent fordert API-Zugriff an» sagt dem Verantwortlichen nichts. «Agent-Prozess fordert PATCH an der Produktionskonfiguration von billing mit der Zugangsdaten billing-admin an» liefert genug Informationen, um innezuhalten und die richtigen Fragen zu stellen. ## Eine begrenzte Sitzung ist keine Blankovollmacht Eine Sitzungsfreigabe sollte einen identifizierbaren Agent-Prozess für einen festgelegten Zeitraum abdecken, nicht jeden zukünftigen Prozess, der aus demselben Repository oder Benutzerkonto gestartet wird. Dieser Unterschied ist wichtig, wenn ein Terminal während einer Übergabe geöffnet bleibt, ein Entwickler einen Agenten nach einer Änderung seiner Anweisungen neu startet oder ein bösartiger lokaler Prozess einen bekannten Befehl nachahmt. Eine Genehmigung, die nur an eine Benutzeridentität gebunden ist, ist zu weitreichend. Eine Genehmigung, die an einen Prozess ohne eindeutige Identität gebunden ist, kann leicht falsch verstanden werden. Eine gute Sitzungsfreigabe beantwortet in klarer Sprache fünf Fragen: Welcher Prozess hat sie angefordert? Wer hat diesen Prozess signiert oder bereitgestellt? Welchen Aktionskanal darf er verwenden? Welcher Dienstumfang gilt? Wann endet die Berechtigung? Die Sitzung sollte enden, sobald der Prozess beendet wird. Ein neuer Prozess braucht eine neue Entscheidung. Sallyports Autorisierung pro Sitzung folgt diesem Muster: Sie zeigt die Code-Signatur des anfordernden Prozesses und genehmigt die Ausführung nur bis zu ihrem Ende. Das ist eine bessere Voreinstellung, als einem Terminal-Tab zu vertrauen, denn ein Terminal-Tab ist keine Identitätsgrenze. Halten Sie Zugangsdaten mit großer Auswirkung außerhalb der Sitzungsfreigabe. Eine Schreibaktion in einer Produktionsdatenbank oder eine Änderung des Zugriffs bei einem Anbieter sollte bei jeder Nutzung den aktuellen Verantwortlichen fragen, selbst wenn dieser zehn Minuten zuvor die Diagnosesitzung des Agenten genehmigt hat. Die erste Genehmigung sagt: «Dieser Prozess darf an diesem System arbeiten.» Die spätere Genehmigung sagt: «Ich akzeptiere genau diese irreversible oder sensible Aktion.» Das sind verschiedene Entscheidungen. Vermeiden Sie dauerhafte Freigaben mit Bezeichnungen wie «Entwicklertools». Sie werden zu unsichtbaren Berechtigungspools. Außerdem wird die Nachprüfung eines Incidents schwierig, weil niemand sagen kann, ob die genehmigende Person erwartet hat, dass genau dieser Agent diese Fähigkeit nutzt. ## Eine Schichtübergabe muss Befugnisse übertragen, nicht nur Informationen Eine Übergabenachricht mit dem Inhalt «Alex hat jetzt Bereitschaft» löst das Problem bei Agent-Genehmigungen nicht, wenn die Sitzungen und Freigaben des Vortags unter dem bisherigen Verantwortlichen weiter funktionieren. Die abgehende Person sollte aktive Agent-Arbeit genauso übergeben wie einen teilweise entschärften Alarm. Erfassen Sie die Prozessidentität, die Zieldienste, den angeforderten Umfang, den Ablaufzeitpunkt und alle Aktionen, die auf eine Bestätigung warten. Der neue Verantwortliche muss diesen Datensatz sehen können, bevor er die Schicht übernimmt. Verwenden Sie diese Reihenfolge: 1. Beenden oder widerrufen Sie Sitzungen, die die abgehende Person nicht länger unterstützen möchte. 2. Listen Sie aktive Sitzungen auf, die weiterlaufen müssen, einschließlich Ziel und Ablaufzeitpunkt. 3. Übertragen Sie das Dienstverzeichnis an die neue Person und bestätigen Sie ihren Benachrichtigungsweg. 4. Verlangen Sie für neue Aufrufe mit großer Auswirkung eine frische Entscheidung der neuen Person. Übertragen Sie keine umfassende Genehmigung von einer Schicht auf die nächste, nur weil die technische Aufgabe noch nicht abgeschlossen ist. Die neue Person kann einen anderen Incident-Kontext, andere Wartungseinschränkungen oder Kenntnisse über ein laufendes Anbieterproblem haben. Ihre Genehmigung muss ihre eigene sein. Der schwierige Fall ist eine Aktion, die bei der Übergabe bereits läuft. Ist sie umkehrbar und beobachtbar, lassen Sie sie unter der aufgezeichneten Autorisierung zu Ende laufen und machen Sie das Ergebnis für die neue Person sichtbar. Ist sie destruktiv, nach außen sichtbar oder wartet sie auf einen zweiten Aufruf, stoppen Sie an der Grenze und fragen Sie erneut. Einige Minuten Verzögerung kosten weniger, als einer fremden Person eine ungeprüfte Produktionsänderung zu hinterlassen. ## Incidents brauchen engere Befugnisse, kein großzügigeres Gedächtnis Während eines Incidents wollen Teams verständlicherweise schnell handeln. Oft reagieren sie darauf, indem sie einem Agenten eine umfassende, lang gültige Berechtigung geben, um «bei der Reparatur der Produktion zu helfen». Diese Berechtigung überlebt die Dringlichkeit und wird schließlich zu einer unerklärten Lücke. Übertragen Sie die Genehmigung dem Incident Commander oder der Person, die dieser Commander für das betroffene System formell delegiert hat. Der normale Bereitschaftsverantwortliche des Dienstes sollte möglichst beteiligt bleiben. Ein Incident braucht jedoch eine entscheidende Person, wenn mehrere Teams dieselbe Abhängigkeit berühren. Schreiben Sie die Incident-Referenz in den Genehmigungsdatensatz. Begrenzen Sie sie auf den Dienst und die Behebungsaktion. Setzen Sie einen kurzen Ablaufzeitpunkt, der zur Arbeit passt, und schließen oder widerrufen Sie die Freigabe, wenn der Incident endet. Stellen Sie sich einen Agenten vor, der eine außer Kontrolle geratene Warteschlange entschärfen soll. Er prüft Metriken, schlägt eine Konfigurationsänderung vor und fordert einen Befehl zum Löschen von Nachrichten an. Der Incident Commander kann nach Prüfung des Rollbacks eine vorübergehende Anpassung der Parallelität genehmigen. Er sollte das Löschen von Nachrichten nicht genehmigen, nur weil es schnell geht. Die Anfrage muss ausdrücklich nennen, um welche Warteschlange und welche Nachrichten es geht, welcher Wiederherstellungsweg existiert und ob Kunden Arbeit verlieren. Geschwindigkeit entsteht durch vorbereitete Befugniswege, klare Verantwortliche und verständliche Anfragen. Sie entsteht nicht dadurch, dass jeder Beteiligte für einen Nachmittag zum Produktionsadministrator wird. ## Genehmigungs-Prompts müssen eine brauchbare Entscheidung erzwingen Ein Prompt ist ungeeignet, wenn ein kompetenter Verantwortlicher innerhalb weniger Sekunden nicht erkennen kann, was er genehmigt. Er ist ebenso ungeeignet, wenn er für eine gewöhnliche Aktion eine völlig neue Sicherheitsanalyse verlangt. Der Prompt sollte die Entscheidungspunkte sichtbar machen, die der Verantwortliche auch im normalen Betrieb verwendet. Nehmen Sie die Identität des Anforderers, die Identität des Agent-Prozesses, den Aktionskanal, die Bezeichnung der Zugangsdaten, das Ziel, den Vorgang und den Umfang auf. Bei einem Befehl zeigen Sie den exakten Befehl und den Remote-Host. Bei einem HTTP-Aufruf zeigen Sie Methode, Host, Pfad und eine sichere Beschreibung des Bodys. Zeigen Sie niemals das Geheimnis selbst als Beleg dafür, dass die Zugangsdaten existieren. Das ist der Unterschied zwischen brauchbaren und nutzlosen Prompts: ```text Request: production configuration change Process: signed coding-agent process, session 8f3a Owner: billing-oncall Credential: billing-admin Action: PATCH https://api.internal.example/v1/routing/default Body: {"provider":"secondary"} Scope: one call Reason supplied: mitigate provider timeout during INC-482 ``` Ein Prompt, der nur «Toolzugriff erlauben?» lautet, drängt den Verantwortlichen zu einer rituellen Genehmigung. Er nennt weder das Ziel noch die Auswirkung. Wenn Ihre Werkzeuge nicht genug Kontext für eine Entscheidung liefern können, sollten sie die Aktion ablehnen, bis der Anforderer ihn bereitstellt. Überlassen Sie einem frei formulierten Feld «Begründung» nicht die Sicherheitsentscheidung. Agenten können überzeugenden Text billig erzeugen. Behandeln Sie die Begründung als Kontext für den Menschen, während das System Ziel, Zugangsdaten und Genehmigungsumfang erzwingt. ## Prüfdatensätze müssen die unangenehmen Fragen beantworten Nach einer unerwarteten Änderung fragen Menschen, wer sie genehmigt hat, welcher Prozess sie ausgeführt hat, welche Zugangsdaten verwendet wurden, welches Ziel erreicht wurde und ob jemand den Datensatz später verändert hat. Eine Prüfspur, die diese Fragen nicht vollständig beantwortet, ist nur ein Hilfsmittel zur Fehlersuche. Halten Sie Sitzungsentscheidungen und einzelne Aktionsereignisse getrennt, aber verknüpfen Sie sie. Ein Sitzungsdatensatz beschreibt den Prozess und den genehmigenden Verantwortlichen. Ein Aktivitätsdatensatz beschreibt jeden Aufruf oder Befehl und sein Ergebnis. Erfassen Sie auch Ablehnungen und Widerrufe. Fehlgeschlagene Versuche erklären oft eine spätere Umgehung oder zeigen, dass ein Prozess Grenzen austestet. Machen Sie den Datensatz manipulationssicher erkennbar. Ein hashverkettetes Protokoll macht Löschung und Änderung feststellbar, wenn jemand die Kette unabhängig prüfen kann. Es macht aus einer schlechten Genehmigung keine gute und ersetzt keine Zugriffskontrollen. Es gibt Ermittlern aber die Möglichkeit zu prüfen, ob die Historie noch mit der aufgezeichneten Reihenfolge übereinstimmt. Sallyport schreibt Sitzungs- und Aktivitätsjournale aus einem verschlüsselten, hashverketteten und blind beschreibbaren Protokoll. Mit `sp audit verify` lässt sich die Kette offline über dem Chiffretext prüfen. Das ist nützlich, weil der Prüfer keinen Zugriff auf operative Geheimnisse braucht, um die Integrität des Datensatzes zu testen. Verstecken Sie Agent-Aktionen nicht in allgemeinen Anwendungslogs. Solche Logs lassen die menschliche Entscheidung oft weg, rotieren schnell und vermischen irrelevante Ereignisse mit der Aktionsspur. Führen Sie einen Datensatz, den ein Bereitschaftsverantwortlicher, ein Sicherheitsprüfer und ein Incident Commander jeweils lesen können, ohne eine Geschichte aus sechs Systemen zusammensetzen zu müssen. ## Fehler bei der Verantwortung beginnen meist mit einer bequemen Ausnahme Das gefährliche Muster beginnt mit einer nachvollziehbaren Abkürzung. Ein Senior-Entwickler muss eine Migration fertigstellen. Der Dienstverantwortliche befindet sich in einer anderen Zeitzone. Jemand fügt eine allgemeine Genehmigungsgruppe hinzu, vergibt eine wiederverwendbare Zugangsdaten oder lässt eine Sitzung über das Wochenende offen. Die Ausnahme funktioniert und wird dadurch zum inoffiziellen Verfahren. Dann erhält der Agent eine umfassendere Aufgabe. Er kann mehr Ziele erreichen, als die ursprüngliche Anfrage erforderte. Der ursprüngliche Entwickler schläft vielleicht, der Verantwortliche ist inzwischen gewechselt, und die allgemeine Gruppe nimmt an, jemand anderes habe den Prompt geprüft. Jede einzelne Entscheidung schien vertretbar. Zusammen haben sie die Verantwortlichkeit entfernt. Beheben Sie das, indem Sie Ausnahmen strukturiert statt informell gestalten. Eine Ausnahme sollte Dienst, Genehmiger, Grund, Endzeit und Prüfpunkt nennen. Sie sollte einen sichtbaren Datensatz erzeugen. Sie darf die dauerhaften Berechtigungen eines Entwicklers nicht stillschweigend erweitern. Widerstehen Sie der beliebten Empfehlung, das Problem mit einer riesigen Regel-Engine zu lösen. Regeln wirken attraktiv, weil Teams glauben, jedes Repository, jeden Branch, jeden Endpunkt, jedes Zeitfenster und jede Stellenbezeichnung abbilden zu können. In der Praxis kann niemand erklären, warum ein bestimmter Aufruf zugeordnet wurde, und veraltete Regeln werden zu Berechtigungen, die niemand behalten wollte. Beginnen Sie mit einem kleinen Entscheidungsmodell: Tresorzugriff, eine begrenzte Sitzungsentscheidung und eine Bestätigung pro Aufruf für Aktionen, die sie verdienen. Dieses Modell zwingt Teams, den schwierigen Teil in klarer Sprache zu klären: Wer ist gerade für dieses System verantwortlich, und was genau möchte diese Person autorisieren? ## Prüfen Sie das Verantwortungsmodell in einer echten Schicht Die meisten Designfehler lassen sich vor einem ernsthaften Incident durch eine kontrollierte Übung finden. Verwenden Sie ein Nichtproduktionssystem, das einem Dienst mit echter Bereitschaftsrotation ähnelt. Starten Sie eine Agent-Sitzung kurz vor einer geplanten Schichtübergabe, fordern Sie zunächst eine routinemäßige Leseaktion an und danach eine Änderung, die eine einzelne Bestätigung braucht. Beobachten Sie, an welchen Stellen Menschen zögern. Kann die abgehende Person aktive Sitzungen sehen? Weiß die neue Person, welchen Dienst sie nun kontrolliert? Identifiziert die Genehmigungsanfrage Prozess und Ziel? Kann eine der beiden Personen die Sitzung widerrufen? Zeigt der Prüfdatensatz die abgelehnten, genehmigten und ausgeführten Aktionen in der richtigen Reihenfolge? Akzeptieren Sie «Das würden wir im Chat klären» nicht als Antwort. Chat ist für die Koordination nützlich, setzt aber keine Entscheidungsgrenze und bewahrt nicht den vollständigen Aktionsdatensatz. Eine Übergabe, die vom Gedächtnis abhängt, scheitert in der geschäftigsten Nacht. Beginnen Sie damit, den aktuellen Verantwortlichen und die Vertretung für den ersten Produktionsdienst festzulegen, auf den Ihre Agenten zugreifen können. Lassen Sie anschließend einen Agenten eine begrenzte Aktion gegen diesen Dienst anfordern. Wenn Sie die Person, die diesen Aufruf genehmigen sollte, nicht nennen können, ohne erst herumzufragen, hat der Agent die Produktion erreicht, bevor Ihr Verantwortungsmodell dazu bereit war.