Accurate AI agents still need authority limits

An agent can be correct and still exceed its authority

A production agent can calculate the right refund and still make the wrong business decision by issuing more credit than it was authorized to approve. As agents move beyond recommendation-oriented copilots and start calling tools and activating workflows, correctness is no longer a sufficient production test because model output can become a business action. The enterprise also has to decide whether a safe, technically valid action is authorized on its behalf. Technical capability and business authority are separate properties.

Commerce makes the distinction concrete. An order agent can make exactly the modification a customer requested while invalidating a financing condition. A delivery promise can match available inventory while missing a carrier restriction applied an hour earlier. In each case, the agent can reason correctly and follow its instructions as intended, yet the business can still end up with an action it did not sanction.

Those examples expose a failure mode that content controls cannot resolve because the question concerns organizational authority. Filters can restrict unsafe output, but organizational rules determine whether the agent may issue a refund, change an order, or make an external commitment. Because the action can look technically successful, the agent can keep operating until a downstream process exposes the problem. Correct reasoning does not establish authorized action.

The production question is how to prevent a correctly behaving agent from exercising authority the enterprise never delegated. The question becomes more important as tool access converts model output into business action. Making the agent demo work is increasingly separate from the harder task of defining which decisions the agent is legitimately allowed to make.

Guardrails, access controls, and delegated authority solve different problems

That distinction adds a control layer alongside those enterprises already use. Early generative-AI controls screen harmful content, protect sensitive information, validate responses, and constrain tool behavior. Model safety, output controls, and secure tool use still matter because agents need protection against unsafe behavior and inappropriate tool use. Delegated authority addresses the separate operational question of which business decisions an agent may make.

Access control covers part of that decision because it determines whether an agent can reach a system or resource. Once that connection is allowed, the enterprise still needs to decide whether a particular action is legitimate under the circumstances in which it is requested. Reachability and authority can produce different answers for the same tool. A technically available operation may still fall outside the agent’s delegated mandate.

That difference means a production agent needs explicit decision rights covering four basic questions: what it can execute, what needs approval, what it can only recommend, and what it can never touch. Those rights need to capture who delegated the authority, how far it extends, when it applies, and who owns the outcome when something goes wrong. Conventional guardrails keep behavior within safety constraints, while these business decisions establish the agent’s mandate.

The mandate also needs an enforcement boundary outside the system prompt. Telling an agent in natural language that it must never perform a particular operation expresses a policy to the model, but the relevant tool can remain technically callable. A Deny decision has to be enforced where the agent cannot convert confidence or compliant-looking reasoning into permission.

Together, these controls answer adjacent questions. Access controls govern what is reachable; safety guardrails constrain behavior; authorization determines whether the enterprise delegated the specific decision being attempted. Human approval can provide another control, but applying it to every action creates a scaling problem. A production authority model has to preserve those controls while adding an enforceable answer to the delegation question.

Agent adoption is already outrunning visibility and ownership

The need for that answer is arriving while organizations are still discovering where agents operate. An April 2026 Cloud Security Alliance survey of 418 IT and security professionals found that 65% of respondents had experienced an AI-agent-related incident during the previous year. It also found that 82% had discovered agents in their environments that they had not previously known about. Token Security sponsored the survey, giving a company with a commercial interest in security around agent deployments a stake in the topic.

Those figures establish the immediate visibility and ownership problem: organizations are already encountering unknown agents and agent-related incidents while trying to establish who knows about, owns, and controls those systems. In that environment, explicit delegation matters more because technical deployment can precede clear organizational ownership. Authority has to be defined in a form that infrastructure can apply.

Define authority before the agent gets enterprise-tool access

Once an agent can turn a decision into an enterprise action, its mandate needs a form that infrastructure can enforce. An Agent Authority Contract provides that form: a machine-enforceable record of the authority the business deliberately delegates to a production agent. It should exist before enterprise-tool access is granted because granting reachability first leaves the organization trying to infer legitimate action from technical permissions later. The contract has to answer seven questions:

Who owns the outcome? The owner should be a named human or business role rather than another system.
What may the agent do? Its mandate should distinguish among reading, recommending, writing, and committing.
Which systems and data may it reach? The contract should establish the resources relevant to the delegated task.
What materiality limits apply? Materiality means how consequential an action is, and its boundaries can include dollar thresholds, record counts, customer scope, and operational impact.
What triggers escalation? Relevant conditions include uncertainty, anomalies, sensitive data, and potential impact.
Can the action be reversed, and who has reversal authority? Reversibility changes the consequences of autonomous execution.
When does the authority expire, and how is it withdrawn? Delegation needs an explicit end and a mechanism for revocation.

Those questions turn broad statements such as “the agent handles customer service” into decision rights that can be evaluated. Consider a service workflow that computes the correct refund. Its reasoning can be entirely sound while the contract still prevents it from issuing a credit above the business-approved autonomous limit. The materiality boundary supplies the business rule that model accuracy alone cannot supply.

The same structure resolves less obvious ambiguities. An order agent might correctly perform a requested modification, yet the action should stop or escalate when a financing or fulfillment condition changes what the business is willing to authorize. A procurement agent might identify the cheapest supplier, while its contract limits it to a recommendation because the business never delegated authority to accept contractual terms. In each case, the mandate attached to the action determines how far the agent can proceed.

That mandate also establishes ownership because autonomous execution leaves responsibility for outcomes with the enterprise. Naming a human or business role forces the enterprise to decide where that responsibility sits before a failure occurs. Expiration and withdrawal follow the same logic: authority is delegated for defined conditions and can cease when those conditions no longer hold.

With those elements defined, the Agent Authority Contract can work alongside access control. Access can establish that a procurement agent is technically able to reach a supplier workflow; the contract can establish whether it may inspect information, recommend a supplier, write a draft change, or commit the company in the current situation. That specificity turns business delegation into a rule the surrounding infrastructure can enforce.

Authorization has four outcomes

A contract becomes operational when each consequential action can resolve into one of four authorization outcomes: Allow, Approve, Recommend, or Deny. A binary permitted-or-blocked model cannot express cases where an agent can contribute useful work while a person or policy service retains the final commitment. The four outcomes separate the agent’s permitted participation from its authority to complete the transaction.

“Allow” covers bounded, low-risk, reversible actions that can run autonomously. An agent might retrieve approved information, classify an inbound request, or update a field with no material consequence. Because the scope and potential impact are limited and reversal remains practical, prior human review adds little control value.

“Approve” lets the agent prepare or initiate an action while execution waits for authorization from a human or a deterministic policy service. Payments and production changes belong here when their consequences require an independent authorization step. The same treatment applies to actions that materially affect a customer, employee, or third party because preparing the operation and receiving authority to execute it are separate decisions.

“Recommend” retains a named human as the final decision-maker. The agent can analyze information, rank options, draft material, or propose an action, allowing automation to reduce the work needed to reach a decision. This outcome fits cases where contextual judgment remains important or where legal, financial, or individual consequences make automatic execution unacceptable.

“Deny” places an action outside delegated authority regardless of the model’s confidence. Deleting critical production data, making a final employment decision, and overriding a mandatory compliance control are examples of operations that can remain prohibited even when an agent has produced apparently correct reasoning. Technical enforcement of that boundary must sit outside the system prompt so execution does not depend on the model honoring a natural-language prohibition.

The World Economic Forum’s May 2026 playbook describes a related separation through its Agent Capability and Authorization Profile, which is designed so delegated actions can be auditable, enforceable, and accountable. In that profile, technical capability is an input to governance, while authorization specifies which capability has been delegated and under what oversight. The distinction becomes especially important when the appropriate authorization outcome changes with business context.

Authority has to be decided in context, at runtime

The four outcomes can change even when the requested action stays the same because risk changes with context. A small service credit might ordinarily receive Allow, then require Approve when its amount crosses a threshold. An account investigation or regulated-customer status could produce the same change even if the requested operation remains identical. Runtime authorization handles these cases by evaluating authority when the agent proposes the action. The sequence is:

The agent proposes an action.
A policy layer evaluates the agent’s identity, delegated principal, requested tool, implicated data, transaction context, and potential impact.
The policy returns Allow, Approve, Recommend, or Deny.
The system records the authority decision, resulting action, and outcome.
Operational telemetry is then used over time to broaden, restrict, or revoke the agent’s authority.

Within that evaluation, the delegated principal identifies the person or business function whose authority the agent is exercising. Combined with agent identity and the requested tool, it tells the policy layer who is acting, whose mandate the agent is using, and what technical operation it wants to invoke. Data and transaction context add the facts that can change whether that operation is legitimate at that moment.

Those changing facts make authorization contextual. Amount, customer status, investigation state, reversibility, and potential impact can each move an otherwise identical request among the four outcomes. An agent may have continuing access to a system while receiving different authorization decisions as business circumstances change.

The earlier commerce failures show why that evaluation has to happen close to execution: an accurate refund, requested order modification, or inventory-based delivery promise can cross an approval limit, invalidate a financing condition, or encounter a carrier constraint introduced an hour earlier. The latest operational context determines whether technically correct reasoning can legitimately become action. Runtime policy is the point where those current facts can affect execution.

Because runtime policy makes a decision for each consequential action, the system can record both the authority decision and what happened afterward. The enterprise can then see which context produced an authorization outcome, what the agent subsequently did, and what business result followed. Those records provide the telemetry needed to change authority as operational evidence accumulates rather than treating the first policy configuration as permanent.

Human approval has to be proportional to risk

Contextual risk can encourage an enterprise to place a person in front of every agent action, but review volume can weaken the control it is meant to provide. When reviewers approve thousands of routine operations, attention declines and genuine exceptions become harder to distinguish. At that scale, human authorization can degrade into rubber-stamping.

Singapore’s updated Model AI Governance Framework for Agentic AI treats access controls, behavioral guardrails, and human approvals as separate controls. It relates oversight to the scope of an action, whether the action can be reversed, and its potential impact. The framework also recognizes that continuous human oversight of every agent workflow becomes impractical at scale and calls for meaningful checkpoints around higher-risk or irreversible actions.

That approach leads to proportional authorization. Narrowly bounded, low-risk actions can execute autonomously, while high-risk or irreversible actions require approval. Unexpected behavior triggers escalation, and a consequential action without a defined authorization policy is denied by default. Human attention can then concentrate where judgment changes the risk outcome.

Proportionality also changes the target for agent autonomy. The useful objective is the highest level of autonomy an enterprise can responsibly observe, govern, and reverse. Reversibility matters because a recoverable operation creates a different exposure from an irreversible one, while potential impact determines how much independent review the enterprise should require before execution. Those factors also provide concrete signals for deciding whether an agent’s authority should later expand or contract.

Treat delegated authority as a variable you can expand or revoke

Once the agent is operating, response accuracy is too narrow to show whether its authority is properly calibrated. A system can produce accurate answers while escalating too much, crossing delegated boundaries, or causing harm through actions it was technically authorized to perform. Production measurement has to capture how delegation itself is working. Five measures provide direct signals:

Override rate measures how often humans reject or materially modify agent decisions.
Escalation precision measures whether escalation identifies genuinely risky cases instead of routinely returning ordinary work to humans.
Unauthorized-action attempts measure how often an agent tries to go beyond its permitted system, data, or action boundaries.
Business-impacting error rate measures how often authorized actions cause financial, compliance, operational, or customer harm.
Decision latency measures whether approval requirements are reducing risk or simply delaying automation that was already safe.

Together, these measures turn authority into a governable operating variable. Consistently reliable performance can support a controlled expansion of bounded authority because the enterprise has evidence about outcomes under the existing mandate. Frequent overrides, failed escalations, or policy violations point in the opposite direction and should narrow or revoke delegated authority.

That feedback loop changes what “deployment” means for an agent. The initial Agent Authority Contract sets the permitted mandate, runtime policy applies that mandate to current conditions, and operating evidence determines whether the mandate should change. Authority remains revocable because production conditions, agent behavior, and the enterprise’s tolerance for consequences can all change after launch.

Concluding thoughts

As AI agents gain access to enterprise systems, the governance question shifts from what they can do to what the business has authorized them to do. That distinction belongs at the executive level because delegated authority determines who can commit company resources, affect customers, change operations, and accept risk on the organization’s behalf.

The practical objective is not maximum autonomy. It is controlled autonomy with explicit ownership, enforceable limits, proportional approval, and a clear path to revocation. Leaders should require those conditions before consequential tool access is granted, then use production evidence to decide whether an agent’s authority should expand or contract.

The organizations that establish these boundaries early can increase autonomy without treating trust as a one-time decision. Agent authority becomes something the enterprise deliberately grants, observes, and adjusts as business conditions and operational evidence change.