Your Agent Didn't Hallucinate. It Exceeded Its Authority.

By Lazar Milicevic · Published October 28, 2026 · 11 min read

Your agent computed the right refund amount, called the right API, and sent a polite confirmation email. Nothing in the transcript looks wrong, yet the business never approved an autonomous credit of that size. If you've been testing agents for hallucinations and toxic output, you've been testing for the wrong failure.

Why content filters can't answer the authority question

A content filter inspects what an agent says. An authorization layer decides what an agent is allowed to do. These are different problems, and a clean transcript tells you nothing about whether the action behind it was sanctioned.

VentureBeat made this argument in its August 2026 piece, Your agent didn't hallucinate; it exceeded its authority. Content filters can block unsafe output. They cannot tell you whether an agent was authorized to issue a refund, touch a production system, or commit the company externally.

Two commerce examples from that article show the shape of the problem:

• A refund workflow computes the correct amount, but nothing caps the credits the business approved for autonomous action.
• A procurement agent finds the cheapest supplier, but nobody defined whether it may accept contract terms or only recommend them.

In both cases the agent did its job well. The model didn't fail. The system around it never encoded the business's limits.

This is also why "just add guardrails" under-delivers. Guardrails usually mean prompt instructions plus output moderation. Neither is a boundary. A system prompt saying "never refund more than $100" is a request, not a control. The VentureBeat article is explicit that a Deny rule must be enforced outside the system prompt, because a natural-language instruction is not a technical boundary.

The industry is converging on this point:

• OWASP's 2026 LLM Top 10 moved Excessive Agency from sixth to third place (LLM03), according to a Cloud Security Alliance research note. The CSA says the 2026 methodology weighted 6,639 documented real-world incidents at 25% alongside 75% practitioner consensus.
• OWASP's recommended mitigation is to enforce authorization in external systems rather than delegating it to the LLM.

If your only safeguard is a better prompt, you have a suggestion, not a control.

Authentication passing is not authorization

Passing identity checks does not mean an agent is allowed to take a given action. Teams often assume that if the agent authenticated cleanly, its behavior is covered. It isn't.

VentureBeat's RSAC 2026 coverage of agent authorization (read it here) reports Cisco's security chief describing incidents where authentication and identity checks pass, but the agent then accesses data it was never scoped to touch or takes an action nobody authorized. The conclusion: the failure is authorization, not identity.

Here is why that happens in small-business setups, where I see it most:

• One broad API key. You give the agent the same key a human admin uses, because scoping it is annoying. Now "authenticated" means "can do everything."
• Tools exposed wholesale. You connect Stripe, your CRM, and your email, and the agent can call any endpoint those integrations expose, including ones you never meant it to use.
• Policy lives in the prompt. "Only refund orders under 30 days old" is a sentence the model weighs against other sentences. It is not an enforced rule.
• No owner. Nobody is named as accountable for what the agent may do, so nobody notices when its scope quietly grows.

The pattern is consistent: identity is solved, scope is not.

Scale makes this worse. VentureBeat reports an April 2026 Cloud Security Alliance survey finding that 65% of respondents had experienced an AI-agent-related incident in the prior year, and 82% had discovered previously unknown agents in their environments. Treat those as figures reported by VentureBeat, not something I verified at the CSA source. Even so, the second number matches what I see in practice: someone wires up an agent for a quick job, and months later it still holds credentials nobody remembers granting.

A decision-rights model: Allow, Approve, Recommend, Deny

Every consequential action an agent can take should map to exactly one of four outcomes. This is the decision-rights model proposed in the VentureBeat article, and it's the most useful framing I've found because it forces you to make a decision per action instead of per agent.

Two details matter more than the table:

1. Default-deny. The article recommends that any consequential action without a defined authorization policy is denied. This inverts how most agent projects start. Usually you expose a toolset and hope. With default-deny, a new capability is off until someone writes the rule.

2. Don't approve everything. The same article warns that requiring human approval for every action degrades into rubber-stamping at scale. If a person clicks "approve" forty times an hour, the approval step becomes theater. Save Approve for the actions that genuinely carry risk, and make the thresholds meaningful.

A practical way to build the matrix is to list every tool your agent can call, then answer four questions for each:

1. Can this action be reversed? How cheaply?
2. What's the worst-case dollar or reputational cost of one bad call?
3. Does it touch customer money, customer data, or an external commitment?
4. Is there a threshold below which it's clearly safe?

The answers sort actions into the four buckets quickly. Most teams discover that a handful of actions deserve Approve or Deny, and the long tail is fine as Allow with a cap.

Write the policy where the model can't reason around it

The enforcement point has to sit between the agent and the system, in code the model can't talk its way past. Here is a minimal pattern: a policy table plus a gate that every tool call passes through.

# agent-policy.yaml
default: deny

actions:
  issue_refund:
    decision: allow
    limits:
      max_amount_usd: 50
      max_order_age_days: 30
    above_limits: approve        # route to a human

  send_customer_email:
    decision: allow
    limits:
      templates_only: true

  accept_contract_terms:
    decision: recommend          # agent drafts, human signs

  delete_record:
    decision: deny

  update_payment_method:
    decision: deny

# gate.py — every tool call goes through this, no exceptions
import yaml

POLICY = yaml.safe_load(open("agent-policy.yaml"))

def authorize(action: str, params: dict) -> str:
    rule = POLICY["actions"].get(action)
    if rule is None:
        return "deny"                      # default-deny

    decision = rule["decision"]
    if decision != "allow":
        return decision

    limits = rule.get("limits", {})
    if params.get("amount_usd", 0) > limits.get("max_amount_usd", float("inf")):
        return rule.get("above_limits", "deny")
    if params.get("order_age_days", 0) > limits.get("max_order_age_days", float("inf")):
        return rule.get("above_limits", "deny")
    return "allow"

def call_tool(action: str, params: dict, execute, queue_for_human):
    outcome = authorize(action, params)
    if outcome == "allow":
        return execute(**params)
    if outcome in ("approve", "recommend"):
        return queue_for_human(action, params, outcome)
    raise PermissionError(f"{action} denied by policy")

Notes on why this works:

• The model never sees the enforcement. It can request a $500 refund as persuasively as it likes; the gate compares numbers, not arguments.
• Unknown actions fail closed. A tool you forgot to list returns deny.
• Policy is reviewable. A non-engineer can read the YAML and say "that cap is too high." Try that with a 2,000-word system prompt.
• It produces an audit trail. Log every authorize result with the parameters. When something goes wrong, you can see whether the agent was permitted or the policy was wrong, which is the exact distinction a hallucination post-mortem can't give you.

This is a sketch, not a complete system. Real deployments also need per-user context, idempotency on retries, and a defined path for what happens when the approver doesn't respond.

What MCP authorization covers, and what it doesn't

If you use the Model Context Protocol, be precise about what its authorization layer does. It controls whether a client may reach a server. It does not decide whether a given action is wise.

The MCP specification (version 2025-11-25) describes authorization at the transport level, letting clients call restricted MCP servers on behalf of resource owners. Key requirements from that version:

• A protected MCP server acts as an OAuth 2.1 resource server.
• Servers must validate that access tokens were issued specifically for them as the audience (RFC 8707) and respond HTTP 401 to invalid or expired tokens.
• Clients must implement PKCE and use the S256 code challenge method when technically capable.
• Authorization servers should issue short-lived access tokens to reduce the impact of leaked tokens.

All of that is valuable. It's the access layer: who is calling, with what token, against which server. But notice what's absent: nothing in the transport spec says "this agent may refund up to $50 but must ask above that." Token scopes can narrow what a client can reach, yet per-action business limits (amount caps, materiality thresholds, escalation triggers) are still your responsibility to design and enforce.

One caution on versions: the MCP specification is revised over time, so check the current version on modelcontextprotocol.io before relying on specifics.

So the layering looks like this:

Most enterprises, per the framing in the source article, are heavily invested in the last row and thin on the third. The research backs that up: a VentureBeat Research study of 573 enterprise leaders (five surveys fielded in June 2026) found companies deployed AI agents ahead of the controls needed to manage them. Only 5% fully trust the evaluations that gate autonomy, and half shipped an agent that passed internal evals and then caused a customer-facing failure in the past year.

Read that last point twice. Passing evals did not predict safe behavior, because evals typically test answers, not authority.

An authority contract per agent

Before an agent touches anything real, write down its authority in one page. The VentureBeat article proposes an "Agent Authority Contract." I could only confirm five of its elements from the text I retrieved, and they're a solid starting point on their own:

1. Owner. A named human accountable for this agent's behavior.
2. What the agent may do. The explicit action list, mapped to Allow / Approve / Recommend / Deny.
3. Systems and data. Which systems it can touch and which data it can read or write.
4. Materiality limits. Dollar caps, record counts, anything that defines "too big to do alone."
5. Escalation triggers. The conditions that force the agent to stop and hand off.

For a solo operator or a five-person team, this can literally be a short document in the repo next to the policy file. The point isn't bureaucracy. It's that the answer to "was this agent allowed to do that?" exists before the incident, not as an argument afterward.

A rollout order that has worked for small teams:

1. Inventory first. List every agent and every credential it holds. Given the reported finding that 82% of surveyed organizations discovered previously unknown agents, assume you'll find a surprise.
2. Start read-only. New agents begin with Recommend on everything consequential. You see what they would have done.
3. Promote by evidence. Move an action to Allow only after you've reviewed its recommendations and the cap is set from observed behavior, not guesswork.
4. Keep Deny permanent for irreversible actions until you have a strong reason and a rollback path.
5. Review the log weekly. Look for repeated Approve requests near a threshold; that's a signal the cap is wrong in one direction or the other.

Who is responsible when it goes wrong

The business owns the outcome of its agent's actions, whether or not the model "meant" to do it. Be careful with the legal precedent here, though, because the best-known case is about a different failure.

In Moffatt v. Air Canada, a British Columbia tribunal held Air Canada liable in February 2024 for its website chatbot's misinformation, finding that a company remains responsible for the actions of its AI tools, per the American Bar Association's summary. The award was modest, covering damages, interest, and tribunal fees, according to a case write-up.

Be honest about its limits. That case was about inaccurate information given by a chatbot, not an agent taking an unauthorized action, and it was decided by a provincial tribunal, so it is not the same as a ruling from a higher court. If you need to know how much weight it carries in your jurisdiction, check with a lawyer or the tribunal's official site. I'm not citing it as proof that "exceeding authority" is a settled legal category. I'm citing it for one narrow point that does generalize: "the AI did it" was not accepted as a defense. If a customer-facing agent can bind you, even informally, assume you'll be held to what it did.

The financial cost of a bad agent action also compounds. Gartner predicted in June 2025 that over 40% of agentic AI projects will be canceled by the end of 2027, citing escalating costs, unclear business value, or inadequate risk controls. That's a 2025 prediction, not fresh 2026 research, but "inadequate risk controls" is exactly the gap this post is about.

Where this leaves you

Before you write another prompt, write the authority list. For each tool your agent can call, decide Allow, Approve, Recommend, or Deny, set caps from your real business limits, and keep the boundary in code rather than in instructions the model could reinterpret. Deny anything without a rule by default, and log every decision so you can answer "was it permitted?" with evidence.

MCP's OAuth-based authorization handles access to servers. The per-action limits are something you design and implement on top of it for your own situation. If you're running agents that touch refunds, invoices, customer records, or outbound email and you aren't sure what they're actually permitted to do, start by listing their tools and mapping each one to the four outcomes above.

Work with BizFlowAI

If you'd rather have this built for you, that's what we do: production AI automation for solo founders and small teams — agents, integrations, and document pipelines that actually ship.

Request a free discovery call — 30 minutes, we map the highest-ROI automation in your workflow. No pitch deck, just engineering.

More guides like this on the BizFlowAI blog.