Suppose I authorize an agent to prepare a transaction. It starts a worker, places a message on a queue, and gives another service enough information to complete the job. I then withdraw permission. The original process stops immediately. Ten seconds later, the worker commits the transaction.

Nothing in this example requires a malicious model. Ordinary asynchronous execution is enough. The system has three different events: permission was withdrawn, a process was stopped, and an external effect became durable. Treating them as the same event makes the control guarantee difficult to state, let alone test.

My broader idea has been an independent control plane for autonomous systems: something that can reason about consequences across an agent’s tool calls and delegations. That ambition becomes more useful when reduced to one question. After revocation, which previously authorized effects can still become real?

The place where a decision becomes an effect

A narrow architecture would attach a task lineage and authorization generation to a proposed external action. Delegation carries that lineage forward. Before an effect crosses a supported commit boundary, the service checks that the task is still authorized.

The important phrase is “before an effect.” Checking permission when work enters a queue leaves a later interval in which authority can change. Checking only in the original agent misses descendants. A worker’s successful cancellation request is also insufficient if the worker is already past its last cancellable point.

For a genuinely mediated service, one possible contract is that an acknowledged revocation prevents later commits from that authorization generation. The acknowledgement must mean something operational: in-flight checks have been resolved, or the commit service will reject their stale generation. A timestamp in a dashboard cannot supply this property.

This resembles established problems in distributed authorization. Zanzibar, for example, treats consistency between authorization decisions and changes in content as a first-class systems concern. Agent delegation changes the workload and the routes through which authority travels. It does not make consistency a newly discovered problem.

What the monitor can actually know

Consequence-aware screening adds another layer. A file read may be harmless in isolation and sensitive when followed by an upload. Several agents may divide a workflow so that no individual call looks dangerous. A monitor needs history and some model of the environment to reason about the sequence.

That semantic judgment should remain separate from the enforcement mechanism. An LLM can suggest that a proposed sequence deserves a pause; it cannot make an unmediated network path disappear. A reliable commit check can enforce a narrow rule while understanding very little about intent. Both can be useful, but their failure modes differ.

An adversarial evaluation should therefore test two things independently: whether the monitor recognizes disallowed trajectories, and whether the execution substrate prevents a rejected trajectory from committing. Combining them into one “blocked actions” number hides which layer failed.

The experiment

The pilot I have proposed uses an asynchronous workflow with a queue, a delegated worker, and an external write. Withdraw permission at varied points. Compare task cancellation, process termination, credential expiry, and a commit gate under the same workload. Include retries and a worker that cached its earlier authorization.

Measure effects committed after the revocation acknowledgement, acknowledgement latency, and ordinary task performance. Introduce legitimate concurrent work so that success cannot mean shutting down the entire system. Then give an adapting agent opportunities to use alternative supported routes.

The claim has a hard boundary. It cannot recall a disclosure already delivered, stop an unmediated copy, or control a service that does not participate. GPU-bound keys or a power switch do not automatically solve those cases. A hardware identity is evidence about a machine, not a proof that no useful copy or downstream action exists elsewhere.

I have explored much broader shutdown ideas. The version worth pursuing first is this bounded one: a clearly defined region in which permission remains withdrawable after delegation. If the only reliable way to revoke a task is to stop unrelated work too, that is an important failure of the design.

Reading and related work