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.