Governance · Oct 11, 2026 · 7 min read
Permission vs Authority
An agent can be authenticated, credentialed, and fully permitted by an API—and still take an action it was never authorized to decide.
There is an uncomfortable gap between what an AI agent is allowed to access and what it is actually authorized to accomplish.
Imagine an enterprise AI agent responsible for resolving customer billing disputes. It can retrieve invoices, inspect transaction histories, identify discrepancies, and initiate refunds through an approved API. It has a valid identity. Its credentials are legitimate. Its API calls are authenticated. Every operation appears in the audit logs.
A customer disputes a $120 charge. The agent examines the account, interprets the available evidence, and initiates a $1,200 refund. Nothing was compromised. No credential was stolen. No API permission was violated. Yet the business has just suffered an unauthorized outcome.
The problem was that it did something it should not have been allowed to decide.
Traditional enterprise security has spent decades refining authentication, authorization and least-privilege access. Those principles remain indispensable. But autonomous agents introduce an important distinction.
A permission answers: Can this identity invoke this operation?
It does not necessarily answer: Is this operation justified by the task, evidence, policy, and authority delegated to the agent?
A refund API may legitimately accept amounts up to $5,000. That does not mean an agent investigating a $120 dispute has the authority to refund $1,200. The API contract defines technical capability. The business policy defines permissible behaviour.
Confusing the two creates a dangerous gap between system access and operational authority.
Access context
Consider an agent with read access to confidential customer records and write access to an external collaboration tool. Both permissions are legitimate. The agent encounters a document instructing it to publish a customer summary to an external channel. If it follows that instruction, the problem is not necessarily a conventional access-control failure. Every individual API invocation might be technically permitted.
The failure occurs when untrusted information influences a decision beyond the authority originally delegated to the agent. Identity controls, prompt safeguards, and tool allowlists address different dimensions of risk. We cannot expect one to substitute for the others.
Four questions
- Identity: Who is acting? Every agent execution needs a verifiable workload identity, with the human or system principal on whose behalf it operates clearly established.
- Capability: What can it technically do? Tools, APIs, resources, and operations must remain constrained by conventional authorization mechanisms.
- Authority: What is it allowed to accomplish in this context? The permitted action must depend on the delegated task, business constraints, data sensitivity, and applicable policies.
- Evidence: Can we justify what happened? The system should retain enough evidence to reconstruct the relevant inputs, policy version, proposed action, authorization outcome, and actual result.
These questions are related, but they are not interchangeable. An agent can satisfy the first two and still fail the third. Without the fourth, understanding the failure becomes an exercise in speculation.
Decision boundary
It may be tempting to put an intelligent governance agent in charge of deciding whether every other agent can act. That merely relocates the trust problem: now the governance agent's interpretation becomes the ultimate authority.
For consequential operations, a different separation is stronger:
- The AI agent proposes an action.
- A deterministic policy decision point evaluates the action against explicit constraints.
- An enforcement boundary permits or rejects execution.
- The execution outcome becomes part of an auditable evidence record.
- Human-controlled decisions remain outside the agent's authority where policy requires them.
An agent can interpret, recommend, and orchestrate. It must not redefine its own permissions or approve exceptions to the constraints governing it.
This introduces an important engineering requirement: the enforcement boundary must be unavoidable. A policy engine is largely decorative if an agent can invoke the underlying API through another route.
In practice
- Platform engineering: agent identities, delegated authority, execution boundaries, and policy versions become first-class platform contracts.
- Security engineering: least privilege must extend beyond resource access to contextual action constraints.
- Governance teams: approval workflows should be linked to actual execution evidence rather than disconnected compliance declarations.
- Operations: retries, partial failures, credential expiry, and policy changes must not silently bypass authorization decisions.
The test
A successful API response tells us an operation was accepted. It does not tell us whether the operation should have occurred.
As autonomous agents become more capable, we will inevitably delegate more operational responsibility to them. That makes the boundary between capability and authority more important, not less.
When reviewing an agent architecture, ask: Can you demonstrate that every consequential action was within the agent's delegated authority—not merely within its API permissions?
If the answer depends entirely on trusting the model's interpretation, the architecture has an unresolved control-plane problem.
The future of enterprise agent governance is not simply making agents observable. It is making their authority explicit, enforceable, and independently verifiable.