Agent decision rights should be written before autonomy is granted

Introduction

The customer-service agent has a valid identity, an approved refund tool and enough system access to submit the transaction.

That proves it can execute a refund. It does not establish that it should be allowed to decide whether the customer deserves one.

Should the agent be able to waive a policy condition because the customer has threatened to leave? Should it choose a discretionary goodwill amount after the standard refund period has expired?

Those are business judgments. Organizations have traditionally delegated them to people with defined authority, escalation routes and accountability.

Giving an agent the technical means to execute a decision does not automatically transfer the decision right behind it.

That is why AI agent decision rights governance belongs upstream of the permission architecture.

NIST’s AI RMF Playbook calls for organizations to define human roles and responsibilities for AI oversight, clarify delegated authorities and relate human-AI configurations to organizational risk tolerance. Its Measure guidance also recommends tracking overrides, policy exceptions, escalations and accountable go/no-go decisions.

The technical system can determine whether an agent is capable of calling a tool.

The enterprise still has to determine what the agent is allowed to decide.

At a glance

• Permission to execute an action is different from authority to make the business judgment that causes it.
• Decision rights should describe the judgment being delegated, not merely the tool an agent can call.
• Consequence, reversibility and exception-making are useful tests for how much discretion an agent should receive.
• Human approval has value only when the reviewer sees the decision that actually matters and has authority to challenge it.
• The business owner of the underlying judgment should participate in delegating it; technical permissions should implement that decision.
• New tools, wider use or greater autonomy should not expand decision rights silently.
• A successful outcome can still be a governance failure if the agent was never authorized to make the decision.

Autonomy is an organizational delegation before it is a technical feature

Agent autonomy is often described through system capabilities: planning several steps, choosing tools, retrying failures, calling external services and continuing work without waiting for a person after every operation.

Those capabilities matter, but they describe only what the technology can do.

Enterprise autonomy also depends on which judgments the organization is willing to delegate.

A procurement agent may have permission to create a purchase order. That does not answer whether it may select the supplier, change the quantity or choose a vendor outside the approved panel. A collections agent may be able to modify a payment plan without being authorized to waive a fee or grant a hardship exception.

The permission layer answers what an agent can execute inside enterprise systems. Decision rights sit upstream and determine what discretion the business intended to give it.

An organization can therefore operate strong least-privilege controls and still delegate the wrong judgment. The agent may have exactly the access it was deliberately given; the governance failure may be that nobody decided whether the underlying business decision belonged inside the agent’s mandate.

NIST’s Govern guidance explicitly asks organizations to clarify human roles, responsibilities and delegated authorities in human-AI configurations. Its Map guidance separately requires human-oversight processes to be defined, assessed and documented for consequential AI use.

The delegation decision should exist before the permission model implements it.

Decision rights should be written around the business judgment

“Customer-service agent may process refunds” sounds clear until the decision is decomposed.

An agent could verify that published eligibility conditions are satisfied, calculate the refund mechanically from the transaction and submit it. Or it could interpret conflicting evidence, waive a policy condition, choose a discretionary amount and decide that retaining the customer justifies an exception.

Both flows use the same refund system.

They do not involve the same authority.

The useful boundary is therefore not simply refund API: yes or no.

It is where standardized execution stops and discretionary judgment begins.

That distinction can be written directly into the operating model. An enterprise might allow an agent to settle standard refunds when documented conditions are met and the amount follows a deterministic rule. Disputed eligibility, policy exceptions and goodwill compensation could remain reserved for a person with the relevant business authority.

The same principle applies elsewhere.

A procurement agent may calculate the cheapest compliant option without having authority to waive supplier requirements. A finance agent may prepare a journal entry while unusual accounting treatment remains a controller decision. An HR agent may assemble evidence for a case without determining an employment outcome.

Writing the delegated judgment makes the autonomy boundary intelligible to both governance and engineering.

Consequence and reversibility shape how much discretion makes sense

Financial value is an obvious input to agent decision rights, but it is not sufficient.

A low-value decision may affect an employee, alter a customer entitlement, expose confidential information or create a pattern that becomes significant at large scale. Conversely, a larger transaction may be suitable for autonomous execution when the governing rules are explicit and the consequences are tightly controlled.

The question is what the decision changes.

Committing funds, changing contractual terms, modifying a regulated record, affecting an employment outcome or sending a binding communication creates different forms of exposure even when the technical action looks simple.

Reversibility changes the delegation calculation as well.

A draft recommendation is easy to discard. An internal ticket can usually be reassigned. A settled payment, customer commitment, production configuration or employee notification can be much harder to unwind, particularly when downstream systems or people have already acted on it.

NIST’s AI RMF asks organizations to consider the likelihood and magnitude of impacts to individuals, groups and organizations when mapping AI risk.

Decision-right design can use the same logic without turning into a risk-taxonomy exercise. The more consequential and difficult to reverse the judgment, the stronger the case for narrowing agent discretion, adding another control or retaining the decision elsewhere.

This does not imply that every irreversible action requires human approval.

It means irreversibility should be considered before autonomy is granted rather than discovered after an agent has already exercised it.

Exceptions are where an agent can quietly become a policy maker

Most enterprise processes have rules and exceptions.

The distinction becomes significant when agents are given discretion.

Applying an existing rule to known facts is one form of authority. Choosing among alternatives that policy already permits gives the agent more latitude but still operates inside a defined envelope.

Creating an exception is different.

A customer may not meet the normal eligibility criteria, but a human manager can decide that unusual circumstances justify special treatment. Procurement may approve a supplier outside the standard panel because of a genuine emergency. Finance may accept an unusual handling decision after considering facts that were not anticipated by the normal workflow.

When an agent is allowed to make those calls, it is no longer only executing policy. It is participating in the interpretation of when policy should bend.

That can give the system an operating role that the enterprise never explicitly intended.

The concern becomes stronger when exceptions recur. An agent that repeatedly makes similar discretionary choices may establish an operating pattern that resembles policy even though no governance body approved one.

Decision rights should therefore distinguish among applying a rule, choosing among explicitly permitted options and departing from the normal rule.

The first two may support broad autonomous operation.

The third deserves deliberate authority.

Model confidence does not grant organizational authority

A common autonomy pattern is to let the model act when confidence is high and escalate uncertain cases.

Confidence can be useful evidence.

It is a weak basis for deciding who holds the underlying decision right.

A model can be highly confident about a judgment the enterprise never intended to delegate. An employment recommendation, customer-remediation exception or unusual financial treatment does not become an appropriate autonomous decision because the model assigns itself a high probability.

The reverse is also true. Low model confidence does not automatically require a person when explicit business rules determine the outcome and the system can verify those rules reliably.

Decision-right design should therefore begin with the business judgment, its consequence and the organization’s policy. Technical uncertainty can then influence how the delegated authority is exercised.

Otherwise the organization risks allowing a technical score to determine an organizational delegation.

Human authority has to remain visible at the edge of agent discretion

Human approval is one way to retain authority, but the value of the control depends on what reaches the reviewer.

Current agent platforms can pause actions before execution. OpenAI’s remote MCP tooling supports configurable approval requirements, including tool-specific approval policies, while Microsoft Agent Framework can mark tools as approval-required and suspend execution until a response is supplied.

Those mechanisms provide enforcement hooks. They do not determine which decision should reach a person.

A reviewer shown only Approve refund_customer? may have little basis for meaningful judgment if the amount, relevant policy, reason for the exception and consequences are absent.

The useful control is not the presence of an approval button. It is whether the person is reviewing the judgment that the enterprise intended to reserve for human authority.

That principle also leaves room for several operating models. An agent can resolve standard cases while escalating exceptions. It can recommend a discretionary outcome while a person makes the decision. It can execute parameters already chosen by a human without being allowed to alter them.

Escalation completes the boundary. When a case no longer fits the agent’s delegated authority—for example because the normal policy does not cover it or the consequence moves outside the agreed range—the workflow should transfer the decision to someone who possesses the missing authority.

NIST’s Measure Playbook explicitly recommends tracking human overrides, policy exceptions, escalations and accountable go/no-go decisions.

The EU AI Act provides a regulatory example of the same principle for high-risk systems. Article 14 requires effective human oversight, including the ability to understand limitations, remain alert to automation bias, interpret outputs and, where appropriate, disregard, override, reverse or stop the system. Those high-risk-system requirements apply according to the amended timetable—generally from 2 December 2027 for the relevant Annex III use cases and 2 August 2028 for high-risk systems embedded in regulated products. The European Commission’s AI Act application timeline sets out those dates.

The governance lesson is useful before those dates: retained human authority should be designed around an actual decision, not added as a ceremonial checkpoint.

The business owner delegates; the permission model implements

Technology teams configure agents, but they do not necessarily own the business authority being transferred.

Refund discretion may belong to customer operations. Payment authority may belong to finance. Supplier-selection rules may sit with procurement, while employment decisions belong within HR and management structures. Risk, legal or compliance functions may constrain those choices without becoming the owner of the operational decision itself.

The OECD’s 2026 Due Diligence Guidance for Responsible AI recommends assigning AI due-diligence oversight to relevant senior management, documenting responsibilities and giving particular attention to staff whose actions and decisions can increase or reduce adverse-impact risk.

For agent governance, the implication is straightforward: the owner of the business authority should participate in deciding whether that authority can be delegated and where its limits sit.

Once that decision exists, technical architecture can implement it through tool scope, transaction limits, parameter restrictions, approval requirements and policy enforcement.

The permission model should implement the delegation, not invent it.

OpenAI and Microsoft provide approval primitives for particular tools. Amazon Bedrock Agents Classic also supports confirmation before configured actions are invoked, although AWS stopped opening Agents Classic to new customers on July 30, 2026 and directs new agent development toward AgentCore.

These mechanisms show that technical controls can enforce a boundary.

They cannot decide what the business boundary ought to be.

Capability and context changes should reopen the delegation

Agent systems rarely remain static.

A workflow can gain another connector or a write-capable API. A product update can let an agent complete a task that previously ended in a human handoff. A system originally deployed as a small internal pilot can become customer-facing, or a process can begin handling larger transactions and a wider affected population.

Those changes matter because technical capability and organizational delegation can drift apart.

An agent approved to draft recommendations may later become capable of executing transactions without anyone explicitly reconsidering the authority behind those actions. A new tool may make a previously theoretical decision executable.

Documented decision rights provide something stable to compare against those changes.

The review question is narrow:

Does the existing delegation of decision authority still make sense in the operating context that exists now?

That should not be confused with formal risk reclassification. A change in purpose, population or decision role may also affect the system’s formal risk category, but that is a separate governance determination.

Here, the concern is whether the agent is still exercising the same kind and amount of business discretion that was originally approved.

A capability can therefore expand without the decision right expanding with it.

If the organization wants to broaden the delegation, that should be an explicit decision rather than a side effect of a product release.

Outcome correctness and delegated authority are separate evidence questions

After an agent acts, teams naturally examine whether the result was correct.

Governance also needs to know whether the agent had the authority to make that decision.

A refund might produce a commercially sensible outcome while exceeding the agent’s delegated discretion. A supplier choice could save money while bypassing a rule that reserves exceptional vendor decisions for procurement. A transaction can succeed technically and still represent an unauthorized exercise of business judgment.

Evidence therefore needs to support both questions.

What decision did the agent make, and what decision right applied at that point?

The organization does not need a new evidence architecture solely for this purpose. Existing execution, approval and policy records may already contain much of the required information.

What matters is that the enterprise can establish whether the agent stayed inside the delegation it was given.

Correctness alone does not answer that.

Broader autonomy should require an explicit governance choice

Enterprises have strong economic reasons to widen agent autonomy.

Fewer human handoffs can shorten cycle time. Routine work becomes cheaper. Approval queues stop slowing processes that the agent appears capable of completing.

Those benefits also create pressure to let operational convenience determine where human judgment disappears.

A team sees that most approvals are granted and asks why they exist. An exception queue becomes expensive. A product update makes another action technically possible, and the temptation is to remove the handoff because the system can now complete the whole process.

Decision rights give the enterprise a better way to respond.

The organization can examine whether the evidence supports widening the class of standard cases the agent may resolve, whether stronger controls would make a broader delegation acceptable, or whether the remaining judgment is still too consequential or discretionary to transfer.

That turns greater autonomy into an operating-model decision.

It prevents autonomy from expanding gradually through product optimization until technical capability has quietly become organizational authority.

FAQs

What are AI agent decision rights?

AI agent decision rights define which business judgments an agent may make autonomously, where its discretion ends and which decisions remain reserved for people or require escalation. They sit upstream of technical permissions, which control what actions and systems the agent can access.

How are decision rights different from agent permissions?

Permissions determine executable access—for example, whether an agent may call a refund API or modify a record. Decision rights determine whether the agent is authorized to make the business judgment that justifies the action. Good least-privilege controls do not automatically create appropriate decision authority.

Should every agent action require human approval?

No. Standardized decisions governed by clear rules may be suitable for autonomous execution. Human authority is more useful where discretion, exceptions, consequence, irreversibility or uncertainty make the underlying judgment unsuitable for unrestricted delegation.

Who should define an AI agent’s decision rights?

The business owner of the underlying decision should participate, together with relevant risk, legal, compliance, security and technology functions. A development or platform team should not determine business delegation merely by deciding which tools to expose.

When should agent decision rights be reviewed?

They should be reconsidered when tools, autonomy, business purpose, transaction scope, affected population or operating consequence change materially, or when incidents and assurance evidence indicate that the original delegation is no longer appropriate.

Autonomy should follow delegation

Agent technology is making it easier to connect models to systems that can create real business effects.

That technical progress does not settle who is allowed to make the underlying decision.

A permission model can restrict access. Approval controls can stop selected actions. Monitoring can show what happened after the agent acted.

None of those mechanisms substitutes for deciding which judgments the enterprise intended to delegate.

That decision comes first.

Once the boundary is explicit, technical controls can enforce it, evidence can show whether the agent stayed inside it and governance can reconsider the delegation when the operating context changes.

Without that sequence, autonomy can expand one integration, workflow and product feature at a time until capability has quietly acquired authority.

An agent should not acquire a decision right simply because the system has learned how to execute the decision.