AV

Most AI agent discussions begin with capabilities.

Can the agent read email? Can it search company documents? Can it update the CRM? Can it create a support ticket? Can it issue a refund? Can it deploy code? Can it place an order?

Those are useful technical questions, but they come too early.

Before deciding what tools to give an AI agent, decide which business decisions the agent has permission to make.

This is the foundation of practical AI agent governance.

An AI agent may be technically capable of accessing ten systems while being authorized to make independent decisions in only two of them. It may be allowed to prepare a supplier order but not submit it. It may recommend a customer refund but require approval above $100. It may reschedule an internal meeting automatically while being prohibited from changing a customer commitment.

That distinction between capability and authority should shape the architecture.

NIST’s AI Risk Management Framework specifically calls for organizations to define and differentiate roles and responsibilities for human and AI configurations, document processes for human oversight, specify application scope, and establish responsibility for AI risk decisions.

If you are evaluating whether an AI workflow deserves investment at all, first review From AI Interest to an Investment Decision: A Practical Founder’s Framework.

What AI Agent Decision Rights Actually Mean

Decision rights answer a simple question:

What can this AI agent decide or do without additional human authorization?

This is different from asking what the model knows.

It is also different from asking which APIs the software can technically call.

Consider an accounts-receivable agent.

The agent may be capable of:

• Reading invoices
• Checking payment status
• Drafting reminder emails
• Sending reminders
• Offering revised payment terms
• Applying an account credit
• Escalating overdue accounts

Those capabilities do not need the same authority.

A sensible policy might allow the agent to check invoices and draft reminders automatically. It might send standard reminders without approval. But changing payment terms or applying a financial credit could require authorization from a finance manager.

The agent remains useful without receiving unlimited autonomy.

Capability Is Not Authority

Traditional applications normally execute predefined logic.

An agent can introduce another layer: it can decide which tools to use, in which sequence, based on the goal and the information it observes.

Anthropic describes agents as systems in which a model directs its own processes and tool use while completing a task, often working through a loop of planning, acting, observing results, and adjusting its next action.

That flexibility creates value.

It also creates an architectural question that ordinary API integration does not answer:

Which decisions should remain inside deterministic software, which can be delegated to an agent, and which require a human?

Four Levels of Decision Rights

A useful starting model has four levels.

Level	Agent Authority	Example
1	Recommend	Suggest which support ticket should be escalated
2	Prepare	Draft a customer response for employee review
3	Execute with approval	Prepare and submit a refund after manager approval
4	Execute autonomously	Categorize and route a routine support request

Do not assign one autonomy level to the entire agent.

Assign it decision by decision.

A customer-support agent could have Level 4 authority for ticket classification, Level 2 authority for sensitive responses, and Level 3 authority for refunds.

That creates much clearer governance than labeling the whole system “autonomous.”

Why Decision Rights Matter More as Agents Become More Capable

A chatbot normally produces an answer.

An agent may produce a change in the outside world.

It can potentially modify a record, send a communication, call another service, change configuration, move data, initiate a transaction, or trigger another workflow.

That difference matters because an incorrect answer and an incorrect action have different consequences.

If a chatbot incorrectly suggests that a customer qualifies for a $500 credit, an employee can reject the suggestion.

If an autonomous agent directly applies the $500 credit, the error has already entered the business system.

The question therefore becomes:

What is the consequence if this decision is wrong?

OWASP identifies “Excessive Agency” as a security risk in LLM applications and points to excessive functionality, excessive permissions, and excessive autonomy as common root causes.

This is why agent design should not start by connecting every available API.

Start with the minimum authority required to produce the desired business outcome.

How to Map AI Agent Decision Rights

A decision-rights map can be created before selecting an agent framework, model, or orchestration platform.

Step 1: Map the Workflow

Write the current workflow without mentioning AI.

For example:

Customer submits request
→ Support team categorizes request
→ Employee checks customer record
→ Employee selects response
→ Manager approves exception
→ Response is sent
→ CRM record is updated

Now mark where actual decisions occur.

You may discover that the workflow contains six actions but only three meaningful decisions.

This prevents teams from treating every automation step as an AI problem.

If you are still deciding which parts of the system should be custom-built, bought, or integrated, see Build, Buy or Integrate? The Decision Most AI Projects Avoid.

Step 2: List Every Decision

For each decision, document:

Decision | Input | Current Owner | Output | System Changed | Exception

Suppose you are designing a procurement agent.

The list could include:

• Determine whether stock is below threshold
• Select an approved supplier
• Compare pricing
• Recommend order quantity
• Create a purchase order
• Submit purchase order
• Accept a substitute product
• Approve a price increase
• Change supplier

Once written separately, it becomes obvious that these decisions do not deserve identical authority.

Step 3: Score the Consequence

Evaluate each decision across five dimensions:

1. Financial impact
2. Reversibility
3. Data sensitivity
4. Security or access impact
5. Customer, employee, legal, or operational consequence

Consider two actions.

Action A: Categorize an internal support ticket incorrectly.

The mistake is usually easy to detect and reverse.

Action B: Change an employee’s system permissions incorrectly.

The second decision changes security access. Even if both actions require only one API call, their risk is not remotely equivalent.

Technical complexity should therefore not determine autonomy.

Consequence should.

Step 4: Assign an Authority Level

Now classify each decision.

Decision	Authority
Search approved knowledge	Autonomous
Summarize information	Autonomous
Draft external communication	Prepare
Send routine approved communication	Conditional autonomy
Approve financial exception	Human approval
Change access permissions	Human approval
Delete critical business data	Restricted
Change agent permissions	Restricted

“Restricted” means the agent does not receive that capability, even if a human asks for it through natural language.

This is important.

A prompt such as “do whatever is necessary to solve this” should never expand the permissions defined by the architecture.

Step 5: Define Boundaries and Approval Rules

Decision rights become operational only when you translate them into controls.

For every consequential action, define:

Who can request it?
What data can the agent access?
Which tools can it call?
What amount or threshold applies?
When is approval required?
Who can approve?
What conditions force escalation?

For example:

The agent may issue refunds up to $25 when the customer meets predefined eligibility rules. Refunds from $25 to $100 require supervisor approval. Anything above $100 must be routed to a manager and cannot be executed by the agent.

That is implementable.

“Use human oversight for important refunds” is not.

NIST recommends defining and documenting human oversight according to organizational policy rather than treating human involvement as an undefined safeguard.

Step 6: Design Logging, Escalation, and Rollback

Authority without traceability creates another problem.

For every action worth delegating, ask whether you can reconstruct:

• What the agent received
• What it decided
• Which tool it called
• Which record it changed
• Which user initiated the task
• Whether approval occurred
• What happened afterward

Also decide what the system should do when information is incomplete.

Stopping is a valid agent behavior.

Escalating is a valid agent behavior.

Requesting clarification is a valid agent behavior.

A well-designed agent does not need to force a decision every time.

OWASP’s current agentic guidance recommends least-privilege access, per-request authorization, human confirmation for high-impact or irreversible actions, and logging of agent activity.

A Practical AI Agent Decision-Rights Matrix

Before development, build a table like this:

Decision	Agent Role	Limit	Human Role	Escalation
Search records	Execute	Authorized data only	None	Access failure
Draft email	Prepare	Approved data sources	Review if sensitive	Policy conflict
Send reminder	Execute	Approved template and recipients	None	Customer complaint
Refund payment	Conditional	Up to defined amount	Approve above limit	Policy exception
Change contract	None	Not permitted	Human decides	Always
Delete record	None	Not permitted	Authorized employee	Always

This one-page document can influence your API design, identity model, permissions, workflow engine, user interface, logging strategy, testing plan, and operating policy.

That makes it more useful at the start of the project than a long list of agent capabilities.

Trade-offs: More Autonomy Is Not Always Better

Teams sometimes assume the most advanced agent is the one that requires the least human involvement.

That is the wrong optimization target.

The goal should be the right level of autonomy for the consequence of the decision.

Adding approval to every action creates friction and may eliminate the value of automation.

Removing approval from every action increases operational risk.

The useful design lies between those extremes.

A low-impact, reversible, high-volume action is a strong candidate for greater autonomy.

A high-impact, difficult-to-reverse decision deserves stronger controls even when the model appears highly accurate during testing.

This is also why a successful demonstration does not prove production readiness. A demo may prove that the agent can complete a task. It does not prove that permissions, failure handling, escalation, monitoring, or approval boundaries are ready for real operations.

For that distinction, see The Difference Between an AI Demo, a Pilot, and a Production System.

Mid CTA: Before choosing your agent framework, create a one-page map of every decision the agent can recommend, prepare, approve, or execute.

What to Do Before You Build

Use three steps.

1. Map the decisions

Take one workflow and identify every point where someone currently makes a judgment, approves an exception, changes a record, communicates externally, or commits company resources.

2. Assign decision rights

Classify each decision as:

Recommend | Prepare | Execute with Approval | Execute Autonomously | Prohibited

Do not grant broader authority than the use case requires.

3. Build controls around the map

Only then design tools, APIs, credentials, approval screens, audit logs, escalation rules, and evaluation scenarios.

Your architecture should enforce the decision-rights map rather than depending on a prompt asking the model to behave correctly.

That is the central principle.

Do not give an AI agent authority simply because it has the capability.

Limitations and Safety Considerations

A decision-rights matrix is a governance and system-design tool. It does not replace security architecture, privacy assessment, legal review, regulatory analysis, model evaluation, penetration testing, or domain-specific safety processes.

Requirements also vary significantly by use case. Healthcare, financial services, employment, critical infrastructure, safety systems, and regulated decision-making may require additional controls and professional review.

NIST describes the AI Risk Management Framework as a voluntary framework for managing AI risks across design, development, deployment, use, and evaluation. It should be treated as a risk-management reference rather than a substitute for applicable laws, regulations, contracts, or sector standards.

The practical rule is simpler:

As the consequence of a decision increases, become more deliberate about who or what has the authority to make it.

End CTA: Map your AI agent’s decision rights before you commit to the architecture.

FAQ

1. What are decision rights for an AI agent?

AI agent decision rights define which decisions or actions an agent can make independently and which require human review or approval. They should specify the agent’s authority, permissions, limits, escalation requirements, and prohibited actions.

2. How much autonomy should an AI agent have?

An AI agent should receive only the autonomy required for its intended task. Low-impact and easily reversible decisions may justify greater autonomy, while financial, security-sensitive, regulated, irreversible, or high-impact decisions generally require stronger controls and human involvement.

3. What is the difference between AI agent permissions and decision rights?

Permissions define what systems, data, and functions the agent can technically access. Decision rights define what the agent is authorized to decide or execute. An agent may technically have access to a system while still requiring approval before performing specific actions.

4. When should an AI agent require human approval?

Human approval should be considered when an action has significant financial, legal, security, privacy, customer, employee, operational, or safety consequences, particularly when the action is difficult to reverse.

5. What is excessive agency in AI?

OWASP describes excessive agency as a condition in which an LLM-based system has more functionality, permissions, or autonomy than required. This can allow incorrect, ambiguous, or manipulated model outputs to cause damaging actions.

6. How do you create an AI agent governance framework?

Start by mapping the business workflow, identifying each decision, assigning authority levels, restricting data and tools, defining approval and escalation rules, logging consequential actions, and testing expected and unexpected failure scenarios.