# Vorübergehender Produktionszugriff: Berechtigungen, die mit dem Task enden Der Produktionszugriff eines Coding-Agenten sollte enden, weil das Autorisierungssystem sein Ende festlegt, nicht weil jemand später zurückkommen wollte. Ein Zweck, eine Frist und eine abschließende Prüfung machen aus einer riskanten Ausnahme eine begrenzte Berechtigung, die ein anderer Engineer nachvollziehen kann. Ich habe Zugriffskontrollen auf die langweilige Art scheitern sehen: Der Vorfall ist gelöst, der Task abgeschlossen, aber das Zugangsmittel bleibt verwendbar. An diesem Tag passiert nichts Dramatisches. Monate später taucht dasselbe Zugangsmittel in einem unabhängigen Skript auf, ein alter Agent-Prozess läuft weiter oder jemand verwendet es, weil es praktisch ist. Die ursprüngliche Ausnahme ist durch Nachlässigkeit zu dauerhaftem Produktionszugriff geworden. Vorübergehender Produktionszugriff braucht drei Fakten, die der Durchsetzungspunkt auswerten kann: warum der Agent handeln darf, worauf er zugreifen darf und wann er aufhören muss. Der letzte Punkt ist genauso wichtig wie die ersten beiden. Wenn Sie keine Ablehnung nachweisen können, nachdem der Task abgeschlossen ist, ist der Task noch nicht beendet. ## Eine Frist muss Anfragen ablehnen, nicht nur ein Ticket schmücken Eine angegebene Endzeit hat nur dann Wirkung, wenn die Komponente, die eine Aktion ausführt oder autorisiert, sie bei jeder Anfrage prüft. Ein Projekt-Tracker, ein Kalendereintrag oder eine Erinnerung im Chat kann einen alten Prozess nicht daran hindern, um 02:00 Uhr eine API aufzurufen. Diese Unterscheidung überrascht Teams, weil ihr Änderungsprozess diszipliniert aussieht. Sie verlangen ein Ticket, eine prüfende Person und einen Abschlussstatus. Dann geben sie einem Agenten ein Zugangsmittel, das gültig bleibt, bis jemand es manuell austauscht. Der Workflow hält die Absicht fest, während das Zugangsmittel seine Berechtigung behält. Legen Sie den Ablaufzeitpunkt dorthin, wo die Anfrage in die Produktion gelangt. Je nach Aufbau kann das ein Identity Provider sein, der ein kurzlebiges Token ausstellt, ein Access Gateway, das eine Grant-Datenbank prüft, ein SSH-Zertifikatsprüfer oder ein Broker, der das Zugangsmittel verwahrt und die Aktion ausführt. Der geschützte Dienst muss eine Anfrage erhalten, die er nach Ablauf der Frist ablehnen kann. NIST SP 800-207 weist in seiner Beschreibung einer Zero-Trust-Architektur auf einen wichtigen Punkt hin: Zugriffsentscheidungen sollten geprüft werden, bevor eine Sitzung zu einer Unternehmensressource aufgebaut wird, und der Zugriff sollte pro Sitzung gewährt werden. Das bedeutet nicht, dass jede Anwendung ein vollständiges Zero-Trust-Produkt nachbauen muss. Es bedeutet, dass ein einmal gewährter Zugriff für eine Sitzung nicht dauerhaft angemessen bleibt. Bei Agenten sollten Sie mindestens zu Beginn jeder Aktion prüfen. Für lang laufende Arbeiten brauchen Sie eine zusätzliche Entscheidung: Entweder darf die bereits gestartete Operation unter einer begrenzten Lease zu Ende laufen, oder sie wird beim Ablauf der Lease abgebrochen. Legen Sie dieses Verhalten vor einem Ausfall fest. Ein ungeplanter Abbruch während einer Datenbankreparatur kann genauso schädlich sein wie uneingeschränkter Zugriff. Eine Frist sollte einen Zeitstempel in einer einheitlichen Zeitbasis verwenden, normalerweise UTC. Schreiben Sie nicht «bis zum Ende des Tages» und hoffen Sie, dass jedes System denselben Tag meint. Speichern Sie `2025-04-18T16:30:00Z`, zeigen Sie der genehmigenden Person die lokale Zeit und lassen Sie den Anfragepfad den gespeicherten Zeitstempel vergleichen. ## Der Zweck muss die Berechtigung begrenzen Ein Zweck ist nur dann nützlich, wenn er einschränkt, was der Agent tun darf. «Bei der Produktion helfen» und «den Alarm untersuchen» beschreiben eine Stimmung, aber keine Autorisierungsgrenze. Formulieren Sie den Zweck so, dass ein Engineer, der die Berechtigung nicht genehmigt hat, entscheiden kann, ob eine Anfrage dazugehört. Eine brauchbare Formulierung nennt den auslösenden Arbeitspunkt, das Ziel, die erlaubte Aktion und die erwartete Abschlussbedingung. Zum Beispiel: > Erhöhte Checkout-Fehler im Vorfall INC-482 untersuchen. Logs und Deployment-Status des Checkout-Service lesen. Den Checkout-Worker nur neu starten, wenn der Incident Commander den Neustart genehmigt. Zugriff beenden, sobald INC-482 gelöst ist oder um 16:30 UTC, je nachdem, was zuerst eintritt. Diese Aussage schafft klare Entscheidungen. Das Lesen einer Abrechnungsdatenbank gehört nicht dazu. Ein unabhängiges Anwendung-Deployment gehört nicht dazu. Für den Neustart des Workers gibt es eine benannte Genehmigungsbedingung. Der Agent kann weiterhin nützlich sein, ohne einen Blankoscheck zu erhalten. Der Umfang braucht mehr als die Bezeichnung «Produktion». Binden Sie die Berechtigung an konkrete Ziele: - benannte API-Hosts, Repositories oder SSH-Hosts - benannte Methoden oder Befehle, etwa `GET /health` oder eine Abfrage des Deployment-Status - benannte Umgebungen und Konto-IDs - eine maximale Anzahl von Aktionen oder eine maximale Anfragerate, wenn wiederholte Aufrufe bei der Aufgabe wahrscheinlich sind - eine verantwortliche Person, die die Arbeit stoppen kann Vermeiden Sie die verbreitete Empfehlung, einem Agenten weitreichenden Lesezugriff zu geben, weil «read-only sicher ist». Lesezugriff kann Kundendaten, Konfigurationen, Topologie, Deployment-Historie oder in alten Logs enthaltene Zugangsdaten offenlegen. Außerdem kann ein Agent viel mehr Kontext sammeln, als der Zweck erfordert. Geben Sie ihm nur die benötigten Observability-Endpunkte und den erforderlichen Bereich der Log-Abfragen. Es gibt noch eine Grenze, die Teams oft verwischen: Ein Task-Zweck ist nicht dasselbe wie ein Prompt. Der Prompt sagt dem Agenten, was er versuchen soll. Der Autorisierungszweck sagt dem Durchsetzungspunkt, was er erlauben darf, selbst wenn sich der Prompt ändert, das Modell eine falsche Schlussfolgerung zieht oder eine Tool-Ausgabe feindselige Anweisungen enthält. Behandeln Sie Prompts als nicht vertrauenswürdige Eingaben für die Zugriffsentscheidung. ## Zugangsmittel und Berechtigungen laufen unterschiedlich ab Ein Zugangsmittel beweist, dass ein Aufrufer etwas besitzt. Die Autorisierung entscheidet, ob dieser Aufrufer diese Anfrage jetzt ausführen darf. Beide Teile müssen enden, wenn die Arbeit endet. Ein Bearer-Token mit einem `exp`-Anspruch kann eine gute zeitliche Begrenzung sein, wenn die empfangende API Signatur, Audience und Ablauf bei jeder Anfrage prüft. Es ist keine universelle Lösung. Manche Dienste zwischenspeichern die Authentifizierung, akzeptieren undurchsichtige Tokens, die an anderer Stelle geprüft werden, oder autorisieren ein Token anhand eines serverseitigen Zustands, der aktiv bleibt. Ein Token, das in 15 Minuten abläuft, verfehlt außerdem die Task-Grenze, wenn der Task nach vier Minuten beendet war. Dasselbe Problem gibt es bei SSH. OpenSSH unterstützt signierte Benutzerzertifikate mit einem Gültigkeitsintervall. Das Handbuch von `ssh-keygen` dokumentiert `-V` als Option für dieses Intervall. Ein kurzlebiges Zertifikat ist deutlich besser, als einen langlebigen privaten Schlüssel in einem Agent-Arbeitsbereich abzulegen. Der Ablauf beantwortet aber nur die Zeitfrage. Sie müssen weiterhin Principals, Zielhosts und das Befehlsverhalten einschränken. Dieser Befehl zeigt ein Zertifikat, das 20 Minuten gültig ist: ```sh ssh-keygen -s ./user_ca -I agent-run-7f3a \\ -n deploy-readonly -V +20m ./agent-run-7f3a.pub ``` Die Ausgabe nennt normalerweise die Datei mit dem signierten öffentlichen Schlüssel, zum Beispiel: ```text Signed user key ./agent-run-7f3a-cert.pub: id "agent-run-7f3a" serial 0 for deploy-readonly valid from 2025-04-18T16:00:00 to 2025-04-18T16:21:00 ``` Verwechseln Sie dieses Zertifikat nicht mit einer vollständigen Task-Berechtigung. Wenn das entfernte Konto beliebige Befehle ausführen kann, autorisiert das Zertifikat bis 16:21 weiterhin beliebige Befehle. Verwenden Sie bei Bedarf ein eingeschränktes Konto, einen erzwungenen Befehl oder eine Allowlist für Befehle auf dem Host. Widerruf und Ablauf sind ebenfalls verschieden. Der Ablauf ist vorhersehbar und funktioniert auch dann, wenn ein zentraler Widerrufsdienst nicht verfügbar ist. Der Widerruf beendet die Berechtigung vorzeitig, wenn der Vorfall gelöst ist, der Agent sich unerwartet verhält oder eine genehmigende Person ihre Zustimmung zurückzieht. Ein gutes Design unterstützt beides: eine kurze maximale Lebensdauer plus sofortigen Widerruf. ## Der Abschluss eines Tasks braucht ein maschinenlesbares Ereignis Der Abschluss eines Tasks muss ein Ereignis erzeugen, das eine Zugriffskomponente verarbeiten kann. Wenn eine Person nur den Ticketstatus ändert, ohne dass ein verbundener Widerrufspfad existiert, entsteht ein falsches Gefühl von Vollständigkeit. Verwenden Sie zwei Beendigungsbedingungen. Die erste ist eine harte Endzeit, die beim Erstellen der Berechtigung festgelegt wird. Die zweite ist ein früheres Abschlusssignal aus dem Arbeitssystem oder von der verantwortlichen Person. Das tatsächliche Ende ist der frühere dieser beiden Zeitpunkte. Ein wieder geöffnetes Ticket stellt die alte Berechtigung nicht stillschweigend wieder her. Dafür braucht es eine neue Genehmigung und eine neue Endzeit. Das schützt vor einem bekannten Fehler. Ein Agent erhält Zugriff für einen Vorfall. Er meldet, dass er das Problem behoben hat, woraufhin die zuständige Person den Vorfall schließt. Ein zweiter Agent-Prozess besitzt jedoch weiterhin eine authentifizierte Verbindung und sammelt weiter Diagnosedaten. Später öffnet das Team den Vorfall erneut, bemerkt aber nicht, dass der alte Prozess nie beendet wurde. Die Zugriffsentscheidung war an eine Erzählung im Ticket gebunden, nicht an den Lebenszyklus des tatsächlichen Prozesses. Binden Sie die Autorisierung neben der Task-ID auch an eine unveränderliche Run-ID. Ein Task kann über mehrere Tage mehrere Runs haben. Jeder Run braucht seinen eigenen Start, sein eigenes Ende und eine verantwortliche Person. Wenn der Run endet, widerrufen Sie die Berechtigung. Wenn der Task geschlossen wird, widerrufen Sie jeden noch aktiven Run, der daran hängt. Das Abschlusssignal braucht einen idempotenten Empfänger. Systeme wiederholen Webhooks, und Personen drücken Schaltflächen zweimal. Eine Widerrufsanfrage sollte wiederholte Zustellungen akzeptieren und den ersten wirksamen Zeitpunkt beibehalten, statt ein Duplikat als Fehler zu behandeln, den jemand ignoriert. Protokollieren Sie die Quelle des Abschlusses. Eine Statusänderung aus einem Ticketsystem, ein manueller Stopp durch den Incident Commander, das Ende eines Prozesses und ein harter Ablauf bedeuten während einer Untersuchung unterschiedliche Dinge. Für den Zugriff ist das Ergebnis gleich, aber das Audit-Protokoll sollte festhalten, warum er endete. Gewähren Sie keine automatische Verlängerung, nur weil ein Agent kurz vor dem Ablauf weitere Tool-Aufrufe erzeugt. Dieses Muster belohnt einen beschäftigten Prozess mit mehr Berechtigung. Eine Person muss eine neue Entscheidung treffen, gegebenenfalls mit einem geänderten Zweck, wenn sich die Arbeit verändert hat. ## Ein Berechtigungsdatensatz verhindert unklare Genehmigungen Ein strukturierter Berechtigungsdatensatz macht aus einer Genehmigung etwas, das das System durchsetzen und ein Engineer prüfen kann. Er zeigt außerdem fehlende Entscheidungen, bevor der Agent die Produktion berührt. Das folgende Beispiel ist bewusst schlicht. Es ist ein Datenformat, keine Policy-Sprache. Die Felder verhindern, dass ein Agent-Run eine vage, wiederverwendbare Berechtigung übernimmt. ```yaml grant_id: grant_01JQ7P8V6R agent_run_id: run_7f3a2c purpose: "INC-482: inspect checkout worker failures" owner: "on-call engineer" created_at: "2025-04-18T16:00:00Z" ends_at: "2025-04-18T16:30:00Z" ends_on_task_close: "INC-482" targets: - "https://ops.example.internal/checkout/status" - "ssh://checkout-worker-03.internal" allowed_actions: - "GET /checkout/status" - "journalctl -u checkout-worker --since 20m" closure_required: true verification_action: "GET /checkout/status" ``` Der Datensatz sagt nicht «Produktionszugriff: ja». Dieses Feld würde die wichtigen Entscheidungen verbergen. Stattdessen zeigt er, wer die Entscheidung verantwortet, welcher Run sie erhält und welche Anfrage Sie verwenden werden, um nachzuweisen, dass die Berechtigung verschwunden ist. Der Umfang sollte verständlich genug sein, damit eine genehmigende Person ihn ablehnen kann. Eine riesige Liste von Wildcard-Pfaden führt dazu, dass Menschen Zugriff abnicken, weil sie ihn unter Zeitdruck nicht verstehen. Wenn der Agent zwanzig unabhängige Ziele braucht, teilen Sie die Arbeit in mehrere Berechtigungen auf oder räumen Sie ein, dass der Zweck zu weit gefasst ist. Legen Sie kein Geheimnis in diesen Datensatz. Eine Berechtigungs-ID und eine Zielbeschreibung reichen aus. Der Executor kann ein geschütztes Zugangsmittel auflösen, nachdem er die Berechtigung geprüft hat. So können Sie außerdem nützliche Audit-Daten aufbewahren, ohne Material zu speichern, mit dem sich der Produktionszugriff wiederherstellen lässt. Der Datensatz sollte einen Neustart überstehen und aus Sicht der Person, die den Agenten ausführt, nur angehängt werden können. Wenn der Agent `ends_at` ändern, seine Ziele anpassen oder ein Abschlusssignal löschen kann, haben Sie die Sicherheitsentscheidung an den Prozess delegiert, den Sie eigentlich begrenzen wollten. Treffen Sie ausdrückliche Entscheidungen für bereits laufende Vorgänge. Eine Log-Abfrage kann nach dem Ablauf ohne großes Risiko fertig werden. Ein Deployment, eine Migration oder ein Neustart braucht möglicherweise eine Abbruchregel, eine Transaktionsgrenze oder ein Verfahren zur Übernahme durch einen Menschen. Die schlechteste Option ist, dieses Verhalten undefiniert zu lassen und es erst während der Wiederherstellung herauszufinden. ## Beweisen Sie den Ablauf mit einer negativen Anfrage Sie weisen das Ende des Zugriffs nach, indem Sie über denselben Weg, den der Agent verwendet hat, eine Anfrage senden, die jetzt fehlschlagen sollte. Ein geschlossenes Ticket, ein abgelaufener Ausweis in einer Admin-Konsole und eine widerrufene Datenbankzeile sind unterstützende Hinweise. Der Beweis sind sie nicht. Planen Sie die Prüfung unmittelbar nach dem früheren Zeitpunkt von Task-Abschluss und Ablauf. Verwenden Sie einen harmlosen Endpunkt, der die Berechtigung weiterhin benötigt, etwa eine Anfrage zum Servicestatus. Testen Sie nicht mit einem öffentlichen Health-Check, weil ein öffentlicher Endpunkt unabhängig vom Zugriff immer erfolgreich sein kann. Eine einfache Testsequenz sieht so aus: ```sh # Dieser Aufruf war erfolgreich, solange die Berechtigung aktiv war. agent-action --grant grant_01JQ7P8V6R \\ GET https://ops.example.internal/checkout/status # Wiederholen Sie nach dem Task-Abschluss exakt die geschützte Aktion. agent-action --grant grant_01JQ7P8V6R \\ GET https://ops.example.internal/checkout/status ``` Der zweite Befehl sollte eine Ausgabe wie diese erzeugen: ```text request_id=req_92a1 status=403 reason=grant_ended ended_at=2025-04-18T16:12:09Z ``` Ihre Implementierung kann `401`, `403` oder eine Verbindungsverweigerung zurückgeben. Legen Sie eine Bedeutung fest und dokumentieren Sie sie. Der Audit-Eintrag muss zeigen, dass die Zugriffsschicht die Anfrage wegen des beendeten Grants abgelehnt hat, nicht weil DNS fehlgeschlagen ist oder das Ziel gerade nicht verfügbar war. Testen Sie die Pfade, die Menschen gern vergessen. Wenn ein Agent HTTPS und SSH verwenden kann, prüfen Sie beides. Wenn der Dienst nach einem API-Austausch ein Cookie ausstellt, stellen Sie sicher, dass dieses Cookie nicht länger als die Berechtigung gilt. Wenn ein Worker Aktionen lokal in eine Warteschlange stellt, muss der Executor die Autorisierung beim Absenden der Aktion prüfen, nicht nur beim Annehmen des Jobs. Führen Sie einen geplanten Ablauf-Test in einer Nicht-Produktionsumgebung aus, bevor Sie sich in der Produktion auf das Design verlassen. Erstellen Sie eine Berechtigung mit sehr kurzer Lebensdauer, führen Sie eine erlaubte Anfrage aus, warten Sie auf den Ablauf und wiederholen Sie dieselbe Anfrage. Widerrufen Sie anschließend eine zweite aktive Berechtigung vorzeitig und wiederholen Sie die Anfrage. Diese beiden Prüfungen finden unterschiedliche Fehler: falsche Uhrbehandlung und einen defekten vorzeitigen Widerruf. Die Uhrensynchronisation verdient Aufmerksamkeit. Die Komponente, die die Frist prüft, sollte eine vertrauenswürdige Systemuhr verwenden und den Prüfzeitpunkt protokollieren. Wenn ein Laptop seine Uhr zurückstellen und damit den Zugriff verlängern kann, ist die Frist nicht durchsetzbar. Ein zentraler Broker verringert dieses Risiko, weil eine ständig laufende Komponente die Entscheidung trifft. Die Zeitquelle müssen Sie trotzdem überwachen. ## Agent-Prozesse brauchen ihre eigene Grenze Ein Task kann sich über Wiederholungen, Terminals und Modellrunden erstrecken. Ein Agent-Prozess bleibt dennoch eine praktische Einheit für die Zugriffskontrolle. Eine Berechtigung pro Run schafft einen klaren Punkt für Genehmigung, Beobachtung und sofortigen Widerruf. Verwechseln Sie eine Unterhaltung nicht mit einem Prozess. Eine Person kann einem Agenten nach einem Modellneustart oder nachdem ein Tool einen Kindprozess gestartet hat sagen: «Untersuche weiter.» Wenn der Zugriff der Unterhaltung ohne ein neues Autorisierungsereignis folgt, verliert die zuständige Person den Überblick darüber, welches ausführbare Programm die Berechtigung besitzt. Protokollieren Sie die Prozessidentität, die den Run gestartet hat. Unter macOS liefert die Codesignatur-Autorität einer genehmigenden Person nützlichere Informationen als ein vom Benutzer angegebener Prozessname. Ein Prozess namens `agent` sagt fast nichts aus. Eine gespeicherte Signaturidentität, ein Pfad zur ausführbaren Datei, der Elternprozess und die Startzeit ermöglichen eine spätere Prüfung. Sallyport verwendet standardmäßig eine Sitzungsfreigabe für einen neuen Agent-Prozess. Die Genehmigungskarte stellt dabei die Codesignatur-Autorität des Prozesses an den Anfang. Das ist eine sinnvolle Prozessgrenze. Die Sitzungsfreigabe sollte trotzdem Teil einer Task-Berechtigung mit Endzeit bleiben. Widerrufen Sie den Zugriff bei einem normalen Prozessende, aber verlassen Sie sich nie allein darauf. Prozesse stürzen ab, Rechner gehen in den Ruhezustand und Eltern-Kind-Beziehungen werden unübersichtlich. Die harte Frist und das Task-Abschlussereignis bleiben die Rückfallebenen. Wenn der Prozess nach dem Abschluss eines Tasks weiterläuft, muss der Anfragepfad ihn schon ablehnen, bevor das Betriebssystem ihn bereinigt. Trennen Sie den Terminalzugriff einer menschlichen Bedienperson vom Zugriff des Agenten. Es ist verlockend, den Agenten die authentifizierte Shell der Bedienperson erben zu lassen, weil das die Einrichtung vereinfacht. Dadurch wird aber die Zuordnung unbrauchbar, und der Agent kann sämtliche Berechtigungen erhalten, die die Person an diesem Tag gesammelt hat. Geben Sie dem Agenten eine eigene Identität und lassen Sie ihn seinen eigenen Zugriffspfad verwenden. ## Genehmigungsabfragen ersetzen keine Begrenzung Eine Person, die auf «Genehmigen» klickt, kann eine offensichtlich falsche Anfrage erkennen. Genehmigungen werden jedoch schwach, wenn sie zu häufig erscheinen oder zu wenig beschreiben. Eine Abfrage mit dem Text «API-Aufruf erlauben» zwingt die Person, die Folgen zu erraten. Zeigen Sie der genehmigenden Person Zweck, Ziel, Methode oder Befehl, Endzeit der Berechtigung und Agent-Identität. Wenn das System die Anfrage nicht in diesen Begriffen erklären kann, hat es nicht genug Informationen gesammelt, um verantwortungsvoll um eine Genehmigung zu bitten. Eine Genehmigung pro Aufruf ist für Aktionen mit irreversiblen Folgen sinnvoll, etwa beim Löschen von Daten, Rotieren eines Zugangsmittels, Auslösen eines Zahlungslaufs oder Deployment einer ungeprüften Änderung. Sie sollte nicht zur normalen Kontrolle für jedes Lesen eines Logs werden. Menschen genehmigen wiederholte Abfragen reflexartig, besonders während eines Vorfalls. Bei einem Aufruf mit gesetztem Per-Call-Genehmigungs-Flag fragt Sallyport bei jeder Verwendung nach einer Genehmigung. Diese Einstellung sollte eine Endzeit ergänzen, nicht ersetzen. Eine Person kann um 16:29 einen gültigen Aufruf genehmigen. Der Zugriffspfad muss spätere Aufrufe nach dem Ende der Berechtigung trotzdem ablehnen. Halten Sie einen schnellen Not-Aus bereit, der nicht voraussetzt, dass die ursprüngliche genehmigende Person gefunden wird. Der Bereitschaftsdienst braucht eine Möglichkeit, einen Run zu beenden, wenn der Agent in einer Schleife läuft, eine Ausgabe falsch interpretiert oder das falsche Ziel berührt. Protokollieren Sie, wer den Stopp verwendet hat und warum. Eine Notfallkontrolle ohne Verantwortlichkeit kann zu einem weiteren ungeprüften Zugriffspfad werden. ## Ein Audit-Protokoll muss die unangenehmen Fragen beantworten Nach einem Produktionsereignis fragen Menschen, wann der Zugriff begann, wer ihn erlaubt hat, welcher Prozess ihn verwendet hat, welche Anfragen erfolgreich waren und ob er wirklich beendet wurde. Logs, die nur Erfolge aufzeichnen, können die letzte Frage nicht beantworten. Protokollieren Sie auch abgelehnte Aufrufe, besonders Ablehnungen nach Ablauf oder Widerruf. Eine Ablehnung beweist, dass der Durchsetzungspunkt eine Anfrage erhalten und die Grenze angewendet hat. Sie kann einen festhängenden Agenten sichtbar machen, der nach dem Task-Abschluss weiter versucht, Aktionen auszuführen. Das verdient Aufmerksamkeit, obwohl die Kontrolle funktioniert hat. Verbinden Sie die Grant-Entscheidung und einzelne Aktionen über IDs. Eine prüfende Person sollte von `grant_01JQ7P8V6R` zur genehmigenden Person, zum zugehörigen Task, zur Run-Identität, zum erlaubten Umfang, zur Quelle des Abschlusses und zu jeder Anfrage gelangen können. Wenn diese Daten in unabhängigen Systemen ohne gemeinsame ID liegen, wird die Rekonstruktion zum Rätselraten. Manipulationsnachweise sind wichtig, weil Zugriffsaufzeichnungen oft erst dann relevant werden, wenn jemand einen Anreiz hat, sie zu verändern. Sallyport erstellt seine Sitzungs- und Aktivitätsjournale aus einem verschlüsselten Audit-Log mit Hash-Verkettung. Mit `sp audit verify` lässt sich diese Kette offline über dem Chiffretext prüfen. Das entscheidet nicht, ob eine Anfrage angemessen war. Es erschwert aber, eine stille Veränderung der aufgezeichneten Reihenfolge zu verbergen. Sammeln Sie nicht jeden Prompt und jeden Modellgedanken als Ersatz für Aktionslogs. Solche Aufzeichnungen erzeugen Datenschutz- und Aufbewahrungsprobleme und identifizieren möglicherweise trotzdem nicht die tatsächliche Netzwerkanfrage. Beginnen Sie mit der Autorisierungsentscheidung und dem Aktionsergebnis. Fügen Sie Prompt-Kontext nur hinzu, wenn Ihre betrieblichen und datenschutzrechtlichen Regeln das rechtfertigen. Geben Sie prüfenden Personen einen festen Abschlussdatensatz. Er sollte die Grant-ID, den wirksamen Endzeitpunkt, die Quelle der Beendigung, die Anzahl erfolgreicher Aktionen, die Anzahl abgelehnter Aktionen nach dem Ende und das Ergebnis der Prüfungsanfrage enthalten. So wird aus der vagen Aussage «Zugriff entfernt» etwas, das bei einer Änderungsprüfung hinterfragt werden kann. ## Bauen Sie die Kontrolle in einer kleinen, testbaren Abfolge auf Sie brauchen keine allgemeine Policy-Engine, um vorübergehenden Zugriff durchzusetzen. Sie brauchen einen engen Mechanismus, den jede Agent-Aktion verwenden muss, und einen Ablehnungspfad, den Sie testen können. Beginnen Sie damit, die Aktionen aufzulisten, die Agenten derzeit in der Produktion ausführen. Trennen Sie Leseaktionen, umkehrbare Schreibvorgänge und Aktionen mit irreversiblen oder weitreichenden Folgen. Ermitteln Sie für jede Aktion, wer das tatsächliche Zugangsmittel besitzt und wo die Durchsetzung stattfindet. Diese Übung bringt häufig Zugangsmittel in Umgebungsvariablen, Shell-Profilen, CI-Logs oder kopierten Konfigurationsdateien ans Licht. Bauen Sie anschließend den minimalen Lebenszyklus: 1. Erstellen Sie eine eigene Run-Identität und eine strukturierte Berechtigung mit Zweck und harter Endzeit. 2. Leiten Sie jede geschützte HTTP- oder SSH-Aktion über einen Executor, der die Berechtigung vor der Verwendung prüft. 3. Akzeptieren Sie ein vorzeitiges Abschluss- oder Widerrufsereignis und speichern Sie dessen wirksamen Zeitpunkt. 4. Senden Sie nach der Beendigung eine harmlose geschützte Anfrage und bewahren Sie das Ergebnis der Ablehnung auf. 5. Prüfen Sie abgelaufene und widerrufene Berechtigungen regelmäßig auf Versuche, die nach dem Ende des Zugriffs fortgesetzt wurden. Beginnen Sie nicht mit komplizierten Regeln, die jeden möglichen Befehl klassifizieren. Teams verbringen Wochen mit Syntaxdebatten, während ihre Agenten weiterhin langlebige Zugangsmittel besitzen. Beginnen Sie mit benannten Zielen, kurzen Lebensdauern, einer Identität pro Run und einem Nachweis der Ablehnung. Fügen Sie feinere Einschränkungen hinzu, wenn Ihre Aktionshistorie zeigt, dass tatsächlich weitreichende Bereiche angefordert werden. Der Qualitätsmaßstab ist einfach und anspruchsvoll: Wenn der Task geschlossen wird, muss ein alter Agent-Prozess an der Produktionsgrenze scheitern, und Sie müssen zeigen können, warum er gescheitert ist. Bis Sie diese Prüfung ausführen können, ist der Zugriff nur auf dem Papier vorübergehend.