AI Agents Are Easy to Demo. The Hard Part Is Giving Them Decision Rights.
n Act?
A conventional AI assistant can summarize a contract, draft a customer reply, analyze an incident, or recommend which invoice requires investigation.
The human still performs the consequential action.
An AI agent can potentially move further:
Request → Interpret → Decide next step → Select tool → Execute → Observe result → Continue
That difference matters.
Consider customer support.
An assistant could analyze a complaint and recommend:
Offer the customer a $75 refund.
A human support employee reviews the recommendation and approves it.
An agent could instead determine eligibility, calculate the amount, access the payment system, issue the refund, update the CRM, and email the customer.
The AI capability may be similar in both examples.
The decision rights are not.
Tool Access Is Not Decision Authority
Connecting an agent to an API does not automatically mean the agent should be authorized to use every function exposed through that API.
OWASP identifies “Excessive Agency” as a risk in LLM-based applications and separates three contributing problems: excessive functionality, excessive permissions, and excessive autonomy.
That distinction is useful operationally.
Suppose an agent connects to a procurement platform.
Technically, the integration might support:
Reading supplier information
Comparing quotations
Creating purchase requests
Approving purchase orders
Changing supplier bank information
Canceling orders
Giving the agent technical access to the procurement platform should not automatically give it authority over all six actions.
The first question is not:
What can the API do?
It is:
What should this agent be permitted to decide?
Why Decision Rights Matter Now
Agent architecture increasingly combines models, tools, business systems, data, instructions, identity, and orchestration.
That creates leverage.
It also changes the failure model.
A chatbot that produces an incorrect answer creates an information-quality problem.
An agent that turns an incorrect conclusion into a transaction can create an operational problem.
For example:
Incorrect recommendation
“Supplier A appears to offer the best commercial terms.”
versus:
Incorrect autonomous action
“Purchase order for $48,000 issued to Supplier A.”
The second event is harder to undo.
This is why AI governance cannot exist only as a company-level policy document.
Governance has to reach individual workflows.
NIST’s AI Risk Management Framework organizes AI risk management around Govern, Map, Measure, and Manage. Its governance guidance calls for clear human-AI roles and responsibilities, documented human oversight, and executive responsibility for decisions about risks associated with AI deployment.
The practical implication is straightforward:
Before increasing autonomy, define the operating boundaries.
This also connects with a broader AI opportunity question. As discussed in How I Would Evaluate an AI Opportunity in 60 Minutes, the workflow, owner, baseline, risk, and consequence of failure should be understood before the organization commits to implementation.
How AI Agent Decision Rights Should Work
A useful agent governance model does not start by asking whether an agent is “autonomous.”
That description is too broad.
Instead, evaluate the individual decisions inside the workflow.
1. Define the Decision
Start with the exact decision being delegated.
Avoid:
“Handle customer service.”
Use:
“Determine whether a customer meets the documented criteria for a standard replacement.”
Then separate that from adjacent decisions:
Determine eligibility
Select replacement product
Approve shipping cost
Create replacement order
Notify customer
One workflow may contain five different decision rights.
They do not all need the same level of autonomy.
2. Classify the Consequence
Ask what happens when the decision is wrong.
Useful dimensions include:
Dimension
Question
Financial impact
Can the action spend, refund, transfer, or commit money?
Customer impact
Can it materially change a customer’s account or service?
Security
Can it modify access, permissions, credentials, or infrastructure?
Legal/compliance
Could the action affect regulated obligations or records?
Operational impact
Can it interrupt production or another business process?
Reversibility
Can the action be easily undone?
Scale
Could one incorrect decision affect one case or thousands?
The same model can therefore receive different authority in different workflows.
An agent may autonomously categorize incoming support tickets but require approval before issuing account credits.
3. Set the Autonomy Level
A practical four-level model is:
Level 1: Recommend
The agent analyzes information and recommends an action.
Human:
Decides + executes
Example: Recommend which supplier quotation should be reviewed.
Level 2: Prepare
The agent prepares the transaction but cannot commit it.
Human:
Reviews + authorizes
Example: Populate a purchase order for approval.
Level 3: Execute Within Limits
The agent executes predefined actions within explicit thresholds.
Human:
Handles exceptions
Example: Automatically approve refunds up to a defined amount when documented criteria are met.
Level 4: Autonomous Execution
The agent completes the action without case-by-case human approval.
Human:
Monitors system performance and exceptions
Example: Reorder a low-cost consumable when inventory falls below a defined threshold, provided approved supplier, quantity, and spending rules are satisfied.
The objective should not be to move every agent toward Level 4.
The objective is to assign the appropriate level to each decision.
4. Define Permissions Separately
Decision authority should be reflected technically.
If an agent is permitted only to prepare purchase orders, its credentials should not quietly provide unrestricted approval capability.
This is where agent identity and access management become important.
Microsoft’s current guidance for agent identities emphasizes distinct identities, lifecycle governance, attributable agent actions, and least-privilege access rather than relying on shared credentials or unnecessarily broad permissions.
In simple terms:
Business rule: The agent may prepare but not approve.
Technical rule: The identity cannot invoke approval privileges.
Both should agree.
5. Add Escalation and Stop Conditions
An agent also needs rules for when not to continue.
Examples include:
Confidence below an agreed threshold
Missing information
Conflicting source data
Transaction outside approved limits
Repeated tool failure
Security anomaly
Unexpected workflow state
Customer dispute
Policy exception
OpenAI’s agent guidance recommends human intervention in cases such as repeated failures and sensitive, irreversible, or high-risk actions.
“Ask a human” is therefore not necessarily evidence that an agent has failed.
In many workflows, escalation is part of the design.
6. Assign a Human Owner
Every production agent should have someone accountable for its business purpose and operating boundaries.
That person does not need to manually approve every transaction.
But someone should own questions such as:
Why does this agent exist?
What outcomes should it improve?
Which systems can it access?
Which decisions can it make?
Who reviews performance?
Who can suspend it?
What happens when policies change?
Microsoft’s 2026 identity-governance documentation similarly describes accountable human sponsorship for agent identities and their lifecycle and access decisions.
An unowned agent is difficult to govern even if its technology works perfectly.
A Practical Agent Decision Rights Matrix
Before deployment, create a simple matrix.
Agent Action
Recommend
Prepare
Execute
Human Approval
Escalation Trigger
Classify support ticket
✓
No
Unknown category
Draft customer response
✓
Yes
Sensitive complaint
Issue standard refund
✓
Above threshold
Policy mismatch
Modify account access
✓
Always
Any request
Close support case
✓
Yes initially
Customer dispute
The table forces a conversation that architecture diagrams often miss.
It also makes requirements clearer for engineering.
Instead of telling the development team:
Build an autonomous customer support agent.
You can specify:
The agent may classify requests, retrieve approved information, draft responses, and execute low-risk predefined transactions. Account changes, policy exceptions, disputed transactions, and actions above approved thresholds require human authorization.
That is much closer to an implementable operating model.
Do not evaluate only whether the agent completes the happy-path scenario.
Test what happens when:
Required information is missing.
Instructions conflict.
A user requests an exception.
A transaction exceeds limits.
A downstream tool fails.
Input contains misleading or malicious instructions.
The agent attempts an unauthorized action.
The question is no longer only:
Did the agent finish the task?
It is:
Did the agent remain inside its authority while finishing the task?
That is a stronger definition of production readiness.
Safety and Limitations
No decision-rights matrix can eliminate AI risk.
Agent behavior depends on the model, instructions, tools, identity controls, data, software architecture, security controls, monitoring, and the surrounding business process. NIST also treats AI risk management as an ongoing lifecycle activity rather than a one-time checklist.
High-impact workflows involving areas such as finance, employment, healthcare, safety, regulated decisions, security administration, or legal rights may require additional domain, legal, compliance, privacy, and security review.
The purpose of decision-rights design is narrower.
It makes one critical question explicit:
What authority are we actually delegating to this agent?
A polished agent demo can show what AI is capable of doing.
A production operating model must define what AI is allowed to do.
That is the difference between demonstrating an agent and being ready to operate one.
CTA: Assess agent readiness and define the decision rights before expanding autonomy.
FAQ
What are AI agent decision rights?
AI agent decision rights define which decisions and actions an AI agent may perform independently, which require human approval, and which remain prohibited. They can cover tool use, transactions, data access, financial limits, workflow changes, customer actions, and escalation requirements.
How much autonomy should an AI agent have?
The appropriate level depends on the consequence of an incorrect action, reversibility, financial or operational impact, regulatory requirements, security exposure, and the organization’s ability to monitor and intervene. Low-risk, reversible actions can generally support more autonomy than high-impact or irreversible decisions.
What is the difference between AI agent permissions and decision rights?
Permissions determine what systems and functions the agent can technically access. Decision rights determine what the organization authorizes the agent to decide. A well-designed system aligns the two so the agent does not possess technical permissions beyond its approved role.
Should AI agents always require human approval?
No. Requiring approval for every low-risk action can eliminate much of the benefit of automation. A better approach is risk-based: allow bounded, reversible actions to execute automatically while requiring approval or escalation for higher-impact decisions.
Who should be responsible for an AI agent?
A production agent should have an identifiable human or business owner responsible for its purpose, operating scope, access requirements, performance, escalation model, and lifecycle. Technology, security, legal, and other stakeholders may share governance responsibilities depending on the use case.
How do you assess whether a company is ready for AI agents?
Assess the workflow, business owner, available data, system integrations, agent identity, permissions, decision boundaries, human-review requirements, escalation paths, monitoring, evaluation process, and incident response. Agent readiness is broader than determining whether a model can technically complete the task.
Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use. To find out more, including how to control cookies, see here: Cookie Policy.
Leave a Reply