# Sudo-Zugriff für KI-Agenten: Jede Rechteerhöhung kontrollieren Einem KI-Agenten sudo zu geben, nur weil er bereits eine Remote-Shell öffnen kann, verwechselt zwei verschiedene Dinge. Remote-Ausführung beantwortet die Frage: «Kann er diesen Rechner erreichen?» Eine Rechteerhöhung beantwortet: «Darf diese Anfrage geschützte Zustände verändern?» Dafür braucht es unterschiedliche Nachweise, Kontrollen und Aufzeichnungen. Ich habe erlebt, wie Teams beides zu einer einzigen Komfortfunktion zusammenlegten: Ein Agent verbindet sich über SSH, führt `sudo` aus und hinterlässt ein Chat-Transkript. Das wirkt ordentlich, bis ein fehlerhafter Befehl den falschen Dienst neu startet, eine Konfigurationsdatei ersetzt oder einer Anweisung folgt, die in einem Repository versteckt war. Dann kann niemand sagen, welcher Prozess die Berechtigung hatte, wer die Aktion genehmigt hat oder warum Root-Zugriff notwendig erschien. **sudo-Zugriff für KI-Agenten** sollte eine eng begrenzte, zuordenbare Ausnahme für eine konkret benannte Aktion bedeuten. Der Agent darf dadurch nicht für den Rest einer Aufgabe über die ständige Macht eines Administrators verfügen. ## Eine Remote-Shell und sudo beantworten unterschiedliche Fragen Eine SSH-Sitzung bestätigt, dass sich ein Client bei einem entfernten Konto authentifiziert hat. Sie beweist nicht, dass jeder in dieser Sitzung eingegebene oder erzeugte Befehl Root-Rechte verdient. Halte das normale Konto leistungsfähig genug für Erkundung, Builds, Tests, das Lesen von Logs und die Vorbereitung von Deployments. Schiebe die kleine Gruppe geschützter Änderungen hinter einen separaten Weg zur Rechteerhöhung. Diese Unterscheidung verschwimmt, weil die Shell die Rechteerhöhung wie ein Syntaxdetail aussehen lässt: ```sh ssh deploy@api-02 'sudo systemctl restart payment-worker' ``` Diese eine Zeile verbirgt mindestens fünf Entscheidungen: Welcher Agent-Prozess hat sie ausgeführt, welchen Host hat er angesprochen, ist der Dienstname korrekt, warum ist ein Neustart nötig und hat eine Person die Konsequenz akzeptiert? SSH kann die Verbindung authentifizieren. `sudo` kann den effektiven Benutzer wechseln. Keines der beiden Werkzeuge erfasst von sich aus den Grund oder bietet einen Entscheidungspunkt, der zu autonomer Arbeit passt. Normale Remote-Befehle sollten normal bleiben. Ein Agent kann `systemctl status` ausführen, ein bereits lesbares Dienst-Log prüfen, eine gerenderte Konfiguration vergleichen oder einen Health-Check ausführen, ohne Root anzufordern. Das hat einen praktischen Vorteil: Der Agent kann Belege sammeln, bevor er jemanden um die Genehmigung einer Änderung bittet. Übertreibe es nicht und stelle jeden Shell-Befehl hinter eine menschliche Bestätigung. Das führt zu Genehmigungsmüdigkeit, und Menschen beginnen, Karten nur noch durchzuklicken. Setze die Reibung dort ein, wo eine Aktion eine geschützte Grenze verändert: Dienstverwaltung, Änderungen an Systempaketen, privilegierte Dateischreibzugriffe, Kontenänderungen, Netzwerkregeln, Geheimnisse, Boot-Einstellungen und Vorgänge mit Produktionsdaten. Das Schreibbild eines Befehls bestimmt nicht sein Risiko. `sudo cat /var/log/...` kann sensible Inhalte offenlegen. `sudo systemctl restart ...` kann einen kundenrelevanten Dienst unterbrechen. Ein scheinbar harmloses `sudo install` kann eine ausführbare Datei ersetzen. Bewerte die Auswirkung, das Ziel und die Frage, ob die Argumente einen Ausbruch in beliebiges Verhalten mit Root-Rechten erlauben. ## Sudoers-Regeln sind Allowlists, keine Sicherheitsbegründung Das `sudoers`-Handbuch sagt, dass sudo anhand des Pfads zum Befehl und, sofern konfiguriert, anhand der Befehlszeilenargumente bestimmt, ob ein Benutzer einen Befehl ausführen darf. Das ist nützliche Technik, macht eine weit gefasste Allowlist aber nicht automatisch zu einer sicheren Delegation. Eine Regel wie diese delegiert deutlich mehr, als viele beabsichtigen: ```sudoers autobot ALL=(root) NOPASSWD: /usr/bin/systemctl * ``` Sie erlaubt dem Konto, jede Unit zu starten, zu stoppen, neu zu starten, zu aktivieren, zu deaktivieren, zu maskieren und zu untersuchen, die das lokale `systemctl` unterstützt. Ein Agent, der eine Unit-Datei, eine Umgebungsdatei oder die ausführbare Datei eines Dienstes beeinflussen kann, kann einen genehmigten Neustart in eine Codeausführung als root verwandeln. Außerdem gibt es in der Regel weder einen Änderungsgrund noch eine Ablaufzeit. Argumentbeschränkungen helfen nur, wenn das erlaubte Programm eine kleine, stabile Schnittstelle hat und keine vom Angreifer kontrollierten Eingaben als Pfad, Shell-Ausdruck, Plugin, Editor, Pager oder Konfigurationsquelle interpretiert. Administratoren übersehen das oft, weil der Befehl vertraut aussieht. Ein Befehl wird nicht allein dadurch eng begrenzt, dass sein Binärpfad absolut angegeben ist. Bevorzuge einen speziell entwickelten Helfer mit einer festen Operation und eindeutiger Validierung. Ein Neustart-Helfer kann beispielsweise einen fest eingebauten Dienstnamen akzeptieren, statt beliebige `systemctl`-Argumente entgegenzunehmen: ```sh #!/bin/sh set -eu case "${1:-}" in payment-worker|report-worker) ;; *) echo "unsupported service" >&2; exit 64 ;; esac exec /usr/bin/systemctl restart "$1" ``` Beschränke sudo anschließend auf diesen Helfer und, sofern die Plattform das unterstützt, auf die exakten Argumente: ```sudoers autobot ALL=(root) /usr/local/sbin/restart-approved-service payment-worker, \ /usr/local/sbin/restart-approved-service report-worker ``` Damit verhinderst du eine unkontrollierte Ausweitung der `systemctl`-Unterbefehle. Ob der Neustart gerade sinnvoll ist, beantwortet das jedoch nicht. Der Helfer braucht außerdem Root-Besitz, nicht beschreibbare übergeordnete Verzeichnisse und Schutz vor vom Agenten kontrollierten Umgebungsvariablen. Wenn ein Agent den Helfer bearbeiten oder etwas ersetzen kann, das der Helfer ausführt, ist die Regel gescheitert. Vermeide die beliebte Empfehlung, für Automatisierung «einfach NOPASSWD zu verwenden». Sie gefällt vielen, weil unbeaufsichtigte Jobs nicht mehr an Passwortabfragen scheitern. Die Passwortabfrage war für einen autonomen Agenten nie die entscheidende Kontrolle. Sie durch uneingeschränkte Rechteerhöhung zu ersetzen, entfernt lediglich die letzte sichtbare Unterbrechung. Ersetze sie durch eine konkrete Genehmigung und eine verantwortbare Aufzeichnung, nicht durch bloße Bequemlichkeit. ## Eine Erhöhungsanfrage braucht einen prüfbaren Grund Ein Grund gehört zur Autorisierungsentscheidung. Er ist kein dekorativer Satz, der nachträglich in ein Ticket kopiert wird. Der Agent sollte die Anfrage vor der Rechteerhöhung erstellen, und die Genehmigungsoberfläche sollte die geplante Aktion zusammen mit diesem Grund anzeigen. Die Anfrage sollte mindestens diese Felder zusammenführen: - Das genaue Ziel, etwa `api-02` und `payment-worker`. - Die angeforderte privilegierte Aktion einschließlich fester Argumente. - Der Grund, verknüpft mit einem Vorfall, Deployment, Wartungsvorgang oder beobachteten Zustand. - Die erwartete Auswirkung und eine Rückfallaktion. - Eine kurze Ablaufzeit, damit eine liegen gebliebene Anfrage nicht zu einer dauerhaften Berechtigung wird. Der Grund muss Belege enthalten, die ein Mensch bewerten kann. «Ich brauche sudo, um den Build zu reparieren» zeigt, dass der Agent noch nicht ausreichend diagnostiziert hat. «Ersetze `/etc/acme/client.conf` durch die geprüfte Release-Konfiguration, nachdem die aktuelle Zertifikatserneuerung einen Parse-Fehler gemeldet hat; stelle die vorherige Version wieder her, wenn die Validierung fehlschlägt» nennt eine Datei, eine Bedingung und einen Wiederherstellungsweg. Halte die Anfrage strukturiert, auch wenn du zusätzlich eine Freitexterklärung speicherst. Strukturierte Felder erschweren es einem Agenten, das Ziel zwischen Planung und Ausführung unbemerkt zu ändern. Außerdem ermöglichen sie eine spätere Prüfung, ohne dass jemand eine Entscheidung aus mehreren Chatfenstern rekonstruieren muss. Verwende eine unveränderliche Anfrage-ID. Die Genehmigung sollte genau diese ID, das angegebene Ziel und die angegebene Aktion autorisieren. Genehmige keine natürlichsprachliche Anweisung wie «Kümmere dich um den Ausfall» und überlasse es dem Agenten, später zu entscheiden, welche Root-Befehle darunterfallen. Das macht aus der menschlichen Genehmigung einen Blankoscheck. Eine sinnvolle Anfrage kann so aussehen: ```json { "request_id": "elev-7f4c2", "agent_session": "run-91b0", "host": "api-02", "operation": "/usr/local/sbin/restart-approved-service payment-worker", "reason": "Deployment 482 left payment-worker unhealthy; status shows repeated configuration parse errors.", "expected_effect": "Service restarts with the reviewed configuration.", "rollback": "Restore the previous configuration revision and restart the service.", "expires_at": "2025-03-08T14:25:00Z" } ``` Die Ausführungsaufzeichnung sollte `request_id` übernehmen. Ohne diese Verknüpfung kann ein Genehmiger eine Aktion akzeptiert haben, während der Agent eine andere ausgeführt hat. ## Der Agent-Prozess braucht eine eigene Identität Ein gemeinsames `deploy`-Konto lässt nach einem Vorfall alle Akteure gleich aussehen. Gib dem Agent-Lauf eine Identität, aus der hervorgeht, welche ausführbare Datei ihn gestartet hat, welcher Mensch oder Dienst ihn initiiert hat, welches Repository und welche Aufgabe er erhalten hat und wann seine Berechtigung endet. Menschliche Identität und Prozessidentität sind getrennte Tatsachen. Ein Entwickler kann einen Agenten starten, aber der Prozess des Agenten führt den Befehl vielleicht erst Stunden später aus, nachdem er Dateien, Tool-Ausgaben und Netzwerkantworten gelesen hat. Die Audit-Spur sollte beide Fakten bewahren. «Jamie hat Lauf 91b0 gestartet» und «der signierte Agent-Prozess 91b0 hat eine Erhöhung angefordert» ermöglichen es einem Ermittler, Initiierung und Ausführung zu unterscheiden. Codesignaturen können dabei helfen, die lokale ausführbare Datei zu identifizieren, die den Zugriff angefordert hat. Sie beweisen nicht, dass die Anweisung des Modells sicher war, und machen ein kompromittiertes Repository nicht vertrauenswürdig. Behandle die Prozessidentität als Begrenzung dafür, wer anfragen darf, nicht als Beweis dafür, dass die Anfrage sinnvoll ist. Gib dem Agenten kein wiederverwendbares Root-Passwort, keinen privaten SSH-Schlüssel, der direkt auf einem Administratorkonto landet, und keinen langlebigen sudo-Zeitstempel, den er unbegrenzt verlängern kann. Jedes davon verwandelt eine begrenzte Anfrage in eine portable Fähigkeit. Sobald der Agent diese Fähigkeit in einen Arbeitsbereich, ein Log, ein Build-Artefakt oder einen Kindprozess kopieren kann, hast du die Kontrolle über ihre Verbreitung verloren. Kurzlebige Zugangsdaten verringern das Risiko, machen einen schlechten Befehl aber nicht gut. Verwende die Ablaufzeit zusammen mit einer definierten Aktion, einem gebundenen Prozess und einem Grund. Fehlt eines davon, hast du nur ein Zugriffstoken mit einer freundlicheren Bezeichnung. ## Eine Root-Shell lässt dem Agenten zu viel Raum, Anweisungen neu zu deuten Genehmige für eine Agent-Sitzung niemals `sudo -i`, `sudo su`, `sudo sh` oder ein uneingeschränktes `sudo bash`. Eine Root-Shell autorisiert jeden späteren Befehl, auch Befehle, die aus Tool-Ausgaben zusammengesetzt wurden und zum Zeitpunkt der ersten Genehmigung noch nicht existierten. Die gleiche Warnung gilt für Befehlsformen, die einen beliebigen Interpreter tarnen: ```sh sudo python3 -c "$AGENT_TEXT" sudo env CONFIG="$AGENT_TEXT" /usr/local/sbin/apply-config sudo tee /etc/some-file.conf ``` Jedes Beispiel wirkt begrenzt, bis du den Eingabekanal untersuchst. Python führt beliebigen Code aus. `env` kann das Verhalten eines Programms auf eine Weise verändern, die der Aufrufer nicht erwartet hat. `tee` gibt Schreibzugriff auf einen beliebigen Pfad unter Root-Besitz, wenn der Pfad nicht begrenzt ist. Eine Befehlsrichtlinie, die Argumente und Umgebung ignoriert, ist nur eine Richtlinie für Dateinamen. Ein besseres Design trennt Diagnose und Ausführung. Der Agent kann nicht privilegierte Fakten untersuchen, eine geplante Änderung erstellen und sie zur Prüfung einreichen. Ein eng begrenzter privilegierter Helfer erhält dann nur die genehmigten Eingaben. Der Helfer muss diese Eingaben erneut validieren, weil Validierung zum Prüfzeitpunkt andere Fehler abwehrt als Validierung zum Ausführungszeitpunkt. Stell dir einen Deployment-Agenten vor, der einen Dienstausfall feststellt. Unter weit gefasstem sudo könnte er ein Unit-Override bearbeiten, den Manager neu laden und den Dienst neu starten. Eine schädliche Zeichenfolge in einer vom Repository kontrollierten Konfiguration kann zu einer `ExecStart`-Zeile werden, die mit Root-Rechten ausgeführt wird. In einem eingeschränkten Design darf der Agent den Status lesen und die geprüfte Konfiguration vorbereiten, aber ein privilegierter Deployment-Helfer akzeptiert nur den Inhalts-Digest eines genehmigten Artefakts. Unit-Dateien, beliebige Pfade und nicht verwaltete Overrides weist er zurück. Das ist mehr Arbeit, als eine Shell zu übergeben. Es ist aber auch der Unterschied zwischen einer bekannten Aktion und einem Interpreter, der nach der Genehmigung neue Aktionen erfinden kann. ## Die Genehmigung muss dem Risiko der Aktion folgen Eine Genehmigung pro Sitzung kann für routinemäßige, begrenzte Remote-Aktionen sinnvoll sein. Für jede Nutzung einer Administratorberechtigung ist sie nicht geeignet. Behandle Sitzungsautorisierung und Autorisierung pro Aufruf als getrennte Kontrollen. Die Sitzungsautorisierung beantwortet: «Darf dieser identifizierte Agent-Prozess für die Dauer dieses Laufs gewöhnliche Remote-Kanäle verwenden?» Sie verhindert, dass ein unbekannter lokaler Prozess einen bekannten Agenten unbemerkt imitiert. Sie sollte enden, wenn der Prozess beendet wird, und ein Operator sollte sie sofort widerrufen können. Die Autorisierung pro Aufruf beantwortet: «Darf diese konkrete Aktion jetzt ausgeführt werden?» Setze sie für Vorgänge mit großer Reichweite, knappen Zugangsdaten, Auswirkungen auf die Produktion oder irreversiblen Folgen ein. Die Genehmigungskarte sollte zuerst die Prozessidentität zeigen und anschließend Ziel, Aktion, Grund, Ablaufzeit und erwartete Auswirkung. Wer die Identität unter einem langen Erklärungstext versteckt, verfehlt den Zweck. Zwinge den Operator nicht, hundert Zeilen erzeugter Shell-Befehle zu lesen. Gib dem Agenten ein Vokabular benannter Aktionen mit aufbereiteten Details. «Payment-Worker auf api-02 neu starten» lässt sich prüfen. Ein Shell-Block mit verschachtelten Anführungszeichen verleitet Menschen dazu, etwas abzunicken, das sie nicht verstehen. Der Genehmigungsweg braucht außerdem einen Ablehnungsweg, der dem Agenten bei der Erholung hilft. Gib eine klare Ablehnung zurück und, wo sinnvoll, eine Anweisung wie «erfordert einen Deployment-Änderungsdatensatz» oder «diese Aktion ist in der Produktion nicht verfügbar». Lass den Agenten nicht mit geringfügig veränderten Formulierungen erneut fragen, bis jemand müde zustimmt. Eine Ablehnung sollte die Anfrage schließen, solange nicht ein Mensch eine neue Anfrage mit wesentlich anderen Informationen erstellt. Auch im Notfall sollte die gleiche Disziplin gelten. Ein Bereitschaftstechniker kann eine eng begrenzte Anfrage mit kurzer Ablaufzeit und Vorfallsreferenz genehmigen. Die Dringlichkeit kann eine schnellere Prüfung rechtfertigen, nicht aber das Löschen der Aufzeichnung oder die Vergabe einer interaktiven Root-Shell. ## Audit-Aufzeichnungen müssen den Agenten überdauern, der die Anfrage erstellt hat Ein Terminal-Transkript hilft bei der Fehlersuche, kann aber die Anforderungen an eine Audit-Aufzeichnung nicht erfüllen. Der Agent kann es auslassen, lokale Dateien verändern oder Befehle über einen Weg ausführen, den das Transkript nicht erfasst hat. Erfasse Autorisierung und Ausführung in einem Speicher, den der Agent nicht überschreiben kann. Zeichne die Entscheidung getrennt von der Aktion auf. Eine Genehmigungsaufzeichnung sollte zeigen, wer wann genehmigt hat, die Prozessidentität, den genauen Inhalt der Anfrage und die Ablaufzeit. Eine Ausführungsaufzeichnung sollte zeigen, ob der Helfer ausgeführt wurde, welchen Host er erreicht hat, was er zurückgegeben hat, wann er beendet wurde und welche Anfrage-ID ihn autorisiert hat. Füge statt einer unbeschränkten Ablage sensibler Befehlsausgaben einen Ergebnis-Digest oder eine begrenzte Zusammenfassung hinzu. Die untersuchende Person muss erkennen können, dass `payment-worker` neu gestartet wurde und wieder fehlerfrei lief. Sie braucht kein kopiertes Datenbankpasswort, das zufällig in stderr auftauchte. Manipulationsnachweise sind wichtig, weil Audit-Logs nach einem Vorfall besonders interessant werden. Eine Hash-Kette verknüpft jeden Datensatz mit dem vorherigen. Wird ein Eintrag verändert oder entfernt, erkennt die Prüfung die Unterbrechung. Halte die Prüfung unabhängig vom Agenten und möglichst auch unabhängig von den Zugangsdaten, die zur Ausführung der Aktionen verwendet wurden. Ein Log, dessen Prüfung die kompromittierten Administratorzugangsdaten braucht, ist gerade dann weniger nützlich, wenn du es am dringendsten benötigst. Ein Offline-Prüfer sollte beispielsweise eine Sequenz wie diese melden: ```text $ sp audit verify --file agent-audit.enc verified records: 184 chain start: 8c1a...e72d chain end: 4bf0...193a status: valid ``` Entscheidend ist nicht der Befehlsname. Entscheidend ist, dass der Prüfer einen veränderten verschlüsselten Datensatz erkennen kann, ohne den Agenten um eine Erklärung zu bitten. Bewahre Kopien außerhalb des Rechners auf, auf dem der Agent arbeitet, denn ein Angreifer mit Kontrolle über diesen Rechner kann das gesamte Journal löschen. Sallyport folgt dieser Trennung, indem Zugangsdaten vom Agenten ferngehalten und Sitzungs- sowie Einzelaktionsjournale aus einem schreibgeschützten, verschlüsselten und hashverketteten Audit-Log erstellt werden. Dieses Modell ist hilfreich, wenn Agenten HTTP- oder SSH-Aktionen benötigen, aber niemals die Zugangsdaten besitzen sollen, die sie autorisieren. ## Privilegierte Helfer brauchen enge Schnittstellen und Tests mit feindlichen Eingaben Ein Helfer ist sicherheitskritischer Code, auch wenn er nur zwanzig Zeilen umfasst. Teste ihn so, als stammten jedes Argument, jede Umgebungsvariable, das Arbeitsverzeichnis und jede referenzierte Datei von einem Angreifer. Ein KI-Agent kann dazu gebracht werden, schädliche Inhalte zu übergeben, ohne dies beabsichtigt zu haben. Beginne mit einem Verzeichnis der Aktionen. Schreibe für jeden privilegierten Effekt auf, den der Agent tatsächlich benötigt, etwa den Neustart eines bestimmten Dienstes oder die Installation eines signierten Release-Artefakts. Wenn sich ein Effekt nicht beschreiben lässt, ohne «beliebigen Befehl ausführen» zu sagen, wurde die Aktion noch nicht entworfen. Beantworte für jeden Helfer diese Fragen, bevor du ihn in sudoers einträgst: 1. Welche exakten Eingaben kann der Aufrufer liefern, und wie validiert der Helfer jede einzelne? 2. Welche Dateisystempfade, ausführbaren Dateien, Konfigurationsdateien und Umgebungsvariablen beeinflussen sein Verhalten? 3. Kann eine akzeptierte Eingabe eine Shell, einen Interpreter, Pager, Editor, Plugin-Loader oder Netzwerkabruf auslösen? 4. Prüft der Helfer Besitz, Berechtigungen und Inhaltsidentität, bevor er handelt? 5. Welche Aufzeichnung erzeugt er sowohl bei fehlgeschlagener Validierung als auch bei erfolgreicher Ausführung? Führe Negativtests durch, nicht nur den Erfolgsfall. Übergib `../`-Pfade, Shell-Metazeichen, einen leeren Dienstnamen, übergroße Eingaben, unerwartetes Unicode und einen gültigen Namen, der auf einen unsicheren Zustand verweist. Versuche, eine referenzierte Datei zwischen Prüfung und Verwendung zu ersetzen. Prüfe, ob ein beschreibbares Log-, temporäres oder übergeordnetes Verzeichnis dem Agenten ermöglicht, Root-Ausgaben umzuleiten. Untersuche Abhängigkeiten auch nach Updates. Ein Helfer, der gegen eine Version eines Befehls sicher war, kann unsicher werden, wenn eine neue Option einen Konfigurationspfad akzeptiert oder eine Erweiterung lädt. Enge Schnittstellen verringern diesen Wartungsaufwand, beseitigen ihn aber nicht. ## Rechteerhöhungen als kontrollierte Ausnahme einführen Beginne damit, die gefährlichsten Formen dauerhafter Berechtigungen zu entfernen: gemeinsame Administratorkonten, uneingeschränktes `NOPASSWD`, wiederverwendbare Root-Geheimnisse in der Agent-Konfiguration und Root-Shells. Du musst nicht jede Automatisierung stoppen, bevor du diese Änderung vornimmst. Bewahre zunächst die schreibgeschützte Diagnose und überführe dann eine geschützte Aktion nach der anderen in einen ausdrücklichen Helfer- und Genehmigungsweg. Wähle eine Aktion, die häufig genug vorkommt, um den Prozess zu testen, aber einen begrenzten Rückweg hat, etwa den Neustart eines benannten Workers nach einem geprüften Deployment. Verlange vom Agenten Host, Grund, Auswirkung, Rückweg und Ablaufzeit. Weise vage Anfragen zurück. Diese Reibung bringt dem Agenten-Workflow bei, welche Belege er sammeln muss, bevor er um mehr Macht bittet. Prüfe abgelehnte Anfragen genauso ernsthaft wie erfolgreiche. Eine Häufung von Anfragen für beliebige Dateischreibzugriffe kann zeigen, dass der Deployment-Mechanismus eine benötigte Aktion nicht anbietet. Sie kann auch zeigen, dass der Agent wiederholt versucht, eine Grenze zu umgehen. Das sind unterschiedliche Probleme, und eine Audit-Spur hilft, sie auseinanderzuhalten. Übe anschließend den Widerruf. Beende eine Sitzung, während der Agent arbeitet, lehne eine bereits ausgestellte Anfrage nach ihrem Ablauf ab und prüfe, dass eine kopierte Anfrage-ID keine zweite Aktion autorisieren kann. Teams testen häufig Genehmigungsoberflächen und überspringen diesen Teil. Der Widerruf ist die Kontrolle, die du brauchst, wenn der Agent sich in der Mitte eines Laufs anders zu verhalten beginnt. Miss Reife nicht daran, wie viele Befehle ein Agent als root ausführen kann. Miss sie daran, ob jede Rechteerhöhung eng begrenzt, zuordenbar, zeitlich beschränkt, prüfbar und rückholbar bleibt, wenn der Agent oder seine Eingaben fehlschlagen.