Updated October 26, 2026
· ~3 min read
The first rule of agent identity is that the agent is not the user. An agent acting for someone needs credentials that carry that person's permissions, no more, and that can be traced back to both the person and the agent. Three problems follow: how the agent gets tokens to call other services on a user's behalf (outbound), how a human approves something the agent wants to do while they are away (asynchronous consent), and how your own APIs and MCP servers recognise and authorise agents (inbound).
Four approaches have emerged. Amazon Bedrock AgentCore Identity vaults OAuth tokens and handles on-behalf-of access for agents on AWS. Auth0 for AI Agents adds a Token Vault and every form of CIBA — Client-Initiated Backchannel Authentication, the standard for "approve this on your phone" — for 50% on top of an Auth0 plan. Okta's Cross App Access implements the Identity Assertion Authorization Grant (ID-JAG), letting an enterprise identity provider issue short-lived assertions so an agent can call another company's app for a user without a consent prompt for each pairing. And Cloudflare Access fronts internal apps and MCP servers with Managed OAuth (April 2026) and MCP server portals.
An MCP server that needs authorisation acts as an OAuth 2.1 resource server: it must publish OAuth Protected Resource Metadata (RFC 9728) pointing to its authorization server, and clients discover everything from there. The 2025-11-25 revision made Client ID Metadata Documents — a client identified by an HTTPS URL to its own metadata — the recommended way for clients and servers with no prior relationship to meet. The 2026-07-28 revision went further: it deprecated Dynamic Client Registration in favour of those documents (it remains for backwards compatibility), required clients to validate the issuer in authorization responses (RFC 9207), and bound client credentials to the authorization server that issued them. If you built MCP auth in 2025 around Dynamic Client Registration, plan the change.
Question 1 of 2
Are you building agents, or a product that agents will call?
Building agents on AWS: use AgentCore Identity for outbound tokens and on-behalf-of flows, and Gateway with Policy for what agents may call. Building a SaaS product whose customers will connect their own agents: make your API and MCP server a proper OAuth resource server per the MCP authorization spec — with Auth0, Cognito or your own authorization server — and plan to accept Cross App Access assertions as enterprise customers ask for them. Selling to enterprises on Okta: Cross App Access is how their IT teams will want agent access governed. Exposing internal tools to agents quickly: put them behind Cloudflare Access with Managed OAuth or an MCP server portal rather than handing out service-account keys.
Identity for AI Agents and MCP Authorization
Make your product safe for AI agents to use and your own agents safe to run: an OAuth resource server and MCP authorization that follow the current spec, on-behalf-of tokens from a vault, human approval for consequential actions, and an audit trail that names both the person and the agent.
Secure LLM Gateway on AWS
One governed way for every team to call AI models: keys held centrally, budgets and rate limits per team, fallbacks between providers, and hardening that assumes the gateway is a target.
Production GenAI Platform on AWS
Deploy secure, scalable AI systems using AWS-native GenAI services. RAG, agent orchestration, and guardrails: production-ready.
We work with startups and growing companies on AWS architecture decisions. Tell us about your situation and we will recommend the right approach.
As of October 26, 2026. Provided as is, for general information, and accurate to the best of our knowledge on the date shown. Not legal, compliance, tax, financial or other professional advice. Prices, limits and vendor services change; check current vendor documentation before relying on anything here. Terms of use.