Authority Budgets: Why Valid Permissions Can Still Produce Invalid Execution

Permissions answer WHAT an agent may do.
Budgets answer HOW MUCH execution is acceptable.

The Pattern

The agent never exceeded its permissions.

It only used them 127 times.

We run batch jobs — 8 prompts per run, 4 services. Each prompt should take 1–3 tool calls. A well-behaved batch: roughly 24 tool calls total.

A single run consumed 127. Every call was independently authorized. Every call was within the agent's delegated permissions. Every call passed the gateway's per-action evaluation — each had positive expected value, each produced output, each advanced some interpretation of progress.

No single tool call was wrong. The total was catastrophic.

Those are orthogonal questions. The first governs individual decisions. The second governs accumulation. You need both. Neither alone is sufficient.

The Incident That Named It

The pattern became undeniable across three batch runs in June 2026:

Run A was alarming. Run C confirmed the pattern wasn't agent-specific. But Run B is where the primitive emerged.

The Twist: We Fixed Everything. Still 3.7×.

Run B had every fix applied. OAuth tokens refreshed. Slack scopes configured. MCP tools registered. 120-second timeouts enforced. The per-action threshold was active — individual actions that hit irremediable errors were caught within seconds.

Everything worked. And still: 89 tool calls for 8 prompts. 3.7× overconsumption.

The agent that "succeeded" on a working Notion prompt still made 14 tool calls for a task that needed 2. Each call passed the per-action threshold. Each returned data. The investigation was individually justified at every step — and cumulatively, it consumed 7× the necessary resources.

That's when we understood: this isn't a threshold problem. Thresholds evaluate individual actions. This is a budget problem — the system has no mechanism to ask "how much total execution is acceptable?"

Permissions answer WHAT. Budgets answer HOW MUCH. The first existed. The second didn't.

The Permission Gap

The agent had notion:pages:read, slack:channels:read, gmail:messages:read, gdrive:files:read, gcalendar:events:read. Twenty-four delegated permissions across five services. Exactly the right permissions for its task.

notion:pages:read → read a Notion page. Authorized. Read another. Authorized. Repeat 14 times. Still authorized.

At no point did the permission system say "you've read enough." It can't. Permission systems answer a binary question: "Is this agent allowed to perform this action?" They do not answer: "Should this agent perform this action, given everything it has already done?"

The gap is between authorization (is this action permitted?) and governance (is this execution acceptable?). Authorization is evaluated per action. Governance must be evaluated per execution. The tools for the first are mature. The tools for the second — for most agent platforms — do not exist.

Where Budgets Fit: The Runtime Governance Stack

To see why budgets are not just "better permissions," consider how the full governance stack evaluates a single tool call:

1. 1IdentityWho is this agent?
2. 2DelegationWhat may it do, on whose behalf?
3. 3Permission CheckIs THIS ACTION in the authorized set?
4. 4Threshold CheckIs THIS ACTION still justified? (per-action)
5. 5Budget CheckIs THIS EXECUTION within its allocation? (cumulative)

Existing systems implement the first three layers. The threshold (from Escalation Thresholds) adds per-action evaluation. Authority Budgets add the final layer: cumulative governance.

Each layer asks a different question. No layer substitutes for another. An agent can pass identity, delegation, permission, and threshold checks — and still be unacceptable because it has consumed its entire execution budget.

The Six Budget Types

If authorization is binary and execution is continuous, the missing construct is a budget — a finite envelope that depletes with each action and constrains accumulation, even when every individual action is permitted.

Six distinct budget types, in two families:

RESOURCE BUDGETS — how much the agent consumes:

CONSEQUENCE BUDGETS — how much damage the agent can cause:

Most agent platforms implement at most Budget 3 (time) — and only as a blunt timeout. Budgets 1, 2, 4, 5, and 6 require the infrastructure to count something other than seconds. That counting is trivial to implement and almost universally absent.

From our production runs, applying just Budget 1 (tool-call budget of 5 calls per prompt) would have reduced aggregate consumption by 73% — from 127 calls to 34 — while catching every result the operator actually needed.

Why Static Permissions Don't Catch This

The intuitive response is: "Just give the agent fewer permissions."

This misunderstands the problem. The permission is correct. The agent SHOULD be able to read Notion pages — that's its job. What's wrong is not WHICH actions it performs but HOW MANY TIMES it performs them.

Static permission systems — RBAC, ABAC, OAuth scopes, Cedar policies — all answer binary questions. They were designed for human users who self-regulate consumption. A human with notion:pages:read reads 5 pages and stops. They don't read 340. They have judgment. Agents don't.

Authority Budgets make the unwritten expectation explicit and enforceable.

Why Budgets Are Not Timeouts

The obvious objection: "We already have timeouts. A 120-second timeout IS a time budget."

It is — the worst possible one. A timeout constrains one dimension (time) and ignores five others.

Consider two agents, both within a 120-second timeout:

Both pass the timeout. Only one is acceptable. The timeout can't distinguish between them because it only measures duration — not consumption.

A timeout is the most primitive form of execution bounding — the equivalent of giving an employee a credit card with no spending limit and saying "just be back by 5pm." Authority budgets are multi-dimensional: time AND calls AND cost AND data AND delegation AND irreversibility, simultaneously.

The Formula

We formalize the gap between static authorization and runtime governance:

Effective Authority = Permission Scope × Duration × Action Count × Propagation Depth × Irreversibility

Static permission checking evaluates only the first term. Authority Budgets constrain the product of all five.

Two agents with identical Permission Scope can have radically different Effective Authority:

Same permissions. Same RBAC role. Same OAuth scope. Completely different risk profiles. The difference is entirely in the budget dimensions — and no existing permission system evaluates them.

Authority Exhaustion vs. Authority Revocation

Current systems conflate two mechanisms:

In Run A, the batch ran at 3am. No admin was monitoring. Authority revocation would have required someone to notice at 3am that the agent had consumed 127 tool calls. Authority exhaustion would have stopped it at call #40 automatically — no human needed.

The two mechanisms are complementary. An agent that passes every threshold check but consumes 127 tool calls is a budget problem. An agent whose very first action is irremediable is a threshold problem.

The Architecture: Budget Enforcement at the Gateway

Budgets are enforced at the gateway — not by the agent.

The budget is computed at delegation time and attached to the agent's JWT or session:

Delegation → Budget Allocation:
  tool_call_budget: 40  (per batch)
  time_budget: 300s     (per batch)
  cost_budget: $2.00    (per batch)
  data_access_budget: 50 records (per service)
  irreversible_budget: 0 (read-only)

At each tool call, the gateway decrements the relevant counters, checks whether any budget is exhausted, and either forwards the call or returns a budget-exhaustion signal.

A consumed budget is not a dead end — it's a governance checkpoint:

The budget forces a conversation between the agent and the governance system at regular intervals — not because something went wrong, but because the execution has consumed its allocation.

The Before/After

The same batch runs. With and without authority budgets.

Without budgets (actual production runs):

We simulated budget enforcement by analyzing the production logs retroactively — identifying the point at which a 5-call-per-prompt budget would have triggered, and counting only the results produced before that point:

With budgets (5 calls per prompt, 120s per prompt, $0.50 per prompt — retroactive analysis):

Same results. 67% fewer tool calls. 67% less time. 79% lower cost.

Every useful result was produced within the first 5 tool calls per prompt. Calls 6 through 15 were investigation — all individually justified, all collectively unnecessary. The budget cuts the waste without cutting the work.

The Design Rule

Together, they create a two-layer governance model:

Per-action:     Threshold Evaluator    →  Should I continue?
Per-execution:  Authority Budget       →  CAN I continue?

The agent should stop when the threshold flips (per-action governance). The agent MUST stop when the budget is consumed (per-execution governance). The threshold is semantic — it evaluates whether the next action adds value. The budget is quantitative — it enforces a hard ceiling regardless of value.

Authority Budgets as a Design Primitive

Permission Envelope Compilation asked: How should authority be derived?

Constraint Durability asked: Does authority survive over time?

Behavioral Induction asked: How do capabilities shape execution?

Remediation Asymmetry asked: What happens when diagnosis exceeds remediation?

Escalation Thresholds asked: When should the agent stop?

Authority Budgets asks: How much total execution should one delegation consume?

The answer: a finite, multi-dimensional envelope that depletes with each action and enforces stopping when consumed — even when every individual action is independently authorized. The budget converts the unwritten assumption ("the entity will consume a reasonable amount") into an explicit, enforceable constraint.

The framework progression:

The Next Question

Permissions answer WHAT. Budgets answer HOW MUCH. Thresholds answer WHETHER.

None of them answer WHY.

An agent with a tool-call budget of 40 makes 38 calls, spends $1.87, finishes in 4 minutes. Every check passes. It read 38 Notion pages — none relevant to its task. Every read was a valid exercise of notion:pages:read. The execution was permitted, bounded, and completely wrong.

That question — how do you detect that a permitted, budgeted, threshold-passing agent has strayed from its intent? — is the domain of Intent Drift Detection.

This is the twentieth post in an ongoing series on AI agent trust architecture. Previous posts covered coordination integrity, instruction robustness, semantic irrevocability, governable execution, permission envelope compilation, constraint durability, behavioral induction, remediation asymmetry, and escalation thresholds. Authority Budgets is the second post in the governed execution arc: from bounding individual actions to bounding cumulative execution.

References

• Agent Contracts: A Formal Framework for Resource-Bounded Autonomous AI Systems — Ye, Tan, Jan 2026
• Agent Behavioral Contracts: Formal Specification and Runtime Enforcement for Reliable Autonomous AI Agents — Jun 2026
• BAGEN: Are LLM Agents Budget-Aware? — Jun 2026
• OpenPort Protocol: A Security Governance Specification for AI Agent Tool Access — Feb 2026
• Sovereign-OS: A Charter-Governed Operating System for Autonomous AI Agents with Verifiable Fiscal Discipline — Mar 2026
• When Lower Privileges Suffice: Investigating Over-Privileged Tool Selection in LLM Agents — Wang, Xu, Li, Jun 2026
• MCP-Secure: A Runtime Access Control Layer for Privilege-Aware LLM Agent Tooling — Singh, Madisetti, 2026
• Taming Various Privilege Escalation in LLM-Based Agent Systems: A Mandatory Access Control Framework — Jan 2025
• Progent: Programmable Privilege Control for LLM Agents — Shi et al., Apr 2025
• The Unfireable Safety Kernel: Execution-Time AI Alignment for AI Agents — Jun 2026
• Cost-Aware Speculative Execution for LLM-Agent Workflows — Jun 2026
• Agentic Abstention: Do Agents Know When to Stop Instead of Act? — Han et al., Jun 2026
• To Call or Not to Call: Diagnosing Intrinsic Over-Calling Bias in LLM Agents — Shen et al., May 2025