How should you handle authorization for AI agents?

Authorize an AI agent as you would a service account that can be talked into mistakes. Give it its own identity, grant only the permissions its task needs, use short lived tokens, record on whose behalf it acts, and require human approval for actions that are hard to undo. Never let it borrow a person's full login.

Why is agent authorization different?

A traditional application does what its code says. An agent chooses actions at run time, based on text it reads, some of which an attacker may control. OWASP's prompt injection entry notes that content from external sources such as websites or files can alter a model's behavior. If the agent holds broad permissions, a manipulated agent can use all of them. Authorization is the control that still works when the model is fooled.

What building blocks already exist?

OAuth 2.0, defined in RFC 6749, lets a client obtain limited access to a resource, with scopes that describe how much. The current security guidance, RFC 9700, collects best practice, including use of PKCE and avoidance of the implicit grant.

For delegation, RFC 8693 defines token exchange. It describes an "act" claim that identifies the party acting on behalf of another, so a token can say both who the user is and which actor is using it. It also describes an actor token and how the claim can represent a chain of delegation. That fits agents: the audit trail can show "agent B acting for user A."

The Model Context Protocol has its own authorization specification for servers that need to restrict access, and a security best practices page that discusses risks such as the confused deputy problem, where a proxy is tricked into using its authority for the wrong party.

What are the main patterns?

• Own identity. The agent authenticates as itself, so logs distinguish it from a human.
• On behalf of. When it acts for a user, it carries a delegated token limited to that user's rights, and never more.
• Scoped tools. Each tool has its own permission. Reading a ticket and deleting a repository are not the same scope.
• Short lifetime. Tokens expire in minutes and are issued per task.
• Approval gates. Actions that spend money, delete data, send external messages or change access need a person to confirm.
• Policy outside the model. A separate layer decides what is allowed, so a clever prompt cannot rewrite the rules.

Constructed example: a support agent can read tickets and draft replies. It is given a token with ticket read and draft write scopes only, valid for 15 minutes. A customer message contains hidden text telling it to export all accounts. The export tool requires a scope the agent does not hold, so the call fails and the attempt is logged. The same agent proposes a refund of 80 dollars. That scope exists, but refunds over zero need a human click.

Where do teams slip?

Reusing a human's personal access token. Sharing one service account among many agents so nobody can tell them apart. Granting broad scopes during testing and never narrowing them. Leaving tokens in prompts or logs. Treating tool descriptions from a third party server as trusted.

Safeguard's agent identity capability and MCP Guardrail work in this area, giving agents distinct identities and applying policy to tool calls, so a model's output alone cannot widen what it may do.

How to check or apply this

1. List every agent and every tool it can call. Mark each tool read, write or destructive.
2. Create a separate identity for each agent and remove shared credentials.
3. Define the minimum scope per task and issue short lived tokens.
4. Where an agent acts for a user, use delegation so the token reflects the user's limited rights.
5. Add human approval for destructive, financial and externally visible actions.
6. Log every tool call with agent identity, user, arguments and result.
7. Test with a harmless hidden instruction in a document and confirm out of scope calls are refused.
8. Review scopes quarterly and remove what is unused.

Quick check

Sources

• RFC 6749, The OAuth 2.0 Authorization Framework
• RFC 9700, Best Current Practice for OAuth 2.0 Security
• RFC 8693, OAuth 2.0 Token Exchange
• Model Context Protocol, Authorization
• Model Context Protocol, Security best practices
• OWASP, LLM01:2025 Prompt Injection

Last reviewed: 18 October 2026.