Authorization for AI agents: why token-based controls matter

At a glance

What this is: Curity’s analysis shows that AI agent security in Azure Foundry and MCP workflows depends on token-based authorization, not permanent API access, because natural-language commands can otherwise drive unauthorized backend actions.

Why it matters: This matters to IAM and security teams because agentic systems inherit authorization risk, and the control point shifts to how tokens are issued, scoped, exchanged, and approved across every backend call.

Context

The core governance problem is not that AI agents can call tools, but that they can do so in ways that outlive the intent that triggered the action. In Azure Foundry and MCP-style workflows, natural language becomes an execution input, so access decisions have to remain explicit even when the user experience feels conversational.

Curity’s example centres on enterprises that want agents to operate on internal resources without accidentally crossing into another user’s data or another customer’s scope. That makes authorization, token scope, and runtime attributes the real policy layer, while the agent remains only the actor carrying the request.

For IAM teams, this is familiar in principle but different in timing. The question is no longer whether the application authenticates, but whether the access token expresses the exact customer, region, purpose, and privilege boundary needed for the task at the moment it runs.

Key questions

Q: What breaks when AI agents are given permanent API credentials?

A: Permanent credentials create standing privilege, which expands the blast radius of a compromised prompt, misrouted tool call, or malicious workflow. Once those credentials are embedded in an agent path, they are difficult to contain and easy to reuse. Short-lived tokens and scoped claims reduce that exposure significantly.

Q: Why do AI agents need token-based authorization instead of simple authentication?

A: Authentication only proves who or what is calling, but it does not limit what the caller may do. AI agents need token-based authorization because the backend must enforce scope, audience, and runtime attributes on every request, especially when the agent can translate a natural-language prompt into multiple downstream API calls.

Q: What are the signs that an AI agent authorization design is too coarse?

A: Common warning signs are shared credentials across tasks, tokens that never expire, missing customer or region claims, and APIs that accept any request once the agent is logged in. Those patterns make it impossible to distinguish a legitimate task from an overreaching one, so misuse and prompt-induced drift can reach backend systems.

Q: How should security teams implement multi-person approval for high-risk privileged actions?

A: Security teams should place a quorum-based approval step in front of destructive privileged actions such as bulk deletion, so no single operator can execute them alone. The control works best when paired with least privilege, clear approver roles, and logging in the approval workflow. For urgent maintenance, teams should define exceptions, because security controls only work when the operating model is realistic.

Technical breakdown

Why short-lived OAuth 2.0 tokens matter for AI agents

Short-lived OAuth 2.0 access tokens reduce the blast radius of agent misuse because they bind authority to a narrow time window and a narrow scope. In this model, the agent is not trusted with a standing credential. Instead, each backend action is authorised through a token that can carry claims such as audience, purpose, customer context, and region. That matters in AI workflows because prompts can change task intent mid-session, and a permanent secret would turn that drift into broad backend access. Token integrity also matters because downstream APIs must trust the claims they receive, not the agent’s natural language request.

Practical implication: Issue short-lived tokens with tightly scoped claims and reject any backend request that cannot be justified by the token, not the prompt.

How A2A and MCP change the authorization problem

A2A and MCP add structure to agent-to-tool communication, but they do not remove the need for authorization. The external application sends a natural-language command to a backend agent, the agent then calls an MCP server, and each hop becomes a policy decision point. That means the security model has to work across multiple protocols and services, not just at the front door. The important technical shift is that the agent is now a broker of intent, while the authorization server remains the authority that issues tokens for specific backend resources. Without that separation, protocol integration can hide privilege expansion behind a smooth developer workflow.

Practical implication: Treat every agent-to-agent and agent-to-server hop as an independent authorization boundary with explicit token checks.

Why token attributes are the real policy engine

The article’s token example shows why claims-based authorization is more precise than static role assignment for agentic systems. Attributes such as customer_id, region, scope, client_type, and agent_id let APIs decide whether the request matches the intended business context. That is especially important when an agent can make mistakes or be manipulated, because the API must compare the requested action with the claims in the token. In practice, this is closer to attribute-driven authorization than to generic authentication. The agent does not need broad identity power. It needs a token whose contents are rich enough for the API to make a deterministic allow or deny decision.

Practical implication: Design token claims with the minimum runtime attributes your APIs need, then enforce them at the resource server.

Threat narrative

Attacker objective: Induce the agent to perform backend actions or retrieve data outside the authorised user, customer, or region scope.

1. A user issues a natural-language command to an agent, and the agent translates that command into backend requests through A2A and MCP integrations.
2. The agent receives scoped OAuth 2.0 access rather than a permanent API key, so the token becomes the control point for what the backend will honour.
3. A malicious or mistaken prompt can try to steer the agent toward an unauthorised data request, but the API rejects it when the token claims do not match the requested action.
4. If the access model were based on standing credentials instead of short-lived tokens, the same prompt path could expand into broader backend access and unsafe data exposure.

Breaches seen in the wild

• Storm-1283 OAuth apps abuse 2023: Storm-1283 added secrets to new and existing OAuth apps in Entra ID and used them to run Azure cryptomining VMs, costing victims up to $1.5 million.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Token scope, not agent intent, is the governing unit: AI agents can translate natural language into backend action, but authorization still has to be enforced at the token boundary. The moment the agent can request resources on behalf of a user, the security problem becomes whether the issued token precisely limits customer, region, purpose, and audience. Practitioners should stop treating the prompt as the control plane and treat claims as the real enforcement layer.

Permanent credentials are structurally wrong for agentic workflows: A standing API key assumes the subject will remain trusted across many future actions, but an agent’s runtime behaviour can shift with context and input. That assumption fails when the actor can change task shape inside the session and trigger a different backend action than originally intended. The implication is that persistent access is the wrong governance model for AI-mediated execution.

Access intelligence is becoming the missing identity discipline for AI systems: The article points to a future in which identity teams design tokens while developers consume them as a service. That is a useful division of labour because token issuance, claim design, and token exchange now determine whether an agent can act safely across internal and external organisations. For IAM programmes, this makes authorization design an operational architecture issue, not a late-stage integration detail.

MCP and A2A expand the number of decision points without removing policy responsibility: Once agents can call servers and other agents, the authorization problem becomes distributed across several hops. Each hop needs deterministic policy that can survive protocol translation, and each backend must be able to reject a request even when the upstream agent sounds legitimate. Practitioners should treat distributed agent workflows as a chain of authorisation checks, not a trust inheritance path.

Named concept: runtime token governance for agents: This article describes a pattern in which authorization is encoded into short-lived tokens with runtime attributes rather than embedded in the agent itself. That approach gives identity teams a way to govern changing context without handing the agent durable privilege. The practical conclusion is that enterprise AI governance now depends on how well runtime token governance is designed and enforced.

What this signals

Runtime token governance is the practical control boundary for agentic systems: once an agent can turn natural language into backend execution, the governance programme has to move from generic identity assurance to claim-level authorisation. The useful question is whether your APIs can distinguish approved intent from merely plausible intent using token contents alone.

Enterprises should expect the most durable AI security designs to separate orchestration from authority. Agents can still be useful at the interaction layer, but the security model only holds when a dedicated authorization service issues the exact token shape the resource server needs.

The implementation pattern here is not unique to Azure Foundry or MCP. Any workflow in which an agent can act on behalf of a person or another service needs the same discipline around scope, runtime attributes, and approval-gated elevation.

For practitioners

• Enforce short-lived token issuance for agents Replace permanent API credentials with short-lived OAuth 2.0 access tokens that are scoped to a single task, resource, customer, or region.
• Design claims for backend authorization Include runtime attributes such as purpose, audience, customer_id, region, and agent_id so APIs can make deterministic allow or deny decisions.
• Separate developer experience from policy authority Let developers call simple APIs while an identity team owns token design, token exchange, and the authorisation server that issues access.
• Require approval before privilege escalation Use human approval as the gate before an agent receives a higher-privilege token for conditions such as purchase execution or external collaboration.
• Validate agent and MCP endpoints equally Apply authentication and authorization checks to internal endpoints as well as internet-facing APIs so internal network placement does not become a trust bypass.

Key takeaways

• AI agents need authorization built around scoped tokens because natural-language prompts can otherwise reach backend actions they were never meant to trigger.
• The key design choice is not the interface the agent uses, but whether the resource server can verify customer, region, purpose, and privilege from the token alone.
• Human approval and token exchange become the control points that keep agentic workflows useful without turning them into standing access paths.

Key terms

• Short-lived access token: A short-lived access token is a time-limited credential that reduces how long a stolen token can be reused. In agentic systems, it is only effective when paired with narrow scope, server binding, and policy checks that limit what the token can do.
• Token Exchange: Token exchange is an OAuth pattern that swaps one credential or token for another with narrower scope or different trust context. In NHI governance, it is useful when a workload must cross boundaries without carrying broad, reusable privileges into downstream systems.
• Runtime Attribute: A runtime attribute is a claim embedded in a token that describes the current context of use, such as customer, region, purpose, or client type. It allows resource servers to make an allow or deny decision based on the task in front of them, not just on the caller's identity.
• Agent Authorization: Agent authorization is the decision process that determines whether a software agent may take a specific action at runtime. It evaluates context, delegated authority, and resource sensitivity at the moment of execution, not only at login or provisioning time.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.