Glossary entry

What is agent authorization?

Agent authorization is the discipline of deciding what an AI agent may do, given the agent's own identity, the action it is attempting, and the live context around the request. It is distinct from user authorization: an agent is not a user, and treating it as one collapses the boundary that an decision records depends on.

Key facts

  • Each agent gets its own identity, separate from the user who started it.
  • Used by teams running production AI agents that act asynchronously, on schedules, or across many users.
  • Without it, agents inherit broad user permissions and exfiltrate data or trigger destructive writes with no second check.
  • Veto lets each agent carry identity context, attaches policy to it, and evaluates governed tool calls against that policy in real time.

In plain English

Authentication answers who is this? Authorization answers what may they do? For humans we have built decades of patterns: roles, scopes, OAuth, session tokens. Agents need the same, but with one twist: the agent often has more raw capability than the human who started it. A support agent may have access beyond the operator's own tickets.

Agent authorization separates two questions that get confused in early agent deployments. The first is identity: whether this is the support-bot, calling from the right service, with a valid token. The second is action: given this identity, whether it may issue this refund, send this email, or write to this row. Conflating them by using the human's session to authorize the agent is what makes destructive writes, tool poisoning, and similar cases possible.

How it works

In practice, agent authorization boundaries on top of an authenticated agent identity. Veto issues a per-agent API key, signs the request, and attaches the identity to the call context. The policy engine then evaluates each tool call against the policy attached to that identity, optionally with an organization scope and a project scope.

The output is one of three verdicts: allow, deny, or require_approval. The latter routes the call into a human approval queue. Each verdict is recorded with the request envelope and the rule that fired, so downstream auditors can review the decision record later.

# YAML policy attached to a specific agent identity
- name: support_bot_can_only_touch_own_org
  match:
    agent: support-bot
    tool: ticket.update
  rules:
    - if: args.organization_id != identity.organization_id
      then: deny
    - if: args.priority == "p0"
      then: require_approval

Operational consequence

Without agent authorization, an agent can inherit the broad permissions its host has, and any jailbroken or hallucinated instruction can drive it. The public failure pattern is older than any single incident: agent had a valid session, acted far beyond its intended scope, and the system had no policy check between plan and side effect. Internal write-ups from teams running early agent deployments report the same shape: agent had a valid session, did something far beyond its intended scope, and there was no per-action check to stop it.

The EU AI Act, SOC 2, and NIST AI RMF converge on a control pattern agent authorization makes concrete: a per-action, identity-aware, logged decision with human escalation for sensitive operations. Bolt policy onto the agent identity and you have a decision record an auditor can inspect.

Related terms

Runtime Authorization

The decision is made at action time, not deploy time.

Tool-Call Authorization

The mechanism that intercepts each invocation and asks the policy engine.

Agent authorization

Veto's product page for agent authorization.

AI Agent Permissions

How to model and grant the permissions that agent authorization enforces.

FAQ

Is an agent only acting on behalf of a user?⌄

Sometimes. But agents also run on schedules, react to webhooks, get triggered by other agents, and accumulate state across many users. Treating an agent as a thin proxy for one user breaks the moment it acts asynchronously or aggregates data. Agent authorization gives the agent its own identity and its own policy.

How is agent authorization different from RBAC?⌄

RBAC assigns roles, and a role is a coarse bundle of permissions. Agent authorization is finer: it sees the actual arguments on each tool call and can refuse a specific value, not just a specific permission. An agent with the support role can issue a small refund or a large one. Agent authorization tells them apart.

Do agents need their own credentials?⌄

Yes. Reusing a human's session for an agent collapses two distinct identities into one and weakens decision records. The agent should have its own API key, its own scope, and its own policy. When something goes wrong, you want to know whether the human did it or the agent did it.

What about agent-to-agent calls?⌄

Agent-to-agent authorization is the same problem one level deeper. The downstream agent should treat the upstream agent like any other caller: check identity, check the requested action, evaluate policy. Veto handles delegated calls by carrying agent identity through the call chain and re-evaluating policy at each hop.

Give each production agent its own identity context and policy.

Sign upInstall the SDK