Agents are the new crawlers
Security teams increasingly use AI agents to orchestrate domain monitoring and threat enrichment rather than manually clicking through dashboards or writing ad‑hoc scripts. Those agents need to discover APIs, understand how to authenticate, and consume structured data on behalf of human operators, not just parse HTML like traditional crawlers. Cloudflare’s Agent Readiness score at isitagentready.com made this explicit by measuring how well sites support agents across discoverability, content, bot access control, and capabilities. Primitive Host wanted its domain intelligence platform to be usable by agents as easily as by humans, which meant adopting the emerging OAuth discovery standards instead of relying purely on documentation. rfc-editor
What RFC 9728 actually defines
OAuth 2.0 Protected Resource Metadata (RFC 9728) defines a metadata format that OAuth 2.0 clients or authorization servers can use to obtain the information they need to interact with a protected resource. Concretely, it specifies a JSON document exposed at a well‑known URI such as /.well-known/oauth-protected-resource that describes the resource’s identifier, supported token types, possible authorization servers, scopes, and related endpoints. This fills a gap in the OAuth ecosystem: authorization servers already publish metadata via RFC 8414, and clients can self‑register via dynamic client registration (RFC 7591), but resource servers previously had no standardized way to describe their own authorization requirements. ashishsrivastav
The protected resource metadata document lives at a deterministic location derived from the resource identifier’s URL, typically by inserting /.well-known/oauth-protected-resource between the origin and any path or query components, which means agents can always attempt a GET to that path when they encounter an unknown protected API. RFC 9728 also introduces the resource_metadata parameter in the WWW-Authenticate header, allowing a resource server to point clients to this metadata document in a 401 Unauthorized response. Together, these mechanisms let agents walk from “I tried to call an API and got a 401” to “I know exactly which issuer to talk to and which scopes to request,” without reading docs or guessing configuration. rfc-editor
Why RFC 9728 matters for a domain intelligence platform
Primitive Host exposes normalized domain intelligence across hundreds of millions of domains and thousands of zones via APIs that support brand abuse detection, malicious domain alerts, and threat enrichment workflows. These APIs are invoked in high‑volume, automated pipelines, and are a natural fit for agents that ingest new registrations, correlate DNS changes, and enrich SOC alerts with registration and zone context. If agents cannot discover how those APIs are protected, they fall back to scraping HTML or relying on manually configured secrets, which is slower, less reliable, and harder to govern. blog.cloudflare
At the same time, modern agent ecosystems and standards—especially the Model Context Protocol (MCP)—increasingly treat RFC 9728 as a requirement for authenticated tools. MCP servers are expected to expose protected resource metadata and authorization server metadata so agents can learn how to authenticate and obtain scoped tokens for each tool they call. By implementing RFC 9728, Primitive Host ensures its domain intelligence APIs can participate cleanly in those ecosystems, making it easier for AI agents to access the same data that human analysts and scripts already use. primitive
Where we started: an agent‑readiness gap
Our starting point was running Cloudflare’s Agent Readiness scan against primitive.host via the public checker at isitagentready.com. The initial score showed that our publication layer was solid but our capabilities layer was weak: agents could not discover our protected API or its authorization requirements from the surface alone. We had public landing pages describing the product and linking to /api/v1/ documentation, but no machine‑readable hints about auth, and 401 responses from the API did not include any WWW-Authenticate guidance for non‑human clients. digitalstrategyforce
Operationally this meant every integration depended on out‑of‑band documentation and human configuration. A human developer could read the docs, learn that Primitive Host uses bearer tokens, and copy a token into their config. An AI agent starting from a URL and a blank configuration, however, had no standard way to discover what kind of token it needed, where to obtain one, or whether any OAuth flows were involved. That agent‑readiness gap is precisely what RFC 9728 is designed to close. agentgrade
The OAuth Protected Resource metadata document on primitive.host
After implementing RFC 9728, Primitive Host now publishes its protected resource metadata at:
https://primitive.host/.well-known/oauth-protected-resource
This JSON document describes the resource identifier for our domain intelligence APIs, the supported token types (Bearer), and how clients should treat our Personal Access Tokens (PATs). In environments where we later introduce full OAuth flows, the same document can list one or more authorization servers via the authorization_servers array, but today it focuses on explaining how agents can use PATs as Bearer tokens to access /api/v1/ endpoints. self-issued
Because the location follows the RFC’s well‑known URI rule, any RFC‑9728‑aware client or framework can perform a simple GET against https://primitive.host/.well-known/oauth-protected-resource, parse the JSON, and immediately understand how Primitive Host’s resource expects to be accessed. This moves the integration burden away from human‑written configuration and toward standard discovery, which is exactly what agent‑ready infrastructure is supposed to provide. django-oauth-toolkit.readthedocs
WWW‑Authenticate hints for metadata discovery
Publishing the metadata file is only half the story; agents still need a way to find it when they make an unauthenticated call to a protected URL. RFC 9728 addresses this by introducing a new resource_metadata parameter in the WWW-Authenticate header so resource servers can advertise the metadata URL directly in their 401 challenges. For example, a resource server can return: rfc-editor
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://primitive.host/.well-known/oauth-protected-resource"
Primitive Host adopted this pattern so that when an agent hits a protected endpoint like /api/v1/zones/com/ without any credentials, the 401 response does more than say “missing or invalid token.” It tells the agent where to fetch the protected resource metadata, which then explains the token expectations and supported auth mechanisms. This aligns neatly with emerging guidance around agent‑ready protocol discovery and Cloudflare’s own use of RFC 9728 in its Managed OAuth and Agent Readiness tooling. primitive
Primitive Host’s current auth model: Personal Access Tokens
One important detail is that Primitive Host does not yet run a full OAuth 2.0 authorization server: there is no /authorize endpoint, no /token endpoint, and no multi‑step OAuth “dance” today. Instead, we use a Personal Access Token (PAT) flow designed for operational simplicity: a user generates a token in the dashboard—typically prefixed with ph_...—and sends it as a Bearer token in API requests. In practice, this looks like: primitive
Authorization: Bearer ph_xxxxxxxxxxxxxxxxx
RFC 9728 still applies in this model because it is agnostic about whether the resource server relies on PATs, OAuth tokens, or other bearer semantics; its goal is to describe the resource’s expectations in a machine‑readable way. Our protected resource metadata therefore documents that Primitive Host currently expects Bearer tokens of the ph_... form, obtained from the user’s dashboard rather than from a token endpoint, and that there is no authorization server metadata to discover yet. As we evolve toward full OAuth or Managed OAuth integrations—for example via Cloudflare Access—we will extend the same document to reference the relevant issuer URLs and scopes. getaibook
Operational benefits for security and research teams
For SOC analysts and brand protection teams, the immediate benefit is that their chosen AI agents can now integrate with Primitive Host as if it were any other well‑described OAuth resource: they can discover the metadata document, learn that Bearer PATs are required, and configure their workflows accordingly. Because the expectation is encoded in JSON rather than hidden in prose docs, agents and frameworks can automate more of the integration work, including handling 401 challenges that point at the protected resource metadata. academy.kspl
From a security perspective, PATs remain simple but auditable: they are tied to user accounts, can be rotated, and can be scoped to specific use cases within Primitive Host’s dashboard. As agents take on more of the workload—fetching new registrations, enriching alerts, or scanning for brand abuse across zones—the ability to treat PATs as first‑class Bearer tokens in an RFC‑9728‑described resource gives teams a cleaner operational surface than ad‑hoc API key conventions. primitive
Aligning with MCP and broader agent ecosystems
The latest Model Context Protocol specifications treat RFC 9728 and RFC 8414 metadata as the standard way MCP servers expose their authentication story to agents, making OAuth discovery a mandatory front door for authenticated tools. While Primitive Host does not yet operate a full OAuth authorization server, implementing RFC 9728 for our domain intelligence resource positions us well to participate in that ecosystem once we add token endpoints and issuer metadata. elliot-digital.co
Even before that evolution, broader agent platforms and CDNs such as Cloudflare already rely on RFC 9728 as the way agents walk from a 401 Unauthorized response to a discovered auth model. By publishing protected resource metadata at https://primitive.host/.well-known/oauth-protected-resource and advertising it via WWW-Authenticate, Primitive Host takes a concrete step toward being agent‑ready, giving AI systems the same predictable interface to domain intelligence that human developers enjoy today. rfc-editor
How RFC 9728 improved our agent‑readiness posture
After adopting RFC 9728, updating our 401 responses, and documenting our PAT expectations in protected resource metadata, our Agent Readiness posture improved in the “Capabilities” dimension because agents can now discover both the existence of our API and how it is protected. Instead of relying entirely on documentation or trial‑and‑error, an agent can follow a standard sequence: hit a URL, receive a 401 with resource_metadata, fetch https://primitive.host/.well-known/oauth-protected-resource, and learn that it must include a Bearer ph_... token obtained from the user’s dashboard. blog.cloudflare
Combined with other publication‑layer improvements—such as structured content for agents and emerging API catalog work—this makes Primitive Host materially more usable for autonomous systems that need continuous domain intelligence, not just for humans behind browsers and scripting environments. As agent ecosystems and standards continue to evolve, RFC 9728 gives us a stable foundation for describing how our resource is protected, whether via PATs today or full OAuth flows tomorrow. primitive