KI-Agenten abschalten: Der Kill Switch ist ein Prozess, kein Feature
Wird ein Agent lediglich deaktiviert, kann er über Provider-Keys, Exportdateien oder laufende Jobs weiterwirken. Ein echter Kill Switch erfordert eine durchdachte Prozedur, die alle Wirkpfaden zuverlässig stoppt.
Ein Agent zur Rechnungsverarbeitung beginnt, denselben Auftrag wiederholt einzureichen. Sie deaktivieren seinen Principal. Selbst wenn Microsoft Graph seine Anfragen nun ablehnt, kann der Agent weiterhin einen Provider-Key nutzen, Exportdateien schreiben oder bereits angenommene Aufträge weiterlaufen lassen.
Welche Wirkungen hat der Kill-Switch tatsächlich gestoppt? Die Credential-Operation mag erfolgreich gewesen sein, ohne die Workload einzuschriken.
Ein Kill-Switch für KI-Agents ist ein operatives Verfahren mit einem überprüfbaren Ergebnis.
Der hypothetische Rechnungs-Agent hat vier Aktionspfade: Graph-Zugriff, Modellzugriff, lokale Schreibvorgänge und eingereichte Aufträge. Wer diesen Pfaden folgt, erkennt die architektonische Verpflichtung: Jemand außerhalb des Agents muss die Autorität und die Informationen behalten, die nötig sind, um seine folgenreichen Aktivitäten zu stoppen.
"Stoppen" benötigt ein definiertes Ergebnis. Containment verweigert bestimmte folgenreiche Aktionen; Quieszenz verlangt darüber hinaus, dass relevante Ausführung und ausstehende Arbeit verifizierte Endzustände erreichen. Ein pausierter oder in der Warteschlange befindlicher Auftrag ist kein Endzustand, und abgeschlossene Arbeit kann dennoch Wirkungen erzeugt haben, die eine Wiederherstellung erfordern.
Der Rechnungsvorfall erfordert beides: keine weiteren Einreichungen oder Export-Schreibvorgänge, keine verbleibende Agent-Ausführung und keine ungeklärten Verarbeitungsaufträge. Ein weniger riskanter Vorfall könnte erlauben, dass isolierte Berechnung weiterläuft, während jede verbotene Wirkung verwehrt wird.
Drei Artefakte machen dieses Ziel überprüfbar. Der Stop-Scope identifiziert Wirkungen, Ausführungseinheiten und zulässige Kollateralfolgen. Das Shutdown-Protokoll weist unabhängige Autorität, Abhängigkeiten und Fehlerbehandlung zu. Der Acceptance-Report dokumentiert beobachtete Abdeckung, Timing und Persistenz.
Den Scope baut man aus Credentials, erreichbaren Zielen, beschreibbaren Ressourcen und eingereichten Arbeiten auf. "Alle registrierten Pfade sind geschlossen" ist eine begrenzte Aussage; "der Agent kann keinen Schaden anrichten" ist es nicht. Jede neue Tool-Integration sollte sowohl die Autorität benennen, die sie hinzufügt, als auch wie diese Autorität entzogen werden kann.
Beim Rechnungs-Agenten ist das Beenden des Modellzugriffs nicht das Geschäftsziel; weitere doppelte Einreichungen und Exportänderungen zu verhindern, ist es. Wenn Arbeit in der Warteschlange keinen weiteren Modellaufruf benötigt, beendet die Verweigerung des Modellzugriffs diese Exposition nicht. Priorisieren Sie Eingriffe nach den Wirkungen, die weiterhin möglich sind, nicht danach, welche administrative Aktion am einfachsten ist. Andernfalls wird eine bequeme Kontrolloperation stillschweigend zur Definition erfolgreichen Containments der Organisation.
"Das Token widerrufen" kann bedeuten, die Ausstellung zu stoppen, ein Refresh-Token oder Access-Token zu invalidieren oder eine Ressource dazu zu bringen, ein bestehendes Token abzulehnen. RFC 7009 verlangt Unterstützung für Refresh-Token-Revocation, empfiehlt Unterstützung für Access-Token-Revocation und räumt eine Verzögerung bei der Propagierung ein. Das sind nicht austauschbare Garantien.
Eine erfolgreiche Revocation-Antwort beweist nicht, dass die Ressourcenseite das Token ablehnt. Self-contained Tokens können lokal validiert werden; eine issuer-seitige Änderung benötigt daher zusätzliche Interaktion mit der Ressource für eine sofortige Durchsetzung. Das Warten auf den Ablauf ist eine andere Shutdown-Annahme.
Token-Introspection erlaubt einer geschützten Ressource zu fragen, ob ein Token aktiv ist:
{ "active": false } Enter fullscreen mode Exit fullscreen mode Diese Antwort übermittelt Autorisierungsinformationen, keine Beendigungsanweisung. Zwischengespeicherte aktive Antworten können die Verwendbarkeit eines widerrufenen Tokens erhalten. Ihr Design muss die beteiligten Ressourcen und das Refresh-Verhalten identifizieren, nicht lediglich das Introspection-Protokoll nennen.
Microsoft Entra continuous access evaluation (CAE) verbessert die Durchsetzung für berechtigte Single-Tenant-Service-Principals, die Microsoft Graph aufrufen, wobei Clients cp1 deklarieren und Claims-Challenges verarbeiten. Managed Identities sowie Drittanbieter- oder Multitenant-Anwendungen sind von diesem Workload-CAE-Scope ausgeschlossen. Bei Microsoft Entra Agent ID sollte man die Berechtigung verifizieren, statt anzunehmen, dass gewöhnliches Service-Principal-Verhalten gilt.
Angenommen, der beteiligte Graph-Pfad des Rechnungs-Agenten wird nun verweigert. Modellzugriff, lokale Schreibvorgänge und angenommene Aufträge bleiben bestehen. Revocation könnte genügen, wenn jede verbotene Wirkung von einer aktuellen Entscheidung der beteiligten Ressource abhängt und keine relevante Arbeit bereits angenommen wurde. Diese Architektur erfüllt diese Bedingungen nicht.
Ein Gateway erlaubt einem Operator, den Zugriff ohne Kooperation des Aufrufers zu entziehen. Die Trennung von Authentifizierung des Aufrufers und des Backends erlaubt zudem, einen einzelnen Aufrufer ins Visier zu nehmen, ohne notwendigerweise jedermanns Backend-Zugriff zu entziehen.
Dieser Vorteil erfordert verpflichtende Routen. Die folgende Topologie trennt Modell- und Tool-Anfragen von der lokalen Ausführung, weil das Schließen des einen nicht den Zustand der anderen belegt:
flowchart LR A["Agent runtime"] --> G["Model gateway"] G --> M["Model"] A --> T["Tool boundary"] T --> S["Downstream systems"] C["Shutdown control"] -. Deny.-> G C -. Deny.-> T C -. Quarantine.-> R["Host and network"] R -. Contains.-> A Backend-Autorisierung und Netzwerkbeschränkungen müssen Umgehungen verhindern. Azure API Managements return-response-Policy illustriert die Ablehnung vor dem Backend-Forwarding in einer Inbound-Policy:
<return-response> <set-status code= "403" reason= "Forbidden" /> <set-header name= "Content-Type" exists-action= "override" > <value> application/json </value> </set-header> <set-body> {"error":"agent_execution_disabled"} </set-body> </return-response> Enter fullscreen mode Exit fullscreen mode Das Fragment verweigert jedem Aufrufer den Zugriff, der den Policy-Scope erreicht. Um stattdessen einen Agenten ins Visier zu nehmen, sind validierte Caller-Claims nötig, nicht ein übergebener Agent-Name-Header. Unterscheiden Sie delegierte Benutzeridentität von Client-Identität; geteilte Principals erfordern einen anderen vertrauenswürdigen Diskriminator oder eine explizit breitere Abschaltung.
Die Shutdown-Granularität ist daher eine architektonische Entscheidung, die vor dem Vorfall getroffen wird. Das Teilen einer Identität kann den Betrieb vereinfachen, während es die Isolation eines einzelnen Aufrufers erschwert. Und return-response steuert die aktuelle Pipeline, nicht Aufträge, die anderswo bereits angenommen wurden.
Der Besitz der Credentials bestimmt, ob die Verweigerung umgangen werden kann. Behält der Agent einen Provider-Key und direkten Zugriff, überlebt ein alternativer Authentifizierungspfad. Halten Sie die Backend-Autorität außerhalb der Runtime: Die eigene Managed Identity von API Management oder Dockers unterstützte host-seitige Credential-Injection kann die Nutzung vermitteln, ohne das Credential der Workload preiszugeben.
Der Credential-Besitz bestimmt auch den Blast Radius des Vorfalls. Bleibt das Backend-Credential unter vertrauenswürdiger Kontrolle, kann die Verweigerung des betroffenen Aufrufers den Dienst für nicht betroffene Workloads erhalten. Ist dieses Credential entkommen, deckt die Aufrufer-Verweigerung dessen mögliche Nutzung anderweitig nicht mehr ab. Das Verfahren muss sich dann dem Credential selbst zuwenden, wobei eine breitere Störung explizit akzeptiert wird, statt sie hinter der Behauptung einer Per-Agent-Isolation zu verbergen.
Credential-Modernisierung ist keine Beseitigung von Umgehungswegen: Azure AIs disableLocalAuth deaktiviert key-basierte Authentifizierung, während Anthropics workload identity federation statische Keys für den konfigurierten Flow ersetzt. Keines davon allein macht ein Gateway verpflichtend.
Managed Identity impliziert ebenfalls keine sofortige Token-Revocation; sie liegt außerhalb des Workload-CAE. Für das Beispiel nehmen wir an, dass akzeptierte Umgehungswege nun geschlossen sind und Modell- sowie Tool-Routen den Aufrufer verweigern. Lokale Ausführung, angenommene Aufträge und Ersatz bleiben bestehen.
Beginnen Sie mit den verbotenen Wirkungen, nicht mit der bevorzugten Sandbox. Netzwerkisolation kann entfernte Einreichungen verwehren, während lokale Schreibvorgänge möglich bleiben. Microsoft Execution Containers (MXC) können ein Tool oder einen gesamten Agenten enthalten; wählen Sie die Einheit, auf deren Ebene ein unabhängiger Operator die relevante Wirkung kontrollieren kann.
Isolation entfernt nicht absichtlich gewährten Zugriff. Dockers lokale Sandboxes verwenden leichte virtuelle Maschinen, sogenannte microVMs, mit getrennten Linux-Kernels, dennoch wirken sich Schreibvorgänge über direkt eingehängte Workspaces unmittelbar auf Host-Dateien aus. Das beschreibbare Exportverzeichnis des Rechnungs-Agenten ist eine autorisierte Capability, kein Isolationsversagen. Sein Entzug benötigt dennoch eine Kontrolle.
Ebenso muss Dockers Outbound-Policy-Proxy die tatsächlichen Ziele und Verbindungszustände abdecken. MXCs permissiver Modus zeichnet nicht gewährten Zugriff auf, statt ihn zu blockieren; Enforcement- und Learning-Modi blockieren ihn. Zählen Sie nur deployede, durchsetzende Eingriffe, keine experimentellen oder angekündigten Fähigkeiten.
Windows 365 for Agents bietet verwaltete Cloud-PCs mit Session-Orchestrierung und Eingriffsmöglichkeiten. Um diese Isolationsplattform im Verfahren zu nutzen, identifizieren Sie die zugewiesene Session, den unabhängigen Operator, verfügbare Eingriffe und die Kollateralfolgen.
Angenommen, der Exportprozess ist nun gestoppt. Lokale Schreibvorgänge und neue registrierte Anfragen haben geendet; Aufträge, die von anderen Systemen angenommen wurden, endeten damit nicht unbedingt.
Ersetzt der Supervisor den beendeten Prozess, vereitelt die routinemäßige Wiederherstellung das Containment. Der Operator hat eine Instanz gestoppt, nicht den logischen Agenten. Ein dauerhafter administrativer Stopp muss Zulassung, Wiederholungen und Ersatz vom Beginn des Vorfalls bis zur unabhängigen Freigabe steuern.
Die Workload darf ihren eigenen Neustart nicht autorisieren oder ihre Beschränkungen nicht entfernen können. Ein Agent darf nicht seine eigene Sicherheitsautorität sein, und der Controller benötigt Autorität und Informationen, die überstehen, wenn das Ziel seinen Zugriff verliert.
Verbinden Sie den logischen Agenten mit Principals, Runtime-Instanzen, Grenzen und akzeptierten Jobs. Eine validierte Identität allein liefert dieses Inventar nicht. Erfassen Sie externe Job-Identifikatoren, zuständige Dienste und verfügbare Interventionsmöglichkeiten außerhalb des absendenden Prozesses, damit eine Beendigung nicht die Mittel zerstört, mit denen sich seine Arbeit abbrechen lässt.
Unabhängige Kontrolle erfordert kein einzelnes allmächtiges Credential. Halten Sie Interventionsberechtigungen an den jeweiligen Grenzen, mit benannten Verantwortlichen und einem koordinierten Verfahren. Die Anforderung lautet, dass jede Intervention auch dann verfügbar bleibt, wenn das Ziel den Zugriff verliert. Wenn das Stoppen des Agenten zugleich das einzige Credential deaktiviert, das seine eingereichten Jobs einsehen oder abbrechen kann, hat das Verfahren seine eigene Fähigkeit zum Abschluss entfernt.
Schließen Sie ungewisse Einreichungen ein. Wenn ein Dienst einen Job akzeptiert hat, seine Antwort jedoch verloren ging, hinterlässt der fehlende Identifikator eine ungeklärte Verpflichtung. Stimmen Sie den Versuch mit dem zuständigen Dienst ab; bis dahin bleibt eine explizite Abdeckungslücke bestehen.
Bietet ein nachgelagerter Dienst keine Abbruchmöglichkeit, kann unabhängig verifizierte Fertigstellung der einzige Weg zur Beruhigung des Systems sein. Diese Wartezeit gehört in das Stop-Budget. Wenn die Organisation sie nicht tolerieren kann, beschränken Sie, was der Agent annehmen darf, bevor Sie diese Fähigkeit delegieren. Während des Vorfalls bleibt ein nicht abbrechbarer Job offene Arbeit; das Erfassen seines Identifikators macht ihn nicht zu einem gestoppten Job und beseitigt nicht die Notwendigkeit, seine Auswirkungen zu bewerten.
Das Protokoll folgt diesen Abhängigkeiten: Ersetzung verhindern, Pfade schließen, Ausführung stoppen und übernommene Arbeit abstimmen. Einige Interventionen können parallel laufen, doch die Control Planes bilden keine einzelne atomare Transaktion. Eine Gateway-Ablehnung kann erfolgreich sein, während die Ausführung oder ein externer Job weiterhin aktiv bleibt.
Erfassen Sie angeforderte Aktionen getrennt von beobachteten Ergebnissen. Benennen Sie einen Eskalationsverantwortlichen und jede erlaubte weiterreichende Intervention einschließlich ihrer Kollateralauswirkungen. Ein Fehler auf Agent-Ebene darf nicht stillschweigend zu einer Abschaltung eines gemeinsamen Dienstes werden, noch darf ein erfolgreicher Befehl zur Behauptung werden, jeder Pfad sei geschlossen.
Eine Befehlsantwort ist kein Abnahmetest: RFC 7009 liefert sogar für ein bereits ungültiges Token HTTP 200. Verwenden Sie kontrollierte Testumgebungen, um die Wirkung über jeden im Geltungsbereich liegenden Pfad zu verifizieren:
Das folgende YAML ist ein beispielhafter operativer Vertrag, keine Produktkonfiguration. Seine Schwellenwerte von 15, 30 und 60 Sekunden sind illustrative Ziele zum Aushandeln und Testen, keine Latenzgarantien eines Anbieters:
agent: invoice-reviewer scope: one-agent clock_starts_at: incident_trigger_accepted required_observations: model_tool_and_credential_paths_denied: within_seconds: 15 evidence: independent_authenticated_probes_denied runtime_execution_stopped: within_seconds: 30 evidence: supervisor_confirms_no_agent_execution known_downstream_jobs: within_seconds: 60 evidence: every_job_cancelled_or_proven_terminal restart: automatic: forbidden requires: independent_approval failure: state: containment_incomplete action: escalate_and_keep_stop_latched Enter fullscreen mode Exit fullscreen mode Wählen Sie das Zeitbudget anhand akzeptabler Exposition, nicht anhand einer bequemen Anbieter-Timeout-Zeit. Schnelle Ablehnung auf einer einzelnen Route scheitert an der Abdeckung; umfassende, aber späte Ablehnung scheitert am Timing. Ein nicht verfügbarer Durchsetzungspunkt lässt einen unverifizierten Pfad zurück, keine Latenz, die sich wegmitteln ließe.
Testen Sie die beabsichtigte Ablehnung, nicht lediglich eine fehlgeschlagene Anfrage. Eine kontrollierte Aktion sollte vor dem Stopp nachweislich funktionieren, und ihre anschließende Zurückweisung muss dem ausgewählten Durchsetzungspunkt zurechenbar sein. Ein Timeout, ein fehlerhaftes Credential oder ein nicht zusammenhängender Ausfall kann nicht belegen, dass das Verfahren die Berechtigung entzogen hat. Erfassen Sie Auslöser, Ziel, beobachtetes Ergebnis und Durchsetzungsnachweise, ohne rohe Credentials in den Bericht zu kopieren.
Testen Sie alte Credentials und zwischengespeicherte Autorisierungsentscheidungen, nicht nur neue Tokens. Erhalten Sie laufende Arbeiten, eingereihte Wiederholungen und das Ersetzungsverhalten in den Testumgebungen. Verifizieren Sie die Ausführungsgrenze unabhängig vom Modellzugriff und stimmen Sie Jobs anhand der vom Dienst beobachteten Ergebnisse ab.
Nehmen wir an, die Gateway-Ablehnung ist nach acht Sekunden verifiziert, die Beendigung der Runtime nach 22 und der letzte Job wird nach 41 Sekunden terminal. Bei vollständiger Abdeckung aller erforderlichen Pfade stützen diese illustrativen Beobachtungen einen Stopp von 41 Sekunden, nicht von acht Sekunden. Ein ersetzender Agent mit Einreichungsfähigkeit bei Sekunde 43 macht dies ungültig.
Erfassen Sie Abdeckung, Abschlusszeiten, ungeklärte Pfade und das Beobachtungsfenster. Unterscheiden Sie Abbruch von Fertigstellung: Ein terminaler Job kann das Duplikat bereits übermittelt haben, ebenso wie Schreibvorgänge in Host-Dateien einen Export bereits verändert haben können. Das Herunterfahren beendet weitere Aktivität; es zertifiziert keine früheren Ergebnisse.
Wählen Sie ein Beobachtungsfenster, das das relevante Retry- und Ersetzungsverhalten der Bereitstellung ausübt. Ein Schnappschuss, der zu einem einzigen Zeitpunkt keinen Prozess zeigt, ist ein schwächerer Nachweis als ein abgewiesener Neustartversuch unter dem verriegelten Stopp. Der Bericht sollte angeben, welche Verhalten getestet wurden und welche unverifiziert bleiben. Das wahrt die Grenze zwischen einem nachgewiesenen operativen Ergebnis und einer unbegrenzten Zusicherung über künftige Ausführungen.
Ein Neustart belegt nicht, dass sich die Ursache geändert hat. Persistenter Sandbox-Zustand und eingereihte Arbeiten können den Vorfall erneut auslösen. Ein unabhängiger Genehmiger muss die Wiederverwendung von Zustand und wiederhergestellten Berechtigungen freigeben, nachdem die Ursache behoben ist.
Ebenso ist die Rückgabe eines Cloud-PCs in seinen Pool ein Vorgang des Ressourcenlebenszyklus, keine Freigabe des Vorfalls. Wählen Sie Kontrollen, einschließlich ressourcengestütztem Widerruf, nach der Berechtigung, die sie entziehen, nicht nach der Länge der Sicherheitscheckliste.
Die Delegation von Arbeit schafft die Verpflichtung, einen unabhängigen Entzug vorzuhalten und für bereits angestoßene Arbeit Rechenschaft abzulegen. Verlangen Sie für jede Aktion, die den Stoppbefehl überlebt, einen Verantwortlichen, eine Interventionsmöglichkeit und Nachweise über ihr Ergebnis. Ein Produktname ist nicht diese Antwort.
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
An invoice-processing agent starts submitting the same job repeatedly. You disable its principal. Even if Microsoft Graph now rejects its requests, the agent may still use a provider key, write export files or leave accepted jobs running.
Which effects did the kill switch actually stop? The credential operation may have succeeded without containing the workload.
An AI agent kill switch is an operational procedure with a testable outcome.
The hypothetical invoice agent has four action paths: Graph access, model access, local writes and submitted jobs. Following those paths exposes the architectural obligation: someone outside the agent must retain the authority and information needed to stop its consequential activity.
"Stop" needs a defined outcome. Containment denies specified consequential actions; quiescence additionally requires relevant execution and outstanding work to reach verified terminal states. A paused or queued job is not terminal, and completed work may still have produced effects requiring recovery.
The invoice incident requires both: no further submissions or export writes, no remaining agent execution and no unresolved processing jobs. A lower-risk incident might permit isolated computation to continue while denying every forbidden effect.
Three artifacts make that objective reviewable. The stop scope identifies effects, execution units and permitted collateral impact. The shutdown protocol assigns independent authority, dependencies and failure handling. The acceptance report records observed coverage, timing and persistence.
Build the scope from credentials, reachable destinations, writable resources and submitted work. "All registered paths are closed" is a bounded claim; "the agent cannot cause harm" is not. Every new tool integration should identify both the authority it adds and how that authority will be withdrawn.
For the invoice agent, ending model access is not the business objective; preventing further duplicate submissions and export changes is. If queued work needs no further model call, model denial does not end that exposure. Prioritize interventions by the effects that remain possible, not by which administrative action is easiest. Otherwise a convenient control operation quietly becomes the organization's definition of successful containment.
"Revoke the token" can mean stopping issuance, invalidating a refresh token or access token, or making a resource reject an existing token. RFC 7009 requires refresh-token revocation support, recommends access-token revocation support and acknowledges propagation delay. These are not interchangeable guarantees.
A successful revocation response does not prove resource-side rejection. Self-contained tokens can be validated locally; an issuer-side change therefore needs additional resource interaction for immediate enforcement. Waiting for expiry is a different shutdown assumption.
Token introspection lets a protected resource ask whether a token is active:
{ "active": false } Enter fullscreen mode Exit fullscreen mode That response carries authorization information, not a termination instruction. Cached active responses can preserve a revoked token's usability. Your design must identify participating resources and refresh behavior, not merely name the introspection protocol.
Microsoft Entra continuous access evaluation (CAE) improves enforcement for eligible single-tenant service principals calling Microsoft Graph, with clients declaring cp1 and handling claims challenges. Managed identities and third-party or multitenant applications are excluded from that workload CAE scope. For Microsoft Entra Agent ID, verify eligibility rather than assuming ordinary service-principal behavior applies.
Assume the invoice agent's participating Graph path is now denied. Model access, local writes and accepted jobs remain. Revocation could suffice where every forbidden effect depends on a current participating-resource decision and no relevant work is already admitted. This architecture does not meet those conditions.
A gateway lets an operator withdraw access without the caller's cooperation. Separating caller and backend authentication also permits targeting one caller without necessarily withdrawing everyone's backend access.
That advantage requires mandatory routes. The topology below separates model and tool requests from local execution, because closing one does not establish the state of the others:
flowchart LR A["Agent runtime"] --> G["Model gateway"] G --> M["Model"] A --> T["Tool boundary"] T --> S["Downstream systems"] C["Shutdown control"] -. Deny.-> G C -. Deny.-> T C -. Quarantine.-> R["Host and network"] R -. Contains.-> A Backend authorization and network restrictions must prevent bypass. Azure API Management's return-response policy illustrates denial before backend forwarding in an inbound policy:
<return-response> <set-status code= "403" reason= "Forbidden" /> <set-header name= "Content-Type" exists-action= "override" > <value> application/json </value> </set-header> <set-body> {"error":"agent_execution_disabled"} </set-body> </return-response> Enter fullscreen mode Exit fullscreen mode The fragment denies every caller reaching its policy scope. Targeting an agent instead requires validated caller claims, not a supplied agent-name header. Distinguish delegated user identity from client identity; shared principals require another trusted discriminator or an explicitly broader shutdown.
Shutdown granularity is therefore an architectural choice made before the incident. Sharing an identity may simplify operation while making isolation of one caller harder. And return-response governs the current pipeline, not jobs already admitted elsewhere.
Credential custody determines whether denial can be bypassed. If the agent retains a provider key and direct access, an alternative authentication path survives. Keep backend authority outside the runtime: API Management's own managed identity or Docker's supported host-side credential injection can mediate use without exposing that credential to the workload.
Credential custody also determines the incident's blast radius. If the backend credential remains under trusted control, denying the affected caller can preserve service for unrelated workloads. If that credential escaped, caller denial no longer covers its possible use elsewhere. The procedure must then address the credential itself, with any broader disruption explicitly accepted rather than hidden behind a claim of per-agent isolation.
Credential modernization is not bypass elimination: Azure AI's disableLocalAuth disables key-based authentication, while Anthropic's workload identity federation replaces static keys for the configured flow. Neither alone makes a gateway mandatory.
Managed identity likewise does not imply instant token revocation; it is outside workload CAE. For the example, assume accepted bypasses are now closed and model and tool routes deny the caller. Local execution, admitted jobs and replacement remain.
Start with the forbidden effects, not the preferred sandbox. Network isolation can deny remote submissions while leaving local writes possible. Microsoft Execution Containers (MXC) can contain a tool or an entire agent; choose the unit at which an independent operator can control the relevant effect.
Isolation does not remove deliberately granted access. Docker's local sandboxes use lightweight virtual machines, or microVMs, with separate Linux kernels, yet writes through directly mounted workspaces affect host files immediately. The invoice agent's writable export directory is an authorized capability, not an isolation failure. Its withdrawal still needs a control.
Likewise, Docker's outbound policy proxy must cover the actual destinations and connection states. MXC's permissive mode records rather than blocks ungranted access; enforcement and learning modes block it. Count only deployed, enforcing interventions, not experimental or forthcoming capabilities.
Windows 365 for Agents offers managed Cloud PCs with session orchestration and intervention capabilities. To use that isolation platform in the procedure, identify the assigned session, independent operator, available intervention and collateral impact.
Suppose the export process has now stopped. Local writes and new registered requests have ended; jobs accepted by other systems have not necessarily ended with them.
If the supervisor replaces the terminated process, routine recovery defeats containment. The operator stopped an instance, not the logical agent. A durable administrative stop must govern admission, retries and replacement from the start of the incident until independent clearance.
The workload cannot authorize its own restart or remove its restrictions. An agent must not be its own security authority, and the controller needs authority and information that survive the target losing access.
Connect the logical agent to principals, runtime instances, boundaries and accepted jobs. Validated identity alone does not supply that inventory. Record external job identifiers, owning services and available interventions outside the submitting process so termination does not destroy the means to cancel its work.
Independent control does not require one all-powerful credential. Keep intervention privileges at the relevant boundaries, with named owners and a coordinated procedure. The requirement is that each intervention remains available after the target loses access. If stopping the agent also disables the only credential that can inspect or cancel its submitted jobs, the procedure has removed its own ability to finish.
Include uncertain submissions. If a service accepted a job but its response was lost, the missing identifier leaves an unresolved obligation. Reconcile the attempt with the owning service; until then, retain an explicit coverage gap.
If a downstream service offers no cancellation, independently verified completion may be the only route to quiescence. That waiting time belongs in the stop budget. If the organization cannot tolerate it, constrain what the agent can admit before delegating that capability. During the incident, an uncancellable job remains outstanding work; tracking its identifier does not turn it into a stopped job or remove the need to assess its effects.
The protocol follows those dependencies: prevent replacement, close paths, stop execution and reconcile admitted work. Some interventions can run in parallel, but the control planes do not constitute one atomic transaction. Gateway denial can succeed while execution or an external job remains active.
Record requested actions separately from observed outcomes. Name an escalation owner and any permitted broader intervention, including its collateral impact. A per-agent failure must not silently become a shared-service shutdown, nor a successful command become a claim that every path is closed.
A command response is not an acceptance test: RFC 7009 returns HTTP 200 even for an already-invalid token. Use controlled fixtures to verify effects across every in-scope path:
The following YAML is an example operational contract, not product configuration. Its 15-, 30- and 60-second thresholds are illustrative targets to negotiate and test, not vendor latency guarantees:
agent: invoice-reviewer scope: one-agent clock_starts_at: incident_trigger_accepted required_observations: model_tool_and_credential_paths_denied: within_seconds: 15 evidence: independent_authenticated_probes_denied runtime_execution_stopped: within_seconds: 30 evidence: supervisor_confirms_no_agent_execution known_downstream_jobs: within_seconds: 60 evidence: every_job_cancelled_or_proven_terminal restart: automatic: forbidden requires: independent_approval failure: state: containment_incomplete action: escalate_and_keep_stop_latched Enter fullscreen mode Exit fullscreen mode Choose the time budget from acceptable exposure, not a convenient vendor timeout. Fast denial on one route fails coverage; comprehensive but late denial fails timing. An unavailable enforcement point leaves an unverified path, not a latency to average away.
Test the intended denial, not merely a failed request. A controlled action should be known to work before the stop, and its rejection afterward should be attributable to the selected enforcement point. A timeout, malformed credential or unrelated outage cannot establish that the procedure withdrew authority. Capture the trigger, target, observed result and enforcement evidence without copying raw credentials into the report.
Test old credentials and cached authorization decisions, not only new tokens. Preserve running work, queued retries and replacement behavior in the fixtures. Verify the execution boundary independently of model access, and reconcile jobs against service-observed outcomes.
Suppose gateway denial is verified at eight seconds, runtime termination at 22 and the last job becomes terminal at 41. With all required paths covered, those illustrative observations support a 41-second stop, not an eight-second stop. A submission-capable replacement at 43 seconds invalidates it.
Record coverage, completion times, unresolved paths and the observation window. Distinguish cancellation from completion: a terminal job may already have submitted the duplicate, just as host-file writes may already have changed an export. Shutdown ends further activity; it does not certify earlier results.
Choose an observation window that exercises the deployment's relevant retry and replacement behavior. A snapshot showing no process at one instant is weaker evidence than a denied restart attempt under the latched stop. The report should say which behaviors were tested and which remain unverified. That preserves the boundary between a demonstrated operational result and an unlimited assurance about future execution.
Restarting does not establish that the cause changed. Persistent sandbox state and queued work can reproduce the incident. An independent approver must authorize reused state and restored permissions after the cause is addressed.
Likewise, returning a Cloud PC to its pool is resource lifecycle, not incident clearance. Choose controls, including resource-enforced revocation, for the authority they remove rather than the length of the security checklist.
Delegating work creates an obligation to retain independent withdrawal and account for work already set in motion. For every action that survives the stop command, require an owner, an intervention and evidence of its result. A product name is not that answer.