Ausführungsbedingungen für Agenten festlegen, die nach dem Abmelden weiterarbeiten

Ziel

Stand: 25. Oktober 2026. Festlegen, was ein Agent nach dem Trennen der Verbindung durch die bedienende Person tun darf, wie viele Ressourcen er verbrauchen darf und wie seine Befugnis endet. Das Neustartverhalten des eingesetzten Supervisors, den Lebenszyklus der Zugangsdaten und die Möglichkeiten zum Abbruch entfernter Vorgänge erneut prüfen. Diese vorgeschlagene Vereinbarung ergänzt die Konfiguration des Dienstkontos um Kontrollen für einen gesamten unbeaufsichtigten Lauf.

Voraussetzungen

Eine verantwortliche Stelle, einen dauerhaften Aufgabenspeicher und einen Supervisor benennen, der die Arbeit unabhängig vom Modell stoppen kann. Lokale Prozesse, delegierte Subagenten und entfernte Jobs erfassen. Anders als bei einer interaktiven Sitzung muss für diesen Ablauf festgelegt sein, was geschieht, wenn keine Rückfrage möglich ist: einen blockierten Zustand dauerhaft speichern und die zuständige Person über einen genehmigten Kanal benachrichtigen.

Schritte

1. Die Ausführungsbedingungen dokumentieren. Zielrevision, erlaubte Ressourcen und Aktionen, Ausgabeort, Ablaufzeitpunkt, Budget und Eskalationsweg speichern. Dem Dienst eine eigene eingeschränkte Identität geben und den auslösenden Nutzer separat erfassen. Einen kopierten Zugangsdatenbestand aus einer interaktiven Sitzung nicht als Identitätskonfiguration des Dienstes verwenden.
2. Nur den erforderlichen Zugriff gewähren. Die Funktionen der Plattform für Workload-Identitäten verwenden. Die Kubernetes-Dokumentation zu Service Accounts beschreibt eigenständige Workload-Identitäten und automountServiceAccountToken: false für Pods, in denen API-Zugangsdaten nicht automatisch eingebunden werden sollen. Eng begrenzte Berechtigungen an der Ressource anwenden, auf die zugegriffen wird. Eine Erneuerung der Zugangsdaten darf den Autorisierungszeitraum der Aufgabe nicht stillschweigend verlängern.
3. Die gesamte Aufgabe budgetieren. Den kumulierten Verbrauch über Subagenten, Wiederholungsversuche und Prozessneustarts hinweg dauerhaft speichern. Grenzen für verstrichene Zeit, Modell- und Tool-Aufrufe, Parallelität, Speicher und kostenpflichtige Dienste festlegen. Vor dem Start Kapazität reservieren, wenn parallele Worker ein gemeinsames Kontingent überschreiten könnten. Dokumentieren, welche Grenzen der Supervisor oder das Gateway tatsächlich durchsetzt; ein Satz im Prompt ist lediglich eine Aufforderung.
4. Einen unabhängigen Stoppweg einrichten. Bei Ablauf der Befugnis oder einem Stopp durch die bedienende Person den Start neuer Arbeit sperren, automatische Neustarts für diesen Lauf deaktivieren und den Abbruch erfasster Arbeit anfordern. Wo vorhanden, den Ablauf der Autorisierung am Schreib-Gateway durchsetzen. Bereits von entfernten Diensten angenommene Vorgänge abgleichen, bevor der Stopp als abgeschlossen gemeldet wird. Ungeklärte Auswirkungen sichtbar halten und eine blinde Wiederholung nach einem Neustart verhindern.
5. Plattformkontrollen präzise zuordnen. Kubernetes Jobs unterstützen activeDeadlineSeconds und das Aussetzen eines Jobs. Beim Aussetzen werden seine aktiven Pods beendet; beim Fortsetzen wird der Zeitgeber für die aktive Frist zurückgesetzt. Deshalb ausserhalb dieses Zeitgebers einen absoluten Ablaufzeitpunkt für die Autorisierung festhalten. Das Aussetzen als Steuerung des Prozesslebenszyklus behandeln, für die Wiederaufnahme dauerhaft gespeicherte Checkpoints der Anwendung vorsehen und Ergebnisse entfernter Vorgänge separat prüfen.
6. Den Status unbeaufsichtigter Arbeit einsehbar machen. Aufgaben- und Versuchskennungen, Zielrevision, Identitätsreferenz, Budgetverbrauch, Tool-Ergebnis und Stoppgrund ohne Geheimnisse protokollieren. Die Kontextweitergabe von OpenTelemetry ermöglicht die Zuordnung von Traces über Dienste hinweg. Benötigte Logs exportieren, bevor die Workload bereinigt wird. Bei einem Kubernetes Job zeigt kubectl get job JOB -o yaml den erfassten Zustand; kubectl logs jobs/JOB ist ein Ausgangspunkt zur Prüfung der Ausgaben, aber kein vollständiger Verlauf aller Versuche.

Erwartetes Ergebnis

Auch nach dem Trennen der Verbindung lässt sich feststellen, wer einen Lauf autorisiert hat, was noch aktiv ist und ob weiterhin eine Schreibbefugnis besteht. Bei einem Neustart des Workers bleiben das Restbudget und der ursprüngliche Ablaufzeitpunkt erhalten. Abschluss, Warten auf Eingaben, laufender Stopp und ungeklärte Ergebnisse entfernter Vorgänge bleiben unterscheidbar.

Grenzen und Prüfbasis

Dies ist ein vorgeschlagenes Verfahren, kein getestetes Deployment. In einer isolierten Umgebung das Trennen der Verbindung durch die bedienende Person, die Erschöpfung eines Kontingents, einen Neustart und das Ablaufen der Befugnis erproben, während ein simulierter entfernter Vorgang noch aussteht. Prüfen, dass nach Erreichen der Grenze keine neue Aktion zugelassen wird und ausstehende Auswirkungen weiter erfasst bleiben. Das Beenden eines Prozesses kann nicht als Nachweis dienen, dass eine entfernte Aktion rückgängig gemacht wurde.