Let Them: A Developer's Guide to UMA for Agents | Multiplier PartnersSkip to contentLet Them: A Developer's Guide to UMA for Agents<br>Written by: Nick Gamb<br>Published: August 06, 2026

Copy page▾

SHARE:in𝕏

There is a fight happening right now over how AI agents should prove who they are. Centralized or decentralized. Ephemeral or enrolled. A new identity type in your IdP, or a cryptographic key that never touches one. Every vendor has a position, most of them have an acronym, and a good deal of the noise is non-human identity marketing wearing a new hat.

I want to make an argument that will sound like a dodge and is not: let them.

They want to use Okta for agent identity? Let them. They want AAuth? Let them. Ephemeral keys minted per session? Let them. Decentralized identifiers, verifiable credentials, a workload identity from their cloud provider? Let them.

I borrowed the framing from Mel Robbins, whose Let Them Theory is about the freedom you get when you stop trying to control what other people do. It applies almost too neatly to identity architecture. The energy going into controlling how someone else's agent attests itself is energy not going into the thing that actually protects you: what happens when that agent shows up at your resource server and asks for something.

That is the part you own. That is the part nobody is specifying.

The gap: RqP ≠ RO

Here is the distinction the whole argument rests on, in the vocabulary UMA has used since 2015.

The resource owner (RO) is the person or organization whose stuff it is. The requesting party (RqP) is whoever is asking. In classic enterprise SSO these collapse into one another, because the employee asking for the file and the employer who owns the file are inside the same trust domain. One IdP. One policy home. One vendor.

An agent economy is not shaped like that.

Bob is a financial advisor. Alice is his client. Bob's firm runs an agent, and that agent wants to read Alice's holdings. Bob's employer federated Bob's identity. Bob's employer did not federate Alice. Alice does not work there. Alice has never heard of their IdP.

So when Bob's agent knocks on Alice's brokerage:

Who is the requesting party? Bob, or his firm, or the agent acting for them.

Who is the resource owner? Alice.

Whose authorization server decides? This is the entire question.

Every agent-identity protocol on the table answers "is this my agent doing my task?" That is a real question and worth answering well. None of them answers "may your agent touch my stuff?" — because answering it requires an authority sitting on the owner's side of the line, and a negotiation to fill it.

UMA worked that out a decade ago. It did not need a new primitive. It needed agent-shaped mechanics.

Two shapes

On the left is the shape most of the market is building: Cross-App Access and Enterprise-Managed Agents. An IT admin consents once, org-wide. The IdP issues a scoped token through an ID-JAG exchange. The MCP server consumes the token and has no policy voice of its own. It works, it ships, and inside one trust domain it is genuinely useful.

Look at what is missing. Alice is in the diagram as a red box, and the label is the point: no message in the protocol reaches her. No terms. No ask-me. No per-operation grant. No owner revocation. The protocol assumes RO is the enterprise, because in the case it was designed for, it is.

XAA and EMA solve intra-domain distribution. That is the RO = enterprise special case . U4A is the general case, and an agent economy is made almost entirely of general cases: my doctor's agent, my advisor's agent, my lawyer's agent, my kid's school's agent, all touching resources whose owner does not work for the company that built the agent.

On the right, the ticket is minted at Alice's authorization server from message one. Policy lives with the person.

What the resource server actually does

The move is to stop treating the resource server as a token consumer and start treating it as the place where the owner's terms are enforced.

Concretely, in the U4A proof of concept, an agent calls an MCP tool and gets refused:

HTTP/1.1 401 Unauthorized<br>WWW-Authenticate: UMA realm="alice-vault",<br>error="insufficient_authorization",<br>as_uri="https://alice-as.uma.lab",<br>ticket="",<br>resource_metadata="https://gateway.uma.lab/.well-known/oauth-protected-resource/mcp",<br>scope="trades:execute",<br>authorization_remediation=""

Two parameters carry the whole idea. as_uri names Alice's authorization server, not the agent's. ticket is an opaque handle to a negotiation that has already started on her side.

That challenge is deliberately a superset of the RAR-metadata step-up draft rather than a rival to it. error and authorization_remediation are draft-zehavi-oauth-rar-metadata unchanged, so a client that implements that draft can read most of this without knowing UMA exists. Decoded, the remediation object is ordinary RAR:

"authorization_details": [{<br>"type":...