Does my API tell an AI agent where to get permission?
When an agent reaches an API that needs permission, it has to find out who grants that permission. Protected-resource metadata is the answer, published by the API itself: which authorisation server to ask and what it can request. It is RFC 9728, and it is where an MCP server's sign-in handshake begins.
What it actually is
Imagine a locked door with a note beside it saying which office issues the keys. The door is your API, and the note is a small JSON file at a well-known address on it. An agent that is turned away reads the note, goes to the right authorisation server, and comes back with a token.
Why it matters
Without the note, an agent that hits a locked API has nowhere to go; a person has to configure it by hand. The MCP specification builds its authorisation on this standard, so an MCP server that needs sign-in and does not publish it is harder for the very assistants it was built for to use.
What good looks like
Metadata at the standard address on the API or MCP server you protect, naming that resource correctly and pointing to an authorisation server that exists, ideally also announced in the response an agent gets when it is first refused.
Being honest about it
This is an Advanced check: it never fails a page and stays out of your headline score. It is a ratified IETF standard, but it only matters if you run an API or MCP server that needs sign-in. For an ordinary website a warning here is the expected result, and publishing it without an API behind it would describe something that is not there.
Where most sites go wrong
The usual gap is an API that answers a refused request with a bare error and no pointer, so an agent learns that it is locked out and not how to get in. The other is metadata that names the wrong resource, often copied from a staging setup, so the token an agent obtains is not accepted.
On the web
State of the Web · November 2026In November 2026, 2% of the sites we could read passed the “OAuth protected-resource metadata” check.
Shopify sites pass it most often, at 89%. Webflow sites pass it least often, at <1%.
On the sites scanned in both October 2026 and November 2026, it went from 10% to 9%.
The month-by-month line counts the sites scanned in each calendar month, so it can differ from the figure above, which uses each site’s latest scan from the last three months.
Goes with
-
Sites that pass this are twice as likely to pass the “This page declares its canonical URL” check too. 99% of the sites that pass the first check pass this one, against 56% of the sites that do not.
-
Sites that pass this are 1.5 times as likely to pass the “Structured data is present” check too. 84% of the sites that pass the first check pass this one, against 54% of the sites that do not.
Not enough history yet.
Based on the sites Bot Appétit has scanned. Most of these sites come from lists we scan for research. Not a random sample of the web.
Not sure where yours stands?
A free scan checks this and everything else in about 20 seconds — no signup. Or if it's already flagged and you'd rather it were simply handled, we do that too.
Flagged for this one? We handle it. No pitch, just a plain-English chat.
Book a call