When software acts for people, identity has to answer new questions: whose permissions does the agent carry, who approved this action, and how does your API tell a real agent from an impersonator? The patterns that work (on-behalf-of tokens, asynchronous approval with CIBA, Cross App Access, MCP's OAuth model and signed agent traffic) and what to build first.
Whose permissions does this request carry? An agent acting for Maria should be able to do what Maria can — not what the agent's service account can, and not what every user of the agent can.
Who approved this? For anything consequential, a human should have said yes, and the system should be able to prove it later.
Is this really an agent, and whose? Your site and API increasingly receive automated traffic that claims to act for real users.
The safe pattern is delegation, not impersonation. The agent obtains a token scoped to the user and to the task (through an OAuth flow the user completes once, or a token exchange from the user's own session) and the identity system keeps those tokens in a vault rather than in the agent's memory or logs. Amazon Bedrock AgentCore Identity and Auth0's Token Vault both exist for exactly this: the agent asks for a token for a user and a service at the moment it needs one, and never holds long-lived credentials itself.
Book a free 30-minute call. You'll leave knowing what we'd do first and roughly what it costs, whether or not you hire us.
Agents work while people are away, so "click to approve" does not fit. CIBA — Client-Initiated Backchannel Authentication — is the OpenID standard for sending an approval request to the user's device and waiting for the answer: "Your assistant wants to pay this $1,240 invoice. Approve?" Auth0 for AI Agents includes every form of CIBA; the pattern is worth implementing whichever provider you use, for any action that moves money, sends on someone's behalf or deletes.
In a company, the question is less "did the user consent" and more "did IT allow this agent to reach that app for these users". Okta's Cross App Access implements the Identity Assertion Authorization Grant: the enterprise identity provider issues a short-lived signed assertion (an ID-JAG) for the user, and the agent exchanges it at the target application for an access token — no consent screen per pairing, and every connection visible and revocable in one admin console. Auth0 can act as the receiving side, so a SaaS product on Auth0 can accept these assertions with configuration rather than code. Expect enterprise security questionnaires to start asking for it.
Your MCP server and API: be a proper OAuth resource server. The MCP authorization spec requires Protected Resource Metadata (RFC 9728) so clients can discover your authorization server, and since the 2026-07-28 revision prefers Client ID Metadata Documents over Dynamic Client Registration.
Your website: Cloudflare's Web Bot Auth lets agent operators sign their HTTP requests with keys published at a well-known directory, and Cloudflare classifies them as signed agents — so you can allow ChatGPT agent while blocking an impersonator using the same user-agent string.
Your internal tools: put them behind an access proxy that speaks OAuth to agents — Cloudflare Access's Managed OAuth does this for any app behind it — rather than issuing service-account keys.
Log every agent action with two identities: the human it acted for and the agent that acted.
Scope agent tokens to the user and the task, short-lived, from a vault — never a shared admin key.
Human approval, by CIBA or in-app confirmation, for anything irreversible.
Make your own API an OAuth resource server per the MCP spec, so customers' agents can connect properly instead of scraping.
Decide your stance on automated traffic to your site, and enforce it with signed-agent verification rather than user-agent strings.
Once a month: what changed in tech that month and what it means for you, from cloud and AI to security and the tools you build with. Every item links to its source. No sales pitch, unsubscribe in one click.
Book a free 30-minute call about it. Bring your setup and your bill; you'll leave knowing what we'd do first and roughly what it costs, whether or not you hire us.
Or keep reading
MCP Authorization After the July 2026 Spec: What Changed and What to Update
The 2026-07-28 MCP revision made the protocol stateless, deprecated Dynamic Client Registration in favour of Client ID Metadata Documents, required issuer validation and bound client credentials to their authorization server. What each change means for MCP servers and clients you have already built.
Read
Where Cloudflare Fits in Your Identity Stack in 2026: Access, Turnstile, Signed Agents and MCP Portals
In 2026 Cloudflare sits in front of more identity decisions than most identity products: who reaches internal apps, which bots reach your sign-up form, which AI agents reach your site and which MCP servers your staff's agents may use. What each product does, and how it combines with Cognito, Auth0 or Okta behind it.
Read
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.