Revocation Is a Runtime Event

Authority changes. Approval is withdrawn, a budget is exhausted, a credential is compromised, a deployment window closes, consent is revoked, a policy is superseded or a delegation simply expires.

In a static permission model, this can look easy: the action was permitted before and is prohibited now. Agent systems make the problem harder because work may already be in motion. The system may be executing a multi-step task, waiting on external services, coordinating other agents, carrying temporary authority or preparing a consequential action whose legitimacy depended on a delegation that no longer exists.

The question is therefore not merely whether authority can be revoked.

It is:

What happens to work already in motion when the authority supporting it changes?

That is a runtime problem.

Authority has time

A delegation is not merely a set of permissions. It exists during an interval in which those permissions are valid, even when nobody bothered to write the interval down.

Authority begins. It may be narrowed, superseded, revoked or allowed to expire.

A useful authority model must therefore describe not only what actions are permitted but when those permissions are valid and whether the conditions supporting them still hold. An action can be permitted when planned and prohibited when executed, permitted when execution begins and prohibited before it completes, or valid for one phase of a workflow but not the next.

Static permission checks miss that movement.

A governed system must not.

A valid plan can become an invalid action

Suppose an agent is authorised to issue refunds up to $500. It identifies twelve eligible customers and prepares the refund operations. Before execution, the operator reduces the agent's authority to $100.

The reasoning may still be sound. The customer records may be unchanged. The recommendation may remain historically intelligible.

What changed is the authority to convert that recommendation into consequence.

The correct state is therefore not “the plan says refund $420, continue”, nor should the plan be erased as though it never made sense. The system should preserve the recommendation while recognising that execution now exceeds current authority.

A valid plan can become an invalid action.

Permission should be checked at consequence boundaries

A naive implementation checks authority once:

task received → authority valid → execute workflow

That turns the initial permission check into a blank cheque.

A governed agent should instead re-evaluate authority at meaningful consequence boundaries:

receive objective → check authority → investigate → prepare recommendation → revalidate before external communication or mutation → execute → receipt

The exact checkpoints should scale with consequence. Reading a local reference file may not require repeated revalidation. Transferring money probably should.

The longer the distance between authorisation and consequence, the weaker an old authority check becomes.

Time passes, state changes, people intervene and other systems act. A permission check is evidence about a moment.

It is not eternal truth.

Revocation must propagate

Revoking authority in one registry is not sufficient if active agents never learn about it.

This creates a particularly ugly distributed-systems failure: authority is revoked conceptually but remains operationally alive. The control plane says “no longer authorised” while the running agent says “nobody told me”.

Both can be technically true. The outcome is still unacceptable.

A mature system therefore needs a mechanism by which material authority changes reach execution paths whose legitimacy depends on them. Depending on the architecture, that may involve event propagation, short-lived authority tokens, leases, polling, capability invalidation, execution checkpoints, central policy evaluation, cancellation signals, revocation registries or parent-child delegation updates.

The mechanism is implementation.

The requirement is architectural:

Material revocation must become visible to the execution paths whose legitimacy depends on the revoked authority.

Otherwise revocation exists only on paper.

Revocation latency is a real property

Revocation is rarely instantaneous.

A policy changes at 12:00:00. One service sees it a second later, another four seconds later, an offline worker several minutes later, while an external system has already accepted a queued command.

This delay is revocation latency.

It should not be treated as an embarrassing implementation detail. It is part of the governance model.

Consequential systems should be able to answer how quickly revocation propagates, which operations may continue during that interval, which actions are too consequential to tolerate delayed revocation, what happens to already-emitted commands, and how uncertain revocation state is represented.

A system handling draft documents may tolerate substantial delay. A system capable of moving significant money may not.

Governance has temporal tolerances.

Pretending otherwise does not make the network faster.

Some authority should be leased

One response to revocation is to avoid creating long-lived authority where shorter authority will do.

Instead of:

Agent may deploy production indefinitely.

Prefer something like:

Agent may deploy service X until 17:00 under change window CW-192.

Or:

Agent may execute this approved release while conditions C remain true.

This makes authority behave more like a lease. The agent must periodically establish that its authority remains valid.

Short-lived authority helps stale permissions expire, prevents forgotten grants from living forever and makes revocation easier to reason about.

But leases are not magic. If renewal is automatic and unconditional, we have merely invented permanent authority with extra HTTP requests.

Renewal must remain connected to the conditions that justified the authority.

Derived authority must die with its parent

Delegation may propagate.

A principal delegates to Agent A. Agent A legitimately delegates a narrower task to Agent B. Agent B delegates a bounded operation to Agent C.

Now revoke A's originating authority.

If B and C continue indefinitely because their delegations were issued before revocation, the system has created authority laundering. The descendants survive their source.

The general rule should be:

Derived authority cannot outlive the authority from which it derives unless another legitimate authority explicitly replaces that basis.

If P → A is revoked, authority derived exclusively through P → A → B → C should collapse downstream.

Not identity. Not memory. Not necessarily all work.

Authority.

Agent B may still exist, hold evidence, explain what happened and later receive a new delegation. What disappears is the legitimacy inherited through the revoked chain.

Revocation should target authority, not identity

Suppose an agent behaves incorrectly and an operator revokes its deployment authority.

The correct response is not to erase the agent's state merely so it can no longer deploy. Historical receipts, evidence and identity may be exactly what investigators need to understand the event.

Authority revocation should not normally imply identity deletion, memory erasure, retrospective history mutation, removal of unrelated permissions or forced agreement with the revoking authority.

A participant can lose permission to act without becoming illegible.

You may constrain consequence without rewriting cognition.

Revocation and cancellation are not identical

A revoked permission may imply cancellation, but not always.

Imagine an agent is authorised to inspect logs, diagnose an incident, modify production and write the incident report. Production mutation authority is revoked halfway through.

The entire task does not necessarily disappear. The agent may still preserve findings, continue diagnosis, document current state, produce an escalation and assist the newly authorised operator.

The system should therefore distinguish:

• authority revoked
• task cancelled
• participant terminated

These are different events.

An agent may need to continue under a smaller authority envelope. A useful runtime operation is therefore to rebind active work to the surviving authority envelope.

The task changes shape without pretending nothing happened.

In-flight actions need explicit treatment

Some actions cannot be stopped cleanly once begun. A message may already have left the system. A financial transaction may be pending settlement. A deployment may be halfway through. A physical system may already be moving. An external API may have accepted a command without exposing cancellation.

Revocation therefore needs different treatment for different execution states.

Not yet executed

Do not execute.

Executing but cancellable

Attempt safe cancellation or interruption and record what completed and what did not.

Irreversible or externally committed

Changing authority state cannot undo the consequence. The system must stop subsequent dependent actions, record the committed consequence, initiate recovery where possible, escalate where necessary and preserve the authority timeline.

This is why revocation cannot be reduced to flipping a boolean.

Reality has momentum.

Sometimes the command has already left the building.

Revocation does not rewrite legitimate history

Suppose an agent had valid authority yesterday and that authority is revoked today. Yesterday's legitimate actions remain legitimate. Revocation changes future authority; it does not rewrite time.

The inverse also holds. If an agent acted without authority yesterday and receives that authority today, the new grant does not retrospectively legitimise the old action.

Authority state is evaluated against the time of consequence.

This is where receipts become essential. Without a receipt preserving the authority state under which an action occurred, later revocation can make historical reconstruction ambiguous.

Receipts and revocation are tightly coupled:

revocation changes what may happen next; receipts preserve why what already happened was or was not legitimate.

One governs the future boundary. The other preserves the past boundary.

Consent revocation deserves special care

Some authority derives from consent.

A person may permit an agent to access records, analyse messages, share data, perform transactions, communicate externally or retain certain information. Consent may later be withdrawn.

The system must then distinguish what future actions must stop, what retained data must be deleted, what records must remain for legal or audit reasons, what derived state may legitimately survive, what historical receipts remain necessary, which downstream systems received the data and whether those consequences can be reversed.

These are not purely technical questions. Law, contract, policy and context may determine the answer.

The runtime's job is not to improvise its own theory of data rights because the architecture feels tidy. It is to represent and enforce the legitimate result.

A revocation event may therefore change both what may happen and, where properly required, what may remain.

Emergency revocation exists for a reason

Sometimes there is no time for graceful transition: credential compromise, active attack, runaway automation, unsafe physical behaviour or material policy failure.

The system may need a kill path.

Even here, precision matters. A mature system should prefer the smallest effective intervention: revoke high-risk external actions, preserve read-only diagnostics, stop new delegation, prevent compromised credential use, retain receipts and forensic state, then broaden the shutdown only when necessary.

Emergency control should not automatically mean “erase everything”.

That is the governance equivalent of dealing with a kitchen fire by demolishing the postcode.

Sometimes required.

Rarely the first move.

Revocation itself should leave a receipt

Revoking authority is consequential and should therefore be answerable.

A revocation receipt may record the authority affected, actor performing the revocation, basis, effective time, expected propagation scope, active tasks affected, downstream delegations invalidated, cancellation attempts, residual risk, recovery conditions and any replacement authority.

That prevents a later puzzle:

Why did the agent suddenly stop?

The answer should not require folklore.

A useful record might say:

Authority envelope AE-204 was revoked by entitled actor OP-17 at 14:32 due to credential compromise. Three derived delegations were invalidated. One in-flight external command could not be cancelled and entered recovery workflow RW-8.

That is usable state.

Revocation needs explicit runtime state

An agent encountering revoked authority has not necessarily failed. It has encountered a changed world.

A mature runtime may distinguish states such as:

• ACTIVE
• EXPIRING
• REVOKED
• SUPERSEDED
• SUSPENDED
• PENDING_REVALIDATION

The exact vocabulary can vary. The important thing is that authority change becomes first-class state.

Otherwise every revocation appears downstream as permission denied, which tells us very little. Was the action always prohibited? Did authority expire? Was it explicitly withdrawn? Did a parent delegation collapse? Is new approval possible? Should the task stop or merely rebind?

Those are materially different situations.

Revalidation should be explicit

When authority changes, the runtime question becomes:

Given current state, current objective and current authority, what remains legitimate?

Possible results include:

• continue — relevant authority survived;
• continue with reduced scope — some permissions remain;
• escalate — the objective remains valid but authority is insufficient;
• suspend — temporary state prevents safe continuation;
• cancel — the task itself is no longer authorised;
• recover — prior consequence must be repaired or contained.

This makes revocation productive. It produces a new governed state rather than an opaque crash.

Never infer restored authority from restored capability

Suppose a revoked credential is re-enabled. The agent can use the tool again.

Does that mean authority has been restored?

No.

Capability returned. Permission may not have.

A tool becoming reachable again cannot silently recreate a delegation. Restoration of authority should itself be explicit, for example through a new authority envelope or a formally reinstated grant.

“Endpoint works again, crack on” is not a governance protocol.

The machine can.

That does not mean the machine may.

We have met this bug before.

Revocation tests whether governance is real

Static authority diagrams are easy: boxes, arrows, scopes, policies. Very handsome.

Revocation asks whether any of it survives contact with a running system. Can authority change while work is moving? Can that change reach the relevant agent? Can downstream delegations collapse correctly? Can legitimate history remain intact? Can the system distinguish reduced authority from identity destruction? Can in-flight consequence be stopped, contained or recorded? Can active work rebind to a smaller envelope?

If not, the system does not really have revocable authority.

It has permissions that remain valid until convenient.

That is a different architecture.

The fifth law

The fifth law is:

Authority must remain revocable while the system is running, and revocation must alter future consequence without rewriting legitimate history.

Authority is not merely something an agent had when the task began. It is something that must still exist when consequence is created.

If it no longer exists, the agent does not inherit yesterday's permission simply because stopping would be inconvenient.

The world changed.

A governed system notices, and changes with it.