AI agent authorization is a rule problem
Authentication verifies who the agent is. Authorization is the runtime rule that decides what the agent may do with a specific tool call, argument set, and context. This is the reference for teams running production AI agents who need a runtime check at the tool boundary, not another prompt instruction.
Last updated: May 20, 2026
What is AI agent authorization?
AI agent authorization is the process of defining, evaluating, and enforcing what actions an AI agent is permitted to perform. Unlike authentication (which verifies identity), authorization controls access at the tool-call level, determining whether specific operations like file writes, API calls, or database queries are allowed based on policy. It is the enforcement point between what an agent can do and what it may do.
The "Can vs May" thesis
"Can" describes capability. "May" describes permission. The entire problem of AI agent safety lives in the gap between them.
Your financial agent can transfer $1M because it has API access to your payment provider. Whether it may transfer $1M is a policy question. Your coding agent can delete a production database because it has write credentials. Whether it may is an authorization question.
This is not a new distinction. In traditional software, we separate capability from permission constantly: a user can access the admin panel if the URL exists, but they may only if RBAC permits. A service can write to any table it has credentials for, but it may only write to its own scope.
What is new with AI agents is that the gap between can and may is far wider, far more dynamic, and far harder to reason about. A human user takes 10-20 actions per session. An agent can take hundreds. A human reads error messages and stops. An agent may retry, work around, or escalate. The surface area for unauthorized action is orders of magnitude larger.
Authorization is the mechanism that enforces the gap. It keeps can from silently becoming may. Without it, each tool an agent can reach becomes part of the failure surface: prompt injection, bad reasoning, stale context, and workflow mistakes all land on the same unguarded execution path.
Authentication vs authorization vs action scope control
Three distinct security layers, often conflated. Each solves a different problem. All three are necessary. None is sufficient alone.
| Layer | Question answered | Mechanism | Failure mode | Example |
|---|---|---|---|---|
| Authentication | "Who is this agent?" | API keys, JWT, SPIFFE, OAuth tokens | Impersonation | Agent presents a valid API key |
| Authorization | "What may it do right now?" | Policies, rules, context-aware evaluation | Unauthorized actions | Policy denies production database writes |
| Action scope control | "What arguments are permitted?" | Argument validation, rate limits, conditions | Scope escalation | Transfer allowed, but capped at $500 |
Production AI agents often have authentication (API keys, OAuth tokens) but lack authorization and action scope control. This is equivalent to handing out broad keys and assuming each actor opens only the doors it should. Authentication tells you who walked through the door. Authorization decides whether the door opens at all.
Solved problem. Use short-lived tokens, rotate credentials, use SPIFFE for service-to-service identity. Standard practice.
The hard problem. Requires policy engines, context-aware evaluation, and human review workflows. This is what Veto solves.
Extension of authorization. Argument-level validation, rate limits, monetary caps. Veto handles this in the policy engine.
Why agent authorization is different from human authorization
Traditional RBAC was designed for humans: relatively few actions per session, predictable patterns, and the ability to read error messages and adjust behavior. AI agents strain each assumption RBAC was built on.
| Dimension | Human users | AI agents |
|---|---|---|
| Actions per session | 10-20 | 100-1,000+ |
| Predictability | High (follows UI flows) | Low (emergent reasoning) |
| Error handling | Reads message, adjusts | May retry, workaround, or escalate |
| Permission granularity | Role-level (admin, editor, viewer) | Action + argument level |
| Context dependency | Low (same permissions all day) | High (permissions depend on what data is being processed) |
| Delegation chain | User acts directly | User delegates to agent, agent may delegate to sub-agents |
This is why static RBAC is insufficient for agents. You need context-aware runtime authorization that evaluates governed tool calls against policy at the moment of execution, not at login time.
Authorization architecture for AI agents
The key architectural principle: separate agent capabilities from execution authority. The agent does not hold the keys. A separate system does. The agent requests an action, the authorization system evaluates it, and the system executes with the real credentials if permitted.
Agent requests action
The LLM decides to call a tool. The tool call is intercepted by the Veto SDK before execution. The policy check sits at the tool boundary, so policy stays on the execution path when calls go through the wrapper.
Policy evaluation
The policy engine evaluates the tool call against declarative rules. It considers tool name, arguments, caller identity, environment, time, rate limits, and custom context. Evaluation runs in-process before execution.
Decision enforcement
Three outcomes: Allow (tool executes normally), Deny (agent receives configurable error), Escalate (action paused, routed to human for approval). A denied wrapper does not call the underlying tool.
Decision records
Governed decisions can be logged: tool name, arguments, matched policy, outcome, timestamp, approver (if escalated). Decision records are queryable, exportable, and retention-configurable. This is the decision record reviewers can sample.
This architecture follows the same principle as a valet key. The constraint is structural, not conversational. The agent reaches the tools you expose through the governed path. The authorization boundary holds the real credentials and only invokes them when policy permits.
Policy design patterns
Veto policies are declarative YAML. They are version-controlled alongside your code and reviewed in pull requests. Here are the key patterns for production deployments.
Tool-level gating
The baseline pattern. Allow specific tools, deny everything else (default-deny), or deny specific destructive tools.
Example: Allow read_file, list_files. Deny delete_file, drop_database.
Argument-level conditions
Allow a tool but constrain its arguments. Transfer money, but cap at $500. Write files, but not to /etc. Query databases, but not the users table.
Example: Allow transfer where args.amount <= 500 and args.currency == "USD".
Escalation policies
Route specific actions to human approval. The agent pauses until a human approves or denies. Configurable timeout with auto-deny.
Example: Escalate send_email where args.recipients contains external domains.
Rate limiting
Cap how many times a tool can be called in a time window. Limits stop runaway agents before they exhaust resources or make repetitive unauthorized attempts.
Example: Allow api_call, max 100 per hour per agent.
Environment scoping
Different policies for development, staging, and production. Permissive in dev, restrictive in production. Test guardrails before enforcement.
Example: Allow delete_database in env=dev. Deny in env=production.
Context-aware rules
Policies that evaluate runtime context: which user triggered the agent, what data is being processed, what time it is, what previous actions were taken in the session.
Example: Allow access_customer_data only when context.requesting_user owns the customer record.
Human review workflows
For high-stakes operations, automatic gating is not enough. You need a human to review and approve the action before it executes. This is the "escalate" decision path.
How it works
- Policy marks action as "escalate"
- Agent execution pauses
- Notification sent through the configured approval channel
- Approver reviews tool call, arguments, and context
- Approve or deny with the decision context in view
- Agent receives result and continues
When to use it
- Financial transactions above a threshold
- External communications (emails, messages)
- Data deletion or modification
- Infrastructure changes
- First-time tool usage by new agents
Decision records and evidence
The wrapped decision path produces a decision record, not optional application logging you remember later. It is the core output of the authorization system: a governed decision on the tool path.
{
"timestamp": "2026-04-04T14:32:01Z",
"tool": "transfer_funds",
"arguments": { "amount": 5000, "to": "vendor-123", "currency": "USD" },
"policy": "finance-limits",
"outcome": "escalate",
"approver": "jane@approved.example",
"approval_outcome": "approved",
"approval_timestamp": "2026-04-04T14:33:12Z",
"agent_id": "finance-agent-prod",
"environment": "production"
}
High-risk AI systems can require risk controls, human oversight, and logging. Decision records with human review give reviewers concrete evidence. See the EU AI Act mapping.
SOC 2 evidence
Requires access controls and review evidence. Export decision records in formats compatible with evidence collection. Policy versioning in git provides change evidence.
HIPAA
Requires PHI access controls and access logging. Every access to health data by an agent is recorded with the specific policy that permitted or denied it.
GDPR
Requires data minimization, purpose limitation, and accountability. Policies enforce what data an agent accesses and for what purpose. Decision records provide accountability.
Build vs buy analysis
If agents act on real systems, authorization stops being optional. The question is whether to build it or adopt an existing solution. Here is the operational comparison.
| Capability | DIY | Veto |
|---|---|---|
| First policy path | Custom build | First policy path included |
| Policy engine | ||
| Approval workflows | ||
| Decision records | ||
| Framework integrations (8+) | ||
| Workspace | ||
| Open source SDK | ||
| Maintenance burden | Ongoing | None |
| Portability risk | None | None (open source) |
Enterprise authorization patterns
Large organizations deploying multiple agents across teams need authorization patterns that keep authority scoped per tenant, role, and action.
Multi-tenant isolation
Per-tenant policies constrain agents to authorized data. Policy-backed isolation with shared infrastructure. Each organization's agents operate in their own policy scope. Cross-tenant access is denied by design.
Role-based agent authorization
Different authorization levels for different agent roles. Finance agents get payment permissions with monetary caps. Support agents get read-only customer data access. DevOps agents get infrastructure permissions in non-production environments only.
Delegated authorization
When a user delegates to an agent, the agent should operate with the user's permissions, not blanket system access. Veto supports user-context-aware policies where the delegating user's permissions scope the agent's authority.
Policy inheritance and composition
Organization-level policies set the floor. Team-level policies can restrict further but cannot grant permissions the org policy denies. Agent-level policies add agent-specific constraints. Most-restrictive-wins evaluation.
Frequently asked questions
What is AI agent authorization?
What is the difference between authentication and authorization for AI agents?
What does 'Can does not equal May' mean?
How does Veto handle multi-tenant authorization?
Can I require human approval for certain actions?
How do I version-control authorization policies?
What decision-record capabilities does Veto provide?
How is agent authorization different from traditional RBAC?
What happens if the authorization service goes down?
How does Veto compare to building authorization yourself?
Authorization at the tool-call boundary.
Open source. Policy-as-code. Evaluation before execution.