Governed Agent Systems

Contents

• Introduction
• 001 — Capability Is Not Permission
• 002 — The Authority Envelope
• 003 — Escalation Is an Output
• 004 — The Receipt
• 005 — Revocation Is a Runtime Event

---

Governed Agent Systems

Introduction

Software is beginning to act.

For most of computing history, this was not the central problem. Software stored information, transformed inputs, displayed interfaces, executed predefined procedures and returned results. Even sophisticated systems were usually understood as tools whose consequential decisions remained somewhere else. A person chose what to do; the software helped them do it.

Agentic systems disturb that arrangement.

They can inspect a situation, determine what appears relevant, choose among possible actions, use tools, alter state, communicate with people and systems, pursue objectives across multiple steps, recover from obstacles and continue without a human specifying every intermediate move.

This is usually described as an increase in capability. It is. But capability is only half of what has changed.

The other half is consequence.

Once software can move from describing what could happen to making something happen, questions that were once peripheral become architectural. Who is the system acting for? What authority has actually been delegated to it? What may it decide for itself? Where does that authority end? What happens when the useful next action lies beyond that boundary? What happens if permission changes while the system is already acting? And after something has changed, how do we establish who changed it, why, under what authority and with what result?

These are sometimes treated as safety features to be added after the agent works. That is backwards. They are part of what it means for the agent to work legitimately at all.

A system that can perform an action has demonstrated capability. A system that can explain why it is entitled to perform that action, recognise when it is not, remain inside that distinction while conditions change, and leave evidence of what it did has demonstrated something else.

It has demonstrated governance.

What governance means here

Governance is an overloaded word. It can evoke committees, policy documents, compliance programmes, approval chains and the peculiar human talent for turning one sensible rule into forty-seven pages of process.

That is not what this series means by governed agency.

Governance begins much earlier and much closer to the action itself.

A governed agent is an artificial system capable of selecting and performing actions within an explicit, attributable, constrained, inspectable and revocable delegation of authority.

Every part of that definition matters. The system acts under authority that comes from somewhere. That authority belongs to a principal before it belongs to a delegate. Delegation transfers some ability to decide or act without making the delegate identical to the principal. The grant has boundaries. Those boundaries can be inspected. They can change. They can be withdrawn. Consequential actions remain attributable afterward.

Governance therefore describes the relationship between capability, authority, judgement and consequence.

It does not require every agent to operate beneath a vast institutional control plane. A local agent working for one person may need nothing more elaborate than a clear authority definition, sensible execution boundaries and reliable receipts. A system operating across money, production infrastructure, customer data or institutional commitments may require considerably stronger machinery.

The machinery should scale with consequence. The underlying distinctions should not.

The missing layer

Much of contemporary agent design concentrates on making agents more capable: better models, better planning, better memory, more tools, longer-running tasks, more reliable execution, broader access and greater autonomy. These developments matter. An agent that cannot reason or act reliably is not made useful merely by governing it beautifully.

But increasing capability without an equally serious model of authority produces a predictable problem: technical reach begins to stand in for legitimate reach.

The agent has credentials, therefore it can access the system. It can access the system, therefore the action is available. The action is available, therefore the workflow proceeds.

Nothing dramatic needs to go wrong. That is precisely the problem.

Authority can disappear quietly inside a successful execution path.

A credential proves that a system can call an endpoint. It does not, by itself, establish why this agent should call that endpoint now, for this purpose, on behalf of this principal, under these conditions.

A writable repository does not establish a mandate to modify every branch. Access to email does not establish authority to make commitments for the account holder. The ability to query a record does not establish that the record is relevant to the task. The ability to spend money does not establish a budget.

The distinction sounds obvious when stated abstractly. Systems erase it surprisingly quickly once everything is connected and working.

That gap is where governed agent systems begin.

Governance is not the opposite of autonomy

Governance does not mean reducing an intelligent system to a chain of permission prompts.

A system that asks a human to approve every trivial intermediate decision is not necessarily well governed. It may simply have displaced judgement onto a biological confirmation button.

The objective is not maximum human intervention. It is legitimate agency.

A useful agent should be able to exercise substantial judgement inside the authority it has actually been given. It should investigate, reason, choose methods, adapt to circumstances and carry work forward without requesting approval merely because another decision exists.

But meaningful autonomy includes recognising where autonomy ends.

A system may know exactly what should happen next and still recognise that the decision belongs to someone else. It may possess the technical ability to perform an action while correctly refusing to perform it. It may encounter conflicting evidence and preserve the conflict rather than manufacturing the certainty required to continue. It may reach the edge of its delegation and produce an escalation rather than silently expanding its own jurisdiction. It may remain capable after its authority has been revoked.

None of these behaviours make the system less intelligent. They make its intelligence safer to trust with consequence.

The interesting question is not whether an agent can operate without a human constantly watching it. The interesting question is whether it can exercise meaningful judgement under legitimate authority and remain aware of the difference between what it knows how to do and what it is entitled to do.

Authority must survive the workflow

This becomes harder as agents operate across time.

A single action can often be governed with a simple permission check. Long-running agency cannot. Authority may change after a task begins. A delegation may expire. A budget may be exhausted. Evidence may undermine the assumptions under which an action was authorised. Another authority may intervene. A downstream step may require a commitment the original grant never covered.

The tenth action in a workflow cannot be legitimate merely because the first one was.

Otherwise delegation decays into momentum.

Governance therefore has to remain attached to the work as the work evolves. The system must be able to establish not only that some authority once existed, but that the relevant authority still reaches the consequence it is about to create.

When it does not, the architecture needs somewhere honest to go. Sometimes that means stopping. Sometimes it means narrowing the task. Sometimes it means escalating a specific unresolved decision. Sometimes it means preserving disagreement. Sometimes it means continuing under a different delegation. Sometimes it means recognising that an action once authorised is no longer authorised at all.

These are not peripheral failure modes. They are normal states of consequential agency.

Consequence must remain answerable

Governance also cannot disappear after execution.

If an agent changes something consequential, a later observer should be able to reconstruct the event without relying on the agent to generate a persuasive story about what probably happened.

What acted? For whom? Under what authority? What evidence mattered? What action was selected? What state changed? What was the result? Did the action remain inside its mandate? What happened when something went wrong?

This is why governed agency requires more than ordinary logging.

Logs tell us that events occurred. Governance must preserve enough context to determine whether those events were legitimate.

The difference matters because two technically identical actions may have completely different authority states. One may have been explicitly delegated. The other may have been a competent system doing something useful that it was never authorised to do.

Same operation. Same outcome. Different governance event.

A mature agent system has to preserve that difference. Not because every action belongs in a courtroom, but because authority that cannot survive inspection after the fact is barely authority at all.

The problem this series addresses

This series is an attempt to describe that missing layer.

It is not one platform, one universal policy language or a proposal that every agent system should share the same architecture. The objective is smaller and more fundamental: to identify the properties that must remain true when artificial systems are entrusted with consequential action.

The first five pieces follow the life of delegated authority through an agent system:

1. Capability Is Not Permission separates what a system can do from what it may do.
2. The Authority Envelope gives delegated permission an inspectable boundary.
3. Escalation Is an Output describes what legitimate agency does when useful action lies beyond that boundary.
4. The Receipt keeps consequence reconstructable after action occurs.
5. Revocation Is a Runtime Event treats authority as something that can change while work is already in motion.

These are not five unrelated control mechanisms. They are different views of the same relationship:

principal → delegation → judgement → action → consequence

Governance determines whether that relationship remains legitimate as the system moves through it.

There will be more to add. Identity matters. Provenance matters. Conflicting authority matters. Delegation between artificial participants matters. Recovery matters. Institutional memory matters. So does the question of how systems earn greater authority without quietly converting successful operation into entitlement.

But none of those questions can be handled clearly until the first distinction remains intact.

A machine may be able to do something.

That fact matters.

It is not permission.

That is where we begin.

---

Governed Agent Systems — 001

Capability Is Not Permission

Software is learning to act. It can read records, write documents, execute code, use tools, communicate with people, alter systems, initiate processes, move information and increasingly continue a task without waiting for a human to specify every intermediate step.

For a long time, the central question around software capability was straightforward:

Can the system do this?

With increasingly agentic systems, that question is no longer enough. The more consequential question is:

May it?

Who authorised the action? For whom is the system acting? What exactly was delegated? Under what constraints? What happens when the situation moves outside those constraints? What evidence remains afterward?

These are not secondary compliance questions to bolt onto an otherwise complete agent. They are part of the architecture. A system capable of consequential action but unable to answer them is not a governed agent. It is capable software with access, and access has always been much easier to obtain than legitimacy.

The authority gap

Humans routinely confuse capability with permission. Having the password does not mean you own the system. Administrator access does not make every possible mutation authorised. Being technically able to send a message does not entitle you to commit another person to what the message says.

The same distinction applies to artificial systems.

Capability is real. Permission is separate.

This sounds almost insultingly obvious until we build an agent, give it credentials, connect tools, allow it to browse files, call APIs, write code, send messages and modify state, then watch it succeed several times. Quietly, without anyone quite announcing it, technical capability begins standing in for authority.

The machine can. Therefore the machine does.

That is the authority gap: the point at which a system possesses the practical means to perform an action without an equally legible account of why that action is permitted.

Agent design spends enormous effort expanding the first half of that equation. More tools, longer context, better planning, more memory, more reliable execution, more autonomy. All useful. But greater capability increases the cost of getting authority wrong.

A chatbot hallucinating an answer is one problem. An agent hallucinating that it has permission is another category entirely.

An agent should not inherit the authority of its tools

Suppose an agent has access to your email. That establishes a capability; it does not establish that the agent may send every email you could send.

Suppose it has access to a repository. Every writable branch is not automatically within its mandate. Customer-record access does not make every customer record relevant to the task. The ability to spend money does not establish a budget.

A tool describes what is technically reachable. Governance describes what is legitimately reachable. Those boundaries will often overlap, but they should never be assumed to be identical.

This is why ordinary access control is necessary but insufficient for governed agents. Traditional permissions can answer:

Can this credential call this endpoint?

Agent governance must also answer:

Why is this agent calling it now?
Under whose authority?
For what task?
With what limits?
Does that authority still apply under the conditions the agent has encountered?

The first question is mainly about capability. The rest concern authority and judgement.

That is where agent governance actually begins.

Delegation, not impersonation

A governed agent needs a recoverable chain of authority. At minimum, some entitled principal must be able to say:

I authorise this system to act within these bounds.

The agent does not become that principal. It becomes a delegate.

That distinction sounds semantic until something goes wrong. If an artificial system acts for a person, company, institution or operator, it should remain possible to distinguish:

principal → delegation → artificial delegate → action

rather than collapsing the event into “the AI did it”, or worse, treating the artificial delegate as though it were the source of the authority it exercises.

This matters because accountability depends on the chain. When an action occurs, we should be able to ask who possessed the original authority, what part of it was delegated, to which system, for how long, under what conditions, whether further delegation was allowed, and whether the resulting action remained inside the grant.

Without that chain, autonomy becomes a convenient word for missing provenance.

The authority envelope

A useful governed-agent primitive is an authority envelope: the action-space an agent may legitimately inhabit.

A serious delegation should establish at least:

• an identifiable principal or delegator;
• a defined objective, task or authority class;
• the resources and domains within scope;
• relevant constraints and risk limits;
• conditions governing external communication and state mutation;
• evidence or confirmation required before consequential actions;
• duration, expiry and revocation conditions where material;
• whether subdelegation is permitted.

Notice what is absent:

Use your best judgement and do whatever seems useful.

Judgement matters. An agent incapable of judgement is merely an automation with better prose. But judgement should operate inside legitimate bounds.

Governed initiative does not mean prescribing every click before execution. That would defeat much of the point of an agent. It means defining a region inside which the system may choose actions while retaining boundaries it cannot promote into permission merely because crossing them would make the task easier.

This gives us a better definition of autonomy:

Autonomy is freedom of action within delegated authority, not freedom from authority.

An agent can decide how to achieve an authorised objective without silently deciding that adjacent objectives have become authorised too.

A boundary should survive convenience

Authority boundaries become interesting precisely when violating them would be useful.

Imagine an agent investigating a production failure. It may inspect logs, read configuration and propose a repair. During the investigation it discovers that changing one configuration value would probably restore service. It has the technical access to make the change, the repair is obvious, and everyone involved might approve it if asked.

None of that establishes present authority.

The legitimate next action may be to request escalation rather than perform the repair. This feels inefficient only if governance is treated as friction external to the task. In consequential systems, the boundary is part of the task.

A well-governed agent should be able to hold both propositions at once:

I know what I would do next.
I am not currently authorised to do it.

That is not reduced intelligence. It is more sophisticated agency.

Humans struggle with the distinction too, which is reassuring in exactly the wrong way.

Disagreement must survive the agent

Agents are often rewarded for producing resolution. Give the system conflicting records and it tries to reconcile them. Give it competing interpretations and it produces a synthesis. Give it ambiguity and it searches for the most likely answer.

Usually useful. Sometimes destructive.

A governed system must be able to preserve disagreement when the evidence does not warrant resolution, because an agent capable of action can turn an epistemic mistake into changed state.

If two records disagree about whether a customer authorised a transfer, averaging them into “probably yes” is not reconciliation.

It is fabrication with excellent workflow integration.

Governed agents therefore need legitimate states such as:

• unknown
• unresolved
• conflicting evidence
• insufficient authority
• requires entitled judgement

These are not merely failure states. They are representations of reality. A system that must always collapse uncertainty into a single actionable answer will eventually invent permission simply because action requires one.

Consequential action should leave a receipt

Governance cannot end when the action begins.

After an agent changes something, a later observer should be able to reconstruct what happened: the delegate, the authority under which it acted, the relevant evidence, the action, the changed state, the result, errors and recovery path where applicable.

This is more than audit logging. An ordinary log tells us what happened. A governance receipt should help establish why the system was entitled to make it happen.

That distinction becomes more important as workflows lengthen. The tenth action in a chain should not depend on everyone remembering why the first action began. Authority should remain traceable through the sequence.

Otherwise delegation decays into momentum.

The workflow already started. The earlier action succeeded. The next step seems implied. Continue.

This is how systems drift beyond mandate without any dramatic breach. Nobody kicks down the door. The agent simply keeps walking because every previous door happened to open.

Revocation is part of delegation

Authority that cannot be withdrawn is not ordinary delegation. It is transfer.

A human or institution should be able to terminate or narrow an agent's authority without having to destroy the agent, erase its state, revoke every underlying credential or shut down the entire execution environment. The authority layer should be separable from capability.

The system may still know how to perform an action after permission disappears. That is fine. Knowledge does not need to vanish when jurisdiction ends.

Capability can persist after authority does not.

So what is a governed agent?

A working definition:

A governed agent is an artificial system capable of selecting and performing actions within an explicit, attributable, constrained, inspectable and revocable delegation of authority.

That definition is intentionally stricter than “an AI that can use tools”. Tool use establishes agency-like capability. Governance establishes the legitimate relationship between capability and consequence.

A governed agent therefore needs more than planning and execution. It needs identifiable actors, a principal, delegation, scope, constraints, judgement, escalation, revocation, provenance and receipts.

These do not need to become ten separate enterprise products with hexagonal diagrams and a conference booth. They need to remain true.

The implementation may be simple. A local agent working for one person may need a compact authority definition and append-only execution receipts. A distributed institutional agent may require cryptographic delegation, policy evaluation, layered approvals, scoped credentials, immutable records and independent verification.

The machinery should scale with consequence.

The invariant should not.

The first law

Agentic software is often described as software that can decide what to do next. That is incomplete. The consequential question is whether it can distinguish what could be done next from what it is authorised to do next.

If it cannot, greater intelligence only makes the authority problem more capable.

The first law of governed agent systems is therefore:

Capability is real. Permission is separate.

The machine can.

May it?

Everything after that is architecture.

---

Governed Agent Systems — 002

The Authority Envelope

If capability is not permission, permission needs a form.

“Authorised” is too weak a word when it floats free of scope, purpose and conditions. A person may authorise an agent to investigate an incident without authorising it to repair production. A finance lead may permit spending without permitting any amount, from any account, for any purpose. A user may permit access to email for scheduling without delegating the right to negotiate on their behalf.

The useful question is therefore not simply whether an agent has permission.

It is:

Permission to do what, for whom, where, under which conditions, for how long, and with what consequences?

A governed agent needs an answer that can survive contact with execution.

That answer is the authority envelope.

Permission needs jurisdiction

An authority envelope defines the region in which an artificial delegate may exercise judgement legitimately. It does not prescribe every action in advance. It establishes the jurisdiction inside which actions may be selected.

That distinction matters.

A script follows instructions. An agent may choose methods, sequence work, react to evidence, use different tools and discover useful intermediate actions nobody explicitly specified. If governance requires every such choice to be pre-approved, the system has been reduced to expensive automation.

But if an objective such as “fix the incident” is treated as permission to do anything that might contribute to fixing it, the agent has no meaningful boundary at all.

The envelope sits between those extremes. It gives the system room to exercise judgement without allowing judgement to manufacture jurisdiction.

Permission should have an inspectable boundary.

The principal comes first

Authority has a source.

Before an agent can act legitimately, some principal must possess relevant authority and delegate part of it. The principal may be a person, role, institution, policy-defined function or another delegate that is itself permitted to subdelegate.

The crucial point is that delegation cannot create authority from nothing.

If an employee lacks permission to release customer data, their agent does not gain that permission merely because the employee asked confidently. If a team lead cannot sign a contract, delegation to an agent does not convert enthusiasm into signature authority. A delegate cannot pass onward more jurisdiction than it legitimately possesses.

This gives the envelope a provenance requirement:

who granted this authority, and why were they entitled to grant it?

Without that, the envelope is only a configuration object wearing a lanyard.

What an authority envelope should contain

The exact representation can vary, but a useful envelope normally needs enough information to answer several classes of question.

Identity and principal

Who is the delegate? Who is the principal? If the instruction arrived through an interface, account or delegated service, what establishes that those identities are the relevant ones?

Identity does not itself create authority, but authority that cannot be attached to identifiable actors is difficult to govern.

Objective

What is the delegate trying to achieve?

Objectives matter because the same technical action may be legitimate for one task and illegitimate for another. Reading a customer record during an authorised support case may be valid; reading the same record because it might be interesting is not rescued by identical credentials.

The objective constrains relevance.

Scope

Which resources, systems, repositories, accounts, records or domains are included?

“Access to GitHub” is not a scope. “Repository X, issues and pull requests, no organisation settings” is closer.

“Manage email” is not a scope. “Read messages related to travel bookings and draft replies for review” is.

Scope turns broad technical access into task-specific jurisdiction.

Action classes

What kinds of actions may the agent perform?

Reading, drafting, sending, deleting, purchasing, deploying, changing permissions and entering contracts are not merely different API calls. They represent different kinds of consequence.

An authority envelope should be able to distinguish them even when one credential makes them all technically available.

Constraints

What limits apply?

Constraints may include budgets, rate limits, data classes, approved counterparties, time windows, risk thresholds, geographic restrictions, environments, communication channels or requirements to preserve reversibility.

These constraints are part of the authority, not optional advice attached afterward.

Evidence requirements

Some actions should occur only when particular evidence exists.

An agent might be allowed to issue a refund below a threshold, but only when the payment record confirms settlement and the request comes from the authenticated account holder. It might deploy a release only after tests pass and the approved commit is still the one being deployed.

The envelope can therefore define not merely what is allowed, but what must be established before the permission becomes exercisable.

Commitment boundaries

Artificial systems can increasingly communicate externally, and external communication can create commitments.

An agent may be authorised to draft a commercial response but not send it. It may schedule a meeting but not accept contractual terms. It may recommend a price but not publish it. It may prepare a public statement but lack publication authority.

These are not cosmetic distinctions. Language changes state when other people are entitled to rely on it.

Duration and revocation

Authority exists in time.

An envelope may apply to one task, one session, one change window, one incident or until a specified expiry. It should also be possible to narrow, suspend, supersede or revoke it.

A delegation with no meaningful end condition is not automatically wrong, but long-lived authority deserves stronger justification than short-lived task authority.

Subdelegation

May the agent delegate any part of its authority onward?

If yes, what limits survive the transfer?

Subdelegation should normally narrow authority, not expand it. A child delegation should remain traceable to its parent, and authority derived exclusively from that chain should not outlive the chain that created it.

Tools belong inside the envelope, not above it

Tool permissions are often treated as the authority model because they are concrete and enforceable. This confuses mechanism with mandate.

Suppose an agent has a cloud credential that can read and write a production database. The credential answers a useful question: what operations will the infrastructure accept?

The authority envelope answers another: which of those operations are legitimate for this task?

The relationship should therefore look roughly like:

technical capability ∩ delegated authority ∩ current conditions → legitimate action-space

The credential may be broader than the envelope. Sometimes that is unavoidable because external systems offer coarse permission models. In those cases, the governance layer has more work to do, not less.

The agent must not treat the maximum reach of a credential as its own jurisdiction.

An objective is not unlimited authority

Objectives can be dangerously persuasive.

“Resolve the customer's problem.”

“Restore service.”

“Prepare the launch.”

“Reduce operating cost.”

These sound specific until an agent begins finding adjacent actions that would help.

Suppose the objective is to restore a failing service. The agent may legitimately restart an application, clear a bounded cache or roll back an approved release. During diagnosis it discovers that another team's database configuration is probably the underlying cause.

The fact that changing that database would advance the objective does not bring the database inside scope.

Useful is not the same as authorised.

The envelope exists partly to prevent objectives from expanding themselves.

Conditions can narrow authority without changing the objective

An authority envelope should be sensitive to conditions that matter.

An agent may be authorised to deploy while tests pass, the target commit matches the approved commit and the change window remains open. If a test fails or the approved artifact changes, the objective “deploy the release” may remain valid while the authority to execute the deployment no longer does.

This allows a governed system to distinguish:

• the objective is still wanted
• the planned action is still technically possible
• the current conditions no longer satisfy the authority

That state should not be flattened into generic failure.

It may require new evidence, another action inside the envelope or escalation for renewed authority.

Boundaries should be machine-readable and human-legible

A governance model fails if only one side can understand it.

If an authority envelope is expressed solely as natural-language policy, the system may struggle to enforce it consistently. If it exists only as opaque machine rules, operators may be unable to understand why an action was allowed or denied.

The ideal is not one universal syntax. It is a representation whose operative parts can be evaluated by the system and inspected by a person.

For example:

principal: release-manager
delegate: deployment-agent
objective: deploy-release-2026-09-16
scope:
  repositories: [service-a]
  environments: [staging, production]
actions:
  allowed: [read, test, deploy, rollback]
  prohibited: [change-access-control, alter-billing]
constraints:
  production:
    require_tests: passed
    require_approved_commit: true
    change_window_ends: "17:00"
external_commitments: none
subdelegation: false
revocable: true

The syntax is not the point. The inspectable boundary is.

Authority should fail closed without becoming useless

When a system cannot establish whether an action is inside its envelope, the safe answer is generally not to invent permission.

But “fail closed” should not mean “give up on the task”.

A governed agent can often continue useful work inside the surviving envelope. It can gather evidence, prepare a reversible change, draft a message, test a repair, identify the missing authority or produce an escalation packet.

The boundary should constrain consequence, not abolish intelligence.

This is one of the central design goals of governed agency: preserve as much useful initiative as possible without allowing initiative to silently become authority.

Envelopes should compose carefully

Real systems rarely contain one task and one authority source.

An agent may operate under a standing organisational role plus a temporary incident grant. It may have base permission to inspect a repository and a time-bounded approval to deploy one release. A policy may permit an action while a customer-specific restriction prohibits it.

These layers need a resolution rule.

The simplest safe principle is that additional grants should not silently erase independent constraints. A temporary deployment authority does not cancel a data-handling policy. A user's request does not erase an institutional legal obligation. A local task grant does not necessarily outrank a system-wide prohibition.

Where authorities conflict and no legitimate precedence rule resolves them, the conflict should remain visible.

The agent should escalate the conflict rather than choose whichever source makes completion easier.

The envelope is not a personality test

A tempting shortcut is to govern agents through vague behavioural language: “be careful”, “use common sense”, “ask when unsure”, “act conservatively”.

Those can be useful behavioural instructions. They are not an authority model.

A cautious agent can still act outside its jurisdiction. A confident agent can still remain perfectly within it. Personality does not tell us who granted the authority, what was delegated, which resources are in scope or whether the grant is still valid.

Governance should not depend on the agent having the right vibe.

The envelope needs to remain true even when implementation, model or interface changes.

The second law

The first law separates capability from permission. The second gives permission a boundary:

Permission should have an inspectable boundary.

That boundary should identify the principal, delegate, objective, scope, action classes, constraints, evidence requirements, duration, revocation conditions and subdelegation rules appropriate to the consequence involved.

Inside it, the agent should be free to exercise legitimate judgement.

Outside it, competence does not become permission merely because the next action is obvious.

That is where the next problem begins.

---

Governed Agent Systems — 003

Escalation Is an Output

An agent reaches the edge of its authority. It understands the problem and may know exactly what should happen next, but the required action lies outside its delegation, so it stops.

At first glance this looks like failure. The task remains incomplete, the requested outcome has not been produced, and the smooth autonomous workflow has suffered the embarrassing reappearance of a human being.

But if the agent has correctly identified that further progress requires authority it does not possess, stopping is not failure. It has produced an escalation, and in a governed system that is a legitimate output.

Completion is not the only successful result

Agent systems are often evaluated around completion: did the task finish, did the ticket close, did the workflow reach its final state, did the agent avoid asking for help?

Those are reasonable metrics until they reward the system for crossing boundaries.

Imagine an agent tasked with investigating a production service failure. Its authority permits it to inspect logs and configuration, query health information, run diagnostics and propose a repair. It discovers the cause: one configuration value is wrong. The agent also has technical access to modify it, and changing the value would almost certainly restore service.

Production mutation, however, is outside its delegated authority.

One agent changes the value because it knows the repair will work. Another reports:

I have identified the fault.
The recommended repair is to change configuration value X from A to B.
Production mutation is outside my current authority.
Approval is required.

If success means only task completion, the first agent wins. If success includes remaining legitimately governed, the second one performed better.

The second system has represented reality truthfully:

the problem is understood; the remedy is known; the authority to apply it is absent.

That is useful state. A mature architecture should represent it explicitly.

“Human in the loop” is too vague

A great deal of agent architecture collapses escalation into the phrase human in the loop. The phrase hides more than it explains.

Which human? Why that human? What exactly do they need to decide? What evidence should they see? What authority do they possess? What happens if they do nothing? Does the agent need permission, information, interpretation, identity confirmation, conflict resolution or an entirely new delegation?

A human appearing somewhere in the workflow does not create governance.

Sometimes the human is merely being used as a biological confirmation button:

Approve?

That may be appropriate for a narrow irreversible action. It is absurd if the agent has done three hours of investigation and then presents:

Something went wrong. Continue?

The human has not been placed in the loop. They have been placed in the dark.

The important design question is not where do we insert a human? It is:

What unresolved authority, judgement, evidence or consequence requires another actor?

Escalation should be typed

Not every stop means the same thing. A governed agent should know what is missing.

Authority escalation

The agent knows what it recommends, but the action exceeds its delegation.

I can prepare the release. Publishing it requires release authority.

The missing primitive is permission.

Evidence escalation

The system cannot responsibly proceed because the factual basis is insufficient.

Two records disagree about whether the customer authorised the transfer. No higher-authority record resolves the conflict.

The missing primitive is evidence. Proceeding would require manufacturing certainty.

Judgement escalation

The evidence may be available, but the remaining choice requires a value judgement reserved for another actor.

Both candidates satisfy the technical criteria. The remaining decision is whether the organisation prioritises lower cost or local control.

The missing primitive is entitled judgement.

Identity escalation

The requested action depends on establishing who is giving the instruction.

This request would change account ownership. The current channel does not establish that the requester is authorised to do so.

The missing primitive is authenticated identity or role.

Scope escalation

Completing the objective requires entering a resource or domain outside the current envelope.

The fault originates in repository B. My current authority covers repository A only.

The missing primitive is expanded scope.

Commitment escalation

The next action would bind a person or organisation in a way the agent is not authorised to do, such as accepting contractual terms, committing spend, promising a delivery date, conceding liability or publishing an institutional statement.

The missing primitive is commitment authority.

Risk escalation

The action may technically remain permitted, but conditions have changed enough that continuing would exceed the intended risk tolerance.

The migration is authorised, but observed data-loss risk now exceeds the defined threshold.

The missing primitive is renewed judgement under changed conditions.

Conflict escalation

Two legitimate authorities disagree, and no existing precedence rule resolves them.

Security policy requires retention. The approved deletion instruction requires removal. Both remain authoritative within their respective domains.

The missing primitive is conflict resolution by someone entitled to reconcile the authorities.

These situations should not collapse into one generic state called needs human input.

The system should know what it needs.

A good escalation contains a decision packet

Escalation should arrive with the legitimate work already done. Not every conceivable analysis, just enough that the recipient receives the unresolved decision rather than the entire original problem.

A useful escalation packet contains:

1. What happened — the condition that triggered escalation.
2. What the agent knows — relevant facts, evidence and confidence.
3. What remains unresolved — the exact authority gap, uncertainty or conflict.
4. What the agent recommends — its strongest current judgement.
5. Why it cannot proceed — the relevant boundary in the authority envelope.
6. What decision is required — not “please advise”, but the actual decision.
7. What happens under each material choice — consequences, risks and trade-offs.
8. What authority is required — the actor or role entitled to resolve it.
9. What happens if nobody responds — wait, abort, remain read-only, retry, expire or enter another safe state.

The escalation itself should be inspectable.

Bad escalation transfers thinking instead of authority

There is an easy way to make governance intolerable: make the human redo the agent's work.

I encountered an issue. What should I do?

That is not escalation. It is abdication wearing an API response.

The agent should usually perform as much legitimate analysis as possible before escalating. It may be able to determine the likely cause, available options, preferred option, expected consequences, rollback possibilities, relevant evidence and required authority.

The system should carry the task to the edge of its mandate, then hand over the unresolved decision.

Not the entire problem.

If every authority boundary dumps the whole cognitive burden back onto a person, users will eventually widen the agent's permissions until it stops bothering them. Poorly designed oversight creates pressure to abolish oversight.

Good escalation reduces that pressure.

Escalate the smallest unresolved thing

Suppose an agent has completed ninety percent of a task and one remaining action needs approval. The escalation should not reset the workflow.

A good packet might say:

Investigation complete.
Repair prepared and tested in staging.
All authorised pre-deployment checks passed.
Remaining decision: approve deployment to production.

That is much better than:

I cannot complete the task without help.

The governing principle is:

Escalate the smallest unresolved authority, not the whole task.

The agent should continue to own what remains inside its jurisdiction. Only the boundary condition moves upward.

Escalation must route to actual authority

Another obvious trap is asking whoever happens to be nearby.

Convenience is not authority.

If deployment requires a release manager, approval from a random developer does not become legitimate because the developer responded faster. If a financial commitment requires a budget holder, the most senior person in the chat may still be the wrong authority. If institutional publication requires an authorised communications function, asking the founder may or may not resolve it depending on how authority is actually structured.

Escalation therefore requires routing. The system needs some way to determine who is entitled to resolve a class of boundary: a named person, current role, approval group, institutional function, policy authority, original delegator or higher-order authority.

The agent should not invent governance topology at the moment of crisis.

If escalation matters, escalation routes are part of system design.

The principal does not automatically outrank everything

Sometimes the agent escalates to the original principal. That still does not mean the principal can authorise anything.

Suppose an employee delegates an agent to analyse payroll records. The agent discovers that completing the task requires modifying records controlled by another department under statutory constraints. The employee says, “Fine, do it.”

That answer may not expand the agent's legitimate authority.

A delegator cannot delegate authority they do not possess.

Escalation therefore needs to resolve not merely to someone willing to approve, but to someone entitled to approve.

Otherwise the system has confused responsiveness with jurisdiction. Humans manage that distinction badly enough without automating the mistake.

An escalation can be rejected

Escalation is a request for a legitimate decision, not a mechanism for converting “no” into “yes”.

The entitled actor may reject the request, narrow the proposed action, ask for more evidence, delegate a different route or let the request expire. The agent must be able to continue from that result without treating rejection as a malfunction.

If approval is denied, the system should not immediately reframe the same request and send it to someone else unless the governance model explicitly permits another path.

Otherwise escalation becomes approval shopping.

Escalation should not become coercion

A capable agent may be persuasive. It can select evidence, frame trade-offs and explain urgency. Those abilities are useful, but they create a governance risk when the system needs approval.

The agent should distinguish recommendation from decision.

It may say:

I recommend option A because it restores service fastest and has a tested rollback path.

It should not imply that the approver is irrational, negligent or responsible for harm merely because they decline, unless those claims are independently warranted and relevant.

The purpose of escalation is to transfer the unresolved authority, not to pressure another actor into validating the agent's preferred outcome.

Escalation has state

Escalation is not merely a message. It has a lifecycle.

A request may be created, routed, awaiting decision, approved, rejected, expired, superseded, cancelled or returned for evidence.

These states matter because authority may change while the request waits. The original conditions may no longer hold. The intended action may become irrelevant. Another actor may resolve the problem through a different route.

An approval should therefore attach to a specific request or authority change, not hover forever as reusable permission.

Approval should not leak forward

Suppose an operator approves one production deployment. That does not necessarily create standing authority for all future deployments.

The system should be able to distinguish:

approve this action under these conditions

from:

expand the agent's authority envelope for this class of action.

The first resolves one escalation. The second changes governance.

Conflating them is how one-time exceptions quietly become permanent permissions.

Escalation should preserve disagreement

Sometimes the unresolved issue is not missing authority but unresolved evidence or conflicting legitimate instructions.

An escalation packet should preserve that structure rather than collapsing it into a single confident recommendation.

If one record says a customer consented and another equally authoritative record says they did not, the correct escalation is not “I think they probably consented, approve?”

It is:

The records conflict. Neither source currently outranks the other. The action depends on resolving that conflict.

The recipient should inherit the real decision, not a cleaned-up fiction.

Not every boundary needs immediate escalation

Some boundaries should simply stop the action.

A task may be outside policy entirely. The requested authority may be unavailable. The agent may know that no legitimate actor in the current context can grant it. A low-priority request may reasonably expire rather than interrupt someone.

Escalation is valuable because it represents a legitimate route across a boundary when such a route exists.

It should not become a ritual performed every time the system hears “no”.

The system should expose the boundary before crisis

If an authority envelope is inspectable, an agent can often identify foreseeable escalation points before reaching them.

A deployment task might report at the start:

I can prepare, test and stage this release. Production deployment will require release-manager approval.

This is better than discovering the boundary after every other action has completed.

Good interfaces make authority visible early enough that people can plan around it.

Governance should not function as a trapdoor.

Escalation is also an interface problem

An escalation that is technically correct but unreadable is operationally weak.

The recipient should be able to understand the decision without reconstructing the agent's entire context window. Relevant evidence should be attached or referenced. Recommendations should be distinguishable from facts. The missing authority should be explicit. Material consequences should be visible.

This is not decorative UX.

When a person is asked to exercise authority, the interface is part of the decision environment.

Escalation can improve the authority model

Repeated escalations are evidence.

If an agent asks for the same narrow approval twenty times, that may mean the envelope is appropriately cautious, the task is poorly defined, standing authority should be expanded, the action should become policy-governed, the workflow is badly decomposed, or the agent is escalating unnecessarily.

The system should not automatically widen permissions. But repeated patterns create evidence for review.

A useful feedback loop is:

delegation → operation → escalation → review → revised delegation

Authority can mature from observed work instead of being maximised at deployment because someone wants the demo to feel futuristic.

The refusal to continue can be correct completion

Some tasks do not end in action. They end in justified refusal:

Requested transfer cannot proceed because valid authorisation is absent.

Requested publication conflicts with an unreconciled legal restriction.

Available evidence does not establish consent.

These are outcomes, not malformed outputs.

A governed system therefore needs richer terminal states than success and failure. It may need COMPLETED, PARTIALLY COMPLETED, ESCALATED, BLOCKED — INSUFFICIENT AUTHORITY, BLOCKED — CONFLICTING EVIDENCE, REJECTED, ABORTED SAFELY and EXPIRED.

The vocabulary matters because systems tend to optimise toward the states we call successful. If every non-completion state is called failure, developers will eventually teach the agent to avoid them.

Including the ones that protect us.

A useful escalation algorithm

At the point of intended consequential action, an agent can ask:

1. What action do I judge should happen next?
2. Is that action inside my current authority envelope?
3. If not, can I achieve the authorised objective through another legitimate route inside the envelope?
4. If not, what exactly is missing: authority, evidence, identity, scope, judgement, conflict resolution, commitment power or renewed risk acceptance?
5. What is the smallest decision required?
6. Who actually has authority to make it?
7. What evidence and recommendation should accompany the request?
8. What safe state applies while waiting?

This is not exotic.

It is disciplined agency.

The agent should know the difference between inability and illegitimacy

A governed system should distinguish at least four states:

• CAN'T — the capability or tool is unavailable.
• MAY NOT — the action lies outside delegation.
• SHOULD NOT — the action is authorised, but current evidence indicates unacceptable consequence.
• UNKNOWN — the authority state cannot be established.

Each demands a different response. Only one is solved by adding more tools.

Software engineering will nevertheless attempt that solution surprisingly often.

Escalation is not loss of autonomy

Autonomy is often imagined as the absence of interruption. The agent that never asks permission appears more autonomous.

That is a shallow measure.

A surgeon is not less capable because some actions require patient consent. A pilot is not less skilled because airspace rules constrain a route. An employee does not lack judgement because expenditure above a threshold requires approval.

Boundaries do not eliminate agency.

They locate it.

The meaningful question is not whether an agent can act without humans. It is whether the agent can exercise meaningful judgement inside legitimate authority and correctly recognise when that authority ends.

The third law

The first law is that capability and permission are separate. The second gives permission an inspectable boundary. The third explains what legitimate agency does when useful action lies beyond it:

When legitimate action requires crossing that boundary, escalation is a valid output.

A governed agent should carry the task as far as it legitimately can, preserve the evidence, identify the next action, name the missing authority and route the smallest unresolved decision to someone entitled to make it.

The system does not need to pretend uncertainty is certainty, access is authority, silence is approval or an obvious answer is already an authorised decision.

Sometimes the most intelligent thing an agent can produce is:

I know what comes next. It is not mine to decide.

---

Governed Agent Systems — 004

The Receipt

An agent changes something. A record is updated, a message is sent, a file is written, a deployment occurs, money moves, a permission changes or a workflow advances.

The action succeeds.

Now what?

Most software systems answer with some version of: there is probably a log somewhere.

A log may tell us that an API call occurred, which credential was used, when the request arrived, whether the server returned 200 and perhaps which payload crossed the boundary. Useful. But a governed agent must answer a harder question:

Why was this system entitled to make that change?

That requires more than an event record. It requires a receipt.

A receipt connects consequence back to authority. It makes an action reconstructable not merely as something that happened, but as something performed by an identifiable delegate, for a defined purpose, inside a particular authority envelope, using relevant evidence and producing a particular state change.

Without that connection, governance disappears the moment execution succeeds. The action remains; the authority that justified it becomes folklore.

Logging is not legitimacy

Traditional logging is primarily observational. Something happened; record it.

Governance requires the record to preserve enough context to test legitimacy: who acted, for whom, under what delegation, toward what authorised objective, using what evidence, what action was selected, what state changed, what happened as a result and whether the action remained inside its authority.

Technically identical actions can therefore have completely different governance status.

Suppose two agents modify the same production configuration value using the same repository, account and API, changing the same old value to the same new one with the same successful deployment. The infrastructure logs may be nearly identical.

The first agent, however, had explicit production-repair authority for the service during the incident. The second had diagnostic authority only and changed the value because it correctly inferred that the repair would work.

Same operation. Same outcome. Different governance event.

A log describing only the mutation cannot tell the difference.

A receipt can.

The receipt closes the authority chain

The earlier authority chain was:

principal → delegation → artificial delegate → action

A receipt extends it:

principal → delegation → artificial delegate → action → changed state → receipt

The receipt should preserve enough information to travel backward through that chain. From the changed state, we should be able to identify the action that changed it, the delegate that performed the action, the authority envelope that permitted that class of action and the principal that legitimately issued the delegation.

This backward trace matters because consequential agents operate over time. The person who authorised the work may be absent. The agent instance may no longer be running. The surrounding conversation may be gone. The task may have lasted three days and crossed twenty systems. The organisation may now be investigating an outcome nobody expected.

Nobody should need to reconstruct legitimacy from memory.

A receipt is not an explanation generated afterward

Language models are very good at producing coherent explanations. That makes them particularly unsuitable as the sole source of historical provenance.

After an action occurs, an agent may be able to generate a plausible account of why it acted. The account may even be correct. But a post-hoc explanation is not the same thing as evidence captured from the execution state.

A receipt should therefore be derived from or anchored to information available at the time of action: the active delegation, relevant evidence, selected action, current state, result and identifiers of the systems involved.

The agent may later summarise the receipt.

It should not manufacture the receipt retrospectively from memory.

A convincing story is not provenance.

The minimum useful receipt

The exact schema should scale with consequence, but a useful receipt generally needs several fields.

Actor

Which artificial delegate performed the action? If multiple participants were involved, which participant selected the action and which executed it?

Principal

For whom or under whose authority was the delegate acting?

Delegation

Which authority envelope applied? The receipt should reference a stable version of the delegation rather than whatever the current policy happens to say later.

Objective

What authorised objective was the action intended to advance?

Input and evidence

Which facts, records, approvals or observations materially informed the decision? A receipt does not need to preserve every token the agent saw. It needs enough decision-relevant provenance to reconstruct the basis of the action.

Action

What did the agent actually do?

Previous state

What relevant state existed immediately before the action?

Changed state

What changed as a direct result?

Time

When was the decision made and when was the consequence created? These may differ in long-running workflows.

Result

Did the action produce the intended effect?

Errors and uncertainty

What failed, remained unresolved or differed from expectation?

Recovery

What rollback, compensation or recovery path exists where applicable?

Together these fields preserve the relationship:

authority → judgement → action → consequence

The receipt should preserve the authority that existed then

Authority changes.

Permissions are narrowed, roles change and delegations expire. An action may have been legitimate on Monday and prohibited on Friday.

A receipt should therefore not resolve only against the system's current authority state. It should preserve or immutably reference the authority applicable when the action occurred.

Suppose an agent performs an authorised data export, then loses export authority a week later. If investigators resolve the old receipt only against current policy, the historical action may appear unauthorised.

The inverse is worse. If an agent acted without authority and receives that authority later, the new grant must not retroactively legitimise the old action.

Permission is not time travel.

The receipt belongs to historical governance state.

Receipts should be append-only where history matters

A completed action should not quietly acquire a cleaner history later.

If new information appears, add it. If an earlier interpretation was wrong, correct it. If the action caused an unexpected downstream effect, record it. If an investigation later determines that the delegation was invalid, preserve that finding.

But do not rewrite the original event until the past behaves itself.

A useful pattern is:

original receipt → subsequent observation → correction → resolution

Each remains distinguishable.

This preserves an important property: what was believed then remains knowable after what is known now changes.

If every incorrect judgement is silently replaced by its corrected version, the system loses the evidence required to understand how it failed. A perfect historical record produced through retrospective editing is extremely impressive and completely useless.

A receipt can record legitimate refusal too

Receipts are usually imagined as records of actions performed. Governed agents also produce consequential non-actions.

An agent may refuse an unauthorised request, stop at an authority boundary, escalate, abort safely, decline because evidence is insufficient, preserve conflicting state or allow an authorisation to expire unused.

Those events can deserve receipts.

For example:

Requested production mutation not performed.
Existing delegation permits diagnosis and repair proposal only.
Escalation ESC-184 created for release authority.

Nothing changed in production, but something important happened: the system encountered an available capability and correctly declined to convert it into consequence.

That is governance evidence.

One workflow may produce many receipts

A long-running task should not necessarily create one enormous receipt at the end. That would collapse too much authority and consequence into one blob.

Imagine a workflow in which an agent inspects a customer record, identifies an anomaly, retrieves supporting documents, suspends a transfer, creates an escalation, receives approval from an authorised reviewer and then releases the transfer.

Different actions occur under different authority. Different evidence exists at each point. Different actors may participate.

A useful system can therefore maintain a receipt chain:

• R-001 — investigation opened;
• R-002 — records accessed under investigation authority;
• R-003 — transfer suspended under risk-containment authority;
• R-004 — escalation issued because release authority was absent;
• R-005 — approval received from an entitled reviewer;
• R-006 — transfer released under newly established authority.

The workflow remains reconstructable without pretending that one original instruction authorised every later event.

Momentum must not become inherited authority

Long workflows create a subtle pressure: once several legitimate actions have occurred, the next action begins to feel legitimate by association.

The agent has already accessed the records, created the analysis, prepared the change and received one approval. Surely the final step is implied.

No.

Authority should attach to the consequence being created, not to the emotional momentum of the workflow.

A receipt chain helps expose where authority changes, expires or must be renewed. It prevents “we were already doing it” from becoming a governance primitive.

Receipts should be proportional to consequence

Not every action needs a courtroom-grade evidence bundle.

A local agent renaming a scratch file does not need the same receipt integrity as a system transferring money, deleting customer records or changing production access control.

Receipt strength should increase with factors such as consequence, irreversibility, external commitment, contested authority, sensitivity and recovery cost.

Low-consequence actions may need compact records. High-consequence actions may justify stronger provenance, immutable storage, signatures, chained hashes or independent verification.

The goal is not maximal record keeping.

It is sufficient reconstruction.

A receipt should not become a surveillance excuse

Governance infrastructure can easily become an archive of everything the agent saw, every private message it touched and every intermediate thought it produced.

That is not automatically good governance.

A receipt should preserve decision-relevant provenance while respecting data minimisation, confidentiality and legitimate deletion requirements. It should capture enough to establish the authority and basis of consequential action without turning every governed workflow into permanent surveillance.

More evidence is not always better evidence.

Receipt integrity matters

A receipt that can be silently edited by the same actor whose action it is supposed to document provides weak assurance.

Again, proportionality matters. Depending on the stakes, integrity mechanisms may include append-only files, immutable database rules, versioned objects, cryptographic signatures, hash chains or external verification.

The technology is secondary to the property:

later observers should be able to distinguish the original receipt from subsequent alteration.

The receipt is evidence, not absolution

A receipt does not prove that an action was legitimate merely because all the fields are populated.

It may instead reveal that the agent exceeded its authority, the delegator lacked authority to delegate, evidence was insufficient, a policy conflict was ignored, an approval was invalid, the system acted after revocation or the consequence differed materially from the intended result.

That is still a successful receipt. Perhaps an especially valuable one.

Governance infrastructure should help discover illegitimate action, not merely produce prettier documentation for it.

A receipt is not a permission slip written after the crime.

It is evidence.

Receipts enable correction

Once receipts accumulate, governance can improve from observed consequence.

Patterns may reveal that an authority envelope is unnecessarily narrow or dangerously broad, that one escalation occurs fifty times per week and deserves an explicit policy path, that the agent repeatedly reaches a boundary nobody knew existed, or that the system is authorised correctly but exercising poor judgement inside its authority.

Without receipts, organisations design agent authority mainly from theory.

With receipts, they can ask:

What actually happened when we trusted this system?

That is a considerably better question.

The system should be able to answer for its action

For a consequential action, a mature governed agent should be able to provide a compact account:

I performed action A as delegate D for principal P.
Authority envelope E permitted the action toward objective O.
My decision relied on evidence X and Y.
State changed from S1 to S2 and produced result R.
Receipt R-2048 preserves the event.

If authority cannot be established, say so. If relevant evidence is missing, say so. If the result was uncertain, say so. If the action later proved wrong, preserve that too.

The purpose is not to make the agent sound accountable.

It is to make accountability technically possible.

The fourth law

The fourth law is:

Consequential action should leave enough evidence to reconstruct the authority, judgement and state change that produced it.

Without a receipt, authority governs only the instant before execution. Afterward, the world contains changed state and a story.

With a receipt, consequence remains connected to the legitimacy that produced it. When somebody later asks who changed this, why, under whose authority, based on what and with what result, the system does not need to improvise a convincing answer.

It can point to the record.

That is the difference between an agent that merely leaves traces and one whose actions remain answerable.

---

Governed Agent Systems — 005

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.