Identity
Who or what is acting, resolvable to a single accountable subject rather than a shared service account.
For decades, authority followed the application.
Intelligence can live anywhere. Authority cannot.
Picture a fairly normal company eighteen months from now. Sales has agents operating through Salesforce. Finance has agents working across ERP and procurement. Developers use coding agents with access to repositories and environments. Teams have built their own. The software the company buys arrives with agents already inside it. Some workflows run on one vendor's models, some on another, several on both within the same process.
The starting position
That is not an exotic architecture. It is the default.
Nothing in that picture requires a strategy, a platform decision or a transformation programme. It is what happens when capable agents ship inside the tools a company already owns and the people using them are allowed to get on with their work. Most organisations will arrive there without ever choosing to.
And then somebody asks the only question that matters.
Who is actually allowed to do what?
It sounds like a governance question. It is not. It is an operating question, and it has a specific structural cause: an employee may ask an AI in one system to perform work in another. An agent may hand part of the task to a second agent. An orchestration layer may discover a tool at run time that nobody named in advance. The model doing the reasoning may change without a single business system changing at all.
So authority can no longer simply follow the application, because the application is no longer where the work is decided.
What actually changed
The chain got longer, and the person left it early.
For thirty years enterprise authority was a short, legible sequence. A person held a role, the role granted access to an application, and the application enforced a permission. Every hop was inside one system of record, and the person was demonstrably present at the point the action happened.
Then · authority follows the application
- Person
- Role
- Application
- Permission
The person is present at every hop. Whose permission is being spent is never in question, because there is only one candidate.
Now · authority is spent somewhere down the chain
- Person
- Agent
- Agent
- Tool
- API
- Business system
The person requesting the outcome may never touch the system in which the consequential action occurs. Everything to the right of the mark is still spending their authority, without them.
This is a different problem from deciding how much authority an agent should have. That question, the one about consequence, reversibility and value at risk, is the subject of essay 003, and it is answered vertically: how high up the scale does this agent get to operate. The question here runs the other way. Not how much, but whose, and for how many hops after the human stopped watching.
The operating questions
Seven questions most operating models cannot answer yet.
Q·01
Whose authority is the agent exercising?
Q·02
If I can approve £10,000 and delegate the task, does the agent inherit £10,000?
Q·03
Can it delegate that authority again?
Q·04
If a second agent completes the work, whose authority is it spending?
Q·05
Does the authority persist after I leave the workflow?
Q·06
What if the AI takes an action I never requested, to reach the objective I did?
Q·07
Where does delegated authority stop?
None of those are primarily questions about AI. They are questions about how the company operates, and they were answerable a decade ago only because the chain was short enough that nobody had to ask.
Intelligence can increasingly live anywhere. Authority cannot.
What stays still
Six things that do not move, whichever AI does the work.
A company can let almost everything else float. These are the pieces that have to resolve to the same answer no matter which agent, model or vendor is holding the task at the time.
Authority
What that subject may do, what it may pass on, and the point at which passing it on stops.
Business rules
The constraints that apply to the action itself, independent of who or what requested it.
Authoritative state
The one version of the facts the business will act on when two systems disagree.
Human decision rights
The decisions a person must make, held as a property of the decision rather than of the tool.
Evidence
What was retained, in a form that survives the agent, the model and the vendor being replaced.
The operating model
Federate intelligence. Anchor authority.
The instinct when this problem lands is to centralise the AI. That is the wrong move, and it fails for the same reason centralising software procurement failed: it makes the organisation slower without making it safer. The intelligence is not the thing that needs holding still.
Federate the intelligence
Let different functions use the AI that works for them. Let models change. Let specialist agents emerge where the work is specialised. Let teams build. None of that has to be governed centrally to be governed well.
Anchor the authority
Make a small number of enterprise rules invariant, and enforce them in one place, so that the answer does not depend on which agent happens to be holding the task when the question is asked.
The seven sentences the anchor has to be able to say
- This is who may act.
- This is what they may delegate.
- This is the authoritative state.
- This action requires human authority.
- This policy always applies.
- This is the evidence we retain.
- This is where machine authority ends.
Those are not aspirations. Each one is a sentence a system has to be able to answer at run time, in the middle of a workflow, without a person present to interpret it. Essay 008 made the general case that policy is becoming executable. Authority is the specific policy that has to survive it first, because it is the one every other rule depends on.
Where Praxis stands
Do not begin with an access model. Begin with one workflow where an agent already acts on something consequential, and follow a single instruction the whole way down: who asked, what authority they held, which hop spent it, what the agent decided on its own, where a person would have had to be, and what evidence exists now that it happened.
Most organisations discover two things doing that once. The authority being spent belongs to somebody who has no idea it is being spent, and the chain has more hops in it than anyone drew on the diagram. Both are cheaper to find on one workflow than across forty.
The uncomfortable version of this is that federating intelligence is the easy half and most companies will do it by accident. Anchoring authority is deliberate work that produces nothing visible on the day it is finished, which is exactly why it tends to happen after the first incident rather than before it.
Let the intelligence go wherever it is useful. Decide, once and in one place, where its authority ends.
Point of View
← All essays
Begin
Whose authority is your agent spending?
One conversation, no pitch deck. Bring a workflow where an agent already acts, and we will trace a single instruction from the person who asked to the system that did it.