AI Agent Authorization Security: Least Privilege Before Agents Get Root | BeyondScale

Summary

This Curity technical article is defensive guidance on how to secure API access when calls originate from AI agents. It argues that because AI agents act semi-autonomously on a user's behalf, they may diverge from user intent and perform unintended high-privilege actions, so APIs must enforce least-privilege, auditable, human-in-the-loop authorization.^[0]

The core recommendation set is built on OAuth: use scopes for coarse-grained limits, claims for fine-grained context-aware decisions, audience-restricted and non-reused tokens, short-lived by-reference tokens without refresh tokens, explicit user consent or step-up for high-risk actions, and explicit marking of AI-agent traffic. The author stresses that Model Context Protocol (MCP) authorization alone secures only the MCP client-to-server hop and does not meet these API-layer requirements.^[0]

How it works

The article describes a class of authorization weakness rather than a specific CVE: delegating actions to a semi-autonomous LLM-powered agent can cause a divergence between user intent and executed actions, so an over-privileged token lets the agent perform sensitive operations (transactions, transfers, cancellations, deletions) the user never authorized. The mitigation is to constrain tokens with scopes and signed claims (e.g., transaction amount limits, date bounds, excluded categories) that the agent cannot tamper with because they are assigned by the authorization server.^[0]

A related exposure is token misuse across components: reusing a low-privilege MCP-client token to call a high-privilege API, or passing JWTs to an LLM or downstream agent, can leak embedded personal data or over-grant privilege. The article recommends token exchange, transaction tokens, elicitation, audience restriction, and opaque by-reference tokens to keep each call least-privilege.^[0]

Key takeaways

• Treat AI agents as delegated, semi-autonomous actors: default to least-privilege and require explicit consent or step-up authorization before they perform high-risk actions.^[0]
• MCP authorization is necessary but not sufficient; the API layer must independently enforce OAuth scopes, claims, audience restrictions, and short-lived opaque tokens.^[0]
• Centralized, external authorization with per-request least-privilege tokens lets organizations govern and update agent access via policy rather than code changes, while preserving auditability.^[0]

Defensive actions

• Protect APIs with OAuth and issue short-lived access tokens with no refresh tokens for AI agents.: Time-limited, centrally re-issued tokens keep the authorization server in control of consent and improve auditability of agent activity.^[0]
• Use scopes for coarse-grained endpoint limits and signed token claims (subject, amount limits, date bounds, excluded categories) for fine-grained, tamper-resistant authorization.: Claims are assigned by the authorization server and cannot be modified by the agent, keeping the user in control of what the agent can access.^[0]
• Enforce audience restrictions and never reuse access tokens across the MCP client, MCP server, and APIs; use token exchange, transaction tokens, or elicitation to obtain least-privilege tokens tailored to each request.: Prevents a low-privilege MCP-client token from being escalated to call high-privilege APIs and avoids over-privileging in agent-to-agent scenarios.^[0]
• Require explicit user approval or step-up authorization for high-privilege actions, and mark AI-agent traffic with claims such as client_type=ai-agent and client_assurance_level.: Keeps humans in control of sensitive operations, provides clear responsibility for audit and governance, and lets APIs adjust policy for public-client or impersonation-prone agents.^[0]
• Issue opaque by-reference tokens to external AI agents rather than JWTs.: JWTs are decodable by-value tokens that could leak embedded personal information if passed to an LLM or another agent.^[0]