Agent Authorization & Approval Gates
Agent authorization decides what an identified agent may do: which tools, data and actions, in which scope and up to which limits. An approval gate is a point where a specific action pauses until an accountable person, or a stricter policy, allows it.
For people, authorization is mostly decided at sign-in and by role. For agents, the decision has to be made at the level of the action, because the agent chooses its actions at runtime and can take many of them quickly.
Three outcomes cover most designs: allow, deny, or require approval. Approval gates belong on consequential or hard-to-reverse actions: payments, deleting data, changing production systems, sending messages outside the organization, or moving sensitive data.
A good gate gives the approver what they need to decide: which agent, acting for whom, wants to do what, with which data, why, and at what cost. A good denial gives the agent a reason, so it can choose a permitted alternative instead of retrying the same thing.
How it works
The decision is made outside the model, at the point where a tool call is executed.
- The agent requests a tool call
- An enforcement point intercepts it
- Policy evaluates the identity, scope, parameters and context
- Allow, deny, or hold for approval
- The decision and its reason are recorded
Existing standards cover parts of this. OAuth 2.0 (RFC 6749) provides scopes, which are coarse. OAuth 2.0 Rich Authorization Requests (RFC 9396) lets a client ask for fine-grained authorization details, such as a specific payment. OpenID Connect Client-Initiated Backchannel Authentication (CIBA) lets a client ask for a user’s authentication or consent on a separate device, without a browser redirect, a pattern that fits asking a person to approve an agent’s action. In the Model Context Protocol, a protected MCP server acts as an OAuth 2.1 resource server.
Example
A procurement agent may raise purchase orders with approved vendors. Policy, for illustration:
| Request | Outcome |
|---|---|
| Approved vendor, under the team’s threshold | Allow |
| Approved vendor, above the threshold | Require approval from the budget owner |
| A vendor that is not approved | Deny, with the reason and the onboarding route |
The agent tries to pay a new vendor. The gate denies it and says why. The agent does not retry; it opens a vendor-onboarding request and tells the requester what happens next.
Common misconceptions
- “Approving everything is safest.” Gates on every action produce approval fatigue, and approvals turn into reflexes. Gate the few actions that matter.
- “The instructions are the authorization.” Telling a model never to delete anything is not enforcement. Instructions can be overridden, including by prompt injection; enforcement has to sit outside the model.
- “Authorize once, at the start.” Context changes during a run. Authorization is decided per action.
Operational implications
Security. Action-level authorization limits what a compromised or confused agent can do.
Governance. Every decision is evidence: what was allowed, denied or approved, by whom and why.
Performance. Gates add waiting time. Measure it, and design the path an agent takes after a denial.
In Tracston, Imperium’s action gate decides whether a consequential action is allowed, blocked or held for approval, as its product page describes.
Related
- Agent Identity
- Agent Execution Tracing
- Autonomous Agents Need Boundaries, Not Just Capabilities
- AI Governance Should Not Mean Blocking AI
- The Query Was Read-Only. The Password Was Exposed.
- The Enterprise AI Firewall Is Becoming a New Security Layer
- AFPM Lab 03: Denied. Still Returned.: The policy says DENY and the tool returns the fields anyway: a decision is not proof that anything was stopped (simulation).