An operations lead withdraws an agent’s permission to release payments. The agent’s main process exits. One payment remains in a queue, a delegated task is still running, and a worker may retry a request whose outcome is uncertain. Each of those items needs an accountable disposition before the incident owner can say what has stopped.
The scenario is illustrative. It frames one research question: which observations support a claim that an agent’s withdrawn authority can no longer cause an action, within a stated scope? This post reviews recent research and protocol specifications, reports a small reproduction of a published closure verifier, and gives a worksheet an incident owner can fill in. This post is part of a three-part research series on agent authority, published 26 October 2026: stop evidence, policies in agent memory and agent control standards.
Define the scope of the claim first
Recent research separates stages that a single “revoked” status can hide. Revocation Is Not Complete at Receipt, an October 2026 preprint by Lifei Liu, Haoran Yu and Danping Zhang, distinguishes committing and delivering a revocation from enforcing it at gateways and preventing guarded effects during an observation window. Its experiments use one deliberately partitioned delivery topology, and the authors give no industry-wide failure rate. Read the paper.
A September 2026 preprint by Genliang Zhu and Chu Wang addresses authority that continues through delegation and asynchronous work. Its protocol tracks where authority came from, how authorization state changes, and checks at the point where an action takes effect. It also accounts for work that continues under a separate valid authority. Both papers are preprints; their reported results depend on their stated assumptions. Read the protocol and evaluation.
The practical step is to write the claim before collecting evidence for it. Name the withdrawn authority, the affected actions, the enforcement routes and the observation window. Record exclusions explicitly. A statement about payment release should say whether it covers scheduled jobs, retries, delegated workers and requests a payment provider had already accepted.
Delivery and cancellation have defined limits
Existing protocols already cover parts of this problem. The OAuth token revocation specification discusses propagation delay, and the token introspection specification describes the security cost of caching introspection responses. Both matter when an agent’s workers consult different copies of authorization state. RFC 7009, RFC 7662.
The final OpenID CAEP 1.0 and Shared Signals Framework 1.0 specifications define event and delivery contracts that can coordinate a change across systems. An incident owner still needs evidence of what each receiver and downstream enforcement point did with the signal. CAEP 1.0, Shared Signals Framework 1.0.
Cancellation has its own limits. The Model Context Protocol specification dated 2025-06-18 makes cancellation notifications optional and recognises that processing may already have completed, or may be impossible to cancel. A report on a workflow’s outcome must account for those races. MCP cancellation.
What we checked independently
RISU Research publishes a separate closure verifier, bounded-agent-closure. It is cited in related work and is distinct from both preprints above. We ran its unchanged test suite at commit ef07236 (package 0.3.1, Node 20): all 75 tests passed. We then submitted its eight supplied synthetic evidence bundles to the verifier and kept the decisions it returned. Pinned upstream repository.
- A missing view is a gap. When the scheduler view was absent, the verifier returned UNKNOWN.
- A surviving schedule is unfinished work. An observed schedule returned INCOMPLETE, even when the bundle claimed success.
- History can stay. Retained historical evidence was compatible with CLOSED in this profile.
- Successors are explicit. A transfer to a successor closed under the conditions the fixture encodes.
| Supplied fixture | Observed result |
|---|---|
| Direct surviving task | INCOMPLETE |
| Transitive surviving task | INCOMPLETE |
| Pending commitment | INCOMPLETE |
| Retained evidence | CLOSED |
| Successor transfer | CLOSED |
| Missing coverage | UNKNOWN |
| Claimed success with a surviving schedule | INCOMPLETE |
| Completed wind-down with stable final scans | CLOSED |
What the reproduction does not show
The verifier evaluates evidence it is given. Our run started no agent, queue or payment, did not search for hidden queues, and does not show that a real collector reports everything truthfully. The test suite and the fixture replay overlap, so the eight fixtures are not eight further independent validations. A verifier result is only as meaningful as the evidence scope and the collection process behind it.
We did not reproduce either preprint. The first paper reports 112 guarded effects in 225 attempts under its partitioned topology; the second reports 17 accepted cases and 44 rejected mutations for its checker. Both figures are the authors’ own. The first paper’s artifact endpoint returned no usable content through our tools.
Give the incident owner an evidence record
We turned the research into a stop-evidence worksheet. It asks for the authority withdrawn, the downstream work, the places that enforce the withdrawal, committed effects and unresolved observations. It has space for successor work under independent authority and for the person who owns reconciliation.
Consider a worker that sent a payment request before revocation and receives the receipt afterwards. The receipt belongs in the incident record. The worker’s next action needs its own current authorization check. An effect that has already committed may need a separate business response, such as reconciliation or an authorized reversal. The worksheet records those responsibilities and assumes no effect can be undone by default.
| Field | What to record |
|---|---|
| Authority withdrawn | Root and delegation identifiers; the revocation request and committed change identifiers |
| Observation window | Clock sources, uncertainty, start and end |
| Scope | Actions and effect destinations included; excluded routes and the reason for each |
| Enforcement routes | The last authorization version observed at each route |
| Open work | Queue entries, retries, delegated work and pending commitments |
| Disposition per item | Prevented, completed earlier, transferred, pending or unknown |
| After the cut | Attempts and committed effects; late receipts and reconciliation actions |
| Gaps | Missing collectors, stale views or contradictory evidence |
| Owners | Remaining actions, owners and next review time |
Write the stop statement with its limits
The worksheet ends with a statement the incident owner can reuse: “For [authority] and [declared routes], observations from [start] to [end] show [result]. [Items] remain unresolved because [specific evidence gap]. [Owner] owns reconciliation.”
Keep the time and scope qualifiers when the statement is copied into an incident summary. The statement then says which actions were prevented, which had already committed, which tasks were transferred and which observations are unavailable. Operations, engineering and risk owners can review one record with a clear meaning for the word “stopped”.
How the KLA stop path relates to the worksheet
Agents that act through KLA agent action ingress work under an agent mandate. Revoking the mandate blocks open proposals bound to it with the reason code mandate_revoked, cancels their pending Decision Requests, and refuses the next action the agent proposes. An action that was already admitted may complete, so it belongs in the worksheet’s “completed earlier” or “after the cut” rows.
The research in this post did not test KLA. The kill-switch architecture guide describes the full KLA stop path, including the incident freeze, and the incident response playbook covers the rest of the incident record.
Frequently Asked Questions
How do you prove an AI agent has stopped?
State the claim first: the authority withdrawn, the routes covered and the observation window. Then record the last authorization version seen at each enforcement route, the disposition of every queued, retried and delegated item, any effects that committed after the cut, and the evidence that is missing. The claim holds only within that scope and window.
Does revoking an agent’s token stop work already in progress?
Not necessarily. OAuth revocation can take time to propagate and cached introspection can be stale. Work already queued, delegated or accepted by a downstream system may still complete, and MCP cancellation is optional and can race with completion. Each item needs its own recorded disposition.
Can a revoked agent’s completed actions be undone?
Revocation stops new actions. An effect that already committed stays committed: a payment, for example, needs a separate business response such as reconciliation or an authorized reversal, recorded with its owner.
What did the closure verifier reproduction show?
At commit ef07236, all 75 upstream tests passed, and the eight supplied synthetic bundles returned three CLOSED, four INCOMPLETE and one UNKNOWN. The run evaluated supplied evidence only. It started no agent or queue and says nothing about how complete a real collector is.
Key Takeaways
An agent has stopped only within a scope someone wrote down: the authority, the routes and the time window. Collect the evidence for that scope, give every open item a disposition, and name the gaps and their owners. Start with the stop-evidence worksheet, and read the kill-switch architecture for the controls that produce the evidence.
Sources were checked on 26 October 2026. The two preprints have not been independently reproduced. Our observations use published synthetic fixtures and contain no KLA production result.