Designing Decision Rights for Agentic AI

By Lavanya Subbarayalu, PwC | Technology Consulting

AI agents are no longer answering only questions prompted to them. In many domains (healthcare, financial services, and others), they now initiate payments, update records, send external communications, and hand off tasks to other agents. Enterprise governance built so far assumes a human will read the output before anything happens. However, these processes were not designed for the AI agents that act on the organization’s behalf directly, which is where failures start occurring.

An insurance AI Agent had confirmed in writing to a customer that there was a 5% downside rider for the customer, even though the customer’s policy did not include one. The agent had access to the product information, but no one had specified what it was authorized to confirm with a particular customer or what action should be taken if it was not possible to verify. While the agent had the capability to check against the systems, the authority was not defined for it to verify. It was three weeks before the problem was discovered, and problems with such occurrences grow as scope increases.

Once agents are carrying out more significant actions on the organization’s behalf, the question that becomes important is no longer whether the model is accurate; it is instead whether the agent was authorized to act and whether there is a clear record of who is responsible for what it did.

The organization is acting whenever an agent takes action. Few organizations have so far deliberately defined that boundary – deciding which tools the agent can use, which commitments it can make, and which decisions should remain with the individual. This brief presents an approach to solving that design problem.

The Decision Rights Failure Pattern — what pilots don’t reveal

The insurance case is not an edge case, and similar variations turn up in several domains (banking, IT operations, supply chain, healthcare, others). In each use case, the agent was technically able to act, but nobody had decided whether it should have the authority to act. Pilots do not expose this since they run on narrow tasks under close supervision. These problems surface when there is a shift to production volume, where authority was never defined.

1.1 Illustrations of Decision Rights failures in Production              

Context	What went wrong	What decision rights would have changed
Insurance — annuity policy	The agent confirmed, in writing, that a 5% downside rider is available in the customer’s policy, which didn’t carry, and the agent had assumed a standard product feature applied rather than checking the specific policy. The problem didn’t surface immediately, and it was caught in a human review after three weeks.	A written confirmation of a specific customer entitlement would typically sit at Level 4, requiring human approval before any commitment goes out. When the agent can’t verify a detail, escalating to a human reviewer is a safer design choice than assuming.
Healthcare workflow	The agent summarized a case, then it sent an external message, which was read as clinical approval.	Summarizing a case and approving it are usually two distinct authority questions and typically require separate authority levels for each action.
Banking operations	The agent prepared a transaction and requested commitment through a broad service credential rather than a scoped / least privilege credential.	Commitment authority should be tied to a named human, instead of the agent’s own credential, which enables reducing this type of risk.
IT operations	The agent diagnosed an incident, then it went ahead and changed the production configuration, using the access it needed to diagnose, extending its authority further than the intended operation.	Keeping diagnosis authority separate from change authority, so tool access doesn’t quietly assume the permission to act, generally addresses this type of authority issue.

1.2a Four conditions that compound failures at scale

Agent sprawl Some agents get deployed outside formal processes, with no registration, no owner, and credentials broader than the task needs, and there is no governance model that can track such agents.   e.g. A campaign agent runs for three months after its campaign ends, still accessing live customer data, because no one decommissioned it.

Multi-agent delegation A sub-agent can hold up having permissions that were not defined or verified, to multiple levels, without a delegation ceiling enforced at the policy layer. e.g. An orchestrator at Level 3 spawns a sub-agent for a Level 4 payment action. Without an enforced ceiling check, the sub-agent executes the action unchecked.

Authority drift Agents with new integrations or accumulated memory can quietly widen the actions they take, even though no policy changed and nobody approved of the wider scope.   e.g. An agent which was scoped to read and summarize gains the ability to trigger external partner notifications through a new integration, which is a scope that no one signed off.

Human oversight erosion As agents prove reliable over time, human reviewers naturally ease off. What it took minutes to approve starts taking seconds. The checkpoint still exists in the workflow, but the scrutiny behind it starts shrinking out, resulting in human oversight erosion. e.g. A compliance team approves 40 agent-generated communications per day. Six months in, average review time: 22 seconds, down from 4 minutes.

Human oversight erosion generally does not show up in an audit log, because there was no policy that is technically broken, and it is a predictable response to a system that has behaved well. Metrics like approval count alone will not reveal it and require key informative metrics like cycle time and reversal rate that signal whether oversight is still real.

These are authority failures, not model failures. A capable model is not the same as an authorized agent and that distinction becomes consequential at production scale.

The Approach — authority by design

The key design consideration in building every agentic AI system is not which agent to trust, but what each agent may do. The decision authority belongs to the agent’s action and not to agent capability. For example, a single agent in a customer service workflow might read a customer record, draft a response, propose a payment transaction, and be blocked from deleting data, performing four actions at four different authority levels.

As a common starting point, many organizations start to define a single blanket permission for all four agent actions, and it eventually leads to incidents as usage increases.

The framework below gives enterprise governance teams a common reference point for classifying agent actions before they are deployed. It has three parts: an action catalog of what an agent may request, a small set of risk variables that assess each action, and the authority level that results.

2.1 HOW AUTHORITY IS ASSIGNED — FROM ACTION CATALOG TO LEVEL

ACTION CATALOG   —   every action the agent may request, classified by consequence
Read	Summarize	Recommend	Update	Send externally ▶	Approve	Delete	Delegate
▼  each action is assessed against six risk variables  ▼
SCOPE systems touched	REVERSIBILITY can it be undone	BUSINESS IMPACT financial / legal	DATA SENSITIVITY personal / regulated	EXTERNAL COMMITMENT binds the org	RECOVERY how fast reversed
▼  variables combine → each action is assigned to one of five authority levels  ▼
Result: all eight catalog actions, mapped across all five levels Level 1 — Recommend: Read, Summarize, Recommend (low scope, fully reversible and internal use). Level 2 — Execute within bounds: Update (bounded change, cleanly reversible). Level 3 — Execute with review: Delegate (subject to the orchestrator’s authority ceiling) Level 4 — Propose: Send externally, approve (high business impact, difficult to reverse, binds the organization). Level 5 — Human-reserved: Delete (irreversible). The same agent holds all five levels at once, one per action type — authority follows the action, not the agent.

2.1a Action catalog

The action catalog provides agents with a list of every action the agent may request, such as read, draft, recommend, update, send externally, delete, approve, and delegate, which are classified by consequences of the action. Without a defined list, teams may govern the agents by persona or by use case rather than by what the agent does.

The six risk variables mentioned in Section 2.1b are applied to each entry, and that combination produces an authority level for an action.

2.1b How each action is assessed

The six risk variables determine where each action lands on different authority levels.

SCOPE how many records or systems touched

REVERSIBILITY can it be cleanly undone

BUSINESS IMPACT financial, legal, reputational

DATA SENSITIVITY personal, financial, regulated

EXTERNAL COMMITMENT does it bind the organization

RECOVERY how fast can a mistake be undone

2.1c Five authority levels

The key distinction between the five authority levels mentioned in the table below is between what an agent may access, what it may use internally, and what it may assert in writing to a customer or counterparty. Any agent that can send external communications effectively can hold Level 4 assertion authority, which is different from the execution authority level. Such authority levels must be designed into the authority framework during the agent design phase itself, rather than retrofitting later.

The authority levels need to define and comprehensively cover what the agent asserts and not just what it executes. For example, in the insurance case, the agent had Level 1 authority, where it can read and summarize product information. However, sending a written confirmation of a specific customer entitlement is treated as a Level 4 action, regardless of what data the agent had read to produce it, because a written confirmation carries the same legal weight as a signed document from an organization’s legal process.

FIVE AUTHORITY LEVELS — MAP EACH AGENT ACTION TO ITS APPROPRIATE LEVEL

#	Authority Level	What it means
5	Human-reserved	Agents may prepare evidence, but final action stays human-owned. It is typically used for regulatory, personnel, or irreversible decisions.
4	Propose	Agent prepares the full action, and a named human approves the action before execution. Typically applies to vendor payments, external commitments, access grants, written assertions or confirmations sent to a customer or counterparty.
3	Execute with review	Agent executes and a human review immediately after, where a rollback window is active, if the action must be reversed.
2	Execute within bounds	Agent acts within explicit, pre-approved limits. A human supervisor monitors and may intervene as required.
1	Recommend	Agent produces analysis, options, or a draft and a human decides the next step.

2.2 Authority Ceilings in Multi-Agent Chains

In multi-agent chains, every agent in the chain also follows the same authority-levels framework along with an additional ceiling rule.

Authority levels for the agents that delegate to sub-agents must be enforced at the policy layer and not in the agent’s instructions.

• Whatever authority an orchestrating agent holds is the maximum that can flow to any sub-agent it spawns. Sub-agents work within that boundary. Delegation to an agent does not generate privilege permissions for the sub-agents when the delegating agent itself does not have high privileges.
• If the orchestrator agent has Level 3 authority level and spawns a sub-agent to execute a Level 4 action, then that action is blocked. Delegation cannot grant a high authority level to the sub-agent when the orchestrator agent itself does not hold a high authority level.
• If the ceiling is not enforced externally, then every delegation turns into a potential privilege escalation that was not signed off by any human.

HOW AUTHORITY FLOWS IN A MULTI-AGENT CHAIN

ORCHESTRATOR AGENT Authority ceiling: LEVEL 3 — Execute with review

▼  delegates work to sub-agents  ▼

SUB-AGENT A Level 1 — Recommend ✓  ALLOWED Inherits a subset of the orchestrator agent’s authority — within the Level 3 ceiling.

SUB-AGENT B Level 2 — Execute within bounds ✓  ALLOWED Operates within pre-approved limits — below the Level 3 ceiling.

SUB-AGENT C Level 4 — Propose ✗  BLOCKED Exceeds the Level 3 ceiling. Delegation cannot grant authority the orchestrator agent does not hold.

When a sub-agent accumulates permission beyond its orchestrator’s ceiling, tracing what agents authorized becomes very difficult, especially after an incident. This is exactly why such authority level and ceiling checks need to be enforced at the policy layer and not inside the agent’s instructions.

3. The Operating Model — how decision rights governance works in practice

The governance operating model for agentic AI includes defining the authority levels and making it operational with four interconnected capabilities, where each stage depends on what the previous one produces:

• Defining what the agents may do.
• Enforcing those boundaries at runtime.
• Measuring whether enforcement is working.
• Revisiting authority as evidence comes in.

3.1 THE FOUR-STAGE DECISION RIGHTS GOVERNANCE CYCLE

STAGE 01 DEFINE Set authority before activation Builds on: Discovery of agents already running • Action catalog What action agents may request • Authority levels governance per action class • Risk variables calibration per action • Named owners business + technical

STAGE 02 ENFORCE Stop unauthorized actions at runtime Builds on: Action catalog + authority levels from Stage 01 • Agent identity bound to registered agent • Policy decision allow or deny before action • Approval routing route high-risk actions to humans • Evidence capture full audit chain recorded

STAGE 03 MEASURE Make governance visible Builds on: Evidence chain from Stage 02 • Compliance rate actions executed within authority • Override rate post-action reversals • Cycle time speed of approval • Detection time violation to surface

STAGE 04 ADAPT Adjust authority on evidence Builds on: Metrics and signals from Stage 03 • Expansion triggers What earns more authority to the agents • Demotion triggers what reduces authority from the agents • Re-certification periodic policy check • Leadership review executive cadence

Stage 01 — Define: Set authority before activation

Stage 01 starts with discovery of what exists (any agents that may be already running), classify it, assign owners, and move forward. A structured agent inventory needs to include the following.

• Who owns the agent, and who is accountable for its actions.
• What the agent may do with the action catalog and authority level for each action type.
• Which are the upstream and downstream systems to which it may connect.

Stage 02 — Enforce: Runtime decision rights enforcement architecture

Enforcement in stage 02 means determining where the authority level policy check happens, which is an architectural choice and should not be treated as another configuration setting.

• Policy enforcement performed outside the agent’s actions acts as a separate gate that every consequential action passes through before reaching any tool or system, along with evidence of each step captured independently across the end-to-end chain for audit and compliance.
• Authority level policy controls embedded in the agent’s own prompts or instructions can be overwritten by injected content, by drift, or by later instruction that takes precedence.

STAGE 02 — RUNTIME DECISION RIGHTS ENFORCEMENT ARCHITECTURE

AGENT Reasons, plans, and proposes the next action

▶

POLICY GATE External enforcement to check the action before the agent executes

▶

TOOL / SYSTEM Where the actual side effect happens

 

EVIDENCE CHAIN Captures every step covering agent identity, policy decision, approval (if any), tool call, outcome, reconstructable end-to-end after the fact

Within Stage 02, authority-level policy enforcement depends on three things:

• Knowing who the agent is (agent’s identity).
• Knowing the dependency chain the agent touches and how much risk that chain carries.
• Identifying the patterns that can change the agent’s behavior without any visible policy violation.

1. Agent identity: Every production agent must be defined with its own registered identity (a dedicated service account for the agent), with a named owner, a defined set of permitted actions, and a clear decommissioning process when the agent is no longer needed. When agents share credentials with human accounts or with each other, post-incident tracing will become significantly difficult and can make it impossible to establish which action came from an agent or a human.
2. Dependency chain and risk level: AI agents may end up connecting to downstream legacy systems that were not defined as part of the authority design if the configuration or system-of-record documentation does not fully reflect what a legacy system can connect to in production, which may result in unintended actions breaking downstream systems. In such cases, as a safer approach, it is better to consider any agent that touches a legacy system marked with the highest risk level in that dependency chain, until that chain is mapped and validated.

Patterns that can redirect agent behavior without policy violation

AI agents can sometimes change their behavior without any visible policy violation and potentially drift from their actual capability and authority. Three patterns can redirect agent behavior without triggering any visible policy violation. Identifying these patterns early will enable the agent to mitigate the agent’s behavior towards the right response:

Pattern	What happens	Detect and respond
Prompt injection	Malicious instructions are embedded in the content the agent processes, such as a document, an email, or an API response, causing the agent to perform actions outside its defined authority. The agent follows what appears to be legitimate instruction, but the source has been manipulated.	·      Flag and record any action outside the agent’s registered authority level, irrespective of whichever instruction produced it. ·      Enable runtime policy enforcement outside the agent itself, so the action is intercepted before execution. ·      Suspend the agent if prompt injection is confirmed, with detailed review of all actions taken during the affected session.
Context corruption	When the agent’s stored / persistent memory is deliberately falsified or degrades without detection, then the agent continues acting on it as though it remains accurate. In this case, the policy has not changed; however, the basis for the agent’s reasoning has changed.	·      Monitor output patterns over time for meaningful shifts in decisions without a change in inputs or policy, which could have resulted in context corruption. ·      Restore memory from a verified baseline and invalidate actions taken during the affected period. ·      Enable proper write controls, so not all memory can be modified by all inputs.
Objective drift	Agent’s decision-making can shift gradually from its original purpose when there are extended interactions without proper reviews. The agent’s actions may still appear to be within authority; however, the agent may be optimizing toward what has changed. This drift accumulates slowly and rarely shows up in individual action logs.	·      Start establishing a behavioral baseline at  deployment and track override rate, compliance rate for any slow drifts over continued usage. ·      Pause the agent if drift is confirmed and reset the objective through configuration rather than whatever context it had accumulated. ·      Run the Stage 04 demotion mechanism before restoring the agent’s authority.

The common control across all three patterns is the same: an external policy gate that checks every action before execution. It’s also what makes the audit trail possible, without it, there’s no way to reconstruct what happened and when.

The agent proposes. The runtime decides. Authority checks performed outside the agent’s reasoning context are harder to manipulate than the policy embedded in prompts, making the agent resilient.

Stage 03 — Measure: Making governance visible

Stage 03 is to measure the right indicators to validate whether enforcement is working.

While tracking agent activity is a starting point, the key question is whether enforcement is working as intended. The four indicators make governance enforcement visible:

• Compliance rate: how much of agent activity stayed within its assigned authority.
• Override rate: how often actions were reversed after the fact, which usually signals that the agent acted beyond its appropriate scope.
• Cycle time: how long approval decisions actually take. This is the leading indicator of human oversight erosion, covered in Section 1.2a.
• Detection time: how quickly a violation gets noticed once it happens.

These indicators are not fixed thresholds, and they are the signals to track over a period, calibrated to the organization’s own risk appetite and the action classes that are in scope as a key step in the agentic AI governance process.

Stage 04 — Adapt: Adjusting authority based on evidence

Stage 04 primarily focuses on tracking the agent authority levels that perform consistently. If the agents generate anomalies or incidents with expanded authority levels, such authority levels require human review before they can be reduced or restored.

However, several decisions on authority levels are to be made at the leadership level rather than letting the technical team decide, because such decisions involve risk and accountability judgment.

Which action classes stay human-owned Regulatory, personnel, irreversible financial, and contract decisions are not scoped by technical teams alone and need executive judgement	How much risk appetite per authority level Deciding how much scope, exposure, or commitment to delegate is a strategic position and should not be treated as a configuration setting.
What governance indicators reach the executive committee Define the indicators that the executive team reviews as the organization’s governance priority.	When to demote and suspend agent triggers Design when to demote and pause agent actions even before an incident occurs, to produce faster and more consistent responses.

Calibrating human authority to risk

Two mechanisms enable human authority over an agent’s actions:

• Human-in-the-loop where a named person approves an action before it executes.
• Human-over-the-loop where a person supervises and can intervene while the agent acts within pre-approved limits.

The table below maps each risk tier to the applicable mechanism, so the authority framework and the human review cadence stay aligned rather than running independently.

HUMAN OVERSIGHT — CALIBRATED TO ACTION RISK

Risk tier	Oversight mechanism	When it applies	Authority level
Low risk	Monitor, measure and collect samples. Enable automated controls	Reversible, internal, well-bounded actions	Level 1–2
Medium risk	Enable supervisory review, where named humans can intervene or roll back.	Executed with a post-review window active	Level 3
High risk	Enable mandatory approval before execution with an evidence chain provided.	External commitment, payment, access change	Level 4
Critical	Human-reserved. Agents may prepare evidence, and a human executes the final step.	Regulatory, financial, personnel, or irreversible	Level 5

 

Approval is most effective when calibrated to consequences of the agent’s actions rather than the model confidence. A confident model can still request an action that falls outside its authorized scope, leading to unintended impact.

4. Key Takeaways

Before an AI agent reaches production, the governance foundations below need to be in place.

• Register agent identity before production.
• Bind authority levels to the registry, not the prompt.
• Preserve the evidence chain end-to-end.
• Keep policy enforcement outside the agent.
• Calibrate human oversight to action risk.
• Design demotion paths before you need them.

5. Conclusion

The governance of agentic AI systems is moving at a fast pace alongside the technology itself. Most organizations are governing the agents they know about, while others run ungoverned agents that are unaccounted for. Strengthening the right level of governance decisions for AI agents will determine how well the agents are defensible as they scale when there are regulatory questions or when something goes wrong and no one is sure which agent made the decision.

The governance structure needs to be designed upfront, even before an agent reaches production, rather than retrofitting it afterward. The need to strengthen the AI agents’ governance model will only grow as more agents begin operating across enterprises and overseeing each other. This makes it increasingly important for organizations to decide, in advance, where authority begins and where it ends.

Models propose. Agents plan. Orchestrators delegate. Organizations still decide where agents’ authority begins, where it ends, who owns the outcome, and which controls make that decision enforceable.

Lavanya Subbarayalu is an enterprise AI architect specializing in large-scale AI platforms, agentic systems, and responsible AI design. She focuses on building practical, production-ready architectures that enable scalable, reliable, and governed deployment of AI systems across enterprise environments.