Decision Rights and Delegated Authority

Execution is not authority.

A machine may be capable of performing an action.

That does not mean it should be allowed to perform it.

An agent may be capable of issuing a refund.

The technical question

Whether the system can execute the action.

The operating model question

Whether the enterprise has authorized it to do so.

Those questions have to remain separate.

Traditional enterprises already understand this distinction for people.

An employee may know how to approve an expense without having the authority to approve it.

An engineer may know how to change a production environment without having unrestricted permission to do so.

A manager may understand a compensation decision without possessing the authority to make it alone.

Capability and authority are separated through roles, policies, approval limits, access controls and accountability structures.

Machine actors require the same distinction.

But the problem is harder.

1. Agents can act at machine speed.
2. →They can operate continuously.
3. →They can cross systems.
4. →They can invoke tools.
5. →They can perform many actions before a human could inspect each one.
6. →They can receive new context during execution.

And the path they take toward an objective may not be specified in advance.

Once machines move from recommending actions to taking them, decision rights become part of the execution architecture.

The AI Native enterprise therefore needs an explicit answer to a new question:

What authority can be delegated to a machine?

Every consequential workflow contains decisions.

1. Approve.
2. →Reject.
3. →Escalate.
4. →Purchase.
5. →Release.
6. →Change.
7. →Communicate.
8. →Commit.
9. →Stop.
10. →Continue.

Traditional organizations distribute these rights among people.

Some decisions belong to employees.

Some belong to managers.

Some require specialists.

Some require committees.

Some require executives.

Some require boards.

Some cannot be delegated because law, regulation or institutional policy assigns accountability to a particular actor.

Decision rights determine who can make which decision under which conditions.

AI does not remove this architecture.

It introduces a new class of actor into it.

The enterprise now has to decide whether a machine can:

• observe
• recommend
• prepare
• decide
• execute
• escalate

and under what conditions each right applies.

This is more precise than asking whether an agent is autonomous.

Autonomy is not one thing.

An agent may have broad freedom to research while having no authority to transact.

It may prepare a decision but require human approval.

It may execute transactions below a threshold and escalate those above it.

It may operate without approval under normal conditions but lose authority when confidence falls, data conflicts or risk conditions change.

The relevant design object is therefore not autonomy in the abstract.

It is the distribution of decision rights.

The need for this architecture is becoming visible in the market.

In February 2026, the U.S. National Institute of Standards and Technology's National Cybersecurity Center of Excellence published a concept paper focused on identity and authorization for software and AI agents.

The premise is straightforward.

Agents increasingly need access to data, tools and applications in order to perform useful work.

That access creates risk.

NIST identifies agent identification, authorization, auditing and nonrepudiation as areas requiring stronger technical practice as agentic systems enter enterprise environments.

The World Economic Forum reached a related conclusion in its 2026 playbook for trusted agent adoption.

Its proposed Agent Capability and Authorization Profile links what an agent can do with what it is authorized to do, the conditions under which that authority applies and the controls required around execution.

Microsoft is moving the same problem into enterprise infrastructure.

Its agent identity architecture treats agents as distinct identities that can receive governed access to enterprise resources. Microsoft also states that organizations remain responsible for identity, least privilege, authorization of actions, human oversight and accountability for agent behavior.

The technical implementations differ.

The underlying operating problem is the same.

This distinction is critical.

An agent may have access to a system because it needs information from that system.

That does not mean it should possess every action the system makes technically possible.

A customer service agent may need access to customer history.

It may need the ability to calculate a refund.

It may even need the ability to issue a refund.

But those are three different permissions.

Traditional enterprise software often bundles these boundaries through application roles.

Agentic execution requires more precision because a machine can move from information to action without the natural pause created by a person navigating the system.

An agent that can read an invoice does not necessarily need permission to approve it.

An agent that can inspect production does not necessarily need permission to modify it.

An agent that can prepare a customer communication does not necessarily need permission to send it.

An agent that can identify a security issue does not necessarily need permission to disable an account.

The architecture must separate what the machine can see from what the machine can do.

And it must separate what the machine can technically do from what the enterprise has authorized it to do in this workflow.

Delegated authority should not be expressed as a binary permission.

Real enterprise authority is conditional.

A manager may approve spending up to a threshold.

An employee may sign an agreement only within defined terms.

An engineer may deploy to production after required controls pass.

A customer service representative may resolve a case within policy but escalate exceptions.

Machine authority should be designed the same way.

An authority envelope defines the conditions inside which a machine can act without seeking additional approval.

At minimum, the envelope can include:

01

Action

What is the agent allowed to do?

02

Object

What data, account, system, customer, transaction or resource may it act upon?

03

Threshold

What financial, operational or risk limit applies?

04

Context

Under what workflow or business condition does the authority exist?

05

Evidence

What information must be available before the action can be taken?

06

Confidence

What level of certainty or evaluation must be satisfied?

07

Time

How long does the authority remain valid?

08

Escalation

What condition causes authority to return to a human or another control point?

09

Accountability

Which human or institutional owner remains responsible for the delegated authority?

This changes the design of agent autonomy.

The agent is not simply autonomous.

It is autonomous inside an envelope.

The authority envelope turns autonomy into an explicit operating construct.

It answers not simply whether the machine can act.

It answers:

Where does its right to act begin, and where does it end?

A powerful model does not need powerful permissions.

This distinction becomes more important as general purpose models become capable across many domains.

The same underlying model may be able to:

• write software
• analyze contracts
• interact with customers
• query financial systems
• modify infrastructure
• prepare hiring decisions
• research competitors

and operate enterprise applications.

The model's capability may be broad.

The agent's authority should not be.

Authority belongs to the operating role the machine is performing.

A procurement agent may receive authority to request supplier information but not approve payment.

A software agent may receive authority to create a pull request but not deploy directly to production.

A finance agent may reconcile transactions but require approval to post an adjustment above a defined amount.

A customer agent may resolve routine cases but escalate cases involving regulatory complaints.

The enterprise therefore should not ask:

That is the machine equivalent of least privilege.

It is also an operating model principle.

Authority cannot be governed if the enterprise cannot identify the actor using it.

Human enterprises already rely on identity.

1. Employees authenticate.
2. →Roles are assigned.
3. →Permissions are granted.
4. →Actions are logged.
5. →Access changes when responsibilities change.
6. →Credentials expire.
7. →Departing employees lose access.

Machine actors need an equivalent lifecycle.

Microsoft's 2026 agent identity architecture reflects this requirement by assigning distinct identities to agents and linking those identities to human sponsors responsible for their access lifecycle.

NIST's work on software and AI agent identity addresses the same problem from a standards perspective.

The significance extends beyond cybersecurity.

Identity creates the foundation for organizational accountability.

The enterprise needs to know:

1. 01Which agent acted?
2. 02Which version?
3. 03On whose behalf?
4. 04Under which role?
5. 05Using which authority?
6. 06Against which resource?
7. 07At what time?
8. 08With what result?

Without that information, delegated authority becomes difficult to distinguish from uncontrolled access.

One of the simplest ways to deploy an agent is to let it act using a human user's credentials or permissions.

That can be convenient.

It can also collapse an important boundary.

If the machine acts entirely as the person, the enterprise may lose the ability to distinguish human action from machine action.

It may also give the machine every permission the human possesses, even when the workflow requires only a subset.

That creates an authority problem.

The agent should be able to act on behalf of a person without becoming indistinguishable from that person.

The execution record should preserve both identities.

The principal

Who delegated the authority?

The machine actor

Who executed the action?

That distinction allows the enterprise to reason about delegation.

Fritzie authorized Agent A to perform Action B within Boundary C.

The agent executed the action.

The enterprise can reconstruct both facts.

This is more than an audit requirement.

It is the beginning of a machine accountability chain.

Not every decision should be governed through the same mechanism.

A useful operating model distinguishes several levels of machine participation.

01

Observe

The machine can access information and monitor conditions.

It cannot recommend, decide or act.

02

Recommend

The machine can interpret information and propose an action.

A human retains the decision.

03

Prepare

The machine can assemble the action for execution.

A human must authorize it before it occurs.

04

Decide

The machine can choose the action within a defined decision domain.

Execution may still require a separate control.

05

Execute

The machine can perform the authorized action.

06

Escalate

The machine can determine that the condition exceeds its authority and transfer the decision to another actor.

These rights can be combined differently across a workflow.

An agent may observe and recommend in one part of the process.

Prepare but not decide in another.

Decide and execute routine cases.

Escalate everything outside its envelope.

This is how autonomy becomes granular.

The ladder does not imply that every agent should move upward.

A machine may have extensive capability while intentionally remaining at Recommend.

Another may operate at Execute for a narrow class of low consequence transactions.

The appropriate level depends on the workflow, consequence, reversibility, evidence, control environment and economics.

Human approval is often treated as the safe default.

But Chapter 04 established that human presence alone does not create control.

The same applies to delegated authority.

If every machine action requires human approval, the machine may increase execution capacity while leaving decision capacity unchanged.

The result can be an acceptance bottleneck.

1. Agents prepare more work.
2. →Humans receive more requests.
3. →Queues grow.
4. →Approval becomes faster but shallower.

Eventually, the organization either constrains machine execution or humans begin approving without meaningful review.

Neither produces the intended operating leverage.

The alternative is not to remove human authority.

It is to place human authority where it creates value.

Routine, bounded, observable and reversible decisions may support delegated machine authority.

Ambiguous, consequential or irreversible decisions may remain human.

Some workflows may use thresholds.

Others may use risk tiers.

Others may require human approval only when the evidence conflicts or the system leaves its expected operating range.

The design problem is to preserve human control without forcing every unit of machine execution through a human decision.

Delegation is incomplete without a mechanism for giving authority back.

An agent needs to know not only what it can do.

It needs to know when it should stop.

That condition may occur when:

• confidence falls
• required evidence is missing
• systems disagree
• financial exposure exceeds a threshold
• policy conflicts
• the case is novel
• the requested action is irreversible
• a customer challenges the decision
• an external condition changes
• a control fails

or the agent encounters a situation outside its defined domain.

Escalation is therefore not an exception bolted onto autonomous execution.

It is part of the authority design.

A well designed machine actor understands the boundary of its mandate.

The operating model must make that boundary explicit.

Human organizations often treat permission as persistent.

A person receives access because of a role and keeps it until the role changes.

Agentic execution creates reasons to make authority more temporary.

An agent may need permission only:

• for one workflow
• for one transaction
• for one customer
• for one period
• for one incident
• for one objective

or until a particular condition changes.

Persistent machine authority increases the surface on which failure or misuse can occur.

Temporary authority can narrow it.

The enterprise can therefore design authority that expires.

New execution requires new authorization or a renewed policy condition.

This makes delegated authority more contextual.

It also aligns permission more closely with the work that justified it.

When a manager delegates a decision to an employee, the organization still knows where accountability sits.

When an executive delegates spending authority, the enterprise does not treat the transaction as ownerless.

When a board delegates operating authority to management, the delegation exists inside a larger governance structure.

Machine delegation needs the same principle.

An agent may execute the action.

It may make the bounded decision.

It may operate without human approval at the moment of execution.

But the enterprise still needs an accountable human or institutional owner for the authority that made the action possible.

This creates a chain.

1. 01A person or governing body authorizes an operating objective.
2. 02Authority is assigned to a role.
3. 03Some portion of that authority is delegated to a machine actor.
4. 04The machine executes within defined boundaries.
5. 05The execution is observed.
6. 06Exceptions return to an accountable actor.
7. 07The authority can be changed or withdrawn.

The chain must remain intact even when no human participates in the individual transaction.

That is how machine autonomy remains inside institutional accountability.

The AI Native enterprise needs to be able to reconstruct not only what happened, but why the machine had the right to make it happen.

For a consequential machine action, the enterprise should be able to answer:

1. 01Who owns the workflow?
2. 02Who authorized machine participation?
3. 03Which machine actor executed the action?
4. 04What decision right had been delegated?
5. 05What authority envelope applied?
6. 06What evidence was available?
7. 07Which policy governed the action?
8. 08What controls were evaluated?
9. 09What action occurred?
10. 10What outcome followed?
11. 11Was escalation required?
12. 12Who remained accountable?

This is different from a technical log.

A technical log may tell the enterprise which service called which application.

An accountability chain explains the institutional basis for the action.

The distinction matters.

A machine action can be technically valid and still be organizationally unauthorized.

It can possess the credentials required to perform an action without possessing a legitimate decision right to perform it.

The AI Native control system has to preserve both.

Technical permission

The system allows the action.

Institutional authority

The enterprise authorized the action.

Delegation therefore forms a closed control loop.

Traditional governance often sits outside execution.

1. Policies are written.
2. →Employees are trained.
3. →Controls are reviewed.
4. →Audits test whether the organization complied.

That model becomes weaker when machine actors can perform thousands of actions at machine speed.

The control cannot depend only on a person remembering the policy before acting.

Policy increasingly has to enter the execution path.

If an agent cannot spend more than a defined amount, the system should enforce the limit.

If particular customer data cannot leave a jurisdiction, the workflow should prevent the action.

If an agent requires human approval before modifying a production environment, the execution architecture should enforce that gate.

If an action requires two independent conditions to be satisfied, the machine should not be able to bypass them because its reasoning concluded that doing so would help achieve the objective.

Telling the agent

The policy is communicated to the machine.

Making it operative

The policy is part of the operating environment.

Prompts can communicate intent.

They should not carry the entire burden of institutional control.

The AI Native enterprise needs controls that exist outside the reasoning of the machine actor.

Traditional access control often asks whether a user has permission to access a resource.

Agentic execution requires a more contextual question.

Is this actor authorized to perform this action, against this resource, for this objective, under these conditions, at this moment?

The answer may depend on more than identity.

It may depend on:

• workflow state
• transaction value
• customer classification
• data sensitivity
• risk level
• location
• time
• prior actions
• available evidence
• model confidence
• the presence of required approval

or whether another control has already failed.

Authority therefore becomes dynamic.

An agent may possess a general role while individual actions remain subject to runtime authorization.

This allows the enterprise to separate broad capability from narrow permission.

The machine can know how to perform many actions.

The control system determines which action is permitted now.

That is a more durable model for enterprise autonomy than granting broad standing permissions to increasingly capable agents.

Human organizations often separate the decision from the evidence that produced it.

A manager approves.

A system records the approval.

The reasoning may remain in an email, a meeting or the manager's head.

Machine execution creates an opportunity to improve this.

A consequential machine decision can carry an evidence record.

1. 01What information was considered?
2. 02Which policy applied?
3. 03What constraints were active?
4. 04What alternatives were rejected?
5. 05What evaluation was performed?
6. 06What confidence or uncertainty was present?
7. 07What authority permitted the action?

The purpose is not to preserve every token of model reasoning.

Nor should enterprises assume that internal model reasoning provides a reliable explanation of why an action occurred.

The useful evidence is operational.

That record gives the enterprise something it can inspect.

It supports audit.

It supports investigation.

It supports evaluation.

And it creates the evidence required to decide whether the authority envelope remains appropriate.

Authority should not be granted and forgotten.

A machine actor can remain inside its formal permissions while producing poor outcomes.

It can make technically valid decisions that create unacceptable error rates.

It can consume far more resources than expected.

It can escalate too often.

It can fail to escalate when it should.

It can produce patterns of action that reveal a flaw in the workflow design.

The enterprise therefore needs to observe not only whether the machine violated a rule.

It needs to observe whether delegated authority is producing the intended operating result.

That means measuring:

• decision quality
• execution quality
• exception rate
• escalation rate
• human override
• failure patterns
• cost
• latency
• outcome quality
• control violations

and changes in the environment in which the authority was granted.

The authority envelope is a hypothesis.

The enterprise is asserting that this machine actor can exercise these rights under these conditions and produce an acceptable result.

1. Authority
2. →Execution
3. →Evidence
4. →Observation
5. →Authority change

Execution tests that hypothesis.

Observation determines whether it remains true.

Enterprises will face pressure to increase machine autonomy.

As systems improve, requiring human approval for every action will become economically difficult to justify.

But autonomy should not expand because the technology category has become more fashionable.

It should expand because evidence supports the delegation.

A machine may begin at Recommend.

Performance is observed.

The enterprise develops confidence in a bounded class of decisions.

The machine moves to Prepare.

Controls improve.

Evaluation demonstrates reliable performance.

A narrow class of decisions moves to Decide.

Execution remains separately controlled.

Later, some actions may move to Execute inside a defined envelope.

The progression is not mandatory.

Some decisions may remain human indefinitely.

Some may move rapidly.

Some may move forward and later move back.

The principle is more important than the direction.

Authority should follow evidence.

Delegated authority needs a reverse path.

A machine that performed well yesterday may encounter a changed environment tomorrow.

• The underlying model may change.
• A data source may degrade.
• A policy may change.
• A new fraud pattern may appear.
• A workflow dependency may fail.
• An evaluation may reveal a systematic error.
• A regulator may change the permissible operating boundary.

The enterprise needs the ability to narrow or revoke authority without redesigning the entire workflow.

That may mean:

• lowering a financial threshold
• requiring additional evidence
• increasing human review
• disabling a tool
• removing access to a resource
• changing the escalation condition
• moving execution back to Prepare

or stopping the machine actor altogether.

Authority is therefore not a permanent property of the agent.

It is a configurable property of the operating system.

Mixed execution systems can contain many actors.

1. Humans.
2. →Agents.
3. →Specialized agents.
4. →Supervisory agents.
5. →Applications.
6. →Policy engines.
7. →External services.

Those actors may not always agree.

A customer agent may determine that a refund is appropriate.

A fraud control may block it.

A revenue policy may permit it.

A financial threshold may require human approval.

A supervisory agent may detect conflicting evidence.

The operating model needs precedence.

1. 01Which authority wins?
2. 02Which control can stop execution?
3. 03Which actor can override another?
4. 04Can a human override the machine?
5. 05Can every human override it, or only designated roles?
6. 06Can one agent authorize another?
7. 07Can a supervisory agent revoke a subordinate agent's authority?

These are not edge cases once agent populations grow.

They are organizational design questions expressed through software.

Traditional enterprises resolve authority conflicts through hierarchy, policy and governance.

AI Native enterprises will need machine readable equivalents.

Enterprises have long separated sensitive responsibilities.

The person who creates a vendor may not be the person who approves payment.

The engineer who writes a change may not be the only person who authorizes its release.

The person who initiates a financial transaction may not be the person who reconciles it.

These controls exist because concentration of authority creates risk.

Agents do not eliminate that principle.

They can make it easier to violate.

One agent may be technically capable of gathering evidence, making the decision, executing the action and evaluating the result.

That may be efficient.

It may also concentrate too much authority in one machine actor.

Some workflows should separate those responsibilities.

1. 01One agent may prepare.
2. 02Another control may validate.
3. 03A human may authorize.
4. 04A separate system may execute.
5. 05Another evaluator may inspect the outcome.

The correct separation depends on consequence and risk.

The principle remains familiar.

Do not confuse the ability to consolidate execution with the wisdom of consolidating authority.

The human side of the workflow also needs explicit decision rights.

Escalation is useless if the person receiving the work cannot resolve it.

A machine may correctly identify that a case exceeds its authority.

But if the case lands with a human who lacks the required information, expertise or permission, the workflow simply creates another queue.

The enterprise therefore needs to design the receiving side of escalation.

1. 01Who receives the case?
2. 02What authority do they possess?
3. 03What context travels with it?
4. 04Can they override the machine?
5. 05Can they modify the policy?
6. 06Can they expand the machine's authority for this case?
7. 07Can they return the work with additional instruction?
8. 08Does their decision become evidence for future execution?

Human intervention is not outside the authority architecture.

It is part of it.

The safest looking operating model is often one in which a person approves every consequential machine action.

At small scale, that may work.

At AI Native scale, it can defeat the operating model.

If machines generate execution faster than humans can authorize it, human approval becomes the system constraint.

The enterprise then has three choices.

The third option is where operating leverage appears.

Routine decisions can move into bounded machine authority.

Humans can retain decisions where consequence, ambiguity or accountability require them.

Escalation can concentrate human attention on the cases where it creates value.

The purpose of delegated authority is therefore not to remove human control.

It is to separate human control from mandatory human participation in every transaction.

That is a different architecture.

Human control moves upward.

From approving every action

To defining which actions can occur without approval.

From inspecting every execution

To designing the evidence and thresholds that determine when inspection is required.

From being the execution gate

To governing the system that creates the gate.

Accountable autonomy does not mean the absence of humans.

It means human authority has been designed into the operating system rather than inserted manually into every action.

Machine execution creates leverage because it can continue without requiring human participation in every step.

But that same property creates risk if the enterprise cannot explain why the machine had the right to act.

The answer is not to keep machines permanently advisory.

Nor is it to grant broad autonomy and attempt to govern the consequences afterward.

The answer is delegated authority.

• Explicit identity.
• Explicit decision rights.
• Explicit boundaries.
• Explicit controls.
• Explicit escalation.
• Explicit accountability.

The machine should know what it is permitted to do.

The execution environment should enforce the boundaries that matter.

The enterprise should be able to reconstruct the authority chain behind consequential action.

And authority should change when execution evidence changes.

This creates a different relationship between humans and machines.

Humans do not need to make every decision.

They need to determine which decisions can be delegated.

They do not need to execute every control.

They need to design controls that remain effective when execution is performed by machines.

They do not need to inspect every action.

They need evidence that tells them when intervention is required.

They do not surrender authority. They architect it.

That is accountable autonomy.

For every workflow containing machine execution, define the decision rights explicitly.

Start with the machine actor.

Then define what it may:

• observe
• recommend
• prepare
• decide
• execute

and escalate.

For every consequential action, define the authority envelope.

1. 01What can it do?
2. 02To what?
3. 03On whose behalf?
4. 04Under which conditions?
5. 05Within what threshold?
6. 06Using what evidence?
7. 07For how long?
8. 08What control must pass?
9. 09What condition terminates the authority?
10. 10Where does escalation go?
11. 11Who remains accountable?

Then enforce the material boundaries in the execution architecture.

Do not leave consequential authority inside prompts alone.

• Instrument the decisions.
• Preserve operational evidence.
• Measure outcomes.
• Measure overrides.
• Measure exceptions.
• Measure failures.
• Measure the cost of control.

Review whether the delegated authority remains appropriate.

Delegated authority is not a permission granted to an agent once.

It is an operating system the enterprise has to manage.

Chapter 03 changed the unit.

The workflow became the primary object of operating design.

Chapter 04 changed the allocation.

Humans and machines became participants in execution.

Chapter 05 changes the authority model.

Machines can receive decision rights and execute within explicit boundaries while accountability remains human and institutional.

1. Chapter 03The workflow became the unit.
2. Chapter 04Humans and machines became participants in execution.
3. Chapter 05Machines receive explicit decision rights and bounded authority.
4. Chapter 06Management itself has to change.

That creates the next problem.

Management.

Traditional management assumes that execution is performed by people.

1. Managers allocate work to people.
2. →Monitor people.
3. →Coordinate people.
4. →Review their output.
5. →Resolve their exceptions.
6. →Develop their capability.
7. →Adjust capacity by changing teams and headcount.

But what happens when part of the execution system is no longer human?

1. 01When capacity can be instantiated through software?
2. 02When agents can receive objectives rather than individual tasks?
3. 03When routine coordination can itself become computational?
4. 04When machine actors can execute continuously inside delegated authority?
5. 05When a manager is responsible for outcomes produced by people and machines together?

The management system has to change.

The manager is no longer responsible only for supervising human activity.

The manager increasingly governs an execution system.

The next question is therefore not whether managers remain.

It is what management becomes when execution itself has changed.

Chapter 06 · Management After Machine Execution