Ok, quick scenario. You’ve built an AI agent that needs to hit three different APIs on a user’s behalf, and each API is protected by OAuth. Totally normal use case.
Except that this time, your agent needs to be autonomous. It’s making a decision at runtime about where to go get a token, for a resource it may have never talked to before, and if it guesses wrong, you’ve got a problem that shows up in a CVE writeup.
This is exactly the gap that Protected Resource Metadata (PRM, defined in RFC 9728) was built to close. While we talk about PRM, we’re also going to talk about “AS discovery”. This is a mechanism that PRM enables and is one of those unglamorous plumbing standards that’s suddenly load-bearing because (who knew?!?!) agents exist now.
The Problem Nobody Had To Solve
Here’s the thing about classic OAuth: the client almost always knew who the authorization server was in advance. You registered your app with your IdP ahead of time and you were good to go. The AS was a fixed point, so discovery (if it happened at all) was AS-side. You always had a .well-known wiht “Here’s my issuer, here’s my token endpoint, here’s my JWKS” via the OIDC we know and love.
Because this was the flow, nobody needed to build a standard way for a resource server to say “here’s who’s allowed to issue tokens for me,” because clients didn’t need to ask.
Agents (to no ones suprise) break that assumption. An agent might discover a new tool or API mid-task and it wants to figure out on the fly, which authorization server it’s supposed to trust for that resource. Without a standard for this, you generally get one of two outcomes: 1) every agent framework invents its own bespoke discovery convention (chaos), or F) agents start trusting whatever AS a resource claims to be governed by, no verification required (worse, that’s why it’s F… for ‘real F**ed up).
What PRM Actually Does
RFC 9728 gives resource servers a standard, well-known metadata document (served at /.well-known/oauth-protected-resource, the .well-known endpoints just like OIDC normally uses) that answers one specific question: Which authorization server(s) issue valid tokens for this resource?
That’s it. That’s the whole job. Go throw a party. The document simply includes:
- The resource identifier
- A list of authorization servers the resource trusts
- Some optional metadata about supported scopes and bearer methods
A client (think agent) hits that .well-known endpoint first, gets back an answer from the MCP server or API endpoint itself, and then goes and does AS discovery (RFC 8414 or OIDC Discovery) against whichever authorization server got named.
It’s a quick two-step dance: discover the AS via PRM, then discover the AS’s own endpoints via its own metadata. Part over, go home.
Why This Matters More for Agents Than It Ever Did for Apps
A human developer wiring up OAuth reads documentation, copies a client ID, and hardcodes an issuer URL. That flow unfortunately didn’t go away with DCR and it’s not going away now. It’s a trust decision made by a person, once, with all the necessary context.
An agent doing dynamic resource discovery is making that trust decision at runtime, unsupervised, potentially thousands of times a day. If there’s no standard mechanism for a resource to authoritatively declare its trusted authorization servers, you’re relying on the agent (or its framework) to just… know. Or worse, to trust a value some prompt or config handed it, which is precisely the kind of thing that turns into chaos.
PRM gives agent frameworks a verifiable, standards-based source of truth instead of an assumption. This is also part of why it’s showing up as a building block in agent-to-agent and agent-to-tool identity work, especially in B2B applications with AI applications.
-> -> -> Look here. Read this -> -> -> What PRM Does Not Do
It does not:
- authenticate the client.
- issue tokens
- tell you anything about required scopes for specific operations (though scopes can be optionally listed)
- does not replace token validation or introspection
I did not say that. Nowhere in this article claims that.
I’ve seen this misunderstanding twice already. Do not treat PRM as if publishing it is itself a security control. It’s just a discovery mechanism. The security control is what you do with the information, just like it always has been. We still need to validate audience, scopes, the issuer, and everything else, PRM just makes sure everyone’s starting from the same map.
TL;DR
- RFC 9728 (PRM) lets a resource server publish a well-known endpoint that points to which authorization servers it trusts.
- This is something OAuth never standardized because clients used to know this in advance.
- Agents changed that (suprising no one): runtime, unsupervised resource discovery needs a verifiable source of truth instead of a guess or a config value.
- PRM discovery is step one of two. First, find the trusted AS via PRM, then discover that AS’s own endpoints via RFC 8414/OIDC Discovery.
- PRM is a discovery mechanism, not a security control on its own. Publishing it doesn’t replace audience validation and issuer checking on the resource server side.
- This is foundational plumbing for agentic identity work. it’s the kind of unglamorous standard that props up all kinds of fun new functionality.