# agenticweb.wiki > Reference map of the agentic web's standards layer: nine lifecycle steps, one record per protocol, every claim sourced. The agentic web is the ordinary HTTP/DNS web extended with machine-native discovery files, signed identity headers, permission tokens, and invocation or payment protocols that let software agents discover, authenticate, act, and transact without scraping human UI. As of 2026-10-25, agenticweb.wiki maps 132 standards across 9 lifecycle steps (Discover, Identify, Permit, Read, Act, Coordinate, Pay, Present, Account) and 283 verified implementations. # Agentic web The agentic web is the ordinary web plus a layer of conventions that let software agents — rather than people driving browsers — discover what a site offers, prove who they are, learn what they may do, read its content, invoke its capabilities, coordinate with other agents, pay for what they use, present results to a person, and be held to account afterwards. None of this replaces HTTP, HTML or DNS. It sits on top of them: a set of well-known files, endpoints, headers and cards that a site can add so an agent does not have to guess. This site maps that layer as nine steps and treats every claim about it as something to source or mark as unverified, not something to assume. ## What "agentic" adds The conventional web was built for a person with a browser: pages carry visual layout, forms expect a human to fill them in, and a click is the unit of action. An agent arriving at the same URL has none of a browser's affordances to fall back on unless it renders the page like one, which is slow, brittle, and easy to break with a redesign. What "agentic" adds is a parallel, machine-native surface: a /.well-known/agent-card.json that states an A2A endpoint and its skills instead of a "Contact us" button; an MCP endpoint that exposes tools with typed schemas instead of a search box; a robots.txt with separate crawler tokens for search inclusion, model training and user-triggered fetches instead of one blanket disallow. The word does not describe a new network or a new browser. It describes a site choosing to publish, in a form an agent can parse without inference, the same things it already publishes for people. ## What it is not Agentic AI is a capability: a model that plans across multiple steps and calls tools to get something done. It can exist entirely inside one vendor's walls — a coding assistant editing files, a customer-support bot querying an internal database — with no reference to any other site's protocols at all. The agentic web is the opposite half of the picture: it is what a site publishes so that somebody else's agent, which it does not control and may never have heard of, can find and use it correctly. An agent can be highly capable and interact with zero agentic-web infrastructure; a site can publish a flawless Agent Card and still be talked to by a very simple bot. The Semantic Web proposed a universal, machine-readable ontology of meaning — RDF triples, OWL classes, a web where any two systems could in principle reason about the same facts. The agentic web makes no such bet. Its protocols are imperative and narrow: fetch this card, call this endpoint, sign this request, settle this payment. There is no shared ontology requirement and no expectation that an agent "understands" a site beyond what a card or schema tells it to do next. Web3 is a project about decentralised ownership and settlement, chiefly through blockchains. The agentic web borrows blockchain rails where they are useful for machine-to-machine payment — x402 and several of its adjacent proposals settle in stablecoins, and identity proposals such as ERC-8004 anchor agent registries on-chain — but most of the agentic web's standards layer (discovery files, agent cards, robots directives, HTTP signatures) has nothing to do with decentralisation and runs on ordinary client-server infrastructure that any single company can operate alone. Browser automation is an agent pretending to be a person: it opens a real browser, reads the rendered DOM or accessibility tree, and clicks buttons and fills forms designed for human hands. It works against any site, including ones that have done nothing to accommodate agents, but it is slow, breaks when a layout changes, and gives the site no way to distinguish a considerate agent from an adversarial scraper. The agentic web is the alternative a site can offer instead: a native interface — an MCP tool, an A2A skill, a signed request — that does not require pretending to be a browser at all. WebMCP sits at the boundary between the two: it lets a page register tools that an agent embedded in the visitor's own browser can call directly, rather than having that agent click through the rendered UI, but as of Chrome's origin-trial rollout announced 9 June 2026 it is still experimental and origin-scoped, not a universally available browser capability. ## The nine steps | # | Step | Question | Classic-web analog | Standards | | --- | --- | --- | --- | --- | | 1 | [Discover](/category/discover/) | What is here, and where? | sitemap, .well-known | 18 | | 2 | [Identify](/category/identify/) | Who is this agent? Who is this site? | TLS certificate, WHOIS | 22 | | 3 | [Permit](/category/permit/) | What may the agent do here? | robots.txt, terms of use | 32 | | 4 | [Read](/category/read/) | Give me the content | HTML, RSS | 6 | | 5 | [Act](/category/act/) | Do something for me | forms, REST APIs | 13 | | 6 | [Coordinate](/category/coordinate/) | Talk to another agent | none; agent-to-agent is new | 13 | | 7 | [Pay](/category/pay/) | Settle the bill | HTTP 402, finally used | 17 | | 8 | [Present](/category/present/) | Show a human the result | the browser | 4 | | 9 | [Account](/category/account/) | Prove what happened; be judged | logs, audit trails | 7 | An agent's path across a site can be described independently of any one protocol: it has to discover what is there, identify itself and the site, learn what it is permitted to do, read content, invoke a capability, coordinate with other agents where more than one is involved, pay if the resource is not free, present the outcome to a person, and leave a record that can be checked afterwards. This site organises every standard it tracks under one of these nine steps; each has a classic-web analogue that most of the concepts descend from. ## How the pieces fit together The steps are not independent of each other in practice. Discovery and identity typically arrive together: an A2A client fetches a site's Agent Card at /.well-known/agent-card.json (itself a use of the well-known-URI convention that RFC 8615 reserved in May 2019) and the card's own content — supported authentication schemes, provider identity — is what lets the client decide whether to trust what it just found. Permission sits alongside both: a robots.txt with distinct tokens for search crawling, training and user-triggered fetches (OpenAI's OAI-SearchBot, GPTBot and ChatGPT-User are documented as three separate policies, and Anthropic and Perplexity publish an equivalent three-way split) tells an agent what it may do with what it has found before it acts on it. Invocation then depends on what discovery handed over: an MCP client that has parsed a server's tools uses that same session to call them; an A2A client that has read a skill's input/output modes structures its request accordingly. Payment, where it appears, is a further step layered on top of invocation rather than a replacement for it — Google's Agent Payments Protocol (AP2) chains an intent mandate, a cart mandate and a payment mandate as cryptographically signed, scoped authorisations so a person can let an agent transact without handing it standing account access, while x402 instead resumes an HTTP request that received a 402 status by attaching a signed payment payload, optionally verified and settled by a third-party facilitator rather than the resource server itself. Both approaches assume identity and permission were already established upstream; neither one does discovery's job for it. ## What is shipping today Coverage varies sharply by step. The Model Context Protocol, published by Anthropic and now governed under the Agentic AI Foundation and the Linux Foundation, is implemented by multiple independent clients — Claude Desktop, Cursor and Zed among them — against its current 2026-07-28 specification, and is the protocol behind the OpenAI Apps SDK's tool ecosystem. The Agent2Agent Protocol (A2A), originated by Google and now under Linux Foundation governance, reports a stable 1.0.x line with adoption named by Google's own Agent Development Kit, by Microsoft's Agent Framework (from 28 April 2026) and by Microsoft Work IQ (from 21 August 2026). x402, from Coinbase and now stewarded by an x402 Foundation, has multiple independent facilitator services running in production across several blockchain networks handling verification and settlement on a resource server's behalf, alongside servers that "self-facilitate" the same logic in-process. Web Bot Auth's signed-request approach to bot identification has separate documented implementations from Google, Cloudflare and Vercel. AP2 launched with more than sixty named partner organisations. Against that, most of the other protocols this site tracks — the majority of the discovery and coordinate rows in particular — have a specification and, at most, one implementing organisation; this site marks that distinction on every protocol page rather than treating "has a GitHub repository" as evidence of use. ## Classic web to agentic web translation Every standard on this map replaces or extends a classic web mechanism that breaks when the visitor is an autonomous software agent rather than a person in a browser. The table below is compiled directly from each record's implementation tier ([IETF RFC 7942 / W3C running-code bar](/methodology/)) and live /check/ probe counts: | Classic web primitive | Step | Why it breaks for agents | Multi-implementation & shipping in production | Trial, prototype & paper drafts | | --- | --- | --- | --- | --- | | sitemap.xml & OpenAPI | [1 Discover](/category/discover/) | Lists human URLs or raw REST routes without agent skills or capability metadata | [RFC 9727](/protocols/api-catalog-rfc9727/) (multi-implementation · 132/1226 origins), [MCP Server Cards (SEP-2127)](/protocols/mcp-server-cards/) (multi-implementation · 131/1226 origins), [Agentic Resource Discovery](/protocols/ard/) (multi-implementation · 26/1226 origins) | [agents.txt](/protocols/agents-txt/) (prototype · 4/1226 origins), [agents.json](/protocols/agents-json/) (prototype · 2/1226 origins), [agent-permissions.json](/protocols/agent-permissions-json/) (prototype · 1/1226 origins), [A Framework for Agent Discovery in DAWN](/protocols/dawn-agent-discovery-framework/) (none found) | | DNS A/SRV & WHOIS | [1 Discover](/category/discover/) | Resolves hostnames to IP addresses, not agent endpoints or cryptographic keys | [Agent Identity and Discovery](/protocols/aid/) (shipping), [Agent Directory Service](/protocols/ads/) (shipping · 1/1226 origins), [OASF](/protocols/oasf/) (shipping) | [DNS for AI Discovery](/protocols/dns-aid/) (prototype), [Discovery of Model Context Protocol Servers via DNS TXT Records](/protocols/mcp-dns-discovery/) (none found), [Agent Name Service v2 (ANS)](/protocols/ans/) (none found) | | TLS certs & User-Agent strings | [2 Identify](/category/identify/) | User-Agent is trivially spoofed; IP allowlists break across cloud and residential proxies | [HTTP Message Signatures](/protocols/http-message-signatures/) (multi-implementation), [WebBotAuth](/protocols/webbotauth/) (multi-implementation · 12/1226 origins), [SPIFFE](/protocols/spiffe/) (multi-implementation), [ERC-8004: Trustless Agents](/protocols/erc-8004/) (multi-implementation), [The Agent Identity Document: A Hosted, Accountable Public Record for AI Agents](/protocols/agent-identity-document/) (shipping) | [Signature Agent Card (Web Bot Auth registry)](/protocols/web-bot-auth-signature-agent-card/) (prototype · 1/1226 origins), [WIMSE](/protocols/wimse/) (prototype) | | OAuth 2.0 consent screens | [3 Permit](/category/permit/) | Assumes a human clicking 'Allow' in an interactive browser redirect loop | [OAuth Protected Resource and Authorization Server Metadata (as used for agent authorization)](/protocols/oauth-metadata-for-agents/) (multi-implementation · 69/1226 origins), [CIMD](/protocols/oauth-cimd/) (multi-implementation · 37/1226 origins), [auth.md](/protocols/auth-md/) (multi-implementation · 23/1226 origins), [ID-JAG](/protocols/identity-assertion-authz-grant/) (multi-implementation · 6/1226 origins) | [Agent Authorization Grant](/protocols/aauth/) (none found), [DAAP](/protocols/daap/) (prototype), [Agent Authorization Profile](/protocols/aap/) (prototype), [AIMS](/protocols/wimse-aims/) (none found) | | robots.txt (Allow/Disallow) | [3 Permit](/category/permit/) | Binary crawl rules cannot separate search indexing, live RAG grounding, and model training | [AI Crawler User-Agent Tokens in robots.txt](/protocols/ai-crawler-tokens-robots/) (multi-implementation · 201/1226 origins), [Content Signals Policy](/protocols/cloudflare-content-signals-policy/) (multi-implementation · 185/1226 origins), [Really Simple Licensing](/protocols/rsl/) (shipping · 4/1226 origins), [TDMRep](/protocols/tdmrep/) (shipping · 5/1226 origins) | [AIPREF Vocabulary](/protocols/aipref-vocabulary/) (none found · 1/1226 origins), [AIPREF](/protocols/aipref-content-usage-attachment/) (none found · 1/1226 origins) | | HTML DOM & RSS feeds | [4 Read](/category/read/) | Layout boilerplate, navbars, and client JS waste 80%+ of context tokens | [llms.txt](/protocols/llms-txt/) (multi-implementation · 519/1226 origins), [Markdown for Agents](/protocols/cloudflare-markdown-for-agents/) (shipping · 214/1226 origins), [AGENTS.md](/protocols/agents-md/) (multi-implementation · 28/1226 origins), [Open Knowledge Format](/protocols/okf/) (shipping), [Agent Readability Spec](/protocols/vercel-agent-readability/) (shipping) | [OSI](/protocols/osi/) (prototype), [The 'knowledge-linkset' Well-Known URI for Publishing Knowledge Artefacts](/protocols/knowledge-linkset/) (none found) | | HTML forms & bespoke REST APIs | [5 Act](/category/act/) | Every site has custom form fields; browser automation breaks when UI layouts change | [Model Context Protocol](/protocols/mcp/) (multi-implementation · 140/1226 origins), [Agent Skills](/protocols/anthropic-agent-skills-format/) (multi-implementation · 111/1226 origins), [Agent Client Protocol](/protocols/agent-client-protocol/) (multi-implementation), [OpenAI Plugins (formerly Apps SDK)](/protocols/openai-apps-sdk-manifests/) (shipping) | [WebMCP](/protocols/webmcp/) (prototype), [NLWeb](/protocols/nlweb/) (prototype) | | Webhooks & microservice RPC | [6 Coordinate](/category/coordinate/) | Built for pre-integrated internal services, not cross-organization task delegation | [Agent2Agent Protocol](/protocols/a2a/) (multi-implementation · 54/1226 origins), [Agent Network Protocol](/protocols/anp/) (shipping), [SLIM](/protocols/slim/) (shipping), [Coral Protocol (CoralOS)](/protocols/coral-protocol/) (shipping), [AAMP](/protocols/aamp/) (multi-implementation) | [Agent-Channel Frame for Identity-Keyed Fan-Out Delivery to Concurrent Sessions](/protocols/agent-channel-fan-out/) (none found) | | HTTP 402 (unused since 1997) | [7 Pay](/category/pay/) | API keys and subscriptions require human signup, credit cards, and monthly billing | [x402](/protocols/x402/) (multi-implementation), [Machine Payments Protocol](/protocols/mpp/) (multi-implementation), [L402](/protocols/l402/) (shipping), [x401: HTTP Proof Requirement Protocol](/protocols/x401/) (shipping) | [Cloudflare Pay per crawl](/protocols/cloudflare-pay-per-crawl/) (prototype) | | 3-D Secure & card checkout | [7 Pay](/category/pay/) | Flags 'human-not-present' agent purchases as bot fraud; no cryptographic proof of user budget | [Agentic Commerce Protocol](/protocols/agentic-commerce-protocol/) (multi-implementation), [Universal Commerce Protocol](/protocols/ucp/) (multi-implementation · 3/1226 origins), [Agent Payments Protocol](/protocols/ap2/) (multi-implementation) | [Visa Trusted Agent Protocol](/protocols/tap/) (prototype), [Verifiable Intent](/protocols/vi/) (prototype), [ERC-8183: Agentic Commerce](/protocols/erc-8183/) (prototype), [ERC-8226](/protocols/erc-8226/) (prototype) | | Iframes & server-driven UI | [8 Present](/category/present/) | Text-only chat cannot render interactive approval cards, forms, or state sync safely | [AG-UI](/protocols/ag-ui/) (multi-implementation), [A2UI (Agent to UI) Protocol](/protocols/a2ui/) (multi-implementation), [MCP Apps](/protocols/mcp-apps/) (multi-implementation) | [A2WP](/protocols/a2wp/) (none found) | | Syslog, referrer cookies & T&Cs | [9 Account](/category/account/) | Cookies vanish when agents summarize; software processes are not legal persons | [Agent Attribution Protocol](/protocols/agent-attribution-protocol/) (shipping) | [OpenTelemetry GenAI Semantic Conventions (agents and MCP)](/protocols/otel-genai-semconv/) (prototype), [Agent Audit Trail](/protocols/agent-audit-trail/) (none found), [AIR](/protocols/scitt-ai-agent-execution/) (none found), [Agent Audit Record](/protocols/wimse-agent-audit-record/) (none found), [ADC](/protocols/agent-decision-commitment/) (none found) | ## Contested ground and whitespace by step Sorting the map by running-code maturity (multi-implementation = 2+ independent interoperable implementations; shipping = 1 production implementation; trial / prototype / none-found = non-production or paper spec) shows where the stack has converged, where competing specifications are fighting for the same slot, and where true whitespace remains: | Step | Total | Multi-implementation (2+ parties) | Single-party shipping | Trial / prototype / spec-only | Contested ground & whitespace implication | | --- | --- | --- | --- | --- | --- | | [1 Discover](/category/discover/) | 18 | 3 | 6 | 9 | Contested root manifests (llms.txt vs RFC 9727 vs ARD vs SEP-2127); DNS layer still early. | | [2 Identify](/category/identify/) | 22 | 4 | 3 | 15 | Converging on RFC 9421 / Web Bot Auth for HTTP signing and ERC-8004 for on-chain registries; 13 drafts competing on workload credentials. | | [3 Permit](/category/permit/) | 32 | 6 | 2 | 24 | Most crowded step (32 specs): active standards war in delegated OAuth (ID-JAG, auth.md, AAuth, DAAP) and AI content licensing (Content-Signal vs AIPREF vs RSL). | | [4 Read](/category/read/) | 6 | 2 | 3 | 1 | Converging rapidly on Accept: text/markdown, Markdown twins, AGENTS.md, and OKF. | | [5 Act](/category/act/) | 13 | 6 | 2 | 5 | Converged around MCP, Agent Skills (SKILL.md), and Zed ACP; in-browser WebMCP in origin trial. | | [6 Coordinate](/category/coordinate/) | 13 | 3 | 3 | 7 | Converging on Linux Foundation A2A for HTTP agent cards; pub/sub fan-out and ad-tech negotiation (AAMP) still contested. | | [7 Pay](/category/pay/) | 17 | 5 | 3 | 9 | Split into two parallel stacks: HTTP 402 micropayments (x402, MPP, L402) vs card-network checkout mandates (ACP, UCP, AP2, TAP, VI). | | [8 Present](/category/present/) | 4 | 3 | 0 | 1 | Small, fast-converging layer (AG-UI, A2UI, MCP Apps); cross-device human interrupt (A2WP) is early whitespace. | | [9 Account](/category/account/) | 7 | 0 | 1 | 6 | Largest whitespace on the map (only 1 of 7 specs shipping): post-hoc audit ledgers (SCITT), attribution, and [Agentic EoR](/terms/agentic-eor/) liability wrappers are mostly draft-stage. | ## Harness and client compatibility matrix A site's published manifests only matter if an agent harness or browser natively parses them. Across the [20 verified harnesses and clients](/instances/#tab-harness) tracked on this site, support currently concentrates on a small core of discovery, read, and tool-invocation standards: | Harness / Client | Native standards consumed or invoked | Observed | | --- | --- | --- | | [CopilotKit](https://www.copilotkit.ai) | [AG-UI](/protocols/ag-ui/), [A2UI](/protocols/a2ui/), [MCP Apps](/protocols/mcp-apps/), [A2A](/protocols/a2a/), [MCP](/protocols/mcp/) | 2026-08-14 | | [Google Agent Development Kit (ADK)](https://google.github.io/adk-docs/) | [A2A](/protocols/a2a/), [MCP](/protocols/mcp/), [AG-UI](/protocols/ag-ui/) | 2026-07-31 | | [Goose (Block)](https://github.com/block/goose) | [MCP](/protocols/mcp/), [AGENTS.md](/protocols/agents-md/), [Agent Skills](/protocols/anthropic-agent-skills-format/) | 2026-08-29 | | [GitHub Copilot Coding Agent](https://docs.github.com/en/copilot/how-tos/use-copilot-agents/coding-agent/create-custom-agents) | [AGENTS.md](/protocols/agents-md/), [MCP](/protocols/mcp/) | 2026-08-29 | | [pay.sh (Agent Payment CLI and Runtime)](https://pay.sh) | [x402](/protocols/x402/), [MPP](/protocols/mpp/) | 2026-09-04 | | [Aider](https://aider.chat/docs/usage/conventions.html) | [AGENTS.md](/protocols/agents-md/) | 2026-08-29 | | [Amp](https://ampcode.com) | [AGENTS.md](/protocols/agents-md/) | 2026-08-29 | | [Claude Code (Anthropic)](https://platform.claude.com/docs/en/agents-and-tools/claude-code/overview) | [Agent Skills](/protocols/anthropic-agent-skills-format/) | 2026-08-29 | | [Cursor](https://cursor.com) | [AGENTS.md](/protocols/agents-md/) | 2026-08-29 | | [Devin (Cognition)](https://devin.ai) | [AGENTS.md](/protocols/agents-md/) | 2026-08-29 | | [Elemen (AGTP Browser)](https://chrishood.com/introducing-elemen-the-worlds-first-browser-for-the-agent-web/) | [AGTP](/protocols/agtp/) | 2026-06-05 | | [Google Chrome (WebMCP Early Preview)](https://developer.chrome.com/blog/webmcp-epp) | [WebMCP](/protocols/webmcp/) | 2026-02-18 | ## Timeline, 2024–2026 The agentic web's standards did not arrive at once. Jeremy Howard's llms.txt proposal, a plain-Markdown convention for pointing language models at a site's documentation, dates to 2024, with no formal governance behind it. Anthropic published the Model Context Protocol in November 2024. Google followed with the Agent2Agent Protocol in April 2025, now on Linux Foundation track. Coinbase's x402 followed in May 2025, later gaining its own foundation and a 2026 v2 revision. IBM's Agent Communication Protocol, a separate agent-to-agent effort from its BeeAI team, was archived as a standalone specification on 29 August 2025, with its own repository stating it had been folded into A2A. Google launched its Agent Payments Protocol (AP2 v0.1.0) on 16 September 2025 with more than sixty launch partners, and donated the core specification to the FIDO Alliance on 28 April 2026 alongside v0.2.0. Cloudflare published its Agent Skills Discovery RFC (/.well-known/agent-skills/index.json, Draft v0.2.0) in January 2026. Google and industry partners announced Agentic Resource Discovery (ARD) on 17 June 2026, with the specification reaching its v0.91 text on 26 August 2026. The Model Context Protocol's most recent dated specification revision is 2026-07-28, accompanied by SEP-2127 MCP Server Cards (/mcp/server-card, finalized 6 October 2026), RFC 9727 API Catalogs (/.well-known/api-catalog), and Google Cloud's Open Knowledge Format (/okf/index.md). This site re-probes adoption across its /check/ readiness panel daily and publishes the day-over-day findings in the [daily digest](/digest/). ## Colliding acronyms "ACP" is not one protocol; it is four, from four distinct groups, across three different steps of this map. Zed's [Agent Client Protocol](/protocols/agent-client-protocol/) connects code editors to coding agents, at the Act step. AGNTCY's [Agent Connect Protocol](/protocols/agent-connect-protocol/) (Cisco, LangChain, Outshift) defines an OpenAPI execution descriptor and REST runtime lifecycle for invoking remote agents, also at the Act step. IBM's [Agent Communication Protocol](/protocols/agent-communication-protocol/) was an agent-to-agent messaging protocol at the Coordinate step, archived in August 2025 and, by its own maintainers' account, merged into A2A. OpenAI and Stripe's [Agentic Commerce Protocol](/protocols/agentic-commerce-protocol/) lets an agent complete a checkout with a merchant, at the Pay step, and is unrelated to any of the other three. Published guides and summaries routinely state a fact about one of these as though it applied to all four; the full picture is on the [ACP term page](/terms/acp/). ## Frequently confused claims Three claims recur in vendor and secondary material about this space and do not hold up as stated. Google-Extended does not control Google Search or AI Overviews. It is a separate token from Googlebot, documented as governing use of crawled content by Gemini apps and Vertex AI; Search and AI Overviews are covered by the ordinary Googlebot crawl, so disallowing Google-Extended alone does not remove a site from Google's AI-powered search surfaces. No mainstream answer engine documents reading llms.txt. Google's own generative-search guidance states plainly that no special markup or llms.txt file is required for its AI features, and no first-party documentation from ChatGPT Search, Perplexity, Claude, or Bing/Copilot lists it as something they fetch or use as a ranking or citation input; the file is a real, dated 2024 proposal with real adoption as a navigation aid, but that is a different claim from being consumed by answer engines. "ACP merged into A2A" is true only of IBM's Agent Communication Protocol. It says nothing about Zed's Agent Client Protocol, AGNTCY's Agent Connect Protocol, or the OpenAI/Stripe Agentic Commerce Protocol, all three of which remain independent, active specifications; treating the merger as if it settled anything about "ACP" in general conflates four unrelated projects that happen to share an initialism. ## Bibliography - [Model Context Protocol specification, 2026-07-28](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/docs/specification/2026-07-28/index.mdx) - [Agent2Agent Protocol specification](https://a2a-protocol.org/latest/specification/) - [A2A Agent Card discovery](https://a2a-protocol.org/v1.0.0/topics/agent-discovery/) - [Agent Client Protocol](https://agentclientprotocol.com) - [IBM Agent Communication Protocol repository](https://github.com/i-am-bee/acp/) - [OpenAI/Stripe Agentic Commerce Protocol repository](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol) - [x402 whitepaper](https://x402.org/wp-content/uploads/sites/10/2026/06/x402-whitepaper.pdf) - [x402 facilitator documentation](https://docs.x402.org/core-concepts/facilitator) - [Agent Payments Protocol specification](https://github.com/google-agentic-commerce/AP2/blob/main/docs/ap2/specification.md) - [AP2 Checkout Mandate](https://ap2-protocol.org/ap2/checkout_mandate/) - [Agentic Resource Discovery specification](https://github.com/ards-project/ard-spec/blob/main/spec/ard.md) - [Google's ARD announcement, 2026-06-17](https://developers.googleblog.com/en/announcing-the-agentic-resource-discovery-specification/) - [RFC 8615, Well-Known Uniform Resource Identifiers](https://www.rfc-editor.org/rfc/rfc8615) - [OpenAI crawler documentation](https://developers.openai.com/api/docs/bots) - [Anthropic crawler policy](https://support.claude.com/en/articles/8896518) - [Perplexity crawler documentation](https://docs.perplexity.ai/guides/bots) - [llms.txt](https://llmstxt.org) - [AGENTS.md](https://agents.md) - [Google's developer guide to AI agent protocols](https://developers.googleblog.com/developers-guide-to-ai-agent-protocols/) [Markdown](/agentic-web/index.md) · [JSON](/agentic-web/index.json) · [llms-full.txt](/llms-full.txt) ## Frequently asked questions - **What is the agentic web?**: The agentic web is the ordinary HTTP/DNS web extended with machine-native discovery files, signed identity headers, permission tokens, and invocation or payment protocols that let software agents discover, authenticate, act, and transact without scraping human UI. As of 2026-10-25, agenticweb.wiki maps 132 standards across 9 lifecycle steps (Discover, Identify, Permit, Read, Act, Coordinate, Pay, Present, Account) and 283 verified implementations. - **How does the agentic web differ from Agentic AI, the Semantic Web, and Web3?**: Agentic AI is a model capability inside one vendor's runtime, whereas the agentic web is the public protocol surface a site publishes so external agents can interact with it natively. Unlike the Semantic Web, it requires no universal ontology (only narrow, imperative manifests and endpoints), and unlike Web3 it runs on standard HTTP/DNS infrastructure, using blockchain rails only where useful for machine payments (such as x402) or on-chain identity registries (such as ERC-8004). - **What are the nine lifecycle steps of the agentic web?**: The nine steps an agent takes across a site are: (1) Discover what the site offers, (2) Identify the agent and origin, (3) Permit or restrict crawler and agent actions, (4) Read machine-formatted content, (5) Act by invoking tools or skills, (6) Coordinate with other agents, (7) Pay or authorize transactions, (8) Present UI to a human, and (9) Account via verifiable audit trails and legal counterparties. - **What is the difference between the four ACP protocols?**: ACP refers to four unrelated specifications at different lifecycle steps: Zed's Agent Client Protocol (Step 5, Act — connecting code editors to coding agents), AGNTCY's Agent Connect Protocol (Step 5, Act — OpenAPI execution descriptors and REST runtime lifecycle), IBM's archived Agent Communication Protocol (Step 6, Coordinate — merged into A2A in August 2025), and the OpenAI/Stripe Agentic Commerce Protocol (Step 7, Pay — merchant checkout for AI agents). --- # A Framework for Agent Discovery in DAWN A Framework for Agent Discovery in DAWN is an agentic-web standard (DNS record) at step 1, Discover, governed by IETF Internet-Draft in the DAWN working group context; its status is "Internet-Draft, Intended Status: Informational". It answers: "How can a client discover the minimum public information about AI agents across local and cross-organizational…?" Implementation status is none found, last verified 2026-10-23. ## Quick Wire Reference - **Step**: 1 Discover (What is here, and where?) - **Version**: draft-zhang-dawn-agent-discovery-framework-09 (2026-10-21) - **Status**: Internet-Draft (draft-zhang-dawn-agent-discovery-framework-09), Intended… - **Discovery / Probe Path**: Federation Metadata Records (FMRs) published as DNS resource records in a site's… - **Spec URL**: https://datatracker.ietf.org/doc/html/draft-zhang-dawn-agent-discovery-framework-09 - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: Federated DNS delegation and referral applied to agent discovery records [Discover](/category/discover/) An informational IETF Internet-Draft describing a two-layer federated reference architecture for initial discovery of AI agents under the DAWN charter. A Local Discovery Plane uses mDNS/DNS-SD or infrastructure-assisted discovery inside a site, while a Federation Plane exchanges Federation Metadata Records (a binding of Minimum Discoverable Information) between site gateways, using DNS (with DNSSEC) as its baseline and adding non-DNS and mixed-mode options such as proactive distribution and directory lookup. It includes an Export Policy Engine for data sovereignty and supports referral, delegation and indirection. It defines no normative formats and positions itself alongside ACAP and Agent Directory rather than replacing them. ## Discovery and probe Federation Metadata Records (FMRs) published as DNS resource records in a site's authoritative zone (Mode A, DNSSEC-validated), or synchronized between Federation Gateways via non-DNS modes (Mode B: BGP-like peering, gossip, trusted directory publication) ``` NONE parse: No concrete record format or name is defined in this informational draft, so support cannot be observed from a site. on absent: No inference; the draft defines no normative formats. ``` Not probed live: no-fixed-path. candidate record; probe rule pending ## History - 2026-10-16 — auto-drafted candidate from exa (https://datatracker.ietf.org/doc/html/draft-zhang-dawn-agent-discovery-framework-06) - 2026-10-20 — version -08 (2026-10-19) and summary re-read; watcher unpinned from -06 (gap scout 2026-10-20, verified via the IETF rsync mirror) - 2026-10-22 — revision draft-zhang-dawn-agent-discovery-framework-08 → 09 (watcher) ## Instances Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Pairs with: [DNS for AI Discovery](/protocols/dns-aid/), [Agent Registration and Discovery Protocol](/protocols/ardp/) ## References - The draft describes a two-layer federated reference architecture (Local Discovery Plane and Federation Plane) with Federation Gateways, an Export Policy Engine and Federation Metadata Records for initial agent discovery; it is informational and defines no normative protocol formats. — [https://datatracker.ietf.org/doc/html/draft-zhang-dawn-agent-discovery-framework-06](https://datatracker.ietf.org/doc/html/draft-zhang-dawn-agent-discovery-framework-06) (2026-10-15) REPORTED - Revision -08 (19 October 2026, expires 22 April 2027, Intended status: Informational; editors B. Zhang, L. Dunbar, Y. Yang) rewrites the abstract: local discovery via mDNS/DNS-SD or infrastructure-assisted discovery; federation with DNS as baseline plus non-DNS and mixed-mode mechanisms. — [https://datatracker.ietf.org/doc/draft-zhang-dawn-agent-discovery-framework/](https://datatracker.ietf.org/doc/draft-zhang-dawn-agent-discovery-framework/) (2026-10-19) VERIFIED - Datatracker shows draft-zhang-dawn-agent-discovery-framework-09, dated 2026-10-21, expires 2027-04-24 — [https://datatracker.ietf.org/doc/draft-zhang-dawn-agent-discovery-framework/](https://datatracker.ietf.org/doc/draft-zhang-dawn-agent-discovery-framework/) (2026-10-21) VERIFIED [JSON](/data/protocols/dawn-agent-discovery-framework.json) · [Markdown](/protocols/dawn-agent-discovery-framework/index.md) · [OKF v0.2](/okf/protocols/dawn-agent-discovery-framework.md) --- # A Server-Side Model for Gating Agent-Initiated Human-Sourced Asynchronous HTTP Tasks on Payment or Entitlement A Server-Side Model for Gating Agent-Initiated Human-Sourced Asynchronous HTTP Tasks on Payment or Entitlement is an agentic-web standard (document format) at step 7, Pay, governed by Individual IETF Internet-Draft submission, not adopted by a…; its status is "Internet-Draft, Intended Status: Informational". It answers: "How should a server gate paid, agent-initiated asynchronous HTTP tasks on payment or entitlement so that fulfilment…?" Implementation status is none found, last verified 2026-10-23. ## Quick Wire Reference - **Step**: 7 Pay (Settle the bill) - **Version**: draft-king-yew-choo-agentic-payments-01 (2026-10-08) - **Status**: Internet-Draft, Intended Status: Informational; expires 11 April 2027 · none… - **Discovery / Probe Path**: none; architectural model with no wire format or discovery element - **Spec URL**: https://datatracker.ietf.org/doc/html/draft-king-yew-choo-agentic-payments-01 - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: none [Pay](/category/pay/) An individual-submission Internet-Draft (Informational) presenting a server-side model for paid, human-sourced asynchronous HTTP tasks initiated by software agents. It places a payment or entitlement gate before fulfilment, maps the gate to adjacent protocols (HTTP Payment authentication scheme, MPP, x402, AP2), and defines a task state machine. Under stated assumptions it yields gate-before-fulfilment safety, at most one task per idempotency key, and at most one gate acceptance per payment requirement. It defines no wire format or conformance requirements. ## Discovery and probe none; architectural model with no wire format or discovery element ``` NONE parse: on absent: ``` Not probed live: no-fixed-path. candidate record; probe rule pending ## History - 2026-10-16 — auto-drafted candidate from exa (https://datatracker.ietf.org/doc/html/draft-king-yew-choo-agentic-payments-01) ## Instances Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Pairs with: [Machine Payments Protocol](/protocols/mpp/), [x402](/protocols/x402/), [Agent Payments Protocol](/protocols/ap2/) ## References - Internet-Draft draft-king-yew-choo-agentic-payments-01 published 8 October 2026, Intended Status Informational. It defines no protocol, wire format, or conformance requirements, and presents a server-side payment/entitlement gate (g*) and task state machine for agent-initiated paid asynchronous HTTP tasks. — [https://datatracker.ietf.org/doc/html/draft-king-yew-choo-agentic-payments-01](https://datatracker.ietf.org/doc/html/draft-king-yew-choo-agentic-payments-01) (2026-10-08) REPORTED [JSON](/data/protocols/agentic-payments-gating-model.json) · [Markdown](/protocols/agentic-payments-gating-model/index.md) · [OKF v0.2](/okf/protocols/agentic-payments-gating-model.md) --- # A2UI (Agent to UI) Protocol A2UI (Agent to UI) Protocol is an agentic-web standard (document format) at step 8, Present, governed by a2ui-project GitHub organisation; its status is "Early stage public preview: v0.9.1 is the 'Current' production…". It answers: "How can an agent describe and stream a framework-neutral, declarative UI to a renderer?" Replacing or extending HTML (declarative UI markup), implementation status is multi-implementation, last verified 2026-10-23. ## Quick Wire Reference - **Step**: 8 Present (Show a human the result) - **Version**: v1.0 (Candidate); v0.9.1 (Current) (2026-06-08) - **Status**: Early stage public preview: v0.9.1 is the 'Current' production release, v1.0… - **Discovery / Probe Path**: No fixed well-known path; renderer and agent capabilities (supported catalogs, custom… - **Spec URL**: https://github.com/a2ui-project/A2UI - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: HTML (declarative UI markup) [Present](/category/present/) A2UI (Agent to UI) is a JSON message protocol that lets an agent describe and incrementally stream a declarative, framework-neutral user interface to a client renderer. Communication is a stream of JSON objects; the agent-to-renderer protocol defines four message types — createSurface, updateComponents, updateDataModel, and deleteSurface — and the renderer maps abstract component descriptions (Card, Button, TextField, etc.) onto its own native widgets (Flutter, Angular, Lit, React, SwiftUI, or plain web components) [[1]](#ref-1). The core design goal is safety: agents can only reference components from a client-defined, pre-approved 'catalog,' so a UI payload is 'safe like data, but expressive like code' rather than executable code [[2]](#ref-2). ## Overview A2UI does not define its own transport. It is explicitly transport-agnostic and is documented with named bindings for three carriers: AG-UI (described as A2UI's 'standard transport binding'), the A2A protocol (via a dedicated A2A extension spec), and MCP (carried over tool calls, tool outputs, or resource subscriptions), plus generic support for SSE+JSON-RPC, WebSockets, and REST [[1]](#ref-1). It solves the problem of agents needing to present rich, interactive interfaces — especially remote agents or agents running across a trust boundary — without shipping arbitrary executable code to the client [[2]](#ref-2). It does not itself specify authentication, payment, or discovery of an agent's existence; those are left to whichever transport (AG-UI, A2A, MCP) carries it. Current state (as of 2026-09-05): the project describes itself as an 'early stage public preview.' The production-recommended version is v0.9.1 (a patch on the stable v0.9 family); v1.0 is a release candidate adding bidirectional typed function calls and single-message UI instantiation; v0.8 is legacy [[2]](#ref-2). The canonical repository, github.com/a2ui-project/a2ui, carries an Apache-2.0 license and Google LLC copyright headers, and the spec site's own 'view source' link resolves to that same repository [[1]](#ref-1)[[2]](#ref-2). Reference renderers exist for Flutter and web frameworks (Lit, Angular, React), with a visual 'A2UI Composer' and a multi-renderer 'A2UI Theater' demo; the AG-UI project ships an a2ui-toolkit package and CopilotKit has added catalog-forwarding integration, indicating active cross-project use rather than a single-vendor demo [[3]](#ref-3). What is disputed or unknown: whether A2UI should be classified as a single-vendor (Google) spec or something closer to a vendor-consortium is judgment-dependent — the code and copyright are Google's, but the working GitHub org name ('a2ui-project') and the AG-UI/CopilotKit integration suggest broader de facto involvement. AG-UI's own docs (fetched 2026-09-05) still point to github.com/google/A2UI rather than the current a2ui-project org, an unresolved naming/rename inconsistency. No independent adoption count exists; observed ecosystem activity (16.3k GitHub stars, AG-UI/CopilotKit integration, multiple demo renderers) has not been converted into a documented probe run, so adoption here is 'observed,' not 'measured.' ## Discovery and probe No fixed well-known path; renderer and agent capabilities (supported catalogs, custom components) are exchanged via transport-specific handshakes, e.g. A2A Agent Cards or MCP initialization metadata ``` GET {endpoint} — the AG-UI, A2A, or MCP endpoint the agent exposes; inspect its handshake/Agent Card/initialization payload parse: Presence of an A2UI catalogId/capability declaration in the handshake metadata, or a createSurface/updateComponents/updateDataModel/deleteSurface message in the response stream on absent: No A2UI capability declared; the agent returns only text or opaque structured JSON, not a declarative UI surface ``` Not probed live: no-fixed-path. A2UI is carried inside an AG-UI, A2A or MCP session; no fixed path. ## History - 2026-09-05 — seeded from Exa Agent research run - 2026-09-06 — verified against a2ui.org v1.0 spec and github.com/a2ui-project/a2ui - 2026-10-16 — A2UI moved from google/A2UI to the a2ui-project GitHub organisation - 2026-10-16 — use-case tags (auto) - 2026-10-16 — version python/a2ui-agent-sdk/v0.8.0 (watcher) - 2026-10-16 — version label restored to 'v1.0 (Candidate); v0.9.1 (Current)'; the repository's latest tag (python/a2ui-agent-sdk/v0.8.0) is a package, SDK or build tag, not the specification version, so the GitHub watch no longer drives version ## Instances - [CopilotKit](https://www.copilotkit.ai) · Observed 2026-08-14 · harness Every instance with its source is listed on the [instances page](/instances/). Verified SDKs, reference implementations & validators: - [a2ui-project/a2ui reference SDK (Flutter and web/Lit renderers)](https://github.com/a2ui-project/a2ui) · sdk (2026-09-05) Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Pairs with: [Agent-User Interaction Protocol](/protocols/ag-ui/), [Agent2Agent Protocol](/protocols/a2a/), [Model Context Protocol](/protocols/mcp/), [MCP Apps](/protocols/mcp-apps/), [AITP (Agent Interaction & Transaction Protocol)](/protocols/aitp/) - [Generative UI](/terms/generative-ui/) - Not to be confused with: AG-UI ## Comparisons - [Iframes & Server-Driven UI vs MCP Apps, AG-UI & A2UI (classic vs agentic)](/compare/iframes-vs-mcp-apps/) - [A2UI (Agent to UI) Protocol vs Agent-User Interaction Protocol](/compare/a2ui-vs-ag-ui/) - [MCP Apps vs A2UI (Agent to UI) Protocol](/compare/mcp-apps-vs-a2ui/) ## References - A2UI Protocol v1.0 spec text (Status: Candidate, Created Nov 20 2025, Last Updated Jun 8 2026) defines a streaming JSON UI protocol with four agent-to-renderer message types (createSurface, updateComponents, updateDataModel, deleteSurface) and named transport bindings for AG-UI, A2A, and MCP. — [https://a2ui.org/specification/v1.0-a2ui/](https://a2ui.org/specification/v1.0-a2ui/) (2026-06-08) VERIFIED - Canonical repo github.com/a2ui-project/a2ui: Apache-2.0 license, Google LLC copyright headers, README states current status 'Early stage public preview' with v0.9.1 as the current production release, v1.0 a release candidate, v0.8 legacy; renderers/host frameworks listed are Web and Flutter, with Lit/Angular/React renderer demos. — [https://github.com/a2ui-project/a2ui](https://github.com/a2ui-project/a2ui) (2026-09-05) VERIFIED - AG-UI's own documentation lists A2UI as a supported 'Generative UI, declarative' spec and names AG-UI as A2UI's standard transport binding, but still links A2UI to github.com/google/A2UI rather than the current a2ui-project org. — [https://docs.ag-ui.com/introduction](https://docs.ag-ui.com/introduction) (2026-09-05) VERIFIED - A2UI moved from google/A2UI to the a2ui-project GitHub organisation — [https://github.com/a2ui-project/A2UI](https://github.com/a2ui-project/A2UI) (2026-10-16) REPORTED - python/a2ui-agent-sdk/v0.8.0 released 2026-10-08 — [https://github.com/a2ui-project/a2ui/releases/tag/python/a2ui-agent-sdk/v0.8.0](https://github.com/a2ui-project/a2ui/releases/tag/python/a2ui-agent-sdk/v0.8.0) (2026-10-08) VERIFIED Disputed: Two GitHub locations are both cited for A2UI: the canonical 'View source of this page' link on a2ui.org points to a2ui-project/a2ui, but AG-UI's own docs (fetched 2026-09-05) still link A2UI to github.com/google/A2UI. This looks like an org rename or fork that the AG-UI docs have not caught up with, not a governance dispute, but it is unresolved which is authoritative going forward. [JSON](/data/protocols/a2ui.json) · [Markdown](/protocols/a2ui/index.md) · [OKF v0.2](/okf/protocols/a2ui.md) --- # AAuth (Hardt) AAuth (Hardt) is an agentic-web standard (HTTP header) at step 3, Permit, governed by IETF Internet-Draft by Dick Hardt; its status is "Active Internet-Draft, draft-hardt-oauth-aauth-protocol-11". It answers: "How does an agent obtain and present authorisation to act at a resource, using signed HTTP requests?" Replacing or extending OAuth, with the agent signing its own requests, implementation status is none found, last verified 2026-10-23. ## Quick Wire Reference - **Step**: 3 Permit (What may the agent do here?) - **Version**: draft-hardt-oauth-aauth-protocol-11 (2026-09-25) - **Status**: Active Internet-Draft, draft-hardt-oauth-aauth-protocol-11 (2026-09-25… - **Discovery / Probe Path**: not determined from the datatracker listing - **Spec URL**: https://datatracker.ietf.org/doc/draft-hardt-oauth-aauth-protocol/ - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: OAuth, with the agent signing its own requests [Permit](/category/permit/) AAuth in its current form is Dick Hardt's Internet-Draft draft-hardt-oauth-aauth-protocol, at revision -11 (2026-09-25, expiring 2027-03-29) [[1]](#ref-1). A companion draft, draft-hardt-aauth-headers, was published as -00 on 2026-10-04 and is already marked Expired by the Datatracker [[2]](#ref-2); the protocol draft itself is active. ## Overview This is a different document from the Rosenberg draft, which this site tracks as aauth (Agent Authorization Grant). That one expired on 2026-04-23, and the Hardt draft is the active AAuth line. The form, party and discovery details here are placeholders pending a read of the drafts; only the version, dates and expiry above are taken from the datatracker. ## Discovery and probe not determined from the datatracker listing ``` GET none parse: not applicable: discovery mechanics were not reviewed for this record on absent: No presence signal exists for this record; absence of a probe result says nothing about adoption. ``` Not probed live: no-fixed-path. candidate record; probe rule pending ## History - 2026-10-15 — curated update 2026-10-15 - 2026-10-16 — Expired Internet-Draft (expired 2026-10-04) - 2026-10-16 — correction: the 2026-10-04 expiry belongs to the companion headers draft; the protocol draft -11 is active until 2027-03-29, so native_status and phase restored - 2026-10-16 — use-case tags (auto) - 2026-10-16 — Companion draft draft-hardt-aauth-headers-00 expired on 2026-10-04; the record follows draft-hardt-oauth-aauth-protocol ## Instances Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Builds on: [HTTP Message Signatures](/protocols/http-message-signatures/) - Pairs with: [HTTP Message Signatures](/protocols/http-message-signatures/), [Agent Authorization Grant](/protocols/aauth/), [Signature Agent Card (Web Bot Auth registry)](/protocols/web-bot-auth-signature-agent-card/), [OAuth Protected Resource and Authorization Server Metadata (as used for agent authorization)](/protocols/oauth-metadata-for-agents/), [Identity Assertion JWT Authorization Grant](/protocols/identity-assertion-authz-grant/), [AAuth Rich Resource Requests](/protocols/aauth-r3/) - Not to be confused with: Agent Authorization Grant (Rosenberg), draft-rosenberg-oauth-aauth ## Comparisons - [Agent Authorization Grant vs AAuth (Hardt)](/compare/aauth-vs-aauth-hardt/) ## References - draft-hardt-oauth-aauth-protocol-11 is dated 2026-09-25 and expires 2027-03-29. — [https://datatracker.ietf.org/doc/draft-hardt-oauth-aauth-protocol/](https://datatracker.ietf.org/doc/draft-hardt-oauth-aauth-protocol/) (2026-09-25) VERIFIED - draft-hardt-aauth-headers-00 is dated 2026-10-04. — [https://datatracker.ietf.org/doc/draft-hardt-aauth-headers/](https://datatracker.ietf.org/doc/draft-hardt-aauth-headers/) (2026-10-04) VERIFIED - draft-hardt-aauth-headers-00 (the companion headers draft, not the protocol draft) is marked Expired by the Datatracker as of 2026-10-04. — [https://datatracker.ietf.org/doc/draft-hardt-aauth-headers/](https://datatracker.ietf.org/doc/draft-hardt-aauth-headers/) (2026-04-02) VERIFIED - Companion draft draft-hardt-aauth-headers-00 expired on 2026-10-04; the record follows draft-hardt-oauth-aauth-protocol — [https://datatracker.ietf.org/doc/draft-hardt-aauth-headers/](https://datatracker.ietf.org/doc/draft-hardt-aauth-headers/) (2026-04-02) VERIFIED [JSON](/data/protocols/aauth-hardt.json) · [Markdown](/protocols/aauth-hardt/index.md) · [OKF v0.2](/okf/protocols/aauth-hardt.md) --- # AAuth Rich Resource Requests (R3) AAuth Rich Resource Requests (R3) is an agentic-web standard (endpoint) at step 3, Permit, governed by Individual IETF Internet-Draft submission, companion to the…; its status is "Exploratory Draft". It answers: "How can an agent request an API's named operations, and a person approve one exact call, without relying on opaque scope…?" Replacing or extending OAuth Rich Authorization Requests (RAR), implementation status is none found, last verified 2026-10-23. ## Quick Wire Reference - **Step**: 3 Permit (What may the agent do here?) - **Version**: draft-hardt-aauth-r3-00 (2026-09-28) - **Status**: Exploratory Draft (-00); no known implementations · none found - **Discovery / Probe Path**: Resource advertises supported operation vocabularies as r3_vocabularies; a resource token… - **Spec URL**: https://datatracker.ietf.org/doc/html/draft-hardt-aauth-r3-00 - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: OAuth Rich Authorization Requests (RAR) [Permit](/category/permit/) AAuth R3 is an individual IETF draft by Dick Hardt that extends AAuth so an agent can request named operations from a vocabulary the resource advertises, rather than scope strings. The resource describes the operations in a JSON R3 document identified by its SHA-256 hash, which the person's server shows for consent. The issuer places the granted operations and hash in the auth token, and the resource enforces from the token alone. For operations marked per-call, a single-use token is bound to the call's concrete parameters. The draft has no known implementations and defines no consent screen or revocation. ## Discovery and probe Resource advertises supported operation vocabularies as r3_vocabularies; a resource token carries r3_uri and r3_s256 pointing at the R3 document ``` NONE parse: on absent: ``` Not probed live: no-fixed-path. candidate record; probe rule pending ## History - 2026-10-16 — auto-drafted candidate from exa (https://insights.bostonidentity.com/research/ietf-datatracker-2026-09-28-aauth-rich-resource-requests) - 2026-10-16 — spec_url moved from the Boston Identity write-up to the Internet-Draft draft-hardt-aauth-r3-00; ietf watch added - 2026-10-16 — revision -00 → 00 (watcher) ## Instances Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Part of: [Agent Authorization Grant](/protocols/aauth/) - Builds on: [Agent Authorization Grant](/protocols/aauth/) - Pairs with: [Agent Authorization Grant](/protocols/aauth/), [AAuth (Hardt)](/protocols/aauth-hardt/), [Model Context Protocol](/protocols/mcp/) ## References - Individual-submission companion to the AAuth Protocol by Dick Hardt (Hellō); -00, marked Exploratory Draft, no known implementations. It replaces scope strings with resource-named operations in vocabularies (MCP, OpenAPI, gRPC, GraphQL, AsyncAPI, WSDL, OData), content-addressed R3 documents identified by SHA-256, and per-call proposals. — [https://insights.bostonidentity.com/research/ietf-datatracker-2026-09-28-aauth-rich-resource-requests](https://insights.bostonidentity.com/research/ietf-datatracker-2026-09-28-aauth-rich-resource-requests) (2026-09-28) REPORTED - Datatracker shows draft-hardt-aauth-r3-00, dated 2026-09-28, expires 2027-04-01 — [https://datatracker.ietf.org/doc/draft-hardt-aauth-r3/](https://datatracker.ietf.org/doc/draft-hardt-aauth-r3/) (2026-09-28) VERIFIED [JSON](/data/protocols/aauth-r3.json) · [Markdown](/protocols/aauth-r3/index.md) · [OKF v0.2](/okf/protocols/aauth-r3.md) --- # Ad Context Protocol (AdCP · /.well-known/adagents.json) Ad Context Protocol (AdCP) is an agentic-web standard (well-known file — /.well-known/adagents.json) at step 5, Act, governed by AgenticAdvertising.org, an industry organization of publishers…; its status is "Active open protocol, current release v3.2.7". It answers: "How can an AI agent discover ad inventory, execute a media buy, sync creative, and report performance across many ad…?" Replacing or extending Ad-tech capability and transaction API, implementation status is shipping, last verified 2026-10-25. ## Quick Wire Reference - **Step**: 5 Act (Do something for me) - **Version**: v3.2.7 (2026-10-24) - **Status**: Active open protocol, current release v3.2.7 · shipping - **Discovery / Probe Path**: /.well-known/adagents.json — Publisher-side well-known file (adagents.json) declares… - **Spec URL**: https://docs.adcontextprotocol.org/ - **Last Verified**: 2026-10-25 (current) - **Classic Web Analog**: Ad-tech capability and transaction API [Act](/category/act/) The Ad Context Protocol (AdCP) is an open standard, published by the industry organization AgenticAdvertising.org, that lets AI agents discover ad inventory, set up commercial relationships, plan and execute media buys, generate and distribute creative, activate targeting data, run governance checks, and report performance across many ad platforms through one set of tasks instead of a bespoke integration per platform [[1]](#ref-1). It explicitly targets more than programmatic exchange: it covers direct deals, sponsorships, broadcast, and out-of-home, since most global ad spend still flows through non-programmatic channels [[1]](#ref-1). ## Overview AdCP solves ad-tech's fragmentation problem for agentic buying: a media buyer's agent sends one natural-language brief via get_products to every connected seller and receives back a common schema (pricing, forecasts, targeting, creative requirements) instead of comparing incompatible dashboards; create_media_buy then executes across sellers in one call, and get_media_buy_delivery aggregates reporting the same way [[1]](#ref-1). Publisher-side discovery runs through a well-known adagents.json file (analogous to robots.txt) declaring authorized agent endpoints and capabilities, and brand-side identity/authorization runs through brand.json; a hosted Registry API additionally resolves publishers and brands to their AdCP agents by capability, category, or geography for broader discovery beyond known domains [[1]](#ref-1). Trust is handled structurally: requests are signed with RFC 9421 HTTP Message Signatures against operator-published JWKS, idempotency keys make retried writes safe, and governance approvals travel as signed JWS tokens so no intermediate agent can forge a human sign-off [[1]](#ref-1). AdCP does not itself run ad auctions or hold inventory — it is a transaction and coordination layer that sits on top of two existing agent-transport protocols, MCP (for AI-assistant tool calls) and A2A (for agent-to-agent collaboration), using the same task schemas over either transport [[1]](#ref-1). It also does not claim every listed agent's capability claims are true by construction: the protocol ships compliance storyboards (a testable, runnable verification suite) precisely because claims otherwise would not be independently checkable [[1]](#ref-1). As of October 2026, the current release is v3.2.5 (succeeding the v3.1.20 release verified in September 2026), with published, versioned client SDKs for JavaScript/TypeScript, Python, and Go [[1]](#ref-1). The one open-source implementation surfaced in the docs, the Prebid Sales Agent (Python backend, TypeScript protocol layer, GAM integration), is explicitly labeled a community example built by a Prebid working group rather than a maintained reference implementation — a caveat AdCP's own documentation states outright, which this record treats as direct evidence of at least one independent, named implementer rather than as proof of broad adoption [[1]](#ref-1). Foundation-level governance (voting classes, Board composition, spec lifecycle) is documented in a public CHARTER.md, which is more governance transparency than many single-vendor competitors in this space disclose [[1]](#ref-1)[[2]](#ref-2). What remains unverified: no independent count of publishers actually serving adagents.json in production, nor of live AdCP agent endpoints, was located in this pass — that would need this project's own probe run before adoption could be upgraded from observed to measured. ## Discovery and probe Publisher-side well-known file (adagents.json) declares authorized agent endpoints and capabilities; brand-side well-known file (brand.json) declares operator identity, agent endpoints, and signing-key discovery; a hosted Registry API additionally resolves brands/publishers to AdCP agents by capability, category, or geography · /.well-known/adagents.json (publisher) and /.well-known/brand.json (brand/operator) ``` GET {origin}/.well-known/adagents.json parse: JSON body with `version`, `publisher.name`/`publisher.domain`, and an `agents[]` array of {url, protocol, capabilities}; a `get_adcp_capabilities` MCP/A2A call against a listed agent url confirms the endpoint actually speaks AdCP on absent: 404 or non-JSON response at /.well-known/adagents.json: the origin has not published AdCP publisher discovery (it may still run an AdCP agent without publishing the file, but that cannot be crawled) ``` Live check run by [the MCP probe](/mcp/server-card): GET /.well-known/adagents.json. adagents.json lists the publisher's authorised ad agents. ``` { "path": "/.well-known/adagents.json", "expect": { "json_keys": [ "agents" ] }, "note": "adagents.json lists the publisher's authorised ad agents." } ``` ## History - 2026-09-05 — seeded from Exa Agent research run - 2026-09-06 — verified against docs.adcontextprotocol.org/dist/docs/3.1.20/intro - 2026-10-16 — AdCP v3.2.4 released on 2026-10-12 - 2026-10-16 — use-case tags (auto) - 2026-10-17 — version v3.2.5 (watcher) - 2026-10-20 — spec_url and page watcher moved off the pinned 3.1.20 docs to the docs home (current release v3.2.5) - 2026-10-23 — version v3.2.6 (watcher) - 2026-10-24 — version v3.2.7 (watcher) ## Instances - [AgenticAdvertising.org (AdCP Clearinghouse)](https://agenticadvertising.org) · Observed 2026-06-15 · venue Every instance with its source is listed on the [instances page](/instances/). Verified SDKs, reference implementations & validators: - [@adcp/sdk (JavaScript/TypeScript, npm)](https://docs.adcontextprotocol.org/) · sdk (2026) Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Builds on: [Model Context Protocol](/protocols/mcp/), [Agent2Agent Protocol](/protocols/a2a/), [HTTP Message Signatures](/protocols/http-message-signatures/) - Pairs with: [Model Context Protocol](/protocols/mcp/), [Agent2Agent Protocol](/protocols/a2a/), [HTTP Message Signatures](/protocols/http-message-signatures/), [agents.json](/protocols/agents-json/), [Official MCP Registry](/protocols/mcp-registry/), [Agentic Advertising Management Protocols](/protocols/aamp/) ## Comparisons - [Ad Context Protocol vs Agentic Real Time Framework](/compare/adcp-vs-artf/) - [Agentic Advertising Management Protocols vs Ad Context Protocol](/compare/aamp-vs-adcp/) ## References - AdCP is a project of AgenticAdvertising.org and coordinates the full ad campaign lifecycle (discovery, accounts, product/creative, media buy execution, real-time serve-time matching via the Trusted Match Protocol, signals/audiences, governance, performance tracking, catalog sync, brand protection) across two transport protocols, MCP and A2A. Current documented version is 3.1.20. adagents.json and brand.json are the two well-known discovery files; a hosted Registry API also resolves agents by capability. Client SDKs are published and versioned for JavaScript/TypeScript (npm @adcp/sdk), Python (PyPI adcp), and Go (github.com/adcontextprotocol/adcp-go); an open-source community example implementation, the Prebid Sales Agent, is built by a Prebid working group (explicitly a community example, not a maintained reference implementation) with GAM integration. Foundation governance (structure, voting classes, Board composition, specification lifecycle, conduct rules) is documented in the project's CHARTER.md and published at agenticadvertising.org/governance. — [https://docs.adcontextprotocol.org/](https://docs.adcontextprotocol.org/) (2026) VERIFIED - AgenticAdvertising.org's own homepage (schema.org Organization markup) names itself 'the member organization pioneering a human-centric advertising future through Agentic AI,' founded 2025, and lists github.com/adcontextprotocol/adcp as its sameAs project repository, corroborating the docs site's governance claims from an independent page on the same organization's root domain. — [https://agenticadvertising.org](https://agenticadvertising.org) (2026) REPORTED - AdCP v3.2.4 released on 2026-10-12 — [https://github.com/adcontextprotocol/adcp/releases](https://github.com/adcontextprotocol/adcp/releases) (2026-10-12) REPORTED - v3.2.5 released 2026-10-16 — [https://github.com/adcontextprotocol/adcp/releases/tag/v3.2.5](https://github.com/adcontextprotocol/adcp/releases/tag/v3.2.5) (2026-10-16) VERIFIED - v3.2.6 released 2026-10-23 — [https://github.com/adcontextprotocol/adcp/releases/tag/v3.2.6](https://github.com/adcontextprotocol/adcp/releases/tag/v3.2.6) (2026-10-23) VERIFIED [JSON](/data/protocols/adcp.json) · [Markdown](/protocols/adcp/index.md) · [OKF v0.2](/okf/protocols/adcp.md) --- # Agent Attribution Protocol (AAP) Agent Attribution Protocol (AAP) is an agentic-web standard (endpoint) at step 9, Account, governed by Single vendor; its status is "The open standard for AI agent affiliate attribution". It answers: "When an AI agent recommends a product and a sale happens later, on another device or session, can anyone prove which…?" Implementation status is shipping, last verified 2026-10-23. ## Quick Wire Reference - **Step**: 9 Account (Prove what happened; be judged) - **Version**: v1.0 (2026-04-02) - **Status**: "The open standard for AI agent affiliate attribution" (vendor's own… - **Discovery / Probe Path**: none - **Spec URL**: https://github.com/rakohq/aap-spec - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: affiliate/referral tracking, reinvented for agents that don't click links or carry… [Account](/category/account/) The Agent Attribution Protocol (AAP) is a commerce-attribution scheme built by Rako, a UK company, so that when an AI shopping agent recommends a product and a user buys it later -- on a different device, browser, or after a delay -- the agent's role in driving that sale can be proven and a commission paid [[1]](#ref-1)[[2]](#ref-2). It replaces cookie- and click-based affiliate tracking, which does not work for agents that recommend inside a conversation rather than generating a clickable link. This is squarely an 'account' spec: its entire function is producing a verifiable record, after the fact, of what an agent did and whether it should be credited/paid for it. ## Overview How it works. An agent calls a search endpoint for offers, gets back a session and offers carrying a Rako-signed 'AAP Code'; when the agent recommends one to the user, it calls recommend(), which is the attribution event -- logged server-side, not via a cookie or link click. A later checkout()/merchant-reported conversion is matched back to that recommendation via the session, and commission is calculated and settled under merchant terms [[2]](#ref-2). The session lifecycle (CREATED, ACTIVE, CHECKOUT, CONVERTED, VALIDATED, SETTLED, with CANCELLED/CLAWED_BACK/DISPUTED/RESOLVED branches) and a 24-hour session expiry are explicitly defined [[2]](#ref-2). What it does not do. AAP is not a neutral, multi-operator standard: by its own specification text, 'issuance, verification, and settlement are operated by Rako' as the sole 'Protocol Authority' [[2]](#ref-2). There is no independent verifier, no federation model, and no way for a second company to run a conformant AAP issuer today. It also does not define a discovery mechanism (a merchant or agent has to integrate Rako's SDK/MCP server directly), and commission math in the spec is illustrative ("examples in this spec use a 20% network-fee model for illustration"), not fixed. Current state. The public spec repository was created 2026-04-02 and is versioned v1.0; working developer tooling exists today -- an MCP server (@rakohq/mcp), a JavaScript/TypeScript SDK (@rakohq/sdk on npm) and a Python SDK (agent-attribution-protocol on PyPI) -- all calling a live api.rako.sh backend, so this is a shipping, callable service rather than a paper spec [[3]](#ref-3). Who implements it. Rako operates the only known implementation (issuer, registry and SDKs). No independent merchant, agent-platform or competing issuer implementation was found in the sources checked. Disputed / unknown. No independent adoption figures (merchants, agents, or transaction volume) are published; adoption is marked unmeasured. "Agent Attribution Protocol" is the subject of a live UK trademark application (UK00004367937) per the spec's own README, and the acronym AAP collides with this site's pre-existing 'aap' record (Agent Authorization Profile, an unrelated IETF OAuth draft) -- readers should not confuse the two. ## Discovery and probe none ``` POST https://api.rako.sh/v1/recommend parse: A successful response with a signed 'AAP Code' and an 'attribution_id'/'recommendation_id' confirms a live Rako-operated AAP session; requires a valid API key, so this probe can confirm the service exists but cannot enumerate third-party agents using it without their cooperation. on absent: 401/403 without a key is expected and does not indicate absence; a connection failure or 404 would indicate the service is down or the endpoint has moved. ``` Not probed live: needs-credentials. The probe is a vendor API call that needs an API key. ## History - 2026-09-06 — new record: found via search for post-hoc agent commerce attribution specs; verified against rako.sh/aap, rako.sh/docs, and github.com/rakohq/aap-spec (README, spec/v1/README.md); flagged as single-vendor 'open spec, closed operation' and acronym collision - 2026-10-16 — use-case tags (auto) ## Instances - [Rako Agent Attribution Protocol (AAP) Authority](https://rako.sh) · Observed 2026-10-23 · authority Every instance with its source is listed on the [instances page](/instances/). Verified SDKs, reference implementations & validators: - [@rakohq/mcp (MCP server)](https://rako.sh/docs) · sdk (2026-09-05) Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Pairs with: [Model Context Protocol](/protocols/mcp/), [Agentic Commerce Protocol](/protocols/agentic-commerce-protocol/), [Universal Commerce Protocol](/protocols/ucp/), [Agent Payments Protocol](/protocols/ap2/), [Agent Audit Trail](/protocols/agent-audit-trail/) - Not to be confused with: Agent Authorization Profile (also abbreviated AAP, IETF OAuth draft, unrelated), AAMP (Agentic Advertising Management Protocols, unrelated, different acronym but easily confused) ## Comparisons - [Cookies, Syslog & T&Cs vs Agent Attribution, OTel GenAI & SCITT (classic vs agentic)](/compare/cookies-syslog-vs-agent-audit-trail/) - [Agent Attribution Protocol vs CoMP (Content Monetization Protocols)](/compare/agent-attribution-protocol-vs-iab-comp/) ## References - rako.sh/aap markets AAP as 'the protocol layer for recording agent recommendations, matching later conversions, and creating cleaner attribution across merchants, agents, and platforms,' with example recommendation.event and conversion.event JSON payloads and a signed 'AAP Code' as the core primitive. — [https://rako.sh/aap](https://rako.sh/aap) (2026-09-05) VERIFIED - The canonical public specification repository (Apache-2.0, created 2026-04-02) documents AAP v1.0: a session lifecycle (CREATED to SETTLED/DISPUTED/CLAWED_BACK), a signed AAP Code, binary (all-or-nothing) attribution, and states plainly that AAP 'is an open spec with a centralised trust model' where 'issuance, verification, and settlement are operated by Rako.' The README also flags a live UK trademark application (UK00004367937) on the name. — [https://raw.githubusercontent.com/rakohq/aap-spec/main/spec/v1/README.md](https://raw.githubusercontent.com/rakohq/aap-spec/main/spec/v1/README.md) (2026-04-02) VERIFIED - rako.sh/docs shows working developer integration paths -- an MCP server package (@rakohq/mcp), a published npm SDK (@rakohq/sdk) and a published PyPI package (agent-attribution-protocol) -- each exposing search/recommend/checkout calls against api.rako.sh, indicating a deployed, callable service rather than a paper spec only. — [https://rako.sh/docs](https://rako.sh/docs) (2026-09-05) VERIFIED Disputed: AAP calls itself 'the open standard' and publishes its spec text under Apache-2.0, but by its own README it has a 'centralised trust model': Rako alone issues and signs the AAP Code, operates the offer registry, and administers commission settlement. This is architecturally closer to a single-vendor affiliate network with a published API than a neutral standard multiple independent operators can run -- readers should weigh 'open spec, closed operation' when comparing it to IETF/W3C-track account specs. It also acronym-collides with both the pre-existing site record 'aap' (Agent Authorization Profile, an unrelated IETF OAuth draft) and, loosely, with IAB Tech Lab's AAMP. [JSON](/data/protocols/agent-attribution-protocol.json) · [Markdown](/protocols/agent-attribution-protocol/index.md) · [OKF v0.2](/okf/protocols/agent-attribution-protocol.md) --- # Agent Audit Trail (AAT) Agent Audit Trail (AAT) is an agentic-web standard (document format) at step 9, Account, governed by IETF individual Internet-Draft; its status is "Active Internet-Draft, Intended status: Standards Track". It answers: "Is there a standard, tamper-evident log format any autonomous AI agent can write its actions to, so a regulator, auditor…?" Implementation status is none found, last verified 2026-10-23. ## Quick Wire Reference - **Step**: 9 Account (Prove what happened; be judged) - **Version**: draft-sharif-agent-audit-trail-08 (2026-10-13) - **Status**: Active Internet-Draft (individual submission), Intended status: Standards… - **Discovery / Probe Path**: none - **Spec URL**: https://datatracker.ietf.org/doc/html/draft-sharif-agent-audit-trail-08 - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: a standardized syslog/audit-log format, but hash-chained like a blockchain for… [Account](/category/account/) Agent Audit Trail (AAT) is an individual IETF Internet-Draft proposing a standard JSON logging format for autonomous AI agent systems: each record must carry an agent identity (URI), a session id, an action type (tool_call, decision, delegation, escalation, error, lifecycle, etc.), an outcome (success, failure, timeout, denied, escalated), and a trust level (L0 no verification through L4 full mutual authentication with revocation checking) [[1]](#ref-1)[[2]](#ref-2). Records are linked into a tamper-evident hash chain -- each record stores the SHA-256 hash (per RFC 8785 canonical JSON) of the immediately preceding record -- with optional ECDSA signatures for non-repudiation, and a record_phase field (pre_execution/post_execution/concurrent) that distinguishes a log written before an action is allowed to run from one written after it completes [[2]](#ref-2). This is a direct fit for this site's 'account' step: it is explicitly a logs/audit-trail format for reconstructing and judging what an agent did. ## Overview What it solves. It gives autonomous-agent operators a single, exportable record format (JSONL is the recommended primary export, with Syslog and CSV also supported) intended to satisfy several overlapping compliance regimes at once: the EU AI Act's Article on automatic event recording for high-risk AI systems (effective August 2026), SOC 2 Trust Services Criteria, ISO/IEC 42001 and 24970, prEN 18229-1, and PCI DSS v4.0.1 [[2]](#ref-2). Later revisions add a 'Decision Reproducibility' section distinguishing record reproducibility (available for any model) from full decision reproducibility (only for open-weight models run at temperature zero in an attested environment), and, introduced in revision -03 and retained through revision -08, an 'Attestation Closure' requirement that the digests recorded cover the entire inference stack (model weights, tokenizer, chat template, inference-engine build, decoding configuration, numeric environment) to close forgery gaps [[2]](#ref-2). What it does not do. AAT does not define a discovery mechanism, a transport, or a place logs must be published -- it is a record format for whatever storage/export pipeline an operator already has. It does not define agent identity or authentication itself (trust_level is self-reported by the logging system, referencing an external identity mechanism such as the also-draft 'MCPS'/Agent Passport concept). Current state. As of 2026-10-13 this is revision -08 of an individual (not Working-Group) draft, authored solely by Raza Sharif of CyberSecAI Ltd, with 'Intended status: Standards Track' -- an author aspiration, not a Working Group adoption. The IETF datatracker's own boilerplate states individual drafts are not endorsed by the IETF and have no formal standing [[1]](#ref-1). Who implements it. No implementation, pilot, or third-party adopter was found in the sources checked; implementation is marked none-found and adoption unmeasured. Disputed / unknown. Whether this draft will be adopted by any IETF working group, referenced by an actual EU AI Act compliance guidance document, or implemented by any agent framework, is unknown. It is listed here as the most complete public spec text found for the 'account' step, explicitly flagged as early-stage and unimplemented rather than as an established standard. ## Discovery and probe none ``` GET {log_export_endpoint} parse: The spec defines a JSON record format, not a network endpoint: each record MUST carry record_id (UUIDv4), timestamp (RFC 3339), agent_id (URI), agent_version (semver), session_id (UUIDv4), action_type (tool_call/tool_response/decision/delegation/escalation/error/lifecycle), action_detail (object), outcome (success/failure/timeout/denied/escalated), trust_level (L0-L4), parent_record_id and prev_hash (SHA-256 of the previous record's RFC 8785 canonical JSON, forming a hash chain), and record_phase (pre_execution/post_execution/concurrent). The RECOMMENDED export format is JSONL. A conforming log is one where every line validates against these mandatory fields and the hash chain verifies. on absent: There is no way to detect AAT usage from outside a system -- it describes an internal/exported logging format, not a discoverable service. Absence just means a given agent's logs were not inspected, not that AAT is unused. ``` Not probed live: needs-credentials. Audit logs are exported from an operator-defined endpoint behind authentication. ## History - 2026-09-06 — new record: found via search for 'agent audit log standard'; verified against datatracker.ietf.org and the archived draft text (revision -03, 2026-09-05); no implementation found - 2026-10-16 — revision draft-sharif-agent-audit-trail-03 → 08 (watcher) - 2026-10-16 — use-case tags (auto) ## Instances Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Pairs with: [An Audit Record Format for AI Agent Authorization Decisions](/protocols/wimse-agent-audit-record/), [Agent Attribution Protocol](/protocols/agent-attribution-protocol/), [SPIFFE (Secure Production Identity Framework for Everyone)](/protocols/spiffe/), [HTTP Message Signatures](/protocols/http-message-signatures/), [Agent Delegation Receipts](/protocols/agent-delegation-receipts/), [AI Agent Execution Profile of SCITT](/protocols/scitt-ai-agent-execution/) - [Audit record](/terms/audit-record/) ## Comparisons - [Cookies, Syslog & T&Cs vs Agent Attribution, OTel GenAI & SCITT (classic vs agentic)](/compare/cookies-syslog-vs-agent-audit-trail/) - [Agent Audit Trail vs AI Agent Execution Profile of SCITT](/compare/agent-audit-trail-vs-scitt-ai-agent-execution/) - [Verifiable Intent vs Agent Audit Trail](/compare/vi-vs-agent-audit-trail/) - [Agent Audit Trail vs An Audit Record Format for AI Agent Authorization Decisions](/compare/agent-audit-trail-vs-wimse-agent-audit-record/) - [OpenTelemetry GenAI Semantic Conventions (agents and MCP) vs Agent Audit Trail](/compare/otel-genai-semconv-vs-agent-audit-trail/) ## References - IETF Datatracker lists draft-sharif-agent-audit-trail as an active Internet-Draft (individual submission, not IETF-endorsed, no formal standing), authored by Raza Sharif of CyberSecAI Ltd, currently at revision -03 (last updated 2026-09-05, expires 2027-03-09), with prior revisions -00 through -02 dated back to at least March 2026. — [https://datatracker.ietf.org/doc/draft-sharif-agent-audit-trail/](https://datatracker.ietf.org/doc/draft-sharif-agent-audit-trail/) (2026-09-05) VERIFIED - The draft text (revision -03) specifies a JSON-based Agent Audit Trail (AAT) with mandatory fields for agent identity, action classification, outcome and trust-level reporting, SHA-256 hash-chained records per RFC 8785, optional ECDSA signatures, JSONL/Syslog/CSV export, and explicitly maps to the EU AI Act (Regulation 2024/1689) high-risk logging mandate (effective August 2026), SOC 2, ISO/IEC 42001, ISO/IEC 24970, prEN 18229-1 and PCI DSS v4.0.1. — [https://www.ietf.org/archive/id/draft-sharif-agent-audit-trail-03.txt](https://www.ietf.org/archive/id/draft-sharif-agent-audit-trail-03.txt) (2026-09-05) VERIFIED - Datatracker shows draft-sharif-agent-audit-trail-08, dated 2026-10-13, expires 2027-04-16 — [https://datatracker.ietf.org/doc/draft-sharif-agent-audit-trail/](https://datatracker.ietf.org/doc/draft-sharif-agent-audit-trail/) (2026-10-13) VERIFIED Disputed: This is an individual Internet-Draft, not a Working Group item -- the IETF datatracker explicitly states such drafts are 'not endorsed by the IETF' and have 'no formal standing' in the standards process, and 'Intended status: Standards Track' is only the author's aspiration. No implementation, adopter or third-party citation of AAT was found in the sources checked; it is included here because it is the most complete public account/audit-log spec text found for this step, not because it has traction. [JSON](/data/protocols/agent-audit-trail.json) · [Markdown](/protocols/agent-audit-trail/index.md) · [OKF v0.2](/okf/protocols/agent-audit-trail.md) --- # Agent Authorization Envelope (AAE) Agent Authorization Envelope (AAE) is an agentic-web standard (document format) at step 3, Permit, governed by Individual Internet-Draft submitted to the IETF datatracker by…; its status is "Active Internet-Draft". It answers: "How can a relying party verify offline, without calling the issuer, that an agent holds a mandate with limits, an expiry…?" Implementation status is none found, last verified 2026-10-23. ## Quick Wire Reference - **Step**: 3 Permit (What may the agent do here?) - **Version**: draft-kroehl-agentic-trust-aae-02 (2026-09-06) - **Status**: Active Internet-Draft (-02, expires 2027-03-10) · none found - **Discovery / Probe Path**: Envelope presented by the agent to the relying party; no discovery path is described. The… - **Spec URL**: https://datatracker.ietf.org/doc/html/draft-kroehl-agentic-trust-aae-02 - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: A signed power of attorney with stated spending limits and an expiry date that a… [Permit](/category/permit/) The Agent Authorization Envelope (AAE) is an individual IETF Internet-Draft by Lars Kersten Kroehl of CryptoKRI GmbH. It defines a JWS-secured W3C Verifiable Credential carrying a mandate, constraints and a validity block for an agent acting under delegated authority. Relying parties run nine ordered checks, including proof of key possession, revocation and delegation-chain narrowing, and refuse when a required constraint or revocation status cannot be checked. Delegated envelopes may only narrow the parent's actions, caps, allowlists and validity window. ## Discovery and probe Envelope presented by the agent to the relying party; no discovery path is described. The optional revocation endpoint is named inside the envelope. ``` NONE parse: on absent: No site-level signal to observe; support is only visible when an agent presents an envelope. ``` Not probed live: no-fixed-path. candidate record; probe rule pending ## History - 2026-10-19 — auto-drafted candidate from exa (https://insights.bostonidentity.com/research/ietf-datatracker-2026-05-21-agent-authorization-envelope-aae) ## Instances Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Pairs with: [Workload Identity in Multi System Environments (WIMSE) Architecture](/protocols/wimse/), [SPIFFE (Secure Production Identity Framework for Everyone)](/protocols/spiffe/) ## References - Datatracker shows draft-kroehl-agentic-trust-aae-02 (Agent Authorization Envelope: A Machine-Evaluable Authorization Structure for Autonomous AI Agents), dated 2026-09-06. — [https://datatracker.ietf.org/doc/html/draft-kroehl-agentic-trust-aae-02](https://datatracker.ietf.org/doc/html/draft-kroehl-agentic-trust-aae-02) (2026-09-06) VERIFIED [JSON](/data/protocols/agent-authorization-envelope.json) · [Markdown](/protocols/agent-authorization-envelope/index.md) · [OKF v0.2](/okf/protocols/agent-authorization-envelope.md) --- # Agent Authorization Grant (AAuth) Agent Authorization Grant (AAuth) is an agentic-web standard (endpoint) at step 3, Permit, governed by IETF individual Internet-Draft; its status is "Expired Internet-Draft". It answers: "How can a conversational AI agent, reached over a channel without browser redirect (phone, SMS), obtain a properly…?" Replacing or extending OAuth Device Authorization Grant, implementation status is none found, last verified 2026-10-23. ## Quick Wire Reference - **Step**: 3 Permit (What may the agent do here?) - **Version**: draft-rosenberg-oauth-aauth-01 (2026-04-22) - **Status**: Expired Internet-Draft (expired 2026-04-23) · none found - **Discovery / Probe Path**: OAuth 2.1 extension grant flow; no well-known file defined - **Spec URL**: https://datatracker.ietf.org/doc/html/draft-rosenberg-oauth-aauth - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: OAuth Device Authorization Grant [Permit](/category/permit/) The Agent Authorization Grant (AAuth) is an individual IETF Internet-Draft, draft-rosenberg-oauth-aauth-01 (dated 2026-04-22, succeeding -00 of 2025-10-19 and expired 2026-04-23), proposing an OAuth 2.1 extension for a specific class of AI agent: one reached through a channel that does not support browser-redirect OAuth flows, such as a phone call over the PSTN or SMS texting [[1]](#ref-1). It solves a narrow but real permit-adjacent problem — authorization, not content-use permission — for voice/text-only conversational agents. ## Overview In the flow it describes, the agent collects personally identifying information from the user through natural-language conversation, then presents that collected PII to obtain an access token with an appropriately constrained scope, rather than redirecting the user to a login page it cannot render over a phone call. The draft's stated primary concern is architectural: ensuring that LLM hallucination inside the agent cannot itself cause an impersonation attack against the authorization flow [[1]](#ref-1). It does not define a well-known discovery file, a permission vocabulary, or content-use semantics — it is purely an authorization-grant flow, adjacent to this wiki's 'identify' and 'permit' steps rather than a pure fit for either. It does not specify a concrete grant_type string or endpoint schema in enough detail in the sections reviewed to build an executable, generic probe; a probe would need to be implementation-specific. The IETF Datatracker shows draft-rosenberg-oauth-aauth-01 (published 2026-04-22 after -00 of 2025-10-19) as an expired Internet-Draft (expired 2026-04-23), while active AAuth specification work in the OAuth ecosystem has continued in Dick Hardt's draft-hardt-oauth-aauth-protocol series (tracked under aauth-hardt). No independent implementation, reference server, or adopting product of Rosenberg's PSTN/SMS PII-collection grant was located, so implementation is recorded as none-found and this record's phase is set to withdrawn. What is unresolved: whether the author (Jonathan Rosenberg) or another party intends to revive this line of work, and whether its PII-collection-then-token-exchange pattern will instead be absorbed into a more general draft such as DAAP or AAP, which address overlapping agent-authorization ground within the same OAuth ecosystem. ## Discovery and probe OAuth 2.1 extension grant flow; no well-known file defined ``` POST {authorization_server}/token with grant_type indicating the Agent Authorization Grant (exact grant_type string not fixed in the draft text reviewed) parse: A 200 response containing an access_token issued via the collected-PII flow described in the draft on absent: Authorization server does not implement this grant; this is expected, since the draft is expired and no implementation was found ``` Not probed live: needs-credentials. The Agent Authorization Grant is observed only inside a token request. ## History - 2026-09-05 — seeded from Exa Agent research run - 2026-09-06 — verified against datatracker.ietf.org/doc/html/draft-rosenberg-oauth-aauth; found expired - 2026-10-16 — draft-rosenberg-oauth-aauth-01 (2026-04-22) expired on 2026-04-23; the active AAuth lineage is draft-hardt-oauth-aauth-protocol-11 - 2026-10-16 — Expired Internet-Draft (expired 2026-04-23) - 2026-10-16 — use-case tags (auto) ## Instances Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Component: [AAuth Rich Resource Requests](/protocols/aauth-r3/) - Depended on by: [AAuth Rich Resource Requests](/protocols/aauth-r3/) - Pairs with: [OAuth Profile for Delegated AI Agent Authorization](/protocols/daap/), [Agent Authorization Profile](/protocols/aap/), [AI Agent Authentication and Authorization (AIMS)](/protocols/aiagent-auth/), [OAuth Protected Resource and Authorization Server Metadata (as used for agent authorization)](/protocols/oauth-metadata-for-agents/), [Identity Assertion JWT Authorization Grant](/protocols/identity-assertion-authz-grant/), [AAuth (Hardt)](/protocols/aauth-hardt/) - [Expired Internet-Draft](/terms/expired-internet-draft/) - Not to be confused with: AAuth (Hardt), draft-hardt-oauth-aauth-protocol ## Comparisons - [OAuth 2.0 Consent & DCR vs CIMD & Agent OAuth Metadata (classic vs agentic)](/compare/oauth-vs-cimd/) - [Agent Authorization Grant vs Identity Assertion JWT Authorization Grant](/compare/aauth-vs-identity-assertion-authz-grant/) - [Agent Authorization Grant vs AAuth (Hardt)](/compare/aauth-vs-aauth-hardt/) - [Agent Authorization Grant vs OAuth Profile for Delegated AI Agent Authorization](/compare/aauth-vs-daap/) ## References - draft-rosenberg-oauth-aauth defines an OAuth 2.1 extension letting an AI agent collect PII conversationally (over PSTN or texting, where redirect-based OAuth is unavailable) and exchange it for a scope-constrained access token, with an explicit goal of preventing LLM-hallucination-driven impersonation. — [https://datatracker.ietf.org/doc/html/draft-rosenberg-oauth-aauth](https://datatracker.ietf.org/doc/html/draft-rosenberg-oauth-aauth) (2025-10-19) VERIFIED - The raw draft-00 HTML text hosted at ietf.org/archive (distinct from the Datatracker's metadata/history page) confirms the same abstract, scope (PSTN/texting channels, PII-collection flow, anti-impersonation goal) and lets the Datatracker's 'Expired' state be cross-checked against the actual spec content rather than taken on the metadata page alone. — [https://www.ietf.org/archive/id/draft-rosenberg-oauth-aauth-00.html](https://www.ietf.org/archive/id/draft-rosenberg-oauth-aauth-00.html) (2025-10-19) VERIFIED - draft-rosenberg-oauth-aauth-01 (2026-04-22) expired on 2026-04-23; the active AAuth lineage is draft-hardt-oauth-aauth-protocol-11 — [https://datatracker.ietf.org/doc/draft-rosenberg-oauth-aauth/](https://datatracker.ietf.org/doc/draft-rosenberg-oauth-aauth/) (2026-04-23) VERIFIED - draft-rosenberg-oauth-aauth-01 (2026-04-22) expired on 2026-04-23; the active AAuth lineage is draft-hardt-oauth-aauth-protocol-11 — [https://datatracker.ietf.org/doc/draft-hardt-oauth-aauth-protocol/](https://datatracker.ietf.org/doc/draft-hardt-oauth-aauth-protocol/) (2026-04-23) VERIFIED - Expired Internet-Draft (expired 2026-04-23) — [https://datatracker.ietf.org/doc/draft-rosenberg-oauth-aauth/](https://datatracker.ietf.org/doc/draft-rosenberg-oauth-aauth/) (2025-10-20) VERIFIED Disputed: The draft is expired per the IETF Datatracker's own document-state field, and no independent implementation was found; it is retained here as a documented proposal rather than an active spec. [JSON](/data/protocols/aauth.json) · [Markdown](/protocols/aauth/index.md) · [OKF v0.2](/okf/protocols/aauth.md) --- # Agent Authorization Profile (AAP) Agent Authorization Profile (AAP) is an agentic-web standard (endpoint) at step 3, Permit, governed by No formal governance body; its status is "Expired Internet-Draft". It answers: "How can OAuth 2.0/JWT claims carry structured agent identity, task context, operational constraints, delegation chains…?" Replacing or extending OAuth profile / scoped service-account token, implementation status is prototype, last verified 2026-10-23. ## Quick Wire Reference - **Step**: 3 Permit (What may the agent do here?) - **Version**: draft-aap-oauth-profile-01 (2026-02-07) - **Status**: Expired Internet-Draft (expired 2026-08-11) · prototype - **Discovery / Probe Path**: OAuth 2.0 authorization-server metadata plus structured JWT claims; no dedicated well-known… - **Spec URL**: https://www.ietf.org/archive/id/draft-aap-oauth-profile-01.html - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: OAuth profile / scoped service-account token [Permit](/category/permit/) The Agent Authorization Profile (AAP) is a single-author IETF individual Internet-Draft, draft-aap-oauth-profile-01, dated 2026-02-07, proposing structured OAuth 2.0/JWT claims for autonomous AI agents [[1]](#ref-1). It extends OAuth 2.0, JWT, RFC 8693 Token Exchange, and proof-of-possession mechanisms so that a resource server can reason about agent identity, task context, operational constraints, delegation chains, and whether human oversight is required for a given call, explicitly without introducing a new protocol [[1]](#ref-1). ## Overview It does not define a discovery mechanism beyond standard OAuth authorization-server metadata, and it does not define content-use or crawling permissions — like DAAP and AAuth, its scope is agent-to-API (M2M) authorization, not publisher content policy. Its distinguishing claim relative to those two overlapping drafts is a heavier emphasis on structured, machine-reasoned claims (delegation chains, human-oversight flags) rather than a minimal composition of existing mechanisms. As of this verification (2026-09-06), the IETF Datatracker's own document-state field shows this draft as an 'Expired Internet-Draft (individual)', IESG state Expired, last updated 2026-08-11 with its single revision (-01) dated 2026-02-07 and no working-group affiliation — it never progressed beyond an individual submission [[1]](#ref-1). The author's listed contact is separately flagged by the Datatracker as possibly no longer valid. A companion project exists at github.com/aapspec, including a spec repository (Apache 2.0 licensed), a claimed reference implementation, JSON Schemas, and test vectors, but the repository's own README shows an IETF-status checklist with no box beyond 'draft-00 submitted' checked, no GitHub stars, and no activity beyond the initial 2026-02-07 push found in this pass [[2]](#ref-2). On that basis this record's phase is set to withdrawn and implementation to prototype (a reference implementation is claimed to exist, but with no evidence of independent use). What is unresolved: whether 'angel cruz' or another contributor intends to resubmit an active revision; whether any of AAP's specific claim names have been adopted informally by agent-framework builders outside the IETF process; and how AAP's more prescriptive claim-schema approach compares in practice to the lighter-weight DAAP profile, which explicitly avoids new claims. Given three overlapping, none-adopted individual OAuth-for-agents drafts (AAuth, DAAP, AAP) exist in this dataset, a future review should watch for which, if any, the OAuth Working Group formally adopts. This expired draft is not the OpenA2A Agent Authorization Protocol. draft-fane-opena2a-aap-02, by A. Fane (OpenA2A), is dated 30 September 2026 and expires 3 April 2027. It is a Standards Track individual submission, not a working-group document, and it is recorded separately as opena2a-aap [[4]](#ref-4). The Workload Authorization Grant, the identity-continuation assertion, and the Agent-Delegation header are separate records from both AAP documents. ## Discovery and probe OAuth 2.0 authorization-server metadata plus structured JWT claims; no dedicated well-known file defined in the spec text reviewed ``` GET {authorization_server}/.well-known/oauth-authorization-server parse: Decode a returned access token as a JWT and check for AAP-specific claim names (agent identity, task binding, delegation chain) as documented in the aapspec/spec repository's JSON Schemas on absent: No AAP claims present; given the draft's expired status this is the expected default across the ecosystem ``` Not probed live: no-fixed-path. AAP is a claims profile inside OAuth tokens; nothing at a fixed path proves it. ## History - 2026-09-05 — seeded from Exa Agent research run - 2026-09-06 — verified against datatracker.ietf.org/doc/draft-aap-oauth-profile/ and github.com/aapspec/spec; found expired - 2026-10-16 — Expired Internet-Draft (expired 2026-08-11) - 2026-10-16 — use-case tags (auto) - 2026-10-20 — noted that draft-fane-opena2a-aap-02 is a different, unexpired draft and is recorded as opena2a-aap; this record stays draft-aap-oauth-profile-01 ## Instances - [OpenA2A Agent Authorization Protocol (AAP) Authority](https://github.com/opena2a-standards/agent-authorization-protocol) · Observed 2026-07-02 · authority Every instance with its source is listed on the [instances page](/instances/). Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Builds on: [OAuth Protected Resource and Authorization Server Metadata (as used for agent authorization)](/protocols/oauth-metadata-for-agents/) - Pairs with: [Agent Authorization Grant](/protocols/aauth/), [OAuth Profile for Delegated AI Agent Authorization](/protocols/daap/), [OAuth Protected Resource and Authorization Server Metadata (as used for agent authorization)](/protocols/oauth-metadata-for-agents/), [HTTP Message Signatures](/protocols/http-message-signatures/), [Identity Assertion JWT Authorization Grant](/protocols/identity-assertion-authz-grant/), [OpenA2A Agent Authorization Protocol](/protocols/opena2a-aap/) - Not to be confused with: AAP also collides with the unrelated Automated Access Point / Advanced Authoring Program acronyms in other domains, Agent Attribution Protocol (AAP), OpenA2A Agent Authorization Protocol (draft-fane-opena2a-aap-02), a different current individual draft recorded as opena2a-aap ## References - The IETF Datatracker's document page for draft-aap-oauth-profile shows Document Type 'Expired Internet-Draft (individual)', IESG state 'Expired', last updated 2026-08-11, author 'angel cruz' with a note that the author's listed e-mail may no longer be valid. — [https://datatracker.ietf.org/doc/draft-aap-oauth-profile/](https://datatracker.ietf.org/doc/draft-aap-oauth-profile/) (2026-08-11) VERIFIED - The aapspec/spec GitHub repository hosts the same spec under an Apache 2.0 license, links a separate reference-impl repository, and its own README's IETF-status checklist shows no item beyond draft submission checked off, with zero GitHub stars and no commits after the 2026-02-07 draft date. — [https://github.com/aapspec/spec](https://github.com/aapspec/spec) (2026-02-07) REPORTED - Expired Internet-Draft (expired 2026-08-11) — [https://datatracker.ietf.org/doc/draft-aap-oauth-profile/](https://datatracker.ietf.org/doc/draft-aap-oauth-profile/) (2026-02-07) VERIFIED - draft-fane-opena2a-aap-02 (30 September 2026, expires 3 April 2027) is a different Internet-Draft from draft-aap-oauth-profile-01. It is a Standards Track individual submission by A. Fane, OpenA2A, and it was not expired on 2026-10-20. — [https://www.ietf.org/archive/id/draft-fane-opena2a-aap-02.txt](https://www.ietf.org/archive/id/draft-fane-opena2a-aap-02.txt) (2026-09-30) VERIFIED Disputed: This record is the expired individual draft draft-aap-oauth-profile-01. A different document, draft-fane-opena2a-aap-02, is current through 3 April 2027 and is recorded separately as opena2a-aap. The Workload Authorization Grant, the identity-continuation assertion, and the Agent-Delegation header are further separate records. [JSON](/data/protocols/aap.json) · [Markdown](/protocols/aap/index.md) · [OKF v0.2](/okf/protocols/aap.md) --- # Agent Client Protocol (ACP) Agent Client Protocol (ACP) is an agentic-web standard (endpoint) at step 5, Act, governed by Zed Industries acts as BDFL/design-team lead over a public…; its status is "v1 stable and shipping". It answers: "How does a code editor invoke and converse with an interchangeable coding agent it did not build?" Replacing or extending Language Server Protocol, implementation status is multi-implementation, last verified 2026-10-23. ## Quick Wire Reference - **Step**: 5 Act (Do something for me) - **Version**: v1.12.0 (schema v1.26.0); v2 unstable (schema v2.0.0-alpha.9) (2026-10-16) - **Status**: v1 stable and shipping; v2 published in Draft form as of 2026-07-20 ·… - **Discovery / Probe Path**: none fixed; local agents are launched as sub-processes, remote agents connect over HTTP or… - **Spec URL**: https://agentclientprotocol.com/get-started/introduction - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: Language Server Protocol [Act](/category/act/) The Agent Client Protocol (ACP) standardizes how a code editor or IDE talks to a coding agent, so that any ACP-compatible agent works with any ACP-compatible editor without bespoke integration work on either side [[1]](#ref-1). It targets the same M×N problem the Language Server Protocol solved for editor-to-language-server integration, but for agent-to-editor instead. ## Overview ACP assumes the user's primary surface is the editor, which reaches out to agents for specific tasks. Local agents run as editor sub-processes and communicate over JSON-RPC via stdio; remote, cloud-hosted agents are supported over HTTP or WebSocket, though the project's own documentation states full remote support is still a work in progress [[1]](#ref-1). ACP deliberately reuses MCP's JSON representations where practical, and layers on coding-specific UX types (e.g. representing diffs) that MCP does not define; user-facing text defaults to Markdown. ACP does not itself define agent discovery beyond the ACP Registry (stabilized 2026-03-09), which gives clients a standard way to find, install, and configure agents — it does not attempt to be a general web-scale discovery mechanism [[2]](#ref-2). It also does not (yet) fully specify remote-agent transport; a dedicated Transports Working Group (JetBrains and Block/Goose engineers) was formed on 2026-04-22 specifically to standardize WebSocket/HTTP transports for remote agents [[2]](#ref-2). As of October 2026, ACP v1 is stable at v1.12.0 / schema v1.26.0 (2026-10-16) and has shipped a steady cadence of "Completed" RFDs throughout 2026 (session resume, session list, logout, elicitation, boolean config options, request cancellation, and more), while ACP v2's protocol documentation and schema (v2.0.0-alpha.9) are published in Draft form [[2]](#ref-2)[[4]](#ref-4). Rust and TypeScript SDKs both reached 1.0 on 2026-06-25 [[2]](#ref-2). Governance is unambiguous and disclosed rather than disputed: Zed Industries is the explicit "BDFL" (benevolent dictator for life) design-team lead over a public Request-for-Dialog process modeled loosely on Rust's RFC process, and JetBrains' Sergey Ignatov joined as a second Lead Maintainer on 2026-02-18, formalizing what the project describes as "growing collaboration between Zed and JetBrains" [[3]](#ref-3)[[2]](#ref-2). What is not yet settled: how much of the remote-agent transport work lands in v1 versus v2, and whether governance broadens beyond the two-company core team the project says it currently anticipates expanding. ## Discovery and probe ACP Registry (a standard way for ACP clients to discover, install, and configure compatible agents, stabilized 2026-03-09); locally, agents run as editor sub-processes over stdio JSON-RPC · none fixed; local agents are launched as sub-processes, remote agents connect over HTTP or WebSocket (remote support still a work in progress) ``` stdio spawn {agent-binary} and send a JSON-RPC 2.0 initialize request per the ACP schema over stdin/stdout parse: response result containing protocolVersion and agentCapabilities confirms an ACP-speaking agent on absent: process exits, writes non-JSON-RPC output, or times out: the binary does not speak ACP ``` Not probed live: client-side. ACP runs between an editor and a local agent binary over stdio. ## History - 2026-09-05 — seeded from Exa Agent research run - 2026-09-06 — verified against agentclientprotocol.com/get-started/introduction, agentclientprotocol.com/updates, agentclientprotocol.com/rfds/about - 2026-09-06 — collisions updated to add Agent Connect Protocol (Cisco/AGNTCY), verified against github.com/agntcy/acp-spec, spec.acp.agntcy.org - 2026-10-16 — Agent Client Protocol v1.11.0 (schema v1.25.0) released on 2026-10-09; v2 is unstable - 2026-10-16 — use-case tags (auto) - 2026-10-16 — version schema-v1.25.0 (watcher) - 2026-10-16 — version label restored to 'v1.11.0 (schema v1.25.0); v2 unstable'; the repository's latest tag (schema-v1.25.0) is a package, SDK or build tag, not the specification version, so the GitHub watch no longer drives version - 2026-10-20 — version v1.12.0 / schema v1.26.0 (2026-10-16); the release watcher does not bump labels (gap scout 2026-10-20) ## Instances - [Zed Editor](https://zed.dev) · Observed 2026-08-24 · harness - [JetBrains IDEs (AI Assistant and Junie)](https://www.jetbrains.com/ai/) · Observed 2026-08-24 · harness Every instance with its source is listed on the [instances page](/instances/). Verified SDKs, reference implementations & validators: - [Rust SDK (v1.0)](https://agentclientprotocol.com/updates) · sdk (2026-06-25) - [Zed editor](https://agentclientprotocol.com/get-started/introduction) · implementation (2026) Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Pairs with: [Model Context Protocol](/protocols/mcp/), [Agent2Agent Protocol](/protocols/a2a/), [Agent-User Interaction Protocol](/protocols/ag-ui/), [Agent Connect Protocol (AGNTCY)](/protocols/agent-connect-protocol/) - [Agent Communication Protocol](/protocols/agent-communication-protocol/) - [Agentic Commerce Protocol](/protocols/agentic-commerce-protocol/) - [Agent Connect Protocol (AGNTCY)](/protocols/agent-connect-protocol/) - [ACP (four protocols)](/terms/acp/) - Not to be confused with: Agent Communication Protocol (IBM), Agentic Commerce Protocol (OpenAI/Stripe), Agent Connect Protocol (AGNTCY) ## Comparisons - [DOM Browser Automation vs WebMCP & MCP (classic vs agentic)](/compare/browser-automation-vs-webmcp/) - [Agent Client Protocol vs Agentic Commerce Protocol](/compare/agent-client-protocol-vs-agentic-commerce-protocol/) - [Agent Client Protocol vs Agent Communication Protocol](/compare/agent-client-protocol-vs-agent-communication-protocol/) - [Model Context Protocol vs Agent Client Protocol](/compare/mcp-vs-agent-client-protocol/) - [Agent Client Protocol vs Agent Connect Protocol (AGNTCY)](/compare/agent-client-protocol-vs-agent-connect-protocol/) ## References - ACP standardizes communication between code editors/IDEs and coding agents for both local (stdio sub-process) and remote (HTTP/WebSocket, still in progress) scenarios; it reuses MCP's JSON representations where possible and adds coding-UX-specific types such as diffs. — [https://agentclientprotocol.com/get-started/introduction](https://agentclientprotocol.com/get-started/introduction) (2026) VERIFIED - ACP v2 protocol documentation and schema were published in Draft form on 2026-07-20; governance is a Zed-led design team using a public RFD (Request for Dialog) process, with Sergey Ignatov of JetBrains joining as Lead Maintainer on 2026-02-18 and an ACP Registry stabilized 2026-03-09. — [https://agentclientprotocol.com/updates](https://agentclientprotocol.com/updates) (2026-07-20) VERIFIED - Governance is explicitly a 'design team with the Zed team as the lead (BDFL)'; RFDs are ACP's RFC-equivalent process, licensed Apache 2.0, discussed on Zulip and via GitHub PRs. — [https://agentclientprotocol.com/rfds/about](https://agentclientprotocol.com/rfds/about) (2026) VERIFIED - Agent Client Protocol v1.11.0 (schema v1.25.0) released on 2026-10-09; v2 is unstable — [https://github.com/agentclientprotocol/agent-client-protocol/blob/main/CHANGELOG.md](https://github.com/agentclientprotocol/agent-client-protocol/blob/main/CHANGELOG.md) (2026-10-09) REPORTED - schema-v1.25.0 released 2026-10-09 — [https://github.com/agentclientprotocol/agent-client-protocol/releases/tag/schema-v1.25.0](https://github.com/agentclientprotocol/agent-client-protocol/releases/tag/schema-v1.25.0) (2026-10-09) VERIFIED - Releases v1.12.0 (Rust crate), schema-v1.26.0 and schema-v2.0.0-alpha.9 (prerelease) published 2026-10-16. — [https://github.com/agentclientprotocol/agent-client-protocol/releases/tag/schema-v1.26.0](https://github.com/agentclientprotocol/agent-client-protocol/releases/tag/schema-v1.26.0) (2026-10-16) VERIFIED [JSON](/data/protocols/agent-client-protocol.json) · [Markdown](/protocols/agent-client-protocol/index.md) · [OKF v0.2](/okf/protocols/agent-client-protocol.md) --- # Agent Commerce Kit (ACK) Agent Commerce Kit (ACK) is an agentic-web standard (document format) at step 7, Pay, developed by Catena Labs and contributed as MIT-licensed open…; its status is "Open protocols with no stated version, status or date on the…". It answers: "How can an agent prove who owns it and pay another party, on any rail, with a receipt both sides can verify?" Replacing or extending A company ID badge plus a signed receipt book, implementation status is prototype, last verified 2026-10-23. ## Quick Wire Reference - **Step**: 7 Pay (Settle the bill) - **Version**: unversioned docs; reference packages agentcommercekit@0.11.0 (2026-10-16) - **Status**: Open protocols with no stated version, status or date on the concepts page… - **Discovery / Probe Path**: none at a fixed path; identity rests on DIDs and verifiable credentials exchanged between the… - **Spec URL**: https://www.agentcommercekit.com/overview/concepts - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: A company ID badge plus a signed receipt book [Pay](/category/pay/) Agent Commerce Kit (ACK) is Catena Labs' set of open patterns for agent identity and agent payments, with reference code [[1]](#ref-1)[[2]](#ref-2). ACK-ID gives an agent a DID and verifiable credentials that trace it back to its owner [[1]](#ref-1). ACK-Pay covers starting a payment, issuing a verifiable receipt and settling on whichever rail the parties use, card or stablecoin among them; it supports x402 [[1]](#ref-1). ## Overview Catena Labs launched it in May 2025 and contributed it as MIT-licensed open source [[1]](#ref-1)[[3]](#ref-3). The docs give no version, status or date. The reference packages are tagged up to agentcommercekit@0.11.0 and the code is still active [[2]](#ref-2). ACK defines nothing at a fixed path on an origin. Its payment half is filed under Pay; ACK-ID would also fit under Identify. ## Discovery and probe none at a fixed path; identity rests on DIDs and verifiable credentials exchanged between the parties ``` GET none — no fixed path defined parse: No artefact at a fixed path to parse. on absent: Not probeable from an origin. ``` Not probed live: no-fixed-path. ACK identity and payment objects are exchanged between parties; no fixed path is defined. ## History - 2026-10-20 — added from gap scout 2026-10-20; verified against agentcommercekit.com/overview/concepts and github.com/agentcommercekit/ack ## Instances Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Pairs with: [x402](/protocols/x402/), [ERC-8004: Trustless Agents](/protocols/erc-8004/), [Agent Payments Protocol](/protocols/ap2/) - Not to be confused with: ACK (TCP acknowledgement, unrelated), Not one of the protocols called ACP ## Comparisons - [Agent Commerce Kit (ACK) vs Agent Payments Protocol](/compare/agent-commerce-kit-vs-ap2/) ## References - The ACK concepts page describes Agent Commerce Kit as open protocols: ACK-ID for agent identity and ownership chains built on DIDs and verifiable credentials, and ACK-Pay for payment initiation, verifiable receipts and settlement-agnostic flows that support x402; it says Catena Labs initially developed it and contributed it as MIT-licensed open source, and gives no version, status or date. — [https://www.agentcommercekit.com/overview/concepts](https://www.agentcommercekit.com/overview/concepts) VERIFIED - The agentcommercekit/ack repository is MIT licensed, created 2025-05-19 and last pushed 2026-10-16, with package tags up to agentcommercekit@0.11.0. — [https://github.com/agentcommercekit/ack](https://github.com/agentcommercekit/ack) (2026-10-16) VERIFIED - Business Wire carries Catena Labs' launch announcement of Agent Commerce Kit. — [https://www.businesswire.com/news/home/20250520361792/en/](https://www.businesswire.com/news/home/20250520361792/en/) (2025-05-20) REPORTED [JSON](/data/protocols/agent-commerce-kit.json) · [Markdown](/protocols/agent-commerce-kit/index.md) · [OKF v0.2](/okf/protocols/agent-commerce-kit.md) --- # Agent Communication Protocol (ACP · /agents) Agent Communication Protocol (ACP) is an agentic-web standard (endpoint — /agents) at step 6, Coordinate, governed by Formerly IBM BeeAI; its status is "ACP is now part of A2A under the Linux Foundation". It answers: "How did agents, applications, and people exchange multimodal REST messages before merging into A2A?" Implementation status is none found, last verified 2026-10-23. ## Quick Wire Reference - **Step**: 6 Coordinate (Talk to another agent) - **Version**: v1.0.3 (2025-08-21) - **Status**: "ACP is now part of A2A under the Linux Foundation" (repository banner) · none… - **Discovery / Probe Path**: /agents - **Spec URL**: https://github.com/i-am-bee/acp - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: none [Coordinate](/category/coordinate/) IBM's Agent Communication Protocol (ACP) was an open REST protocol, built by IBM's BeeAI project, for exchanging multimodal messages (text, code, files, media) between agents, applications, and people, with support for synchronous, background, and streamed responses and for stateless or stateful execution [[1]](#ref-1)[[2]](#ref-2). It solved the same problem A2A now solves: letting agents built on different frameworks discover each other's capabilities (GET /agents) and run tasks (POST /runs) over a standard REST/OpenAPI surface, and it powered agent discovery and execution on IBM's BeeAI Platform [[1]](#ref-1). ## Overview ACP does not exist as an independent, live protocol any more. Its GitHub repository (i-am-bee/acp) was archived by its owner on 2025-08-27 and is now read-only [[1]](#ref-1); the repository's README carries a banner stating "ACP is now part of A2A under the Linux Foundation!" and links a migration guide directing implementers to Google/Linux Foundation's A2A protocol instead [[1]](#ref-1). Because the record here would otherwise duplicate a step already covered by a2a, and because the issuer itself declares the protocol subsumed, this record's phase is set to "withdrawn" and its implementation to "deprecated" per Ruling 11 — it is kept as a historical record rather than deleted, since some deployments and SDKs (acp-sdk on PyPI/npm) may still exist in the wild. At time of archival the final repository release was v1.0.3 (2025-08-21) and the last published OpenAPI spec file was v0.2.0, exposing GET /ping (liveness), GET /agents (agent discovery, paginated via limit/offset), and a /runs family of endpoints for execution [[2]](#ref-2). Governance had been IBM BeeAI-led community governance; there is no evidence ACP itself was ever formally adopted by a Linux Foundation working group before being merged — rather, its functionality and some contributors moved into the A2A project, which is the Linux Foundation-governed successor. What is unresolved: whether any production deployments continue to run the archived ACP server surface independently of A2A; no such deployment was found during this verification pass. ## Discovery and probe GET /agents (Agent Discovery endpoint) · /agents ``` GET {origin}/agents parse: JSON array of agent objects would confirm a live ACP server; in practice the repository is archived and this is not expected to resolve on new deployments on absent: Expected: the protocol was retired in August 2025 and superseded by A2A, so absence is the normal case ``` Not probed live: superseded. IBM ACP was archived and merged into A2A; /agents is not expected on new deployments. ## History - 2026-09-05 — seeded from Exa Agent research run - 2026-09-06 — verified against github.com/i-am-bee/acp (archived banner, archive date) and its OpenAPI spec; set phase withdrawn per Ruling 11 as merged into A2A - 2026-09-06 — collisions updated to add Agent Connect Protocol (Cisco/AGNTCY), verified against github.com/agntcy/acp-spec, spec.acp.agntcy.org - 2026-10-16 — IBM's Agent Communication Protocol is deprecated (merged into A2A) - 2026-10-16 — use-case tags (auto) - 2026-10-16 — version v1.0.3 (watcher) - 2026-10-16 — No push since 2025-08-25 (over 180 days) ## Instances - [IBM BeeAI Multi-Agent Runtime](https://github.com/i-am-bee/beeai-platform) · Observed 2026-08-29 · agent Every instance with its source is listed on the [instances page](/instances/). Verified SDKs, reference implementations & validators: - [i-am-bee/acp (archived reference server)](https://github.com/i-am-bee/acp) · implementation (2026-09-05) Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Pairs with: [Agent2Agent Protocol](/protocols/a2a/), [Model Context Protocol](/protocols/mcp/), [Open Agentic Schema Framework](/protocols/oasf/), [Natural Language Interaction Protocol](/protocols/nlip/), [Agent Protocol](/protocols/agent-protocol-aief/), [Agora Protocol](/protocols/agora-protocol/) - [Agent Client Protocol](/protocols/agent-client-protocol/) - [Agentic Commerce Protocol](/protocols/agentic-commerce-protocol/) - [Agent Connect Protocol (AGNTCY)](/protocols/agent-connect-protocol/) - [ACP (four protocols)](/terms/acp/) - Not to be confused with: Agent Client Protocol (Zed), Agentic Commerce Protocol (OpenAI/Stripe), Agent Connect Protocol (AGNTCY) ## Comparisons - [Agent Client Protocol vs Agent Communication Protocol](/compare/agent-client-protocol-vs-agent-communication-protocol/) - [Agent2Agent Protocol vs Agent Communication Protocol](/compare/a2a-vs-agent-communication-protocol/) - [Agent Communication Protocol vs Agent Connect Protocol (AGNTCY)](/compare/agent-communication-protocol-vs-agent-connect-protocol/) - [Agent Communication Protocol vs Agentic Commerce Protocol](/compare/agent-communication-protocol-vs-agentic-commerce-protocol/) ## References - The i-am-bee/acp GitHub repository was archived by the owner on 2025-08-27 and is read-only; its README banner states "ACP is now part of A2A under the Linux Foundation!" with a link to a migration guide. — [https://github.com/i-am-bee/acp](https://github.com/i-am-bee/acp) (2026-09-05) VERIFIED - The ACP OpenAPI specification (v0.2.0) defines GET /agents for agent discovery, GET /ping for liveness, and a /runs resource for stateless/stateful/streamed execution. — [https://raw.githubusercontent.com/i-am-bee/acp/main/docs/spec/openapi.yaml](https://raw.githubusercontent.com/i-am-bee/acp/main/docs/spec/openapi.yaml) (2026-09-05) VERIFIED - IBM's Agent Communication Protocol is deprecated (merged into A2A) — [https://github.com/i-am-bee/acp](https://github.com/i-am-bee/acp) (2026-10-16) VERIFIED - v1.0.3 released 2025-08-21 — [https://github.com/i-am-bee/acp/releases/tag/v1.0.3](https://github.com/i-am-bee/acp/releases/tag/v1.0.3) (2025-08-21) VERIFIED - No push since 2025-08-25 (over 180 days) — [https://github.com/i-am-bee/acp/releases/tag/v1.0.3](https://github.com/i-am-bee/acp/releases/tag/v1.0.3) (2025-08-21) REPORTED [JSON](/data/protocols/agent-communication-protocol.json) · [Markdown](/protocols/agent-communication-protocol/index.md) · [OKF v0.2](/okf/protocols/agent-communication-protocol.md) --- # Agent Connect Protocol (AGNTCY) (ACP · /agents/search) Agent Connect Protocol (AGNTCY) (ACP) is an agentic-web standard (endpoint — /agents/search) at step 5, Act, governed by AGNTCY project; its status is "Archived repository". It answers: "How does one agent (or an orchestrator) invoke and configure a remote agent it did not build, over a plain HTTP API?" Replacing or extending a REST API gateway for invoking a remote service, implementation status is none found, last verified 2026-10-23. ## Quick Wire Reference - **Step**: 5 Act (Do something for me) - **Version**: v0.2.3 (OpenAPI 3.1.1) (2025-05-23) - **Status**: Archived repository (2026-04-11) · none found - **Discovery / Probe Path**: /agents/search — An agent's ACP capabilities are described in an 'ACP descriptor'… - **Spec URL**: https://github.com/agntcy/acp-spec - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: a REST API gateway for invoking a remote service [Act](/category/act/) The Agent Connect Protocol (ACP), published by the AGNTCY Collective (co-founded by Cisco and LangChain), defines a standard REST/OpenAPI interface for invoking and configuring a remote agent over an API — covering agent discovery/search, stateless Runs, stateful Thread Runs with checkpointed state history, and streaming output [[1]](#ref-1)[[2]](#ref-2). It targets the same problem the Agent Client Protocol (Zed) and IBM's now-retired Agent Communication Protocol both address — a standard invocation surface for interchangeable agents — but is a third, independently governed specification that also happens to be commonly abbreviated "ACP," a collision the AGNTCY project shares with at least two other unrelated "ACP" specifications tracked on this map [[1]](#ref-1). ## Overview ACP does not itself define agent-to-agent negotiation or a payments layer; its scope is narrowly the client/orchestrator-to-agent invocation surface, with agent metadata for richer discovery deferred to a separate 'agent directory' concept. It also does not define transport beyond HTTP/REST — there is no WebSocket or message-queue binding in the specification. As of this check (September 2026), the specification's source repository (agntcy/acp-spec) was archived by its owner on 2026-04-11 and is now read-only, with its last substantive commit dated 2025-05-23 [[1]](#ref-1). The rendered interactive OpenAPI documentation at spec.acp.agntcy.org still resolves and is served unchanged since that date, so existing implementations can still consult it, but no further spec development is occurring under this repository [[2]](#ref-2). The broader AGNTCY Collective remains highly active — 49 public repositories with commits as recent as hours before this check — but its current discovery and identity work is concentrated in newer projects ('dir', a distributed agent directory, and 'oasf', the Open Agentic Schema Framework) rather than in acp-spec, suggesting AGNTCY's own architecture has moved on from this component without a formal deprecation notice or migration guide comparable to IBM's ACP-to-A2A banner [[3]](#ref-3). Governance was, and nominally remains, the AGNTCY Collective's open, multi-vendor structure (Apache 2.0 license, public GitHub PR process, 'Copyright AGNTCY Contributors'). What is unresolved: whether any production deployments still run ACP servers independently of the newer 'dir'-based tooling, and whether AGNTCY intends to formally retire or fold ACP's invocation surface into a successor — no such announcement was found during this verification pass, only the archival action itself. ## Discovery and probe An agent's ACP capabilities are described in an 'ACP descriptor' retrievable via the ACP interface itself or embedded in that agent's record in an AGNTCY agent directory (now superseded in AGNTCY's active tooling by the 'dir' project); no site-wide well-known path is defined · /agents/search ``` POST {origin}/agents/search parse: A 200 response returning a JSON array of agent objects (each with agent_id and metadata.ref) confirms an ACP-speaking server per the v0.2.3 OpenAPI schema. on absent: A 404 or non-JSON response means no ACP server at this origin. Because the specification's own source repository was archived by its owner in April 2026 with no announced successor, absence is the expected and increasingly common result over time. ``` Not probed live: unsafe-post. The probe is POST /agents/search. ## History - 2026-09-06 — added from arXiv 2504.16736 survey comparison, verified against github.com/agntcy/acp-spec, spec.acp.agntcy.org, github.com/orgs/agntcy/repositories - 2026-09-06 — governance corrected to reflect Cisco donating AGNTCY to the Linux Foundation, per sibling records ads/oasf/slim; verified against existing agenticweb.wiki records - 2026-10-16 — The agntcy/acp-spec repository was archived on 2026-04-11 - 2026-10-16 — use-case tags (auto) - 2026-10-16 — No push since 2025-05-23 (over 180 days) ## Instances Verified SDKs, reference implementations & validators: - [acp-spec reference OpenAPI schema](https://github.com/agntcy/acp-spec) · implementation (2026-09-06) Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Pairs with: [Open Agentic Schema Framework](/protocols/oasf/), [Agent2Agent Protocol](/protocols/a2a/), [Agent Client Protocol](/protocols/agent-client-protocol/), [Agent Communication Protocol](/protocols/agent-communication-protocol/), [Model Context Protocol](/protocols/mcp/), [Agora Protocol](/protocols/agora-protocol/) - [Agent Client Protocol](/protocols/agent-client-protocol/) - [Agent Communication Protocol](/protocols/agent-communication-protocol/) - [Agentic Commerce Protocol](/protocols/agentic-commerce-protocol/) - [ACP (four protocols)](/terms/acp/) - Not to be confused with: Agent Client Protocol (Zed), Agent Communication Protocol (IBM), Agentic Commerce Protocol (OpenAI/Stripe) ## Comparisons - [Agent Client Protocol vs Agent Connect Protocol (AGNTCY)](/compare/agent-client-protocol-vs-agent-connect-protocol/) - [Agent Communication Protocol vs Agent Connect Protocol (AGNTCY)](/compare/agent-communication-protocol-vs-agent-connect-protocol/) - [Agent Connect Protocol (AGNTCY) vs Agentic Commerce Protocol](/compare/agent-connect-protocol-vs-agentic-commerce-protocol/) ## References - The agntcy/acp-spec GitHub repository ('Agent Connect Protocol Specification', Apache-2.0, 168 stars) was archived by the owner on 2026-04-11 and is now read-only; its last commit was 2025-05-23 (PR #46, adding basic type support for input/output/config). — [https://github.com/agntcy/acp-spec](https://github.com/agntcy/acp-spec) (2026-09-06) VERIFIED - The rendered OpenAPI spec at spec.acp.agntcy.org (v0.2.3, OpenAPI 3.1.1) defines the Agents, Threads, Thread Runs, and Stateless Runs operation groups (POST /agents/search, GET/POST /threads, POST /runs, etc.) for invoking and configuring remote agents. — [https://spec.acp.agntcy.org/](https://spec.acp.agntcy.org/) (2026-09-06) VERIFIED - The AGNTCY GitHub organization currently lists 49 public repositories with activity within hours to days of this check, with its identity/discovery focus now centered on the 'dir' (Distributed Announce and Discovery of Multi-Agentic-Systems) and 'oasf' (Open Agentic Schema Framework) projects rather than acp-spec. — [https://github.com/orgs/agntcy/repositories](https://github.com/orgs/agntcy/repositories) (2026-09-06) VERIFIED - The agntcy/acp-spec repository was archived on 2026-04-11 — [https://github.com/agntcy/acp-spec](https://github.com/agntcy/acp-spec) (2026-04-11) VERIFIED - No push since 2025-05-23 (over 180 days) — [https://github.com/agntcy/acp-spec](https://github.com/agntcy/acp-spec) (2026-10-15) REPORTED [JSON](/data/protocols/agent-connect-protocol.json) · [Markdown](/protocols/agent-connect-protocol/index.md) · [OKF v0.2](/okf/protocols/agent-connect-protocol.md) --- # Agent Context Interchange Protocol (ACIP) Agent Context Interchange Protocol (ACIP) is an agentic-web standard (document format) at step 3, Permit, governed by Individual Internet-Draft, Network Working Group; its status is "Internet-Draft, Intended Status: Informational". It answers: "How can a coding-agent host resolve organization, project, task, user, and vendor instruction sources into one…?" Implementation status is none found, last verified 2026-10-23. ## Quick Wire Reference - **Step**: 3 Permit (What may the agent do here?) - **Version**: draft-agarwal-acip-00 (2026-10-12) - **Status**: Internet-Draft, Intended Status: Informational; expires 15 April 2027; work in… - **Discovery / Probe Path**: .agents/agent-context.yaml - **Spec URL**: https://datatracker.ietf.org/doc/html/draft-agarwal-acip-00 - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: AGENTS.md with a structured YAML schema, precedence algorithm, and resolution receipt [Permit](/category/permit/) ACIP is an individual Internet-Draft (Informational) defining a YAML policy file, agent-context.yaml, and a host resolution procedure for persistent instructions given to coding agents. It ranks organization, project, task, user, and vendor sources by host-determined provenance and applies path-scoped rules. It separates enforceable constraints from textual directives and preferences, and it defines a resolution receipt. It also specifies compatibility with AGENTS.md and Agent Skills, plus migration profiles for tools without native support. It states that natural-language instructions cannot force behavior and that enforcement requires a host control at the action boundary. ## Discovery and probe Fixed repository path (.agents/agent-context.yaml and .agents/policies/) plus a user-level config path; organization policy via a host-specific managed channel · .agents/agent-context.yaml ``` GET .agents/agent-context.yaml parse: Parse as a single YAML 1.2 document and check that it validates against the ACIP top-level members. Only applies to public repositories; file is in the repository, not the site root. on absent: Treat ACIP as not supported by that repository ``` Not probed live: no-fixed-path. candidate record; probe rule pending ## History - 2026-10-16 — auto-drafted candidate from exa (https://datatracker.ietf.org/doc/html/draft-agarwal-acip-00) ## Instances Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Pairs with: [AGENTS.md](/protocols/agents-md/), [Agent Skills](/protocols/anthropic-agent-skills-format/), [Model Context Protocol](/protocols/mcp/) ## References - Internet-Draft defines ACIP, a YAML-based format and host-resolution behavior for coding-agent context sources, with source precedence, file matching, constraint/directive/preference distinctions, and a resolution receipt. — [https://datatracker.ietf.org/doc/html/draft-agarwal-acip-00](https://datatracker.ietf.org/doc/html/draft-agarwal-acip-00) (2026-10-12) REPORTED [JSON](/data/protocols/acip.json) · [Markdown](/protocols/acip/index.md) · [OKF v0.2](/okf/protocols/acip.md) --- # Agent Decision Commitments for Payments (ADC) Agent Decision Commitments for Payments (ADC) is an agentic-web standard (document format) at step 9, Account, governed by Individual Internet-Draft; its status is "Internet-Draft, Intended Status: Experimental". It answers: "How can an agent's payment decision, including the content it gave the model, be committed to before payment and later…?" Implementation status is none found, last verified 2026-10-23. ## Quick Wire Reference - **Step**: 9 Account (Prove what happened; be judged) - **Version**: draft-milan-agent-decision-commitment-00 (2026-10-15) - **Status**: Internet-Draft, Intended Status: Experimental; expires 18 April 2027 · none… - **Discovery / Probe Path**: Decision context claim (JWT claim "decision_context") carried in a payment mandate or… - **Spec URL**: https://datatracker.ietf.org/doc/html/draft-milan-agent-decision-commitment-00 - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: A sealed, timestamped receipt of what the agent read before it paid, openable only… [Account](/category/account/) Defines the Agent Decision Commitment (ADC), a salted hash commitment to a decision record covering the content given to the model interface, the model calls, and the resulting answer and action. The commitment is carried as a single selectively disclosable claim ("decision_context") in an existing payment mandate or payload and is by default registered with a SCITT transparency service before payment authorization. Disclosure and verification report attestation levels rather than verdicts. It also defines bindings to three agent payment protocols and to account-to-account credit transfers, and a witnessed reciprocal exchange between two parties' agents. It produces evidence only and does not allocate liability. ## Discovery and probe Decision context claim (JWT claim "decision_context") carried in a payment mandate or payload; commitment registered with a SCITT transparency service ``` NONE parse: on absent: No public discovery endpoint; support could only be observed by inspecting payment mandates for a decision_context claim. ``` Not probed live: no-fixed-path. candidate record; probe rule pending ## History - 2026-10-19 — auto-drafted candidate from exa (https://datatracker.ietf.org/doc/html/draft-milan-agent-decision-commitment-00) ## Instances Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Builds on: [Agent Payments Protocol](/protocols/ap2/) - Pairs with: [Verifiable Intent](/protocols/vi/), [Agent Payments Protocol](/protocols/ap2/), [AI Agent Execution Profile of SCITT](/protocols/scitt-ai-agent-execution/) ## Comparisons - [Cookies, Syslog & T&Cs vs Agent Attribution, OTel GenAI & SCITT (classic vs agentic)](/compare/cookies-syslog-vs-agent-audit-trail/) - [Verifiable Intent vs Agent Decision Commitments for Payments](/compare/vi-vs-agent-decision-commitment/) ## References - Internet-Draft defines the Agent Decision Commitment: a salted hash commitment to a decision record, carried as a selectively disclosable claim in a payment mandate and registered with a transparency service, with bindings to three agent payment protocols and account-to-account credit transfers, plus a witnessed reciprocal exchange. — [https://datatracker.ietf.org/doc/html/draft-milan-agent-decision-commitment-00](https://datatracker.ietf.org/doc/html/draft-milan-agent-decision-commitment-00) (2026-10-15) REPORTED [JSON](/data/protocols/agent-decision-commitment.json) · [Markdown](/protocols/agent-decision-commitment/index.md) · [OKF v0.2](/okf/protocols/agent-decision-commitment.md) --- # Agent Delegation Receipts Agent Delegation Receipts is an agentic-web standard (document format) at step 3, Permit, governed by Individual Internet-Draft submitted to the IETF; its status is "Internet-Draft, Intended Status: Informational". It answers: "How can a human principal's authorization of an AI agent (scope, boundaries, validity window, and operator instruction…?" Implementation status is none found, last verified 2026-10-23. ## Quick Wire Reference - **Step**: 3 Permit (What may the agent do here?) - **Version**: draft-nelson-agent-delegation-receipts-15 (2026-10-22) - **Status**: Internet-Draft (draft-nelson-agent-delegation-receipts-15), Intended Status… - **Discovery / Probe Path**: No discovery mechanism described in the available page text; receipts are presented by the… - **Spec URL**: https://datatracker.ietf.org/doc/html/draft-nelson-agent-delegation-receipts-15 - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: A signed power-of-attorney slip the agent shows before acting, with a hash pinning… [Permit](/category/permit/) Defines the Agent Delegation Receipt, a signed record of the scope, hard boundaries, validity window, and operator-instruction hash that a human principal authorized for an AI agent. Revision -15 (2026-10-22; originally introduced in -11) uses a JWS profile (RFC 7515) over JCS-canonicalized JSON (RFC 8785) and a COSE_Sign1 profile (RFC 9052). It also specifies scope attenuation across multi-agent delegation chains and a revocation registry with cascade semantics. The draft states it is an audit and attribution layer for honest deployments, not a control against a malicious operator. ## Discovery and probe No discovery mechanism described in the available page text; receipts are presented by the agent to a verifier before executing an action. ``` NONE parse: on absent: No site-level support signal is defined, so absence cannot be observed. ``` Not probed live: no-fixed-path. candidate record; probe rule pending ## History - 2026-10-16 — auto-drafted candidate from exa (https://datatracker.ietf.org/doc/html/draft-nelson-agent-delegation-receipts-11) - 2026-10-20 — version -14 (2026-10-15); watcher unpinned from -11 (gap scout 2026-10-20) - 2026-10-23 — revision 14 → 15 (watcher) ## Instances Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Pairs with: [Agent Payments Protocol](/protocols/ap2/), [ERC-8004: Trustless Agents](/protocols/erc-8004/), [Agent Audit Trail](/protocols/agent-audit-trail/) ## References - The Internet-Draft defines the Agent Delegation Receipt as a signed record of what a human principal authorized an AI agent to do, using a JWS profile over JCS-canonicalized JSON and a COSE_Sign1 profile, plus scope attenuation for delegation chains and a revocation registry with cascade semantics. — [https://datatracker.ietf.org/doc/html/draft-nelson-agent-delegation-receipts-11](https://datatracker.ietf.org/doc/html/draft-nelson-agent-delegation-receipts-11) (2026-10-09) REPORTED - Revision -14 (15 October 2026, expires 18 April 2027, R. Nelson, Informational); its abstract keeps the -11 JWS/JCS and COSE_Sign1 profiles. — [https://datatracker.ietf.org/doc/draft-nelson-agent-delegation-receipts/](https://datatracker.ietf.org/doc/draft-nelson-agent-delegation-receipts/) (2026-10-15) VERIFIED - Datatracker shows draft-nelson-agent-delegation-receipts-15, dated 2026-10-22, expires 2027-04-25 — [https://datatracker.ietf.org/doc/draft-nelson-agent-delegation-receipts/](https://datatracker.ietf.org/doc/draft-nelson-agent-delegation-receipts/) (2026-10-22) VERIFIED [JSON](/data/protocols/agent-delegation-receipts.json) · [Markdown](/protocols/agent-delegation-receipts/index.md) · [OKF v0.2](/okf/protocols/agent-delegation-receipts.md) --- # Agent Directory Service (ADS · /v1/agents) Agent Directory Service (ADS) is an agentic-web standard (endpoint — /v1/agents) at step 1, Discover, governed by AGNTCY project; its status is "Internet-Draft". It answers: "Given a required skill, which agents provide it, where are they, and how can I fetch a verifiable, content-addressed…?" Implementation status is shipping (observed on 1/1226 probed origins), last verified 2026-10-23. ## Quick Wire Reference - **Step**: 1 Discover (What is here, and where?) - **Version**: draft-mp-agntcy-ads-02 (2026-07-06) - **Status**: Internet-Draft; work in progress; canonical spec tracked at… - **Discovery / Probe Path**: /v1/agents — Content-addressed OCI-artifact storage plus a DHT for global skill-based… - **Spec URL**: https://datatracker.ietf.org/doc/html/draft-mp-agntcy-ads-02 - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: a distributed package registry (like npm or an OCI container registry) combined… [Discover](/category/discover/) The Agent Directory Service (ADS) is a distributed directory for storing and discovering metadata about AI agent applications, structured as records that can be searched by the skills they claim to provide [[1]](#ref-1). It originates from AGNTCY (an Outshift/Cisco-led project now positioned under the Linux Foundation) and is written up as an individual IETF Internet-Draft, revision -02, dated 6 July 2026, with its living canonical text tracked outside the IETF at spec.dir.agntcy.org and source at github.com/agntcy/dir [[1]](#ref-1). ## Overview ADS solves agent discovery at scale using content-addressed storage: each agent record is packaged as an OCI-compliant artifact (reusing container-registry infrastructure and its manifest/layer model) and identified by a content ID (CID) derived from a cryptographic digest [[1]](#ref-1). Records are indexed into a distributed hash table keyed by a multi-level skill taxonomy (plus domain and module taxonomies), so a query for a capability resolves to the CIDs and peer IDs of agents that claim it, without a central registry [[1]](#ref-1). Distribution between directory nodes happens over the OCI protocol's peer-to-peer synchronization [[1]](#ref-1). Distinct from the DHT-based global layer, ADS also runs a host-local "AI Finder" service, exposed over gRPC and, via a gateway, as a REST API: GET /v1/agents lists catalog entries with deterministic pagination, GET /v1/agents/{cid} retrieves one entry, GET /v1/agents/{cid}/export renders a stored OASF record into other ecosystems' native formats (a2a, agent-skill, mcp-ghcopilot), and GET /.well-known/ai-catalog.json serves the host's catalog document at the well-known URI this project explicitly designed to interoperate with the ARD/AI Catalog ecosystem [[1]](#ref-1). The export operation is described as ADS's "heterogeneity bridge" -- one canonical OASF record materialized into several downstream protocols' native card formats without changing its underlying storage representation [[1]](#ref-1). ADS does not define its own agent capability schema from scratch; it uses the separately-maintained Open Agentic Schema Framework (OASF, see oasf) as its native record format, and treats other ecosystems' formats (A2A cards, MCP server descriptors) as export targets rather than first-class stored types [[1]](#ref-1). Current state: the draft was published 6 July 2026 and expires 7 January 2027; it explicitly states it is "to be removed before publishing as an RFC," i.e. still a working draft rather than a finished document [[1]](#ref-1). Unlike several other records on this map, this one has a concrete, buildable open-source implementation (github.com/agntcy/dir) referenced directly from the spec text, which supports recording implementation as "shipping" -- but no independent count of production deployments or registered agents was located, so adoption remains unmeasured. What is disputed or unknown: how ADS's DHT-based global layer interacts in practice with a search-first, centralized-registry model like ARD's -- the "AI Catalog Interoperability" section of the draft describes projection and export, but whether third parties beyond AGNTCY's own tooling actually consume ADS-hosted records via the ai-catalog.json path was not independently verified here. ## Discovery and probe Content-addressed OCI-artifact storage plus a DHT for global skill-based discovery; a host-local AI Finder service exposes the same records over gRPC and a REST gateway · /.well-known/ai-catalog.json (host-local AI Finder); GET /v1/agents (REST API) ``` GET https://{origin}/v1/agents parse: 200 response is a paginated JSON list of CatalogEntry records; a companion GET /.well-known/ai-catalog.json returns the host's WellKnownCatalog document on absent: Host does not run an AGNTCY ADS AI Finder REST gateway; the record may still exist in the distributed hash table without a host-local HTTP surface ``` Live check run by [the MCP probe](/mcp/server-card): GET /v1/agents. An Agent Directory Service lists catalog entries as a JSON array at /v1/agents. ``` { "path": "/v1/agents", "expect": { "content_type": "json", "text_match": "\"(agents|entries|items|records)\"\\s*:\\s*\\[" }, "note": "An Agent Directory Service lists catalog entries as a JSON array at /v1/agents." } ``` ## History - 2026-09-05 — seeded from Exa Agent research run - 2026-09-06 — verified against draft-mp-agntcy-ads-02 spec text via datatracker.ietf.org - 2026-10-16 — use-case tags (auto) ## Instances - [Agora Protocol API (api.agoraproto.org)](https://api.agoraproto.org/) · Observed 2026-10-23 · origin Every instance with its source is listed on the [instances page](/instances/). Verified SDKs, reference implementations & validators: - [agntcy/dir (AGNTCY Directory reference implementation)](https://github.com/agntcy/dir) · implementation (2026-07-06) Our probe: seen on 1 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Builds on: [Open Agentic Schema Framework](/protocols/oasf/) - Pairs with: [Open Agentic Schema Framework](/protocols/oasf/), [Agentic Resource Discovery](/protocols/ard/), [AI Catalog well-known file](/protocols/ai-catalog-well-known-file/), [Agent2Agent Protocol](/protocols/a2a/), [Model Context Protocol](/protocols/mcp/), [GB/Z 185 Artificial intelligence — Agent interconnection (人工智能 智能体互联)](/protocols/gbz-185-agent-interconnection/) - Scanners & registries: [AGNTCY Directory specification](https://spec.dir.agntcy.org/) - Not to be confused with: ADS is a generic acronym also used for Active Directory Services and Alternate Data Streams; within the agentic space, unrelated to ARDS/ARD ## Comparisons - [DNS (A/SRV) & WHOIS vs AID & DNS-AID (classic vs agentic)](/compare/dns-whois-vs-aid/) ## References - draft-mp-agntcy-ads-02 (6 July 2026) defines ADS as a distributed directory service storing agent metadata as content-addressed OCI artifacts, discoverable via a DHT keyed on a skill taxonomy, and exposes an AI Finder service over gRPC and REST (GET /v1/agents, GET /v1/agents/{cid}, GET /v1/agents/{cid}/export, GET /.well-known/ai-catalog.json) that is explicitly interoperable with the AI Catalog / ARD ecosystem. — [https://datatracker.ietf.org/doc/html/draft-mp-agntcy-ads-02](https://datatracker.ietf.org/doc/html/draft-mp-agntcy-ads-02) (2026-07-06) VERIFIED - AGNTCY published a technical note describing AI Catalog interoperability layered over its directory service. — [https://blogs.agntcy.org/technical/2026/06/17/ai-catalog-over-directory.html](https://blogs.agntcy.org/technical/2026/06/17/ai-catalog-over-directory.html) (2026-06-17) REPORTED [JSON](/data/protocols/ads.json) · [Markdown](/protocols/ads/index.md) · [OKF v0.2](/okf/protocols/ads.md) --- # Agent Discovery Protocol (ADP · /.well-known/agent.json) Agent Discovery Protocol (ADP) is an agentic-web standard (well-known file — /.well-known/agent.json) at step 1, Discover, governed by IETF individual Internet-Draft; its status is "Internet-Draft". It answers: "How does an agent escalate from a cheap DNS lookup, to a well-known JSON metadata document, to a real-time WebSocket…?" Implementation status is prototype, last verified 2026-10-23. ## Quick Wire Reference - **Step**: 1 Discover (What is here, and where?) - **Version**: draft-pro-adp-agent-discovery-02 (2026-07-24) - **Status**: Internet-Draft; work in progress · prototype - **Discovery / Probe Path**: /.well-known/agent.json — Layer 1 DNS-AID (SVCB/TLSA), Layer 2 well-known JSON metadata… - **Spec URL**: https://datatracker.ietf.org/doc/html/draft-pro-adp-agent-discovery-02 - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: a layered service-discovery stack (DNS SRV -> REST descriptor -> live connection)… [Discover](/category/discover/) The Agent Discovery Protocol (ADP) is a layered protocol, currently at v1.1, for discovering, verifying, and interacting with AI agents on the internet [[1]](#ref-1). It is an individual IETF Internet-Draft (not adopted by any working group), revision -02, dated 24 July 2026 (succeeding -01 of 18 June 2026) [[1]](#ref-1)[[3]](#ref-3). ## Overview ADP's organizing idea is escalation: "if SVCB answers your question, do not issue an HTTP request; if Well-Known suffices, do not open a WebSocket" [[1]](#ref-1). It is explicitly a three-layer stack. Layer 1 is DNS discovery, and rather than redefine it, ADP delegates entirely to the separate DNS-AID Internet-Draft (see dns-aid), reusing its SVCB records, its well-known/cap/cap-sha256 SvcParamKeys, and its DANE TLSA-based endpoint authentication [[1]](#ref-1). Layer 2 is a well-known JSON metadata document, published by default at /.well-known/agent.json, containing identity, capability, relationship, security-policy and endpoint-map blocks [[1]](#ref-1). Layer 3 covers interaction endpoints: an HTML landing page at the domain root with embedded JSON-LD structured data for human-facing discovery, plus a WebSocket transport -- the Agent Gateway Protocol (AGP) -- for real-time inter-agent messaging authenticated with Ed25519 signatures [[1]](#ref-1). A TXT+SRV fallback exists for organizations that cannot deploy SVCB records [[1]](#ref-1). ADP does not itself mint a new DNS mechanism (Layer 1 is DNS-AID verbatim) and does not define the internal schema of whatever protocol Layer 3 ultimately hands off to (MCP, A2A, etc. remain external, similar to ARD's artifact-agnostic envelope) [[1]](#ref-1). Because it explicitly reuses DNS-AID, the two drafts should be read together rather than as fully independent proposals: ADP's Layer 1 section is a summary that points back to the normative DNS-AID text. Current state: revision -02 was published 24 July 2026 (after -01 on 18 June 2026), expiring 25 January 2027 unless refreshed, and its "Changes from -00" section (part of the table of contents) indicates it is still actively being revised rather than stable [[1]](#ref-1). A single-author reference implementation was located at github.com/harrylian8766/adp-protocol (5 stars, 1 fork, fetched 2026-09-06): a Node.js SDK and CLI implementing all three layers (SVCB-first DNS discovery aligned with DNS-AID's SvcParamKeys, the agent.json builder, HTML landing-page generation, and Ed25519 verification), published under a CC0 protocol license / MIT SDK license [[2]](#ref-2). This is a solo hobbyist project rather than a vendor or standards-body implementation, so implementation is recorded as prototype rather than shipping; no independent deployment or adopter evidence was located, so adoption remains unmeasured. What is disputed or unknown: whether ADP's Layer 2/3 additions (the well-known JSON schema, the WebSocket AGP transport) will be adopted independently of whether DNS-AID itself is adopted, since the two are only loosely coupled (an implementer could deploy DNS-AID without ADP's higher layers, or vice versa using the TXT+SRV fallback); and how ADP's /.well-known/agent.json relates to the similarly-named but structurally different /.well-known/agent fallback defined by the unrelated AID specification (see aid) -- both use the word "agent" in a well-known path but are not the same document format. ## Discovery and probe Layer 1 DNS-AID (SVCB/TLSA), Layer 2 well-known JSON metadata, Layer 3 HTML landing page + JSON-LD + WebSocket (Agent Gateway Protocol) · /.well-known/agent.json ``` GET https://{origin}/.well-known/agent.json parse: 200 response is a JSON document with identity/endpoints/capabilities/security top-level blocks on absent: Domain does not publish ADP Layer 2 metadata; check for a DNS-AID SVCB record with a well-known SvcParamKey as a possible Layer 1-only deployment ``` Live check run by [the MCP probe](/mcp/server-card): GET /.well-known/agent.json. An ADP agent.json has identity and endpoints blocks. ``` { "path": "/.well-known/agent.json", "expect": { "json_keys": [ "identity", "endpoints" ] }, "note": "An ADP agent.json has identity and endpoints blocks." } ``` ## History - 2026-09-05 — seeded from Exa Agent research run - 2026-09-06 — verified against draft-pro-adp-agent-discovery-02 spec text via datatracker.ietf.org - 2026-09-06 — fix round 1: added second evidence entry (harrylian8766/adp-protocol reference implementation, fetched directly); upgraded implementation unknown -> prototype on that basis - 2026-10-16 — draft-pro-adp-agent-discovery-02 is dated 2026-07-24 - 2026-10-16 — use-case tags (auto) ## Instances Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Builds on: [DNS for AI Discovery](/protocols/dns-aid/) - Pairs with: [DNS for AI Discovery](/protocols/dns-aid/), [Agent Identity and Discovery](/protocols/aid/), [Agent2Agent Protocol](/protocols/a2a/), [Model Context Protocol](/protocols/mcp/), [Agentic Resource Discovery](/protocols/ard/) - Not to be confused with: ADP is a generic acronym also used for 'Agile Development Process' and unrelated ADP payroll/HR company; within the agentic space, distinct from ARDP (Agent Registration and Discovery Protocol) and AID/DNS-AID ## Comparisons - [Agent Identity and Discovery vs Agent Discovery Protocol](/compare/aid-vs-adp/) ## References - draft-pro-adp-agent-discovery-02 (18 June 2026) defines ADP v1.1 as a three-layer stack: Layer 1 delegates entirely to DNS-AID (SVCB records), Layer 2 defines a GET-able /.well-known/agent.json metadata document, and Layer 3 defines an HTML landing page plus a WebSocket-based Agent Gateway Protocol (AGP) with Ed25519 signature authentication for real-time messaging. — [https://datatracker.ietf.org/doc/html/draft-pro-adp-agent-discovery-02](https://datatracker.ietf.org/doc/html/draft-pro-adp-agent-discovery-02) (2026-06-18) VERIFIED - A reference implementation exists at github.com/harrylian8766/adp-protocol (5 stars, 1 fork, fetched 2026-09-06): a Node.js SDK (protocol identifier urn:adp:1.1) implementing SVCB-first DNS discovery, TLSA/DANE, the /.well-known/agent.json builder, HTML landing-page generation, and a CLI, explicitly version-aligned with draft-pro-adp-agent-discovery-02 and cross-referencing draft-mozleywilliams-dnsop-dnsaid for SvcParamKey usage. — [https://github.com/harrylian8766/adp-protocol](https://github.com/harrylian8766/adp-protocol) (2026-09-06) VERIFIED - draft-pro-adp-agent-discovery-02 is dated 2026-07-24 — [https://datatracker.ietf.org/doc/draft-pro-adp-agent-discovery/](https://datatracker.ietf.org/doc/draft-pro-adp-agent-discovery/) (2026-07-24) VERIFIED [JSON](/data/protocols/adp.json) · [Markdown](/protocols/adp/index.md) · [OKF v0.2](/okf/protocols/adp.md) --- # Agent Identity and Discovery (AID · /.well-known/agent) Agent Identity and Discovery (AID) is an agentic-web standard (DNS record — /.well-known/agent) at step 1, Discover, governed by Agent Community open-source project; its status is "Current normative specification". It answers: "Given a domain, where is the agent and which protocol should I speak, with cryptographic proof the endpoint controls the…?" Implementation status is shipping, last verified 2026-10-23. ## Quick Wire Reference - **Step**: 1 Discover (What is here, and where?) - **Version**: v2.1.0 (aid2 wire format; aid1 legacy) (2026-06-01) - **Status**: Current normative specification · shipping - **Discovery / Probe Path**: /.well-known/agent — DNS TXT record at a fixed base name, with an HTTPS well-known fallback - **Spec URL**: https://raw.githubusercontent.com/agentcommunity/agent-identity-discovery/main/packages/docs/specification.md - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: a DNS SRV/TXT record for agents, with a TLS-certificate-like endpoint proof bolted on [Discover](/category/discover/) Agent Identity & Discovery (AID) answers "given a domain, where is the agent and which protocol should I speak?" using a single DNS TXT record published at the fixed base name _agent. [[1]](#ref-1). It is deliberately minimal: after AID resolves an endpoint and protocol token, richer protocols (MCP, A2A, OpenAPI, OAuth) take over for the actual interaction [[1]](#ref-1). It is maintained by "Agent Community" as an open-source project (agentcommunity/agent-identity-discovery on GitHub) rather than through any formal standards body. ## Overview The current wire format is v2 (aid2), current since 1 June 2026, which supersedes a legacy aid1 format kept only for backward compatibility during a migration window [[1]](#ref-1). A record is a semicolon-delimited key=value string with required version/uri/proto (or their single-letter aliases v/u/p), and optional fields for auth hints, description, docs link, deprecation date, and an Ed25519 public key (pka/k) used for endpoint proof [[1]](#ref-1). When a key is present, an AID client performs a PKA (Public-Key-for-Agent) handshake -- HTTP Message Signatures (RFC 9421) over a nonce challenge, keyed by an RFC 7638 JWK thumbprint -- to verify the endpoint controls the corresponding private key [[1]](#ref-1). A newer "domain-binding" profile (Appendix B.7) lets the endpoint additionally attest that it consents to serve the specific queried domain, closing a gap where any domain could otherwise publish another party's endpoint and key without that endpoint's consent [[1]](#ref-1). AID is explicit about what it does not do: it does not issue credentials, grant authorization, prove human approval, define SPIFFE/WIMSE trust-domain federation, or manage cryptographic key rotation -- a key change is simply a key change, with no DNS-level provenance chain [[1]](#ref-1). Discovery is exact-host only; clients must not walk up to parent domains, though CNAME delegation lets child hosts share a record explicitly [[1]](#ref-1). A .well-known/agent HTTP fallback exists for environments (some managed DNS panels) where TXT record creation is restricted, but that path's trust rests on TLS rather than DNS, and cannot satisfy a dnssec=require policy [[1]](#ref-1). The project's own GitHub repository (47 stars, 8 forks, fetched 2026-09-06) shows real shipped code: published npm (@agentcommunity/aid) and PyPI (aid-discovery) packages, source-available Go/Rust/.NET/Java libraries, an aid-doctor CLI, a live interactive workbench, and at least one documented live showcase domain (supabase.agentcommunity.org) [[2]](#ref-2) -- so implementation is recorded as shipping. No independent count of AID-publishing domains beyond that one showcase example was located, so adoption is recorded as observed rather than measured. The specification's own roadmap flags that a future major version (aid3) is expected to make domain-binding mandatory rather than optional-with-default, once adoption is broad enough that the switching cost is low [[1]](#ref-1). What is disputed: AID's DNS-TXT approach and the separately-authored, IETF-track DNS-AID specification (see dns-aid) solve the identical "resolve a domain to an agent endpoint" problem with incompatible record shapes (TXT vs. SVCB), and no evidence of coordination between the two efforts was found in the texts read for this verification. ## Discovery and probe DNS TXT record at a fixed base name, with an HTTPS well-known fallback · _agent. (DNS TXT); /.well-known/agent (HTTP fallback) ``` GET https://{origin}/.well-known/agent parse: 200 response is JSON mirroring the v2 TXT record keys (version, uri, proto, auth, ...); trustSource is reported as well-known-tls rather than dns for this path on absent: No well-known fallback; query DNS TXT at _agent.{domain} directly (not curl-executable) -- absence of both means the domain does not publish AID ``` Live check run by [the MCP probe](/mcp/server-card): GET /.well-known/agent. The AID well-known document mirrors the DNS TXT record, including uri. ``` { "path": "/.well-known/agent", "expect": { "content_type": "json", "json_keys": [ "uri" ] }, "note": "The AID well-known document mirrors the DNS TXT record, including uri." } ``` ## History - 2026-09-05 — seeded from Exa Agent research run - 2026-09-06 — verified against AID v2.1.0 spec text via raw.githubusercontent.com - 2026-09-06 — fix round 1: added second evidence entry (agentcommunity GitHub repo, fetched directly) showing real published multi-language packages; upgraded implementation unknown -> shipping and adoption unmeasured -> observed on that basis - 2026-10-16 — use-case tags (auto) - 2026-10-16 — version packages/aid-go/v2.1.1 (watcher) - 2026-10-16 — version label restored to 'v2.1.0 (aid2 wire format; aid1 legacy)'; the repository's latest tag (packages/aid-go/v2.1.1) is a package, SDK or build tag, not the specification version, so the GitHub watch no longer drives version ## Instances - [Agent Community / Open Agent Registry (AID)](https://agentcommunity.org) · Observed 2026-10-23 · venue Every instance with its source is listed on the [instances page](/instances/). Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Builds on: [HTTP Message Signatures](/protocols/http-message-signatures/) - Pairs with: [DNS for AI Discovery](/protocols/dns-aid/), [Model Context Protocol](/protocols/mcp/), [Agent2Agent Protocol](/protocols/a2a/), [HTTP Message Signatures](/protocols/http-message-signatures/), [Agent Name Service v2 (ANS)](/protocols/ans/), [Agentic Resource Discovery](/protocols/ard/) - Not to be confused with: DNS-AID (unrelated IETF dnsop draft that solves the same problem with SVCB instead of TXT), AID also collides with generic 'agent ID' usage elsewhere ## Comparisons - [DNS (A/SRV) & WHOIS vs AID & DNS-AID (classic vs agentic)](/compare/dns-whois-vs-aid/) - [Agent Identity and Discovery vs DNS for AI Discovery](/compare/aid-vs-dns-aid/) - [Agent Identity and Discovery vs Agent2Agent Protocol](/compare/aid-vs-a2a/) - [Agent Identity and Discovery vs Agent Discovery Protocol](/compare/aid-vs-adp/) ## References - AID v2.1.0 (1 June 2026, agentcommunity.org) defines a DNS TXT record at the canonical base name _agent. with required keys v/u/p (version/uri/proto), an optional Ed25519 endpoint-proof key (pka/k), and a JSON .well-known/agent HTTP fallback for environments where DNS TXT record creation is restricted. — [https://raw.githubusercontent.com/agentcommunity/agent-identity-discovery/main/packages/docs/specification.md](https://raw.githubusercontent.com/agentcommunity/agent-identity-discovery/main/packages/docs/specification.md) (2026-06-01) VERIFIED - The agentcommunity/agent-identity-discovery GitHub repository (47 stars, 8 forks, 5 contributors, fetched 2026-09-06) shows AID v2 shipped as published packages -- npm @agentcommunity/aid, PyPI aid-discovery, plus source-available Go/Rust/.NET/Java libraries -- an official aid-doctor CLI, a live interactive workbench at aid.agentcommunity.org, and a documented live showcase domain (supabase.agentcommunity.org) used in the README's own Go example, i.e. a real, multi-language, actively maintained implementation exists beyond the specification text alone. — [https://github.com/agentcommunity/agent-identity-discovery](https://github.com/agentcommunity/agent-identity-discovery) (2026-09-06) VERIFIED - packages/aid-go/v2.1.1 released 2026-06-01 — [https://github.com/agentcommunity/agent-identity-discovery/releases/tag/packages/aid-go/v2.1.1](https://github.com/agentcommunity/agent-identity-discovery/releases/tag/packages/aid-go/v2.1.1) (2026-10-15) VERIFIED Disputed: AID (agentcommunity.org) and DNS-AID (IETF dnsop draft-mozleywilliams) both answer 'given a domain, where is the agent and which protocol' but chose incompatible DNS shapes -- a single TXT record with key=value pairs, versus an SVCB RRset with SvcParamKeys and a separate _index._agents label. No evidence either project references or coordinates with the other in the text fetched for this record. [JSON](/data/protocols/aid.json) · [Markdown](/protocols/aid/index.md) · [OKF v0.2](/okf/protocols/aid.md) --- # Agent Identity Protocol (AIP) Agent Identity Protocol (AIP) is an agentic-web standard (endpoint) at step 2, Identify, governed by IETF individual draft; its status is "Internet-Draft, Intended Status: Standards Track". It answers: "How can an autonomous agent prove a decentralized identity and a verifiable chain of delegated authority from its human…?" Implementation status is none found, last verified 2026-10-23. ## Quick Wire Reference - **Step**: 2 Identify (Who is this agent? Who is this site?) - **Version**: draft-singla-agent-identity-protocol-03, published 2026-06-10 (2026-06-10) - **Status**: Internet-Draft, Intended Status: Standards Track (author's stated intent; not… - **Discovery / Probe Path**: none — W3C Decentralized Identifier (DID) resolution plus cryptographic… - **Spec URL**: https://datatracker.ietf.org/doc/html/draft-singla-agent-identity-protocol-03 - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: W3C DID plus a delegated-capability credential chain [Identify](/category/identify/) The Agent Identity Protocol (AIP) is a proposed decentralized identity, delegation, and authorization framework for autonomous AI agents. It combines W3C Decentralized Identifiers (did:aip, derived from an agent's Ed25519 key), capability-based authorization (Capability Manifests), cryptographic delegation chains with scope attenuation (default depth 3, hard cap 10), an AIP-GRANT consent ceremony, and a Registry that issues short-lived signed Credential Tokens and DPoP-bound OAuth 2.0 tokens via RFC 8693 token exchange for MCP servers [[1]](#ref-1). ## Overview It targets the "identity gap" the author identifies: when an autonomous agent presents itself to an API, a payment processor, or another agent, there is today no standard way to establish the agent's persistent identity across interactions, which human or organization it acts on behalf of, or exactly which actions it is authorized to take [[1]](#ref-1). Current state: draft-singla-agent-identity-protocol-03, published 2026-06-10 (expiring 2026-12-12), a sole-author IETF Internet-Draft by Paras Singla under the Network Working Group umbrella (not a chartered WG) [[2]](#ref-2). The author lists "Standards Track" as the intended status, which reflects the author's stated intent rather than IETF working-group adoption [[2]](#ref-2). Who implements it: no implementation, reference library, or deployment was located in this pass. Disputed or unknown: whether AIP will be picked up by any chartered WG or remain an individual proposal. The AIP acronym and did:aip method name also collide with other proposals (draft-prakash-aip and a Solana-based did:aip entry in the W3C DID method registry), so readers should confirm they mean this specific draft. ## Discovery and probe W3C Decentralized Identifier (DID) resolution plus cryptographic delegation-chain verification · none ``` n/a n/a (client-side protocol; no fixed origin artifact) parse: n/a on absent: Absence of a site artifact means nothing; AIP is negotiated between agents. ``` Not probed live: client-side. AIP is a client-side identity protocol with no origin artefact. ## History - 2026-09-05 — seeded from Exa Agent research run - 2026-09-06 — verified against draft-singla-agent-identity-protocol-03's abstract, introduction and document header; flagged limited depth of review and the AIP acronym collision - 2026-10-16 — use-case tags (auto) ## Instances Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Pairs with: [ERC-8004: Trustless Agents](/protocols/erc-8004/), [Agent Name Service v2 (ANS)](/protocols/ans/), [Agent Authorization Grant](/protocols/aauth/), [Workload Identity in Multi System Environments (WIMSE) Architecture](/protocols/wimse/), [Model Context Protocol](/protocols/mcp/) - Not to be confused with: Agent Interaction Protocol (unrelated proposals sometimes use the same AIP initialism), did:aip Solana-based DID method in the W3C DID method registry, Agent Identity Protocol (Prakash, draft-prakash-aip / arXiv 2603.24775) ## References - AIP defines a decentralized identity, delegation and authorization framework for autonomous AI agents combining W3C DIDs, capability-based authorization, cryptographic delegation chains and deterministic validation, aiming to avoid reliance on centralized identity providers; it is a sole-author Internet-Draft (Paras Singla, Independent) with Standards Track as the author's intended status, and no working-group sponsorship, as shown on its ietf.org archive header — [https://www.ietf.org/archive/id/draft-singla-agent-identity-protocol-03.html](https://www.ietf.org/archive/id/draft-singla-agent-identity-protocol-03.html) (2026-06-10) REPORTED - The IETF Datatracker's document page for draft-singla-agent-identity-protocol shows Document Type 'Active Internet-Draft (individual)', RFC stream '(None)', Intended RFC status '(None)', and last updated 2026-06-09 -- confirming no working-group has taken up the draft. — [https://datatracker.ietf.org/doc/draft-singla-agent-identity-protocol/](https://datatracker.ietf.org/doc/draft-singla-agent-identity-protocol/) (2026-06-09) REPORTED Disputed: This is a single-author draft with an author-stated Standards Track intent but no WG sponsorship and no located implementation; the acronym AIP is also used elsewhere for unrelated agent-interaction proposals, which is a collision worth flagging to readers. [JSON](/data/protocols/aip.json) · [Markdown](/protocols/aip/index.md) · [OKF v0.2](/okf/protocols/aip.md) --- # Agent Identity Protocol (AIP): Verifiable Delegation for AI Agent Systems (/.well-known/aip/.json) Agent Identity Protocol (AIP): Verifiable Delegation for AI Agent Systems is an agentic-web standard (document format — /.well-known/aip/.json) at step 3, Permit, governed by Individual Internet-Draft by a single independent author; its status is "Internet-Draft, Intended Status: Standards Track". It answers: "How can a relying party verify from a token and the issuer's public key who delegated authority, which agents it passed…?" Implementation status is none found, last verified 2026-10-23. ## Quick Wire Reference - **Step**: 3 Permit (What may the agent do here?) - **Version**: draft-prakash-aip-02 (2026-10-10) - **Status**: Internet-Draft, Intended Status: Standards Track; expires 13 April 2027 · none… - **Discovery / Probe Path**: /.well-known/aip/.json — Self-signed agent identity document at a well-known HTTPS path… - **Spec URL**: https://datatracker.ietf.org/doc/html/draft-prakash-aip-02 - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: Attenuable capability tokens (Biscuit), applied to agent-to-agent subdelegation [Permit](/category/permit/) AIP conveys delegated authority along a chain of AI agents so a relying party can verify the grantor, the path, and that each hop only narrowed authority. It defines an encoding-neutral chain model with a single attenuation invariant, a normative verification algorithm, and two encodings (a JWT chain and a Biscuit token with Datalog policy). It defines bindings for MCP, A2A and generic HTTP, and is intended to compose with the AIMS framework. Agent identifiers are aip:web (DNS-based) or aip:key (self-certifying Ed25519). ## Discovery and probe Self-signed agent identity document at a well-known HTTPS path derived from the aip:web identifier · /.well-known/aip/.json ``` GET /.well-known/aip/.json parse: Parse JSON; check aip equals "1.0", id is an AIP identifier, and document_signature verifies over the JCS-canonicalized document on absent: Treat the site or agent as not supporting AIP ``` Not probed live: no-fixed-path. candidate record; probe rule pending ## History - 2026-10-16 — auto-drafted candidate from exa (https://datatracker.ietf.org/doc/html/draft-prakash-aip-02) ## Instances Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Pairs with: [Model Context Protocol](/protocols/mcp/), [Agent2Agent Protocol](/protocols/a2a/), [WIMSE AI Identity Management System](/protocols/wimse-aims/), [Credential Delegation Protocol for AI Agents in Multi-System Environments](/protocols/credential-delegation-protocol-wimse/) - Not to be confused with: aip ## Comparisons - [Agent Identity Protocol (AIP): Verifiable Delegation for AI Agent Systems vs Credential Delegation Protocol for AI Agents in Multi-System Environments](/compare/aip-delegation-chain-vs-credential-delegation-protocol-wimse/) ## References - The draft specifies AIP, a delegation chain model with an attenuation invariant, a verification algorithm, JWT-chain and Biscuit encodings, and bindings for MCP, A2A and HTTP. — [https://datatracker.ietf.org/doc/html/draft-prakash-aip-02](https://datatracker.ietf.org/doc/html/draft-prakash-aip-02) (2026-10-10) REPORTED [JSON](/data/protocols/aip-delegation-chain.json) · [Markdown](/protocols/aip-delegation-chain/index.md) · [OKF v0.2](/okf/protocols/aip-delegation-chain.md) --- # Agent Name Service v2 (ANS) Agent Name Service v2 (ANS) is an agentic-web standard (DNS record) at step 2, Identify, governed by IETF Independent Submission; its status is "Expired Internet-Draft". It answers: "What domain-anchored identity belongs to an autonomous agent, and at what assurance tier can that identity be trusted?" Replacing or extending DNS/DNSSEC name plus certificate transparency log, implementation status is none found, last verified 2026-10-23. ## Quick Wire Reference - **Step**: 2 Identify (Who is this agent? Who is this site?) - **Version**: draft-narajala-courtney-ansv2-01, last updated 2026-04-15 (replaces… - **Status**: Expired Internet-Draft (expired 2026-10-15) · none found - **Discovery / Probe Path**: none — A Registration Authority verifies domain ownership via ACME and issues a… - **Spec URL**: https://datatracker.ietf.org/doc/draft-narajala-courtney-ansv2/ - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: DNS/DNSSEC name plus certificate transparency log [Identify](/category/identify/) Agent Name Service v2 (ANS) is a proposed identity architecture that anchors every autonomous agent's identity to a DNS domain name it controls, rather than to a platform-specific account or an unverified self-asserted name [[1]](#ref-1). A Registration Authority (RA) verifies domain ownership via the ACME protocol (the same mechanism Let's Encrypt uses for TLS certificates) and then issues two certificates: a Server Certificate from a public Certificate Authority, and an Identity Certificate from a private CA binding a version-specific "ANSName" to that domain [[1]](#ref-1). Every lifecycle event (issuance, rotation, revocation) is sealed into an append-only Transparency Log aligned with the IETF's SCITT (Supply Chain Integrity, Transparency, and Trust) work, and clients can pick from three assurance tiers — Bronze (PKI only), Silver (PKI plus DANE), or Gold (PKI plus DANE plus the Transparency Log) — matched to how much a given transaction has at risk [[1]](#ref-1). ## Overview It solves domain-anchored, auditable agent identity where the party relying on the identity did not provision it. Its design explicitly decouples identity issuance (owned by the RA) from discovery (left to independent, competing Discovery Services that index the sealed events), and separates a three-layer trust model: Layer 1 foundational identity (this protocol), Layer 2 operational-maturity attestation by third-party assessors, and Layer 3 real-time behavioral reputation scoring — only Layer 1 is specified here [[1]](#ref-1). It does not itself define reputation scoring, message formats for agent-to-agent communication, or any fixed DNS record type or well-known HTTP path we could locate in the text reviewed; those remain open or left to Discovery Services. Current state: an Independent Submission Internet-Draft — not sponsored by any IETF working group — first published as draft-narajala-ans in May 2025 and renamed/rewritten as draft-narajala-courtney-ansv2, currently at revision -01 (last updated 2026-04-15) [[1]](#ref-1). Authors span GoDaddy, OWASP, and Cisco. Who implements it: no running implementation, reference code, or deployed Registration Authority was found in this pass. GoDaddy and Infoblox issued a joint press release in May 2026 announcing support for open standards for AI-agent discovery, identity and verification, but this is a statement of intent about the space rather than confirmed evidence that ANS v2 specifically is deployed [[2]](#ref-2). Disputed or unknown: whether GoDaddy's announced support is for this exact spec version; whether any Registration Authority or Discovery Service exists yet; and how the fixed discovery mechanics (DNS record type, well-known path) will be finalized are all open. ## Discovery and probe A Registration Authority verifies domain ownership via ACME and issues a dual certificate (public-CA Server Certificate + private-CA Identity Certificate binding a version-specific ANSName); lifecycle events are sealed into an append-only SCITT-aligned Transparency Log · none ``` GET n/a — no fixed well-known path or DNS record type is defined in the draft text reviewed parse: Resolve the ANSName's Identity Certificate chain and check the Transparency Log for a matching sealed registration event on absent: No ANS identity is bound to the domain; the agent cannot be verified at any of ANS's three assurance tiers (Bronze/Silver/Gold) ``` Not probed live: no-fixed-path. The ANS draft defines no fixed well-known path or record type. ## History - 2026-09-05 — seeded from Exa Agent research run - 2026-09-06 — verified against draft-narajala-courtney-ansv2-01 primary text and the GoDaddy/Infoblox press release - 2026-10-16 — Expired Internet-Draft (expired 2026-10-15) - 2026-10-16 — use-case tags (auto) - 2026-10-20 — version label notes expiry ## Instances - [GoDaddy Agent Name Service (ANS) Authority](https://github.com/godaddy/ans) · Observed 2026-07-15 · authority Every instance with its source is listed on the [instances page](/instances/). Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Pairs with: [DNS for AI Discovery](/protocols/dns-aid/), [SPIFFE (Secure Production Identity Framework for Everyone)](/protocols/spiffe/), [Workload Identity in Multi System Environments (WIMSE) Architecture](/protocols/wimse/), [Signature Agent Card (Web Bot Auth registry)](/protocols/web-bot-auth-signature-agent-card/), [Agent2Agent Protocol](/protocols/a2a/), [Agent Identity and Discovery](/protocols/aid/) ## Comparisons - [DNS (A/SRV) & WHOIS vs AID & DNS-AID (classic vs agentic)](/compare/dns-whois-vs-aid/) - [ERC-8004: Trustless Agents vs Agent Name Service v2 (ANS)](/compare/erc-8004-vs-ans/) - [Agent Name Service v2 (ANS) vs DNS-Based Agent Naming](/compare/ans-vs-dan/) ## References - ANS v2 anchors every agent identity to a DNS domain name, issues dual PKI certificates via an ACME-verified Registration Authority, seals lifecycle events into a SCITT-aligned Transparency Log, and defines three assurance tiers (Bronze: PKI; Silver: PKI+DANE; Gold: PKI+DANE+Transparency Log) — [https://datatracker.ietf.org/doc/draft-narajala-courtney-ansv2/](https://datatracker.ietf.org/doc/draft-narajala-courtney-ansv2/) (2026-04-15) VERIFIED - GoDaddy and Infoblox announced joint support for open standards for AI-agent discovery, identity and verification — [https://aboutus.godaddy.net/newsroom/news-releases/press-release-details/2026/Infoblox-and-GoDaddy-Support-Open-Standards-for-AI-Agent-Discovery-Identity-and-Verification-2026-0acKMntvOC/default.aspx](https://aboutus.godaddy.net/newsroom/news-releases/press-release-details/2026/Infoblox-and-GoDaddy-Support-Open-Standards-for-AI-Agent-Discovery-Identity-and-Verification-2026-0acKMntvOC/default.aspx) (2026-05-14) REPORTED - Expired Internet-Draft (expired 2026-10-15) — [https://datatracker.ietf.org/doc/draft-narajala-courtney-ansv2/](https://datatracker.ietf.org/doc/draft-narajala-courtney-ansv2/) (2026-04-13) VERIFIED Disputed: This is an Independent Submission with no IETF working-group sponsorship and no implementation found in this pass; the GoDaddy/Infoblox press release announces support for standards in this space generally and should not be read as confirmation that ANS v2 specifically has been deployed. [JSON](/data/protocols/ans.json) · [Markdown](/protocols/ans/index.md) · [OKF v0.2](/okf/protocols/ans.md) --- # Agent Network Protocol (ANP · /.well-known/agent-descriptions) Agent Network Protocol (ANP) is an agentic-web standard (well-known file — /.well-known/agent-descriptions) at step 6, Coordinate, governed by Community-led open-source project; its status is "Released v1.2". It answers: "How can decentralized agents from different platforms authenticate, discover, and message each other without a central…?" Implementation status is shipping, last verified 2026-10-23. ## Quick Wire Reference - **Step**: 6 Coordinate (Talk to another agent) - **Version**: v1.2 (2026-09-24) - **Status**: Released v1.2 (core suite); meta-protocol (ANP-06) remains draft/unreleased ·… - **Discovery / Probe Path**: /.well-known/agent-descriptions — Agent Discovery Service Protocol (ADSP), active .well-known… - **Spec URL**: https://github.com/agent-network-protocol/AgentNetworkProtocol - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: none [Coordinate](/category/coordinate/) The Agent Network Protocol (ANP) is a suite of open specifications describing itself as aiming to become "the HTTP of the Agentic Web era": a protocol stack for agent identity, naming, discovery, negotiation, secure messaging, and application-level collaboration [[1]](#ref-1). It solves several coordinate-layer problems at once rather than one narrow one: did:wba (ANP-03) gives agents a Web-based DID identity method; ANP-04 layers human-readable WNS handles (e.g. alice.example.com) over DIDs; ANP-07 defines machine-readable Agent Description documents; ANP-08 (the Agent Discovery Protocol, ADSP) defines active discovery via a well-known JSON-LD collection page and a passive registration API for search-service agents; ANP-09 defines an end-to-end encrypted instant-messaging profile suite (direct and group messaging, attachments, federation, mentions); and ANP-10 layers an agent payment protocol (AP2) on top [[1]](#ref-1)[[2]](#ref-2). ## Overview ANP explicitly does not rebuild core internet infrastructure — it reuses HTTP, DNS, CA/TLS, CDN, and search rather than defining a new network stack — and its meta-protocol layer (ANP-06, a semantic negotiation layer analogous in spirit to Agora's protocol negotiation) remains an unreleased draft, not part of the currently released architecture [[1]](#ref-1). The released specification suite reached v1.2 on 2026-09-24 [[3]](#ref-3) (succeeding v1.1 of September 2026, where the wire-level protocolVersion field remained "1.0.0" in released message examples [[1]](#ref-1)). Discovery is confirmed executable: GET https://{domain}/.well-known/agent-descriptions should return a JSON-LD CollectionPage whose items[] array lists ad:AgentDescription entries with pagination via a next field, per RFC 8615 conventions [[2]](#ref-2). The project also publishes vNext draft revisions (ANP-01 through ANP-09) that do not yet replace the released v1.1 text, and a separately versioned ANP Messaging 1.2 draft for multi-device cryptographic endpoints. What is unresolved: no independently measured count of live ANP deployments was found in this pass — adoption here is recorded as unmeasured, and the seed's prior "v0.1, experimental" characterization understated the protocol's actual maturity (v1.1, released), which was corrected in this pass. ## Discovery and probe Agent Discovery Service Protocol (ADSP), active .well-known discovery · /.well-known/agent-descriptions ``` GET {origin}/.well-known/agent-descriptions parse: JSON-LD CollectionPage document with an items[] array of ad:AgentDescription entries confirms ANP active discovery is exposed on absent: 404 or non-JSON-LD response means the domain does not expose ANP active discovery; agents there may still be reachable only via passive registration with a search service ``` Live check run by [the MCP probe](/mcp/server-card): GET /.well-known/agent-descriptions. ANP active discovery is a JSON-LD collection of AgentDescription items. ``` { "path": "/.well-known/agent-descriptions", "expect": { "content_type": "json", "text_match": "AgentDescription" }, "note": "ANP active discovery is a JSON-LD collection of AgentDescription items." } ``` ## History - 2026-09-05 — seeded from Exa Agent research run - 2026-09-06 — verified against agent-network-protocol.com and github.com/agent-network-protocol/AgentNetworkProtocol README + ANP-08 discovery spec; corrected version from v0.1/experimental to released v1.1 and filled discovery path - 2026-10-16 — Agent Network Protocol v1.2 released on 2026-09-24 - 2026-10-16 — use-case tags (auto) ## Instances - [AgentConnect (ANP DID:WBA Agent Node)](https://github.com/agent-network-protocol/AgentConnect) · Observed 2026-07-23 · agent Every instance with its source is listed on the [instances page](/instances/). Verified SDKs, reference implementations & validators: - [agent-network-protocol/AgentNetworkProtocol (specification repository)](https://github.com/agent-network-protocol/AgentNetworkProtocol) · implementation (2026-09-05) Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Builds on: [HTTP Message Signatures](/protocols/http-message-signatures/) - Pairs with: [Agent2Agent Protocol](/protocols/a2a/), [Agent Name Service v2 (ANS)](/protocols/ans/), [Agora Protocol](/protocols/agora-protocol/), [Model Context Protocol](/protocols/mcp/), [Agent Payments Protocol](/protocols/ap2/), [LMOS (Language Model Operating System)](/protocols/lmos/) ## Comparisons - [Webhooks & RPC vs Agent2Agent Protocol (A2A) (classic vs agentic)](/compare/webhooks-vs-a2a/) - [Agent2Agent Protocol vs Agent Network Protocol](/compare/a2a-vs-anp/) - [Agent Network Protocol vs Model Context Protocol](/compare/anp-vs-mcp/) - [Agent Network Protocol vs Coral Protocol (CoralOS)](/compare/anp-vs-coral-protocol/) ## References - ANP's released specification suite (v1.1) covers did:wba identity, WNS handles, agent description (ANP-07), agent discovery (ANP-08), end-to-end instant messaging (ANP-09), and the AP2 agent payment protocol (ANP-10); the meta-protocol (ANP-06) remains an unreleased draft. — [https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/main/README.md](https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/main/README.md) (2026-09-05) VERIFIED - ANP-08 (Agent Discovery Protocol, Released v1.1) defines active discovery via the well-known path https://{domain}/.well-known/agent-descriptions, returning a JSON-LD CollectionPage listing agent description documents, plus a passive registration API for search-service agents. — [https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/main/08-ANP-Agent-Discovery-Protocol-Specification.md](https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/main/08-ANP-Agent-Discovery-Protocol-Specification.md) (2026-09-05) VERIFIED - Agent Network Protocol v1.2 released on 2026-09-24 — [https://github.com/agent-network-protocol/AgentNetworkProtocol/releases](https://github.com/agent-network-protocol/AgentNetworkProtocol/releases) (2026-09-24) VERIFIED [JSON](/data/protocols/anp.json) · [Markdown](/protocols/anp/index.md) · [OKF v0.2](/okf/protocols/anp.md) --- # Agent Payments Protocol (AP2) Agent Payments Protocol (AP2) is an agentic-web standard (endpoint) at step 7, Pay, governed by Google; its status is "Security/authorization protocol for agent-performed payments". It answers: "Did the user actually authorize what this agent is about to buy and pay for, and can the merchant prove it later?" Replacing or extending Signed payment authorization / purchase order, implementation status is multi-implementation (Google), last verified 2026-10-23. ## Quick Wire Reference - **Step**: 7 Pay (Settle the bill) - **Version**: v0.2.0 (2026-04-28) - **Status**: Security/authorization protocol for agent-performed payments; core spec now… - **Discovery / Probe Path**: none — No site-level discovery; AP2 mandates are exchanged as message payloads… - **Spec URL**: https://raw.githubusercontent.com/google-agentic-commerce/AP2/main/docs/ap2/specification.md - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: Signed payment authorization / purchase order [Pay](/category/pay/) The Agent Payments Protocol (AP2) is a security and authorization framework for agent-performed payments: it defines how a user's intent to buy something is captured as a cryptographically signed, tamper-evident Mandate that a Merchant, Credential Provider, and Merchant Payment Processor can verify and later present as dispute evidence [[1]](#ref-1). It solves the "was this agent actually authorized to spend this money on this cart" problem for both human-present ("direct") and human-not-present ("autonomous") purchase flows, using two linked mandate types: a Checkout Mandate (what is being bought) and a Payment Mandate (how it is being paid for), each with a corresponding Receipt [[1]](#ref-1)[[4]](#ref-4). ## Overview AP2 explicitly does not define a commerce protocol itself — no catalog APIs, no checkout session lifecycle, no merchant-facing REST surface — it is a security layer meant to sit inside a Commerce Protocol such as the Universal Commerce Protocol (UCP), which it says it is "designed explicitly to be compatible with" [[1]](#ref-1). It also does not expose any discoverable endpoint or well-known file: mandates travel as message payloads inside whatever transport the surrounding commerce or agent-to-agent protocol uses, so there is no generic HTTP probe that proves or disproves AP2 support at an origin. As of this verification, AP2's normative specification text has been donated by Google to the FIDO Alliance for continued stewardship; the original google-agentic-commerce/AP2 GitHub repository states explicitly that further contributions there are limited to code samples and an SDK, not the spec itself [[2]](#ref-2). Google's original announcement (September 2025) cited more than 60 launch partners, though that figure comes from Google's own blog post rather than an independent count [[3]](#ref-3). Reference samples exist in Python, Go, and Android using Google's Agent Development Kit (ADK) and Gemini models, but these are demonstration code, not a conformance suite. What is disputed or unresolved: how governance actually operates now that the spec sits with FIDO rather than in the original GitHub repo — no FIDO-hosted specification page was located during this verification, only the original repository's copy and Google's donation announcement — and how the 60+ "launch partners" map to organizations actually running AP2-verified mandates in production versus organizations that merely endorsed the announcement. ## Discovery and probe No site-level discovery; AP2 mandates are exchanged as message payloads inside a Commerce Protocol (e.g. UCP) or an agent framework (A2A/MCP-compatible flows), not fetched from a well-known path · none ``` none none parse: not applicable — AP2 is a client-side/in-band mandate format, not an origin-exposed endpoint or file on absent: There is no generic HTTP probe for AP2: a Merchant, Credential Provider, or Merchant Payment Processor supports AP2 only if it accepts and validates AP2 Checkout/Payment Mandates inside its own commerce protocol's message flow (e.g. as a UCP payment handler), which cannot be detected by an unauthenticated GET against the origin. ``` Not probed live: needs-credentials. AP2 mandates are exchanged inside an authorised checkout; nothing is published at a fixed path. ## History - 2026-09-05 — seeded from Exa Agent research run - 2026-09-06 — verified against google-agentic-commerce/AP2 (README, CONTRIBUTING.md, docs/ap2/specification.md, docs/ap2/checkout_mandate.md) and Google Cloud blog launch announcement; folded in ap2-checkout-mandate as a component rather than a separate protocol - 2026-10-16 — AP2 v0.2.0 released on 2026-04-28, and AP2 was donated to the FIDO Alliance (Payments TWG and Agentic Authentication TWG) the same day - 2026-10-16 — use-case tags (auto) ## Instances - [FIDO Alliance (Verifiable Intent and AP2 Working Group)](https://fidoalliance.org) · Observed 2026-07-31 · authority Every instance with its source is listed on the [instances page](/instances/). Verified SDKs, reference implementations & validators: - [code/sdk/python/ap2 (Python AP2 SDK)](https://api.github.com/repos/google-agentic-commerce/AP2/contents/code/sdk/python/ap2) · sdk - [AP2 SDK + samples (Python, Go, Android) using Google ADK](https://raw.githubusercontent.com/google-agentic-commerce/AP2/main/README.md) · implementation Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Component: [AP2 Checkout Mandate](/protocols/ap2-checkout-mandate/) - Builds on: [Universal Commerce Protocol](/protocols/ucp/) - Depended on by: [Agent Decision Commitments for Payments](/protocols/agent-decision-commitment/), [AP2 Checkout Mandate](/protocols/ap2-checkout-mandate/), [Universal Commerce Protocol](/protocols/ucp/) - Pairs with: [Universal Commerce Protocol](/protocols/ucp/), [Agentic Commerce Protocol](/protocols/agentic-commerce-protocol/), [Agent2Agent Protocol](/protocols/a2a/), [Model Context Protocol](/protocols/mcp/), [x402](/protocols/x402/), [Visa Trusted Agent Protocol](/protocols/tap/) - [Mandate](/terms/mandate/) - [Human Not Present](/terms/human-not-present/) - [Verifiable Intent](/terms/verifiable-intent/) - [Buyer of Record & Merchant of Record (Agentic Commerce)](/terms/buyer-of-record/) - Scanners & registries: [Agents Welcome — Agent Protocol Atlas](https://agentswelcome.dev/protocols), [The Agent Almanac](https://agentalmanac.org/) ## Comparisons - [3-D Secure & Card Checkout vs AP2, ACP & UCP (classic vs agentic)](/compare/3d-secure-vs-ap2/) - [x402 vs Agent Payments Protocol](/compare/x402-vs-ap2/) - [Agent Payments Protocol vs Agentic Commerce Protocol](/compare/ap2-vs-agentic-commerce-protocol/) - [Agent Payments Protocol vs Universal Commerce Protocol](/compare/ap2-vs-ucp/) - [Agent Payments Protocol vs EMV Agentic Payments – Framework for Specifications](/compare/ap2-vs-emv-agentic-payments/) - [Verifiable Intent vs Agent Payments Protocol](/compare/vi-vs-ap2/) - [KYAPay Token vs Agent Payments Protocol](/compare/kyapay-token-vs-ap2/) - [Agent Commerce Kit (ACK) vs Agent Payments Protocol](/compare/agent-commerce-kit-vs-ap2/) ## References - AP2 defines five roles (Shopping Agent, Credential Provider, Merchant, Merchant Payment Processor, Trusted Surface) and two Mandate types (Checkout Mandate, Payment Mandate) used as cryptographic, signed evidence of what a user authorized, for both human-present and human-not-present flows; it is explicitly designed to be compatible with and complementary to UCP. — [https://raw.githubusercontent.com/google-agentic-commerce/AP2/main/docs/ap2/specification.md](https://raw.githubusercontent.com/google-agentic-commerce/AP2/main/docs/ap2/specification.md) VERIFIED - AP2's CONTRIBUTING.md states the core specification has been donated to the FIDO Alliance, and that contributions to the google-agentic-commerce/AP2 repository going forward are to samples and SDK only. — [https://raw.githubusercontent.com/google-agentic-commerce/AP2/main/CONTRIBUTING.md](https://raw.githubusercontent.com/google-agentic-commerce/AP2/main/CONTRIBUTING.md) VERIFIED - Google's launch announcement (blog.google / cloud.google.com) frames AP2 as an open protocol for agent payments with more than 60 partners at launch, and that the spec was donated to FIDO for continued development. — [https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol](https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol) (2025-09-16) REPORTED - The AP2 checkout_mandate.md defines the Checkout Mandate as cryptographic proof to the Merchant that the Shopping Agent is authorized to purchase a specific Checkout, and a Checkout Receipt for the completed transaction. — [https://raw.githubusercontent.com/google-agentic-commerce/AP2/main/docs/ap2/checkout_mandate.md](https://raw.githubusercontent.com/google-agentic-commerce/AP2/main/docs/ap2/checkout_mandate.md) VERIFIED - AP2 v0.2.0 released on 2026-04-28, and AP2 was donated to the FIDO Alliance (Payments TWG and Agentic Authentication TWG) the same day — [https://github.com/google-agentic-commerce/AP2/releases](https://github.com/google-agentic-commerce/AP2/releases) (2026-04-28) REPORTED - AP2 v0.2.0 released on 2026-04-28, and AP2 was donated to the FIDO Alliance (Payments TWG and Agentic Authentication TWG) the same day — [https://fidoalliance.org/fido-alliance-to-develop-standards-for-trusted-ai-agent-interactions/](https://fidoalliance.org/fido-alliance-to-develop-standards-for-trusted-ai-agent-interactions/) (2026-04-28) VERIFIED [JSON](/data/protocols/ap2.json) · [Markdown](/protocols/ap2/index.md) · [OKF v0.2](/okf/protocols/ap2.md) --- # Agent Protocol (AP) Agent Protocol (AP) is an agentic-web standard (endpoint) at step 5, Act, governed by Originated as an AI Engineer Foundation community project; its status is "Common interface for interacting with AI agents. The protocol…". It answers: "How does a client or dev-tool start a task on an autonomous agent, step it, and fetch results, regardless of which…?" Implementation status is multi-implementation (project README), last verified 2026-10-24. ## Quick Wire Reference - **Step**: 5 Act (Do something for me) - **Version**: unversioned OpenAPI spec (schemas/openapi.yml) - **Status**: "Common interface for interacting with AI agents. The protocol is tech stack… - **Discovery / Probe Path**: None published; a client is expected to know an agent's base URL out of band (no well-known… - **Spec URL**: https://github.com/agi-inc/agent-protocol - **Last Verified**: 2026-10-24 (current) - **Classic Web Analog**: a REST job-queue API for arbitrary autonomous-agent backends [Act](/category/act/) Agent Protocol is a framework-agnostic, OpenAPI v3 REST specification originally proposed by the AI Engineer Foundation (AIEF) community, alongside the early Auto-GPT/e2b ecosystem, to give any autonomous agent a single, predictable interface: create a task (POST /ap/v1/agent/tasks), execute it step by step (POST /ap/v1/agent/tasks/{task_id}/steps), and list or download artifacts, regardless of the framework the agent was built with [[1]](#ref-1). It solves the comparison and integration problem for early agent frameworks — before Agent Protocol, every agent exposed a bespoke interface, making benchmarking and devtool-building across agents difficult; the spec's own stated goal is 'great developer experience' for agent builders wanting to avoid writing boilerplate API code [[1]](#ref-1). ## Overview It does not define agent-to-agent communication (the README lists this as future roadmap, unrealized), does not define authorization on behalf of end users, and does not define discovery — clients are expected to know an agent's base URL out of band [[1]](#ref-1). As of this check (September 2026), the project's governance and web presence show significant drift from its AIEF origins. The GitHub repository formerly hosted under the AI-Engineer-Foundation organization now redirects to agi-inc/agent-protocol and states it is "Maintained by AGI, Inc.," a commercial entity, rather than the original community foundation [[1]](#ref-1). More notably, the repository's own linked documentation domain, agentprotocol.ai, no longer hosts the project's docs at all: as fetched during this verification pass, it serves an unrelated third-party site describing itself as an 'independent, vendor-neutral guide' to MCP, A2A, and Agent Protocol, with no visible connection to AI Engineer Foundation, AGI Inc., or the GitHub repository that links to it as its official documentation [[2]](#ref-2). This is flagged as a dispute rather than treated as settled, since it was not possible in this pass to determine whether the domain lapsed and was independently re-registered, or was deliberately repurposed by a current stakeholder. Implementation history shows genuine multi-party adoption during the 2023–2024 Auto-GPT era — Auto-GPT, Auto-GPT-Forge, and smol developer all merged Agent-Protocol-compliant PRs, with e2b and Auto-GPT credited as 'engaged' co-developers of the spec — but no evidence of continued active development or adoption was found in the past year of repository activity [[1]](#ref-1). What is unresolved: whether Agent Protocol should be considered a live, maintained standard at all today, or a historically important but now largely dormant spec whose primary surviving artifact is the OpenAPI file in a repository under new, commercial ownership. ## Discovery and probe None published; a client is expected to know an agent's base URL out of band (no well-known path or registry defined by the spec itself) ``` POST {origin}/ap/v1/agent/tasks parse: A 200/201 response returning a Task object containing a task_id field confirms an Agent-Protocol-compliant server per the OpenAPI schema. on absent: A 404 or schema mismatch means this origin does not implement Agent Protocol. Given the project's docs domain has since been repurposed to unrelated content and no commit activity was found in the past year, absence should now be treated as the default expectation rather than a surprise. ``` Not probed live: unsafe-post. The probe is POST /ap/v1/agent/tasks, which starts a task. ## History - 2026-09-06 — added from arXiv 2504.16736 survey comparison, verified against github.com/AI-Engineer-Foundation/agent-protocol (redirects to agi-inc/agent-protocol), agentprotocol.ai - 2026-10-16 — use-case tags (auto) - 2026-10-16 — version js-sdk-v1.0.5 (watcher) - 2026-10-16 — No push since 2025-04-08 (over 180 days) - 2026-10-16 — version label restored to 'unversioned OpenAPI spec (schemas/openapi.yml)'; the repository's latest tag (js-sdk-v1.0.5) is a package, SDK or build tag, not the specification version, so the GitHub watch no longer drives version ## Instances - [LangChain LangGraph Platform Agent Server](https://langchain-ai.github.io/langgraph/) · Observed 2026-08-29 · agent Every instance with its source is listed on the [instances page](/instances/). Verified SDKs, reference implementations & validators: - [agent-protocol SDK/client packages](https://github.com/AI-Engineer-Foundation/agent-protocol) · sdk (2026-09-06) Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Pairs with: [Model Context Protocol](/protocols/mcp/), [Agent2Agent Protocol](/protocols/a2a/), [Agent Communication Protocol](/protocols/agent-communication-protocol/) - Not to be confused with: Agent Connect Protocol (AGNTCY), Agent Communication Protocol (IBM), Agent Client Protocol (Zed) ## Comparisons - [Agent Protocol vs Model Context Protocol](/compare/agent-protocol-aief-vs-mcp/) ## References - The GitHub repository formerly at AI-Engineer-Foundation/agent-protocol now redirects to agi-inc/agent-protocol ('Maintained by AGI, Inc.'), MIT licensed, 1.5k stars, 186 forks; its README defines the protocol as an OpenAPI REST spec with POST /ap/v1/agent/tasks and POST /ap/v1/agent/tasks/{task_id}/steps as its two essential routes, and lists Auto-GPT, Auto-GPT-Forge, and smol developer as adopting projects. — [https://github.com/agi-inc/agent-protocol](https://github.com/agi-inc/agent-protocol) (2026-09-06) VERIFIED - The repository's own 'Docs' link, https://agentprotocol.ai/, currently serves an unrelated third-party site ('AgentProtocol.ai') describing itself as 'an independent, vendor-neutral guide' comparing MCP, A2A, and Agent Protocol — it shows no visible affiliation with AI Engineer Foundation, AGI Inc., or the agi-inc/agent-protocol repository, and does not host the project's own documentation. — [https://agentprotocol.ai/](https://agentprotocol.ai/) (2026-09-06) VERIFIED - js-sdk-v1.0.5 released 2024-04-02 — [https://github.com/agi-inc/agent-protocol/releases/tag/js-sdk-v1.0.5](https://github.com/agi-inc/agent-protocol/releases/tag/js-sdk-v1.0.5) (2024-04-02) VERIFIED - No push since 2025-04-08 (over 180 days) — [https://github.com/agi-inc/agent-protocol/releases/tag/js-sdk-v1.0.5](https://github.com/agi-inc/agent-protocol/releases/tag/js-sdk-v1.0.5) (2024-04-02) REPORTED Disputed: The repository's own README and GitHub 'About' field link https://agentprotocol.ai/ as the project's documentation home, but as fetched during this verification pass the domain serves unrelated third-party content — a vendor-neutral protocol-comparison guide covering MCP, A2A, and Agent Protocol — with no visible affiliation to AI Engineer Foundation, AGI Inc., or the GitHub repository that links it. The canonical specification currently survives only as the openapi.yml file inside the GitHub repository itself. [JSON](/data/protocols/agent-protocol-aief.json) · [Markdown](/protocols/agent-protocol-aief/index.md) · [OKF v0.2](/okf/protocols/agent-protocol-aief.md) --- # Agent Readability Spec (ARS) Agent Readability Spec (ARS) is an agentic-web standard (document format) at step 4, Read, governed by Vercel; its status is "A specification and scoring checklist, not a protocol". It answers: "How readable is this site's content for AI agents, and what specifically should be fixed?" Implementation status is shipping, last verified 2026-10-23. ## Quick Wire Reference - **Step**: 4 Read (Give me the content) - **Version**: current (last updated 2026-03-23 per a secondary source; no version number or… - **Status**: A specification and scoring checklist, not a protocol; framed as best… - **Discovery / Probe Path**: none - **Spec URL**: https://vercel.com/kb/guide/agent-readability-spec - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: a Lighthouse/PageSpeed-style audit checklist, but scored against agent readability… [Read](/category/read/) Vercel's Agent Readability Spec is a checklist and 0-100 scoring system for how well a website's content can be discovered, fetched, and understood by AI agents [[1]](#ref-1). It groups roughly twenty independently verifiable checks into three areas: discovery (an llms.txt file, a permissive robots.txt, XML and markdown sitemaps), structure (canonical links, meta tags, Schema.org/JSON-LD, heading hierarchy, text-to-HTML ratio), and context (an AGENTS.md skill file, markdown mirrors of HTML pages, Accept: text/markdown content negotiation, fenced and language-tagged code blocks, OpenAPI/Swagger schema links) [[1]](#ref-1). ## Overview It solves the problem of turning "be agent-friendly" into a concrete, curl-verifiable punch list: each requirement in the spec ships with an example and a shell command to check it, and site owners get a single percentage score (passed / total × 100) they can track over time [[1]](#ref-1). Notably, it documents — by name, as Vercel's own recommended practice — serving a markdown alternate for every HTML page and returning it when a client sends Accept: text/markdown, with a Link header pointing back to the canonical HTML URL [[1]](#ref-1). This is the same content-negotiation pattern also described in llms.txt v2's discovery mechanism (see the llms-txt record) and is the clearest documented instance of the general "markdown twin" practice found during this verification pass. It does not solve trust or accuracy: nothing in the spec checks whether the content is correct, and a perfect score says only that a page is structurally easy to fetch and parse, not that an agent's answer using it will be right. It is also not a protocol or a machine-readable manifest — there is no fixed path an agent fetches to learn a site's score; the checklist is meant to be run by (or on behalf of) the site owner, and scoring is reproduced by third-party tools rather than looked up from a canonical registry. Current state, as of this verification (September 2026): the page itself carries no publication date or version number. An independent commentator dated it to "last updated March 23" (2026) and noted its author is Timothy Jordan [[2]](#ref-2). At least one third-party checker, agent-ready.dev, implements scoring explicitly described as checking a site "against the Vercel Agent Readability Spec and llmstxt.org standard," which is the clearest evidence of independent implementation found [[3]](#ref-3); Vercel's own knowledge-base article is the only primary specification text. What is disputed or unknown: the spec was published unilaterally by a hosting vendor, with no external review process, and overlaps substantially with an earlier, separately maintained 'Agent-Friendly Documentation Spec' — a secondary source flagged this as worth scrutinizing given Vercel's commercial interest in the hosting practices the spec implicitly favors (server-rendered pages, content negotiation infrastructure) [[2]](#ref-2). No independent adoption count or measurement of how many sites meet a given score threshold was found. ## Discovery and probe none — not a discoverable manifest; it is a checklist a site owner applies to their own pages, verified externally by tools like agent-ready.dev or is-agentic.com · none ``` GET {origin}/ (plus /llms.txt, /robots.txt, /sitemap.xml, /sitemap.md, /AGENTS.md as sub-checks; see the spec's own per-requirement curl commands) parse: No single field proves conformance; the spec defines ~20 discrete site- and page-level checks (llms.txt served, robots.txt allows AI bots, AGENTS.md present, canonical link, JSON-LD, markdown mirrors, Accept: text/markdown negotiation, etc.) each independently verifiable by curl, and a numeric score = round(passed/total * 100) on absent: A site failing most checks is not in violation of anything; the spec is a voluntary readiness checklist, not an enforced requirement ``` Not probed live: no-fixed-path. A checklist, not a manifest; the llms-txt, agents-md, robots and sitemap checks cover its site-level items. ## History - 2026-09-06 — new record added during read-step verification; verified against vercel.com/kb/guide/agent-readability-spec and independent commentary - 2026-10-16 — use-case tags (auto) ## Instances Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Pairs with: [llms.txt](/protocols/llms-txt/), [AGENTS.md](/protocols/agents-md/), [AI Crawler User-Agent Tokens in robots.txt](/protocols/ai-crawler-tokens-robots/), [api-catalog: A Well-Known URI and Link Relation to Help Discovery of APIs](/protocols/api-catalog-rfc9727/), [NLWeb](/protocols/nlweb/), [Markdown for Agents](/protocols/cloudflare-markdown-for-agents/) - Scanners & registries: [Agent Ready](https://agent-ready.dev/) - Not to be confused with: Agent-Friendly Documentation Spec (a separate, earlier spec by a different maintainer covering similar ground — see dispute) ## Comparisons - [HTML DOM & RSS vs Accept: text/markdown & OKF (classic vs agentic)](/compare/html-dom-vs-markdown-for-agents/) - [Agent Readability Spec vs llms.txt](/compare/vercel-agent-readability-vs-llms-txt/) - [Open Knowledge Format vs Agent Readability Spec](/compare/okf-vs-vercel-agent-readability/) - [Markdown for Agents vs Agent Readability Spec](/compare/cloudflare-markdown-for-agents-vs-vercel-agent-readability/) - [Agent Readability Spec vs AGENTS.md](/compare/vercel-agent-readability-vs-agents-md/) ## References - Full checklist text: site-level files (llms.txt, robots.txt, sitemap.xml/md, AGENTS.md), page-level HTML requirements (canonical link, meta tags, JSON-LD, heading structure, signal-to-noise ratio), server configuration (markdown mirrors, `Accept: text/markdown` content negotiation, `Link` header canonical), content quality (fenced code blocks, OpenAPI schema links), and the scoring formula — [https://vercel.com/kb/guide/agent-readability-spec](https://vercel.com/kb/guide/agent-readability-spec) (2026-03) VERIFIED - Independent commentary identifies the author as Timothy Jordan, notes the page carries no publication date and was 'last updated March 23' (2026), and frames it as a competing effort alongside a pre-existing 'Agent-Friendly Documentation Spec' maintained separately — [https://dacharycarey.com/2026/03/28/how-to-evaluate-platform-written-spec/](https://dacharycarey.com/2026/03/28/how-to-evaluate-platform-written-spec/) (2026-03-28) REPORTED - A third-party checker, agent-ready.dev, scores sites specifically 'against the Vercel Agent Readability Spec and llmstxt.org standard', indicating at least one independent implementation of the scoring logic — [https://agent-ready.dev/](https://agent-ready.dev/) (2026) REPORTED Disputed: Vercel published this spec without an external standards process or a clear version/date, prompting at least one independent commentator to note it overlaps with, and was not coordinated with, a pre-existing 'Agent-Friendly Documentation Spec' maintained by someone else. [JSON](/data/protocols/vercel-agent-readability.json) · [Markdown](/protocols/vercel-agent-readability/index.md) · [OKF v0.2](/okf/protocols/vercel-agent-readability.md) --- # Agent Registration and Discovery Protocol (ARDP · /.well-known/ardp/meta) Agent Registration and Discovery Protocol (ARDP) is an agentic-web standard (endpoint — /.well-known/ardp/meta) at step 1, Discover, governed by IETF individual Internet-Draft; its status is "Expired Internet-Draft". It answers: "How can an autonomous agent register a stable identity, advertise its capabilities and current endpoints with a TTL, and…?" Implementation status is none found, last verified 2026-10-23. ## Quick Wire Reference - **Step**: 1 Discover (What is here, and where?) - **Version**: draft-pioli-agent-discovery-01 (latest revision, expired) (2026-02-24) - **Status**: Expired Internet-Draft (expired 2026-08-28) · none found - **Discovery / Probe Path**: /.well-known/ardp/meta — RESOLVE/QUERY operations over an HTTPS binding, with a minimal… - **Spec URL**: https://datatracker.ietf.org/doc/html/draft-pioli-agent-discovery-01 - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: a service registry with dynamic health/TTL semantics (like Consul or a SIP… [Discover](/category/discover/) The Agent Registration and Discovery Protocol (ARDP) specifies a lightweight, transport-agnostic protocol for registering, discovering, and reaching autonomous agents in distributed and federated environments, providing stable agent identities, dynamic endpoint resolution, capability advertisement across MCP/A2A/HTTP/gRPC, minimal presence signaling, and a security-first discovery control plane [[1]](#ref-1). It is a single-author IETF individual Internet-Draft; the latest text is revision -01, dated 24 February 2026 [[1]](#ref-1). ## Overview It solves agent liveness and endpoint churn using a TTL-based model: an agent registers with a server, the server assigns and enforces TTL bounds (advertised at /.well-known/ardp/meta, e.g. ttl_min/ttl_max/auth_profiles/supported_protocols), and clients are expected to refresh at roughly half the TTL with jitter [[1]](#ref-1). Discovery is split into a RESOLVE operation (map a registered agent identifier to active endpoints and capabilities, access-controlled) and a QUERY operation (discover by capability or namespace, also authorized) [[1]](#ref-1). Privacy is a first-class concern: QUERY responses are minimized by default to just an identifier and status, with full detail gated behind an explicit detail=full request parameter, and the server must mark a response "redacted": true when fields are withheld [[1]](#ref-1). ARDP does not define its own transport-security handshake beyond referencing a jws-proof-of-control auth profile in its example metadata, and does not attempt to be a full registry federation protocol -- there is no evidence in the text read of a cross-registry query mechanism comparable to ARD's federation parameter [[1]](#ref-1). Current state: the IETF Datatracker's own status page (a separate fetch from the draft text itself) shows this document's IESG state as "Expired -- Expired & archived", the sole author's listed contact "may no longer be valid", and no revision beyond -01 [[1]](#ref-1)[[2]](#ref-2). Phase is recorded as withdrawn on the strength of that authoritative status confirmation, not "unknown": the document is formally lapsed and archived, not merely undocumented. No implementation, deployment, or adopter evidence was located; implementation is recorded as "none found" rather than unknown, since a specific negative search (checking for a follow-up draft and any linked reference implementation) turned up nothing, as distinct from simply not having looked. What is disputed or unknown: whether this specification is abandoned (an expired, unrenewed single-author draft is a weak signal either way, since many individual IETF drafts lapse and are later resubmitted) or quietly superseded by the author moving to a different venue; and, separately, the confusable-name risk with the unrelated, much more actively developed ARD (Agentic Resource Discovery) specification, which shares three of four words in its expansion and a similar acronym but has no connection in governance, mechanism, or authorship. ## Discovery and probe RESOLVE/QUERY operations over an HTTPS binding, with a minimal metadata resource advertising TTL bounds and supported auth profiles · /.well-known/ardp/meta ``` GET https://{origin}/.well-known/ardp/meta parse: 200 response is JSON with ttl_min, ttl_max, auth_profiles and supported_protocols fields on absent: Domain does not run an ARDP-compliant registration/discovery endpoint ``` Live check run by [the MCP probe](/mcp/server-card): GET /.well-known/ardp/meta. ARDP meta declares TTL bounds and auth profiles. ``` { "path": "/.well-known/ardp/meta", "expect": { "json_keys": [ "ttl_min", "auth_profiles" ] }, "note": "ARDP meta declares TTL bounds and auth profiles." } ``` ## History - 2026-09-05 — seeded from Exa Agent research run - 2026-09-06 — verified against draft-pioli-agent-discovery-00 spec text via datatracker.ietf.org; noted draft expired 2026-08-05 with no successor found - 2026-09-06 — fix round 1: fetched IETF Datatracker status page as second, independent evidence entry confirming Expired/archived state; corrected version/spec_url from -00 to the actual latest revision -01; set phase from unknown to withdrawn on the strength of the datatracker's own Expired status (resolves the phase-unknown gate without needing an explanatory sentence) - 2026-10-16 — Expired Internet-Draft (expired 2026-08-28) - 2026-10-16 — use-case tags (auto) ## Instances Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Pairs with: [Agent2Agent Protocol](/protocols/a2a/), [Model Context Protocol](/protocols/mcp/), [Agent Name Service v2 (ANS)](/protocols/ans/), [DNS for AI Discovery](/protocols/dns-aid/), [Agentic Resource Discovery](/protocols/ard/), [A Framework for Agent Discovery in DAWN](/protocols/dawn-agent-discovery-framework/) - Not to be confused with: ARD (Agentic Resource Discovery, unrelated Google/Microsoft/HF spec with a similar acronym and near-identical name) ## References - draft-pioli-agent-discovery-00 (February 2026) specifies ARDP, a lightweight protocol providing stable agent identities (AIDs), dynamic endpoint resolution via RESOLVE/QUERY operations, capability advertisement across MCP/A2A/HTTP/gRPC, TTL-bounded presence records, and a minimal /.well-known/ardp/meta resource; this Internet-Draft expired 5 August 2026 with no successor revision found. — [https://datatracker.ietf.org/doc/html/draft-pioli-agent-discovery-00](https://datatracker.ietf.org/doc/html/draft-pioli-agent-discovery-00) (2026-02) VERIFIED - IETF Datatracker's status page for draft-pioli-agent-discovery (fetched 2026-09-06, distinct page from the htmlized draft text) shows the document's IESG state as "Expired", type "Expired Internet-Draft (individual) -- Expired & archived", with a single author (Roberto Pioli) whose listed e-mail "may no longer be valid", and only one revision beyond -00 (the -01 text, latest revision dated 2026-02-24) -- independently confirming this is a lapsed, unrenewed single-author submission rather than an active track. — [https://datatracker.ietf.org/doc/draft-pioli-agent-discovery/](https://datatracker.ietf.org/doc/draft-pioli-agent-discovery/) (2026-09-06) VERIFIED - Expired Internet-Draft (expired 2026-08-28) — [https://datatracker.ietf.org/doc/draft-pioli-agent-discovery/](https://datatracker.ietf.org/doc/draft-pioli-agent-discovery/) (2026-02-24) VERIFIED Disputed: This draft's own name and acronym (ARDP, Agent Registration and Discovery Protocol) is one character and one word away from the entirely unrelated, much more prominent ARD (Agentic Resource Discovery, ard.md) from Google/Microsoft/Hugging Face. They are independent specifications with no shared authorship or mechanism found in the texts read. [JSON](/data/protocols/ardp.json) · [Markdown](/protocols/ardp/index.md) · [OKF v0.2](/okf/protocols/ardp.md) --- # Agent Skills (/.well-known/agent-skills/index.json) Agent Skills is an agentic-web standard (document format — /.well-known/agent-skills/index.json) at step 5, Act, originated by Anthropic and donated on 22 October 2026 to the…; its status is "Active open format under the Linux Foundation Agentic AI…". It answers: "How can reusable, on-demand procedural instructions and bundled resources be packaged so any compatible agent can load…?" Replacing or extending Package README / plugin manifest, implementation status is multi-implementation (observed on 111/1226 probed origins), last verified 2026-10-24. ## Quick Wire Reference - **Step**: 5 Act (Do something for me) - **Version**: unversioned living spec (agentskills.io/specification) - **Status**: Active open format under the Linux Foundation Agentic AI Foundation (AAIF)… - **Discovery / Probe Path**: /.well-known/agent-skills/index.json - **Spec URL**: https://agentskills.io/specification - **Last Verified**: 2026-10-24 (current) - **Classic Web Analog**: Package README / plugin manifest [Act](/category/act/) Agent Skills is an open packaging format for reusable procedural knowledge: a "skill" is a directory containing a required SKILL.md file (YAML frontmatter with a name and description, plus optional license, compatibility, metadata, and experimental allowed-tools fields) followed by Markdown instructions, and optionally scripts/, references/, and assets/ subdirectories for executable code, longer documentation, and templates respectively [[1]](#ref-1). It solves the problem of giving an agent domain-specific, team- or user-specific know-how — a legal review checklist, a data pipeline procedure — as a portable, version-controllable unit that works across any compatible agent product, rather than being locked into one vendor's prompt-engineering conventions [[2]](#ref-2). ## Overview The format's core mechanism is progressive disclosure in three stages: at startup an agent loads only the name and description (roughly 100 tokens) for every available skill; when a task matches a description, the agent loads the full SKILL.md body (recommended under 5,000 tokens); only when the instructions call for it does the agent load bundled scripts, references, or assets [[1]](#ref-1). This keeps large skill libraries cheap to keep "on hand" without bloating context. For local environments, host agents scan configured skill directories (such as .claude/skills/ or ~/.codex/skills/); for web origins, the companion Agent Skills Discovery RFC (v0.2.0) defines /.well-known/agent-skills/index.json (https://schemas.agentskills.io/discovery/0.2.0/schema.json), which lists published skills along with their SKILL.md or archive URLs and SHA-256 digests [[1]](#ref-1)[[2]](#ref-2). Agent Skills still does not define a runtime RPC protocol for invoking a skill over a network — it remains a packaging, progressive-disclosure, and static-discovery convention, distinct from the separate "Skills over MCP" effort exploring dynamic skill discovery through MCP itself (cross-reference — see mcp record). Originally developed by Anthropic in 2025 and maintained in the agentskills/agentskills GitHub organization [[2]](#ref-2), Agent Skills was formally donated by Anthropic to the Linux Foundation's Agentic AI Foundation (AAIF) on 22 October 2026 [[3]](#ref-3), placing its governance under the same neutral foundation umbrella as MCP and A2A. A client showcase names roughly 35 adopting products spanning coding agents (Claude Code, Cursor, GitHub Copilot, VS Code, JetBrains Junie, Amp, OpenHands, Goose, Roo Code, OpenCode, Factory), general assistants (Claude.ai, Gemini CLI, ChatGPT & Codex), and enterprise platforms (Snowflake Cortex Code, Databricks Genie Code, Spring AI) [[2]](#ref-2). This is direct, first-party observation of a broad adopter list rather than a systematic count, so adoption here is recorded as observed, not measured. What remains open: no version number is attached to the specification itself (it is presented as a living document), and the relationship/overlap between this format and the MCP "Skills over MCP" working group's discovery mechanism has not been reconciled by either project as of this check. ## Discovery and probe Local skill directory (/SKILL.md with YAML frontmatter name and description) plus optional origin well-known discovery index (/.well-known/agent-skills/index.json per Agent Skills Discovery RFC v0.2.0) · /.well-known/agent-skills/index.json ``` GET /.well-known/agent-skills/index.json parse: JSON object with $schema (https://schemas.agentskills.io/discovery/0.2.0/schema.json) and a skills[] array of entries with name, type, description, url, and digest (sha256:...); local packages validate via YAML frontmatter in {skill-name}/SKILL.md on absent: 404 or non-JSON at /.well-known/agent-skills/index.json means the origin does not publish a web skill discovery index; local Agent Skills packages may still be distributed via repositories or local skill directories. ``` Live check run by [the MCP probe](/mcp/server-card): GET /.well-known/agent-skills/index.json. Agent Skills Discovery RFC v0.2.0 publishes a JSON skill index with a top-level skills[] array at /.well-known/agent-skills/index.json. ``` { "path": "/.well-known/agent-skills/index.json", "expect": { "content_type": "json", "json_keys": [ "skills" ] }, "note": "Agent Skills Discovery RFC v0.2.0 publishes a JSON skill index with a top-level skills[] array at /.well-known/agent-skills/index.json." } ``` ## History - 2026-09-05 — seeded from Exa Agent research run - 2026-09-06 — verified against agentskills.io and agentskills.io/specification - 2026-10-16 — use-case tags (auto) - 2026-10-22 — Anthropic donated Agent Skills to the Linux Foundation Agentic AI Foundation (AAIF); track updated to linux-foundation ## Instances - [Zuplo API Gateway (zuplo.com)](https://zuplo.com/) · Observed 2026-10-25 · origin - [Zoom Developers (developers.zoom.us)](https://developers.zoom.us/) · Observed 2026-10-25 · origin - [Zapier (zapier.com)](https://zapier.com/) · Observed 2026-10-25 · origin - [Wistia (wistia.com)](https://wistia.com/) · Observed 2026-10-25 · origin - [Vast.ai (vast.ai)](https://vast.ai/) · Observed 2026-10-25 · origin - [Taskade (taskade.com)](https://taskade.com/) · Observed 2026-10-25 · origin - [SurrealDB (surrealdb.com)](https://surrealdb.com/) · Observed 2026-10-25 · origin - [Supermemory (supermemory.ai)](https://supermemory.ai/) · Observed 2026-10-25 · origin - [Supabase (supabase.com)](https://supabase.com/) · Observed 2026-10-25 · origin - [Sentry (sentry.io)](https://sentry.io/) · Observed 2026-10-25 · origin - [Scalar API Platform (scalar.com)](https://scalar.com/) · Observed 2026-10-25 · origin - [SavvyCal (savvycal.com)](https://savvycal.com/) · Observed 2026-10-25 · origin - [Sanity Content Operating System (sanity.io)](https://sanity.io/) · Observed 2026-10-25 · origin - [RunPod GPU Cloud (runpod.io)](https://runpod.io/) · Observed 2026-10-25 · origin - [Replicate (replicate.com)](https://replicate.com/) · Observed 2026-10-25 · origin - [Reducto Document AI (reducto.ai)](https://reducto.ai/) · Observed 2026-10-25 · origin - [React Email by Resend (react.email)](https://react.email/) · Observed 2026-10-25 · origin - [Pydantic & Logfire (pydantic.dev)](https://pydantic.dev/) · Observed 2026-10-25 · origin - [Publica.la (publica.la)](https://publica.la/) · Observed 2026-10-25 · origin - [Proof API (api.proof.com)](https://api.proof.com/.well-known/ard.json) · Observed 2026-10-25 · origin - [Prisma ORM & Postgres (prisma.io)](https://prisma.io/) · Observed 2026-10-25 · origin - [Podscan Podcast Intelligence API (podscan.fm)](https://podscan.fm/) · Observed 2026-10-25 · origin - [Perplexity API Docs (docs.perplexity.ai)](https://docs.perplexity.ai/) · Observed 2026-10-25 · origin - [Papermark Open-Source DocSend (papermark.io)](https://papermark.io/) · Observed 2026-10-25 · origin - [OpenStatus (openstatus.dev)](https://openstatus.dev/) · Observed 2026-10-25 · origin - [Novita AI (novita.ai)](https://novita.ai/) · Observed 2026-10-25 · origin - [MotherDuck Serverless DuckDB (motherduck.com)](https://motherduck.com/) · Observed 2026-10-25 · origin - [Morph Fast Apply LLM (morphllm.com)](https://morphllm.com/) · Observed 2026-10-25 · origin - [Model Context Protocol Docs (modelcontextprotocol.io)](https://modelcontextprotocol.io/) · Observed 2026-10-25 · origin - [LibreChat Open-Source AI Workspace (librechat.ai)](https://librechat.ai/) · Observed 2026-10-25 · origin - [Lago (getlago.com)](https://getlago.com/) · Observed 2026-10-25 · origin - [Kent C. Dodds (kentcdodds.com)](https://kentcdodds.com/) · Observed 2026-10-25 · origin - [Intercom Developers (developers.intercom.com)](https://developers.intercom.com/) · Observed 2026-10-25 · origin - [Hostinger (hostinger.com)](https://hostinger.com/) · Observed 2026-10-25 · origin - [Fly.io (fly.io)](https://fly.io/) · Observed 2026-10-25 · origin - [Eodly (eodly.io)](https://eodly.io/) · Observed 2026-10-25 · origin - [Descope Identity & Agent Auth (descope.com)](https://descope.com/) · Observed 2026-10-25 · origin - [DC Hub (dchub.cloud)](https://dchub.cloud/) · Observed 2026-10-25 · origin - [Customer.io (customer.io)](https://customer.io/) · Observed 2026-10-25 · origin - [crewai.com](https://crewai.com/) · Observed 2026-10-25 · origin - [Coinbase (coinbase.com)](https://coinbase.com/) · Observed 2026-10-25 · origin - [Circle (circle.so)](https://circle.so/) · Observed 2026-10-25 · origin - [Checkly Synthetic Monitoring (checklyhq.com)](https://checklyhq.com/) · Observed 2026-10-25 · origin - [Cerebrium Serverless AI (cerebrium.ai)](https://cerebrium.ai/) · Observed 2026-10-25 · origin - [Cal.com Scheduling Infrastructure (cal.com)](https://cal.com/) · Observed 2026-10-25 · origin - [Bird (bird.com)](https://bird.com/) · Observed 2026-10-25 · origin - [Baseten Docs (docs.baseten.co)](https://docs.baseten.co/) · Observed 2026-10-25 · origin - [Augment Code Docs (docs.augmentcode.com)](https://docs.augmentcode.com/) · Observed 2026-10-25 · origin - [Attio Docs (docs.attio.com)](https://docs.attio.com/) · Observed 2026-10-25 · origin - [Appwrite Backend Platform (appwrite.io)](https://appwrite.io/) · Observed 2026-10-25 · origin - [Apideck Unified API (apideck.com)](https://apideck.com/) · Observed 2026-10-25 · origin - [Amplitude (amplitude.com)](https://amplitude.com/) · Observed 2026-10-25 · origin - [Agent Skills Specification (agentskills.io)](https://agentskills.io/) · Observed 2026-10-25 · origin - [Agent Client Protocol (agentclientprotocol.com)](https://agentclientprotocol.com/) · Observed 2026-10-25 · origin - [AG-UI Documentation Origin (docs.ag-ui.com)](https://docs.ag-ui.com/) · Observed 2026-10-25 · origin - [Ad Context Protocol Docs (docs.adcontextprotocol.org)](https://docs.adcontextprotocol.org/) · Observed 2026-10-25 · origin - [x402 Foundation Spec Origin (x402.org)](https://x402.org/) · Observed 2026-10-23 · origin - [Vercel (vercel.com)](https://vercel.com/) · Observed 2026-10-23 · origin - [Tempo (tempo.xyz)](https://tempo.xyz/) · Observed 2026-10-23 · origin - [Resend (resend.com)](https://resend.com/) · Observed 2026-10-23 · origin - [QuickNode (quicknode.com)](https://quicknode.com/) · Observed 2026-10-23 · origin - [Proof (proof.com)](https://proof.com/) · Observed 2026-10-23 · origin - [Neon Serverless Postgres (neon.com)](https://neon.com/) · Observed 2026-10-23 · origin - [mastra.ai](https://mastra.ai/) · Observed 2026-10-23 · origin - [Loops (loops.so)](https://loops.so/) · Observed 2026-10-23 · origin - [Cloudflare (cloudflare.com)](https://cloudflare.com/) · Observed 2026-10-23 · origin - [ClickHouse (clickhouse.com)](https://clickhouse.com/) · Observed 2026-10-23 · origin - [blog.cloudflare.com](https://blog.cloudflare.com/) · Observed 2026-10-23 · origin - [auth.md Specification Origin (auth-md.com)](https://auth-md.com/) · Observed 2026-10-23 · origin - [Apify (apify.com)](https://apify.com/) · Observed 2026-10-23 · origin - [agenticweb.wiki Reference Agent and MCP Server](https://agenticweb.wiki) · Observed 2026-10-23 · agent - [agent-ready.dev Conformance Scanner Agent](https://agent-ready.dev) · Observed 2026-10-23 · agent - [Goose (Block)](https://github.com/block/goose) · Observed 2026-08-29 · harness - [Claude Code (Anthropic)](https://platform.claude.com/docs/en/agents-and-tools/claude-code/overview) · Observed 2026-08-29 · harness Every instance with its source is listed on the [instances page](/instances/). Verified SDKs, reference implementations & validators: - [Claude Code](https://agentskills.io) · implementation (2026) - [skills-ref](https://agentskills.io/specification) · validator (2026) Our probe: seen on 111 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Pairs with: [Model Context Protocol](/protocols/mcp/), [AGENTS.md](/protocols/agents-md/), [llms.txt](/protocols/llms-txt/), [Open Agentic Schema Framework](/protocols/oasf/), [Open Knowledge Format](/protocols/okf/), [Agent Context Interchange Protocol](/protocols/acip/) - [Agent skill](/terms/agent-skill/) - [SKILL.md](/terms/skill-md/) - Not to be confused with: MCP "Skills over MCP" working group (a related but distinct proposal for discovering skills through MCP itself) ## Comparisons - [OpenAPI & REST APIs vs Model Context Protocol (MCP) (classic vs agentic)](/compare/openapi-vs-mcp/) - [DOM Browser Automation vs WebMCP & MCP (classic vs agentic)](/compare/browser-automation-vs-webmcp/) - [Agent Skills vs Model Context Protocol](/compare/anthropic-agent-skills-format-vs-mcp/) - [WebMCP vs Agent Skills](/compare/webmcp-vs-anthropic-agent-skills-format/) - [Agent Skills vs AGENTS.md](/compare/anthropic-agent-skills-format-vs-agents-md/) - [Agent Skills vs llms.txt](/compare/anthropic-agent-skills-format-vs-llms-txt/) ## References - Agent Skills is a lightweight open format: a skill is a directory with a required SKILL.md (YAML frontmatter with required name and description fields, optional license/compatibility/metadata/allowed-tools) plus Markdown instructions and optional scripts/, references/, assets/ directories; agents load skills via three-stage progressive disclosure (discovery of name+description, activation loads the full body, execution loads bundled resources on demand). Validation tooling ships as skills-ref. — [https://agentskills.io/specification](https://agentskills.io/specification) (2026) VERIFIED - "The Agent Skills format was originally developed by Anthropic, released as an open standard, and has been adopted by a growing number of agent products. The standard is open to contributions from the broader ecosystem" — development happens on github.com/agentskills/agentskills and a public Discord. A client showcase lists dozens of named adopting products including Claude Code, Claude.ai, Cursor, GitHub Copilot, VS Code, Gemini CLI, ChatGPT & Codex, JetBrains Junie, Amp, OpenHands, Goose, Letta, Factory, Roo Code, OpenCode, Snowflake Cortex Code, Databricks Genie Code, and Spring AI, among ~35 named logos. — [https://agentskills.io](https://agentskills.io) (2026) VERIFIED - On 22 October 2026, Anthropic donated the Agent Skills format (SKILL.md specification and github.com/agentskills/agentskills) to the Linux Foundation's Agentic AI Foundation (AAIF) as one of four newly contributed projects. — [https://aaif.io/news/agentic-ai-foundation-announces-four-new-projects](https://aaif.io/news/agentic-ai-foundation-announces-four-new-projects) (2026-10-22) VERIFIED [JSON](/data/protocols/anthropic-agent-skills-format.json) · [Markdown](/protocols/anthropic-agent-skills-format/index.md) · [OKF v0.2](/okf/protocols/anthropic-agent-skills-format.md) --- # Agent Transfer Protocol (AGTP) Agent Transfer Protocol (AGTP) is an agentic-web standard (endpoint) at step 6, Coordinate, governed by IETF individual/independent submission; its status is "Internet-Draft, independent submission". It answers: "How can AI agent traffic be identified, authenticated, and governed as a distinct application-layer protocol rather than…?" Implementation status is none found, last verified 2026-10-23. ## Quick Wire Reference - **Step**: 6 Coordinate (Talk to another agent) - **Version**: draft-hood-independent-agtp-09 (2026-06-28) - **Status**: Internet-Draft (work in progress), independent submission · none found - **Discovery / Probe Path**: none - **Spec URL**: https://www.ietf.org/archive/id/draft-hood-independent-agtp-09.html - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: none [Coordinate](/category/coordinate/) The Agent Transfer Protocol (AGTP) is an Internet-Draft proposing a dedicated, non-HTTP, application-layer transport protocol purpose-built for AI agent traffic, submitted independently to the IETF (not sponsored by a working group) by Chris Hood of Nomotic, Inc [[1]](#ref-1). It aims to solve a problem the author frames as: HTTP-based "Agent Group Messaging Protocols" (the draft's own term, naming MCP, ACP, A2A, and ANP as examples) presuppose HTTP as transport and so lack semantic vocabulary, observability primitives, and agent-identity mechanisms at the transport layer [[2]](#ref-2). AGTP proposes its own intent-oriented methods (QUERY, SUMMARIZE, BOOK, SCHEDULE, LEARN, DELEGATE, COLLABORATE, CONFIRM, ESCALATE, NOTIFY, DESCRIBE, SUSPEND), protocol-level agent identity/authority headers, a purpose-built status-code vocabulary, and prefers QUIC with mandatory TCP/TLS fallback [[2]](#ref-2). ## Overview AGTP does not define a discovery mechanism comparable to a well-known URI, and — because it proposes an entirely new wire protocol rather than a convention layered on existing HTTP infrastructure — it has no probe that can be executed with a simple curl against an arbitrary origin; there is no evidence of any implementation, reference or otherwise, as of this verification pass. As of 2026-09-05 the current revision on the IETF datatracker is -09, dated 2026-06-28, five revisions past the -04 draft this record was originally seeded from (2026-04-17); the abstract that draft-09 preserves has iterated substantially, layering in normative integration hooks for a "Merchant Identity and Agentic Commerce Binding specification," new merchant-related headers, and new authority-scope domains, evidence that the draft is under active, fast-moving individual authorship [[1]](#ref-1)[[2]](#ref-2). It remains an independent submission: it has not been adopted by any IETF working group, has no known implementations, and its status track here is recorded as IETF only in the loose sense of venue — it is not on a working-group standards track. What is unresolved: whether any organization beyond the sole named author (Nomotic, Inc.) is contributing to or planning to implement AGTP; no evidence of external implementers or adopters was found. ## Discovery and probe none · none ``` none none — AGTP is a non-HTTP application-layer protocol (QUIC preferred, TCP/TLS fallback) with its own method vocabulary (QUERY, SUMMARIZE, BOOK, SCHEDULE, LEARN, DELEGATE, COLLABORATE, CONFIRM, ESCALATE, NOTIFY, DESCRIBE, SUSPEND); it defines no well-known HTTP path or endpoint that a curl-style probe could hit parse: not applicable: there is no HTTP response body or header to parse because AGTP does not run over HTTP on absent: not applicable — no implementation of AGTP has been located anywhere, so there is nothing to probe for absence against; see summary_md ``` Not probed live: not-http. AGTP is its own application-layer protocol over QUIC or TCP. ## History - 2026-09-05 — seeded from Exa Agent research run - 2026-09-06 — verified against IETF datatracker and draft-hood-independent-agtp-09 (updated spec_url from -04 to current -09, dated 2026-06-28); no implementations found - 2026-10-16 — use-case tags (auto) ## Instances - [Elemen (AGTP Browser)](https://chrishood.com/introducing-elemen-the-worlds-first-browser-for-the-agent-web/) · Observed 2026-06-05 · harness - [Drupal AGTP Module](https://www.drupal.org/project/agtp) · Observed 2026-06-05 · origin Every instance with its source is listed on the [instances page](/instances/). Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Pairs with: [Agent2Agent Protocol](/protocols/a2a/), [Model Context Protocol](/protocols/mcp/), [Agent Network Protocol](/protocols/anp/), [Agent Communication Protocol](/protocols/agent-communication-protocol/), [Agentic Commerce Protocol](/protocols/agentic-commerce-protocol/) ## References - draft-hood-independent-agtp is at revision 09 (dated 2026-06-28 per the IETF datatracker document history), authored by Chris Hood of Nomotic, Inc., filed as an independent submission (not a working-group draft). — [https://datatracker.ietf.org/doc/draft-hood-independent-agtp/](https://datatracker.ietf.org/doc/draft-hood-independent-agtp/) (2026-09-05) VERIFIED - The draft defines AGTP as a dedicated application-layer protocol for AI agent traffic, distinct from and layered beneath HTTP-based agent protocols it calls Agent Group Messaging Protocols (AGMP) including MCP, ACP, A2A, and ANP; it prefers QUIC and requires TCP/TLS fallback. — [https://www.ietf.org/archive/id/draft-hood-independent-agtp-04.html](https://www.ietf.org/archive/id/draft-hood-independent-agtp-04.html) (2026-09-05) VERIFIED [JSON](/data/protocols/agtp.json) · [Markdown](/protocols/agtp/index.md) · [OKF v0.2](/okf/protocols/agtp.md) --- # Agent-Channel Frame for Identity-Keyed Fan-Out Delivery to Concurrent Sessions Agent-Channel Frame for Identity-Keyed Fan-Out Delivery to Concurrent Sessions is an agentic-web standard (endpoint) at step 6, Coordinate, governed by Individual Internet-Draft by a single author, submitted via the…; its status is "Internet-Draft, Intended Status: Informational". It answers: "How can concurrent agent sessions of one identity-bound principal (or members of an organisation) exchange short…?" Implementation status is none found, last verified 2026-10-23. ## Quick Wire Reference - **Step**: 6 Coordinate (Talk to another agent) - **Version**: draft-morrison-agent-channel-fan-out-03 (2026-10-23) - **Status**: Internet-Draft, Intended Status: Informational; expires 26 April 2027 · none… - **Discovery / Probe Path**: Delivery substrate addressed via the discovery mechanism of draft-morrison-mcp-dns-discovery… - **Spec URL**: https://datatracker.ietf.org/doc/html/draft-morrison-agent-channel-fan-out-03 - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: A pub/sub message envelope with Server-Sent Events delivery, addressed by identity… [Coordinate](/category/coordinate/) An individual Internet-Draft (Informational) defining an application-layer JSON frame, the agent-channel frame, for short structured messages between concurrent agent sessions of one principal or members of an organisation. Senders name a recipient scope that is expanded against live subscriptions at delivery time, and recipients receive frames over a per-handle Server-Sent Events stream with an optional subscribe filter. Frames are ephemeral; persistence is out of scope. It composes with draft-morrison-mcp-dns-discovery and draft-morrison-identity-accord and introduces no new transport. ## Discovery and probe Delivery substrate addressed via the discovery mechanism of draft-morrison-mcp-dns-discovery (DNS-based); per-handle SSE stream ``` NONE parse: on absent: No public probe defined in the available text; support cannot be observed from a site without the companion discovery draft details. ``` Not probed live: no-fixed-path. candidate record; probe rule pending ## History - 2026-10-16 — auto-drafted candidate from exa (https://datatracker.ietf.org/doc/html/draft-morrison-agent-channel-fan-out-02) - 2026-10-23 — revision 02 → 03 (watcher) ## Instances Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Pairs with: [Discovery of Model Context Protocol Servers via DNS TXT Records](/protocols/mcp-dns-discovery/) ## References - Datatracker shows draft-morrison-agent-channel-fan-out-03, published 2026-10-23 (expires 26 April 2027), specifying the JSON agent-channel frame, identity attribution pair, inline provenance block, and SSE fan-out delivery. — [https://datatracker.ietf.org/doc/html/draft-morrison-agent-channel-fan-out-03](https://datatracker.ietf.org/doc/html/draft-morrison-agent-channel-fan-out-03) (2026-10-23) VERIFIED - Internet-Draft specifies a JSON agent-channel frame with a closed catalogue of kinds, identity attribution pair, provenance block, recipient scope expansion, and per-handle Server-Sent Events delivery with subscribe-time filters. — [https://datatracker.ietf.org/doc/html/draft-morrison-agent-channel-fan-out-02](https://datatracker.ietf.org/doc/html/draft-morrison-agent-channel-fan-out-02) (2026-10-09) REPORTED [JSON](/data/protocols/agent-channel-fan-out.json) · [Markdown](/protocols/agent-channel-fan-out/index.md) · [OKF v0.2](/okf/protocols/agent-channel-fan-out.md) --- # agent-permissions.json (/.well-known/agent-permissions.json) agent-permissions.json is an agentic-web standard (well-known file — /.well-known/agent-permissions.json) at step 3, Permit, governed by Lightweight Agent Standards Working Group, an open community…; its status is "v1.0.0, complete JSON Schema published". It answers: "Which page-level interactions (clicking, form submission, file upload, media control, script execution) may an agent…?" Implementation status is prototype (observed on 1/1226 probed origins), last verified 2026-10-23. ## Quick Wire Reference - **Step**: 3 Permit (What may the agent do here?) - **Version**: 1.0.0 (2026-07-17) - **Status**: v1.0.0, complete JSON Schema published; described by the working group's own… - **Discovery / Probe Path**: /.well-known/agent-permissions.json — well-known file, overridable per-page by an HTML tag. It does not govern whether a URL may be crawled in the first place (robots.txt's job), does not define content-use-after-fetch permissions (AIPREF/Content Signals' job), and does not define authentication or payment. Governance is informal: LAS-WG presents itself as an open working group with a GitHub org and a companion arXiv paper, not a submission to IETF, W3C, or any chartered standards body, and no version history beyond 1.0.0 (published 2026-07-17) was found in this pass. As of this verification (2026-09-06), the spec text and JSON Schema are complete and internally consistent across both the GitHub repository and the independently-hosted arXiv paper, which is enough for two independent primary sources; however, this pass found no production website actually serving a live agent-permissions.json file, and no browser-agent product (e.g. a computer-use or browsing agent framework) documented as consuming it, though LAS-WG publishes a reference Python validator and parser in its GitHub repository, so implementation is recorded as prototype rather than shipping. What is unresolved: whether LAS-WG has any institutional backing beyond its own GitHub organization; whether any of the browser-driving agent vendors (OpenAI Operator-style agents, Anthropic computer use, browser extensions) have committed to reading this file; and how it will interact with the pre-existing, differently-scoped agents.json API-discovery convention it explicitly distinguishes itself from in its own comparison table. ## Discovery and probe well-known file, overridable per-page by an HTML element · /.well-known/agent-permissions.json ``` GET {origin}/.well-known/agent-permissions.json parse: Valid JSON with top-level 'metadata' (schema_version, last_updated) and 'strict' boolean fields present, per the LAS-WG JSON Schema on absent: No agent-permissions.json at the well-known path; also check the page's HTML for a override before concluding the site has not published page-action permissions ``` Live check run by [the MCP probe](/mcp/server-card): GET /.well-known/agent-permissions.json. agent-permissions.json requires metadata and strict at top level. ``` { "path": "/.well-known/agent-permissions.json", "expect": { "json_keys": [ "metadata", "strict" ] }, "note": "agent-permissions.json requires metadata and strict at top level." } ``` ## History - 2026-09-06 — created and verified against github.com/las-wg/agent-permissions.json and arxiv.org/html/2601.02371v2 (occupant-diff candidate) - 2026-10-16 — No push since 2025-12-10 (over 180 days) - 2026-10-16 — use-case tags (auto) ## Instances - [agent-ready.dev Conformance Scanner Agent](https://agent-ready.dev) · Observed 2026-10-23 · agent Every instance with its source is listed on the [instances page](/instances/). Verified SDKs, reference implementations & validators: - [las-wg/agent-permissions.json (JSON Schema + spec)](https://github.com/las-wg/agent-permissions.json) · implementation (2026-07-17) Our probe: seen on 1 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Pairs with: [AI Crawler User-Agent Tokens in robots.txt](/protocols/ai-crawler-tokens-robots/), [AIPREF Vocabulary](/protocols/aipref-vocabulary/), [Content Signals Policy](/protocols/cloudflare-content-signals-policy/), [agents.json](/protocols/agents-json/), [WebMCP](/protocols/webmcp/) ## Comparisons - [AI Crawler User-Agent Tokens in robots.txt vs agent-permissions.json](/compare/ai-crawler-tokens-robots-vs-agent-permissions-json/) - [agent-permissions.json vs auth.md](/compare/agent-permissions-json-vs-auth-md/) ## References - The las-wg/agent-permissions.json GitHub repository publishes a complete JSON Schema (metadata, strict default, resource_rules with an enumerated verb list including read_content/click_element/submit_form/execute_script/upload_file, action_guidelines with RFC 2119 directives, and an api block referencing OpenAPI/MCP/A2A endpoints), discoverable at /.well-known/agent-permissions.json or via a tag. — [https://github.com/las-wg/agent-permissions.json](https://github.com/las-wg/agent-permissions.json) (2026-07-17) VERIFIED - An arXiv paper by the Lightweight Agent Standards Working Group, 'Permission Manifests for Web Agents,' independently describes the same manifest structure, discovery paths, and positions it against MCP/A2A and OpenAPI as complementary rather than competing. — [https://arxiv.org/html/2601.02371v2](https://arxiv.org/html/2601.02371v2) (2026-01) VERIFIED - No push since 2025-12-10 (over 180 days) — [https://github.com/las-wg/agent-permissions.json](https://github.com/las-wg/agent-permissions.json) (2026-10-15) REPORTED [JSON](/data/protocols/agent-permissions-json.json) · [Markdown](/protocols/agent-permissions-json/index.md) · [OKF v0.2](/okf/protocols/agent-permissions-json.md) --- # Agent-to-Wallet Protocol for Digital Credentials (A2WP) Agent-to-Wallet Protocol for Digital Credentials (A2WP) is an agentic-web standard (endpoint) at step 8, Present, governed by Individual Internet-Draft submitted to the IETF Network Working…; its status is "Internet-Draft, Intended Status: Standards Track". It answers: "How can an AI agent hand a credential offer or presentation request to a wallet unchanged, so that credentials and keys…?" Implementation status is none found, last verified 2026-10-23. ## Quick Wire Reference - **Step**: 8 Present (Show a human the result) - **Version**: draft-senarath-a2wp-01 (2026-10-17) - **Status**: Internet-Draft, Intended Status: Standards Track; expires 20 April 2027; work… - **Discovery / Probe Path**: Not specified in the visible text; bindings (transport and agent authentication) are out of… - **Spec URL**: https://datatracker.ietf.org/doc/html/draft-senarath-a2wp-01 - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: A delegation hand-off, similar to a browser passing a payment request to a separate… [Present](/category/present/) A2WP is an individual IETF Internet-Draft (Standards Track intended) that defines messages and calls between an AI Agent and a Wallet. The Agent submits a credential offer or presentation request exactly as received. The Wallet decides whether to act, involves the Principal when needed, and runs OpenID4VCI or OpenID4VP with the Issuer or Verifier. The Agent polls the operation status and receives any continuation, while keys and credentials stay in the Wallet. Transport bindings, wallet policy, and credential formats are out of scope. ## Discovery and probe Not specified in the visible text; bindings (transport and agent authentication) are out of scope of the document ``` NONE parse: on absent: No public discovery mechanism is defined in the visible text, so support cannot be observed from a site. ``` Not probed live: no-fixed-path. candidate record; probe rule pending ## History - 2026-10-19 — auto-drafted candidate from exa (https://datatracker.ietf.org/doc/html/draft-senarath-a2wp-01) ## Instances Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Pairs with: [x401: HTTP Proof Requirement Protocol](/protocols/x401/) ## Comparisons - [Iframes & Server-Driven UI vs MCP Apps, AG-UI & A2UI (classic vs agentic)](/compare/iframes-vs-mcp-apps/) - [Agent-User Interaction Protocol vs Agent-to-Wallet Protocol for Digital Credentials](/compare/ag-ui-vs-a2wp/) ## References - The Internet-Draft defines A2WP, where an AI Agent passes a credential offer or presentation request unchanged to a Wallet. The Wallet runs OpenID4VCI or OpenID4VP, and credentials, presentations and keys never reach the agent. The draft has Submit, Get and Cancel calls and an operation lifecycle of pending, completed, failed and cancelled. — [https://datatracker.ietf.org/doc/html/draft-senarath-a2wp-01](https://datatracker.ietf.org/doc/html/draft-senarath-a2wp-01) (2026-10-17) REPORTED [JSON](/data/protocols/a2wp.json) · [Markdown](/protocols/a2wp/index.md) · [OKF v0.2](/okf/protocols/a2wp.md) --- # Agent-User Interaction Protocol (AG-UI) Agent-User Interaction Protocol (AG-UI) is an agentic-web standard (endpoint) at step 8, Present, governed by AG-UI open-source project, originated and still primarily…; its status is "1.0 released and frozen". It answers: "How does an agent stream state, generative UI, messages, and tool activity into a user-facing application in real time?" Implementation status is multi-implementation, last verified 2026-10-23. ## Quick Wire Reference - **Step**: 8 Present (Show a human the result) - **Version**: 1.0 (2026-09-18) - **Status**: 1.0 released and frozen; JSON Schema published · multi-implementation - **Discovery / Probe Path**: No fixed well-known path; a client is coded against a known agent backend endpoint that emits… - **Spec URL**: https://docs.ag-ui.com/introduction - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: A server-sent-events/WebSocket API contract between a web frontend and its backend [Present](/category/present/) AG-UI (Agent-User Interaction Protocol) is an open, lightweight, event-based protocol that standardizes how an AI agent backend streams state, messages, generative-UI updates, and tool activity into a user-facing frontend application, and how the frontend sends interactions and tool results back. CopilotKit announced it on May 12, 2025 as 'an open, lightweight protocol that streams a single sequence of JSON events over standard HTTP or an optional binary channel' [[1]](#ref-1). Its own docs position it as one of three complementary 'agentic protocols': MCP handles Agent↔Tools/Data, A2A handles Agent↔Agent, and AG-UI handles Agent↔User Interaction — it is explicitly not a competitor to either [[2]](#ref-2). ## Overview Mechanically, an agent backend emits roughly sixteen standard event types (e.g. streaming text message chunks, tool-call events, state snapshots and diffs, run lifecycle/error events) over whatever transport the integration chooses — SSE, WebSockets, or webhooks are all named as compatible — and a middleware layer normalizes 'loose event format matching' so different backend frameworks and different frontend clients can interoperate without agreeing on a single wire transport [[2]](#ref-2). AG-UI itself does not define a fixed origin path or well-known discovery file; a given application wires its own agent endpoint and a client library (or hand-rolled parser) that speaks the event vocabulary. AG-UI does not solve tool invocation (that is MCP's job) or agent-to-agent delegation (A2A's job), and it does not define authentication, payment, or content-permission mechanics. Current state: AG-UI 1.0 was released and frozen on 2026-09-18 with a normative protocol/schema.json JSON Schema (@ag-ui/core reached 1.0.3 on 2026-10-16) under github.com/ag-ui-protocol/ag-ui (MIT license) [[4]](#ref-4)[[5]](#ref-5). It is described in its own docs as supported 'first-party' by Microsoft Agent Framework, Google ADK, AWS Strands Agents, Mastra, Pydantic AI, Agno, LlamaIndex, AG2, and AWS Bedrock AgentCore, with community-maintained SDKs in Kotlin, Go, Dart, Java, Rust, Ruby, C++, and .NET, and CopilotKit itself as the reference first-party client [[2]](#ref-2)[[3]](#ref-3). AG-UI also documents relationships with two adjacent generative-UI specs — A2UI (which it calls its own declarative generative-UI companion, with AG-UI as A2UI's 'standard transport binding') and MCP Apps — treating both as things it can carry rather than as competitors. What is disputed or unknown: there is no independent, documented count of production deployments; the evidence here is repository activity and named partner integrations, which is 'observed,' not a measured census. The relationship between AG-UI, originated and still steered largely by CopilotKit, and 'community' governance is informal — there is a public Discord and a biweekly working group, but no independent foundation. It is unclear how much of the 1st-party partner list reflects deployed production traffic versus documented compatibility. ## Discovery and probe No fixed well-known path; a client is coded against a known agent backend endpoint that emits an AG-UI-compatible event stream over an agreed transport (SSE, WebSockets, webhooks) ``` POST {endpoint} — the application-defined AG-UI run endpoint (no fixed path; confirmed per-integration, e.g. via a framework's AG-UI adapter) parse: Response is an event stream using AG-UI's ~16 standard event types (e.g. TEXT_MESSAGE_START/CONTENT/END, RUN_ERROR, STATE_SNAPSHOT); presence of these event names confirms AG-UI compliance on absent: No AG-UI-shaped event stream; the backend is not exposing an AG-UI-compatible interface ``` Not probed live: no-fixed-path. The AG-UI run endpoint is application-defined. ## History - 2026-09-05 — seeded from Exa Agent research run - 2026-09-06 — verified against docs.ag-ui.com/introduction, github.com/ag-ui-protocol/ag-ui, and CopilotKit's original announcement - 2026-10-16 — AG-UI 1.0 was released and frozen on 2026-09-18, with a published JSON Schema - 2026-10-16 — use-case tags (auto) - 2026-10-16 — version release/2026-10-13 (watcher) - 2026-10-16 — version label restored to '1.0'; the repository's latest tag (release/2026-10-13) is a package, SDK or build tag, not the specification version, so the GitHub watch no longer drives version - 2026-10-16 — @ag-ui/core 1.0.3 published 2026-10-16 ## Instances - [CopilotKit](https://www.copilotkit.ai) · Observed 2026-08-14 · harness - [Google Agent Development Kit (ADK)](https://google.github.io/adk-docs/) · Observed 2026-07-31 · harness Every instance with its source is listed on the [instances page](/instances/). Verified SDKs, reference implementations & validators: - [@ag-ui/core and related TypeScript packages (core, client, encoder, proto, cli)](https://github.com/ag-ui-protocol/ag-ui) · sdk (2026-09-05) - [Community SDKs: Kotlin, Go, Dart, Java, Rust, Ruby, C++, .NET](https://docs.ag-ui.com/introduction) · sdk (2026-09-05) - [CopilotKit (reference/1st-party client)](https://github.com/CopilotKit/CopilotKit) · implementation (2026-09-05) Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Pairs with: [A2UI (Agent to UI) Protocol](/protocols/a2ui/), [Model Context Protocol](/protocols/mcp/), [Agent2Agent Protocol](/protocols/a2a/), [MCP Apps](/protocols/mcp-apps/), [Agent Client Protocol](/protocols/agent-client-protocol/) - [Subagent](/terms/subagent/) - [Interrupt](/terms/interrupt/) - [Generative UI](/terms/generative-ui/) - Not to be confused with: A2UI ## Comparisons - [Iframes & Server-Driven UI vs MCP Apps, AG-UI & A2UI (classic vs agentic)](/compare/iframes-vs-mcp-apps/) - [A2UI (Agent to UI) Protocol vs Agent-User Interaction Protocol](/compare/a2ui-vs-ag-ui/) - [MCP Apps vs Agent-User Interaction Protocol](/compare/mcp-apps-vs-ag-ui/) - [Agent-User Interaction Protocol vs Agent-to-Wallet Protocol for Digital Credentials](/compare/ag-ui-vs-a2wp/) ## References - CopilotKit's own announcement post, dated May 12, 2025, introduces AG-UI as 'an open, lightweight protocol that streams a single sequence of JSON events over standard HTTP or an optional binary channel.' — [https://webflow.copilotkit.ai/blog/introducing-ag-ui-the-protocol-where-agents-meet-users](https://webflow.copilotkit.ai/blog/introducing-ag-ui-the-protocol-where-agents-meet-users) (2025-05-12) VERIFIED - docs.ag-ui.com/introduction (fetched 2026-09-05) describes AG-UI as an open, lightweight, event-based protocol, positions it as the 'Agent ↔ User Interaction' layer alongside MCP (Agent ↔ Tools & Data, from Anthropic) and A2A (Agent ↔ Agent, from Google), and lists 1st-party integrations from Microsoft Agent Framework, Google ADK, AWS Strands/Bedrock AgentCore, plus SDKs in Kotlin, Go, Dart, Java, Rust, Ruby, C++, .NET. — [https://docs.ag-ui.com/introduction](https://docs.ag-ui.com/introduction) (2026-09-05) VERIFIED - GitHub repo github.com/ag-ui-protocol/ag-ui carries an MIT license, 15.7k stars, 3,840+ commits, and daily commit activity as of Sep 4-5, 2026, indicating an actively maintained, multi-contributor project rather than a dormant announcement. — [https://github.com/ag-ui-protocol/ag-ui](https://github.com/ag-ui-protocol/ag-ui) (2026-09-05) VERIFIED - AG-UI 1.0 was released and frozen on 2026-09-18, with a published JSON Schema — [https://github.com/ag-ui-protocol/ag-ui/discussions/2792](https://github.com/ag-ui-protocol/ag-ui/discussions/2792) (2026-09-18) REPORTED - release/2026-10-13 released 2026-10-13 — [https://github.com/ag-ui-protocol/ag-ui/releases/tag/release/2026-10-13](https://github.com/ag-ui-protocol/ag-ui/releases/tag/release/2026-10-13) (2026-10-13) VERIFIED - @ag-ui/core 1.0.3 published 2026-10-16 — [https://www.npmjs.com/package/@ag-ui/core](https://www.npmjs.com/package/@ag-ui/core) (2026-10-16) REPORTED [JSON](/data/protocols/ag-ui.json) · [Markdown](/protocols/ag-ui/index.md) · [OKF v0.2](/okf/protocols/ag-ui.md) --- # Agent2Agent Protocol (A2A · /.well-known/agent-card.json) Agent2Agent Protocol (A2A) is an agentic-web standard (endpoint — /.well-known/agent-card.json) at step 6, Coordinate, governed by Linux Foundation; its status is "Stable, v1.0.1". It answers: "How do two independent agents, built on different frameworks, discover each other and delegate a task to completion?" Implementation status is multi-implementation (150+ supporting organizations, claimed by the Linux…; observed on 54/1226 probed origins), last verified 2026-10-23. ## Quick Wire Reference - **Step**: 6 Coordinate (Talk to another agent) - **Version**: 1.0.1 (2026-05-28) - **Status**: Stable, v1.0.1 · multi-implementation - **Discovery / Probe Path**: /.well-known/agent-card.json — Agent Card - **Spec URL**: https://a2a-protocol.org/latest/specification/ - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: none [Coordinate](/category/coordinate/) Agent2Agent (A2A) is an open protocol for two independent AI agents — potentially built on different frameworks, by different companies, running on separate servers — to discover each other's capabilities and collaborate on a task without either exposing its internal memory, tools, or proprietary logic [[1]](#ref-1). It solves agent-to-agent interoperability at the application layer: an A2A server publishes a JSON "Agent Card" describing its identity, service endpoint, supported interaction modes (sync request/response, Server-Sent Events streaming, async push notifications), and skills; a client agent fetches that card, then exchanges JSON-RPC 2.0 messages over HTTP(S) to create and drive a task to completion [[1]](#ref-1). Standard discovery is the well-known URI https://{domain}/.well-known/agent-card.json, per RFC 8615; the spec also allows curated-registry discovery (no standard registry API is prescribed) and direct/hardcoded configuration [[1]](#ref-1). In v1.0 the endpoint left the top of the card: url, protocolBinding, and protocolVersion sit on each supportedInterfaces[] entry, and preferredTransport and additionalInterfaces fold into that array [[7]](#ref-7). A legacy v0.3 card still carries a top-level url. A probe accepts either shape and records which fields it used. ## Overview A2A does not itself define a registry protocol, a payment mechanism, or a UI-rendering format — those are left to other layers (registries, x402/agentic-commerce specs, and UI-negotiation extensions respectively). It also does not replace intra-agent tool-calling protocols such as MCP; A2A and MCP are commonly described by the project as complementary. Google announced A2A on 2025-04-09 with 50+ launch partners and donated it to the Linux Foundation later in 2025 [[2]](#ref-2). On 17 August 2026 A2A joined the Agentic AI Foundation (AAIF), alongside that Linux Foundation project and its Technical Steering Committee [[6]](#ref-6). The specification reached v1.0.0 on 12 March 2026 (followed by patch release v1.0.1 on 28 May 2026) and is labeled stable on the project's documentation site [[1]](#ref-1). At its one-year mark (2026-04-09) the project's press release claimed more than 150 supporting organizations, integration into major cloud platforms (the release names Google Cloud, Microsoft, and AWS), and active production deployments in supply chain, financial services, insurance, and IT operations [[3]](#ref-3) — this adoption count is a claim by the Linux Foundation/A2A project itself, not an independently measured probe count, so it is recorded here as "claimed," not "measured." Official SDKs are published for Python, Go, JavaScript, Java, .NET, and Rust under the a2aproject GitHub organization, and the project lists integrations from frameworks including Google ADK, LangGraph, and IBM's BeeAI [[2]](#ref-2). The spec leaves curated-discovery registry APIs to individual deployments. The 150-organization figure stays labelled claimed [[3]](#ref-3)[[12]](#ref-12). Public card versions are a different instrument, and the censuses below are not averaged because their frames differ. Agenstry, 1 September 2026: of 1,910 cards that declare a protocolVersion, 65.5% (1,252) are 0.3.x and 25.5% (488) are 1.0.x [[8]](#ref-8). Emissar, crawl of 2 October 2026: 276 cards on the Tranco top million, 205 in the v1.0 shape and 71 in the v0.3 shape, none signed, and none in the top 1,000 domains [[9]](#ref-9). APIs.io / Kin Lane, 21 September 2026: 421 parseable cards out of 4,718 hosts probed, from a catalogue of 27,840 providers [[10]](#ref-10). rStation, collected 12 October 2026: 661 cards on 2,164 x402 seller hosts; 189 pass the version they were attributed and fail a check that assumes 1.0, so grading every card as 1.0 inflates the failure count [[11]](#ref-11). ## Discovery and probe Agent Card · /.well-known/agent-card.json ``` GET {origin}/.well-known/agent-card.json parse: Accept either card shape and record which one was seen. A v1.0 card places url, protocolBinding, and protocolVersion inside supportedInterfaces[] (preferredTransport and additionalInterfaces fold into that array). A legacy v0.3 card carries a top-level url. name may be present on either shape. on absent: 404 or non-JSON response means no public Agent Card is hosted at this well-known path; the origin may still run A2A behind auth or a registry ``` Live check run by [the MCP probe](/mcp/server-card): GET /.well-known/agent-card.json. An A2A Agent Card names the agent and where to reach it: a top-level url on a 0.3 card, or url, protocolBinding, and protocolVersion inside supportedInterfaces on a 1.0 card. ``` { "path": "/.well-known/agent-card.json", "expect": { "content_type": "json", "json_keys": [ "name" ], "text_match": "\"url\"\\s*:|supportedInterfaces" }, "note": "An A2A Agent Card names the agent and where to reach it: a top-level url on a 0.3 card, or url, protocolBinding, and protocolVersion inside supportedInterfaces on a 1.0 card." } ``` ## History - 2026-09-05 — seeded from Exa Agent research run - 2026-09-06 — verified against a2a-protocol.org/latest/specification/, github.com/a2aproject/A2A README and agent-discovery.md, and the LF/A2A one-year press release (prnewswire) - 2026-10-16 — A2A v1.0.1 released on 2026-05-28 (v1.0.0 on 2026-03-12); governance is the Linux Foundation with a Technical Steering Committee of AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP and ServiceNow - 2026-10-16 — use-case tags (auto) - 2026-10-20 — AAIF membership (17 August 2026) added beside the Linux Foundation TSC; probe accepts v1.0 supportedInterfaces cards and legacy v0.3 cards; four card-version censuses recorded with their frames - 2026-10-21 — a2a-sdk 1.2.3 published 2026-10-19 ## Instances - [SurrealDB (surrealdb.com)](https://surrealdb.com/) · Observed 2026-10-25 · origin - [Speakeasy (speakeasy.com)](https://speakeasy.com/) · Observed 2026-10-25 · origin - [Reducto Document AI (reducto.ai)](https://reducto.ai/) · Observed 2026-10-25 · origin - [Pydantic & Logfire (pydantic.dev)](https://pydantic.dev/) · Observed 2026-10-25 · origin - [Publica.la (publica.la)](https://publica.la/) · Observed 2026-10-25 · origin - [Perplexity API Docs (docs.perplexity.ai)](https://docs.perplexity.ai/) · Observed 2026-10-25 · origin - [Novita AI (novita.ai)](https://novita.ai/) · Observed 2026-10-25 · origin - [Model Context Protocol Docs (modelcontextprotocol.io)](https://modelcontextprotocol.io/) · Observed 2026-10-25 · origin - [Intercom Developers (developers.intercom.com)](https://developers.intercom.com/) · Observed 2026-10-25 · origin - [DC Hub (dchub.cloud)](https://dchub.cloud/) · Observed 2026-10-25 · origin - [Cerebrium Serverless AI (cerebrium.ai)](https://cerebrium.ai/) · Observed 2026-10-25 · origin - [Baseten Docs (docs.baseten.co)](https://docs.baseten.co/) · Observed 2026-10-25 · origin - [Augment Code Docs (docs.augmentcode.com)](https://docs.augmentcode.com/) · Observed 2026-10-25 · origin - [Attio Docs (docs.attio.com)](https://docs.attio.com/) · Observed 2026-10-25 · origin - [Apideck Unified API (apideck.com)](https://apideck.com/) · Observed 2026-10-25 · origin - [Agent Skills Specification (agentskills.io)](https://agentskills.io/) · Observed 2026-10-25 · origin - [Agent Client Protocol (agentclientprotocol.com)](https://agentclientprotocol.com/) · Observed 2026-10-25 · origin - [AG-UI Documentation Origin (docs.ag-ui.com)](https://docs.ag-ui.com/) · Observed 2026-10-25 · origin - [Ad Context Protocol Docs (docs.adcontextprotocol.org)](https://docs.adcontextprotocol.org/) · Observed 2026-10-25 · origin - [2s.io](https://2s.io/) · Observed 2026-10-25 · origin - [Telnyx (telnyx.com)](https://telnyx.com/) · Observed 2026-10-23 · origin - [QuickNode (quicknode.com)](https://quicknode.com/) · Observed 2026-10-23 · origin - [Neuronto Agentic Web Index](https://neuronto.com) · Observed 2026-10-23 · venue - [Mnemom Cryptographic Agent Trust Service](https://mnemom.ai) · Observed 2026-10-23 · authority - [Dreaming Press (dreaming.press)](https://dreaming.press/) · Observed 2026-10-23 · origin - [Cloudflare (cloudflare.com)](https://cloudflare.com/) · Observed 2026-10-23 · origin - [agenticweb.wiki Reference Agent and MCP Server](https://agenticweb.wiki) · Observed 2026-10-23 · agent - [agent-ready.dev Conformance Scanner Agent](https://agent-ready.dev) · Observed 2026-10-23 · agent - [Agent Community / Open Agent Registry (AID)](https://agentcommunity.org) · Observed 2026-10-23 · venue - [IBM BeeAI Multi-Agent Runtime](https://github.com/i-am-bee/beeai-platform) · Observed 2026-08-29 · agent - [CopilotKit](https://www.copilotkit.ai) · Observed 2026-08-14 · harness - [8004.org / ERC-8004 Trustless Agents Registry](https://www.8004.org) · Observed 2026-08-13 · venue - [Google Agent Development Kit (ADK)](https://google.github.io/adk-docs/) · Observed 2026-07-31 · harness - [Nevermined x402 Facilitator and Metering Clearinghouse](https://docs.nevermined.app) · Observed 2026-07-23 · venue - [AGNTCY Agent Directory Service (Linux Foundation)](https://agntcy.org) · Observed 2026-07-23 · venue - [Infoblox DNS-AID Registry (Linux Foundation)](https://github.com/infobloxopen/dns-aid-core) · Observed 2026-07-15 · venue - [GoDaddy Agent Name Service (ANS) Authority](https://github.com/godaddy/ans) · Observed 2026-07-15 · authority - [OpenA2A Agent Authorization Protocol (AAP) Authority](https://github.com/opena2a-standards/agent-authorization-protocol) · Observed 2026-07-02 · authority Every instance with its source is listed on the [instances page](/instances/). Verified SDKs, reference implementations & validators: - [a2a-sdk (PyPI)](https://pypi.org/project/a2a-sdk) · sdk (2026-09-05) - [@a2a-js/sdk (npm)](https://github.com/a2aproject/a2a-js) · sdk (2026-09-05) - [a2a-python (reference SDK)](https://github.com/a2aproject/a2a-python) · implementation (2026-09-05) - [a2a-go](https://github.com/a2aproject/a2a-go) · implementation (2026-09-05) - [a2a-java](https://github.com/a2aproject/a2a-java) · implementation (2026-09-05) - [a2a-dotnet](https://github.com/a2aproject/a2a-dotnet) · implementation (2026-09-05) - [a2a-rs (Rust)](https://github.com/a2aproject/a2a-rs) · implementation (2026-09-05) Our probe: seen on 54 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Depended on by: [Ad Context Protocol](/protocols/adcp/) - Pairs with: [Model Context Protocol](/protocols/mcp/), [x402](/protocols/x402/), [Agent Payments Protocol](/protocols/ap2/), [Official MCP Registry](/protocols/mcp-registry/), [The Agent Identity Document: A Hosted, Accountable Public Record for AI Agents](/protocols/agent-identity-document/), [Agent Client Protocol](/protocols/agent-client-protocol/) - [Agent Card](/terms/agent-card/) - [Well-known URI](/terms/well-known/) - [Agentic web](/terms/agentic-web/) - [Subagent](/terms/subagent/) - [Agent2Agent (A2A)](/terms/agent-to-agent/) - [A2A Task](/terms/a2a-task/) - [AI agent](/terms/ai-agent/) - Scanners & registries: [Agents Welcome — Agent Protocol Atlas](https://agentswelcome.dev/protocols), [The Agent Almanac](https://agentalmanac.org/) - Not to be confused with: Account-to-Account payments (A2A, banking) ## Comparisons - [Webhooks & RPC vs Agent2Agent Protocol (A2A) (classic vs agentic)](/compare/webhooks-vs-a2a/) - [Agent2Agent Protocol vs Model Context Protocol](/compare/a2a-vs-mcp/) - [Agent2Agent Protocol vs MCP Server Cards (SEP-2127)](/compare/a2a-vs-mcp-server-cards/) - [Agent2Agent Protocol vs Agent Communication Protocol](/compare/a2a-vs-agent-communication-protocol/) - [Agent Identity and Discovery vs Agent2Agent Protocol](/compare/aid-vs-a2a/) - [Agent2Agent Protocol vs Agent Network Protocol](/compare/a2a-vs-anp/) - [Agent2Agent Protocol vs Coral Protocol (CoralOS)](/compare/a2a-vs-coral-protocol/) - [Agent2Agent Protocol vs AITP (Agent Interaction & Transaction Protocol)](/compare/a2a-vs-aitp/) - [Agent2Agent Protocol vs Secure Low-Latency Interactive Messaging](/compare/a2a-vs-slim/) - [Agent2Agent Protocol vs Natural Language Interaction Protocol](/compare/a2a-vs-nlip/) ## References - A2A v1.0.0 specification defines JSON-RPC 2.0 over HTTP(S), the Agent Card discovery document, and the well-known path /.well-known/agent-card.json per RFC 8615. — [https://a2a-protocol.org/latest/specification/](https://a2a-protocol.org/latest/specification/) (2026-09-05) VERIFIED - The A2A Protocol project is an open source project under the Linux Foundation, contributed by Google, licensed Apache 2.0. Official SDKs exist for Python (a2a-sdk), Go, JavaScript, Java, .NET, and Rust, maintained under the a2aproject GitHub org. — [https://raw.githubusercontent.com/a2aproject/A2A/main/README.md](https://raw.githubusercontent.com/a2aproject/A2A/main/README.md) (2026-09-05) VERIFIED - On its one-year anniversary (announced 2026-04-09), the A2A Protocol project stated it had surpassed 150 supporting organizations and cited integration in major cloud platforms and enterprise production use. — [https://www.prnewswire.com/news-releases/a2a-protocol-surpasses-150-organizations-lands-in-major-cloud-platforms-and-sees-enterprise-production-use-in-first-year-302737641.html](https://www.prnewswire.com/news-releases/a2a-protocol-surpasses-150-organizations-lands-in-major-cloud-platforms-and-sees-enterprise-production-use-in-first-year-302737641.html) (2026-04-09) VERIFIED - A2A v1.0.1 released on 2026-05-28 (v1.0.0 on 2026-03-12); governance is the Linux Foundation with a Technical Steering Committee of AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP and ServiceNow — [https://github.com/a2aproject/A2A/releases](https://github.com/a2aproject/A2A/releases) (2026-05-28) REPORTED - A2A v1.0.1 released on 2026-05-28 (v1.0.0 on 2026-03-12); governance is the Linux Foundation with a Technical Steering Committee of AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP and ServiceNow — [https://a2a-protocol.org/latest/](https://a2a-protocol.org/latest/) (2026-05-28) VERIFIED - A2A joined the Agentic AI Foundation on 17 August 2026. The project was already a Linux Foundation project. — [https://aaif.io/blog/a2a-joins-aaif](https://aaif.io/blog/a2a-joins-aaif) (2026-08-17) VERIFIED - In v1.0, protocolVersion left the top of the Agent Card and sits on each supportedInterfaces[] entry, next to protocolBinding and url. preferredTransport and additionalInterfaces folded into that array. — [https://a2a-protocol.org/latest/whats-new-v1/](https://a2a-protocol.org/latest/whats-new-v1/) (2026-03-12) VERIFIED - Of 1,910 Agent Cards declaring protocolVersion in the Agenstry registry on 2026-09-01, 65.5% (1,252) are 0.3.x and 25.5% (488) are 1.0.x. — [https://agenstry.com/blog/state-of-the-agent-card](https://agenstry.com/blog/state-of-the-agent-card) (2026-09-01) VERIFIED - Emissar's crawl of 2 October 2026 found 276 Agent Cards on the Tranco top million: 205 in the v1.0 shape, 71 in the v0.3 shape, none signed, and none in the top 1,000 domains. — [https://emissar.ai/learn/a2a-adoption-2026](https://emissar.ai/learn/a2a-adoption-2026) (2026-10-02) VERIFIED - APIs.io reported on 2026-09-21 that 421 parseable Agent Cards were found from 4,718 hosts probed, out of 27,840 providers. — [https://apievangelist.com/2026/09/21/a2a-adoption-is-421-of-27840-and-most-of-them-arrived-with-the-card/](https://apievangelist.com/2026/09/21/a2a-adoption-is-421-of-27840-and-most-of-them-arrived-with-the-card/) (2026-09-21) VERIFIED - rStation, collected 12 October 2026, parsed 661 Agent Cards on 2,164 x402 seller hosts. 189 documents pass their attributed version and fail a check that assumes 1.0. — [https://rstation.ai/problems/ai_agent/papers/1](https://rstation.ai/problems/ai_agent/papers/1) (2026-10-12) VERIFIED - The Linux Foundation one-year release on 9 April 2026 claimed more than 150 supporting organizations, and named Google, Microsoft, and AWS integrations. That organization count is the project's own claim. — [https://www.linuxfoundation.org/press/a2a-protocol-surpasses-150-organizations-lands-in-major-cloud-platforms-and-sees-enterprise-production-use-in-first-year](https://www.linuxfoundation.org/press/a2a-protocol-surpasses-150-organizations-lands-in-major-cloud-platforms-and-sees-enterprise-production-use-in-first-year) (2026-04-09) VERIFIED - a2a-sdk 1.2.3 published 2026-10-19 — [https://pypi.org/project/a2a-sdk/](https://pypi.org/project/a2a-sdk/) (2026-10-19) REPORTED [JSON](/data/protocols/a2a.json) · [Markdown](/protocols/a2a/index.md) · [OKF v0.2](/okf/protocols/a2a.md) --- # Agentic Advertising Management Protocols (AAMP) Agentic Advertising Management Protocols (AAMP) is an agentic-web standard (endpoint) at step 6, Coordinate, governed by IAB Tech Lab; its status is "Active umbrella initiative, current release AAMP 2.3, described…". It answers: "How do a buyer's agent and a seller's agent discover each other's inventory, negotiate terms and hand off a transaction…?" Implementation status is multi-implementation (IAB Tech Lab and named partners), last verified 2026-10-23. ## Quick Wire Reference - **Step**: 6 Coordinate (Talk to another agent) - **Version**: AAMP 2.3 (2026-07-30) - **Status**: Active umbrella initiative, current release AAMP 2.3, described by its own… - **Discovery / Probe Path**: https://registry.iabtechlab.ai/ — endpoint - **Spec URL**: https://github.com/IABTechLab/AAMP - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: no single classic-web analog; closest is an umbrella of OpenRTB/OpenDirect-style… [Coordinate](/category/coordinate/) AAMP is IAB Tech Lab's umbrella name for its agentic-advertising program: how a buyer's agent and a seller's agent (and the platforms behind them) discover inventory, negotiate, and execute an advertising transaction using agent-to-agent workflows layered on existing ad-tech standards (OpenRTB, OpenDirect, AdCOM, the Deals API) [[1]](#ref-1). This record has been moved from the site's original 'account' placement to 'coordinate' because its core, distinguishing content -- beyond ARTF, which already has its own record under 'act' -- is agent-to-agent negotiation and deal-making (Agentic Direct, Agentic Audiences, buyer/seller agent SDKs), not post-hoc recording or judgment of what happened. ## Overview What it is. Three pillars: Agent Foundations (high-performance execution -- this is ARTF), Agentic Protocols (schemas and reference SDKs for buyer/seller agent discovery, negotiation and transacting), and Trust and Transparency (the free, IAB-run Agent Registry for agent identity and disclosure) [[1]](#ref-1). AAMP 2.3, released 2026-07-30, added enterprise deployment paths (Amazon Bedrock AgentCore, Databricks), Meta buying support, Google Ad Manager reporting integration, embedded privacy diligence (IAB Diligence Platform, SafeGuard Privacy) inside the reference Buyer Agent, and open-source contributions from named partners HyperMindZ (a Deals Sync MCP Server) and Mixpeek (a Content Taxonomy Parser) [[2]](#ref-2). What it does not do. AAMP is not itself a single wire protocol: it has no one spec document or version number that a probe can confirm end-to-end. Its GitHub hub instead points to five separately-versioned repositories -- Agentic Direct, Buyer Agent, Seller Agent, a Registry Agent example, and ARTF -- aligned only through 'governance coordination,' not a shared release [[3]](#ref-3). It does not define payment settlement (that sits with card-network specs like Verifiable Intent) and does not provide an independent audit-trail format of its own. Current state. Governed by IAB Tech Lab's Agentic Task Force, an open working group any member or non-member can join; AAMP 2.3 (2026-07-30) is the current named release, with named-executive quotes from AWS, SafeGuard Privacy, HyperMindZ, Mixpeek and Adform describing production integration work, though none of the fetched sources gives an independently countable adoption figure [[1]](#ref-1)[[2]](#ref-2). Who implements it. IAB Tech Lab publishes open-source reference implementations for each pillar (Agentic Direct, Buyer Agent, Seller Agent SDKs; ARTF's Go and Rust servers); AWS supports AAMP on Bedrock AgentCore; HyperMindZ and Mixpeek have contributed named components. Disputed / unknown. Because AAMP names a coordinated program rather than one spec, 'AAMP 2.3 adoption' is not a single measurable quantity; adoption claims here are attributed to IAB Tech Lab and the named partner quotes, not independently verified counts. Readers evaluating whether a given ad-tech company 'supports AAMP' should ask which constituent repo/version they mean. ## Discovery and probe endpoint · https://registry.iabtechlab.ai/ ``` GET https://registry.iabtechlab.ai/ parse: A response listing registered agents (buyer/seller/registry agents) indicates the IAB Tech Lab Agent Registry, AAMP's 'Trust and Transparency' pillar, is live; absence of a listing for a given company is not proof they lack an AAMP integration, since registration is voluntary. on absent: No registry entry for a company does not mean no AAMP deployment -- only that it has not self-registered. ``` Not probed live: no-fixed-path. AAMP registries are operated by IAB Tech Lab, not by the origin. ## History - 2026-09-05 — seeded from Exa Agent research run - 2026-09-06 — verified against iabtechlab.com/standards/aamp-agentic-advertising-management-protocols/, the 2026-07-30 AAMP 2.3 press release, and github.com/IABTechLab/AAMP; moved step from 'account' to 'coordinate'; flagged umbrella-program dispute and acronym collision with IETF AAP (Agent Authorization Profile) - 2026-10-16 — use-case tags (auto) ## Instances Verified SDKs, reference implementations & validators: - [AAMP GitHub hub (5 constituent repos)](https://github.com/IABTechLab/AAMP) · implementation (2026-09-05) - [Agentic Direct reference implementation](https://github.com/IABTechLab/agentic-direct) · implementation (2026-09-05) - [Buyer Agent SDK](https://github.com/IABTechLab/buyer-agent) · implementation (2026-09-05) - [Seller Agent SDK](https://github.com/IABTechLab/seller-agent) · implementation (2026-09-05) - [Agentic Audiences (formerly LiveRamp UCP donation)](https://github.com/IABTechLab/agentic-audiences) · implementation (2026-09-05) Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Pairs with: [Agentic Real Time Framework](/protocols/artf/), [Ad Context Protocol](/protocols/adcp/), [Model Context Protocol](/protocols/mcp/), [Agent2Agent Protocol](/protocols/a2a/), [CoMP (Content Monetization Protocols)](/protocols/iab-comp/) - Not to be confused with: Agent Authorization Profile (also abbreviated AAP, IETF OAuth draft, unrelated) ## Comparisons - [Webhooks & RPC vs Agent2Agent Protocol (A2A) (classic vs agentic)](/compare/webhooks-vs-a2a/) - [Agentic Advertising Management Protocols vs Ad Context Protocol](/compare/aamp-vs-adcp/) ## References - IAB Tech Lab's AAMP standards page (last updated 2026-08-12) describes AAMP as an umbrella of three pillars -- Agent Foundations (ARTF), Agentic Protocols (Agentic Direct, Buyer/Seller Agent SDKs, Agentic Audiences fka UCP), and Trust and Transparency (the Agent Registry) -- and links five open-source GitHub repos plus the registry. — [https://iabtechlab.com/standards/aamp-agentic-advertising-management-protocols/](https://iabtechlab.com/standards/aamp-agentic-advertising-management-protocols/) (2026-08-12) VERIFIED - IAB Tech Lab's 2026-07-30 press release announces AAMP 2.3, adding Amazon Bedrock AgentCore deployment, Meta buying, Google Ad Manager reporting, an IAB Diligence Platform/SafeGuard Privacy integration, and open-source contributions (Deals Sync MCP Server from HyperMindZ, Content Taxonomy Parser from Mixpeek); quotes named executives from AWS, SafeGuard Privacy, HyperMindZ, Mixpeek and Adform describing integration work. — [https://iabtechlab.com/press-releases/iab-tech-lab-releases-aamp-2-3-bringing-enterprise-grade-infrastructure-and-privacy-diligence-to-agentic-advertising/](https://iabtechlab.com/press-releases/iab-tech-lab-releases-aamp-2-3-bringing-enterprise-grade-infrastructure-and-privacy-diligence-to-agentic-advertising/) (2026-07-30) VERIFIED - The AAMP GitHub hub repository lists five constituent repositories with independent semantic versioning per repo (Agentic Direct, Buyer Agent, Seller Agent, Registry Agent example, and ARTF), coordinated only via 'governance coordination' rather than a single version number. — [https://github.com/IABTechLab/AAMP](https://github.com/IABTechLab/AAMP) (2026-09-05) VERIFIED Disputed: AAMP is not one protocol: it is a named umbrella for at least five separately-versioned repositories and three conceptually distinct pillars (execution via ARTF, which this site tracks as its own record under 'act'; negotiation/transaction via Agentic Direct and Agentic Audiences; and identity/disclosure via the Agent Registry, which overlaps with this site's 'identify' step). 'AAMP 2.3' is a marketing-level release label for the coalition's roadmap, not a single spec version that a probe can confirm end-to-end. This record is kept (per instructions, not withdrawn) but should be read as a program name whose most testable component (ARTF) already has its own row; readers wanting a single executable spec should look at ARTF, Agentic Direct or the Agent Registry individually. [JSON](/data/protocols/aamp.json) · [Markdown](/protocols/aamp/index.md) · [OKF v0.2](/okf/protocols/aamp.md) --- # Agentic Authority Graph Validation (AAGV) Agentic Authority Graph Validation (AAGV) is an agentic-web standard (document format) at step 3, Permit, governed by Individual Internet-Draft submission, author D. O. Watts; its status is "Internet-Draft, Intended Status: Experimental". It answers: "How can an implementer represent a delegated-authority graph in JSON and deterministically validate that declared…?" Implementation status is none found, last verified 2026-10-23. ## Quick Wire Reference - **Step**: 3 Permit (What may the agent do here?) - **Version**: draft-watts-agentic-authority-graph-validation-00 (2026-10-14) - **Status**: Internet-Draft, Intended Status: Experimental; expires 17 April 2027 · none… - **Discovery / Probe Path**: none defined; AAGV is a carrier-neutral JSON interchange profile exchanged out of band - **Spec URL**: https://datatracker.ietf.org/doc/html/draft-watts-agentic-authority-graph-validation-00 - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: A linter or schema validator for authority graphs that returns INVALID… [Permit](/category/permit/) AAGV is an individual IETF Internet-Draft (Experimental) defining a carrier-neutral JSON model and deterministic algorithm for validating authority graphs with declared roots, consequential sinks, normal paths, and revocation cut sets. It includes anti-vacuity rules that reject empty sink or normal-path sets, dangling references, non-dominating cuts, and non-revocable cut edges. It returns INDETERMINATE rather than closed when relevant edge state is unknown. It does not define an authorization token, discover hidden paths, or prove physical containment. ## Discovery and probe none defined; AAGV is a carrier-neutral JSON interchange profile exchanged out of band ``` NONE parse: on absent: No site-level discovery mechanism is defined, so support cannot be observed from a site. ``` Not probed live: no-fixed-path. candidate record; probe rule pending ## History - 2026-10-16 — auto-drafted candidate from exa (https://datatracker.ietf.org/doc/html/draft-watts-agentic-authority-graph-validation-00) ## Instances Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also ## References - The Internet-Draft defines AAGV, a JSON interchange profile and deterministic validation algorithm for authority roots, consequential sinks, normal paths, revocation cut sets and snapshot edge state, with outcomes INVALID, INDETERMINATE, VALID_OPEN and VALID_CLOSED. — [https://datatracker.ietf.org/doc/html/draft-watts-agentic-authority-graph-validation-00](https://datatracker.ietf.org/doc/html/draft-watts-agentic-authority-graph-validation-00) (2026-10-14) REPORTED [JSON](/data/protocols/aagv.json) · [Markdown](/protocols/aagv/index.md) · [OKF v0.2](/okf/protocols/aagv.md) --- # Agentic Commerce Protocol (ACP) Agentic Commerce Protocol (ACP) is an agentic-web standard (endpoint) at step 7, Pay, governed by Technical Steering Committee; its status is "Beta open standard, interaction model for connecting buyers…". It answers: "How do a buyer's agent and a merchant complete a deterministic, programmatic checkout without the agent becoming the…?" Replacing or extending Checkout API, implementation status is multi-implementation (OpenAI and Stripe), last verified 2026-10-23. ## Quick Wire Reference - **Step**: 7 Pay (Settle the bill) - **Version**: 2026-04-17 (date-versioned spec; unreleased/ tracks current development)… - **Status**: Beta open standard, interaction model for connecting buyers, agents, and… - **Discovery / Probe Path**: Bilateral capability negotiation (per RFC: capability_negotiation) between agent platform and… - **Spec URL**: https://github.com/agentic-commerce-protocol/agentic-commerce-protocol - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: Checkout API [Pay](/category/pay/) The Agentic Commerce Protocol (ACP) is an open, REST-based interaction model that lets a buyer's AI agent (a "platform" such as ChatGPT) complete a checkout with a merchant's existing commerce stack, while the merchant remains the system of record for orders, payments, tax, and compliance [[1]](#ref-1). It solves the discovery-to-checkout hand-off for conversational and agentic shopping: a client negotiates capabilities, creates and updates a CheckoutSession, and completes or cancels it, with optional delegated-payment tokens (/agentic_commerce/delegate_payment) so an agent platform can pass a payment method to a merchant without becoming a payment processor [[1]](#ref-1). ## Overview It does not define blockchain settlement, on-chain escrow, or a payment rail of its own — payments continue to run over the merchant's existing PSP relationship, and ACP is scoped explicitly to checkout session lifecycle, feed ingestion, and payment-handler negotiation, not returns, tax computation, or fraud modeling [[1]](#ref-1). It is also not a discovery protocol: there is no published well-known path for finding ACP support at an origin; capability negotiation is bilateral and appears to be arranged per integration (RFC: capability_negotiation), so it cannot be probed generically the way UCP's /.well-known/ucp can. As of the current state (2026-09), the specification uses date-based versioning with a complete snapshot per release; the latest stable release is 2026-04-17, adding a push-model Feed API, multi-item checkout examples, and 3-D Secure authentication flows, with active development continuing in an unreleased/ branch [[1]](#ref-1). Governance sits with a Technical Steering Committee of up to seven organization seats, appointed by Founding Maintainers OpenAI and Stripe, who retain veto power scoped narrowly to five stated principles (mission, neutrality, security, protocol integrity, and considered decision-making) [[2]](#ref-2). Meta has since joined as a third lead maintainer alongside OpenAI and Stripe [[3]](#ref-3). Reference implementations exist from both founding maintainers: OpenAI's ChatGPT commerce surface and Stripe's Agentic Commerce integration, both documented on their respective developer sites [[4]](#ref-4)[[5]](#ref-5). Because the only adoption figures available come from the maintaining organizations' own materials, adoption here is recorded as claimed rather than independently measured. What remains unresolved: how "beta" status maps to production risk for merchants going live today, and whether the TSC's veto mechanism has ever been invoked in a real dispute. ## Discovery and probe Bilateral capability negotiation (per RFC: capability_negotiation) between agent platform and merchant; no fixed well-known path published ``` POST {origin}/checkout_sessions parse: Response includes an API-Version response/negotiation and a CheckoutSession object per the 2026-04-17 OpenAPI schema on absent: Absence proves nothing generalizable: ACP endpoints and auth are negotiated per integration and not advertised at a fixed public path, so a failed probe only shows this origin/path pair is not configured, not that ACP is unsupported. ``` Not probed live: unsafe-post. The probe is POST /checkout_sessions, which creates a checkout on the merchant; never run unauthenticated. ## History - 2026-09-05 — seeded from Exa Agent research run - 2026-09-06 — verified against agentic-commerce-protocol GitHub repo (README, docs/governance.md, MAINTAINERS.md, spec/2026-04-17), developers.openai.com/commerce, docs.stripe.com/agentic-commerce - 2026-09-06 — collisions updated to add Agent Connect Protocol (Cisco/AGNTCY), verified against github.com/agntcy/acp-spec, spec.acp.agntcy.org - 2026-10-16 — use-case tags (auto) ## Instances Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Pairs with: [Agent Payments Protocol](/protocols/ap2/), [Universal Commerce Protocol](/protocols/ucp/), [x402](/protocols/x402/), [Visa Trusted Agent Protocol](/protocols/tap/), [Machine Payments Protocol](/protocols/mpp/), [Agent Attribution Protocol](/protocols/agent-attribution-protocol/) - [Agent Client Protocol](/protocols/agent-client-protocol/) - [Agent Communication Protocol](/protocols/agent-communication-protocol/) - [Agent Connect Protocol (AGNTCY)](/protocols/agent-connect-protocol/) - [ACP (four protocols)](/terms/acp/) - [Idempotency-Key header](/terms/idempotency-key/) - [Buyer of Record & Merchant of Record (Agentic Commerce)](/terms/buyer-of-record/) - Scanners & registries: [The Agent Almanac](https://agentalmanac.org/) - Not to be confused with: Agent Client Protocol (Zed), Agent Communication Protocol (IBM), ERC-8183 (also informally called Agentic Commerce Protocol), Agent Connect Protocol (AGNTCY) ## Comparisons - [3-D Secure & Card Checkout vs AP2, ACP & UCP (classic vs agentic)](/compare/3d-secure-vs-ap2/) - [Agent Payments Protocol vs Agentic Commerce Protocol](/compare/ap2-vs-agentic-commerce-protocol/) - [Universal Commerce Protocol vs Agentic Commerce Protocol](/compare/ucp-vs-agentic-commerce-protocol/) - [Agent Client Protocol vs Agentic Commerce Protocol](/compare/agent-client-protocol-vs-agentic-commerce-protocol/) - [x402 vs Agentic Commerce Protocol](/compare/x402-vs-agentic-commerce-protocol/) - [Agentic Commerce Protocol vs EMV Agentic Payments – Framework for Specifications](/compare/agentic-commerce-protocol-vs-emv-agentic-payments/) - [Verifiable Intent vs Agentic Commerce Protocol](/compare/vi-vs-agentic-commerce-protocol/) - [Agent Communication Protocol vs Agentic Commerce Protocol](/compare/agent-communication-protocol-vs-agentic-commerce-protocol/) - [Agent Connect Protocol (AGNTCY) vs Agentic Commerce Protocol](/compare/agent-connect-protocol-vs-agentic-commerce-protocol/) ## References - ACP is an interaction model and open standard maintained by OpenAI and Stripe, currently in beta, using date-based versioning; the 2026-04-17 release added Cart, Feed, Orders, authentication and MCP support. — [https://github.com/agentic-commerce-protocol/agentic-commerce-protocol](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol) (2026-04-17) VERIFIED - Governance: a Technical Steering Committee of up to 7 org seats; OpenAI and Stripe are Founding Maintainers with veto power exercised only against violations of five named principles (mission, neutrality, security, protocol integrity, considered decision-making). — [https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/docs/governance.md](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/docs/governance.md) VERIFIED - Meta has joined OpenAI and Stripe as a lead maintainer of the project. — [https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/MAINTAINERS.md](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/MAINTAINERS.md) VERIFIED - OpenAI publishes ACP-based Commerce documentation for building checkout flows in ChatGPT. — [https://developers.openai.com/commerce/](https://developers.openai.com/commerce/) REPORTED - Stripe publishes Agentic Commerce documentation implementing ACP for merchants. — [https://docs.stripe.com/agentic-commerce](https://docs.stripe.com/agentic-commerce) REPORTED [JSON](/data/protocols/agentic-commerce-protocol.json) · [Markdown](/protocols/agentic-commerce-protocol/index.md) · [OKF v0.2](/okf/protocols/agentic-commerce-protocol.md) --- # Agentic Mobile Protocol (AMP) Agentic Mobile Protocol (AMP) is an agentic-web standard (endpoint) at step 7, Pay, governed by Ant International; its status is "Described by Ant International as fully open-sourced at launch". It answers: "How can an AI agent shop and pay through a person's mobile wallet, within limits the person signed in advance, and have…?" Implementation status is shipping (Ant International), last verified 2026-10-23. ## Quick Wire Reference - **Step**: 7 Pay (Settle the bill) - **Version**: unversioned (no tags or releases; main branch) (2026-09-23) - **Status**: Described by Ant International as fully open-sourced at launch (2026-04-28)… - **Discovery / Probe Path**: none at an origin; mandates, payment tokens and assurance data pass between the agent, the… - **Spec URL**: https://github.com/ant-intl/AMP/blob/main/docs/Overview.md - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: A signed standing order on a mobile wallet, checked at every step of the payment [Pay](/category/pay/) AMP is Ant International's open protocol for AI agents that shop and pay through mobile wallets on the Alipay+ network [[1]](#ref-1)[[3]](#ref-3). The person signs a Mandate in advance, either IMMEDIATE (one purchase) or AUTONOMOUS (the agent may act later within limits) [[2]](#ref-2). An Intent Guard then checks each later step against that mandate [[1]](#ref-1). ## Overview The spec text names four checkpoints: mandate creation pre-verification, payment token, payment request and wallet debit (S1 to S4). It also defines three layers of assurance data (user identity, mandate authorization and payment token request), carried as a three-layer SD-JWT [[2]](#ref-2). The repository has five spec documents with MUST/SHOULD requirements, under Apache-2.0 [[1]](#ref-1). Ant International launched AMP on 2026-04-28, calling it fully open-sourced and citing 40+ wallet partners, 1.8 billion accounts and 150 million merchants [[3]](#ref-3). The public repository, however, was only created on 2026-08-17 and has no tags or releases [[1]](#ref-1). A global rollout with 50+ mobile payment partners was reported on 2026-09-11 [[4]](#ref-4). All adoption figures are Ant's own. AMP defines nothing at a merchant's origin, so there is no path to probe. It overlaps in purpose with AP2's mandates and the card networks' agent-payment schemes, but runs on wallet rails rather than cards. ## Discovery and probe none at an origin; mandates, payment tokens and assurance data pass between the agent, the wallet and the Alipay+ network ``` GET none — mandates and payment tokens are exchanged inside an authorised wallet flow parse: No public artefact at a fixed path to parse. on absent: Not probeable from an origin; check the merchant's or wallet's own announcement instead. ``` Not probed live: needs-credentials. AMP mandates and payment tokens are exchanged inside an authorised wallet flow; nothing is published at a fixed path. ## History - 2026-10-20 — added from gap scout 2026-10-20; verified against github.com/ant-intl/AMP (repo metadata, Overview.md, Intent Trust Domain.md) and Ant International's 2026-04-28 launch release; rollout via The Paypers ## Instances Verified SDKs, reference implementations & validators: - [ant-intl/AMP: specification and reference code (Apache-2.0)](https://github.com/ant-intl/AMP) · implementation (2026-10-20) Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Pairs with: [Agent Payments Protocol](/protocols/ap2/), [Visa Trusted Agent Protocol](/protocols/tap/), [Verifiable Intent](/protocols/vi/) - [Know Your Agent](/terms/know-your-agent/) - Not to be confused with: AMP (Accelerated Mobile Pages, Google's unrelated web page format) ## References - The ant-intl/AMP repository is Apache-2.0 licensed, created 2026-08-17 and last pushed 2026-09-23, with no tags or releases; its docs/ folder holds Overview, Intent Trust Domain, Payment Service Domain, Wallet Service Domain and Business Scenarios Processes documents written with MUST/SHOULD requirements. — [https://github.com/ant-intl/AMP](https://github.com/ant-intl/AMP) (2026-09-23) VERIFIED - The Intent Trust Domain document defines IMMEDIATE and AUTONOMOUS mandate types, four verification checkpoints (S1 Mandate Creation Pre-Verification, S2 Payment Token, S3 Payment Request, S4 Wallet Debit) and three layers of assurance data (L1 User Identity, L2 Mandate Authorization, L3 Payment Token Request) carried as a three-layer SD-JWT (RFC 9901, ES256). — [https://github.com/ant-intl/AMP/blob/main/docs/Intent%20Trust%20Domain.md](https://github.com/ant-intl/AMP/blob/main/docs/Intent%20Trust%20Domain.md) (2026-09-23) VERIFIED - Ant International's launch release (Kuala Lumpur, 2026-04-28) calls AMP fully open-sourced, cites 40+ wallet partners, 1.8 billion accounts and 150 million merchants, and says it supports nano-transactions as small as $0.000001. — [https://www.ant-intl.com/en/news/detail/?id=ant-international-launches-open-sourced-agentic-mobile-protocol-to-drive-ai-commerce](https://www.ant-intl.com/en/news/detail/?id=ant-international-launches-open-sourced-agentic-mobile-protocol-to-drive-ai-commerce) (2026-04-28) VERIFIED - The Paypers reports AMP's global rollout on 2026-09-11 with 50+ mobile payment partners and first-phase wallets including Alipay, GCash, DANA, KakaoPay and Toss. — [https://thepaypers.com/payments/news/ant-internationals-agentic-mobile-protocol-rolls-out-globally](https://thepaypers.com/payments/news/ant-internationals-agentic-mobile-protocol-rolls-out-globally) (2026-09-11) REPORTED [JSON](/data/protocols/amp-ant.json) · [Markdown](/protocols/amp-ant/index.md) · [OKF v0.2](/okf/protocols/amp-ant.md) --- # Agentic Real Time Framework (ARTF) Agentic Real Time Framework (ARTF) is an agentic-web standard (endpoint) at step 5, Act, governed by IAB Tech Lab; its status is "Final v1.0 specification, published after public comment". It answers: "How does a host advertising platform invoke a third party's agent service, deployed as a container inside its own…?" Implementation status is multi-implementation (IAB Tech Lab), last verified 2026-10-23. ## Quick Wire Reference - **Step**: 5 Act (Do something for me) - **Version**: v1.0 (2026-07-20) - **Status**: Final v1.0 specification, published after public comment; v2.0 development… - **Discovery / Probe Path**: http://{host}:{health-port}/health/ready — endpoint - **Spec URL**: https://github.com/IABTechLab/agentic-real-time-framework - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: a plugin/sidecar execution framework for real-time bidding -- closer to a… [Act](/category/act/) ARTF defines how a host advertising platform (an SSP or DSP) can let a third party's agent service run inside the host's own infrastructure -- packaged as a container -- and be called directly to mutate an OpenRTB bid request in real time: fraud detection, bid shading, audience augmentation, viewability scoring and similar tasks [[1]](#ref-1)[[2]](#ref-2). It is the execution/runtime layer of IAB Tech Lab's broader AAMP advertising-agent program (see the separate AAMP record), specifically the piece that answers "how does an agent invoke a capability inside someone else's system" -- which is why this record has been moved from the site's original 'account' placement to 'act.' The framework standardizes container runtime behavior, a gRPC RTBExtensionPoint.GetMutations service, an MCP tool (extend_rtb) as an alternative interface for AI agents, and Kubernetes-style health endpoints, all built on existing infrastructure primitives (Kubernetes, Docker, Protobuf, gRPC) rather than inventing new transport [[3]](#ref-3)[[4]](#ref-4). ## Overview What it does not do. ARTF does not define agent identity or authentication (containers run inside the host's own trusted network, with no external network access by default), does not standardize commercial terms or negotiation (that is AAMP's Agentic Direct/Deals-API layer), and does not itself provide an audit trail beyond whatever the host platform's own logging does. Current state. IAB Tech Lab opened public comment on ARTF v1.0 on 2025-11-13, closing 2026-01-15 [[1]](#ref-1). The finalized v1.0 specification and a Git tag were published 2026-07-20, with an accompanying Go reference implementation, and the project's own August 2026 recap describes v1.0 as already in production use by unnamed companies, several of whom helped design it, while adding a Rust reference implementation and cross-node orchestration; work on v2.0 was already underway at that point [[2]](#ref-2)[[3]](#ref-3)[[4]](#ref-4). Who implements it. IAB Tech Lab publishes an open-source Go reference server (gRPC + MCP + web UI + health checks) and, per the August 2026 post, a Rust reference implementation; the November 2025 launch quoted named ad-tech companies (Index Exchange, Chalice, The Trade Desk) describing implementation work, though none of those sources names a company as live in production as of the v1.0 release. Disputed / unknown. No independent, named list of production deployments exists in public sources; "used in production by a number of companies" is IAB Tech Lab's own claim, not something this site has measured. Because ARTF nodes are deployed inside a host's private infrastructure by design, there is no public origin to probe for adoption counting -- the probe above will almost always come back absent from the outside, which is expected behavior, not evidence of non-adoption. ## Discovery and probe endpoint · http://{host}:{health-port}/health/ready ``` GET http://{host}:8080/health/ready parse: HTTP 200 with the readiness handler's OK body indicates a running ARTF node (per internal/health in the Go reference implementation); a companion MCP tool 'extend_rtb' is exposed at {host}:8081/mcp and a gRPC RTBExtensionPoint.GetMutations service at port 50051. on absent: Connection refused or non-200 means no ARTF container is deployed at that host/port -- expected for the overwhelming majority of ad-tech origins, since ARTF nodes run inside a host platform's private infrastructure rather than being publicly addressable. ``` Not probed live: needs-credentials. ARTF containers run inside the host platform; the health endpoint is internal. ## History - 2026-09-05 — seeded from Exa Agent research run - 2026-09-06 — verified against iabtechlab.com/standards/artf/, the 2025-11-13 launch press release, the 2026-08-12 milestone post, and github.com/IABTechLab/agentic-real-time-framework (README, internal/health, cmd/agent/main.go); moved step from 'account' to 'act'; filled probe, discovery, adoption=claimed - 2026-10-16 — use-case tags (auto) ## Instances Verified SDKs, reference implementations & validators: - [IAB Tech Lab ARTF Go reference implementation](https://github.com/IABTechLab/agentic-real-time-framework) · implementation (2026-07-20) Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Builds on: [Model Context Protocol](/protocols/mcp/) - Pairs with: [Agentic Advertising Management Protocols](/protocols/aamp/), [Model Context Protocol](/protocols/mcp/), [Ad Context Protocol](/protocols/adcp/) ## Comparisons - [Ad Context Protocol vs Agentic Real Time Framework](/compare/adcp-vs-artf/) ## References - IAB Tech Lab announced ARTF v1.0 for public comment on 2025-11-13, open until 2026-01-15, describing a containerized architecture aiming to cut bid request/response time up to 80%; quotes from Index Exchange, Chalice and The Trade Desk describe early implementation work. — [https://iabtechlab.com/press-releases/iab-tech-lab-announces-agentic-rtb-framework-artf-v1-0-for-public-comment/](https://iabtechlab.com/press-releases/iab-tech-lab-announces-agentic-rtb-framework-artf-v1-0-for-public-comment/) (2025-11-13) VERIFIED - The standards page (last modified 2026-08-12) says public comment ran until 2026-01-15 and links to the finalized v1.0 specification and sample code repositories. — [https://iabtechlab.com/standards/artf/](https://iabtechlab.com/standards/artf/) (2026-08-12) VERIFIED - IAB Tech Lab's 2026-08-12 milestone post says v1.0 'is now being used in production by various companies, including several of the organizations that helped design it,' adds a Rust reference implementation and an orchestration layer for chaining ARTF nodes, and states that v2.0 work has already begun -- without naming which companies are in production. — [https://iabtechlab.com/a-milestone-for-the-agentic-advertising-ecosystem/](https://iabtechlab.com/a-milestone-for-the-agentic-advertising-ecosystem/) (2026-08-12) VERIFIED - The GitHub repository's v1.0 tag/release was published 2026-07-20; the Go reference implementation exposes gRPC (port 50051), an MCP server (port 50052, or /mcp on the web-UI port), a web UI (8081) and Kubernetes health endpoints at /health/live and /health/ready (port 8080, default). — [https://github.com/IABTechLab/agentic-real-time-framework](https://github.com/IABTechLab/agentic-real-time-framework) (2026-07-20) VERIFIED [JSON](/data/protocols/artf.json) · [Markdown](/protocols/artf/index.md) · [OKF v0.2](/okf/protocols/artf.md) --- # Agentic Resource Discovery (ARD · /.well-known/ard.json) Agentic Resource Discovery (ARD) is an agentic-web standard (well-known file — /.well-known/ard.json) at step 1, Discover, authored by individuals at Google, Microsoft and Hugging Face; its status is "Proposal". It answers: "Where are an organization's discoverable agentic resources (MCP servers, A2A agents, skills, registries), and how can…?" Replacing or extending sitemap plus a search engine index, implementation status is multi-implementation (observed on 26/1226 probed origins), last verified 2026-10-23. ## Quick Wire Reference - **Step**: 1 Discover (What is here, and where?) - **Version**: v0.91 (2026-08-26) - **Status**: Proposal · multi-implementation - **Discovery / Probe Path**: /.well-known/ard.json — well-known manifest, robots.txt Agentmap directive, HTML tag, DNS SVCB records, or in-page markup; the manifest path is /.well-known/ard.json [[1]](#ref-1). A significant correction to earlier internal notes: the v0.91 text makes /.well-known/ard.json the canonical path and explicitly demotes the older /.well-known/ai-catalog.json path (and the ai-catalog link relation) to an optional predecessor that a conformant consumer is not required to consult [[1]](#ref-1). Prior assumptions that ai-catalog.json was still canonical as of this version are wrong as of the text fetched 2026-09-06. ARD does not define a signing or authentication scheme of its own (it defers to whatever trust framework a publisher's trustManifest declares), does not constrain artifact-specific schemas (MCP, A2A, etc. remain external), and does not define a normative way to fetch a full entry by identifier from a search result [[1]](#ref-1). Implementation exists: AGNTCY's Agent Directory Service explicitly serves /.well-known/ai-catalog.json and can export records into a2a, mcp, oasf and agent-skill formats, functioning as one real ARD-manifest-compatible implementation [[3]](#ref-3). Beyond that, adoption is thin and lagging the spec's own migration: a probe of 50 domains run by this site's publisher (agenticresources) on 2026-09-04 found 31 serving some manifest, all 31 still on the deprecated ai-catalog.json path, and only 6 of those also serving the new ard.json path [[4]](#ref-4) -- meaning the observed deployment base predates this very revision's path rename. Because that probe artifact is not present in this repository, adoption here is recorded as "observed" rather than "measured". What is disputed or unknown: whether the ecosystem migrates to ard.json before a competing discovery mechanism (DNS-AID, AID, ADP) becomes the practical default; whether any registry beyond ADS has implemented the POST /search and POST /explore REST surface this spec mandates; and how the optional trustManifest verification step will be operationalized across publishers who have never coordinated on a trust framework. The record ai-catalog-well-known-file, which previously modelled the manifest file as a separate entity, has been folded into this record: it described the same well-known artifact that this specification now supersedes with ard.json, and keeping it separate obscured that the two are one lineage, not two competing formats. ## Discovery and probe well-known manifest, robots.txt Agentmap directive, HTML , DNS SVCB, in-page JSON-LD · /.well-known/ard.json ``` GET https://{origin}/.well-known/ard.json parse: 200 response is JSON with a top-level "entries" array of ARD entries (each with identifier/displayName/type/url-or-data); a consumer MAY also check the predecessor /.well-known/ai-catalog.json and an HTML tag on absent: Domain publishes no ARD manifest at the current canonical path; it may still publish at the deprecated predecessor path /.well-known/ai-catalog.json, which conformant consumers are not required to consult ``` Live check run by [the MCP probe](/mcp/server-card): GET /.well-known/ard.json. An ARD manifest is JSON with a top-level entries array. ``` { "path": "/.well-known/ard.json", "expect": { "json_keys": [ "entries" ] }, "note": "An ARD manifest is JSON with a top-level entries array." } ``` ## History - 2026-09-05 — seeded from Exa Agent research run - 2026-09-06 — verified against ARD v0.91 spec text (raw.githubusercontent.com/ards-project/ard-spec/main/spec/ard.md); corrected canonical path from ai-catalog.json to ard.json; folded ai-catalog-well-known-file into this record - 2026-10-16 — use-case tags (auto) ## Instances - [Zuplo API Gateway (zuplo.com)](https://zuplo.com/) · Observed 2026-10-25 · origin - [Warp Agentic Terminal (warp.dev)](https://warp.dev/) · Observed 2026-10-25 · origin - [Supabase (supabase.com)](https://supabase.com/) · Observed 2026-10-25 · origin - [Scalar API Platform (scalar.com)](https://scalar.com/) · Observed 2026-10-25 · origin - [Pydantic & Logfire (pydantic.dev)](https://pydantic.dev/) · Observed 2026-10-25 · origin - [Publica.la (publica.la)](https://publica.la/) · Observed 2026-10-25 · origin - [Proof API (api.proof.com)](https://api.proof.com/.well-known/ard.json) · Observed 2026-10-25 · origin - [Infisical Secrets Management (infisical.com)](https://infisical.com/) · Observed 2026-10-25 · origin - [Fly.io (fly.io)](https://fly.io/) · Observed 2026-10-25 · origin - [Eodly (eodly.io)](https://eodly.io/) · Observed 2026-10-25 · origin - [Desvela (desvela.dev)](https://desvela.dev/) · Observed 2026-10-25 · origin - [Bird (bird.com)](https://bird.com/) · Observed 2026-10-25 · origin - [Arcade AI Tool-Calling Runtime (arcade.dev)](https://arcade.dev/) · Observed 2026-10-25 · origin - [Salespeak B2B Buyer Concierge Agent](https://salespeak.ai) · Observed 2026-10-23 · agent - [Railway (railway.com)](https://railway.com/) · Observed 2026-10-23 · origin - [Neuronto Agentic Web Index](https://neuronto.com) · Observed 2026-10-23 · venue - [agenticweb.wiki Reference Agent and MCP Server](https://agenticweb.wiki) · Observed 2026-10-23 · agent - [Agentic Resources (agenticresources.dev)](https://agenticresources.dev/) · Observed 2026-10-23 · origin Every instance with its source is listed on the [instances page](/instances/). Verified SDKs, reference implementations & validators: - [AGNTCY Agent Directory Service (ai-catalog.json export/import)](https://datatracker.ietf.org/doc/html/draft-mp-agntcy-ads-02) · implementation (2026-07-06) - [ARD official conformance-test CLI (manifest, publisher-resolution, and registry-validation modes)](https://raw.githubusercontent.com/ards-project/ard-spec/main/spec/ard.md) · validator (2026-08-26) Our probe: seen on 26 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Component: [AI Catalog well-known file](/protocols/ai-catalog-well-known-file/) - Depended on by: [ERC-8444: Agentic Resource Discovery (ARD) Onchain](/protocols/erc-8444/) - Pairs with: [Model Context Protocol](/protocols/mcp/), [Agent2Agent Protocol](/protocols/a2a/), [Agent Directory Service](/protocols/ads/), [DNS for AI Discovery](/protocols/dns-aid/), [Agent Identity and Discovery](/protocols/aid/), [api-catalog: A Well-Known URI and Link Relation to Help Discovery of APIs](/protocols/api-catalog-rfc9727/) - [MCP Server Card](/terms/server-card/) - [Well-known URI](/terms/well-known/) - [Agentmap directive](/terms/agentmap/) - [Agentic web](/terms/agentic-web/) - [API Catalog (RFC 9727)](/terms/api-catalog/) - [Agentic Resource Discovery (ARD) manifest](/terms/ard-manifest/) - [AI agent](/terms/ai-agent/) - Scanners & registries: [ardvark](https://ardvark.no/), [Neuronto ARD publisher list](https://neuronto.com/ard-publishers) - Not to be confused with: ARDP (Agent Registration and Discovery Protocol, unrelated IETF draft), AIR (the urn:air: identifier namespace this spec defines is sometimes referred to standalone) ## Comparisons - [sitemap.xml vs llms.txt & ARD (classic vs agentic)](/compare/sitemap-xml-vs-llms-txt/) - [Agentic Resource Discovery vs llms.txt](/compare/ard-vs-llms-txt/) - [Agentic Resource Discovery vs api-catalog: A Well-Known URI and Link Relation to Help Discovery of APIs](/compare/ard-vs-api-catalog-rfc9727/) - [Agentic Resource Discovery vs AI Catalog well-known file](/compare/ard-vs-ai-catalog-well-known-file/) - [MCP Server Cards (SEP-2127) vs Agentic Resource Discovery](/compare/mcp-server-cards-vs-ard/) - [agents.json vs Agentic Resource Discovery](/compare/agents-json-vs-ard/) - [Agentic Resource Discovery vs Official MCP Registry](/compare/ard-vs-mcp-registry/) - [Agentic Resource Discovery vs agents.txt](/compare/ard-vs-agents-txt/) - [Agentic Resource Discovery vs ERC-8444: Agentic Resource Discovery (ARD) Onchain](/compare/ard-vs-erc-8444/) - [Open Agentic Schema Framework vs Agentic Resource Discovery](/compare/oasf-vs-ard/) ## References - ARD v0.91 (26 Aug 2026), authored by Google/Microsoft/Hugging Face individuals, defines the ARD entry as a JSON-LD node and moves the canonical manifest path to /.well-known/ard.json, explicitly naming /.well-known/ai-catalog.json as the deprecated predecessor path that consumers MAY but need not consult. — [https://raw.githubusercontent.com/ards-project/ard-spec/main/spec/ard.md](https://raw.githubusercontent.com/ards-project/ard-spec/main/spec/ard.md) (2026-08-26) VERIFIED - Google announced the Agentic Resource Discovery Specification and directed publishers to a well-known catalog mechanism. — [https://developers.googleblog.com/en/announcing-the-agentic-resource-discovery-specification/](https://developers.googleblog.com/en/announcing-the-agentic-resource-discovery-specification/) (2026-06-17) REPORTED - AGNTCY's Agent Directory Service (ADS) implements AI Catalog interoperability, serving /.well-known/ai-catalog.json and exporting records to a2a/mcp/oasf formats -- one real implementation of the ARD manifest side. — [https://datatracker.ietf.org/doc/html/draft-mp-agntcy-ads-02](https://datatracker.ietf.org/doc/html/draft-mp-agntcy-ads-02) (2026-07-06) VERIFIED - A probe of 50 domains run by this site's publisher (agenticresources) on 2026-09-04 found 31 serving a manifest, all 31 on the predecessor ai-catalog.json path, and only 6 of those also on the new ard.json path -- i.e. the ecosystem has not yet moved to the canonical path this v0.91 revision defines. — [https://agenticresources.dev/](https://agenticresources.dev/) (2026-09-04) REPORTED Disputed: The path this specification calls canonical has changed between revisions and prior internal notes got this backwards: v0.91 (26 Aug 2026) makes /.well-known/ard.json canonical and demotes /.well-known/ai-catalog.json to an optional, non-required-to-consult predecessor path. Our own probe (2026-09-04, prior to this verification) found the entire observed deployment base still on the old ai-catalog.json path, with only 6 of 31 also serving the new path -- so real-world adoption lags the spec text by at least one full path rename. Adoption level is left as "observed" rather than "measured" here because no probe-run artifact exists inside this repository (data/) to cite by filename; the probe that produced the 31/50 figure lives in the sibling agenticresources.dev project. [JSON](/data/protocols/ard.json) · [Markdown](/protocols/ard/index.md) · [OKF v0.2](/okf/protocols/ard.md) --- # agents.json (/.well-known/agents.json) agents.json is an agentic-web standard (well-known file — /.well-known/agents.json) at step 5, Act, governed by Wildcard AI; its status is "Dormant: last push 2025-08-21, version 0.1.3". It answers: "How does an agent learn which multi-step API call sequences ("flows") a service supports, on top of its raw OpenAPI surface?" Implementation status is prototype (observed on 2/1226 probed origins), last verified 2026-10-25. ## Quick Wire Reference - **Step**: 5 Act (Do something for me) - **Version**: 0.1.0 (spec; Bridge SDK 0.1.3) (2025-03) - **Status**: Dormant: last push 2025-08-21, version 0.1.3 · prototype - **Discovery / Probe Path**: /.well-known/agents.json — Proposed well-known path, though the spec itself notes providers… - **Spec URL**: https://github.com/wild-card-ai/agents-json - **Last Verified**: 2026-10-25 (current) - **Classic Web Analog**: an OpenAPI/Swagger spec, extended with the multi-call recipes a human developer… [Act](/category/act/) Moved from the Read step to Act. agents.json is Wildcard AI's specification for describing multi-step API call sequences ("flows") for LLM agents, built as an extension of OpenAPI rather than a competitor to it [[1]](#ref-1). It belongs under "Act" (do something for me), not "Read": its own FAQ explicitly contrasts it with llms.txt — "llms.txt ... doesn't address the challenges of taking structured actions ... agents.json enables them to execute multi-step workflows reliably" [[1]](#ref-1). It was included in this batch as a read-step candidate but is a discovery-plus-invocation spec for API actions, so it is reported here with a corrected step rather than filed under Read. ## Overview What it is: a JSON document, structurally an annotated OpenAPI spec, adding two concepts — flows (a named sequence of one or more API calls that accomplishes an outcome) and links (how the output of one call feeds the input of the next) — so an agent doesn't have to infer multi-call sequences (e.g., "search Gmail threads, list messages in a thread, reply with base64 RFC 822 content") from raw endpoint descriptions alone [[1]](#ref-1). It proposes, but does not require, publishing the file at /.well-known/agents.json, and maintains a discretionary registry of published files at wild-card.ai/registry [[1]](#ref-1) (not independently verified in this pass). The reference runtime, "Wildcard Bridge", is a Python package that loads an agents.json file and executes the described flows with Basic/ApiKey/Bearer auth [[1]](#ref-1). What it does not do: it is explicitly stateless — orchestration and context are the calling agent's responsibility, not the spec's — and it does not define a serving protocol beyond "an agent fetches this JSON document" [[1]](#ref-1). It is single-vendor: Wildcard AI controls the spec text, the only public runtime implementation, and the registry. Current state: version 0.1.0, first shown publicly in a March 2025 Hacker News post [[3]](#ref-3), with the GitHub repository still receiving commits as of August 2026 [[2]](#ref-2). No changelog entry or version bump beyond 0.1.0 was found during this pass, and no independent (non-Wildcard) implementation of the spec or the registry was located. What is disputed or unknown: adoption beyond Wildcard's own quickstart examples (Resend, Stripe, Rootly, Twitter+Giphy, and a Resend+Hubspot+Google Sheets demo) is unmeasured; there is no evidence of provider-side publication of agents.json files outside Wildcard's own demos, and the well-known path is explicitly optional per the spec's own FAQ, so counting adoption by well-known-path presence alone would understate or misstate real usage. ## Discovery and probe Proposed well-known path, though the spec itself notes providers can maintain files without adopting the path; a discretionary third-party registry also exists · /.well-known/agents.json (proposed; not mandatory, per the spec's own FAQ) ``` GET {origin}/.well-known/agents.json parse: 200 response with a JSON body extending an OpenAPI document with `flows` and `links` fields on absent: No agents.json at the well-known path; the provider may still have one published in Wildcard's registry or elsewhere, since the path is a proposal, not a requirement ``` Live check run by [the MCP probe](/mcp/server-card): GET /.well-known/agents.json. agents.json extends OpenAPI with a flows field. ``` { "path": "/.well-known/agents.json", "expect": { "json_keys": [ "flows" ] }, "note": "agents.json extends OpenAPI with a flows field." } ``` ## History - 2026-09-06 — new record added during read-step verification; reclassified to the act step and verified against the wild-card-ai/agents-json README and repository metadata - 2026-10-16 — agents.json is dormant: last push 2025-08-21, version 0.1.0 - 2026-10-16 — use-case tags (auto) - 2026-10-16 — version resend (watcher) - 2026-10-16 — No push since 2025-08-21 (over 180 days) - 2026-10-16 — version label restored to '0.1.0'; the repository's latest tag (resend) is a package, SDK or build tag, not the specification version, so the GitHub watch no longer drives version - 2026-10-20 — collision with the unrelated agents.json format served by Zapier and Cloudflare recorded - 2026-10-25 — version updated to 0.1.3 (latest specification release prior to repository dormancy on 2025-08-21) ## Instances - [2s.io](https://2s.io/) · Observed 2026-10-25 · origin - [agent-ready.dev Conformance Scanner Agent](https://agent-ready.dev) · Observed 2026-10-23 · agent - [Wildcard Bridge Reference Agents (Stripe, Resend, Rootly, Sheets)](https://wild-card.ai) · Recorded 2026-09-06 · agent Every instance with its source is listed on the [instances page](/instances/). Verified SDKs, reference implementations & validators: - [Wildcard Bridge Python package](https://github.com/wild-card-ai/agents-json) · sdk (2026-08) Our probe: seen on 2 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Pairs with: [Model Context Protocol](/protocols/mcp/), [llms.txt](/protocols/llms-txt/), [api-catalog: A Well-Known URI and Link Relation to Help Discovery of APIs](/protocols/api-catalog-rfc9727/), [AGENTS.md](/protocols/agents-md/), [AI Catalog well-known file](/protocols/ai-catalog-well-known-file/), [Ad Context Protocol](/protocols/adcp/) - Scanners & registries: [Agents Welcome — Agent Protocol Atlas](https://agentswelcome.dev/protocols) - Not to be confused with: agents.md (unrelated coding-agent instructions file), agent.json / agentfile.json (various unrelated agent-config conventions used by other frameworks), an unrelated /.well-known/agents.json format with an agents[] list (seen at zapier.com and cloudflare.com, 2026-10-20), not Wildcard's OpenAPI + flows file ## Comparisons - [sitemap.xml vs llms.txt & ARD (classic vs agentic)](/compare/sitemap-xml-vs-llms-txt/) - [agents.json vs Agentic Resource Discovery](/compare/agents-json-vs-ard/) - [Model Context Protocol vs agents.json](/compare/mcp-vs-agents-json/) - [WebMCP vs agents.json](/compare/webmcp-vs-agents-json/) ## References - agents.json is an OpenAPI-based specification (current version 0.1.0) adding `flows` (multi-call contracts) and `links` (how calls chain together) on top of an existing OpenAPI document; it proposes but does not mandate `/.well-known/agents.json`; and the maintainers explicitly distinguish it from MCP (stateless vs. MCP's stateful connections) and from llms.txt ("llms.txt ... doesn't address the challenges of taking structured actions") — [https://raw.githubusercontent.com/wild-card-ai/agents-json/master/README.md](https://raw.githubusercontent.com/wild-card-ai/agents-json/master/README.md) (2026) VERIFIED - The wild-card-ai/agents-json GitHub repository was created 2025-01-30 and last pushed 2026-08-25 — [https://github.com/wild-card-ai/agents-json](https://github.com/wild-card-ai/agents-json) (2026-08-25) VERIFIED - The spec was publicly announced via a March 2025 'Show HN' post positioning it as an OpenAPI specification for LLMs — [https://news.ycombinator.com/item?id=43243893](https://news.ycombinator.com/item?id=43243893) (2025-03) REPORTED - agents.json is dormant: last push 2025-08-21, version 0.1.0 — [https://github.com/wild-card-ai/agents-json](https://github.com/wild-card-ai/agents-json) (2025-08-21) VERIFIED - resend released 2025-02-09 — [https://github.com/wild-card-ai/agents-json/releases/tag/resend](https://github.com/wild-card-ai/agents-json/releases/tag/resend) (2025-02-09) VERIFIED - No push since 2025-08-21 (over 180 days) — [https://github.com/wild-card-ai/agents-json/releases/tag/resend](https://github.com/wild-card-ai/agents-json/releases/tag/resend) (2025-02-09) REPORTED [JSON](/data/protocols/agents-json.json) · [Markdown](/protocols/agents-json/index.md) · [OKF v0.2](/okf/protocols/agents-json.md) --- # AGENTS.md (/AGENTS.md) AGENTS.md is an agentic-web standard (well-known file — /AGENTS.md) at step 4, Read, governed by Agentic AI Foundation, a Linux Foundation project; its status is "An open format... regardless of which coding agent you use". It answers: "What build, test, and convention instructions should a coding agent follow in this repository?" Implementation status is multi-implementation (agents.md; observed on 28/1226 probed origins), last verified 2026-10-23. ## Quick Wire Reference - **Step**: 4 Read (Give me the content) - **Version**: current site guidance (living document) (2026-09) - **Status**: "An open format... regardless of which coding agent you use"; explicitly not… - **Discovery / Probe Path**: /AGENTS.md — Fixed filename at a repository's root; agents read the nearest AGENTS.md… - **Spec URL**: https://agents.md - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: CONTRIBUTING.md / a repository's contributor instructions, but written for an agent… [Read](/category/read/) AGENTS.md is an open convention for a markdown file placed at a repository's root (or nested inside subpackages) that gives coding agents the operational context a human-facing README would clutter: build and test commands, code-style rules, security considerations, and PR conventions [[1]](#ref-1). It complements, rather than replaces, README.md: the README stays focused on human contributors while AGENTS.md carries agent-specific detail [[1]](#ref-1). ## Overview It solves the problem of giving many different coding agents — Codex, Claude Code, Cursor, Copilot, and dozens of others — one predictable, tool-agnostic place to find per-repository instructions, instead of every vendor inventing its own proprietary rules file (.cursorrules, CLAUDE.md, etc., some of which are still separately supported alongside it). It has no required fields or schema: "AGENTS.md is just standard Markdown. Use any headings you like; the agent simply parses the text you provide" [[1]](#ref-1). In a monorepo, nested AGENTS.md files are supported and the closest file to the edited path wins, letting each subproject carry tailored instructions; the OpenAI repository itself reportedly has 88 such files [[1]](#ref-1). It does not enforce anything: whether an agent actually runs the test commands it lists is a matter of each tool's own behavior, and explicit user chat instructions always override the file's contents [[1]](#ref-1). It is not a machine-readable manifest (no capability declarations, no discovery well-known path) — it is read as freeform prose, closer to documentation than to a protocol. Current state: the format launched in August 2025, originating from OpenAI's Codex team working with Amp, Google's Jules, Cursor, and Factory [[1]](#ref-1)[[2]](#ref-2)[[3]](#ref-3). As of this verification (September 2026) it is stewarded by the Agentic AI Foundation (AAIF), a Linux Foundation project, and is supported by more than two dozen coding tools and agents, including several that also support a proprietary rules file of their own alongside it (Zed, Windsurf, RooCode, Kilo Code, opencode) [[1]](#ref-1). The project's own site claims over 60,000 AGENTS.md files exist across public, non-fork, non-archived GitHub repositories, based on a GitHub code search rather than an independent crawl [[1]](#ref-1). What is disputed or unknown: the 60,000+ figure is a claim by the format's own stewards, not an independently reproduced count, and no third-party adoption study analogous to the llms.txt Tranco studies was found during this verification. It is also unclear how much of AAIF's governance is substantive versus a naming step shortly after Linux Foundation involvement was announced (2026), since the specification text itself has not visibly changed in structure since the original release. ## Discovery and probe Fixed filename at a repository's root; agents read the nearest AGENTS.md up the directory tree from the file being edited, so a nested file in a monorepo package takes precedence over the root file · AGENTS.md ``` GET {origin}/AGENTS.md (repository-root fetch, e.g. raw.githubusercontent.com///HEAD/AGENTS.md) parse: 200 response containing markdown text; presence alone is the signal since there are no required fields or schema on absent: No repository-level agent instructions are declared; an agent falls back to inferring conventions from the codebase or README ``` Live check run by [the MCP probe](/mcp/server-card): GET /AGENTS.md. AGENTS.md is a Markdown briefing at /AGENTS.md; at least one Markdown heading (# ...) is required so plain-text error stubs do not match. ``` { "path": "/AGENTS.md", "expect": { "text_match": "(?m)^#{1,6}\\s+\\S" }, "note": "AGENTS.md is a Markdown briefing at /AGENTS.md; at least one Markdown heading (# ...) is required so plain-text error stubs do not match." } ``` ## History - 2026-09-05 — seeded from Exa Agent research run - 2026-09-06 — verified against agents.md, OpenAI's harness-engineering post, and a secondary account of the August 2025 launch - 2026-10-16 — use-case tags (auto) ## Instances - [Zapier (zapier.com)](https://zapier.com/) · Observed 2026-10-25 · origin - [Webflow Developers (developers.webflow.com)](https://developers.webflow.com/) · Observed 2026-10-25 · origin - [Perplexity API Docs (docs.perplexity.ai)](https://docs.perplexity.ai/) · Observed 2026-10-25 · origin - [MetricSpot (metricspot.com)](https://metricspot.com/) · Observed 2026-10-25 · origin - [Fly.io (fly.io)](https://fly.io/) · Observed 2026-10-25 · origin - [DC Hub (dchub.cloud)](https://dchub.cloud/) · Observed 2026-10-25 · origin - [Attio Docs (docs.attio.com)](https://docs.attio.com/) · Observed 2026-10-25 · origin - [Ad Context Protocol Docs (docs.adcontextprotocol.org)](https://docs.adcontextprotocol.org/) · Observed 2026-10-25 · origin - [Tempo (tempo.xyz)](https://tempo.xyz/) · Observed 2026-10-23 · origin - [Telnyx (telnyx.com)](https://telnyx.com/) · Observed 2026-10-23 · origin - [Railway (railway.com)](https://railway.com/) · Observed 2026-10-23 · origin - [QuickNode (quicknode.com)](https://quicknode.com/) · Observed 2026-10-23 · origin - [n8n Documentation Origin (docs.n8n.io)](https://docs.n8n.io/) · Observed 2026-10-23 · origin - [Apify (apify.com)](https://apify.com/) · Observed 2026-10-23 · origin - [agenticweb.wiki Reference Agent and MCP Server](https://agenticweb.wiki) · Observed 2026-10-23 · agent - [agent-ready.dev Conformance Scanner Agent](https://agent-ready.dev) · Observed 2026-10-23 · agent - [Windsurf (Cognition)](https://docs.windsurf.com) · Observed 2026-08-29 · harness - [OpenCode](https://opencode.ai) · Observed 2026-08-29 · harness - [OpenAI Codex and ChatGPT Connectors](https://developers.openai.com) · Observed 2026-08-29 · harness - [Goose (Block)](https://github.com/block/goose) · Observed 2026-08-29 · harness - [Google Jules](https://jules.google) · Observed 2026-08-29 · harness - [GitHub Copilot Coding Agent](https://docs.github.com/en/copilot/how-tos/use-copilot-agents/coding-agent/create-custom-agents) · Observed 2026-08-29 · harness - [Devin (Cognition)](https://devin.ai) · Observed 2026-08-29 · harness - [Cursor](https://cursor.com) · Observed 2026-08-29 · harness - [Amp](https://ampcode.com) · Observed 2026-08-29 · harness - [Aider](https://aider.chat/docs/usage/conventions.html) · Observed 2026-08-29 · harness Every instance with its source is listed on the [instances page](/instances/). Verified SDKs, reference implementations & validators: - [OpenAI Codex](https://openai.com/codex/) · implementation (2026) - [Amp](https://ampcode.com/) · implementation (2026) - [Google Jules](https://jules.google/) · implementation (2026) - [Cursor](https://cursor.com/) · implementation (2026) - [Factory](https://factory.com/) · implementation (2026) Our probe: seen on 28 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Pairs with: [llms.txt](/protocols/llms-txt/), [Model Context Protocol](/protocols/mcp/), [Agent Skills](/protocols/anthropic-agent-skills-format/), [Open Knowledge Format](/protocols/okf/), [Agent Context Interchange Protocol](/protocols/acip/), [Agent Readability Spec](/protocols/vercel-agent-readability/) - [Coding agent instruction files](/terms/coding-agent-instructions/) - Scanners & registries: [CrawlIndex](https://crawlindex.org/) - Not to be confused with: AGENT.md (legacy pre-merge filename some tools symlink for backward compatibility) ## Comparisons - [HTML DOM & RSS vs Accept: text/markdown & OKF (classic vs agentic)](/compare/html-dom-vs-markdown-for-agents/) - [llms.txt vs AGENTS.md](/compare/llms-txt-vs-agents-md/) - [AGENTS.md vs agents.txt](/compare/agents-md-vs-agents-txt/) - [Open Knowledge Format vs AGENTS.md](/compare/okf-vs-agents-md/) - [Agent Readability Spec vs AGENTS.md](/compare/vercel-agent-readability-vs-agents-md/) - [Agent Skills vs AGENTS.md](/compare/anthropic-agent-skills-format-vs-agents-md/) ## References - Full AGENTS.md rationale, format (no required fields, closest-file-wins precedence), FAQ, migration guidance, and current list of 25+ adopting tools (Codex, Amp, Jules, Cursor, Factory, Devin, Aider, goose, Ona, VS Code, Zed, Windsurf, GitHub Copilot coding agent, Warp, Junie, RooCode, Phoenix, Augment Code, Kilo Code, opencode, and more). "AGENTS.md is now stewarded by the Agentic AI Foundation under the Linux Foundation". — [https://agents.md](https://agents.md) (2026-09) VERIFIED - AGENTS.md was released by OpenAI in August 2025, emerging from collaboration across OpenAI Codex, Amp, Jules (Google), Cursor, and Factory — [https://blog.stackademic.com/agents-md-the-readme-your-ai-coding-agent-actually-reads-e634b7e2de34](https://blog.stackademic.com/agents-md-the-readme-your-ai-coding-agent-actually-reads-e634b7e2de34) (2026) REPORTED - OpenAI's own harness-engineering writeup for the Codex repository references "the initial AGENTS.md file that directs agents how to work in" the repo, corroborating OpenAI's originating role — [https://openai.com/index/harness-engineering/](https://openai.com/index/harness-engineering/) (2026) REPORTED [JSON](/data/protocols/agents-md.json) · [Markdown](/protocols/agents-md/index.md) · [OKF v0.2](/okf/protocols/agents-md.md) --- # agents.txt (/agents.txt) agents.txt is an agentic-web standard (well-known file — /agents.txt) at step 1, Discover, governed by None; its status is "An open standard proposal for declaring what AI agents can do…". It answers: "Which agent-facing protocols (payments, auth, MCP, skills, A2A) does this site speak, and where?" Implementation status is prototype (observed on 4/1226 probed origins), last verified 2026-10-23. ## Quick Wire Reference - **Step**: 1 Discover (What is here, and where?) - **Version**: agents-txt.com: v1.0; competing proposals carry no shared version - **Status**: "An open standard proposal for declaring what AI agents can do on a website"… - **Discovery / Probe Path**: /agents.txt — Fixed filename at the site root - **Spec URL**: https://agents-txt.com/spec - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: robots.txt, but declaring which agent protocols a site supports rather than which… [Discover](/category/discover/) Moved from the Read step to Discover. agents.txt is not one specification but a name shared by at least four non-converging proposals for a site-root text file that declares which agent-facing protocols (payments, auth, MCP endpoints, Skills, A2A) a site supports and where to find them [[1]](#ref-1)[[2]](#ref-2)[[3]](#ref-3)[[4]](#ref-4). It is filed here under "Discover" (what is here, and where?) rather than "Read", since every version found declares protocol/capability presence and location, not page content, and one variant (agents-txt.com) explicitly frames itself as complementary to A2A's AgentCard discovery and RFC 9727's API Catalog [[1]](#ref-1). ## Overview What it is (per the most detailed version found, agents-txt.com's v1.0): a plain-text file at the site root listing supported protocols, e.g. Protocols: x402, mpp, with directives for pointing agents at an A2A AgentCard, an MCP endpoint, or other machine-readable capability declarations [[1]](#ref-1). A second, independently maintained proposal (kaylacar/agents-txt) describes a similar but not identical capability-declaration format and claims IANA filing (#72/#73, "under review") and an active IETF Internet-Draft [[2]](#ref-2). A third effort, agentstxt.dev, is reported by a Mastercard developer-documentation page to have had its IETF draft expire on 2026-04-10, with that same source describing "a fragmented landscape with 11+ competing proposals ... no ratified standard" [[3]](#ref-3). A fourth, academic proposal in the arXiv paper "Towards an Agent-First Web" defines yet another agents.txt grammar (INI-style [agent-class] blocks with allow/rate-limit/content-format fields) without referencing any of the other three [[4]](#ref-4). It solves, in principle, the problem of an agent needing to discover a site's supported protocols in one request rather than probing each well-known path individually — a genuine gap, since A2A, MCP, x402, and other protocols each define their own discovery convention but nothing ties them together at a single site level. It does not currently solve that problem in practice, because there is no single agents.txt to fetch: an agent cannot know, without trying multiple grammars, which of at least four incompatible conventions (if any) a given site implements. None of the identified efforts has IETF ratification, and the one with the most third-party visibility (agentstxt.dev) had its own draft lapse. Current state, as of this verification (September 2026): earliest dated public artifact found is the kaylacar/agents-txt GitHub repository, created 2026-02-22 and last updated 2026-07-18 [[2]](#ref-2); agents-txt.com presents a v1.0 spec text with no stated publication date [[1]](#ref-1); the Mastercard reference page's fragmentation characterization is dated to 2026 without a specific day [[3]](#ref-3). No implementation count, adopter list, or resolution among the competing proposals was found. What is disputed: everything about precedence, authorship, and which (if any) proposal will consolidate the space. This record should be treated as thin pending a resolution or a dominant implementation emerging. ## Discovery and probe Fixed filename at the site root · /agents.txt (well-known root path per all identified proposals; one proposal also allows /.well-known/agents.txt) ``` GET {origin}/agents.txt parse: 200 response with a text/plain body listing supported protocols (e.g. `Protocols: x402, mpp`) or per-agent directives, per whichever competing grammar the site chose to implement on absent: No agents.txt at the site root under any of the competing conventions; given the fragmentation, absence is a weak signal either way ``` Live check run by [the MCP probe](/mcp/server-card): GET /agents.txt. agents.txt must contain robots-style or key-value directives (User-agent:, Agent:, Allow:, Disallow:, Endpoint:, Sitemap:, Policy:) or an # agents.txt header at /agents.txt, not a redirected documentation page. ``` { "path": "/agents.txt", "expect": { "text_match": "(?im)^(user-agent|agent|allow|disallow|endpoint|sitemap|policy|auth|rate-limit|crawl-delay)\\s*:|^#\\s*agents\\.txt\\b" }, "note": "agents.txt must contain robots-style or key-value directives (User-agent:, Agent:, Allow:, Disallow:, Endpoint:, Sitemap:, Policy:) or an # agents.txt header at /agents.txt, not a redirected documentation page." } ``` ## History - 2026-09-06 — new record added during read-step verification; reclassified to the discover step after finding the name covers multiple non-converging, competing specifications - 2026-10-16 — use-case tags (auto) ## Instances - [MetricSpot (metricspot.com)](https://metricspot.com/) · Observed 2026-10-25 · origin - [Lago (getlago.com)](https://getlago.com/) · Observed 2026-10-25 · origin - [Dreaming Press (dreaming.press)](https://dreaming.press/) · Observed 2026-10-23 · origin - [Agentic AI Foundation (aaif.io)](https://aaif.io/) · Observed 2026-10-23 · origin Every instance with its source is listed on the [instances page](/instances/). Our probe: seen on 4 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Pairs with: [Agent2Agent Protocol](/protocols/a2a/), [Model Context Protocol](/protocols/mcp/), [x402](/protocols/x402/), [api-catalog: A Well-Known URI and Link Relation to Help Discovery of APIs](/protocols/api-catalog-rfc9727/), [llms.txt](/protocols/llms-txt/), [auth.md](/protocols/auth-md/) - Not to be confused with: Multiple unrelated, mutually incompatible specifications share the "agents.txt" name (see dispute): agents-txt.com's v1.0 protocol-declaration format, kaylacar/agents-txt's IETF-draft capability-declaration proposal, agentstxt.dev (a separate proposal whose IETF draft expired 2026-04-10), and the ad hoc allow/rate-limit format described in the arXiv paper 'Towards an Agent-First Web' ## Comparisons - [sitemap.xml vs llms.txt & ARD (classic vs agentic)](/compare/sitemap-xml-vs-llms-txt/) - [AGENTS.md vs agents.txt](/compare/agents-md-vs-agents-txt/) - [llms.txt vs agents.txt](/compare/llms-txt-vs-agents-txt/) - [Agentic Resource Discovery vs agents.txt](/compare/ard-vs-agents-txt/) ## References - agents-txt.com publishes a v1.0 'agents.txt Standard' spec: a text file at the site root declaring supported protocols (e.g. x402, mpp), with explicit sections relating it to A2A's AgentCard discovery and to RFC 9727's API Catalog — [https://agents-txt.com/spec](https://agents-txt.com/spec) (2026) VERIFIED - A separate GitHub proposal, kaylacar/agents-txt, describes itself as an open standard proposal for AI-agent capability declaration via a well-known URI, with IANA numbers #72/#73 'filed, under review' and an IETF Internet-Draft on Datatracker; the repository was created 2026-02-22 and last updated 2026-07-18 — [https://github.com/kaylacar/agents-txt](https://github.com/kaylacar/agents-txt) (2026-07-18) VERIFIED - A Mastercard merchant-developer reference page lists agents.txt (at agentstxt.dev, a third distinct effort) as an 'Emerging Standard (Draft)' whose IETF draft expired 2026-04-10, describing 'a fragmented landscape with 11+ competing proposals (agent-manifest.txt, agents-brief.txt, etc.)' and 'no ratified standard' (may require login: HTTP 401 on one check and 200 on another, 2026-09-06) — [https://developer.mastercard.com/merchant-cloud/documentation/tutorials-and-guides/agentic-commerce-guide/24/](https://developer.mastercard.com/merchant-cloud/documentation/tutorials-and-guides/agentic-commerce-guide/24/) (2026) REPORTED - An arXiv paper, 'Towards an Agent-First Web', independently proposes its own agents.txt grammar (INI-style allow/rate-limit/content-format blocks per agent class) served at /.well-known/agents.txt, distinct from the other three — [https://arxiv.org/html/2606.19116v1](https://arxiv.org/html/2606.19116v1) (2026) VERIFIED Disputed: "agents.txt" names at least four non-converging, mutually incompatible proposals (agents-txt.com's v1.0, kaylacar/agents-txt's IETF-draft capability format, agentstxt.dev's expired-draft format, and an academic paper's own INI-style grammar), none of which has become a ratified or dominant standard. [JSON](/data/protocols/agents-txt.json) · [Markdown](/protocols/agents-txt/index.md) · [OKF v0.2](/okf/protocols/agents-txt.md) --- # Agora (agent marketplace protocol) Agora (agent marketplace protocol) is an agentic-web standard (well-known file) at step 7, Pay, governed by Single vendor / independent project; its status is "Testnet-only". It answers: "How can an AI agent discover, hire, and pay another AI agent for a paid job, with escrowed on-chain settlement?" Replacing or extending freelance marketplace plus escrow, implementation status is prototype, last verified 2026-10-23. ## Quick Wire Reference - **Step**: 7 Pay (Settle the bill) - **Version**: API v1, contract v1 (V2 contract written but undeployed) (2026-05-25) - **Status**: Testnet-only; production_status explicitly "testnet-only" in its own manifest… - **Discovery / Probe Path**: https://api.agoraproto.org/.well-known/ai-services.json — /.well-known/ai-services.json… - **Spec URL**: https://api.agoraproto.org/v1/openapi.json - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: freelance marketplace plus escrow [Pay](/category/pay/) This record covers the agent-to-agent hiring marketplace at agoraproto.org, previously conflated in this dataset with the unrelated academic "Agora Protocol" research paper (now split out as agora-protocol). It moved to the pay step in this verification pass: fetching its live OpenAPI spec and its own /.well-known/ai-services.json manifest shows the protocol is fundamentally a paid-marketplace and payment-settlement spec, not a general agent-coordination protocol — its endpoint surface is dominated by /v1/jobs, /v1/listings, /v1/requests/bids, /v1/payments/quote, /v1/payments/execute, and an /v1/x402/* family implementing the HTTP-402 payment-required pattern [[2]](#ref-2). ## Overview What it is: a marketplace where an AI agent needing a capability it lacks (translation, compliance audit, fact-checking, code review, etc.) can discover, hire, and pay another AI agent for a bounded, escrowed job, settling on-chain in USDC on Base Sepolia (a testnet) [[1]](#ref-1)[[3]](#ref-3). Each agent carries a W3C DID identity; jobs move through offer/accept/reject/result/approve/dispute states with a code-as-judge dispute-resolution mechanism; reputation and trust levels (probation, new, verified, trusted) are tracked and tied to settled on-chain jobs [[1]](#ref-1). Discovery works through two .well-known files: /.well-known/ai-services.json (a machine-readable marketplace manifest naming the project, its chain, and its production status) and /.well-known/agora.json (webhook signing keys and supported webhook event types) [[3]](#ref-3). What it does not do: it explicitly is not the Oxford/Camel AI academic Agora negotiation protocol, despite the shared name — its own manifest states this directly [[1]](#ref-1). It is not a general-purpose agent-to-agent messaging protocol; it is scoped to paid marketplace transactions. Current state (as of manifest date 2026-05-25, checked live 2026-09-05): explicitly "testnet-only" production status. The manifest discloses, in unusual and welcome detail, that its deployed V1 escrow contract (AgoraEscrow.sol at a named Base Sepolia address) has four documented weaknesses from a 2026-05-27 external audit (owner can unilaterally refund disputed jobs; dispute path is refund-only; no deadline check on result submission; fees can change post-funding), that a V2 contract addressing these exists in the repository but is undeployed and unaudited, and that the manifest itself warns "Do NOT use this deployment for mainnet money" [[3]](#ref-3). Governance is a single, apparently small, independent project (no vendor consortium or standards body named) — track is recorded as single-vendor. What is unresolved: no evidence of any other implementer, adopter, or independent security review beyond the project's own disclosed audit; adoption is unmeasured. Correction (2026-09-06 relink): the manifest is served on the API host (api.agoraproto.org), not the apex domain (agoraproto.org); the discovery and probe paths in this record now point at https://api.agoraproto.org/.well-known/ai-services.json accordingly. ## Discovery and probe /.well-known/ai-services.json manifest plus /.well-known/agora.json webhook-signing config · https://api.agoraproto.org/.well-known/ai-services.json ``` GET https://api.agoraproto.org/.well-known/ai-services.json parse: JSON manifest with schema_version, type:"marketplace", and production_status field; on agoraproto.org itself this currently reads "testnet-only" on absent: 404 means the origin does not publish an Agora-style AI-services manifest; this is a single-project convention, not yet a broadly adopted well-known name ``` Not probed live: no-fixed-path. Agora Commerce publishes at api.agoraproto.org, not on member origins. ## History - 2026-09-05 — seeded from Exa Agent research run - 2026-09-06 — verified against api.agoraproto.org openapi.json and .well-known manifests, and agoraproto.org homepage; moved step from coordinate to pay given its payments/escrow/marketplace scope; confirmed distinct project from agora-protocol (Oxford academic) via the project's own disambiguation notice - 2026-10-16 — use-case tags (auto) ## Instances - [Agora Marketplace](https://agoraproto.org) · Observed 2026-03-09 · venue Every instance with its source is listed on the [instances page](/instances/). Verified SDKs, reference implementations & validators: - [Agora API (agoraproto.org, testnet)](https://api.agoraproto.org/v1/openapi.json) · implementation (2026-05-25) - [AgoraEscrow.sol V1 external security audit (2026-05-27, self-disclosed weaknesses)](https://api.agoraproto.org/.well-known/ai-services.json) · validator (2026-05-27) Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Builds on: [x402](/protocols/x402/) - Pairs with: [x402](/protocols/x402/), [Agent2Agent Protocol](/protocols/a2a/), [Model Context Protocol](/protocols/mcp/), [ERC-8183: Agentic Commerce](/protocols/erc-8183/), [ERC-8004: Trustless Agents](/protocols/erc-8004/) - Not to be confused with: Agora Protocol (Marro et al., academic negotiation protocol — unrelated, see agora-protocol) ## References - agoraproto.org's homepage schema.org markup and its own manifest explicitly state it is not to be confused with the academic Agora Protocol paper by Marro et al., describing itself instead as "Open marketplace and communication protocol where AI agents discover, hire, and pay other AI agents for paid work," settling on-chain on Base Sepolia in USDC via HTTP-402 escrow. — [https://agoraproto.org](https://agoraproto.org) (2026-09-05) VERIFIED - The live OpenAPI spec at api.agoraproto.org/v1/openapi.json exposes payments/escrow endpoints (/v1/payments/quote, /v1/payments/execute), an x402 payment-protocol job flow (/v1/x402/jobs, /v1/x402/quote), and a jobs/listings/bids marketplace surface, confirming this is a commerce/payments protocol rather than a general negotiation protocol. — [https://api.agoraproto.org/v1/openapi.json](https://api.agoraproto.org/v1/openapi.json) (2026-09-05) VERIFIED - The project's own /.well-known/ai-services.json manifest discloses production_status "testnet-only", chain "base-sepolia", settlement_currency "USDC", and documents known security limitations (C-01, C-02, H-01, H-02) in its V1 escrow contract from a 2026-05-27 external audit, stating the V2 contract fixing them is written but not yet deployed or audited. — [https://api.agoraproto.org/.well-known/ai-services.json](https://api.agoraproto.org/.well-known/ai-services.json) (2026-09-05) VERIFIED Disputed: This project and the academic 'Agora Protocol' (arXiv:2410.11905, Oxford/Camel AI) share the name "Agora" but are confirmed, by the marketplace project's own published manifest, to be unrelated, independently authored projects. [JSON](/data/protocols/agora-commerce-protocol.json) · [Markdown](/protocols/agora-commerce-protocol/index.md) · [OKF v0.2](/okf/protocols/agora-commerce-protocol.md) --- # Agora Protocol (/.wellknown) Agora Protocol is an agentic-web standard (well-known file — /.wellknown) at step 6, Coordinate, governed by Academic research project; its status is "Research protocol with reference implementation and demo". It answers: "How can two heterogeneous LLM agents communicate efficiently, moving from expensive natural-language negotiation to a…?" Implementation status is prototype, last verified 2026-10-23. ## Quick Wire Reference - **Step**: 6 Coordinate (Talk to another agent) - **Version**: current repository (post-paper iteration) - **Status**: Research protocol with reference implementation and demo · prototype - **Discovery / Probe Path**: /.wellknown — well-known list of supported protocol hashes - **Spec URL**: https://raw.githubusercontent.com/agora-protocol/agora-protocol.github.io/master/specs.html - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: none [Coordinate](/category/coordinate/) Agora (the academic protocol, arXiv:2410.11905) is a cross-platform communication protocol for networks of heterogeneous LLM-based agents, from University of Oxford and Camel AI researchers [[1]](#ref-1). It solves the cost/scalability problem of agent-to-agent natural-language chat: two agents ("Alice" and "Bob" in the spec's running example) initially converse in natural language via their LLMs; when a communication pattern recurs, they use their LLMs to negotiate a shared structured protocol (typically JSON) in a handful of rounds; once agreed, each side writes a deterministic "routine" (a small script) implementing its side, after which further exchanges no longer require invoking an LLM at all [[2]](#ref-2). This lets very different agents that have never met communicate at low up-front cost while converging toward near-zero marginal cost, which the authors frame as achieving efficiency, versatility, and portability simultaneously. ## Overview Each Agora message is a JSON envelope carrying protocolHash (a hash of the negotiated protocol document, or null for natural-language exchanges), protocolSources (URIs where the protocol document can be fetched), and a body; responses carry status ("success"/"failure") and body [[2]](#ref-2). Agents may expose a /.wellknown endpoint listing the protocol hashes and source URIs they already support, letting a sender skip negotiation entirely when a suitable shared protocol already exists [[2]](#ref-2). Agora does not define payments, identity/authentication, or a marketplace — it is purely a communication/negotiation protocol between agents that already know how to reach each other over HTTPS. It is explicitly and importantly a different project from the same-named agent marketplace at agoraproto.org (see agora-commerce-protocol); agoraproto.org's own site states this disambiguation directly [[3]](#ref-3). As of this verification, the project's code has moved past the original paper-demo (aimed at a 100-agent network with mixed LLM backends and DB technologies) toward an updated HuggingFace demo and a general-purpose Python library, but there is no versioned "1.0" release and no measured count of production deployments — it remains a research/community project rather than a standards-track spec. Governance is informal (the original academic authors plus open community contribution via GitHub/Discord); no formal standards body is involved. ## Discovery and probe well-known list of supported protocol hashes · /.wellknown ``` GET {origin}/.wellknown parse: JSON object mapping protocol hashes to arrays of protocol-document source URIs confirms the agent declares Agora-supported protocols on absent: Absence means the agent does not advertise pre-negotiated protocols and any Agora exchange would fall back to natural-language negotiation over the same transaction envelope ``` Live check run by [the MCP probe](/mcp/server-card): GET /.wellknown. Agora agents declare supported protocols at /.wellknown (sic) as a JSON map from protocol hash strings to arrays of protocol-document URLs. ``` { "path": "/.wellknown", "expect": { "content_type": "json", "text_match": "^\\s*\\{\\s*\"[A-Za-z0-9_-]{8,}\"\\s*:\\s*\\[\\s*\"https?://" }, "note": "Agora agents declare supported protocols at /.wellknown (sic) as a JSON map from protocol hash strings to arrays of protocol-document URLs." } ``` ## History - 2026-09-05 — seeded from Exa Agent research run - 2026-09-06 — verified against agora-protocol paper-demo README, agora-protocol.github.io specs.html, and agoraproto.org's own disambiguation notice; confirmed distinct from agora-commerce-protocol - 2026-10-16 — use-case tags (auto) - 2026-10-16 — No push since 2025-03-04 (over 180 days) ## Instances - [Agora Protocol Reference Origin (Oxford Demo)](https://github.com/agora-protocol/paper-demo) · Observed 2026-10-23 · agent Every instance with its source is listed on the [instances page](/instances/). Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Pairs with: [Agent2Agent Protocol](/protocols/a2a/), [Agent Network Protocol](/protocols/anp/), [Agent Connect Protocol (AGNTCY)](/protocols/agent-connect-protocol/), [Agent Communication Protocol](/protocols/agent-communication-protocol/), [Model Context Protocol](/protocols/mcp/) - Not to be confused with: Agora (agoraproto.org agent-to-agent marketplace, a different, unrelated project — see agora-commerce-protocol) ## References - Agora: "A Scalable Communication Protocol for Networks of LLMs" (arXiv:2410.11905) is authored by Samuele Marro, Emanuele La Malfa, Jesse Wright, Guohao Li, Nigel Shadbolt, Michael Wooldridge, and Philip Torr, affiliated with the University of Oxford and Camel AI. — [https://raw.githubusercontent.com/agora-protocol/paper-demo/main/README.md](https://raw.githubusercontent.com/agora-protocol/paper-demo/main/README.md) (2026-09-05) VERIFIED - The Agora specification defines a three-tier interaction model (natural language, LLM-negotiated structured protocol, then deterministic routine scripts), a JSON transaction envelope (protocolHash, protocolSources, body/status), and a /.wellknown endpoint agents expose to advertise supported protocol hashes and their sources. — [https://raw.githubusercontent.com/agora-protocol/agora-protocol.github.io/master/specs.html](https://raw.githubusercontent.com/agora-protocol/agora-protocol.github.io/master/specs.html) (2026-09-05) VERIFIED - agoraproto.org's own machine-readable manifest explicitly disambiguates itself from "the academic 'Agora Protocol' paper by Marro et al. — that is a different project that happens to share the name," confirming the two Agoras are unrelated. — [https://agoraproto.org](https://agoraproto.org) (2026-09-05) VERIFIED - No push since 2025-03-04 (over 180 days) — [https://github.com/agora-protocol/agora-protocol.github.io](https://github.com/agora-protocol/agora-protocol.github.io) (2026-10-15) REPORTED [JSON](/data/protocols/agora-protocol.json) · [Markdown](/protocols/agora-protocol/index.md) · [OKF v0.2](/okf/protocols/agora-protocol.md) --- # AI Agent Authentication and Authorization (AIMS) AI Agent Authentication and Authorization (AIMS) is an agentic-web standard (document format) at step 2, Identify, governed by IETF WIMSE Working Group; its status is "Replaced by draft-ietf-wimse-aims-00". It answers: "Is there an IETF-endorsed way to authenticate and authorize an AI agent, and has the WIMSE working group actually taken…?" Implementation status is none found (The document's own authors and IdPro commentary…), last verified 2026-10-23. ## Quick Wire Reference - **Step**: 2 Identify (Who is this agent? Who is this site?) - **Version**: draft-ietf-wimse-aims-00 (WIMSE WG document, expires 2027-03-19); replaces… - **Status**: Replaced by draft-ietf-wimse-aims-00 (WG document, 2026-09-15) · none found - **Discovery / Probe Path**: none - **Spec URL**: https://datatracker.ietf.org/doc/draft-ietf-wimse-aims/ - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: none; closest classic-web analog is a service-account/workload-identity framework… [Identify](/category/identify/) AI Agent Authentication and Authorization — informally called AIMS (Agent Identity Management System) by its authors — is an IETF Internet-Draft that proposes best practices for authenticating and authorizing AI agents by composing existing standards, principally the WIMSE architecture and the OAuth 2.0 family, rather than by defining any new wire protocol [[1]](#ref-1). Its core thesis, as described by co-author Jeff Lombardo, is that an AI agent should be modeled as a workload: it needs an identifier, credentials that cryptographically bind to that identifier, a way to authenticate to other systems, and a way to request delegated authorization, all of which the identity community has already built for services and microservices [[4]](#ref-4). ## Overview It solves the "assembly gap" rather than a standards gap: instead of inventing new token formats or credential lifecycles for agents, it maps WIMSE identifiers (a superset of SPIFFE IDs) to identifiers, WIMSE Workload Identity Tokens / X.509 / SPIFFE JWT-SVIDs to credentials, mTLS and HTTP Message Signatures and WIMSE Proof Tokens to authentication, and OAuth 2.0 flows — authorization code for delegated user flows, client credentials for autonomous agents, token exchange and ID-JAG identity chaining for multi-domain workflows — to authorization, with the OpenID Foundation's Shared Signals Framework, CAEP and RISC left as the mechanism for observability and revocation [[4]](#ref-4). It explicitly does not define any new protocol, does not pick a single policy/compliance standard (deliberately left deployment-specific), and — as of the version reviewed — does not close several hard problems: it has no defined way to revoke a subverted agent that still holds a validly attested credential, no settled per-hop scope-narrowing or chain-verification mechanism for multi-hop agent-to-agent delegation (at least one WIMSE list reviewer reported a confused-deputy escalation path under the current grant patterns), and does not resolve where cryptographic signing material should live given that AI workloads often run with broad sandbox privileges [[3]](#ref-3). Current state: following a WIMSE working-group adoption call that closed on 2026-08-24 with broad list support [[3]](#ref-3), the individual draft (draft-klrc-aiagent-auth-03, updated 2026-07-06) was formally replaced on 2026-09-15 by the WIMSE Working Group document draft-ietf-wimse-aims-00 (expires 2027-03-19, tracked separately under wimse-aims) [[1]](#ref-1)[[5]](#ref-5). Readers following active IETF WIMSE work on agent identity and authorization should track wimse-aims (draft-ietf-wimse-aims). Who implements it: no implementation was located; this is a framework/best-practices document, not a protocol with conformance software, so "implementation" here would mean deployments that follow its composition guidance, and none was independently verified in this pass. Disputed or unknown: how the adopted draft-ietf-wimse-aims WG document evolves from its initial -00 baseline; how the unresolved revocation and multi-hop delegation gaps get closed once (if) the WG owns the document; and how this composition-first approach will relate to competing agent-identity proposals also sitting in WIMSE's orbit (e.g. draft-asor-wimse-agent-delegation-chain, draft-reece-wimse-cross-org-delegation, draft-sweeney-wimse-credential-delegation), none of which this pass reviewed in depth. ## Discovery and probe none; this is a best-practices/architecture framework document, not a discoverable wire protocol with its own well-known path · none ``` GET none parse: not applicable — this record has no probeable wire signal; readers should instead probe the underlying components it composes (SPIFFE Workload API, WIMSE credential/token endpoints, OAuth 2.0 discovery metadata), each tracked as its own record on absent: The draft is a best-practices framework, not a deployable protocol with its own presence signal; absence of adoption means only the individual draft-klrc-aiagent-auth-03 text exists, with no WG document, no registered media type, and no fixed discovery path to probe for ``` Not probed live: no-fixed-path. An IETF framework draft composing WIMSE, SPIFFE and OAuth flows; it defines no artefact of its own at an origin. ## History - 2026-09-07 — created from IETF datatracker (draft-klrc-aiagent-auth-03), WIMSE WG document list, and reporting on the 2026-08-24 WIMSE adoption call - 2026-10-16 — draft-ietf-wimse-aims-00 was published as a WIMSE working group document on 2026-09-15 and replaces draft-klrc-aiagent-auth - 2026-10-16 — use-case tags (auto) - 2026-10-20 — version, spec_url and dispute moved to draft-ietf-wimse-aims-00 (gap scout 2026-10-20) ## Instances Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Builds on: [Workload Identity in Multi System Environments (WIMSE) Architecture](/protocols/wimse/), [SPIFFE (Secure Production Identity Framework for Everyone)](/protocols/spiffe/) - Pairs with: [Workload Identity in Multi System Environments (WIMSE) Architecture](/protocols/wimse/), [WIMSE AI Identity Management System](/protocols/wimse-aims/), [SPIFFE (Secure Production Identity Framework for Everyone)](/protocols/spiffe/), [HTTP Message Signatures](/protocols/http-message-signatures/), [Identity Assertion JWT Authorization Grant](/protocols/identity-assertion-authz-grant/), [OAuth Protected Resource and Authorization Server Metadata (as used for agent authorization)](/protocols/oauth-metadata-for-agents/) - Not to be confused with: AIP (Agent Identity Protocol, a different, unrelated DID-based individual draft already tracked as its own record) ## Comparisons - [AI Agent Authentication and Authorization (AIMS) vs WIMSE AI Identity Management System](/compare/aiagent-auth-vs-wimse-aims/) ## References - draft-klrc-aiagent-auth-03, "AI Agent Authentication and Authorization", is an Active Internet-Draft (individual submission, not a WG document), last updated 2026-07-06, expires 2027-01-07, authored by Pieter Kasselman, Jeff Lombardo (AWS), Yaroslav Rosomakho (Zscaler), Brian Campbell (Ping Identity), Nick Steele (OpenAI) and Aaron Parecki. Its abstract states it proposes best practices for AI agent authentication and authorization by leveraging existing standards — the WIMSE architecture and the OAuth 2.0 family — rather than defining new protocols, to provide a framework, identify gaps, and guide future standardization. — [https://datatracker.ietf.org/doc/draft-klrc-aiagent-auth/](https://datatracker.ietf.org/doc/draft-klrc-aiagent-auth/) (2026-07-06) VERIFIED - The IETF WIMSE working group document list (Active Internet-Drafts, 6 hits, checked 2026-09-07) contains draft-ietf-wimse-wpt, draft-ietf-wimse-http-signature, draft-ietf-wimse-arch, draft-ietf-wimse-identifier, draft-ietf-wimse-mutual-tls and draft-ietf-wimse-workload-creds. No draft-ietf-wimse-aiagent-auth (or any WG-adopted version of the AIMS draft) appears in that list or in the WG's "Related Internet-Drafts" section, which instead lists several other, separate individual drafts on agent delegation (e.g. draft-asor-wimse-agent-delegation-chain, draft-reece-wimse-cross-org-delegation, draft-sweeney-wimse-credential-delegation). — [https://datatracker.ietf.org/wg/wimse/documents/](https://datatracker.ietf.org/wg/wimse/documents/) (2026-09-07) VERIFIED - WIMSE WG chair Justin Richer opened a formal call for adoption of draft-klrc-aiagent-auth (referred to by the authors as AIMS) as a WIMSE working-group document, with responses due 2026-08-24; co-author Pieter Kasselman recused himself from chairing the process. List response was broad support for adoption, with most respondents treating remaining technical gaps (revocation of subverted-but-credentialed agents, multi-hop delegation scope narrowing and chain verification, a reported confused-deputy escalation path, and whether cryptographic signing material belongs inside AI workloads) as post-adoption work rather than blockers. — [https://freenode.net/article/wimse-moves-to-adopt-ai-agent-auth-framework-draft](https://freenode.net/article/wimse-moves-to-adopt-ai-agent-auth-framework-draft) (2026-08-24) REPORTED - Co-author Jeff Lombardo's own account (IdPro blog) describes AIMS (Agent Identity Management System) as a layered framework composing existing standards — WIMSE identifiers (a superset of SPIFFE IDs) for identifiers, WIMSE Workload Identity Tokens / X.509 / SPIFFE JWT-SVIDs for credentials, mTLS / HTTP Message Signatures / WIMSE Proof Tokens for authentication, OAuth 2.0 flows (authorization code, client credentials, token exchange, ID-JAG identity chaining) for delegated authorization, and OpenID Shared Signals Framework / CAEP / RISC for observability and revocation — explicitly not defining any new wire protocol. — [https://idpro.org/how-we-stopped-reinventing-and-started-composing-standards-for-agentic-identity/](https://idpro.org/how-we-stopped-reinventing-and-started-composing-standards-for-agentic-identity/) (2026-07-29) REPORTED - draft-ietf-wimse-aims-00 was published as a WIMSE working group document on 2026-09-15 and replaces draft-klrc-aiagent-auth — [https://datatracker.ietf.org/doc/draft-ietf-wimse-aims/](https://datatracker.ietf.org/doc/draft-ietf-wimse-aims/) (2026-09-15) VERIFIED - draft-ietf-wimse-aims-00 was published as a WIMSE working group document on 2026-09-15 and replaces draft-klrc-aiagent-auth — [https://datatracker.ietf.org/doc/draft-klrc-aiagent-auth/](https://datatracker.ietf.org/doc/draft-klrc-aiagent-auth/) (2026-09-15) VERIFIED - draft-ietf-wimse-aims-00 header: WIMSE, 15 September 2026, expires 19 March 2027, Informational, title 'AI Identity Management System', same six authors as draft-klrc-aiagent-auth. — [https://datatracker.ietf.org/doc/draft-ietf-wimse-aims/](https://datatracker.ietf.org/doc/draft-ietf-wimse-aims/) (2026-09-15) VERIFIED Disputed: The draft is in a live WIMSE working-group adoption process: a formal call for adoption closed 2026-08-24 with broad list support for adopting it as a WG starting point, and on 2026-09-15 it was published as the WG document draft-ietf-wimse-aims-00 ('AI Identity Management System'). Reviewers on the WIMSE list flagged unresolved gaps: no defined revocation path for a subverted-but-still-validly-credentialed agent, no per-hop scope narrowing or chain verification for multi-hop agent-to-agent delegation (at least one reviewer reported a confused-deputy escalation path), disagreement over modeling agent identity purely as workload identity, and concern that cryptographic signing material should not live inside AI workloads that often run with broad sandbox privileges. [JSON](/data/protocols/aiagent-auth.json) · [Markdown](/protocols/aiagent-auth/index.md) · [OKF v0.2](/okf/protocols/aiagent-auth.md) --- # AI Agent Execution Profile of SCITT (AIR) AI Agent Execution Profile of SCITT (AIR) is an agentic-web standard (document format) at step 9, Account, governed by Individual Internet-Draft submitted to the IETF Network Working…; its status is "Internet-Draft, Intended Status: Informational". It answers: "How can an agent operator produce independently verifiable, tamper-evident records of an AI agent's material actions…?" Implementation status is none found, last verified 2026-10-23. ## Quick Wire Reference - **Step**: 9 Account (Prove what happened; be judged) - **Version**: draft-emirdag-scitt-ai-agent-execution-01 (2026-10-12) - **Status**: Internet-Draft, Intended Status: Informational; expires 15 April 2027; work in… - **Discovery / Probe Path**: Not a web-discovery standard. Records are registered with a SCITT Transparency Service… - **Spec URL**: https://datatracker.ietf.org/doc/html/draft-emirdag-scitt-ai-agent-execution-01 - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: A notarized, hash-chained audit ledger held by a third-party custodian, applied to… [Account](/category/account/) An individual IETF Internet-Draft (-01, Informational) profiling SCITT (RFC 9943) for AI agent execution evidence. It defines the AgentInteractionRecord, a hash-chained COSE_Sign1 signed statement for each material agent action, with the Agent Operator as Issuer and an independent Evidence Custodian as Transparency Service. It specifies registration policy, identity binding levels, redaction receipts and compliance mappings. The Evidence Receipt is not yet fully specified in this revision. ## Discovery and probe Not a web-discovery standard. Records are registered with a SCITT Transparency Service (Evidence Custodian) and verified by relying parties out of band. ``` NONE parse: on absent: No site-level probe is defined; support cannot be observed from a site's public endpoints. ``` Not probed live: no-fixed-path. candidate record; probe rule pending ## History - 2026-10-16 — auto-drafted candidate from exa (https://datatracker.ietf.org/doc/html/draft-emirdag-scitt-ai-agent-execution-01) ## Instances Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Pairs with: [An Audit Record Format for AI Agent Authorization Decisions](/protocols/wimse-agent-audit-record/), [Agent Audit Trail](/protocols/agent-audit-trail/), [Agent Decision Commitments for Payments](/protocols/agent-decision-commitment/) ## Comparisons - [Cookies, Syslog & T&Cs vs Agent Attribution, OTel GenAI & SCITT (classic vs agentic)](/compare/cookies-syslog-vs-agent-audit-trail/) - [Agent Audit Trail vs AI Agent Execution Profile of SCITT](/compare/agent-audit-trail-vs-scitt-ai-agent-execution/) ## References - Internet-Draft defines the AgentInteractionRecord (AIR) as a COSE_Sign1 signed statement payload for material AI agent actions. It maps the Agent Operator to SCITT Issuer and an independent Evidence Custodian to Transparency Service, and defines registration policy, redaction receipts and regulatory mappings (EU AI Act Arts. 12/19, DORA, NIST AI RMF, MAS, PCI DSS, MiFID II). — [https://datatracker.ietf.org/doc/html/draft-emirdag-scitt-ai-agent-execution-01](https://datatracker.ietf.org/doc/html/draft-emirdag-scitt-ai-agent-execution-01) (2026-10-12) REPORTED [JSON](/data/protocols/scitt-ai-agent-execution.json) · [Markdown](/protocols/scitt-ai-agent-execution/index.md) · [OKF v0.2](/okf/protocols/scitt-ai-agent-execution.md) --- # AI Catalog well-known file (/.well-known/ai-catalog.json) AI Catalog well-known file is an agentic-web standard (well-known file — /.well-known/ai-catalog.json) at step 1, Discover, governed by Originated in the AI-Card / ARD working repositories and…; its status is "Active discovery path in MCP SEP-2127 and predecessor path of…". It answers: "Which AI-capable artifacts and registries does this domain publish? (superseded question -- see ard)" Replacing or extending sitemap.xml, implementation status is shipping (observed on 62/1226 probed origins), last verified 2026-10-24. ## Quick Wire Reference - **Step**: 1 Discover (What is here, and where?) - **Version**: n/a -- not a separately versioned artifact - **Status**: Active discovery path in MCP SEP-2127 (Final, 2026-10-06) and predecessor path… - **Discovery / Probe Path**: /.well-known/ai-catalog.json — superseded -- see ard - **Spec URL**: https://raw.githubusercontent.com/ards-project/ard-spec/main/spec/ard.md - **Last Verified**: 2026-10-24 (current) - **Classic Web Analog**: sitemap.xml [Discover](/category/discover/) /.well-known/ai-catalog.json is the well-known catalog path originated in the AI-Card / early Agentic Resource Discovery (ARD) work [[1]](#ref-1) and referenced normatively by MCP SEP-2127 (Final, 6 October 2026) and the MCP Server Card discovery specification (docs/discovery.md), which state that clients discovering MCP servers at the domain level SHOULD attempt to retrieve /.well-known/ai-catalog.json [[2]](#ref-2). ## Overview In ARD v0.91 (26 August 2026), the ARD specification renamed its canonical manifest path from /.well-known/ai-catalog.json to /.well-known/ard.json while keeping the same JSON Schema (spec/schemas/ai-catalog.schema.json, specVersion: "1.0") [[1]](#ref-1). Because MCP SEP-2127 clients look for /.well-known/ai-catalog.json while ARD v0.91+ clients look for /.well-known/ard.json, origins publishing an ARD/AI catalog should serve the same document at both paths. ## Discovery and probe superseded -- see ard · /.well-known/ai-catalog.json ``` GET https://{origin}/.well-known/ai-catalog.json parse: superseded; see the ard record's probe for the current canonical path on absent: superseded; see ard ``` Live check run by [the MCP probe](/mcp/server-card): GET /.well-known/ai-catalog.json. Deprecated predecessor path of the ARD manifest, still probed so the census can count migration. ``` { "path": "/.well-known/ai-catalog.json", "expect": { "json_keys": [ "entries" ] }, "note": "Deprecated predecessor path of the ARD manifest, still probed so the census can count migration." } ``` ## History - 2026-09-05 — seeded from Exa Agent research run - 2026-09-06 — merged into ard: confirmed via ARD v0.91 spec text that ai-catalog.json is ARD's own deprecated predecessor path, not a separate specification - 2026-09-06 — fix round 1: added second evidence entry (Google ARD launch blog post, fetched directly) to satisfy the two-evidence gate - 2026-10-16 — use-case tags (auto) ## Instances - [Zapier (zapier.com)](https://zapier.com/) · Observed 2026-10-25 · origin - [tldraw Infinite Canvas SDK (tldraw.com)](https://tldraw.com/) · Observed 2026-10-25 · origin - [SurrealDB (surrealdb.com)](https://surrealdb.com/) · Observed 2026-10-25 · origin - [Supabase (supabase.com)](https://supabase.com/) · Observed 2026-10-25 · origin - [Speakeasy (speakeasy.com)](https://speakeasy.com/) · Observed 2026-10-25 · origin - [Scalar API Platform (scalar.com)](https://scalar.com/) · Observed 2026-10-25 · origin - [SavvyCal (savvycal.com)](https://savvycal.com/) · Observed 2026-10-25 · origin - [Reducto Document AI (reducto.ai)](https://reducto.ai/) · Observed 2026-10-25 · origin - [Publica.la (publica.la)](https://publica.la/) · Observed 2026-10-25 · origin - [Proof API (api.proof.com)](https://api.proof.com/.well-known/ard.json) · Observed 2026-10-25 · origin - [Lago (getlago.com)](https://getlago.com/) · Observed 2026-10-25 · origin - [Hostinger (hostinger.com)](https://hostinger.com/) · Observed 2026-10-25 · origin - [Fly.io (fly.io)](https://fly.io/) · Observed 2026-10-25 · origin - [Eodly (eodly.io)](https://eodly.io/) · Observed 2026-10-25 · origin - [Dries Buytaert (dri.es)](https://dri.es/) · Observed 2026-10-25 · origin - [Desvela (desvela.dev)](https://desvela.dev/) · Observed 2026-10-25 · origin - [DC Hub (dchub.cloud)](https://dchub.cloud/) · Observed 2026-10-25 · origin - [Cal.com Scheduling Infrastructure (cal.com)](https://cal.com/) · Observed 2026-10-25 · origin - [Bird (bird.com)](https://bird.com/) · Observed 2026-10-25 · origin - [beehiiv Newsletter Platform (beehiiv.com)](https://beehiiv.com/) · Observed 2026-10-25 · origin - [Arcade AI Tool-Calling Runtime (arcade.dev)](https://arcade.dev/) · Observed 2026-10-25 · origin - [Appwrite Backend Platform (appwrite.io)](https://appwrite.io/) · Observed 2026-10-25 · origin - [Amplitude (amplitude.com)](https://amplitude.com/) · Observed 2026-10-25 · origin - [Vercel (vercel.com)](https://vercel.com/) · Observed 2026-10-23 · origin - [Telnyx (telnyx.com)](https://telnyx.com/) · Observed 2026-10-23 · origin - [Salespeak B2B Buyer Concierge Agent](https://salespeak.ai) · Observed 2026-10-23 · agent - [RudderStack (rudderstack.com)](https://rudderstack.com/) · Observed 2026-10-23 · origin - [Resend (resend.com)](https://resend.com/) · Observed 2026-10-23 · origin - [Railway (railway.com)](https://railway.com/) · Observed 2026-10-23 · origin - [QuickNode (quicknode.com)](https://quicknode.com/) · Observed 2026-10-23 · origin - [Next.js (nextjs.org)](https://nextjs.org/) · Observed 2026-10-23 · origin - [Neuronto Agentic Web Index](https://neuronto.com) · Observed 2026-10-23 · venue - [Neon Serverless Postgres (neon.com)](https://neon.com/) · Observed 2026-10-23 · origin - [n8n Documentation Origin (docs.n8n.io)](https://docs.n8n.io/) · Observed 2026-10-23 · origin - [Loops (loops.so)](https://loops.so/) · Observed 2026-10-23 · origin - [IMG.LY (img.ly)](https://img.ly/) · Observed 2026-10-23 · origin - [Hugging Face (huggingface.co)](https://huggingface.co/) · Observed 2026-10-23 · origin - [GTmetrix (gtmetrix.com)](https://gtmetrix.com/) · Observed 2026-10-23 · origin - [GitHub (github.com)](https://github.com/) · Observed 2026-10-23 · origin - [GitBook (gitbook.com)](https://gitbook.com/) · Observed 2026-10-23 · origin - [facilitator.live.nevermined.app](https://facilitator.live.nevermined.app/) · Observed 2026-10-23 · origin - [ClickHouse (clickhouse.com)](https://clickhouse.com/) · Observed 2026-10-23 · origin - [Apify (apify.com)](https://apify.com/) · Observed 2026-10-23 · origin - [Anthropic Claude Platform (platform.claude.com)](https://platform.claude.com/) · Observed 2026-10-23 · origin - [Airtable (airtable.com)](https://airtable.com/) · Observed 2026-10-23 · origin - [agenticweb.wiki Reference Agent and MCP Server](https://agenticweb.wiki) · Observed 2026-10-23 · agent - [Agentic Resources (agenticresources.dev)](https://agenticresources.dev/) · Observed 2026-10-23 · origin - [agent-ready.dev Conformance Scanner Agent](https://agent-ready.dev) · Observed 2026-10-23 · agent Every instance with its source is listed on the [instances page](/instances/). Our probe: seen on 62 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Part of: [Agentic Resource Discovery](/protocols/ard/) - Pairs with: [Agentic Resource Discovery](/protocols/ard/), [api-catalog: A Well-Known URI and Link Relation to Help Discovery of APIs](/protocols/api-catalog-rfc9727/), [MCP Server Cards (SEP-2127)](/protocols/mcp-server-cards/), [agents.json](/protocols/agents-json/), [llms.txt](/protocols/llms-txt/), [Official MCP Registry](/protocols/mcp-registry/) - [Well-known URI](/terms/well-known/) - [Agentic Resource Discovery (ARD) manifest](/terms/ard-manifest/) ## Comparisons - [Agentic Resource Discovery vs AI Catalog well-known file](/compare/ard-vs-ai-catalog-well-known-file/) - [MCP Server Cards (SEP-2127) vs AI Catalog well-known file](/compare/mcp-server-cards-vs-ai-catalog-well-known-file/) ## References - ARD v0.91 specification renaming the manifest path from /.well-known/ai-catalog.json to /.well-known/ard.json while retaining ai-catalog.schema.json — [https://raw.githubusercontent.com/ards-project/ard-spec/main/spec/ard.md](https://raw.githubusercontent.com/ards-project/ard-spec/main/spec/ard.md) (2026-08-29) VERIFIED - MCP Server Card discovery specification stating clients SHOULD attempt to retrieve /.well-known/ai-catalog.json for domain-level server card discovery — [https://github.com/modelcontextprotocol/experimental-ext-server-card/blob/main/docs/discovery.md](https://github.com/modelcontextprotocol/experimental-ext-server-card/blob/main/docs/discovery.md) (2026-10-06) VERIFIED [JSON](/data/protocols/ai-catalog-well-known-file.json) · [Markdown](/protocols/ai-catalog-well-known-file/index.md) · [OKF v0.2](/okf/protocols/ai-catalog-well-known-file.md) --- # AI Crawler User-Agent Tokens in robots.txt (/robots.txt) AI Crawler User-Agent Tokens in robots.txt is an agentic-web standard (well-known file — /robots.txt) at step 3, Permit, governed by No single governing body; its status is "A convention, not a formal spec". It answers: "Which named AI crawler or agent user-agent tokens may a website allow or disallow in robots.txt, and what does each…?" Implementation status is multi-implementation (observed on 201/1226 probed origins), last verified 2026-10-23. ## Quick Wire Reference - **Step**: 3 Permit (What may the agent do here?) - **Version**: Ongoing; tokens and their scopes are updated by each vendor independently - **Status**: A convention, not a formal spec; each vendor's documentation is normative only… - **Discovery / Probe Path**: /robots.txt — User-agent group directives inside robots.txt, one group per named… - **Spec URL**: https://www.rfc-editor.org/rfc/rfc9309.html - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: The original robots.txt User-agent convention, extended per-vendor for AI [Permit](/category/permit/) This record covers the most widely deployed permit mechanism on the web today: a family of vendor-specific user-agent tokens that AI companies define for use inside a site's existing robots.txt file, built on the IETF's RFC 9309 Robots Exclusion Protocol syntax. It is not a single spec but a convention each vendor documents and maintains independently, unified only by shared syntax (User-agent groups with allow/disallow rules) [OpenAI, Anthropic, Google, Perplexity docs below]. ## Overview Four major vendors were checked directly for this record. OpenAI documents GPTBot (training data collection), OAI-SearchBot (search indexing), and OAI-AdsBot (ad-related validation), each with its own user-agent string and published IP range for verification [[1]](#ref-1). Anthropic documents ClaudeBot (training-data collection), Claude-User (fetches triggered by a live user question to Claude), and Claude-SearchBot (search-quality crawling), explaining separately what disabling each one via robots.txt does to a site's treatment [[2]](#ref-2). Google documents the long-standing Googlebot token alongside the AI-specific Google-Extended token, and is explicit that Google-Extended controls only training data for Gemini models and Vertex AI grounding, with 'no effect on Google Search or other products' — confirming, directly from Google's own text, the prior finding that Google-Extended does not control Search or AI Overviews [[3]](#ref-3). Perplexity documents PerplexityBot (crawling for its models) and Perplexity-User, which it states explicitly 'is not used for web crawling or to collect content for training AI foundation models' but instead fetches pages live in response to a user's question [[4]](#ref-4). The pattern across all four vendors is the same: a 'bulk crawling / training' token and a separate 'live, user-triggered fetch' token, plus sometimes a third 'search index' token, each independently blockable. This granularity is exactly the gap the IETF AIPREF drafts and Cloudflare's Content Signals Policy are trying to standardize into a single, vendor-neutral vocabulary — today, a publisher who wants to block AI training but keep search visibility must maintain a separate robots.txt group per vendor, using each vendor's own token names, rather than one general-purpose signal. As of this verification (2026-09-06), all four vendor documentation pages were live and internally consistent with each other's pattern. No unified registry of every AI crawler token across every vendor (beyond each vendor's own page) was checked in this pass; adoption is recorded as observed, since the tokens themselves are demonstrably deployed by name-brand vendors and honoured by a large fraction of the web's robots.txt files, but no systematic probe run counted that fraction for this record. What is unresolved: whether the IETF AIPREF or Cloudflare Content Signals conventions will eventually consolidate these per-vendor tokens into one general vocabulary, or whether new AI companies will simply keep adding their own named tokens to this already-fragmented list. ## Discovery and probe User-agent group directives inside robots.txt, one group per named crawler token · /robots.txt ``` GET {origin}/robots.txt parse: Look for User-agent groups matching known tokens: GPTBot, OAI-SearchBot, OAI-AdsBot (OpenAI); ClaudeBot, Claude-User, Claude-SearchBot (Anthropic); Googlebot, Google-Extended (Google); PerplexityBot, Perplexity-User (Perplexity); then read the allow/disallow rules in that group on absent: No group for a given token means that crawler applies its default (documented per-vendor, typically full access) rather than an explicit restriction ``` Live check run by [the MCP probe](/mcp/server-card): GET /robots.txt. A robots.txt group naming a known AI crawler token. In probe/has, any group naming a known AI crawler token counts as found; in validate_manifest, permit step coverage requires at least one allowed/partial AI crawler, Content-Signal, Content-Usage, or Agentmap directive. ``` { "path": "/robots.txt", "expect": { "text_match": "(?im)^user-agent:\\s*(GPTBot|OAI-SearchBot|ClaudeBot|Claude-User|Claude-SearchBot|Google-Extended|PerplexityBot|CCBot|Applebot-Extended|meta-externalagent|Bytespider|Amazonbot)\\b" }, "note": "A robots.txt group naming a known AI crawler token. In probe/has, any group naming a known AI crawler token counts as found; in validate_manifest, permit step coverage requires at least one allowed/partial AI crawler, Content-Signal, Content-Usage, or Agentmap directive." } ``` ## History - 2026-09-06 — created and verified against developers.openai.com/api/docs/bots, support.claude.com/en/articles/8896518, developers.google.com/search/docs/crawling-indexing/google-common-crawlers, docs.perplexity.ai/guides/bots (occupant-diff candidate) - 2026-10-16 — Cloudflare 'Disallow AI Training' and Accountable crawler designation (2026-09-15); Bot Preference Sync replaces Managed robots.txt - 2026-10-16 — use-case tags (auto) - 2026-10-20 — noted the expired crawler best-practices draft draft-illyes-aipref-cbcp-04 (2026-04-09, expired 2026-10-11); from gap scout 2026-10-20, verified against the datatracker page (via Exa) and the -04 text (IETF rsync archive) ## Instances - [Zuplo API Gateway (zuplo.com)](https://zuplo.com/) · Observed 2026-10-25 · origin - [Zep Long-Term Agent Memory (getzep.com)](https://getzep.com/) · Observed 2026-10-25 · origin - [Zapier (zapier.com)](https://zapier.com/) · Observed 2026-10-25 · origin - [Warp Agentic Terminal (warp.dev)](https://warp.dev/) · Observed 2026-10-25 · origin - [Vellum AI Workflow Platform (vellum.ai)](https://vellum.ai/) · Observed 2026-10-25 · origin - [Vast.ai (vast.ai)](https://vast.ai/) · Observed 2026-10-25 · origin - [SurrealDB (surrealdb.com)](https://surrealdb.com/) · Observed 2026-10-25 · origin - [Speakeasy (speakeasy.com)](https://speakeasy.com/) · Observed 2026-10-25 · origin - [SavvyCal (savvycal.com)](https://savvycal.com/) · Observed 2026-10-25 · origin - [Reducto Document AI (reducto.ai)](https://reducto.ai/) · Observed 2026-10-25 · origin - [React Email by Resend (react.email)](https://react.email/) · Observed 2026-10-25 · origin - [Pydantic & Logfire (pydantic.dev)](https://pydantic.dev/) · Observed 2026-10-25 · origin - [Publica.la (publica.la)](https://publica.la/) · Observed 2026-10-25 · origin - [Podscan Podcast Intelligence API (podscan.fm)](https://podscan.fm/) · Observed 2026-10-25 · origin - [Plane (plane.so)](https://plane.so/) · Observed 2026-10-25 · origin - [Morph Fast Apply LLM (morphllm.com)](https://morphllm.com/) · Observed 2026-10-25 · origin - [MetricSpot (metricspot.com)](https://metricspot.com/) · Observed 2026-10-25 · origin - [Lovable AI Full-Stack Builder (lovable.dev)](https://lovable.dev/) · Observed 2026-10-25 · origin - [LanceDB (lancedb.com)](https://lancedb.com/) · Observed 2026-10-25 · origin - [Lago (getlago.com)](https://getlago.com/) · Observed 2026-10-25 · origin - [Hostinger (hostinger.com)](https://hostinger.com/) · Observed 2026-10-25 · origin - [Eodly (eodly.io)](https://eodly.io/) · Observed 2026-10-25 · origin - [Devin Origin (devin.ai)](https://devin.ai/) · Observed 2026-10-25 · origin - [DC Hub (dchub.cloud)](https://dchub.cloud/) · Observed 2026-10-25 · origin - [Cerebrium Serverless AI (cerebrium.ai)](https://cerebrium.ai/) · Observed 2026-10-25 · origin - [Browser Use Web Agent Runtime (browser-use.com)](https://browser-use.com/) · Observed 2026-10-25 · origin - [beehiiv Newsletter Platform (beehiiv.com)](https://beehiiv.com/) · Observed 2026-10-25 · origin - [Atlan (atlan.com)](https://atlan.com/) · Observed 2026-10-25 · origin - [Arcade AI Tool-Calling Runtime (arcade.dev)](https://arcade.dev/) · Observed 2026-10-25 · origin - [Appwrite Backend Platform (appwrite.io)](https://appwrite.io/) · Observed 2026-10-25 · origin - [Apideck Unified API (apideck.com)](https://apideck.com/) · Observed 2026-10-25 · origin - [Amplitude (amplitude.com)](https://amplitude.com/) · Observed 2026-10-25 · origin - [2s.io](https://2s.io/) · Observed 2026-10-25 · origin - [Yahoo (yahoo.com)](https://yahoo.com/) · Observed 2026-10-23 · origin - [Tempo (tempo.xyz)](https://tempo.xyz/) · Observed 2026-10-23 · origin - [Telnyx (telnyx.com)](https://telnyx.com/) · Observed 2026-10-23 · origin - [SleekNova (sleeknova.com)](https://sleeknova.com/) · Observed 2026-10-23 · origin - [SAP (sap.com)](https://sap.com/) · Observed 2026-10-23 · origin - [Samsung (samsung.com)](https://samsung.com/) · Observed 2026-10-23 · origin - [Salespeak B2B Buyer Concierge Agent](https://salespeak.ai) · Observed 2026-10-23 · agent - [quora.com](https://quora.com/) · Observed 2026-10-23 · origin - [QAIL (qail.ai)](https://qail.ai/) · Observed 2026-10-23 · origin - [oreilly.com](https://oreilly.com/) · Observed 2026-10-23 · origin - [mvnrepository.com](https://mvnrepository.com/) · Observed 2026-10-23 · origin - [medium.com](https://medium.com/) · Observed 2026-10-23 · origin - [kochava.com](https://kochava.com/) · Observed 2026-10-23 · origin - [Honeycomb AI (honeyb.ai)](https://honeyb.ai/) · Observed 2026-10-23 · origin - [GitHub (github.com)](https://github.com/) · Observed 2026-10-23 · origin - [Figma (figma.com)](https://figma.com/) · Observed 2026-10-23 · origin - [factory.com](https://factory.com/) · Observed 2026-10-23 · origin - [Dreaming Press (dreaming.press)](https://dreaming.press/) · Observed 2026-10-23 · origin - [devtoollab.com](https://devtoollab.com/) · Observed 2026-10-23 · origin - [Cloudflare (cloudflare.com)](https://cloudflare.com/) · Observed 2026-10-23 · origin - [cloudandsre.com](https://cloudandsre.com/) · Observed 2026-10-23 · origin - [Canva (canva.com)](https://canva.com/) · Observed 2026-10-23 · origin - [bmdpat.com](https://bmdpat.com/) · Observed 2026-10-23 · origin - [blakecrosley.com](https://blakecrosley.com/) · Observed 2026-10-23 · origin - [AWS Strands Agents (strandsagents.com)](https://strandsagents.com/) · Observed 2026-10-23 · origin - [auth.md Specification Origin (auth-md.com)](https://auth-md.com/) · Observed 2026-10-23 · origin - [Associated Press (ap.org)](https://ap.org/) · Observed 2026-10-23 · origin - [agenticweb.wiki Reference Agent and MCP Server](https://agenticweb.wiki) · Observed 2026-10-23 · agent - [Agentic AI Foundation (aaif.io)](https://aaif.io/) · Observed 2026-10-23 · origin - [agent-ready.dev Conformance Scanner Agent](https://agent-ready.dev) · Observed 2026-10-23 · agent - [Crawlytics AI Crawler Directory](https://crawlytics.app/resources/ai-bots-list/) · Observed 2026-08-29 · venue Every instance with its source is listed on the [instances page](/instances/). Verified SDKs, reference implementations & validators: - [OpenAI crawlers (GPTBot, OAI-SearchBot, OAI-AdsBot)](https://developers.openai.com/api/docs/bots) · implementation (2026) - [Anthropic crawlers (ClaudeBot, Claude-User, Claude-SearchBot)](https://support.claude.com/en/articles/8896518) · implementation (2026) - [Google crawlers (Googlebot, Google-Extended)](https://developers.google.com/search/docs/crawling-indexing/google-common-crawlers) · implementation (2026) - [Perplexity crawlers (PerplexityBot, Perplexity-User)](https://docs.perplexity.ai/guides/bots) · implementation (2026) Our probe: seen on 201 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Depended on by: [Content Signals Policy](/protocols/cloudflare-content-signals-policy/), [Really Simple Licensing](/protocols/rsl/) - Pairs with: [AIPREF Vocabulary](/protocols/aipref-vocabulary/), [AIPREF Content-Usage Attachment](/protocols/aipref-content-usage-attachment/), [Content Signals Policy](/protocols/cloudflare-content-signals-policy/), [ai.txt](/protocols/ai-txt/), [Text and Data Mining Reservation Protocol](/protocols/tdmrep/), [Markdown for Agents](/protocols/cloudflare-markdown-for-agents/) - [Content-Signal directive](/terms/content-signal/) - Scanners & registries: [Cloudflare AI Crawl Control bot reference](https://developers.cloudflare.com/ai-crawl-control/reference/bots/), [CrawlerCheck](https://crawlercheck.com/), [CrawlIndex](https://crawlindex.org/), [Lumar Agentic Readiness Scanner](https://agentic-readiness.lumar.io/) ## Comparisons - [robots.txt (Allow/Disallow) vs Content-Signal, AIPREF & TDMRep (classic vs agentic)](/compare/robots-txt-vs-content-signal/) - [AI Crawler User-Agent Tokens in robots.txt vs agent-permissions.json](/compare/ai-crawler-tokens-robots-vs-agent-permissions-json/) - [AI Crawler User-Agent Tokens in robots.txt vs Really Simple Licensing](/compare/ai-crawler-tokens-robots-vs-rsl/) - [AI Crawler User-Agent Tokens in robots.txt vs Text and Data Mining Reservation Protocol](/compare/ai-crawler-tokens-robots-vs-tdmrep/) - [AI Crawler User-Agent Tokens in robots.txt vs Content Signals Policy](/compare/ai-crawler-tokens-robots-vs-cloudflare-content-signals-policy/) - [AI Crawler User-Agent Tokens in robots.txt vs ai.txt](/compare/ai-crawler-tokens-robots-vs-ai-txt/) ## References - OpenAI's own bot documentation (developers.openai.com/api/docs/bots) names OAI-SearchBot, OAI-AdsBot, and GPTBot with distinct user-agent strings and published IP ranges, and recommends site owners control each via robots.txt. — [https://developers.openai.com/api/docs/bots](https://developers.openai.com/api/docs/bots) (2026) VERIFIED - Anthropic's support article names three distinct robots — ClaudeBot (training), Claude-User (user-triggered access), and Claude-SearchBot (search quality) — and documents what disabling each one via robots.txt does. — [https://support.claude.com/en/articles/8896518](https://support.claude.com/en/articles/8896518) (2026) VERIFIED - Google's documentation states that Google-Extended is a standalone robots.txt product token controlling only Gemini model training/grounding and Vertex AI, and explicitly states it has no effect on Google Search or other Google products, confirming it is distinct from the Googlebot token. — [https://developers.google.com/search/docs/crawling-indexing/google-common-crawlers](https://developers.google.com/search/docs/crawling-indexing/google-common-crawlers) (2026) VERIFIED - Perplexity's crawler documentation names PerplexityBot (crawling/training) and Perplexity-User (live user-query-triggered fetches, explicitly not used for crawling or training) as separate tokens with separate published IP ranges. — [https://docs.perplexity.ai/guides/bots](https://docs.perplexity.ai/guides/bots) (2026) VERIFIED - Cloudflare 'Disallow AI Training' and Accountable crawler designation (2026-09-15); Bot Preference Sync replaces Managed robots.txt — [https://blog.cloudflare.com/](https://blog.cloudflare.com/) (2026-09-15) REPORTED - draft-illyes-aipref-cbcp 'Crawler best practices' (G. Illyes, M. Kühlewind of Ericsson, A. Kohn) lists six practices crawlers must follow: respect the Robots Exclusion Protocol, identify themselves in the User-Agent string, not interfere with a site's normal operation, support caching directives, publish their IP ranges in a standardized format, and publish a page explaining how to block them and how crawled data is used. Its last revision, -04 of 2026-04-09, expired on 2026-10-11 with no successor and is archived. — [https://datatracker.ietf.org/doc/draft-illyes-aipref-cbcp/](https://datatracker.ietf.org/doc/draft-illyes-aipref-cbcp/) (2026-04-09) VERIFIED [JSON](/data/protocols/ai-crawler-tokens-robots.json) · [Markdown](/protocols/ai-crawler-tokens-robots/index.md) · [OKF v0.2](/okf/protocols/ai-crawler-tokens-robots.md) --- # ai.txt (/ai.txt) ai.txt is an agentic-web standard (well-known file — /ai.txt) at step 3, Permit, governed by None; its status is "IETF Internet-Draft presented as a formal well-known-URI…". It answers: "May AI systems train on, scrape, index, or cache this site's content, and under what per-agent or per-path conditions?" Implementation status is prototype, last verified 2026-10-23. ## Quick Wire Reference - **Step**: 3 Permit (What may the agent do here?) - **Version**: draft-car-ai-txt-wellknown-00 - **Status**: IETF Internet-Draft (draft-car-ai-txt-wellknown-00) presented as a formal… - **Discovery / Probe Path**: /ai.txt — Fixed filename at the site root, following the /.well-known/ convention… - **Spec URL**: https://www.ietf.org/archive/id/draft-car-ai-txt-wellknown-00.html - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: robots.txt, extended from crawl permission to AI-specific permissions (training… [Permit](/category/permit/) Moved from the Read step to Permit. ai.txt is not read-step content — every substantive proposal found (excluding the differently-scoped aitxt.ing) is a permissions declaration: whether AI systems may train on, scrape, index, or cache a site's content, comparable to robots.txt extended with AI-specific and licensing semantics [[1]](#ref-1)[[2]](#ref-2)[[3]](#ref-3). It is filed here under "Permit" (what may the agent do here?) rather than "Read", and is reported with this corrected step. ## Overview What it is, per the most detailed version found (IETF Internet-Draft draft-car-ai-txt-wellknown-00): a text file at /ai.txt declaring site-wide defaults for four fields — Training, Scraping, Indexing, Caching — each allow/deny/(conditional for Training only), with path-scoped Training-Allow/Training-Deny overrides, a Training-License and Training-Fee for conditional training, and per-agent blocks that can override the defaults for a named bot (e.g. allowing ClaudeBot to train while denying GPTBot) [[1]](#ref-1). A second, independently authored proposal, kaylacar/ai-txt, targets the same policy domain (training, licensing, attribution, per-agent rules) and separately claims its own IANA filing and IETF draft [[2]](#ref-2). A third, an arXiv-published domain-specific language, defines yet a different syntax (Disallow: Return, Disallow: Train) for largely the same purpose, explicitly modeled on robots.txt's declared-but-unenforced approach [[3]](#ref-3). It solves, in principle, a real gap: robots.txt has no notion of "may train on" versus "may crawl for search indexing" versus "may serve in a live AI answer", and site owners increasingly want to distinguish these. Per-agent, per-path granularity and an attached licensing/fee mechanism go further than robots.txt's binary allow/disallow. It does not currently solve that gap in a way any agent could rely on, because — as with agents.txt — there is no single ai.txt an agent can fetch and trust: at least two IETF-style drafts and one academic DSL independently claim the same well-known filename for the same purpose, with no evidence any converged or even cited one another. A fourth party, aitxt.ing, uses the identical filename for an unrelated content-description product ("preventing hallucination" by describing resources to AI assistants), which would collide outright with any site that adopted a policy-declaration ai.txt at the same path [[4]](#ref-4). Current state, as of this verification (September 2026): the earliest dated artifact identified is the kaylacar/ai-txt repository, created 2026-02-22 [[2]](#ref-2); the arXiv DSL paper is dated 2025 [[3]](#ref-3); the IETF draft-car draft carries no clear publication date in the fetched text. Enforcement is, by every proposal's own admission, declarative only — like robots.txt, nothing prevents a non-compliant crawler from ignoring the file. What is disputed or unknown: which (if any) proposal has priority, whether any has actual publisher adoption, and how the aitxt.ing name collision would be resolved in practice. This record should be treated as thin and revisited once (or if) one proposal gains distinguishable traction. ## Discovery and probe Fixed filename at the site root, following the /.well-known/ convention on some proposals · /ai.txt or /.well-known/ai.txt (varies by proposal) ``` GET {origin}/ai.txt parse: 200 response with a text body containing top-level Training/Scraping/Indexing/Caching directives (allow/deny/conditional) and optional per-Agent blocks, per the IETF draft's grammar; other proposals use different field names for the same purpose, or an unrelated content-description grammar (aitxt.ing) on absent: No ai.txt under any identified convention; given active fragmentation and low visibility, absence does not indicate a deliberate policy choice ``` Live check run by [the MCP probe](/mcp/server-card): GET /ai.txt. ai.txt carries Training, Scraping, Indexing or Caching directives. ``` { "path": "/ai.txt", "expect": { "text_match": "(?im)^(training|scraping|indexing|caching)\\s*:" }, "note": "ai.txt carries Training, Scraping, Indexing or Caching directives." } ``` ## History - 2026-09-06 — new record added during read-step verification; reclassified to the permit step after finding the name covers multiple unrelated policy proposals plus one unrelated content-description product - 2026-10-16 — use-case tags (auto) ## Instances - [Spawning AI (ai.txt Origin Steward)](https://spawning.ai/ai-txt) · Observed 2026-08-29 · origin Every instance with its source is listed on the [instances page](/instances/). Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Pairs with: [AI Crawler User-Agent Tokens in robots.txt](/protocols/ai-crawler-tokens-robots/), [AIPREF Vocabulary](/protocols/aipref-vocabulary/), [AIPREF Content-Usage Attachment](/protocols/aipref-content-usage-attachment/), [Text and Data Mining Reservation Protocol](/protocols/tdmrep/), [Really Simple Licensing](/protocols/rsl/) - Not to be confused with: At least four unrelated, mutually incompatible specifications share the "ai.txt" name (see dispute): the IETF Internet-Draft draft-car-ai-txt-wellknown (training/scraping/indexing/caching policy), kaylacar/ai-txt (a separate IANA-filed proposal for the same policy domain), the arXiv 'ai.txt: A Domain-Specific Language' paper (Disallow: Return / Disallow: Train directives), and aitxt.ing ('a universal standard for describing any resource to AI assistants', a content-description format unrelated to policy) ## Comparisons - [AI Crawler User-Agent Tokens in robots.txt vs ai.txt](/compare/ai-crawler-tokens-robots-vs-ai-txt/) ## References - IETF Internet-Draft draft-car-ai-txt-wellknown-00 defines '/ai.txt' as a well-known URI declaring site-wide Training/Scraping/Indexing/Caching defaults (allow/deny/conditional), per-path Training-Allow/Training-Deny overrides, licensing and fee fields, and per-agent blocks (e.g. distinct rules for ClaudeBot vs. GPTBot) — [https://www.ietf.org/archive/id/draft-car-ai-txt-wellknown-00.html](https://www.ietf.org/archive/id/draft-car-ai-txt-wellknown-00.html) (2026) VERIFIED - A separate GitHub repository, kaylacar/ai-txt, independently proposes 'an open standard proposal for declaring a website's AI policy: training, licensing, attribution, per-agent rules', claiming IANA filing #76/#77 'under review' and an IETF Internet-Draft on Datatracker; created 2026-02-22, last updated 2026-07-18 — [https://github.com/kaylacar/ai-txt](https://github.com/kaylacar/ai-txt) (2026-07-18) VERIFIED - An arXiv paper, 'ai.txt: A Domain-Specific Language for Guiding AI Interactions with the Internet', independently defines its own ai.txt DSL with Disallow: Return and Disallow: Train directives, explicitly positioned as an extension of robots.txt's model of declared-not-enforced regulation — [https://arxiv.org/html/2505.07834v1](https://arxiv.org/html/2505.07834v1) (2025) VERIFIED - aitxt.ing markets itself as 'a universal standard for describing any resource to AI assistants using plain text, preventing hallucination' — a content-description product, not a policy-permission format, despite sharing the ai.txt name — [https://aitxt.ing/](https://aitxt.ing/) (2026) THIN Disputed: "ai.txt" is used by at least four unrelated efforts: two independent IETF-style Internet-Drafts covering the same training/scraping/indexing/caching policy domain (draft-car-ai-txt-wellknown and kaylacar/ai-txt), an academic DSL paper covering similar ground with different syntax, and a commercial product (aitxt.ing) that repurposes the name for an unrelated content-description use case. [JSON](/data/protocols/ai-txt.json) · [Markdown](/protocols/ai-txt/index.md) · [OKF v0.2](/okf/protocols/ai-txt.md) --- # AIPREF Content-Usage Attachment (Content-Usage /robots.txt) AIPREF Content-Usage Attachment is an agentic-web standard (well-known file — Content-Usage /robots.txt) at step 3, Permit, governed by IETF AI Preferences Working Group; its status is "Internet-Draft, work in progress". It answers: "How does a publisher attach its AI-use preferences to content served over HTTP, so an automated system can find them?" Replacing or extending robots.txt plus HTTP representation metadata, implementation status is none found (observed on 1/1226 probed origins), last verified 2026-10-23. ## Quick Wire Reference - **Step**: 3 Permit (What may the agent do here?) - **Version**: draft-ietf-aipref-attach-05 (2026-08-19) - **Status**: Internet-Draft, work in progress; "About This Document" note says it is to be… - **Discovery / Probe Path**: /robots.txt — robots.txt directive and/or Content-Usage HTTP response header, both… - **Spec URL**: https://www.ietf.org/archive/id/draft-ietf-aipref-attach-05.html - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: robots.txt plus HTTP representation metadata [Permit](/category/permit/) The AIPREF Content-Usage Attachment draft is an IETF AI Preferences Working Group Internet-Draft that defines how a publisher attaches machine-readable AI-use preferences to HTTP-served content [[1]](#ref-1). It solves the 'where do the preference values live' half of the AIPREF pair: it specifies two attachment mechanisms, a Robots Exclusion Protocol extension (a new directive inside robots.txt) and an HTTP response header field named Content-Usage, and states explicitly that it updates RFC 9309 (the Robots Exclusion Protocol RFC) so the two documents are read together [[1]](#ref-1). ## Overview It does not itself define the vocabulary of preference values — which use categories exist (e.g. AI training, search, input to generative answers) and how they are expressed — that is the companion AIPREF Vocabulary draft (draft-ietf-aipref-vocab), which this document's tokens reference. It also does not define enforcement: like robots.txt, compliance depends entirely on the crawler choosing to read and honour the signal. As of this verification (2026-09-06) the current version is draft-ietf-aipref-attach-05, dated 2026-08-19, confirming the prior finding that -05 was current as of August 2026 [[1]](#ref-1). The document is still explicitly marked as a work in progress with boilerplate noting the 'About This Document' section is to be stripped before RFC publication, and it carries no RFC number yet. Development happens in the open on GitHub under ietf-wg-aipref/drafts with a public issue tracker and mailing list (ai-control@ietf.org) [[1]](#ref-1). Implementers are not named in the draft itself; this record does not find independent evidence of shipping crawlers or CMS/CDN products emitting the Content-Usage header or the new robots.txt directive as of this verification — adoption is unmeasured rather than zero, since a systematic scan was not run for this record. What is unresolved: how this attachment mechanism will interact with the pre-existing, unrelated Cloudflare Content Signals Policy convention, which also extends robots.txt with different signal names (search/ai-input/ai-train) and predates this draft; and whether major crawler operators (Google, OpenAI, Anthropic, Perplexity) will adopt the IETF vocabulary once it reaches RFC status rather than continuing with their own per-vendor robots.txt tokens, which are already in wide use (see ai-crawler-tokens-robots). ## Discovery and probe robots.txt directive and/or Content-Usage HTTP response header, both updating RFC 9309 · /robots.txt ``` GET {origin}/robots.txt parse: Presence of a 'Content-Usage' line in a robots.txt group, or a Content-Usage HTTP response header on the fetched resource itself on absent: Publisher has not attached machine-readable AI-use preferences via either attachment method; no inference can be drawn about actual policy ``` Live check run by [the MCP probe](/mcp/server-card): GET /robots.txt. A Content-Usage line in robots.txt (or HTTP Content-Usage response header on / or /robots.txt) attaches AIPREF preferences to the site. ``` { "path": "/robots.txt", "expect": { "text_match": "(?im)^content-usage:" }, "note": "A Content-Usage line in robots.txt (or HTTP Content-Usage response header on / or /robots.txt) attaches AIPREF preferences to the site." } ``` ## History - 2026-09-05 — seeded from Exa Agent research run - 2026-09-06 — verified against ietf.org/archive/id/draft-ietf-aipref-attach-05.html - 2026-10-16 — use-case tags (auto) ## Instances - [Dries Buytaert (dri.es)](https://dri.es/) · Observed 2026-10-25 · origin Every instance with its source is listed on the [instances page](/instances/). Our probe: seen on 1 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Builds on: [AIPREF Vocabulary](/protocols/aipref-vocabulary/) - Pairs with: [AIPREF Vocabulary](/protocols/aipref-vocabulary/), [AI Crawler User-Agent Tokens in robots.txt](/protocols/ai-crawler-tokens-robots/), [Content Signals Policy](/protocols/cloudflare-content-signals-policy/), [Text and Data Mining Reservation Protocol](/protocols/tdmrep/), [ai.txt](/protocols/ai-txt/), [Really Simple Licensing](/protocols/rsl/) - [AIPREF Vocabulary](/protocols/aipref-vocabulary/) - [Content usage preference](/terms/content-usage-preference/) - Scanners & registries: [IETF aipref working group](https://datatracker.ietf.org/wg/aipref/) ## Comparisons - [robots.txt (Allow/Disallow) vs Content-Signal, AIPREF & TDMRep (classic vs agentic)](/compare/robots-txt-vs-content-signal/) - [AIPREF Content-Usage Attachment vs AIPREF Vocabulary](/compare/aipref-content-usage-attachment-vs-aipref-vocabulary/) ## References - draft-ietf-aipref-attach-05, dated 2026-08-19, defines attachment via the Robots Exclusion Protocol and an HTTP header field, and states it updates RFC 9309. — [https://www.ietf.org/archive/id/draft-ietf-aipref-attach-05.html](https://www.ietf.org/archive/id/draft-ietf-aipref-attach-05.html) (2026-08-19) VERIFIED - The working document is developed on GitHub by the ietf-wg-aipref organization with an issue tracker and a rendered latest draft. — [https://datatracker.ietf.org/doc/html/draft-ietf-aipref-vocab-07](https://datatracker.ietf.org/doc/html/draft-ietf-aipref-vocab-07) (2026-08-19) REPORTED [JSON](/data/protocols/aipref-content-usage-attachment.json) · [Markdown](/protocols/aipref-content-usage-attachment/index.md) · [OKF v0.2](/okf/protocols/aipref-content-usage-attachment.md) --- # AIPREF Vocabulary (/robots.txt) AIPREF Vocabulary is an agentic-web standard (document format — /robots.txt) at step 3, Permit, governed by IETF AI Preferences Working Group; its status is "Internet-Draft, work in progress". It answers: "What controlled set of values expresses a publisher's AI-use preferences, independent of how they are attached to content?" Implementation status is none found (observed on 1/1226 probed origins), last verified 2026-10-23. ## Quick Wire Reference - **Step**: 3 Permit (What may the agent do here?) - **Version**: draft-ietf-aipref-vocab-08 (2026-09-14) - **Status**: Internet-Draft, work in progress; explicitly states its contents 'DO NOT… - **Discovery / Probe Path**: /robots.txt — Not independently discoverable; values are carried by the Content-Usage… - **Spec URL**: https://datatracker.ietf.org/doc/html/draft-ietf-aipref-vocab-08 - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: Controlled metadata vocabulary (like Dublin Core terms) [Permit](/category/permit/) The AIPREF Vocabulary draft is the second half of the IETF AI Preferences Working Group's pair of documents. Where the Content-Usage Attachment draft defines where preference values live (robots.txt directive or HTTP header), this draft defines what those values mean: a controlled vocabulary for declaring restrictions or permissions on how digital assets may be used by automated processing systems [[1]](#ref-1). The two are meant to be read together and are cross-referenced explicitly in the attach draft [[2]](#ref-2). ## Overview It does not define an attachment or discovery mechanism of its own — the vocabulary is inert without the Content-Usage attach draft to carry it — and it does not cover licensing, payment, or compensation terms, which are out of scope for the working group's charter as currently drafted. The current revision is draft-ietf-aipref-vocab-08, dated 2026-09-14 (expiring 2027-03-18), succeeding -07 of 2026-08-19 [[1]](#ref-1)[[3]](#ref-3). The document is unusually explicit about its immaturity: its own 'Note to Readers' states that presence or absence of any particular text does not indicate working-group consensus, and it is published solely as a basis for further discussion [[1]](#ref-1). This is a stronger caveat than the boilerplate carried by most IETF drafts. Governance is the IETF AI Preferences Working Group, with development on GitHub (ietf-wg-aipref/drafts) and discussion on the ai-control@ietf.org list. No implementer of the AIPREF vocabulary specifically (as opposed to the broader Content-Usage attachment surface) was identified in this verification pass; adoption is unmeasured. What is unresolved: the exact set of controlled vocabulary terms was not enumerated in this pass and should be checked against the rendered draft text at the GitHub Pages mirror (ietf-wg-aipref.github.io/drafts/draft-ietf-aipref-vocab.html) in a future review; whether the vocabulary will converge with, or remain distinct from, the pre-existing Cloudflare Content Signals Policy vocabulary (search/ai-input/ai-train) is also unresolved, since the two were developed independently and target overlapping use cases. ## Discovery and probe Not independently discoverable; values are carried by the Content-Usage attachment mechanism (robots.txt directive or HTTP header) ``` GET {origin}/robots.txt parse: Parse any Content-Usage directive value against the AIPREF controlled vocabulary tokens defined in this draft on absent: No AIPREF-vocabulary token found in the attachment surface; cannot distinguish 'no preference stated' from 'publisher uses a different vocabulary (e.g. Cloudflare Content Signals)' ``` Live check run by [the MCP probe](/mcp/server-card): GET /robots.txt. Vocabulary tokens are not validated; a non-empty Content-Usage value in robots.txt (or HTTP Content-Usage response header) is the signal. ``` { "path": "/robots.txt", "expect": { "text_match": "(?im)^content-usage:\\s*\\S" }, "note": "Vocabulary tokens are not validated; a non-empty Content-Usage value in robots.txt (or HTTP Content-Usage response header) is the signal." } ``` ## History - 2026-09-05 — seeded from Exa Agent research run - 2026-09-06 — verified against datatracker.ietf.org/doc/html/draft-ietf-aipref-vocab-07 - 2026-10-16 — revision draft-ietf-aipref-vocab-07 → 08 (watcher) - 2026-10-16 — use-case tags (auto) ## Instances - [Dries Buytaert (dri.es)](https://dri.es/) · Observed 2026-10-25 · origin Every instance with its source is listed on the [instances page](/instances/). Our probe: seen on 1 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Depended on by: [AIPREF Content-Usage Attachment](/protocols/aipref-content-usage-attachment/) - Pairs with: [AIPREF Content-Usage Attachment](/protocols/aipref-content-usage-attachment/), [Content Signals Policy](/protocols/cloudflare-content-signals-policy/), [AI Crawler User-Agent Tokens in robots.txt](/protocols/ai-crawler-tokens-robots/), [Text and Data Mining Reservation Protocol](/protocols/tdmrep/), [Really Simple Licensing](/protocols/rsl/), [agent-permissions.json](/protocols/agent-permissions-json/) - [AIPREF Content-Usage Attachment](/protocols/aipref-content-usage-attachment/) - [Content usage preference](/terms/content-usage-preference/) - Scanners & registries: [IETF aipref working group](https://datatracker.ietf.org/wg/aipref/) ## Comparisons - [robots.txt (Allow/Disallow) vs Content-Signal, AIPREF & TDMRep (classic vs agentic)](/compare/robots-txt-vs-content-signal/) - [Text and Data Mining Reservation Protocol vs AIPREF Vocabulary](/compare/tdmrep-vs-aipref-vocabulary/) - [Really Simple Licensing vs AIPREF Vocabulary](/compare/rsl-vs-aipref-vocabulary/) - [Content Signals Policy vs AIPREF Vocabulary](/compare/cloudflare-content-signals-policy-vs-aipref-vocabulary/) - [AIPREF Content-Usage Attachment vs AIPREF Vocabulary](/compare/aipref-content-usage-attachment-vs-aipref-vocabulary/) ## References - draft-ietf-aipref-vocab-07, dated 2026-08-19, defines a vocabulary for expressing how automated processing systems may use digital assets, and states the document does not yet reflect working-group consensus. — [https://datatracker.ietf.org/doc/html/draft-ietf-aipref-vocab-07](https://datatracker.ietf.org/doc/html/draft-ietf-aipref-vocab-07) (2026-08-19) VERIFIED - The vocabulary draft is developed in the same ietf-wg-aipref/drafts GitHub repository and mailing list as the Content-Usage attachment draft, confirming the two are companion documents. — [https://www.ietf.org/archive/id/draft-ietf-aipref-attach-05.html](https://www.ietf.org/archive/id/draft-ietf-aipref-attach-05.html) (2026-08-19) REPORTED - Datatracker shows draft-ietf-aipref-vocab-08, dated 2026-09-14, expires 2027-03-18 — [https://datatracker.ietf.org/doc/draft-ietf-aipref-vocab/](https://datatracker.ietf.org/doc/draft-ietf-aipref-vocab/) (2026-09-14) VERIFIED [JSON](/data/protocols/aipref-vocabulary.json) · [Markdown](/protocols/aipref-vocabulary/index.md) · [OKF v0.2](/okf/protocols/aipref-vocabulary.md) --- # AITP (Agent Interaction & Transaction Protocol) AITP (Agent Interaction & Transaction Protocol) is an agentic-web standard (endpoint) at step 6, Coordinate, governed by NEAR AI-led open-source specification, MIT licensed; its status is "Version: 0.1.0. Status: Draft. AITP is a spec in progress and…". It answers: "How do two agents representing different, mutually untrusted people or businesses (e.g. a personal assistant and an…?" Implementation status is prototype (NEAR AI), last verified 2026-10-23. ## Quick Wire Reference - **Step**: 6 Coordinate (Talk to another agent) - **Version**: 0.1.0 (Draft) - **Status**: Version: 0.1.0. Status: Draft. "AITP is a spec in progress and we are open to… - **Discovery / Probe Path**: None defined by AITP itself; agents are addressed directly once discovered out of band (e.g.… - **Spec URL**: https://aitp.dev/ - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: HTTP+HTML for agent-to-agent interaction, per the project's own framing [Coordinate](/category/coordinate/) AITP (Agent Interaction & Transaction Protocol), published by NEAR AI, is a draft specification for AI agents to communicate securely across trust boundaries — the project's canonical example is a personal AI assistant booking a flight by talking directly to an airline's own booking agent, exchanging structured flight options, passenger details, and payment information over a shared protocol rather than the assistant scraping the airline's website [[1]](#ref-1). It consists of two parts: a core Threads protocol for the conversation itself, described as 'inspired by and largely compatible with' OpenAI's Assistant/Threads API, and an extensible Capabilities layer — standardized message types agents can negotiate to support structured interactions such as multimodal input, generative UI (forms, buttons), payment requests, and human-in-the-loop attestations [[1]](#ref-1)[[2]](#ref-2). ## Overview AITP explicitly positions itself as complementary to, not competing with, three adjacent categories: same-owner multi-agent orchestration frameworks (CrewAI, Autogen, LangGraph), service-metadata protocols that let agents call existing APIs (MCP, Bitte, llms.txt), and browser-use agents that navigate existing websites (ChatGPT Operator) — the project frames the last of these as merely 'transitional, useful until AITP adoption grows' [[2]](#ref-2). It does not define its own transport-layer security scheme beyond what a chosen Transport (e.g. HTTPS) provides, and does not define agent discovery: personal assistants and service agents are expected to already know how to reach each other, typically via the NEAR AI Hub's own agent registry, which sits outside the AITP spec itself [[1]](#ref-1). As of this check (September 2026), AITP remains at version 0.1.0 and Draft status; the project states plainly that the spec is being written simultaneously with its own reference implementation (NEAR AI Hub agents) and is actively soliciting feedback before a 1.0 release [[1]](#ref-1)[[2]](#ref-2). The only implementations identified are NEAR AI's own — agents built on app.near.ai/agents are claimed by NEAR AI to support all AITP features — with no independent, non-NEAR production adopter confirmed during this verification pass, so adoption here is recorded as claimed rather than measured. What remains unresolved: how AITP's Capabilities layer (particularly payments, which relies on unspecified external settlement rails) will interoperate with the payment-specific protocols already on this map, and whether any framework or platform outside the NEAR ecosystem has committed to implementing AITP ahead of a stable 1.0. ## Discovery and probe None defined by AITP itself; agents are addressed directly once discovered out of band (e.g. via the NEAR AI Hub's own agent registry, which is outside the AITP spec) ``` POST {origin}/threads parse: A response containing a Thread object 'largely compatible with the OpenAI Assistant/Threads API' is necessary but not sufficient; confirming AITP specifically requires observing a Capability-exchange message (per the capabilities schema) rather than plain-text-only thread content. on absent: A 404 or a Threads-API-shaped response with no Capability exchange means this origin either doesn't speak AITP or only speaks the underlying OpenAI-compatible Threads transport without AITP's capability layer. ``` Not probed live: unsafe-post. The probe is POST /threads, which creates a thread. ## History - 2026-09-06 — added from arXiv 2504.16736 survey comparison, verified against aitp.dev, github.com/nearai/aitp - 2026-10-16 — use-case tags (auto) ## Instances - [NEAR AI Shade Workers (AITP Agent Runtime)](https://aitp.dev) · Observed 2026-02-25 · agent Every instance with its source is listed on the [instances page](/instances/). Verified SDKs, reference implementations & validators: - [aitp-py](https://github.com/nearai/aitp) · sdk (2026-09-06) Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Pairs with: [Agent2Agent Protocol](/protocols/a2a/), [Model Context Protocol](/protocols/mcp/), [A2UI (Agent to UI) Protocol](/protocols/a2ui/), [llms.txt](/protocols/llms-txt/), [Agent Payments Protocol](/protocols/ap2/) ## Comparisons - [Webhooks & RPC vs Agent2Agent Protocol (A2A) (classic vs agentic)](/compare/webhooks-vs-a2a/) - [Agent2Agent Protocol vs AITP (Agent Interaction & Transaction Protocol)](/compare/a2a-vs-aitp/) ## References - AITP's homepage states Version: 0.1.0, Status: Draft, and describes the protocol as two parts — a core Threads protocol (inspired by and largely compatible with the OpenAI Assistant/Threads API) and an extensible Capabilities layer for structured interactions like multimodal input, generative UI, payments, and human-in-the-loop attestations. — [https://aitp.dev/](https://aitp.dev/) (2026-09-06) VERIFIED - The nearai/aitp GitHub repository (MIT license, 25 stars, 4 forks) confirms the same version/status and hosts the capability schemas directory; its README frames AITP as complementary to (not a replacement for) multi-agent orchestration frameworks, service-metadata protocols like MCP, and browser-use agents. — [https://github.com/nearai/aitp](https://github.com/nearai/aitp) (2026-09-06) VERIFIED [JSON](/data/protocols/aitp.json) · [Markdown](/protocols/aitp/index.md) · [OKF v0.2](/okf/protocols/aitp.md) --- # An Audit Record Format for AI Agent Authorization Decisions (Agent Audit Record) An Audit Record Format for AI Agent Authorization Decisions (Agent Audit Record) is an agentic-web standard (document format) at step 9, Account, governed by IETF individual Internet-Draft; its status is "Internet-Draft, Intended Status: Informational". It answers: "What should a tamper-evident record of an agent's authorization decision contain?" Replacing or extending a standardised audit-log entry, implementation status is none found, last verified 2026-10-23. ## Quick Wire Reference - **Step**: 9 Account (Prove what happened; be judged) - **Version**: draft-gilda-audit-agent-audit-record-00 (replaces… - **Status**: Internet-Draft (individual), Intended Status: Informational; expires 19 April… - **Discovery / Probe Path**: none; a record format, not a discoverable service - **Spec URL**: https://datatracker.ietf.org/doc/draft-gilda-audit-agent-audit-record/ - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: a standardised audit-log entry [Account](/category/account/) draft-gilda-audit-agent-audit-record defines an audit record format for AI agent authorization decisions: one in-toto predicate type (agent-audit-record) signed in a DSSE envelope. Its -00 revision of 2026-10-16 replaces draft-gilda-wimse-agent-audit-record-02 and builds on WIMSE identifiers and draft-ietf-wimse-aims. ## Overview A record carries the authorization decision, the observed effect and the derived agreement between them, decision-point evaluability and input freshness, the seven minimum audit fields of the WIMSE AIMS framework, and an RFC 8785 JSON canonicalization contract so a third party can recompute consistency from the bytes. It also specifies what a retaining party keeps beside a record so it can later be dated from external anchors. It belongs with the account step beside agent-audit-trail, which covers a hash-chained log of agent actions, and defines a record format exchanged between parties rather than a fixed origin endpoint. ## Discovery and probe none; a record format, not a discoverable service ``` GET none parse: not applicable: audit records are exported from an operator-defined endpoint, not found at a fixed path on absent: No presence signal exists for this record; absence of a probe result says nothing about adoption. ``` Not probed live: no-fixed-path. candidate record; probe rule pending ## History - 2026-10-15 — curated update 2026-10-15 - 2026-10-16 — use-case tags (auto) - 2026-10-17 — Datatracker marks draft-gilda-wimse-agent-audit-record as replaced by draft-gilda-audit-agent-audit-record - 2026-10-20 — renamed draft: label, spec_url, summary and status moved to draft-gilda-audit-agent-audit-record-00 (gap scout 2026-10-20) - 2026-10-20 — noted draft-thaha-wimse-agent-evidence-binding-00, which defines an in-toto predicate designed to compose with this audit record format; from gap scout 2026-10-20, verified against the -00 text (IETF rsync mirror) ## Instances Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Builds on: [Workload Identity in Multi System Environments (WIMSE) Architecture](/protocols/wimse/) - Pairs with: [Agent Audit Trail](/protocols/agent-audit-trail/), [WIMSE AI Identity Management System](/protocols/wimse-aims/), [Workload Identity in Multi System Environments (WIMSE) Architecture](/protocols/wimse/), [SPIFFE (Secure Production Identity Framework for Everyone)](/protocols/spiffe/), [HTTP Message Signatures](/protocols/http-message-signatures/), [AI Agent Execution Profile of SCITT](/protocols/scitt-ai-agent-execution/) - [Audit record](/terms/audit-record/) ## Comparisons - [Cookies, Syslog & T&Cs vs Agent Attribution, OTel GenAI & SCITT (classic vs agentic)](/compare/cookies-syslog-vs-agent-audit-trail/) - [Agent Audit Trail vs An Audit Record Format for AI Agent Authorization Decisions](/compare/agent-audit-trail-vs-wimse-agent-audit-record/) ## References - draft-gilda-wimse-agent-audit-record-02, 'An Audit Record Format for AI Agent Authorization Decisions', is dated 2026-10-05. — [https://datatracker.ietf.org/doc/draft-gilda-wimse-agent-audit-record/](https://datatracker.ietf.org/doc/draft-gilda-wimse-agent-audit-record/) (2026-10-05) VERIFIED - The -02 draft text (October 2026, expires 7 April 2027) defines the record format as an in-toto predicate type. — [https://www.ietf.org/archive/id/draft-gilda-wimse-agent-audit-record-02.html](https://www.ietf.org/archive/id/draft-gilda-wimse-agent-audit-record-02.html) (2026-10-05) VERIFIED - Datatracker marks draft-gilda-wimse-agent-audit-record as replaced by draft-gilda-audit-agent-audit-record — [https://datatracker.ietf.org/doc/draft-gilda-wimse-agent-audit-record/](https://datatracker.ietf.org/doc/draft-gilda-wimse-agent-audit-record/) (2026-10-05) VERIFIED - draft-gilda-audit-agent-audit-record-00 (S. Gilda, 16 October 2026, Informational, expires 19 April 2027) states: 'This document replaces draft-gilda-wimse-agent-audit-record-02.' — [https://datatracker.ietf.org/doc/draft-gilda-audit-agent-audit-record/](https://datatracker.ietf.org/doc/draft-gilda-audit-agent-audit-record/) (2026-10-16) VERIFIED - draft-thaha-wimse-agent-evidence-binding-00 (October 2026) defines an in-toto predicate type for Execution Receipts so they can be carried by the same toolchain as audit records in the format of draft-gilda-wimse-agent-audit-record (an in-toto Statement in a DSSE envelope), and cites that draft's -02 revision. — [https://datatracker.ietf.org/doc/draft-thaha-wimse-agent-evidence-binding/](https://datatracker.ietf.org/doc/draft-thaha-wimse-agent-evidence-binding/) (2026-10-19) VERIFIED [JSON](/data/protocols/wimse-agent-audit-record.json) · [Markdown](/protocols/wimse-agent-audit-record/index.md) · [OKF v0.2](/okf/protocols/wimse-agent-audit-record.md) --- # Anonymous Bot Authentication (ABA) Anonymous Bot Authentication (ABA) is an agentic-web standard (endpoint) at step 2, Identify, governed by Individual Internet-Draft, not adopted by a working group; its status is "Active Internet-Draft, Intended Status: Informational". It answers: "How can a site tell authorised, well-behaved bots from others, and rate-limit them, without learning which bot sent each…?" Implementation status is none found, last verified 2026-10-23. ## Quick Wire Reference - **Step**: 2 Identify (Who is this agent? Who is this site?) - **Version**: draft-rescorla-anonymous-webbotauth-01 (2026-07-19) - **Status**: Active Internet-Draft, Intended Status: Informational; expires 20 January… - **Discovery / Probe Path**: None at an origin: a bot registers with a credential Anchor, receives an Endorsement, redeems… - **Spec URL**: https://datatracker.ietf.org/doc/draft-rescorla-anonymous-webbotauth/ - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: A members-only pass that proves you belong to a club without showing your name [Identify](/category/identify/) Anonymous Bot Authentication (ABA) is an individual IETF draft by Eric Rescorla and Richard Barnes that offers a privacy-preserving alternative to signature-based Web Bot Auth [[1]](#ref-1)[[2]](#ref-2). Bots register with a credential Anchor, which checks them against its policy and issues an anonymous credential. The bot redeems it with a Moderator, run by or cooperating with the site, for a credential it presents later; the site learns only that the request comes from some bot that Anchor endorsed, not which one [[2]](#ref-2). The concrete design builds on the MoLE anonymous-endorsement architecture [[2]](#ref-2). ## Overview The authors argue that identifying every bot lets sites discriminate against bots acting in the public interest, such as price comparison or monitoring for discrimination, and stops people fetching content anonymously with automated tools [[2]](#ref-2). ABA keeps per-bot rate limiting, separate content for bots, access based on criteria, and bot-versus-human classification. It gives up allow and deny lists of individual bots and auditing of what a given bot did [[2]](#ref-2). A site can still treat Anchors differently, and IP addresses or fingerprinting may still identify a bot by other means [[2]](#ref-2). Current state: -01 of 2026-07-19 (the -00 appeared on 2026-04-08), Informational, expiring 2027-01-20, not adopted by the webbotauth WG [[1]](#ref-1). The draft says it has not yet had significant security analysis, and no implementation was found. ## Discovery and probe None at an origin: a bot registers with a credential Anchor, receives an Endorsement, redeems it with a Moderator (run by or for the site) for an anonymous Credential and presents that Credential; the concrete design uses the MoLE architecture ``` NONE parse: on absent: The draft defines no site-side artefact, so support cannot be observed from a site's public endpoints. ``` Not probed live: no-fixed-path. Anonymous credentials are presented per request; no site-side artefact is defined. ## History - 2026-10-20 — added from gap scout 2026-10-20; verified against the datatracker page (via Exa) and the -01 text (IETF rsync mirror) ## Instances Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Pairs with: [Web Bot Auth HTTP Message Signatures](/protocols/webbotauth/), [JAFAR: A JSON-Based Format for Publishing IP Ranges of Automated HTTP Clients](/protocols/jafar/), [Signature Agent Card (Web Bot Auth registry)](/protocols/web-bot-auth-signature-agent-card/) ## Comparisons - [Web Bot Auth HTTP Message Signatures vs Anonymous Bot Authentication](/compare/webbotauth-vs-anonymous-bot-auth/) ## References - Datatracker lists draft-rescorla-anonymous-webbotauth-01 as an active individual Internet-Draft by E. Rescorla (Independent) and R. Barnes (Cisco), Informational, dated 2026-07-19 and expiring 2027-01-20. — [https://datatracker.ietf.org/doc/draft-rescorla-anonymous-webbotauth/](https://datatracker.ietf.org/doc/draft-rescorla-anonymous-webbotauth/) (2026-07-19) VERIFIED - The -01 text describes Anonymous Bot Authentication: bots register with an Anchor and receive anonymous credentials, so a site learns only that a request comes from some bot the Anchor endorsed. It supports per-bot rate limiting, separate content for bots, access conditioned on criteria, traffic classification and unlinkability, but not allow or deny lists of individual bots or auditing; the concrete instantiation uses MoLE (draft-jms-mole-architecture), and it contrasts itself with the signature-based draft-meunier-webbotauth-httpsig-protocol. — [https://www.ietf.org/archive/id/draft-rescorla-anonymous-webbotauth-01.html](https://www.ietf.org/archive/id/draft-rescorla-anonymous-webbotauth-01.html) (2026-07-19) VERIFIED [JSON](/data/protocols/anonymous-bot-auth.json) · [Markdown](/protocols/anonymous-bot-auth/index.md) · [OKF v0.2](/okf/protocols/anonymous-bot-auth.md) --- # AP2 Checkout Mandate AP2 Checkout Mandate is an agentic-web standard (document format) at step 7, Pay, governed by FIDO Alliance / AP2; its status is "AP2 specification component, not an independently published…". It answers: "What exactly did the user approve for checkout?" Replacing or extending Signed purchase order, implementation status is none found, last verified 2026-10-23. ## Quick Wire Reference - **Step**: 7 Pay (Settle the bill) - **Version**: v0.2.0 (2026-04-28) - **Status**: AP2 specification component, not an independently published protocol · none… - **Discovery / Probe Path**: none - **Spec URL**: https://raw.githubusercontent.com/google-agentic-commerce/AP2/main/docs/ap2/checkout_mandate.md - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: Signed purchase order [Pay](/category/pay/) This record is withdrawn as a distinct protocol entry. The "AP2 Checkout Mandate" is not a separate specification: it is one topic page (docs/ap2/checkout_mandate.md) inside the single AP2 specification document tree, defining the Checkout Mandate object and its Checkout Receipt as one of AP2's two Mandate types (the other being the Payment Mandate) [[1]](#ref-1)[[2]](#ref-2). It has no independent governance, repository, versioning, or discovery mechanism apart from AP2 itself — it is versioned, donated to FIDO, and maintained exactly as AP2 is. Content and evidence for this concept has been folded into the ap2 record. This id is kept in the dataset only so a reader who encounters "AP2 Checkout Mandate" as a separate name is redirected rather than finding a dead link. ## Discovery and probe none — see ap2 · none ``` none none parse: not applicable on absent: not applicable; this record is retired, see ap2 ``` Not probed live: needs-credentials. A component of AP2, observable only inside a checkout. ## History - 2026-09-05 — seeded from Exa Agent research run - 2026-09-06 — verified: confirmed this is a component of ap2's specification.md, not a distinct protocol; set phase=withdrawn and merged content into ap2 - 2026-10-16 — use-case tags (auto) - 2026-10-16 — version v0.2.0 (watcher) ## Instances Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Part of: [Agent Payments Protocol](/protocols/ap2/) - Builds on: [Agent Payments Protocol](/protocols/ap2/) - Pairs with: [Agent Payments Protocol](/protocols/ap2/), [Agentic Commerce Protocol](/protocols/agentic-commerce-protocol/), [Visa Trusted Agent Protocol](/protocols/tap/), [EMV Agentic Payments – Framework for Specifications](/protocols/emv-agentic-payments/), [Universal Commerce Protocol](/protocols/ucp/), [Verifiable Intent](/protocols/vi/) - [Mandate](/terms/mandate/) ## References - docs/ap2/checkout_mandate.md is a topic page inside the AP2 specification (docs/ap2/specification.md), not a standalone protocol with its own governance, versioning, or repository. — [https://raw.githubusercontent.com/google-agentic-commerce/AP2/main/docs/ap2/specification.md](https://raw.githubusercontent.com/google-agentic-commerce/AP2/main/docs/ap2/specification.md) VERIFIED - The Checkout Mandate and its Checkout Receipt are defined as part of AP2's Mandates section alongside the Payment Mandate; both mandate types share AP2's roles, verification model, and dispute-evidence design. — [https://raw.githubusercontent.com/google-agentic-commerce/AP2/main/docs/ap2/checkout_mandate.md](https://raw.githubusercontent.com/google-agentic-commerce/AP2/main/docs/ap2/checkout_mandate.md) VERIFIED - v0.2.0 released 2026-04-28 — [https://github.com/google-agentic-commerce/AP2/releases/tag/v0.2.0](https://github.com/google-agentic-commerce/AP2/releases/tag/v0.2.0) (2026-04-28) VERIFIED [JSON](/data/protocols/ap2-checkout-mandate.json) · [Markdown](/protocols/ap2-checkout-mandate/index.md) · [OKF v0.2](/okf/protocols/ap2-checkout-mandate.md) --- # Apache Ossie (formerly Open Semantic Interchange) (OSI) Apache Ossie (formerly Open Semantic Interchange) (OSI) is an agentic-web standard (document format) at step 4, Read, governed by Apache Software Foundation, Apache Incubator; its status is "Undergoing incubation at the Apache Software Foundation)". It answers: "How can an AI agent or BI tool read a metric or data-model definition and get the same meaning another tool intended?" Implementation status is prototype, last verified 2026-10-23. ## Quick Wire Reference - **Step**: 4 Read (Give me the content) - **Version**: 0.2.0.dev0 (draft, in development); last tagged pre-release osi-0.1.1-rc1 - **Status**: Undergoing incubation at the Apache Software Foundation ('Apache Ossie… - **Discovery / Probe Path**: none - **Spec URL**: https://github.com/apache/ossie - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: a shared data dictionary made machine-readable, distributed like a schema file… [Read](/category/read/) OSI/Apache Ossie is a JSON- and YAML-based specification for representing semantic-layer objects (datasets, metrics, dimensions, relationships) so that BI tools, data catalogs and AI/agentic applications compute a term like "churn rate" the same way regardless of which vendor's tool wrote the definition [[1]](#ref-1). It is a document/interchange format, not a network protocol: there is no discovery endpoint or well-known path, and no runtime negotiation. Consumption happens by reading (or generating) a semantic-model file against the published JSON Schema -- which is why this record has been moved from the site's original 'account' placement to 'read': OSI is squarely about machine-readable representations of content (metric/data definitions) for consumption by BI and agent tooling, not about recording or attributing actions after the fact. ## Overview What it does not do: OSI/Ossie does not define an API, an audit trail, an authentication scheme, or a discovery mechanism. It says nothing about who is allowed to read or write a given semantic model, and it does not itself measure or certify adoption. Current state. Snowflake announced OSI on 2025-09-23 with Salesforce, BlackRock, dbt Labs and RelationalAI as co-leads, alongside a larger coalition of BI/data vendors [[1]](#ref-1). On 2026-01-27 Snowflake published "the first version of the OSI specification" as an Apache-2.0 repository and said governance would eventually move to a neutral foundation [[2]](#ref-2). That move happened on 2026-06-22, when the project entered the Apache Incubator as "Apache Ossie (incubating)"; the original open-semantic-interchange GitHub organization now has zero public repositories, and its old repo URL redirects to github.com/apache/ossie [[3]](#ref-3). As of this verification, the live core specification is versioned 0.2.0.dev0 and is explicitly marked DRAFT -- "schema may change before 0.2.0 is released" -- and the only Git tag in the history is a release-candidate, osi-0.1.1-rc1, not a 1.0 [[4]](#ref-4). This means the January 2026 "specification finalized" headline describes the spec's first public release, not a stable/versioned final; readers should not assume OSI has reached a frozen v1.0. Who implements it. The repository ships reference converters for a dozen vendor ecosystems -- Snowflake, Databricks, Salesforce, dbt, GoodData, NVIDIA, Omni, Polaris, Honeydew, Wisdom, OrionBelt and an ontology bridge -- but these live in a converters/ directory of a repo whose core spec is still draft, so they read as reference/example integrations rather than confirmed production deployments; this record conservatively marks implementation as 'prototype' rather than 'multi-implementation.' Disputed / unknown. Whether OSI's broad vendor coalition (dbt Labs, Salesforce, BlackRock, Databricks, Mistral AI and ~30 others) reflects production adoption of the spec itself, or membership in a working group around a still-drafting spec, is not independently measurable from public sources. No probe has been run; adoption is marked unmeasured rather than claimed, because no single party made a countable claim we could cite. The vocabulary used by this site for 'track' does not have a category for an ASF Incubator podling, which is a materially different governance state from an informal community project. ## Discovery and probe none ``` GET https://raw.githubusercontent.com/apache/ossie/main/core-spec/ossie-schema.json parse: Fetch the JSON Schema, then validate a candidate semantic-model file (dataset/metric/dimension document) against it; a pass confirms the file is Ossie/OSI-conformant. There is no fixed well-known path or origin endpoint — OSI/Ossie is an exchanged document format, not a runtime discovery protocol. on absent: If a tool claims 'OSI' or 'Ossie compatibility' but cannot produce a document that validates against this schema, the claim cannot be confirmed. ``` Not probed live: no-fixed-path. OSI is a schema for semantic models exchanged between tools, not an origin artefact. ## History - 2026-09-05 — seeded from Exa Agent research run - 2026-09-06 — verified against github.com/apache/ossie (README, core-spec/spec.md), incubator.apache.org/projects/ossie.html, and Snowflake's 2025-09-23 and 2026-01-27 posts; moved step from 'account' to 'read', corrected spec_url, name, governance, and version; flagged draft-vs-finalized dispute - 2026-10-16 — use-case tags (auto) - 2026-10-16 — version osi-0.1.1-rc1 (watcher) - 2026-10-16 — version label restored to '0.2.0.dev0 (draft, in development); last tagged pre-release osi-0.1.1-rc1'; the repository's latest tag (osi-0.1.1-rc1) is a package, SDK or build tag, not the specification version, so the GitHub watch no longer drives version ## Instances Verified SDKs, reference implementations & validators: - [Ossie converters: dbt](https://github.com/apache/ossie-converters/tree/main/dbt) · implementation (2026-09-05) - [Ossie converters: Salesforce](https://github.com/apache/ossie-converters/tree/main/salesforce) · implementation (2026-09-05) - [Ossie converters: Databricks](https://github.com/apache/ossie-converters/tree/main/databricks) · implementation (2026-09-05) - [Ossie converters: Snowflake](https://github.com/apache/ossie-converters/tree/main/snowflake) · implementation (2026-09-05) - [Ossie converters: GoodData](https://github.com/apache/ossie-converters/tree/main/gooddata) · implementation (2026-09-05) - [Ossie schema validation tooling](https://github.com/apache/ossie/tree/main/validation) · validator (2026-09-05) Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Not to be confused with: Open Source Initiative (osi.org) ## Comparisons - [HTML DOM & RSS vs Accept: text/markdown & OKF (classic vs agentic)](/compare/html-dom-vs-markdown-for-agents/) - [Apache Ossie (formerly Open Semantic Interchange) vs Open Knowledge Format](/compare/osi-vs-okf/) ## References - Snowflake announced the Open Semantic Interchange initiative on 2025-09-23 with Salesforce, BlackRock, dbt Labs and RelationalAI as co-leading partners, plus a wider coalition (Alation, Atlan, Tableau, ThoughtSpot, Sigma, Omni and others). — [https://www.snowflake.com/en/news/press-releases/snowflake-salesforce-dbt-labs-and-more-revolutionize-data-readiness-for-ai-with-open-semantic-interchange-initiative/](https://www.snowflake.com/en/news/press-releases/snowflake-salesforce-dbt-labs-and-more-revolutionize-data-readiness-for-ai-with-open-semantic-interchange-initiative/) (2025-09-23) VERIFIED - Snowflake's 2026-01-27 post says 'the first version of the OSI specification is now available' via an Apache-2.0 licensed repo at github.com/open-semantic-interchange/OSI, and that OSI would later move to 'a neutral, foundation-led governance model.' — [https://www.snowflake.com/en/blog/open-semantic-interchanges-specs-finalized/](https://www.snowflake.com/en/blog/open-semantic-interchanges-specs-finalized/) (2026-01-27) VERIFIED - The project entered the Apache Incubator on 2026-06-22 as 'Apache Ossie (incubating)'; the original open-semantic-interchange GitHub org now shows 0 public repositories and github.com/open-semantic-interchange/OSI redirects to github.com/apache/ossie. — [https://incubator.apache.org/projects/ossie.html](https://incubator.apache.org/projects/ossie.html) (2026-06-22) VERIFIED - The current core specification file (core-spec/spec.md) is headed 'DRAFT version -- in development, schema may change before 0.2.0 is released' and labelled Version 0.2.0.dev0; the repository's only Git tag is osi-0.1.1-rc1, not a v1.0 -- contradicting the 'specification finalized' framing of the January 2026 announcement. — [https://raw.githubusercontent.com/apache/ossie/main/core-spec/spec.md](https://raw.githubusercontent.com/apache/ossie/main/core-spec/spec.md) (2026-09-05) VERIFIED - latest tag osi-0.1.1-rc1 — [https://github.com/apache/ossie/releases/tag/osi-0.1.1-rc1](https://github.com/apache/ossie/releases/tag/osi-0.1.1-rc1) (2026-10-15) VERIFIED Disputed: Snowflake's January 2026 post is titled 'OSI Specification Finalized,' but the specification text in the repository is versioned 0.2.0.dev0 and explicitly marked DRAFT, with the only tagged release a release-candidate (osi-0.1.1-rc1). 'Finalized' appears to describe the *initial publication* of a spec document, not a stable/final version number. Separately, vocab.json has no track value for 'Apache Software Foundation incubator project' distinct from 'linux-foundation' (LF-specific) or 'industry-body' (trade association); 'community' was chosen as the least-wrong fit but understates that Ossie now has ASF Incubator governance (mentors, PPMC, a defined graduation process) rather than no formal governance. [JSON](/data/protocols/osi.json) · [Markdown](/protocols/osi/index.md) · [OKF v0.2](/okf/protocols/osi.md) --- # api-catalog: A Well-Known URI and Link Relation to Help Discovery of APIs (RFC 9727 · /.well-known/api-catalog) api-catalog: A Well-Known URI and Link Relation to Help Discovery of APIs (RFC 9727) is an agentic-web standard (well-known file — /.well-known/api-catalog) at step 1, Discover, governed by IETF; its status is "Proposed Standard". It answers: "Given a publisher's domain, where is the machine-readable list of the APIs it exposes?" Replacing or extending sitemap.xml, but for APIs instead of pages, implementation status is multi-implementation (observed on 132/1226 probed origins), last verified 2026-10-23. ## Quick Wire Reference - **Step**: 1 Discover (What is here, and where?) - **Version**: RFC 9727 (2025-06) - **Status**: Proposed Standard (errata exist) · multi-implementation - **Discovery / Probe Path**: /.well-known/api-catalog — well-known URI plus an 'api-catalog' HTTP Link header / HTML link… - **Spec URL**: https://www.rfc-editor.org/rfc/rfc9727.html - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: sitemap.xml, but for APIs instead of pages [Discover](/category/discover/) RFC 9727 defines the "api-catalog" well-known URI and a matching "api-catalog" link relation, intended to facilitate automated discovery of a Publisher's APIs [[1]](#ref-1). It is a Standards Track IETF RFC, published June 2025, with the IETF itself as change controller and a single named author, Kevin Smith of Vodafone [[1]](#ref-1). It predates the current wave of agent-discovery specifications (ARD, DNS-AID, AID, ADP, ARDP, ADS) by roughly a year, and is not agent-specific: it is a general web-API discovery mechanism that this map's occupant-diff process flagged as relevant because it addresses the same "where are this domain's machine-callable capabilities" question the agentic-web specs are now re-solving with different formats. ## Overview It solves API discovery for a domain's own APIs: a publisher hosts a document at /.well-known/api-catalog (or elsewhere, pointed to by the link relation) listing hyperlinks to its API endpoints, in the mandatory Linkset format (application/linkset+json, itself defined by RFC 9264) [[1]](#ref-1). A GET request must return the catalog document; a HEAD request must return a Link header carrying the relation [[1]](#ref-1). The catalog can nest -- one api-catalog document can point to others via further api-catalog-relation links -- which the RFC recommends for publishers with APIs spread across multiple domains or too many APIs for one flat list [[1]](#ref-1). Publishers already using a different catalog format (APIs.json, RESTdesc, HAL, or a schema.org WebAPI extension) may keep it and additionally expose a minimal Linkset-format catalog to satisfy this RFC, using content negotiation to serve either [[1]](#ref-1). It does not mandate any particular path for the API endpoints themselves, does not require the catalog to be hosted on the same domain it describes (a publisher can point to a third party's catalog for APIs it does not control), and does not define authentication, versioning policy, or any agent-specific semantics -- it is a pure discovery/link-relation mechanism aimed at human developers and their tooling, not agents specifically [[1]](#ref-1). Security guidance is largely operational: use TLS, avoid leaking internal/private APIs into a public catalog, and rate-limit the endpoint [[1]](#ref-1). Current state: RFC 9727 is a published Proposed Standard with known errata on file at the RFC Errata system, and carries no revision history beyond the original June 2025 text and its errata [[1]](#ref-1). No independent adoption count was located during this verification pass -- the RFC's own text does not claim any deployments, and no third-party survey was found in the sources read. What is disputed or unknown: whether this general-purpose, agent-agnostic mechanism will be adopted, ignored, or superseded by the newer agent-specific well-known conventions (ARD's ard.json, ADP's agent.json) that solve an overlapping but not identical problem -- API discovery generically versus agentic-resource discovery specifically -- and whether any publisher serves both /.well-known/api-catalog and one of the newer agent-specific manifests at the same origin. ## Discovery and probe well-known URI plus an 'api-catalog' HTTP Link header / HTML link relation · /.well-known/api-catalog ``` GET https://{origin}/.well-known/api-catalog parse: 200 response with Content-Type application/linkset+json, body containing a top-level "linkset" array whose entries carry "item" (or other) link relations to API endpoints; a HEAD request instead returns a Link header with rel=api-catalog on absent: Publisher does not expose an RFC 9727 API catalog at the well-known location; check for an 'api-catalog' Link header or on the site's root response instead, since the RFC allows the catalog to live at any URI the publisher chooses ``` Live check run by [the MCP probe](/mcp/server-card): GET /.well-known/api-catalog. RFC 9727 requires application/linkset+json with a linkset array at /.well-known/api-catalog (probe and validate_manifest also observe Link: rel=api-catalog headers on /). ``` { "path": "/.well-known/api-catalog", "expect": { "content_type": "linkset", "json_keys": [ "linkset" ] }, "note": "RFC 9727 requires application/linkset+json with a linkset array at /.well-known/api-catalog (probe and validate_manifest also observe Link: rel=api-catalog headers on /)." } ``` ## History - 2026-09-06 — new record created from the occupant-diff candidate list; verified against RFC 9727 text via rfc-editor.org - 2026-09-06 — fix round 1: added second evidence entry (IANA Well-Known URIs registry, fetched directly) confirming permanent registration - 2026-10-16 — use-case tags (auto) ## Instances - [Zuplo API Gateway (zuplo.com)](https://zuplo.com/) · Observed 2026-10-25 · origin - [Zep Long-Term Agent Memory (getzep.com)](https://getzep.com/) · Observed 2026-10-25 · origin - [Zapier (zapier.com)](https://zapier.com/) · Observed 2026-10-25 · origin - [Wistia (wistia.com)](https://wistia.com/) · Observed 2026-10-25 · origin - [Webflow Developers (developers.webflow.com)](https://developers.webflow.com/) · Observed 2026-10-25 · origin - [Warp Agentic Terminal (warp.dev)](https://warp.dev/) · Observed 2026-10-25 · origin - [Vellum AI Workflow Platform (vellum.ai)](https://vellum.ai/) · Observed 2026-10-25 · origin - [Vast.ai (vast.ai)](https://vast.ai/) · Observed 2026-10-25 · origin - [tldraw Infinite Canvas SDK (tldraw.com)](https://tldraw.com/) · Observed 2026-10-25 · origin - [SurrealDB (surrealdb.com)](https://surrealdb.com/) · Observed 2026-10-25 · origin - [Supermemory (supermemory.ai)](https://supermemory.ai/) · Observed 2026-10-25 · origin - [Supabase (supabase.com)](https://supabase.com/) · Observed 2026-10-25 · origin - [StackOne Agentic Integration Hub (stackone.com)](https://stackone.com/) · Observed 2026-10-25 · origin - [Speakeasy (speakeasy.com)](https://speakeasy.com/) · Observed 2026-10-25 · origin - [Skyvern Browser Automation Agent (skyvern.com)](https://skyvern.com/) · Observed 2026-10-25 · origin - [Sentry (sentry.io)](https://sentry.io/) · Observed 2026-10-25 · origin - [Scalar API Platform (scalar.com)](https://scalar.com/) · Observed 2026-10-25 · origin - [SavvyCal (savvycal.com)](https://savvycal.com/) · Observed 2026-10-25 · origin - [Sanity Content Operating System (sanity.io)](https://sanity.io/) · Observed 2026-10-25 · origin - [RunPod GPU Cloud (runpod.io)](https://runpod.io/) · Observed 2026-10-25 · origin - [Replicate (replicate.com)](https://replicate.com/) · Observed 2026-10-25 · origin - [Reducto Document AI (reducto.ai)](https://reducto.ai/) · Observed 2026-10-25 · origin - [Pydantic & Logfire (pydantic.dev)](https://pydantic.dev/) · Observed 2026-10-25 · origin - [Publica.la (publica.la)](https://publica.la/) · Observed 2026-10-25 · origin - [Proof API (api.proof.com)](https://api.proof.com/.well-known/ard.json) · Observed 2026-10-25 · origin - [Podscan Podcast Intelligence API (podscan.fm)](https://podscan.fm/) · Observed 2026-10-25 · origin - [PlanetScale (planetscale.com)](https://planetscale.com/) · Observed 2026-10-25 · origin - [Perplexity API Docs (docs.perplexity.ai)](https://docs.perplexity.ai/) · Observed 2026-10-25 · origin - [OpenStatus (openstatus.dev)](https://openstatus.dev/) · Observed 2026-10-25 · origin - [Novita AI (novita.ai)](https://novita.ai/) · Observed 2026-10-25 · origin - [Morph Fast Apply LLM (morphllm.com)](https://morphllm.com/) · Observed 2026-10-25 · origin - [Model Context Protocol Docs (modelcontextprotocol.io)](https://modelcontextprotocol.io/) · Observed 2026-10-25 · origin - [MetricSpot (metricspot.com)](https://metricspot.com/) · Observed 2026-10-25 · origin - [LibreChat Open-Source AI Workspace (librechat.ai)](https://librechat.ai/) · Observed 2026-10-25 · origin - [Lago (getlago.com)](https://getlago.com/) · Observed 2026-10-25 · origin - [Kent C. Dodds (kentcdodds.com)](https://kentcdodds.com/) · Observed 2026-10-25 · origin - [Infisical Secrets Management (infisical.com)](https://infisical.com/) · Observed 2026-10-25 · origin - [Hostinger (hostinger.com)](https://hostinger.com/) · Observed 2026-10-25 · origin - [Glama MCP Gateway & Directory (glama.ai)](https://glama.ai/) · Observed 2026-10-25 · origin - [Fly.io (fly.io)](https://fly.io/) · Observed 2026-10-25 · origin - [Eodly (eodly.io)](https://eodly.io/) · Observed 2026-10-25 · origin - [Dries Buytaert (dri.es)](https://dri.es/) · Observed 2026-10-25 · origin - [DC Hub (dchub.cloud)](https://dchub.cloud/) · Observed 2026-10-25 · origin - [Customer.io (customer.io)](https://customer.io/) · Observed 2026-10-25 · origin - [crewai.com](https://crewai.com/) · Observed 2026-10-25 · origin - [Convex Reactive Backend (convex.dev)](https://convex.dev/) · Observed 2026-10-25 · origin - [Coinbase (coinbase.com)](https://coinbase.com/) · Observed 2026-10-25 · origin - [Cal.com Scheduling Infrastructure (cal.com)](https://cal.com/) · Observed 2026-10-25 · origin - [Bird (bird.com)](https://bird.com/) · Observed 2026-10-25 · origin - [Better Stack Observability (betterstack.com)](https://betterstack.com/) · Observed 2026-10-25 · origin - [beehiiv Newsletter Platform (beehiiv.com)](https://beehiiv.com/) · Observed 2026-10-25 · origin - [Baseten Docs (docs.baseten.co)](https://docs.baseten.co/) · Observed 2026-10-25 · origin - [Augment Code Docs (docs.augmentcode.com)](https://docs.augmentcode.com/) · Observed 2026-10-25 · origin - [Attio Docs (docs.attio.com)](https://docs.attio.com/) · Observed 2026-10-25 · origin - [Atlan (atlan.com)](https://atlan.com/) · Observed 2026-10-25 · origin - [Arcade AI Tool-Calling Runtime (arcade.dev)](https://arcade.dev/) · Observed 2026-10-25 · origin - [Apideck Unified API (apideck.com)](https://apideck.com/) · Observed 2026-10-25 · origin - [Amplitude (amplitude.com)](https://amplitude.com/) · Observed 2026-10-25 · origin - [Agent Skills Specification (agentskills.io)](https://agentskills.io/) · Observed 2026-10-25 · origin - [Agent Client Protocol (agentclientprotocol.com)](https://agentclientprotocol.com/) · Observed 2026-10-25 · origin - [AG-UI Documentation Origin (docs.ag-ui.com)](https://docs.ag-ui.com/) · Observed 2026-10-25 · origin - [Ad Context Protocol Docs (docs.adcontextprotocol.org)](https://docs.adcontextprotocol.org/) · Observed 2026-10-25 · origin - [2s.io](https://2s.io/) · Observed 2026-10-25 · origin - [x402 Foundation Spec Origin (x402.org)](https://x402.org/) · Observed 2026-10-23 · origin - [Vercel (vercel.com)](https://vercel.com/) · Observed 2026-10-23 · origin - [Telnyx (telnyx.com)](https://telnyx.com/) · Observed 2026-10-23 · origin - [Resend (resend.com)](https://resend.com/) · Observed 2026-10-23 · origin - [Railway (railway.com)](https://railway.com/) · Observed 2026-10-23 · origin - [QuickNode (quicknode.com)](https://quicknode.com/) · Observed 2026-10-23 · origin - [Neuronto Agentic Web Index](https://neuronto.com) · Observed 2026-10-23 · venue - [Neon Serverless Postgres (neon.com)](https://neon.com/) · Observed 2026-10-23 · origin - [IMG.LY (img.ly)](https://img.ly/) · Observed 2026-10-23 · origin - [Hugging Face (huggingface.co)](https://huggingface.co/) · Observed 2026-10-23 · origin - [ClickHouse (clickhouse.com)](https://clickhouse.com/) · Observed 2026-10-23 · origin - [blog.cloudflare.com](https://blog.cloudflare.com/) · Observed 2026-10-23 · origin - [Apify (apify.com)](https://apify.com/) · Observed 2026-10-23 · origin - [agenticweb.wiki Reference Agent and MCP Server](https://agenticweb.wiki) · Observed 2026-10-23 · agent - [agent-ready.dev Conformance Scanner Agent](https://agent-ready.dev) · Observed 2026-10-23 · agent Every instance with its source is listed on the [instances page](/instances/). Our probe: seen on 132 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Pairs with: [Agentic Resource Discovery](/protocols/ard/), [DNS for AI Discovery](/protocols/dns-aid/), [AI Catalog well-known file](/protocols/ai-catalog-well-known-file/), [MCP Server Cards (SEP-2127)](/protocols/mcp-server-cards/), [agents.json](/protocols/agents-json/), [OAuth Protected Resource and Authorization Server Metadata (as used for agent authorization)](/protocols/oauth-metadata-for-agents/) - [API Catalog (RFC 9727)](/terms/api-catalog/) - Not to be confused with: Not to be confused with the ARD ecosystem's ai-catalog.json well-known file (see ard), a different, agent-specific well-known artifact with no normative relationship to this RFC ## Comparisons - [OpenAPI & REST APIs vs Model Context Protocol (MCP) (classic vs agentic)](/compare/openapi-vs-mcp/) - [sitemap.xml vs llms.txt & ARD (classic vs agentic)](/compare/sitemap-xml-vs-llms-txt/) - [Agentic Resource Discovery vs api-catalog: A Well-Known URI and Link Relation to Help Discovery of APIs](/compare/ard-vs-api-catalog-rfc9727/) - [api-catalog: A Well-Known URI and Link Relation to Help Discovery of APIs vs The 'knowledge-linkset' Well-Known URI for Publishing Knowledge Artefacts](/compare/api-catalog-rfc9727-vs-knowledge-linkset/) ## References - RFC 9727 (June 2025, Standards Track, sole author Kevin Smith/Vodafone) defines the api-catalog well-known URI and link relation; a publisher MUST resolve GET /.well-known/api-catalog to an API catalog document in the Linkset format (application/linkset+json per RFC 9264), and MAY additionally offer other formats via content negotiation or a different hosting location signposted by the api-catalog link relation. — [https://www.rfc-editor.org/rfc/rfc9727.html](https://www.rfc-editor.org/rfc/rfc9727.html) (2025-06) VERIFIED - IANA's Well-Known URIs registry (fetched 2026-09-06) lists "api-catalog" as a permanent registration, reference RFC9727, change controller IETF, registered 2024-12-23 -- independent confirmation that this well-known path is formally registered and not merely proposed in the RFC text. — [https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml](https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml) (2026-09-06) VERIFIED [JSON](/data/protocols/api-catalog-rfc9727.json) · [Markdown](/protocols/api-catalog-rfc9727/index.md) · [OKF v0.2](/okf/protocols/api-catalog-rfc9727.md) --- # Attenuated Delegation Profile for Automated Agents Attenuated Delegation Profile for Automated Agents is an agentic-web standard (HTTP header) at step 3, Permit, governed by Individual IETF Internet-Draft targeting the OAuth Working Group; its status is "Active Internet-Draft, Intended status: Standards Track". It answers: "How can an automated agent pass on a user's authority so that each hop can only narrow scope, floors, and expiry?" Implementation status is none found, last verified 2026-10-24. ## Quick Wire Reference - **Step**: 3 Permit (What may the agent do here?) - **Version**: draft-hamr-oauth-agent-delegation-03 (2026-10-22) - **Status**: Active Internet-Draft (individual submission), Intended status: Standards… - **Discovery / Probe Path**: An Agent-Delegation HTTP header on a request signed with RFC 9421. No well-known file is… - **Spec URL**: https://datatracker.ietf.org/doc/html/draft-hamr-oauth-agent-delegation-03 - **Last Verified**: 2026-10-24 (current) - **Classic Web Analog**: A signed chain of authority on an HTTP request, each hop narrower than the last [Permit](/category/permit/) draft-hamr-oauth-agent-delegation-03 is a Standards Track Internet-Draft of the IETF OAuth working group, dated 22 October 2026 and expiring 25 April 2027 (succeeding -02 of 19 September 2026) [[1]](#ref-1)[[3]](#ref-3). It defines an Agent-Delegation HTTP header on top of RFC 9421 HTTP Message Signatures [[1]](#ref-1). Each link in the chain can only narrow scope, floors, and expiry. Call classes are r, w, and x [[1]](#ref-1). ## Overview It is a separate record from the Workload Authorization Grant, the identity-continuation assertion, and both AAP documents. The datatracker entry for the draft is [[2]](#ref-2). ## Discovery and probe An Agent-Delegation HTTP header on a request signed with RFC 9421. No well-known file is defined. ``` n/a n/a (Agent-Delegation request header; no fixed origin artifact) parse: n/a. Look for an Agent-Delegation header on a request signed under RFC 9421. Call classes are r, w, and x. Each link can only narrow scope, floors, and expiry. on absent: No Agent-Delegation header on a given request means this profile was not used for that call. ``` Not probed live: no-fixed-path. Agent-Delegation is an HTTP header on a request signed with RFC 9421; there is no fixed path to fetch. ## History - 2026-10-20 — added from staged research 2026-10-20; header read from draft-hamr-oauth-agent-delegation-02 - 2026-10-23 — revision 02 → 03 (watcher) ## Instances Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Builds on: [HTTP Message Signatures](/protocols/http-message-signatures/) - Pairs with: [HTTP Message Signatures](/protocols/http-message-signatures/), [Identity Assertion JWT Authorization Grant](/protocols/identity-assertion-authz-grant/), [Workload Authorization Grant](/protocols/workload-authz-grant/), [Identity Continuation Assertion for OAuth 2.0 Token Exchange](/protocols/oauth-id-continuation/), [OpenA2A Agent Authorization Protocol](/protocols/opena2a-aap/) - Not to be confused with: Agent Authorization Profile (draft-aap-oauth-profile) and OpenA2A AAP, which are token models rather than this header ## References - draft-hamr-oauth-agent-delegation-02 is a Standards Track Internet-Draft of the Web Authorization Protocol (OAuth) working group, dated 19 September 2026 and expiring 23 March 2027. It defines an Agent-Delegation HTTP header on top of RFC 9421. Each link can only narrow scope, floors, and expiry. Call classes are r, w, and x. — [https://www.ietf.org/archive/id/draft-hamr-oauth-agent-delegation-02.txt](https://www.ietf.org/archive/id/draft-hamr-oauth-agent-delegation-02.txt) (2026-09-19) VERIFIED - Datatracker document page for draft-hamr-oauth-agent-delegation. — [https://datatracker.ietf.org/doc/draft-hamr-oauth-agent-delegation/](https://datatracker.ietf.org/doc/draft-hamr-oauth-agent-delegation/) (2026-09-19) VERIFIED - Datatracker shows draft-hamr-oauth-agent-delegation-03, dated 2026-10-22, expires 2027-04-25 — [https://datatracker.ietf.org/doc/draft-hamr-oauth-agent-delegation/](https://datatracker.ietf.org/doc/draft-hamr-oauth-agent-delegation/) (2026-10-22) VERIFIED [JSON](/data/protocols/oauth-agent-delegation.json) · [Markdown](/protocols/oauth-agent-delegation/index.md) · [OKF v0.2](/okf/protocols/oauth-agent-delegation.md) --- # auth.md (/auth.md) auth.md is an agentic-web standard (document format — /auth.md) at step 3, Permit, governed by Single vendor; its status is "Published protocol specification at auth-md.com/specification". It answers: "How does an AI agent register a new account for its user on a service, without a human filling out a sign-up form or an…?" Replacing or extending Self-service sign-up form, implementation status is multi-implementation (auth-md.com, which lists Resend, Cloudflare…; observed on 23/1226 probed origins), last verified 2026-10-24. ## Quick Wire Reference - **Step**: 3 Permit (What may the agent do here?) - **Version**: Launched 2026-06, current spec undated beyond launch (2026-06) - **Status**: Published protocol specification at auth-md.com/specification; not submitted… - **Discovery / Probe Path**: /auth.md — A markdown convention file at the site root, cross-referenced with RFC… - **Spec URL**: https://auth-md.com/auth.md - **Last Verified**: 2026-10-24 (current) - **Classic Web Analog**: Self-service sign-up form [Permit](/category/permit/) auth.md is a single-vendor protocol, launched by WorkOS-affiliated auth-md.com at MCP Night 4 during the AI Engineer World's Fair 2026, that lets an AI agent register a new user account on a service directly, without a human filling out a sign-up form or an existing OAuth client registration [[1]](#ref-1). It targets a specific gap in the permit space: existing OAuth flows assume a client and a resource server already have a trust relationship (a registered client_id); auth.md instead lets a never-before-seen agent discover how to create that relationship in the first place. ## Overview The published specification defines three registration flows: an 'identity_assertion' flow where the agent's own identity provider vouches for the user via an ID-JAG (an emerging IETF identity-assertion mechanism) and registration completes with no human present; a 'service_auth' flow; and an 'anonymous' flow using an OTP the human reads back to the agent to bind the new account to the right person [[1]](#ref-1). auth.md is explicitly built as a thin composition layer on top of two existing IETF specs rather than a replacement for OAuth: discovery starts from a 401 response whose WWW-Authenticate header points to RFC 9728 Protected Resource Metadata at /.well-known/oauth-protected-resource, which in turn points to RFC 8414 Authorization Server Metadata [[1]](#ref-1). It does not define payment (the vendor's own materials pair it with x402 for that), and it does not define content-use permissions — its scope is strictly account creation. It is not on any standards track; auth-md.com is a commercial site operated in connection with WorkOS and credits an individual founder, Fabricio Telles. As of this verification (2026-09-06), the specification text is published and internally coherent, and the vendor's own homepage names nine companies as already serving their own auth.md file (Resend, Cloudflare, Firecrawl, Ora.ai, here.now, mailbox.bot, agents-txt.com, WorkOS, and Alpic), each linked to that company's specific URL [[2]](#ref-2). Because this adoption count is self-reported by auth-md.com rather than independently measured by this wiki's own probe, the adoption level is recorded as claimed (by auth-md.com), not measured; implementation is recorded as multi-implementation on the strength of multiple named, independent adopting companies, though this pass did not fetch each named company's individual /auth.md file to confirm live service. What is unresolved: whether ID-JAG, the identity-assertion mechanism the strongest flow depends on, is itself standardized enough to interoperate across identity providers (it is described here as 'an emerging IETF draft'); how widely auth.md is adopted beyond the launch partners named on its own site; and how it will be distinguished in practice from the unrelated, independently-developed ACT-AUTH.md convention found in the actcore/act-spec repository, which addresses similar agent-credential ground under the same filename pattern. ## Discovery and probe A markdown convention file at the site root, cross-referenced with RFC 9728 Protected Resource Metadata for the actual OAuth exchange · /auth.md ``` GET {origin}/auth.md parse: A markdown document describing one or more of the three named flows (identity_assertion, service_auth, anonymous) and referencing /.well-known/oauth-protected-resource and /.well-known/oauth-authorization-server per RFC 9728/8414 on absent: No auth.md file at the site root; the service has not published an agent self-registration convention ``` Live check run by [the MCP probe](/mcp/server-card): GET /auth.md. auth.md describes one or more of the three named flows. ``` { "path": "/auth.md", "expect": { "text_match": "identity_assertion|service_auth|anonymous" }, "note": "auth.md describes one or more of the three named flows." } ``` ## History - 2026-09-06 — created and verified against auth-md.com/specification and auth-md.com (occupant-diff candidate) - 2026-10-16 — use-case tags (auto) ## Instances - [tldraw Infinite Canvas SDK (tldraw.com)](https://tldraw.com/) · Observed 2026-10-25 · origin - [SurrealDB (surrealdb.com)](https://surrealdb.com/) · Observed 2026-10-25 · origin - [Scalar API Platform (scalar.com)](https://scalar.com/) · Observed 2026-10-25 · origin - [Publica.la (publica.la)](https://publica.la/) · Observed 2026-10-25 · origin - [Mintlify (mintlify.com)](https://mintlify.com/) · Observed 2026-10-25 · origin - [Hostinger (hostinger.com)](https://hostinger.com/) · Observed 2026-10-25 · origin - [Fly.io (fly.io)](https://fly.io/) · Observed 2026-10-25 · origin - [WorkOS AuthKit and Agent Auth](https://workos.com) · Observed 2026-10-23 · authority - [Webhooks.cc (webhooks.cc)](https://webhooks.cc/) · Observed 2026-10-23 · origin - [Telnyx (telnyx.com)](https://telnyx.com/) · Observed 2026-10-23 · origin - [QuickNode (quicknode.com)](https://quicknode.com/) · Observed 2026-10-23 · origin - [Neon Serverless Postgres (neon.com)](https://neon.com/) · Observed 2026-10-23 · origin - [Firecrawl (firecrawl.dev)](https://firecrawl.dev/) · Observed 2026-10-23 · origin - [Cloudflare (cloudflare.com)](https://cloudflare.com/) · Observed 2026-10-23 · origin - [agenticweb.wiki Reference Agent and MCP Server](https://agenticweb.wiki) · Observed 2026-10-23 · agent - [agent-ready.dev Conformance Scanner Agent](https://agent-ready.dev) · Observed 2026-10-23 · agent Every instance with its source is listed on the [instances page](/instances/). Verified SDKs, reference implementations & validators: - [auth-md.com specification and reference skill](https://auth-md.com/specification) · implementation (2026-06) Our probe: seen on 23 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Builds on: [OAuth Protected Resource and Authorization Server Metadata (as used for agent authorization)](/protocols/oauth-metadata-for-agents/), [Identity Assertion JWT Authorization Grant](/protocols/identity-assertion-authz-grant/) - Pairs with: [Identity Assertion JWT Authorization Grant](/protocols/identity-assertion-authz-grant/), [OAuth Protected Resource and Authorization Server Metadata (as used for agent authorization)](/protocols/oauth-metadata-for-agents/), [x402](/protocols/x402/), [agents.txt](/protocols/agents-txt/), [Model Context Protocol](/protocols/mcp/) - [Signed agent](/terms/signed-agent/) - [Protected Resource Metadata](/terms/protected-resource-metadata/) - Not to be confused with: Not to be confused with the unrelated ACT-AUTH.md convention published in the actcore/act-spec repository, which addresses similar ground independently ## Comparisons - [OAuth 2.0 Consent & DCR vs CIMD & Agent OAuth Metadata (classic vs agentic)](/compare/oauth-vs-cimd/) - [OAuth Protected Resource and Authorization Server Metadata (as used for agent authorization) vs auth.md](/compare/oauth-metadata-for-agents-vs-auth-md/) - [agent-permissions.json vs auth.md](/compare/agent-permissions-json-vs-auth-md/) ## References - auth-md.com's own specification page defines three registration flows (identity_assertion + ID-JAG, service_auth, anonymous), a discovery sequence built on RFC 9728 Protected Resource Metadata and RFC 8414 Authorization Server Metadata, and states the protocol was launched at MCP Night 4 / AI Engineer World's Fair 2026. — [https://auth-md.com/auth.md](https://auth-md.com/auth.md) (2026-06) VERIFIED - The auth-md.com homepage names Resend, Cloudflare, Firecrawl, Ora.ai, here.now, mailbox.bot, agents-txt.com, WorkOS, and Alpic as parties already publishing an auth.md file, each linked to that company's own /auth.md URL. — [https://auth-md.com/](https://auth-md.com/) (2026-06) REPORTED [JSON](/data/protocols/auth-md.json) · [Markdown](/protocols/auth-md/index.md) · [OKF v0.2](/okf/protocols/auth-md.md) --- # Cloudflare Pay per crawl Cloudflare Pay per crawl is an agentic-web standard (HTTP header) at step 7, Pay, governed by Cloudflare; its status is "Closed beta". It answers: "How can a site charge an AI crawler per request, and how does the crawler agree to pay?" Replacing or extending HTTP 402 Payment Required, used for crawl access, implementation status is prototype, last verified 2026-10-23. ## Quick Wire Reference - **Step**: 7 Pay (Settle the bill) - **Version**: closed beta (2026-07-28) - **Status**: Closed beta; documentation updated 2026-07-28 · prototype - **Discovery / Probe Path**: HTTP 402 response carrying a crawler-price header - **Spec URL**: https://developers.cloudflare.com/ai-crawl-control/features/pay-per-crawl/what-is-pay-per-crawl/ - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: HTTP 402 Payment Required, used for crawl access [Pay](/category/pay/) Pay per crawl is Cloudflare's way for a site to charge AI crawlers per request. The site answers with HTTP 402 and a crawler-price header; the crawler agrees by sending crawler-exact-price or crawler-max-price, and a charged response carries crawler-charged [[1]](#ref-1). Crawlers must sign requests with Web Bot Auth, so a priced crawl is also an identified one [[1]](#ref-1). ## Overview Cloudflare documents it as a closed beta, and the documentation was last updated on 2026-07-28 [[1]](#ref-1). It is a single-vendor mechanism, not an open standard, and sits in the HTTP 402 family with x402 and MPP. The record could equally sit under permit; it is placed at pay because the exchange is a payment. ## Discovery and probe HTTP 402 response carrying a crawler-price header ``` GET {origin}/{priced-path} parse: HTTP 402 with a crawler-price response header; a crawler pays by sending crawler-exact-price or crawler-max-price, and the charged response carries crawler-charged. The crawler must sign requests with Web Bot Auth. on absent: A 200 or a 402 without a crawler-price header means this path is not priced by pay per crawl; the probe cannot see an unsigned-agent decision. ``` Not probed live: no-fixed-path. candidate record; probe rule pending ## History - 2026-10-15 — curated update 2026-10-15 - 2026-10-16 — use-case tags (auto) ## Instances - [Cloudflare Pay Per Crawl and x402 Edge Clearinghouse](https://blog.cloudflare.com/introducing-pay-per-crawl/) · Observed 2026-07-01 · venue Every instance with its source is listed on the [instances page](/instances/). Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Builds on: [HTTP Message Signatures](/protocols/http-message-signatures/), [Web Bot Auth HTTP Message Signatures](/protocols/webbotauth/) - Pairs with: [Signature Agent Card (Web Bot Auth registry)](/protocols/web-bot-auth-signature-agent-card/), [Web Bot Auth HTTP Message Signatures](/protocols/webbotauth/), [x402](/protocols/x402/), [Machine Payments Protocol](/protocols/mpp/), [HTTP Message Signatures](/protocols/http-message-signatures/), [Content Signals Policy](/protocols/cloudflare-content-signals-policy/) - [x402](/protocols/x402/) - [L402](/protocols/l402/) - [Machine Payments Protocol](/protocols/mpp/) - [s402](/protocols/s402/) - [HTTP 402 Payment Required](/terms/http-402-payment-required/) - [Pay per crawl](/terms/pay-per-crawl/) - [Web Bot Auth](/terms/web-bot-auth/) ## Comparisons - [API Keys & Subscriptions vs x402 & MPP (HTTP 402) (classic vs agentic)](/compare/api-keys-vs-x402/) - [Cloudflare Pay per crawl vs x402](/compare/cloudflare-pay-per-crawl-vs-x402/) - [Cloudflare Pay per crawl vs L402](/compare/cloudflare-pay-per-crawl-vs-l402/) - [Cloudflare Pay per crawl vs Machine Payments Protocol](/compare/cloudflare-pay-per-crawl-vs-mpp/) - [Cloudflare Pay per crawl vs s402](/compare/cloudflare-pay-per-crawl-vs-s402/) ## References - Cloudflare's documentation says pay per crawl uses HTTP 402 with crawler-price, crawler-exact-price / crawler-max-price and crawler-charged headers, requires Web Bot Auth signing, and is in closed beta (documentation updated 2026-07-28). — [https://developers.cloudflare.com/ai-crawl-control/features/pay-per-crawl/what-is-pay-per-crawl/](https://developers.cloudflare.com/ai-crawl-control/features/pay-per-crawl/what-is-pay-per-crawl/) (2026-07-28) VERIFIED - Cloudflare's introductory post describes pay per crawl. — [https://blog.cloudflare.com/introducing-pay-per-crawl/](https://blog.cloudflare.com/introducing-pay-per-crawl/) REPORTED [JSON](/data/protocols/cloudflare-pay-per-crawl.json) · [Markdown](/protocols/cloudflare-pay-per-crawl/index.md) · [OKF v0.2](/okf/protocols/cloudflare-pay-per-crawl.md) --- # CoMP (Content Monetization Protocols) CoMP (Content Monetization Protocols) is an agentic-web standard (endpoint) at step 3, Permit, governed by IAB Tech Lab; its status is "CoMP v1: open for public comment until 2026-04-09 and finalized…". It answers: "How does a licensed AI system ask a publisher or content marketplace for content, saying who it is, how it authenticates…?" Implementation status is none found, last verified 2026-10-23. ## Quick Wire Reference - **Step**: 3 Permit (What may the agent do here?) - **Version**: CoMP v1 (Final) (2026-04-28) - **Status**: CoMP v1 (Final): open for public comment until 2026-04-09 and finalized… - **Discovery / Probe Path**: none defined; supply discovery is explicitly out of scope, and terms are reached through a… - **Spec URL**: https://github.com/IABTechLab/CoMP/blob/main/CoMP-1.0.md - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: A syndication licence request, made machine-readable [Permit](/category/permit/) CoMP is IAB Tech Lab's final v1 API specification for licensed content supply to AI systems [[1]](#ref-1). The document itself is titled "Content Metadata Marketplace Supply Specification (MVP)" [[2]](#ref-2). An AI system sends a request saying who it is and how it authenticates (the listed methods include Web Bot Auth). It also states what it will use the content for, from a fixed list of functions [[2]](#ref-2). The publisher or marketplace answers with a Package: the content scope, a licenseurl for terms, a reporturl for usage reporting, how to retrieve the content, and delivery formats that include MCP and NLWeb [[2]](#ref-2). ## Overview It sits under Permit, next to RSL, because it is about access and licence terms between AI systems and publishers. It does not settle payment itself. How an AI system finds suppliers is explicitly out of scope [[2]](#ref-2). V1 closed public comment on 2026-04-09 and was finalized on 2026-04-28 [[1]](#ref-1). The spec is CC-BY 3.0. IAB Tech Lab runs a related AI Bot Management Guidance, which was in public comment until 2026-06-25; its later status is not known [[1]](#ref-1). No implementations have been counted. ## Discovery and probe none defined; supply discovery is explicitly out of scope, and terms are reached through a licenseurl in the response ``` GET none — the spec defines request and response objects, not a fixed endpoint path parse: No fixed path to parse. on absent: Not probeable from an origin. ``` Not probed live: no-fixed-path. CoMP defines request and response objects, not a fixed path; supply discovery is out of scope. ## History - 2026-10-20 — added from gap scout 2026-10-20; verified against IAB Tech Lab's CoMP initiative page and CoMP-1.0.md on the main branch of github.com/IABTechLab/CoMP ## Instances Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Pairs with: [Really Simple Licensing](/protocols/rsl/), [Web Bot Auth HTTP Message Signatures](/protocols/webbotauth/), [Agentic Advertising Management Protocols](/protocols/aamp/), [NLWeb](/protocols/nlweb/), [Model Context Protocol](/protocols/mcp/) ## Comparisons - [Really Simple Licensing vs CoMP (Content Monetization Protocols)](/compare/rsl-vs-iab-comp/) - [Agent Attribution Protocol vs CoMP (Content Monetization Protocols)](/compare/agent-attribution-protocol-vs-iab-comp/) ## References - IAB Tech Lab's CoMP initiative page says V1 of CoMP was open for public comment until April 9, 2026 and was finalized on April 28, 2026, linking 'CoMP v1 (Final)' to github.com/IABTechLab/CoMP; it lists AI Bot Management Guidance as in public comment until June 25, 2026. — [https://iabtechlab.com/standards/comp-content-monetization-protocols-initiative/](https://iabtechlab.com/standards/comp-content-monetization-protocols-initiative/) (2026-04-28) VERIFIED - CoMP-1.0.md, titled 'Content Metadata Marketplace Supply Specification (MVP)', defines an AI System request (identification, aiauth methods including Web Bot Auth, intended-use functions) and a content owner or marketplace response (Package with licenseurl, reporturl, retrieval authorization and delivery formats including MCP and NLWeb); its last commits (2026-04-16, 2026-04-20) are 'Updated per Public Comment Feedback'. — [https://github.com/IABTechLab/CoMP/blob/main/CoMP-1.0.md](https://github.com/IABTechLab/CoMP/blob/main/CoMP-1.0.md) (2026-04-20) VERIFIED [JSON](/data/protocols/iab-comp.json) · [Markdown](/protocols/iab-comp/index.md) · [OKF v0.2](/okf/protocols/iab-comp.md) --- # Content Signals Policy (Content-Signal) Content Signals Policy is an agentic-web standard (well-known file — Content-Signal) at step 3, Permit, governed by Cloudflare, developed with publisher/platform partners named in…; its status is "Vendor-published policy convention layered on robots.txt". It answers: "May content fetched under a robots.txt allow rule also be used for search indexing, as live input to an AI answer, or…?" Replacing or extending robots.txt policy extension, implementation status is multi-implementation (observed on 185/1226 probed origins), last verified 2026-10-23. ## Quick Wire Reference - **Step**: 3 Permit (What may the agent do here?) - **Version**: Announced 2025-09-24 (2025-09-24) - **Status**: Vendor-published policy convention layered on robots.txt; not submitted to a… - **Discovery / Probe Path**: /robots.txt — Machine-readable comment lines inside robots.txt - **Spec URL**: https://blog.cloudflare.com/content-signals-policy/ - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: robots.txt policy extension [Permit](/category/permit/) The Content Signals Policy is a Cloudflare-authored convention, announced 2025-09-24, that extends robots.txt with a machine-readable way for a website operator to state whether content a crawler is allowed to fetch may also be used for three specific downstream purposes: search (building a search index and returning links/excerpts, explicitly excluding AI-generated search summaries), ai-input (feeding content into an AI model at request time, e.g. retrieval-augmented generation or grounding), and ai-train (training or fine-tuning a model) [[1]](#ref-1). It is a permit-layer refinement on top of the existing allow/disallow crawl decision: robots.txt still governs whether a page may be fetched at all, and content signals then govern what may be done with a page the crawler was already allowed to fetch. ## Overview Signals are expressed as human-readable comment lines (so they degrade gracefully for crawlers that don't parse them) of the form content-signal: search=yes, ai-train=no. Per the spec text, yes permits the corresponding use, no prohibits it, and omitting a signal means the operator neither grants nor restricts permission for that use — a deliberately weaker default than an explicit prohibition [[1]](#ref-1). Cloudflare frames any expressed restriction as an express reservation of rights under Article 4 of the EU Copyright Directive (2019/790), aligning its legal grounding with TDMRep's. It does not define enforcement, and Cloudflare's own post frames it as advisory: compliance depends on crawler operators choosing to read and honour the signal, exactly like robots.txt itself. It has not, as of this verification, been submitted to IETF, W3C, or any other standards body — it remains a single-vendor convention, distinct from and overlapping with the IETF AIPREF Content-Usage/Vocabulary drafts, which use a different attachment surface (a dedicated header/directive) and a different vocabulary. As of this verification (2026-09-06), the announcement date of 2025-09-24 is confirmed directly from the post's own structured-data metadata, matching the prior finding [[1]](#ref-1). Cloudflare ships the mechanism directly into its own customer-facing robots.txt management tooling, giving it a shipping implementation by definition for any site on Cloudflare's platform, though no independent count of how many zones have set a non-default signal was found in this pass — adoption is unmeasured. What is unresolved: whether AI vendors (OpenAI, Anthropic, Google, Perplexity) formally commit to honouring these specific signal names in their own crawler documentation, as opposed to their existing per-bot robots.txt tokens (see ai-crawler-tokens-robots), was not confirmed in this pass. ## Discovery and probe Machine-readable comment lines inside robots.txt · /robots.txt ``` GET {origin}/robots.txt parse: Look for 'content-signal: search=', 'content-signal: ai-input=', or 'content-signal: ai-train=' lines (as machine-readable comments) inside any robots.txt group on absent: Website operator has not stated a content-signal preference for that use; the spec is explicit that omission means the operator neither grants nor restricts permission for that use ``` Live check run by [the MCP probe](/mcp/server-card): GET /robots.txt. Content Signals are Content-Signal lines in robots.txt. ``` { "path": "/robots.txt", "expect": { "text_match": "(?im)^content-signal:" }, "note": "Content Signals are Content-Signal lines in robots.txt." } ``` ## History - 2026-09-05 — seeded from Exa Agent research run - 2026-09-06 — verified against blog.cloudflare.com/content-signals-policy/ - 2026-09-07 — added Google's 2026-07-06 statement that no crawler honours the directive (Search Engine Roundtable, Search Engine Journal) - 2026-10-16 — Cloudflare 'Disallow AI Training' and Accountable crawler designation (2026-09-15); Bot Preference Sync replaces Managed robots.txt - 2026-10-16 — use-case tags (auto) ## Instances - [Zuplo API Gateway (zuplo.com)](https://zuplo.com/) · Observed 2026-10-25 · origin - [Zoom Developers (developers.zoom.us)](https://developers.zoom.us/) · Observed 2026-10-25 · origin - [Zep Long-Term Agent Memory (getzep.com)](https://getzep.com/) · Observed 2026-10-25 · origin - [Zapier (zapier.com)](https://zapier.com/) · Observed 2026-10-25 · origin - [Wistia (wistia.com)](https://wistia.com/) · Observed 2026-10-25 · origin - [Webflow Developers (developers.webflow.com)](https://developers.webflow.com/) · Observed 2026-10-25 · origin - [Vellum AI Workflow Platform (vellum.ai)](https://vellum.ai/) · Observed 2026-10-25 · origin - [Vast.ai (vast.ai)](https://vast.ai/) · Observed 2026-10-25 · origin - [tldraw Infinite Canvas SDK (tldraw.com)](https://tldraw.com/) · Observed 2026-10-25 · origin - [Taskade (taskade.com)](https://taskade.com/) · Observed 2026-10-25 · origin - [SurrealDB (surrealdb.com)](https://surrealdb.com/) · Observed 2026-10-25 · origin - [Supermemory (supermemory.ai)](https://supermemory.ai/) · Observed 2026-10-25 · origin - [Supabase (supabase.com)](https://supabase.com/) · Observed 2026-10-25 · origin - [Speakeasy (speakeasy.com)](https://speakeasy.com/) · Observed 2026-10-25 · origin - [Sentry (sentry.io)](https://sentry.io/) · Observed 2026-10-25 · origin - [Scalar API Platform (scalar.com)](https://scalar.com/) · Observed 2026-10-25 · origin - [SavvyCal (savvycal.com)](https://savvycal.com/) · Observed 2026-10-25 · origin - [Sanity Content Operating System (sanity.io)](https://sanity.io/) · Observed 2026-10-25 · origin - [RunPod GPU Cloud (runpod.io)](https://runpod.io/) · Observed 2026-10-25 · origin - [Replicate (replicate.com)](https://replicate.com/) · Observed 2026-10-25 · origin - [Reducto Document AI (reducto.ai)](https://reducto.ai/) · Observed 2026-10-25 · origin - [React Email by Resend (react.email)](https://react.email/) · Observed 2026-10-25 · origin - [Pydantic & Logfire (pydantic.dev)](https://pydantic.dev/) · Observed 2026-10-25 · origin - [Publica.la (publica.la)](https://publica.la/) · Observed 2026-10-25 · origin - [Proof API (api.proof.com)](https://api.proof.com/.well-known/ard.json) · Observed 2026-10-25 · origin - [Podscan Podcast Intelligence API (podscan.fm)](https://podscan.fm/) · Observed 2026-10-25 · origin - [PlanetScale (planetscale.com)](https://planetscale.com/) · Observed 2026-10-25 · origin - [Plane (plane.so)](https://plane.so/) · Observed 2026-10-25 · origin - [Perplexity API Docs (docs.perplexity.ai)](https://docs.perplexity.ai/) · Observed 2026-10-25 · origin - [OpenStatus (openstatus.dev)](https://openstatus.dev/) · Observed 2026-10-25 · origin - [Novita AI (novita.ai)](https://novita.ai/) · Observed 2026-10-25 · origin - [MotherDuck Serverless DuckDB (motherduck.com)](https://motherduck.com/) · Observed 2026-10-25 · origin - [Morph Fast Apply LLM (morphllm.com)](https://morphllm.com/) · Observed 2026-10-25 · origin - [Model Context Protocol Docs (modelcontextprotocol.io)](https://modelcontextprotocol.io/) · Observed 2026-10-25 · origin - [LibreChat Open-Source AI Workspace (librechat.ai)](https://librechat.ai/) · Observed 2026-10-25 · origin - [LanceDB (lancedb.com)](https://lancedb.com/) · Observed 2026-10-25 · origin - [Lago (getlago.com)](https://getlago.com/) · Observed 2026-10-25 · origin - [Kent C. Dodds (kentcdodds.com)](https://kentcdodds.com/) · Observed 2026-10-25 · origin - [Hostinger (hostinger.com)](https://hostinger.com/) · Observed 2026-10-25 · origin - [Glama MCP Gateway & Directory (glama.ai)](https://glama.ai/) · Observed 2026-10-25 · origin - [Fly.io (fly.io)](https://fly.io/) · Observed 2026-10-25 · origin - [Eodly (eodly.io)](https://eodly.io/) · Observed 2026-10-25 · origin - [Dries Buytaert (dri.es)](https://dri.es/) · Observed 2026-10-25 · origin - [docs.warp.dev](https://docs.warp.dev/) · Observed 2026-10-25 · origin - [Descope Identity & Agent Auth (descope.com)](https://descope.com/) · Observed 2026-10-25 · origin - [DC Hub (dchub.cloud)](https://dchub.cloud/) · Observed 2026-10-25 · origin - [Customer.io (customer.io)](https://customer.io/) · Observed 2026-10-25 · origin - [crewai.com](https://crewai.com/) · Observed 2026-10-25 · origin - [Convex Reactive Backend (convex.dev)](https://convex.dev/) · Observed 2026-10-25 · origin - [Circle (circle.so)](https://circle.so/) · Observed 2026-10-25 · origin - [Cal.com Scheduling Infrastructure (cal.com)](https://cal.com/) · Observed 2026-10-25 · origin - [Browser Use Web Agent Runtime (browser-use.com)](https://browser-use.com/) · Observed 2026-10-25 · origin - [Bird (bird.com)](https://bird.com/) · Observed 2026-10-25 · origin - [Better Stack Observability (betterstack.com)](https://betterstack.com/) · Observed 2026-10-25 · origin - [beehiiv Newsletter Platform (beehiiv.com)](https://beehiiv.com/) · Observed 2026-10-25 · origin - [Baseten Docs (docs.baseten.co)](https://docs.baseten.co/) · Observed 2026-10-25 · origin - [Augment Code Docs (docs.augmentcode.com)](https://docs.augmentcode.com/) · Observed 2026-10-25 · origin - [Attio Docs (docs.attio.com)](https://docs.attio.com/) · Observed 2026-10-25 · origin - [Atlan (atlan.com)](https://atlan.com/) · Observed 2026-10-25 · origin - [Arcade AI Tool-Calling Runtime (arcade.dev)](https://arcade.dev/) · Observed 2026-10-25 · origin - [Amplitude (amplitude.com)](https://amplitude.com/) · Observed 2026-10-25 · origin - [Agent Skills Specification (agentskills.io)](https://agentskills.io/) · Observed 2026-10-25 · origin - [Agent Client Protocol (agentclientprotocol.com)](https://agentclientprotocol.com/) · Observed 2026-10-25 · origin - [AG-UI Documentation Origin (docs.ag-ui.com)](https://docs.ag-ui.com/) · Observed 2026-10-25 · origin - [Ad Context Protocol Docs (docs.adcontextprotocol.org)](https://docs.adcontextprotocol.org/) · Observed 2026-10-25 · origin - [xAI (x.ai)](https://x.ai/) · Observed 2026-10-23 · origin - [x402 Foundation Spec Origin (x402.org)](https://x402.org/) · Observed 2026-10-23 · origin - [Twilio (twilio.com)](https://twilio.com/) · Observed 2026-10-23 · origin - [Telnyx (telnyx.com)](https://telnyx.com/) · Observed 2026-10-23 · origin - [Stripe Documentation (docs.stripe.com)](https://docs.stripe.com/) · Observed 2026-10-23 · origin - [Resend (resend.com)](https://resend.com/) · Observed 2026-10-23 · origin - [Railway (railway.com)](https://railway.com/) · Observed 2026-10-23 · origin - [QuickNode (quicknode.com)](https://quicknode.com/) · Observed 2026-10-23 · origin - [Proof (proof.com)](https://proof.com/) · Observed 2026-10-23 · origin - [Neon Serverless Postgres (neon.com)](https://neon.com/) · Observed 2026-10-23 · origin - [n8n Documentation Origin (docs.n8n.io)](https://docs.n8n.io/) · Observed 2026-10-23 · origin - [GitBook (gitbook.com)](https://gitbook.com/) · Observed 2026-10-23 · origin - [Firecrawl (firecrawl.dev)](https://firecrawl.dev/) · Observed 2026-10-23 · origin - [Cloudflare (cloudflare.com)](https://cloudflare.com/) · Observed 2026-10-23 · origin - [ClickHouse (clickhouse.com)](https://clickhouse.com/) · Observed 2026-10-23 · origin - [circle.com](https://circle.com/) · Observed 2026-10-23 · origin - [blog.cloudflare.com](https://blog.cloudflare.com/) · Observed 2026-10-23 · origin - [auth.md Specification Origin (auth-md.com)](https://auth-md.com/) · Observed 2026-10-23 · origin - [Associated Press (ap.org)](https://ap.org/) · Observed 2026-10-23 · origin - [Apify (apify.com)](https://apify.com/) · Observed 2026-10-23 · origin - [aitxt.ing](https://aitxt.ing/) · Observed 2026-10-23 · origin - [agenticweb.wiki Reference Agent and MCP Server](https://agenticweb.wiki) · Observed 2026-10-23 · agent - [Agentic AI Foundation (aaif.io)](https://aaif.io/) · Observed 2026-10-23 · origin - [agent-ready.dev Conformance Scanner Agent](https://agent-ready.dev) · Observed 2026-10-23 · agent - [0G Labs (0g.ai)](https://0g.ai/) · Observed 2026-10-23 · origin Every instance with its source is listed on the [instances page](/instances/). Verified SDKs, reference implementations & validators: - [Cloudflare (native robots.txt content-signal management for Cloudflare-hosted zones)](https://blog.cloudflare.com/content-signals-policy/) · implementation (2025-09-24) Our probe: seen on 185 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Builds on: [AI Crawler User-Agent Tokens in robots.txt](/protocols/ai-crawler-tokens-robots/) - Pairs with: [AI Crawler User-Agent Tokens in robots.txt](/protocols/ai-crawler-tokens-robots/), [Text and Data Mining Reservation Protocol](/protocols/tdmrep/), [AIPREF Vocabulary](/protocols/aipref-vocabulary/), [AIPREF Content-Usage Attachment](/protocols/aipref-content-usage-attachment/), [Cloudflare Pay per crawl](/protocols/cloudflare-pay-per-crawl/), [Markdown for Agents](/protocols/cloudflare-markdown-for-agents/) - [AI crawler tokens](/terms/ai-crawler-tokens/) - [Content-Signal directive](/terms/content-signal/) ## Comparisons - [robots.txt (Allow/Disallow) vs Content-Signal, AIPREF & TDMRep (classic vs agentic)](/compare/robots-txt-vs-content-signal/) - [Content Signals Policy vs Web Bot Auth HTTP Message Signatures](/compare/cloudflare-content-signals-policy-vs-webbotauth/) - [Content Signals Policy vs AIPREF Vocabulary](/compare/cloudflare-content-signals-policy-vs-aipref-vocabulary/) - [AI Crawler User-Agent Tokens in robots.txt vs Content Signals Policy](/compare/ai-crawler-tokens-robots-vs-cloudflare-content-signals-policy/) - [Really Simple Licensing vs Content Signals Policy](/compare/rsl-vs-cloudflare-content-signals-policy/) ## References - Cloudflare's blog post, datePublished 2025-09-24 per its own page metadata, defines three content signals (search, ai-input, ai-train) as machine-readable comment lines inside robots.txt, each independently settable to yes/no, and frames restrictions as express reservations of rights under EU Directive 2019/790 Article 4. — [https://blog.cloudflare.com/content-signals-policy/](https://blog.cloudflare.com/content-signals-policy/) (2025-09-24) VERIFIED - Cloudflare's own developer documentation (distinct from the announcement blog post) reproduces the exact Content Signals Policy text and confirms it ships by default in the managed robots.txt feature, and separately states this feature was already turned on for over 3.8 million domains at launch, giving an independent, dated adoption figure from Cloudflare's own materials. — [https://developers.cloudflare.com/bots/additional-configurations/managed-robots-txt/](https://developers.cloudflare.com/bots/additional-configurations/managed-robots-txt/) (2025-09-24) VERIFIED - Google's John Mueller (r/TechSEO, 2026-07-06): no crawler or LLM he knows of reads the content-signal robots.txt directive; it 'has no effects whatsoever for any crawler or llm' and 'just adds bloat'. Reported independently by Search Engine Roundtable and Search Engine Journal. — [https://www.seroundtable.com/google-cloudflare-content-signals-41631.html](https://www.seroundtable.com/google-cloudflare-content-signals-41631.html) (2026-07-06) VERIFIED - Search Engine Journal's account of the same statement, noting Cloudflare also emits the Content-Signal syntax as an HTTP response header in Markdown for Agents. — [https://www.searchenginejournal.com/google-answers-question-about-llms-author-txt-for-seo/581547/](https://www.searchenginejournal.com/google-answers-question-about-llms-author-txt-for-seo/581547/) (2026-07-06) VERIFIED - Cloudflare 'Disallow AI Training' and Accountable crawler designation (2026-09-15); Bot Preference Sync replaces Managed robots.txt — [https://blog.cloudflare.com/](https://blog.cloudflare.com/) (2026-09-15) VERIFIED Disputed: Two different things carry the same name: an edge-enforced Cloudflare feature that works because Cloudflare blocks the request, and a robots.txt directive that only works if a crawler chooses to honour it. As of July 2026 Google says it does not, and no other major crawler has documented doing so. [JSON](/data/protocols/cloudflare-content-signals-policy.json) · [Markdown](/protocols/cloudflare-content-signals-policy/index.md) · [OKF v0.2](/okf/protocols/cloudflare-content-signals-policy.md) --- # Coral Protocol (CoralOS) Coral Protocol (CoralOS) is an agentic-web standard (endpoint) at step 6, Coordinate, governed by Single company/startup-led open-source project; its status is "Kubernetes for AI agents: a platform for everything between…". It answers: "How do independently-built agents from a public marketplace get orchestrated together into one multi-agent system, with…?" Implementation status is shipping, last verified 2026-10-23. ## Quick Wire Reference - **Step**: 6 Coordinate (Talk to another agent) - **Version**: unversioned, continuously updated platform (Coral Server, Coralizer… - **Status**: "Kubernetes for AI agents: a platform for everything between your agents and… - **Discovery / Probe Path**: Agents are discovered via the centralized Coral Marketplace (publish/discover/monetize with… - **Spec URL**: https://docs.coralos.ai/welcome - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: Kubernetes, but for AI agents, plus an app-store marketplace layer [Coordinate](/category/coordinate/) Coral Protocol, rebranded 'CoralOS' as of this check, is a single-vendor, open-source platform for orchestrating a graph of independently built AI agents — pulled from a public marketplace or built in-house — with per-session privacy isolation, a graph-based (rather than single-planner-hierarchical) coordination model, and built-in payment budgeting [[1]](#ref-1). It positions itself explicitly as infrastructure rather than a thin wire protocol: its own tagline is "Kubernetes for AI agents," and its documented components (Coral Server for orchestration, a Coral Marketplace for discovery/monetization with attestation, a Coral Console for monitoring, and a 'Coralizer' that wraps any existing MCP server into a marketplace-listed agent) describe a full runtime platform built on top of MCP as the underlying inter-agent transport, not a standalone spec document [[1]](#ref-1). ## Overview It solves multi-agent orchestration at the point where a hierarchical single-planner design becomes a bottleneck: Coral's graph-based architecture lets agents communicate directly and monitor each other's progress rather than funneling every decision through a central controller, a design choice the project backs with a cited academic benchmark result (Anemoi, arXiv:2508.17068) showing accuracy gains from this structure on the GAIA benchmark [[1]](#ref-1). It does not define a public, network-visible wire protocol comparable to A2A's Agent Card + JSON-RPC surface; its documented API (e.g. POST /api/v1/local/session) is a local orchestration control-plane endpoint requiring bearer authentication, run by the developer rather than exposed as a discoverable public origin [[2]](#ref-2). As of this check (September 2026), Coral is an actively developed, versionless platform rather than a dated spec release — its docs site itself changed domain during the period covered by this map (from docs.coralprotocol.org to docs.coralos.ai), and its session API already includes native support for x402 micropayment budgets per agent, tying it into the broader agentic-payments ecosystem this map also tracks [[1]](#ref-1)[[2]](#ref-2). Implementations are real and shipping: Coral Server and the Coralizer are both public GitHub repositories under the Coral-Protocol organization. What is unresolved: how open Coral's governance actually is beyond "open-source code, single company roadmap" — no independent steering body or multi-vendor governance document was found, and no adoption count beyond the project's own marketing language was available to verify during this pass. ## Discovery and probe Agents are discovered via the centralized Coral Marketplace (publish/discover/monetize with built-in attestation); a local Coral Server also exposes a session-creation API for orchestrating a given agent graph; MCP is used as the underlying inter-agent transport for 'coralized' agents ``` POST {origin}/api/v1/local/session parse: A 200 response containing a JSON object with namespace and sessionId fields confirms a running Coral (local) server per its documented API reference; the request body's x402Budgets field on agent entries also confirms native x402 micropayment-budget support. on absent: A 404, connection refusal, or 401/403 (this endpoint requires bearer auth) most commonly just means no local Coral Server is running at this address — Coral Server is typically run locally by the developer rather than exposed as a public origin, so a failed probe against an arbitrary public site proves little either way. ``` Not probed live: unsafe-post. The probe is POST /api/v1/local/session, which opens a session. ## History - 2026-09-06 — added from arXiv 2504.16736 survey comparison, verified against docs.coralos.ai/about, docs.coralos.ai/api-reference/local/create-session - 2026-10-16 — use-case tags (auto) ## Instances - [Reef (Coral Incident Agent)](https://dev.to/grandkojo/how-we-built-reef-a-production-incident-agent-with-coral-sentry-webhooks-and-slack-ngg) · Observed 2026-05-31 · agent - [PatchPoint](https://dev.to/abhi_mishra/building-patchpoint-unifying-devops-security-silos-with-coral-sql-318h) · Observed 2026-05-31 · agent - [CoralTeams](https://dev.to/shrutik0101/building-coralteams-an-ai-powered-operational-intelligence-platform-with-coral-28l9) · Observed 2026-05-31 · agent - [CoralSec Copilot](https://dev.to/codewithmehru/how-i-built-coralsec-copilot-a-unified-enterprise-soc-with-coral-nextjs-in-4-days-235o) · Observed 2026-05-30 · agent Every instance with its source is listed on the [instances page](/instances/). Verified SDKs, reference implementations & validators: - [Coral Server](https://github.com/Coral-Protocol/coral-server) · implementation (2026-09-06) - [Coralizer (MCP-server-to-agent wrapper)](https://github.com/Coral-Protocol/coralizer) · implementation (2026-09-06) Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Builds on: [Model Context Protocol](/protocols/mcp/) - Pairs with: [Model Context Protocol](/protocols/mcp/), [x402](/protocols/x402/), [Agent2Agent Protocol](/protocols/a2a/), [Open Agentic Schema Framework](/protocols/oasf/) ## Comparisons - [Webhooks & RPC vs Agent2Agent Protocol (A2A) (classic vs agentic)](/compare/webhooks-vs-a2a/) - [Agent2Agent Protocol vs Coral Protocol (CoralOS)](/compare/a2a-vs-coral-protocol/) - [Agent Network Protocol vs Coral Protocol (CoralOS)](/compare/anp-vs-coral-protocol/) ## References - CoralOS (formerly 'Coral Protocol'; docs.coralprotocol.org now redirects to docs.coralos.ai) describes itself as 'Kubernetes for AI agents' — a platform comprising Coralized Agents, a Coral Marketplace for discovery/monetization, Coral Server for orchestration, Coral Console for monitoring, and a Coralizer that turns any MCP server into a marketplace-listed agent. — [https://docs.coralos.ai/about](https://docs.coralos.ai/about) (2026-09-06) VERIFIED - The documented local API includes POST /api/v1/local/session ('Create session'), which accepts an agentGraphRequest of agents (each with an id, provider, and an x402Budgets array for per-resource micropayment budgets) and returns a namespace and sessionId. — [https://docs.coralos.ai/api-reference/local/create-session](https://docs.coralos.ai/api-reference/local/create-session) (2026-09-06) VERIFIED [JSON](/data/protocols/coral-protocol.json) · [Markdown](/protocols/coral-protocol/index.md) · [OKF v0.2](/okf/protocols/coral-protocol.md) --- # Credential Delegation Protocol for AI Agents in Multi-System Environments Credential Delegation Protocol for AI Agents in Multi-System Environments is an agentic-web standard (endpoint) at step 3, Permit, governed by Individual Internet-Draft submitted to the IETF WIMSE Working…; its status is "Internet-Draft, Intended Status: Standards Track". It answers: "How can a human user delegate scoped, attenuated, revocable credentials to AI agents across multiple service providers…?" Implementation status is prototype, last verified 2026-10-23. ## Quick Wire Reference - **Step**: 3 Permit (What may the agent do here?) - **Version**: draft-sweeney-wimse-credential-delegation-01 (2026-10-13) - **Status**: Internet-Draft, Intended Status: Standards Track; expires 16 April 2027 ·… - **Discovery / Probe Path**: Delegation Server endpoints within a trust domain; no standard discovery path described in… - **Spec URL**: https://datatracker.ietf.org/doc/html/draft-sweeney-wimse-credential-delegation-01 - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: OAuth 2.0 Token Exchange profile for agent delegation [Permit](/category/permit/) An individual Internet-Draft in the IETF WIMSE space that profiles OAuth 2.0 Token Exchange (RFC 8693), DPoP (RFC 9449), Rich Authorization Requests (RFC 9396) and CIBA for delegating scoped credentials to AI agents. It defines ephemeral-key agent identities, capability-shaped delegation tokens, credential wrapping, consent-gated delegation, cascading revocation and audit chains. It defines no new token formats or grant types and is positioned as a companion to draft-ietf-wimse-aims. ## Discovery and probe Delegation Server endpoints within a trust domain; no standard discovery path described in the available text ``` NONE parse: on absent: No externally observable site-level signal described; treat support as unknown ``` Not probed live: no-fixed-path. candidate record; probe rule pending ## History - 2026-10-16 — auto-drafted candidate from exa (https://datatracker.ietf.org/doc/html/draft-sweeney-wimse-credential-delegation-01) ## Instances Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Pairs with: [WIMSE AI Identity Management System](/protocols/wimse-aims/), [HTTP Message Signatures](/protocols/http-message-signatures/), [Agent Identity Protocol (AIP): Verifiable Delegation for AI Agent Systems](/protocols/aip-delegation-chain/) ## Comparisons - [Agent Identity Protocol (AIP): Verifiable Delegation for AI Agent Systems vs Credential Delegation Protocol for AI Agents in Multi-System Environments](/compare/aip-delegation-chain-vs-credential-delegation-protocol-wimse/) ## References - Internet-Draft draft-sweeney-wimse-credential-delegation-01, published 13 October 2026, Intended Status Standards Track, workgroup WIMSE; profiles RFC 8693, RFC 9449, RFC 9396 and OpenID CIBA for credential delegation to AI agents. — [https://datatracker.ietf.org/doc/html/draft-sweeney-wimse-credential-delegation-01](https://datatracker.ietf.org/doc/html/draft-sweeney-wimse-credential-delegation-01) (2026-10-13) REPORTED - Source for the draft and issue tracker are hosted on GitHub; the reference implementation is reported to pass twenty Asor interop vectors. — [https://github.com/cred-ninja/protocol](https://github.com/cred-ninja/protocol) REPORTED [JSON](/data/protocols/credential-delegation-protocol-wimse.json) · [Markdown](/protocols/credential-delegation-protocol-wimse/index.md) · [OKF v0.2](/okf/protocols/credential-delegation-protocol-wimse.md) --- # Discovery of Model Context Protocol Servers via DNS TXT Records Discovery of Model Context Protocol Servers via DNS TXT Records is an agentic-web standard (DNS record) at step 1, Discover, governed by Individual Internet-Draft by a single author; its status is "Active Internet-Draft". It answers: "How can a client discover an MCP server's endpoint, the operating organisation's identity, and a signed ~handle identity…?" Implementation status is none found, last verified 2026-10-23. ## Quick Wire Reference - **Step**: 1 Discover (What is here, and where?) - **Version**: draft-morrison-mcp-dns-discovery-09 (2026-10-22) - **Status**: Active Internet-Draft (-09, Informational; expires 2027-04-25) · none found - **Discovery / Probe Path**: _mcp. - **Spec URL**: https://datatracker.ietf.org/doc/html/draft-morrison-mcp-dns-discovery-09 - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: DKIM/DMARC-style underscore-labelled TXT records for MCP server discovery [Discover](/category/discover/) This Internet-Draft defines three DNS TXT records: _mcp. for MCP server endpoint, transport, key and capability profile; _org-alter. for operator organisational identity; and _alter. for an Ed25519-signed ~handle envelope. DNSSEC validation is required for the envelope record, and a DANE TLSA pin is required on the MCP endpoint in some cases. It follows the DKIM, SPF, DMARC and MTA-STS precedent and discusses related DNS-based discovery drafts (AGENT-AID, DNS-AID, MDNS-AGENT). ## Discovery and probe DNS TXT records at _mcp., _org-alter. and _alter.; DNSSEC required for the envelope record, DANE TLSA pin on the MCP endpoint where required · _mcp. ``` DNS TXT query _mcp. parse: Parse the semicolon-delimited key=value TXT record (endpoint URL, protocol family, transport, key, capability profile); optionally query _org-alter. and _alter. on absent: Treat the domain as not advertising MCP discovery via DNS (NXDOMAIN or no TXT record) ``` Not probed live: no-fixed-path. candidate record; probe rule pending ## History - 2026-10-16 — auto-drafted candidate from exa (https://datatracker.ietf.org/doc/html/draft-morrison-mcp-dns-discovery-08) - 2026-10-23 — A newer revision, draft-morrison-mcp-dns-discovery-09, now exists; the -08 page is marked as an older version of an Internet-Draft whose latest revision is Active. (auto) ## Instances Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Builds on: [Model Context Protocol](/protocols/mcp/) - Pairs with: [Model Context Protocol](/protocols/mcp/), [DNS for AI Discovery](/protocols/dns-aid/), [Agent Identity and Discovery](/protocols/aid/), [Agent-Channel Frame for Identity-Keyed Fan-Out Delivery to Concurrent Sessions](/protocols/agent-channel-fan-out/) ## Comparisons - [DNS (A/SRV) & WHOIS vs AID & DNS-AID (classic vs agentic)](/compare/dns-whois-vs-aid/) - [Discovery of Model Context Protocol Servers via DNS TXT Records vs DNS for AI Discovery](/compare/mcp-dns-discovery-vs-dns-aid/) - [Discovery of Model Context Protocol Servers via DNS TXT Records vs MCP Server Cards (SEP-2127)](/compare/mcp-dns-discovery-vs-mcp-server-cards/) ## References - The Internet-Draft defines three DNS TXT records (_mcp, _org-alter, _alter) for MCP server discovery, organisational identity, and a signed Ed25519 handle envelope, with Informational intended status and expiry on 12 April 2027. — [https://datatracker.ietf.org/doc/html/draft-morrison-mcp-dns-discovery-08](https://datatracker.ietf.org/doc/html/draft-morrison-mcp-dns-discovery-08) (2026-10-09) REPORTED - Datatracker shows draft-morrison-mcp-dns-discovery-09, dated 2026-10-22, expires 2027-04-25. — [https://datatracker.ietf.org/doc/html/draft-morrison-mcp-dns-discovery-09](https://datatracker.ietf.org/doc/html/draft-morrison-mcp-dns-discovery-09) (2026-10-22) VERIFIED [JSON](/data/protocols/mcp-dns-discovery.json) · [Markdown](/protocols/mcp-dns-discovery/index.md) · [OKF v0.2](/okf/protocols/mcp-dns-discovery.md) --- # DNS for AI Discovery (DNS-AID) DNS for AI Discovery (DNS-AID) is an agentic-web standard (DNS record) at step 1, Discover, governed by IETF Individual Internet-Draft aimed at the DNSOP working group; its status is "Internet-Draft, Standards Track intended status". It answers: "Given a domain, where is its agent endpoint, what protocol does it speak, and how can that be verified via DNSSEC/DANE?" Replacing or extending DNS-based Service Discovery (DNS-SD) for agents, implementation status is prototype (Infoblox and GoDaddy joint press release), last verified 2026-10-23. ## Quick Wire Reference - **Step**: 1 Discover (What is here, and where?) - **Version**: draft-mozleywilliams-dnsop-dnsaid-02 (2026-05-27) - **Status**: Internet-Draft, Standards Track intended status · prototype - **Discovery / Probe Path**: _index._agents. (SVCB); _agent-name. (SVCB) — DNS SVCB records at the agent's… - **Spec URL**: https://datatracker.ietf.org/doc/html/draft-mozleywilliams-dnsop-dnsaid/ - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: DNS-based Service Discovery (DNS-SD) for agents [Discover](/category/discover/) DNS for AI Discovery (DNS-AID) standardizes publishing AI agents in the Domain Name System so other agents can discover them, using DNS Service Binding (SVCB) records for connectivity and key metadata, a well-known DNS-SD-style entry point (_index._agents.) into an organization's agent index, and optionally DNSSEC and DANE TLSA records for trust [[1]](#ref-1). It is an IETF Internet-Draft in the dnsop working group's area (individual submission, not yet WG-adopted), authored by engineers at Infoblox, Deutsche Telekom and Amazon, current revision -02 dated 27 May 2026 with intended status Standards Track [[1]](#ref-1). ## Overview It solves the "given a domain, where is the agent and which protocol does it speak" problem entirely within DNS, so that once a client has resolved an organization's agents once, subsequent lookups are cacheable and require no extra round trip beyond ordinary DNS resolution [[1]](#ref-1). The mechanism defines two record shapes: an SVCB record at an individual agent's owner name carrying TargetName, alpn, well-known (a well-known URI path per RFC 8615) and other SvcParamKeys, and an SVCB record at the fixed label _index._agents. pointing to an organization-wide index [[1]](#ref-1). A TXT-record fallback and a DNSSEC/DANE-authenticated TLSA companion record are both discussed but explicitly not the primary mechanism [[1]](#ref-1). The document introduces no new DNS resource record types, opcodes, or response codes -- it is a usage convention over existing SVCB/TXT/TLSA record types [[1]](#ref-1). DNS-AID does not itself define authentication or authorization beyond DANE-based TLS endpoint verification, does not define the schema of the capability descriptor referenced by well-known (that is out of scope), and use case 3 (discovery by capability alone, with neither organization nor agent known) is explicitly out of scope for this document, though the authors note it "can be derived" from the spec [[1]](#ref-1). Current state: as of 27 May 2026 this is a dnsop-area individual Internet-Draft, expiring 28 November 2026 unless refreshed [[1]](#ref-1). Infoblox and GoDaddy issued a joint press release on 14 May 2026 announcing support for "open standards for AI agent discovery, identity and verification" that names this effort [[2]](#ref-2), but that is a vendor-support announcement, not evidence of production deployments; no independent implementation count was found. Two other agentic-web specifications explicitly build on it: ADP (draft-pro-adp) delegates its entire DNS discovery layer to DNS-AID rather than duplicating it [[3]](#ref-3), and ARD's informative discussion of federated query resolution names DNS-AID as a way to "discover authoritative registries for specific domains" [[3]](#ref-3). What is disputed or unknown: whether DNS-AID's SVCB-based approach and the separately-authored AID specification's flat TXT-record approach (see aid) will converge, coexist, or one will win out -- no evidence of coordination between the two projects was found. Adoption is recorded as "claimed" (by the Infoblox/GoDaddy announcement) rather than measured, since no independent DNS probe of a domain sample was run for this record. ## Discovery and probe DNS SVCB records at the agent's owner name; DNS-SD-style well-known labels _agents/_index for an organization index; optional TXT fallback and DNSSEC/DANE TLSA for trust · _index._agents. (SVCB); _agent-name. (SVCB) ``` DNS SVCB query for _index._agents.{domain}, then SVCB query for the target agent owner name it returns parse: SVCB RRset present with alpn/well-known/cap SvcParamKeys; absence of TargetName error and presence of at least one SvcParamKey confirms an agent record on absent: Domain publishes no DNS-AID SVCB records; DNS-AID cannot be used to bootstrap discovery for this domain ``` Not probed live: not-http. DNS SVCB records; the HTTP well-known form is covered by the aid rule. ## History - 2026-09-05 — seeded from Exa Agent research run - 2026-09-06 — verified against draft-mozleywilliams-dnsop-dnsaid-02 spec text via datatracker.ietf.org - 2026-10-16 — use-case tags (auto) ## Instances - [Infoblox DNS-AID Registry (Linux Foundation)](https://github.com/infobloxopen/dns-aid-core) · Observed 2026-07-15 · venue Every instance with its source is listed on the [instances page](/instances/). Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Depended on by: [Agent Discovery Protocol](/protocols/adp/) - Pairs with: [Agent Identity and Discovery](/protocols/aid/), [Agent Discovery Protocol](/protocols/adp/), [Agentic Resource Discovery](/protocols/ard/), [api-catalog: A Well-Known URI and Link Relation to Help Discovery of APIs](/protocols/api-catalog-rfc9727/), [Agent Name Service v2 (ANS)](/protocols/ans/), [A Framework for Agent Discovery in DAWN](/protocols/dawn-agent-discovery-framework/) - Not to be confused with: AID (Agent Identity and Discovery, a separate, unrelated agentcommunity.org spec that also does DNS-first discovery) ## Comparisons - [DNS (A/SRV) & WHOIS vs AID & DNS-AID (classic vs agentic)](/compare/dns-whois-vs-aid/) - [Agent Identity and Discovery vs DNS for AI Discovery](/compare/aid-vs-dns-aid/) - [Discovery of Model Context Protocol Servers via DNS TXT Records vs DNS for AI Discovery](/compare/mcp-dns-discovery-vs-dns-aid/) - [DNS for AI Discovery vs DNS-Based Agent Naming](/compare/dns-aid-vs-dan/) ## References - draft-mozleywilliams-dnsop-dnsaid-02 (27 May 2026, IETF dnsop, authors from Infoblox, Deutsche Telekom, Amazon) defines SVCB records at an agent's owner name plus a well-known DNS-SD-style _index._agents. organization index, with optional TXT fallback and DANE TLSA for endpoint authentication. — [https://datatracker.ietf.org/doc/html/draft-mozleywilliams-dnsop-dnsaid/](https://datatracker.ietf.org/doc/html/draft-mozleywilliams-dnsop-dnsaid/) (2026-05-27) VERIFIED - Infoblox and GoDaddy jointly announced support for open standards for AI agent discovery, identity and verification, naming this DNS-based approach. — [https://aboutus.godaddy.net/newsroom/news-releases/press-release-details/2026/Infoblox-and-GoDaddy-Support-Open-Standards-for-AI-Agent-Discovery-Identity-and-Verification-2026-0acKMntvOC/default.aspx](https://aboutus.godaddy.net/newsroom/news-releases/press-release-details/2026/Infoblox-and-GoDaddy-Support-Open-Standards-for-AI-Agent-Discovery-Identity-and-Verification-2026-0acKMntvOC/default.aspx) (2026-05-14) REPORTED - ARD v0.91 itself names DNS-AID as a candidate mechanism for federated routing ("leveraging DNS-AID to discover authoritative registries for specific domains"), and ADP (draft-pro-adp) explicitly delegates its DNS layer to DNS-AID. — [https://raw.githubusercontent.com/ards-project/ard-spec/main/spec/ard.md](https://raw.githubusercontent.com/ards-project/ard-spec/main/spec/ard.md) (2026-08-26) VERIFIED Disputed: Two IETF drafts now build on top of DNS-AID's SVCB mechanism (ADP explicitly, ARD's informative discussion) while a third, unrelated spec (AID, agentcommunity.org) independently chose the DNS TXT record at _agent. for the same job. The two are not compatible: DNS-AID uses SVCB records with a _agents/_index label structure; AID (agentcommunity) uses a flat TXT record. No evidence found that these projects coordinate. [JSON](/data/protocols/dns-aid.json) · [Markdown](/protocols/dns-aid/index.md) · [OKF v0.2](/okf/protocols/dns-aid.md) --- # DNS-Based Agent Naming (DAN) DNS-Based Agent Naming (DAN) is an agentic-web standard (DNS record) at step 1, Discover, governed by IETF Independent Submission; its status is "Active Internet-Draft, Intended status: Standards Track". It answers: "Given a domain, which AI agents does it publish, and how can I locate and cryptographically bind to their service…?" Implementation status is prototype, last verified 2026-10-23. ## Quick Wire Reference - **Step**: 1 Discover (What is here, and where?) - **Version**: draft-seethiraju-dawn-dan-00, 5 June 2026 (single published version; no -01 as… - **Status**: Active Internet-Draft (individual, -00), Intended status: Standards Track… - **Discovery / Probe Path**: _agents. (AIINDEX, TYPE65502); ._agents. (AIDISCA, TYPE65501) —… - **Spec URL**: https://datatracker.ietf.org/doc/draft-seethiraju-dawn-dan/ - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: DNS-based Authentication of Named Entities (DANE) for TLS certificates, applied to… [Discover](/category/discover/) DNS-Based Agent Naming (DAN) is an IETF Internet-Draft from Verisign that proposes two brand-new DNS Resource Record types — AIDISCA and AIINDEX — so that an AI agent's discovery metadata can be published and resolved directly through DNS, the way DANE (RFC 6698) binds TLS certificates to domain names [[1]](#ref-1). AIINDEX, published at a zone's _agents label, lists the AI agent publication names available under that zone; AIDISCA, published at each such agent name, atomically carries the protocol identifier (MCP or A2A), a coarse capabilities string, the service endpoint URL, and a DANE-style embedded certificate association, all in one record [[1]](#ref-1). ## Overview It solves the same problem DNS-AID and AID solve — given a domain, find and cryptographically bind to the agents it publishes — but takes a different technical path: rather than reusing SVCB (DNS-AID) or TXT (AID), it mints two entirely new RRtypes and folds the certificate binding into the discovery record itself instead of a separate TLSA lookup, on the theory that this minimizes DNS round-trips [[3]](#ref-3). It does not define semantic search, ranking, policy evaluation, or agent selection — the draft states these are explicitly out of scope — and it does not yet have IANA-assigned RRtype mnemonics, so records must currently be published in RFC3597 generic form (TYPE65501/TYPE65502) using ordinary DNS zone tooling [[1]](#ref-1). Current state as of 2026-09-07: a single version, draft-seethiraju-dawn-dan-00, dated 5 June 2026, submitted as an individual (non-working-group) Internet-Draft with Intended status Standards Track; IESG state is 'I-D Exists' with no telechat scheduled and no responsible Area Director assigned, meaning it has not been adopted by any IETF working group [[1]](#ref-1). Verisign published the draft alongside a supporting arXiv paper and, on 1 September 2026, a blog post announcing a royalty-free public IPR license intended to support eventual standardization [[3]](#ref-3). Who implements it: only Verisign itself, via the open-source verisign/dan proof-of-concept repository, which provides dan-gen (generates AIDISCA/AIINDEX records from MCP endpoint or A2A agent-card metadata) and dan-discover (resolves and prints them). The repo's examples use illustrative domains rather than confirmed production deployments, and the repository shows no external stars, forks, or contributors as of its last commit (18 July 2026) [[2]](#ref-2). Disputed or unknown: DAN, DNS-AID, and AID are three separately authored, technically incompatible DNS-based discovery mechanisms competing to answer the same question, and no evidence was found that any of the three coordinates with or references the others. Whether DAN will be adopted by an IETF working group, merge with a competing draft, or remain an individual submission is unresolved. No third-party adopter, registrar, or DNS host has been found announcing support for DAN specifically (contrast with DNS-AID, which Infoblox and GoDaddy have publicly named). ## Discovery and probe Two new DNS Resource Record types resolved directly (no well-known HTTP path). AIINDEX, published at a zone's _agents label, enumerates the AI agent publication names available in that zone. AIDISCA, published at each agent's own name, atomically carries protocol identifier, coarse-grained capabilities, service endpoint, and a DANE-style embedded certificate association — no separate TLSA lookup is needed. · _agents. (AIINDEX, TYPE65502); ._agents. (AIDISCA, TYPE65501) ``` DNS query QNAME=_agents.{origin} QTYPE=TYPE65502 (AIINDEX) to enumerate published agents; then QNAME=._agents.{origin} QTYPE=TYPE65501 (AIDISCA) for each listed name parse: AIINDEX RDATA contains an AI Agent Domain Name List (each entry a domain name under the zone); AIDISCA RDATA contains AI Agent Proto (1=MCP, 2=A2A), Capabilities (comma-separated string), Service Endpoint (URL), and Certificate Association Data (DANE-style usage/selector/matching-type + hash), plus an optional Extensions field (e.g. an A2A Agent Card URL) on absent: No AIINDEX/AIDISCA records resolve at this zone; the domain does not publish DAN-discoverable agents. Because the two RR types are not yet IANA-assigned to stable mnemonics, records are typically published and queried in RFC3597 generic form (TYPE65501/TYPE65502); most public DNS resolvers, zone editors, and tooling do not recognize AIDISCA/AIINDEX by name yet. ``` Not probed live: not-http. DNS records of types AIINDEX (65502) at _agents. and AIDISCA (65501); not reachable by HTTP GET. ## History - 2026-09-07 — created as a new discover-step record; verified against draft-seethiraju-dawn-dan-00 (datatracker.ietf.org), the verisign/dan proof-of-concept repository, and Verisign's 2026-09-01 blog announcement - 2026-10-16 — use-case tags (auto) ## Instances Verified SDKs, reference implementations & validators: - [verisign/dan (PoC: dan-gen.py, dan-discover.py)](https://github.com/verisign/dan) · implementation (2026-07-18) Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Pairs with: [DNS for AI Discovery](/protocols/dns-aid/), [Agent Identity and Discovery](/protocols/aid/), [Model Context Protocol](/protocols/mcp/), [Agent2Agent Protocol](/protocols/a2a/), [Agent Name Service v2 (ANS)](/protocols/ans/) - Not to be confused with: DNS-AID (unrelated IETF dnsop draft, SVCB-based, Infoblox/Deutsche Telekom/Amazon/GoDaddy), AID (agentcommunity.org, TXT-based, unrelated authorship), ANS/Agent Name Service v2 (dual-certificate + SCITT transparency log, unrelated authorship), DAN also collides with the unrelated 'Do Anything Now' AI jailbreak prompt meme ## Comparisons - [DNS for AI Discovery vs DNS-Based Agent Naming](/compare/dns-aid-vs-dan/) - [Agent Name Service v2 (ANS) vs DNS-Based Agent Naming](/compare/ans-vs-dan/) ## References - draft-seethiraju-dawn-dan-00 (5 June 2026, Verisign authors Seethiraju/Thakar/Shyamsunder/Osterweil, Intended status Standards Track, individual IETF submission with no working-group sponsorship, IESG state 'I-D Exists') defines the AIDISCA and AIINDEX DNS RR types, their RDATA formats, a client processing model, and IANA considerations for a new 'AI Agent Proto' registry and 'AI Agent DNS Extension Code' registry. — [https://datatracker.ietf.org/doc/draft-seethiraju-dawn-dan/](https://datatracker.ietf.org/doc/draft-seethiraju-dawn-dan/) (2026-06-05) VERIFIED - The verisign/dan GitHub repository is an open-source proof-of-concept reference implementation providing dan-gen.py (generates AIDISCA/AIINDEX records in RFC3597 presentation format from MCP endpoint or A2A agent-card metadata plus a certificate file) and dan-discover.py (resolves and human-readably prints published AIDISCA/AIINDEX records); as of the last commit (18 Jul 2026) it has 0 stars/0 forks and demonstrates only example domains (namestudioapi.com, colinmcnamara.com), not confirmed production deployments. — [https://github.com/verisign/dan](https://github.com/verisign/dan) (2026-07-18) VERIFIED - Verisign's own blog post (1 Sep 2026, co-authored by all four draft authors) announces the DAN Internet-Draft, frames it as extending DANE semantics to AI agent discovery, and states Verisign has published a royalty-free public IPR license to support standardization; it does not claim any third-party adoption. — [https://blog.verisign.com/security/proposed-dns-record-types-ai-agent-discovery/](https://blog.verisign.com/security/proposed-dns-record-types-ai-agent-discovery/) (2026-09-01) VERIFIED Disputed: DAN is the third independent IETF-adjacent proposal to bind AI-agent discovery metadata to DNS, alongside DNS-AID (draft-mozleywilliams-dnsop-dnsaid, SVCB records, Infoblox/Deutsche Telekom/Amazon/GoDaddy) and AID (agentcommunity.org, TXT records). Unlike both, DAN does not reuse an existing RR type (SVCB or TXT): it defines two brand-new RR types (AIDISCA, AIINDEX) that must be published in RFC3597 generic form until IANA assigns mnemonics, and it embeds the certificate association directly inside AIDISCA rather than pointing to a separate DANE TLSA record. No evidence was found in this pass that Verisign's draft references, cites, or coordinates with the DNS-AID or AID authors, or vice versa; all three compete to answer the same 'discover' question with incompatible DNS shapes. [JSON](/data/protocols/dan.json) · [Markdown](/protocols/dan/index.md) · [OKF v0.2](/okf/protocols/dan.md) --- # EMV Agentic Payments – Framework for Specifications EMV Agentic Payments – Framework for Specifications is an agentic-web standard (document format) at step 7, Pay, governed by EMVCo, the technical body jointly owned by American Express…; its status is "Draft v1.0, released for public review and comment". It answers: "When a card network, issuer, merchant, or wallet sees an AI-agent-initiated card payment, how do they consistently find…?" Implementation status is none found, last verified 2026-10-23. ## Quick Wire Reference - **Step**: 7 Pay (Settle the bill) - **Version**: EMV® Agentic Payments – Framework for Specifications, v1.0 DRAFT (2026-08-31) - **Status**: Draft v1.0, released for public review and comment; EMVCo describes it as ‘a… - **Discovery / Probe Path**: none - **Spec URL**: https://www.emvco.com/resources/emv-agentic-payments-framework-for-specifications-v1-0-draft-comment-period-ends-30-sept-2026/ - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: A shared authorisation-hold / standing-order ledger that every party in a card… [Pay](/category/pay/) EMV Agentic Payments – Framework for Specifications is a draft document, not yet a technical specification, published on 1 September 2026 by EMVCo – the technical body jointly owned by American Express, Discover, JCB, Mastercard, UnionPay and Visa that creates and manages the EMV Specifications used for card payments worldwide [[4]](#ref-4). It was produced by EMVCo's newly formed Agentic Payments Task Force, chaired by Clinton Allen, and opened for public comment through 30 September 2026 [[1]](#ref-1)[[3]](#ref-3). ## Overview What it solves: it addresses a specific gap in card-based agentic commerce — how the parties in a card transaction (issuer, network, merchant, acquirer) consistently determine what a consumer actually authorised an AI agent to do, particularly for scenarios where authority persists over time rather than being exercised once, such as recurring purchases, cumulative spending budgets, and actions after the initial transaction (returns, disputes, modifications) [[1]](#ref-1)[[2]](#ref-2). Its central proposal is 'Intent Services': a shared, interoperable layer where participants can register, reference, retrieve and manage a consumer's authorised intent as a persistent state object, rather than each party inferring intent independently. EMVCo frames this as complementary to, not a replacement for, cryptographic intent-assurance mechanisms already in the market (it names 'Verifiable Intent' without further specifying whose) — Intent Services is positioned as a coordination point on top of that cryptographic layer [[1]](#ref-1)[[2]](#ref-2). What it does not do: as of this verification, the document is a framework — it describes ecosystem roles and the categories of data fields Intent Services would need, not a wire protocol, message schema, API surface, or well-known discovery path. It defines no endpoint, header, or file that could be probed today. It explicitly scopes itself to card-based payments only, so it does not address bank-transfer, stablecoin, or other rails covered by protocols like x402 or ACP. It also does not yet define Know Your Agent (KYA) or 'Agentic Transaction Indicators' for flagging that a transaction was agent-initiated — EMVCo says it 'may consider' these in future publications, but they are not part of this draft [[1]](#ref-1)[[2]](#ref-2). Current state: this is v1.0 DRAFT, released 2026-08-31/09-01, under public comment until 2026-09-30; EMVCo describes it as a foundation for further industry engagement and potential specification development, i.e. a pre-specification stage document. No implementation, pilot, or conformance programme exists yet, and none is claimed by EMVCo or any third party. EMVCo says it is collaborating with the FIDO Alliance, OpenID Foundation, OpenWallet Foundation and W3C to keep the framework interoperable with adjacent identity/credential work rather than fragmenting it [[2]](#ref-2). How it relates to other pay-step records on this site: it overlaps in problem space with Google's AP2 (which also formalises consumer-authorised purchase intent as signed Mandates) and with UCP and OpenAI/Stripe's ACP (which define merchant-facing commerce/checkout flows an agent can invoke); EMVCo positions its work as complementary rather than competing — a card-network-side intent-coordination layer that other protocols' payment steps could plug into — but as of this draft there is no published mapping of how an AP2 Payment Mandate, a UCP Payment Token Exchange, or an ACP checkout would concretely interact with an EMVCo Intent Service. What is unresolved: whether Intent Services will be specified as an EMVCo-hosted API, a shared registry, or a set of data-field requirements that networks implement individually; how 'Verifiable Intent' (the cryptographic layer EMVCo says it complements) is itself specified and by whom; and whether this becomes a formal EMV Specification (with EMVCo's usual compliance/testing programme) or remains a lighter-weight framework. ## Discovery and probe none published — the draft is a conceptual/organisational framework (roles, data fields, an ‘Intent Services’ concept) for a future specification; it defines no fixed well-known path, header, or endpoint an agent or origin could probe for today · none ``` none none parse: not applicable — this is a draft framework document, not a deployed protocol; there is no wire format, endpoint, or file to fetch, matching how other pre-implementation pay-step drafts (e.g. vcap) are recorded on absent: No probe exists; EMVCo has not yet published a technical specification, so absence of any signal cannot be distinguished from the framework simply not having reached implementation yet ``` Not probed live: no-fixed-path. A framework document for card-network payment specifications; nothing is published at an origin. ## History - 2026-09-07 — created and verified against EMVCo's 2026-09-01 news release, the companion EMV Insights article by Clinton Allen, independent trade press (fintech.global, 2026-09-04), and the EMVCo overview page - 2026-10-16 — use-case tags (auto) ## Instances Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Pairs with: [Agent Payments Protocol](/protocols/ap2/), [AP2 Checkout Mandate](/protocols/ap2-checkout-mandate/), [Universal Commerce Protocol](/protocols/ucp/), [Agentic Commerce Protocol](/protocols/agentic-commerce-protocol/), [Verifiable Intent](/protocols/vi/) - Not to be confused with: AP2 (Google's Agent Payments Protocol, also card/mandate-oriented), ACP (Agentic Commerce Protocol, OpenAI/Stripe), UCP (Universal Commerce Protocol, Google), Verifiable Intent (vi) — the cryptographic intent layer EMVCo names as complementary; see that article ## Comparisons - [3-D Secure & Card Checkout vs AP2, ACP & UCP (classic vs agentic)](/compare/3d-secure-vs-ap2/) - [Agent Payments Protocol vs EMV Agentic Payments – Framework for Specifications](/compare/ap2-vs-emv-agentic-payments/) - [Agentic Commerce Protocol vs EMV Agentic Payments – Framework for Specifications](/compare/agentic-commerce-protocol-vs-emv-agentic-payments/) - [Verifiable Intent vs EMV Agentic Payments – Framework for Specifications](/compare/vi-vs-emv-agentic-payments/) ## References - On 1 September 2026 EMVCo – described as ‘the technical body that creates and manages EMV® Specifications and programmes’ – released a draft framework, EMV® Agentic Payments – Framework for Specifications v1.0, for public comment through 30 September 2026, focused on card-based agentic payment scenarios (recurring purchases, cumulative budgets, post-transaction activity) where consumer intent must be managed over time; it introduces the concept of ‘Intent Services’, a shared interoperable layer letting payment participants register, reference, retrieve and manage consumer-authorised intent before, during and after a transaction. — [https://www.emvco.com/news/emvco-requests-feedback-on-framework-for-secure-interoperable-and-scalable-card-based-agentic-payments/](https://www.emvco.com/news/emvco-requests-feedback-on-framework-for-secure-interoperable-and-scalable-card-based-agentic-payments/) (2026-09-01) VERIFIED - Clinton Allen, Chair of the EMVCo Agentic Payments Task Force, explains the framework centres on use-cases where a consumer delegates card-payment authority to an AI agent; it is meant to complement cryptographic assurance from existing solutions such as Verifiable Intent with a common coordination point; it may inform future enhancements to EMV 3-D Secure, EMV Payment Tokenisation, EMV Secure Remote Commerce and the EMV Digital Payment Credential, and EMVCo may pursue future work on Know Your Agent (KYA) and Agentic Transaction Indicators; EMVCo is collaborating with the FIDO Alliance, OpenID Foundation, OpenWallet Foundation and W3C to avoid ecosystem fragmentation. — [https://www.emvco.com/knowledge-hub/how-emvco-is-working-to-enable-secure-interoperable-and-scalable-card-based-agentic-payments/](https://www.emvco.com/knowledge-hub/how-emvco-is-working-to-enable-secure-interoperable-and-scalable-card-based-agentic-payments/) (2026-09-01) VERIFIED - Independent trade press confirms the framework was developed by EMVCo's newly formed Agentic Payments Task Force (chaired by Clinton Allen), covers card-based payments where consumers authorise recurring purchases or spending limits for an AI agent, and introduces Intent Services as an interoperable layer for registering and tracking authorised purchasing intent across the transaction lifecycle, working alongside cryptographic technologies such as Verifiable Intent. — [https://fintech.global/2026/09/04/emvco-drafts-framework-for-agentic-card-payments/](https://fintech.global/2026/09/04/emvco-drafts-framework-for-agentic-card-payments/) (2026-09-04) VERIFIED - EMVCo's stated mission is 'to facilitate the worldwide interoperability of secure payment transactions by developing and publishing the EMV Specifications and their related testing processes'; EMVCo itself does not mandate or enforce implementation — that is left to payment networks, issuers, merchants and acquirers. — [https://www.emvco.com/about-us/overview-of-emvco/](https://www.emvco.com/about-us/overview-of-emvco/) VERIFIED [JSON](/data/protocols/emv-agentic-payments.json) · [Markdown](/protocols/emv-agentic-payments/index.md) · [OKF v0.2](/okf/protocols/emv-agentic-payments.md) --- # ERC-8001: Agent Coordination Framework ERC-8001: Agent Coordination Framework is an agentic-web standard (on-chain registry) at step 6, Coordinate, governed by Ethereum EIP/ERC process; its status is "Final Standards Track ERC". It answers: "How can several agents agree on-chain that a coordinated action may run only once every required participant has signed…?" Implementation status is prototype, last verified 2026-10-23. ## Quick Wire Reference - **Step**: 6 Coordinate (Talk to another agent) - **Version**: Final, created 2025-08-02 (2025-12-16) - **Status**: Final Standards Track ERC (moved to Last Call 2025-12-02 and to Final… - **Discovery / Probe Path**: none — no well-known file; discovery is by contract address/ABI — EVM smart-contract… - **Spec URL**: https://eips.ethereum.org/EIPS/eip-8001 - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: A contract that takes effect only when every party has countersigned [Coordinate](/category/coordinate/) ERC-8001 is a Final Ethereum standard for agents that need to act together without a trusted coordinator [[1]](#ref-1). An initiator posts an EIP-712 signed intent naming the participants; each participant posts its own signed acceptance (EIP-712, or ERC-1271 for contract wallets); and the intent becomes executable only once every required acceptance is present and unexpired [[1]](#ref-1). Canonical, sorted participant lists, nonces and standard typed data give replay protection and wallet compatibility, and the spec fixes the lifecycle and the events a contract must emit [[1]](#ref-1). ## Overview It is deliberately small. The authors leave privacy, reputation, threshold policies, bonding and cross-chain coordination to optional modules that reference it, and the spec includes a reference contract rather than pointing to production deployments [[1]](#ref-1). It moved to Last Call on 2025-12-02 and to Final on 2025-12-16 [[2]](#ref-2). Related: ERC-8107, an ENS Trust Registry by the same author and still in Review, is written as the trust and delegation module ERC-8001 anticipates. Agents vouch for or deny each other under ENS names, and a coordinator can admit only participants reachable through a trust path [[3]](#ref-3). No count of ERC-8001 deployments was found, so adoption is unmeasured. ## Discovery and probe EVM smart-contract interface; an initiator posts an EIP-712 intent and participants post EIP-712 or ERC-1271 acceptances to an ERC-8001 contract · none — no well-known file; discovery is by contract address/ABI ``` eth_call {contract_address} parse: Contract implements the ERC-8001 functions (proposeCoordination, acceptCoordination, executeCoordination, cancelCoordination, getCoordinationStatus, getRequiredAcceptances, getAgentNonce) and emits the mandatory lifecycle events on absent: Absence at a given contract address only shows that deployment does not implement ERC-8001; there is no registry of ERC-8001 deployments to enumerate. ``` Not probed live: not-http. An Ethereum contract; observable via eth_call, not HTTP. ## History - 2026-10-20 — added from gap scout 2026-10-20; verified against eips.ethereum.org/EIPS/eip-8001, the ERCs repository file and commit history (Last Call 2025-12-02, Final 2025-12-16), and eips.ethereum.org/EIPS/eip-8107 (related ENS Trust Registry, Review) ## Instances Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Pairs with: [ERC-8183: Agentic Commerce](/protocols/erc-8183/), [ERC-8004: Trustless Agents](/protocols/erc-8004/) ## References - ERC-8001 defines a minimal single-chain primitive for multi-party agent coordination: an initiator posts an intent, each participant provides a verifiable acceptance attestation, and the intent is executable once the required set of acceptances is present and fresh. It requires EIP-712, ERC-1271, EIP-2098 and EIP-5267, leaves privacy, reputation, thresholds, bonding and cross-chain semantics to optional modules, and ships a reference implementation (AgentCoordination.sol). Status Final, created 2025-08-02, author Kwame Bryan. — [https://eips.ethereum.org/EIPS/eip-8001](https://eips.ethereum.org/EIPS/eip-8001) (2025-12-16) VERIFIED - The ERCs repository front matter for erc-8001.md reads status: Final; its commit history shows the move to Last Call on 2025-12-02 and to Final on 2025-12-16. — [https://github.com/ethereum/ERCs/blob/master/ERCS/erc-8001.md](https://github.com/ethereum/ERCs/blob/master/ERCS/erc-8001.md) (2025-12-16) VERIFIED - ERC-8107 'ENS Trust Registry for Agent Coordination' (status Review, created 2025-12-16, same author) defines a web-of-trust registry keyed by ENS names, with OpenPGP-style trust levels and path verification, as the trust and delegation module that ERC-8001 anticipates; it requires ERC-8001. — [https://eips.ethereum.org/EIPS/eip-8107](https://eips.ethereum.org/EIPS/eip-8107) (2025-12-16) VERIFIED [JSON](/data/protocols/erc-8001.json) · [Markdown](/protocols/erc-8001/index.md) · [OKF v0.2](/okf/protocols/erc-8001.md) --- # ERC-8004: Trustless Agents (/.well-known/agent-registration.json) ERC-8004: Trustless Agents is an agentic-web standard (on-chain registry — /.well-known/agent-registration.json) at step 2, Identify, governed by Ethereum EIP process; its status is "Draft Standards Track ERC". It answers: "Who is an agent, and what onchain identity, reputation and validation record does it carry?" Replacing or extending DNS plus a public review/reputation ledger, implementation status is multi-implementation (Forbes citing community trackers), last verified 2026-10-23. ## Quick Wire Reference - **Step**: 2 Identify (Who is this agent? Who is this site?) - **Version**: Draft ERC, created 2025-08-13; Identity and Reputation Registries live on… - **Status**: Draft Standards Track ERC · multi-implementation - **Discovery / Probe Path**: /.well-known/agent-registration.json — ERC-721 Identity Registry token (agentId) resolves via… - **Spec URL**: https://eips.ethereum.org/EIPS/eip-8004 - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: DNS plus a public review/reputation ledger [Identify](/category/identify/) ERC-8004 ("Trustless Agents") is a draft Ethereum standard that gives autonomous agents a portable, onchain identity plus pluggable trust signals, so that agents from different organizations can discover and transact with one another without a pre-existing relationship [[1]](#ref-1). It defines three per-chain singleton registries: an Identity Registry (an ERC-721 token whose tokenURI, here called agentURI, points to a JSON registration file listing the agent's name, description and service endpoints — A2A agent cards, MCP endpoints, ENS names, DIDs, wallets); a Reputation Registry (a standard interface for clients to post signed numeric feedback, with onchain filtering by reviewer and tag to blunt Sybil attacks); and a Validation Registry (generic hooks for requesting and recording independent checks of an agent's work, e.g. by staked re-execution, zkML proofs, or TEE attestations) [[1]](#ref-1). ## Overview It solves discovery-plus-trust for cross-organizational agent economies: MCP and A2A cover how an agent is invoked and how it advertises skills, but neither defines a portable identity an unrelated party can look up and score [[1]](#ref-1). ERC-8004 does not itself define payments (it notes x402 as a complementary, orthogonal protocol), does not prescribe how validation is actually computed (that is left to competing validator networks), and — by the authors' own admission — cannot cryptographically guarantee that an agent's advertised capabilities are functional or non-malicious; it only anchors identity and makes trust signals public and structured [[1]](#ref-1). Current state: still a Draft ERC (no EIP number finalization; created 2025-08-13) [[1]](#ref-1). The Identity and Reputation Registry contracts went live on Ethereum mainnet on 2026-01-29 at deterministic addresses (0x8004A169... and 0x8004BAa1...), following roughly three months of testnet activity reported at over 10,000 registered agents and 20,000 feedback entries [[2]](#ref-2). A community-maintained tracker shows the same two contracts redeployed at identical addresses across at least 16 EVM chains (Base, Arbitrum, Optimism, Polygon, Avalanche, and others), while listing the Validation Registry as still under active revision rather than finalized [[3]](#ref-3). Reference implementations and a client-side verification dApp (AtlasNexus Verify) are cited by the same tracker [[3]](#ref-3). Implementers: the reference implementation repository (erc8004/reference-implementation), the coordinating site 8004.org, and independent tooling such as AtlasNexus Verify [[2]](#ref-2)[[3]](#ref-3). The EIP requires EIP-155, EIP-712, EIP-721 and EIP-1271 as building blocks [[1]](#ref-1). Disputed or unknown: adoption figures (10,000+ agents, 20,000+ feedback entries) come from press and community trackers, not a probe we ran ourselves, so we label them claimed rather than measured. It is also unresolved whether the Validation Registry will ship as specified or be substantially revised, and whether reputation aggregation across chains will be standardized or remain ad hoc per aggregator [[1]](#ref-1)[[3]](#ref-3). ## Discovery and probe ERC-721 Identity Registry token (agentId) resolves via agentURI to a JSON agent registration file; optional HTTPS domain proof at a fixed well-known path · /.well-known/agent-registration.json ``` GET https://{endpoint-domain}/.well-known/agent-registration.json parse: JSON body has a registrations[] entry whose agentRegistry (eip155:{chainId}:{identityRegistry}) and agentId match the onchain agent being checked on absent: Endpoint-domain control is not proven by this optional file; the agent's core identity may still be valid via the onchain agentURI directly (a JSON file at any URI scheme, not necessarily HTTPS at this path) ``` Live check run by [the MCP probe](/mcp/server-card): GET /.well-known/agent-registration.json. ERC-8004 agents publish a registration file with a top-level registrations[] array at the domain they claim. ``` { "path": "/.well-known/agent-registration.json", "expect": { "content_type": "json", "json_keys": [ "registrations" ] }, "note": "ERC-8004 agents publish a registration file with a top-level registrations[] array at the domain they claim." } ``` ## History - 2026-09-05 — seeded from Exa Agent research run - 2026-09-06 — verified against EIP-8004 primary text, Forbes mainnet-launch report (2026-02-05), and community deployment tracker (awesome-erc8004) - 2026-09-07 — added the arXiv 2606.26028 empirical study on live endpoints and Sybil feedback - 2026-10-16 — use-case tags (auto) - 2026-10-20 — added ERC-8122 (Minimal Agent Registry, Draft), an alternative registry design that cites ERC-8004's singleton-per-chain model; from gap scout 2026-10-20, verified against eips.ethereum.org/EIPS/eip-8122 ## Instances - [Openfort Agentic Wallets](https://www.openfort.io) · Observed 2026-10-23 · authority - [8004.org / ERC-8004 Trustless Agents Registry](https://www.8004.org) · Observed 2026-08-13 · venue - [BNB Chain BNBAgent SDK and Identity Authority](https://bnbchain.org) · Observed 2026-07-02 · authority - [ERC-8004 Canonical Registry Contracts (Mainnet and 16 Chains)](https://github.com/erc-8004/erc-8004-contracts) · Observed 2026-01-29 · authority Every instance with its source is listed on the [instances page](/instances/). Verified SDKs, reference implementations & validators: - [Identity Registry (mainnet + 16 chains)](https://etherscan.io/address/0x8004A169FB4a3325136EB29fA0ceB6D2e539a432) · implementation (2026-01-29) - [Reputation Registry (mainnet + 16 chains)](https://etherscan.io/address/0x8004BAa17C55a88189AE136b182e5fdA19dE9b63) · implementation (2026-01-29) Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Depended on by: [ERC-8126: AI Agent Verification](/protocols/erc-8126/), [ERC-8183: Agentic Commerce](/protocols/erc-8183/), [ERC-8226 Regulated Agent Mandate](/protocols/erc-8226/) - Pairs with: [Agent2Agent Protocol](/protocols/a2a/), [Model Context Protocol](/protocols/mcp/), [x402](/protocols/x402/), [Open Agentic Schema Framework](/protocols/oasf/), [Agent Name Service v2 (ANS)](/protocols/ans/), [ERC-8001: Agent Coordination Framework](/protocols/erc-8001/) - [Agentic EoR (Employer / Entity of Record)](/terms/agentic-eor/) ## Comparisons - [User-Agent & IP Allowlists vs Web Bot Auth (RFC 9421) (classic vs agentic)](/compare/user-agent-vs-web-bot-auth/) - [ERC-8004: Trustless Agents vs Agent Name Service v2 (ANS)](/compare/erc-8004-vs-ans/) - [ERC-8004: Trustless Agents vs ERC-8126: AI Agent Verification](/compare/erc-8004-vs-erc-8126/) - [ERC-8004: Trustless Agents vs KYA-OS (Know Your Agent Operating System)](/compare/erc-8004-vs-kya-os/) ## References - EIP-8004 defines three per-chain singleton registries (Identity, Reputation, Validation) and the JSON agent registration file format, including the optional /.well-known/agent-registration.json domain-verification file — [https://eips.ethereum.org/EIPS/eip-8004](https://eips.ethereum.org/EIPS/eip-8004) (2025-08-13) VERIFIED - Identity Registry (0x8004A169FB4a3325136EB29fA0ceB6D2e539a432) and Reputation Registry (0x8004BAa17C55a88189AE136b182e5fdA19dE9b63) deployed at identical addresses on Ethereum mainnet since 29 Jan 2026, after ~3 months of testnet use (10,000+ agents, 20,000+ feedback entries reported) — [https://www.forbes.com/sites/digital-assets/2026/02/05/ai-agents-gain-trust-via-ethereum-erc-8004-on-mainnet/](https://www.forbes.com/sites/digital-assets/2026/02/05/ai-agents-gain-trust-via-ethereum-erc-8004-on-mainnet/) (2026-02-05) VERIFIED - Community-maintained tracker lists the same two contract addresses deployed identically across 16+ EVM chains (Base, Arbitrum, Optimism, Polygon, etc.) and documents the Validation Registry as still under active revision, unlike the finalized Identity/Reputation contracts — [https://github.com/sudeepb02/awesome-erc8004](https://github.com/sudeepb02/awesome-erc8004) REPORTED - Empirical study of 112,921 registrations across Ethereum, BSC and Base: only 3–15% expose a valid ERC-8004 registration file with at least one live service endpoint, and about 90.6% of reputation reviewers exhibit coordinated Sybil behaviour (Xiong et al., arXiv 2606.26028, 2026-06-24). — [https://arxiv.org/abs/2606.26028](https://arxiv.org/abs/2606.26028) (2026-06-24) VERIFIED - ERC-8122 'Minimal Agent Registry' (Draft, created 2025-12-17, author Prem Makeig) proposes a lightweight agent-discovery registry built on ERC-6909 that anyone can deploy on any L2 or mainnet, with fully on-chain metadata (ERC-8048) and cross-chain agent ids (ERC-7930). Its motivation cites ERC-8004's one-singleton-per-chain design as the reason for an alternative that supports custom and curated registries. — [https://eips.ethereum.org/EIPS/eip-8122](https://eips.ethereum.org/EIPS/eip-8122) (2025-12-17) VERIFIED Disputed: The Validation Registry (stake/zkML/TEE-backed independent checking) is not finalized while Identity and Reputation are; adoption is reported by trackers and press, not independently counted by us. Registration counts should be read as a ceiling: the June 2026 empirical study found only 3–15% of registrations point at a live endpoint. [JSON](/data/protocols/erc-8004.json) · [Markdown](/protocols/erc-8004/index.md) · [OKF v0.2](/okf/protocols/erc-8004.md) --- # ERC-8126: AI Agent Verification ERC-8126: AI Agent Verification is an agentic-web standard (on-chain registry) at step 2, Identify, governed by Ethereum EIP/ERC process; its status is "Final Standards Track ERC". It answers: "How can an agent registered under ERC-8004 be put through standard security checks and carry a comparable risk score?" Implementation status is prototype, last verified 2026-10-23. ## Quick Wire Reference - **Step**: 2 Identify (Who is this agent? Who is this site?) - **Version**: Final, created 2026-01-15 (2026-06-02) - **Status**: Final Standards Track ERC (moved to Last Call 2026-05-12 and to Final… - **Discovery / Probe Path**: none — no well-known file; discovery is by contract address/ABI — Agents are identified by… - **Spec URL**: https://eips.ethereum.org/EIPS/eip-8126 - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: A security audit report with a credit-style score, attached to an on-chain identity [Identify](/category/identify/) ERC-8126 is a Final Ethereum standard for checking AI agents that already hold an ERC-8004 identity [[1]](#ref-1). A verification provider runs up to five checks: the agent's token contract, media it produces (with C2PA guidance), its Solidity code (with OWASP guidance), its web endpoints, and its wallet history. It turns the results into zero-knowledge proofs and a single 0-100 risk score [[1]](#ref-1). Detailed results go only to the agent's wallet holder, and attestations can be posted to ERC-8004's Validation Registry so others can see that a check happened [[1]](#ref-1). An optional quantum-resistant encryption layer is also described [[1]](#ref-1). ## Overview It is the first layer of a two-part stack by the same authors: ERC-8196 builds policy-bound agent wallets on top of it. The authors are Leigh Cronian (Cybercentry) and Chris Johnson (Virtuals) [[1]](#ref-1). It moved to Last Call on 2026-05-12 and to Final on 2026-06-02 [[2]](#ref-2). The oddity: ERC-8126 is Final while the standard it requires, ERC-8004, is still a Draft that can change [[2]](#ref-2)[[3]](#ref-3). Its interfaces could therefore break if ERC-8004 changes before finalisation. The spec carries reference code, but no deployed verification provider was counted in this pass, so adoption is unmeasured. ## Discovery and probe Agents are identified by their ERC-8004 Identity Registry token; verification attestations can be posted to ERC-8004's Validation Registry · none — no well-known file; discovery is by contract address/ABI ``` eth_call {contract_address} parse: Look up the agent in an ERC-8004 Validation Registry for ERC-8126 verification attestations; detailed results and the 0-100 risk score are readable only by the agent's wallet holder on absent: No attestation means no ERC-8126 provider has posted one for this agent; it says nothing about whether the agent is safe. ``` Not probed live: not-http. An Ethereum contract; observable via eth_call, not HTTP. ## History - 2026-10-20 — added from gap scout 2026-10-20; verified against eips.ethereum.org/EIPS/eip-8126, the ERCs repository file and commit history (Last Call 2026-05-12, Final 2026-06-02), and the ERC-8004 EIP page (Draft); dispute recorded: Final while its dependency ERC-8004 is Draft ## Instances Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Builds on: [ERC-8004: Trustless Agents](/protocols/erc-8004/) - Depended on by: [ERC-8196: AI Agent Authenticated Wallet](/protocols/erc-8196/) - Pairs with: [ERC-8004: Trustless Agents](/protocols/erc-8004/), [ERC-8196: AI Agent Authenticated Wallet](/protocols/erc-8196/) ## Comparisons - [ERC-8004: Trustless Agents vs ERC-8126: AI Agent Verification](/compare/erc-8004-vs-erc-8126/) ## References - ERC-8126 defines a standard interface for verifying AI agents registered via ERC-8004, with five verification types (Ethereum Token, Media Content, Solidity Code, Web Application and Wallet Verification), zero-knowledge proofs generated by Private Data Verification, and a unified 0-100 risk score visible only to the agent's wallet holder; attestations can be posted to ERC-8004's Validation Registry. Status Final; requires 155, 191, 712, 721, 3009 and 8004; created 2026-01-15. — [https://eips.ethereum.org/EIPS/eip-8126](https://eips.ethereum.org/EIPS/eip-8126) (2026-06-02) VERIFIED - The ERCs repository front matter for erc-8126.md reads status: Final with requires including 8004; its commit history shows the move to Last Call on 2026-05-12 and to Final on 2026-06-02. — [https://github.com/ethereum/ERCs/blob/master/ERCS/erc-8126.md](https://github.com/ethereum/ERCs/blob/master/ERCS/erc-8126.md) (2026-06-02) VERIFIED - ERC-8004, which ERC-8126 requires, is still status Draft on its EIP page. — [https://eips.ethereum.org/EIPS/eip-8004](https://eips.ethereum.org/EIPS/eip-8004) (2025-08-13) VERIFIED Disputed: ERC-8126 reached Final while it depends on ERC-8004, which is still a Draft. A Final standard is meant to be frozen, but the identity and validation registries it builds on can still change, so ERC-8126 implementations may need to follow ERC-8004 revisions. [JSON](/data/protocols/erc-8126.json) · [Markdown](/protocols/erc-8126/index.md) · [OKF v0.2](/okf/protocols/erc-8126.md) --- # ERC-8183: Agentic Commerce ERC-8183: Agentic Commerce is an agentic-web standard (on-chain registry) at step 7, Pay, governed by Ethereum EIP/ERC process; its status is "Draft ERC — This specification defines the Agentic Commerce…". It answers: "How can two agents (a client and a provider) settle a job on-chain, with funds held in escrow and released only once an…?" Replacing or extending Escrow contract with a third-party inspector, implementation status is prototype, last verified 2026-10-23. ## Quick Wire Reference - **Step**: 7 Pay (Settle the bill) - **Version**: Draft, created 2026-02-25 (2026-02-25) - **Status**: Draft ERC — 'This specification defines the Agentic Commerce Protocol: a job… - **Discovery / Probe Path**: none — no well-known file; discovery is by contract address/ABI — EVM smart-contract… - **Spec URL**: https://eips.ethereum.org/EIPS/eip-8183 - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: Escrow contract with a third-party inspector [Pay](/category/pay/) ERC-8183 is a draft Ethereum standard (an ERC on the Standards Track) that defines a minimal on-chain escrow-and-attestation primitive for agent-to-agent commerce: a client locks a budget in an EIP-20 token, a provider submits work, and a designated evaluator (who can be the client itself) either attests completion — releasing escrow to the provider, minus an optional platform fee — or rejects, refunding the client [[1]](#ref-1). A job moves through exactly six states (Open, Funded, Submitted, Completed, Rejected, Expired) with a fixed, small set of allowed transitions, and an optional attestation reason (e.g. a hash) is designed to compose with reputation systems such as ERC-8004 [[1]](#ref-1). ## Overview It solves the narrow case of "client funds work, one attester says done or not done" for agent marketplaces, deliberately keeping the surface small so implementations stay composable, and it explicitly leaves broader agent discovery, negotiation, and reputation to other standards [[1]](#ref-1). It does not define off-chain messaging, does not specify how a client and provider find each other, and does not itself handle currencies other than EIP-20 tokens; it is a settlement primitive, not a full commerce protocol. As of this verification (draft created 2026-02-25, still Draft status), ERC-8183 provides a reference implementation in Solidity (AgenticCommerce.sol, IACPHook.sol) inside the specification itself, and its authors — Davide Crapis, Bryan Lim, Tay Weixiong, and Chooi Zuhwa — include contributors associated with the Virtuals Protocol ecosystem (usernames @ai-virtual-b, @twx-virtuals) based on their GitHub handles, though no independent confirmation of employer affiliation was sought [[1]](#ref-1)[[2]](#ref-2). No deployed, audited, or adopted implementation beyond the reference contracts was located during this verification, so implementation is recorded as prototype and adoption as unmeasured. What is disputed: this proposal's abstract calls itself "the Agentic Commerce Protocol," the identical informal name used for the unrelated OpenAI/Stripe/Meta REST checkout standard tracked separately in this dataset as agentic-commerce-protocol. The two are unconnected — different governance, different technology (on-chain escrow vs. off-chain REST checkout), different authors — and a reader searching "Agentic Commerce Protocol" could easily conflate them. This dataset disambiguates by acronym: ACP (OpenAI/Stripe/Meta) vs. ERC-8183. ## Discovery and probe EVM smart-contract interface (job created on an AgenticCommerce contract deployment) · none — no well-known file; discovery is by contract address/ABI ``` eth_call {contract_address} parse: Contract implements the ERC-8183 job state machine functions (setBudget, fund, submit, complete, reject, claimRefund) and emits the corresponding lifecycle events; requires EIP-20 for the escrowed token on absent: Absence at a given contract address only shows that specific deployment does not implement ERC-8183; there is no registry of ERC-8183 deployments to enumerate, so 'is ERC-8183 adopted' cannot be answered by any single probe. ``` Not probed live: not-http. An Ethereum contract; observable via eth_call, not HTTP. ## History - 2026-09-05 — seeded from Exa Agent research run - 2026-09-06 — verified against eips.ethereum.org/EIPS/eip-8183; flagged name collision with agentic-commerce-protocol (ACP) - 2026-10-16 — use-case tags (auto) ## Instances - [QNTX and ClawPlaza ERC-8183 Job Escrow Markets](https://eips.ethereum.org/EIPS/eip-8183) · Observed 2026-07-02 · venue Every instance with its source is listed on the [instances page](/instances/). Verified SDKs, reference implementations & validators: - [Virtuals ACP (Agent Commerce Protocol, EconomyOS)](https://os.virtuals.io/acp/overview/) · implementation (2026-10-20) Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Builds on: [ERC-8004: Trustless Agents](/protocols/erc-8004/) - Pairs with: [ERC-8004: Trustless Agents](/protocols/erc-8004/), [x402](/protocols/x402/), [Agentic Commerce Protocol](/protocols/agentic-commerce-protocol/), [Agent2Agent Protocol](/protocols/a2a/), [ERC-8226 Regulated Agent Mandate](/protocols/erc-8226/), [ERC-8001: Agent Coordination Framework](/protocols/erc-8001/) - [Agentic EoR (Employer / Entity of Record)](/terms/agentic-eor/) - Not to be confused with: Agentic Commerce Protocol (OpenAI/Stripe ACP) ## Comparisons - [ERC-8183: Agentic Commerce vs x402](/compare/erc-8183-vs-x402/) ## References - ERC-8183's abstract defines a job with escrowed budget and four states (Open, Funded, Submitted, Terminal outcomes Completed/Rejected/Expired), with an evaluator who alone may mark a submitted job completed, requires EIP-20, and cites composability with ERC-8004 for reputation. The EIP page lists a Discussion Link at Ethereum Magicians and names four individual authors, with a reference implementation (IACPHook.sol, AgenticCommerce.sol) included in the specification; status is Draft on the ERC standards track. — [https://eips.ethereum.org/EIPS/eip-8183](https://eips.ethereum.org/EIPS/eip-8183) (2026-02-25) VERIFIED - The Ethereum Magicians discussion thread for ERC-8183 ('erc-8183-agentic-commerce') is live and hosts the proposal's community discussion, corroborating the EIP page's listed Discussion Link. — [https://ethereum-magicians.org/t/erc-8183-agentic-commerce/27902](https://ethereum-magicians.org/t/erc-8183-agentic-commerce/27902) (2026-02-25) REPORTED Disputed: The proposal's own title and abstract call the standard 'the Agentic Commerce Protocol,' the same phrase used by the unrelated OpenAI/Stripe specification tracked in this dataset as 'agentic-commerce-protocol.' The two share no governance, code, or organization; ERC-8183 is an on-chain escrow/attestation primitive on Ethereum, while ACP is an off-chain REST checkout API maintained by OpenAI, Stripe, and Meta. [JSON](/data/protocols/erc-8183.json) · [Markdown](/protocols/erc-8183/index.md) · [OKF v0.2](/okf/protocols/erc-8183.md) --- # ERC-8196: AI Agent Authenticated Wallet ERC-8196: AI Agent Authenticated Wallet is an agentic-web standard (on-chain registry) at step 3, Permit, governed by Ethereum EIP/ERC process; its status is "Final Standards Track ERC". It answers: "How can an asset owner let an AI agent transact from a wallet only within a policy the owner set, with proof and an…?" Implementation status is none found, last verified 2026-10-23. ## Quick Wire Reference - **Step**: 3 Permit (What may the agent do here?) - **Version**: Final, created 2026-03-14 (2026-07-21) - **Status**: Final Standards Track ERC (Final 2026-07-21); requires ERC-4337 and ERC-8126 ·… - **Discovery / Probe Path**: none — no well-known file; discovery is by contract address/ABI — EVM smart-contract… - **Spec URL**: https://eips.ethereum.org/EIPS/eip-8196 - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: A corporate card with spending rules enforced by the card itself, plus a… [Permit](/category/permit/) ERC-8196 is a Final Ethereum standard for wallets that an AI agent can use but not abuse [[1]](#ref-1). The asset owner registers a policy on an ERC-4337 smart account, and the wallet executes an agent's transaction only when it comes with cryptographic proof that the action complies with that policy [[1]](#ref-1). Every session is logged in a hash-chained audit trail. A commit-reveal of entropy stops a host from steering a probabilistic agent by resampling, and credentials for legacy (non-chain) services can be delegated through TLS attestations without handing the agent private keys [[1]](#ref-1). ## Overview It is the execute layer of a two-layer stack by the same authors: ERC-8126 answers whether an agent is trustworthy, ERC-8196 whether this action is authorised now, and the spec encourages ERC-8126 Wallet Verification before granting control [[1]](#ref-1). It reached Final on 2026-07-21 [[2]](#ref-2). The dependency chain runs through ERC-8126 to ERC-8004, which is still a Draft (see the dispute on erc-8126). No deployed wallet implementing ERC-8196 was found in this pass, so implementation is unknown and adoption unmeasured. ## Discovery and probe EVM smart-contract interface on an ERC-4337 account; policies are registered on the wallet contract · none — no well-known file; discovery is by contract address/ABI ``` eth_call {contract_address} parse: Contract implements the ERC-8196 functions (registerPolicy, getPolicy, revokePolicy, executeAction) on absent: Absence at a given contract address only shows that wallet does not implement ERC-8196; there is no registry of ERC-8196 wallets to enumerate. ``` Not probed live: not-http. An Ethereum contract; observable via eth_call, not HTTP. ## History - 2026-10-20 — added from gap scout 2026-10-20; verified against eips.ethereum.org/EIPS/eip-8196 and the ERCs repository file and commit history (Final 2026-07-21) ## Instances Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Builds on: [ERC-8126: AI Agent Verification](/protocols/erc-8126/) - Pairs with: [ERC-8126: AI Agent Verification](/protocols/erc-8126/), [ERC-8004: Trustless Agents](/protocols/erc-8004/) ## Comparisons - [ERC-8226 Regulated Agent Mandate vs ERC-8196: AI Agent Authenticated Wallet](/compare/erc-8226-vs-erc-8196/) ## References - ERC-8196 defines a standard interface for AI agent-authenticated wallets that execute transactions only with verifiable cryptographic proof that the action complies with a policy set by the asset owner. It is Layer 2 (Execute) above ERC-8126 (Layer 1, Identify and Verify), with credential delegation without exposing private keys, a hash-chained audit trail, entropy commit-reveal against host influence, and legacy credential delegation via TLS attestations. Status Final; requires 155, 191, 712, 4337 and 8126; created 2026-03-14. — [https://eips.ethereum.org/EIPS/eip-8196](https://eips.ethereum.org/EIPS/eip-8196) (2026-07-21) VERIFIED - The ERCs repository front matter for erc-8196.md reads status: Final; its commit history shows the move to Final on 2026-07-21. — [https://github.com/ethereum/ERCs/blob/master/ERCS/erc-8196.md](https://github.com/ethereum/ERCs/blob/master/ERCS/erc-8196.md) (2026-07-21) VERIFIED [JSON](/data/protocols/erc-8196.json) · [Markdown](/protocols/erc-8196/index.md) · [OKF v0.2](/okf/protocols/erc-8196.md) --- # ERC-8226 Regulated Agent Mandate ERC-8226 Regulated Agent Mandate is an agentic-web standard (on-chain registry) at step 3, Permit, governed by Ethereum ERC process; its status is "Draft, Standards Track: ERC". It answers: "What scoped, time-bounded, and financially capped authority may an on-chain agent exercise on a regulated asset holder's…?" Replacing or extending Power of attorney, implementation status is prototype, last verified 2026-10-23. ## Quick Wire Reference - **Step**: 3 Permit (What may the agent do here?) - **Version**: Draft, created 2026-04-12 (2026-04-12) - **Status**: Draft, Standards Track: ERC (marked ⚠️ Draft on eips.ethereum.org) · prototype - **Discovery / Probe Path**: EVM contract interface detection (ERC-165 supportsInterface for IAgentMandate) - **Spec URL**: https://eips.ethereum.org/EIPS/eip-8226 - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: Power of attorney [Permit](/category/permit/) ERC-8226, also called the Regulated Agent Mandate Standard (RAMS), is a Draft Ethereum Request for Comments that defines a compliance-delegation layer for AI agents acting on tokenized regulated assets such as securities or fund units [[1]](#ref-1). It answers the permit question for on-chain agents: what scoped, time-bounded, financially capped authority has a KYC-cleared principal granted an agent, and how does a regulated token contract check that authority before letting the agent's call through. ## Overview The spec defines two Solidity interfaces: IAgentMandate, a registry keyed by (agent, principal) pairs that exposes canExecute for pre-flight checks and recordExecution for logging use, and IComplianceProvider, which lets a token-compliance framework plug in. Mandates cap a transferred quantity (token amount for ERC-20/ERC-1155, count for ERC-721) per asset address, can be time-limited, and can be frozen (halted but not revoked) by an authorized enforcer while only the principal can revoke outright. RAMS is explicitly agnostic to the agent-identity standard used (it names ERC-8004 as a compatible example), the token standard (ERC-20/721/1155), and the regulated-token compliance framework (it names ERC-7943 and ERC-3643) [[1]](#ref-1). It does not itself provide agent identity, KYC verification, or token-transfer-eligibility logic; those are left to the named companion standards. It does not define an off-chain permission surface (no well-known file or HTTP header) — the entire mechanism is on-chain, discoverable only by probing whether a given regulated-token deployment has wired an IAgentMandate-conformant registry into its transfer checks. As of this verification (2026-09-06) the proposal is Draft status, created 2026-04-12 by four authors affiliated with Brickken, a tokenized real-world-asset platform, with an open Ethereum Magicians discussion thread and a merged pull request into the community ethereum/ERCs repository dated 2026-05-12 [[1]](#ref-1)[[2]](#ref-2). A reference implementation and test suite (IAgentMandate registry, IComplianceProvider, an optional IAgentExecutor forwarding interface, a RamsGated base contract, and an ERC-7943 asset that inherits it) ship alongside the spec text, but this is the proposers' own reference code, not an independent production deployment [[1]](#ref-1). What is unresolved: no independent implementer, regulated-asset platform, or agent-identity project has been found describing production use of RAMS; adoption is unmeasured. It is unclear whether RAMS will progress through EIP editor review toward Final status, whether it will compete with or be folded into ERC-8004's agent-identity ecosystem, and whether real KYC/regulatory infrastructure will treat an on-chain mandate as legally sufficient without off-chain paperwork. ## Discovery and probe EVM contract interface detection (ERC-165 supportsInterface for IAgentMandate) ``` ETH_CALL {contract}.canExecute(agent, principal, asset, action, amount) via eth_call against IAgentMandate parse: Call reverts with false/error if no active mandate exists; a successful bool return with mandate data proves an IAgentMandate registry is deployed at {contract} on absent: No IAgentMandate registry is deployed at the address; the asset contract carries no RAMS-conformant delegation layer ``` Not probed live: not-http. An Ethereum contract; observable via eth_call, not HTTP. ## History - 2026-09-05 — seeded from Exa Agent research run - 2026-09-06 — verified against eips.ethereum.org/EIPS/eip-8226 and github.com/ethereum/ERCs/pull/1844 - 2026-10-16 — use-case tags (auto) ## Instances - [Brickken RAMS (ERC-8226 RWA Agent Mandate Authority)](https://eips.ethereum.org/EIPS/eip-8226) · Observed 2026-07-17 · authority Every instance with its source is listed on the [instances page](/instances/). Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Builds on: [ERC-8004: Trustless Agents](/protocols/erc-8004/) - Pairs with: [ERC-8004: Trustless Agents](/protocols/erc-8004/), [ERC-8183: Agentic Commerce](/protocols/erc-8183/), [Agent Payments Protocol](/protocols/ap2/) - [Agentic EoR (Employer / Entity of Record)](/terms/agentic-eor/) ## Comparisons - [ERC-8226 Regulated Agent Mandate vs ERC-8196: AI Agent Authenticated Wallet](/compare/erc-8226-vs-erc-8196/) ## References - The canonical spec text (abstract, motivation, IAgentMandate/IComplianceProvider interfaces, reference implementation) is published on eips.ethereum.org, status Draft, created 2026-04-12. — [https://eips.ethereum.org/EIPS/eip-8226](https://eips.ethereum.org/EIPS/eip-8226) (2026-04-12) VERIFIED - The EIP's discussion thread and originating pull request on the ethereum/ERCs repo record the proposal's provenance and author affiliation with Brickken. — [https://github.com/ethereum/ERCs/pull/1844](https://github.com/ethereum/ERCs/pull/1844) (2026-05-12) REPORTED [JSON](/data/protocols/erc-8226.json) · [Markdown](/protocols/erc-8226/index.md) · [OKF v0.2](/okf/protocols/erc-8226.md) --- # ERC-8444: Agentic Resource Discovery (ARD) Onchain (/.well-known/ard.json) ERC-8444: Agentic Resource Discovery (ARD) Onchain is an agentic-web standard (on-chain registry — /.well-known/ard.json) at step 1, Discover, governed by Ethereum EIP/ERC process; its status is "Draft Standards Track ERC, created 2026-10-12". It answers: "How can on-chain skills, task bounties and agent identities be found through ordinary ARD search, without the searcher…?" Implementation status is prototype, last verified 2026-10-23. ## Quick Wire Reference - **Step**: 1 Discover (What is here, and where?) - **Version**: Draft, created 2026-10-12 (2026-10-12) - **Status**: Draft Standards Track ERC, created 2026-10-12 · prototype - **Discovery / Probe Path**: /.well-known/ard.json — On-chain registry of value records, served by gateways that are… - **Spec URL**: https://eips.ethereum.org/EIPS/eip-8444 - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: A search-engine listing backed by a land registry: the listing is ordinary, the… [Discover](/category/discover/) ERC-8444 puts ARD (Agentic Resource Discovery) on Ethereum [[1]](#ref-1). ARD answers what exists and who says so, rooted in domains; this draft adds the other half, what a resource is worth and how it settles, rooted in addresses [[1]](#ref-1). It defines an on-chain registry of value records. Each record is a valid ARD v0.91 entry bound to an on-chain anchor: a token-bound skill, a token-bound task tender with an escrowed bounty, an address-anchored agent identity (which can point to an ERC-8004 registration file), or an ARD registry endpoint [[1]](#ref-1)[[2]](#ref-2). ## Overview The bridge to the web is two-way. Gateways that serve these records must be conformant ARD registries, so ordinary ARD clients find on-chain offers with no wallet or RPC endpoint [[1]](#ref-1). A domain endorses an address by listing it under value:controllers (or an entry's value:controller) in its own /.well-known/ard.json, which plain ARD registries ignore [[1]](#ref-1). Authority always sits with the address, never the domain, and records are identified by anchor, with ARD URNs as aliases [[1]](#ref-1). Tenders add a new direction to ARD: an entry whose reader is a supplier looking for work [[1]](#ref-1). Current state: a Draft created 2026-10-12 by a single author, with reference contracts and test vectors in the ERCs repository [[2]](#ref-2). It is not part of the ARD specification itself, and no deployment was found. ## Discovery and probe On-chain registry of value records, served by gateways that are conformant ARD registries; a domain acknowledges an address in its own ARD manifest through a top-level value:controllers member or an entry's value:controller · /.well-known/ard.json ``` GET https://{origin}/.well-known/ard.json parse: ARD manifest with a top-level value:controllers array (did:pkh identifiers) or entries carrying value:controller; a gateway's manifest must also list at least one application/ai-registry+json entry describing itself on absent: The domain has not acknowledged any ERC-8444 controller address; its ordinary ARD entries remain valid, and per the ERC every existing ARD entry is already a dormant (level 0) value record ``` Live check run by [the MCP probe](/mcp/server-card): GET /.well-known/ard.json. A domain acknowledges an ERC-8444 controller address with value:controllers or value:controller in its ARD manifest. ``` { "path": "/.well-known/ard.json", "expect": { "text_match": "\"value:controllers?\"" }, "note": "A domain acknowledges an ERC-8444 controller address with value:controllers or value:controller in its ARD manifest." } ``` ## History - 2026-10-20 — added from gap scout 2026-10-20; verified against eips.ethereum.org/EIPS/eip-8444 and the ERCs repository file erc-8444.md (Draft, 2026-10-12) ## Instances Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Builds on: [Agentic Resource Discovery](/protocols/ard/) - Pairs with: [Agentic Resource Discovery](/protocols/ard/), [ERC-8004: Trustless Agents](/protocols/erc-8004/), [x402](/protocols/x402/) ## Comparisons - [Agentic Resource Discovery vs ERC-8444: Agentic Resource Discovery (ARD) Onchain](/compare/ard-vs-erc-8444/) ## References - ERC-8444 defines an on-chain registry of value records for agentic resources: each record binds an ARD entry to an on-chain anchor (a token-bound executable skill, a token-bound task tender, an address-anchored agent identity, or an ARD registry endpoint) and, via a kind adapter, to the controlling address. Every record is a valid ARD entry and every resolver that serves records is a conformant ARD registry; a domain acknowledges an address in /.well-known/ard.json via value:controllers or value:controller. Status Draft; requires 165, 712 and 1271; created 2026-10-12; author Gary Yang (finchip). — [https://eips.ethereum.org/EIPS/eip-8444](https://eips.ethereum.org/EIPS/eip-8444) (2026-10-12) VERIFIED - The ERCs repository file erc-8444.md reads status: Draft and lists reference assets: an ARDOnchainRegistry.sol kernel, four kind adapters (skill, task, agent, registry), example descriptors, a gateway manifest and test vectors, and vendors the ARD v0.91 entry schema. — [https://github.com/ethereum/ERCs/blob/master/ERCS/erc-8444.md](https://github.com/ethereum/ERCs/blob/master/ERCS/erc-8444.md) (2026-10-12) VERIFIED [JSON](/data/protocols/erc-8444.json) · [Markdown](/protocols/erc-8444/index.md) · [OKF v0.2](/okf/protocols/erc-8444.md) --- # GB/Z 185 Artificial intelligence — Agent interconnection (人工智能 智能体互联) GB/Z 185 Artificial intelligence — Agent interconnection (人工智能 智能体互联) is an agentic-web standard (document format) at step 6, Coordinate, governed by Chinese national standardization guidance technical document…; its status is "国家标准 指导性技术文件, status 现行, published 2026-05-22". It answers: "How do AI agents built by different Chinese companies identify, describe, find and call each other, and invoke tools…?" Implementation status is prototype (SAMR press conference 2026-06-26), last verified 2026-10-23. ## Quick Wire Reference - **Step**: 6 Coordinate (Talk to another agent) - **Version**: GB/Z 185.1–185.7-2026 (national standardization guidance technical document)… - **Status**: 国家标准 指导性技术文件 (GB/Z, national standardization guidance technical document)… - **Discovery / Probe Path**: Part 5 of the series covers agent discovery; its full text was not read for this record, so… - **Spec URL**: https://openstd.samr.gov.cn/bzgk/gb/newGbInfo?hcno=CFF03D872963466AC7F03ED0E28B6702 - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: A national interconnection standard, like the rules that let different carriers'… [Coordinate](/category/coordinate/) GB/Z 185 is China's seven-part national guidance standard for interconnecting AI agents. The parts cover general architecture, agent identity codes, identity management, agent description, discovery, interaction and tool invocation [[1]](#ref-1)[[2]](#ref-2)[[4]](#ref-4). It is a GB/Z document, a national standardization guidance technical document: in force since 2026-05-22, but guidance-grade rather than mandatory [[1]](#ref-1). ## Overview The series sits under technical committee TC28 and its AI subcommittee TC28/SC42. CESI led the drafting. The Part 1 record lists 37 drafting units, among them BUPT, Xiaomi, Huawei, Ant Group, China Mobile, Alibaba Cloud, ByteDance (Volcano Engine), ZTE, Lenovo and CNNIC [[1]](#ref-1). The full text of Part 1 is free to read and download from SAMR's openstd site [[3]](#ref-3). The regulator says 70+ organisations drafted it, 100+ firms have joined the initiative and 50+ pilots are running [[4]](#ref-4). Those are the regulator's figures, not counts this site has checked. An open-source companion, the Agent Interconnection Protocol (AIP), was first released on 2025-10-27 by BUPT and CESI, and its project says it conforms to the series [[5]](#ref-5). That AIP is a different thing from the Agent Identity Protocol drafts this site tracks under the same initialism. What is open: this record has not yet been checked against the full text of Part 5 (discovery), so it does not say whether the series defines a well-known path or registry an agent could probe. ## Discovery and probe Part 5 of the series covers agent discovery; its full text was not read for this record, so no fixed path is asserted ``` GET none — no origin path confirmed parse: No probe rule yet. Reading Part 5 (discovery) is needed to learn whether the series defines a well-known path or registry endpoint. on absent: Not probeable from an origin until Part 5 is read; absence says nothing about adoption. ``` Not probed live: no-fixed-path. probe rule pending: Part 5 (discovery) full text not yet read for a well-known path ## History - 2026-10-20 — added from gap scout 2026-10-20; verified against the SAMR standards records for Parts 1 and 7, the openstd full-text entry, the SAMR press conference of 2026-06-26 and the AIP project news page ## Instances Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Pairs with: [Agent2Agent Protocol](/protocols/a2a/), [Agent Network Protocol](/protocols/anp/), [Agent Directory Service](/protocols/ads/), [Model Context Protocol](/protocols/mcp/) - Not to be confused with: AIP: the open-source Agent Interconnection Protocol (OpenAtom) that accompanies this series is unrelated to the Agent Identity Protocol drafts tracked as aip and aip-delegation-chain ## References - The SAMR national standards record for GB/Z 185.1-2026 '人工智能 智能体互联 第1部分：总体架构 / Artificial intelligence—Agent interconnection—Part 1: General architecture' shows a GB/Z guidance technical document, status 现行 (in force), published 2026-05-22, technical committee TC28 executed by TC28/SC42, with 37 drafting units led by CESI and including BUPT, Xiaomi, Huawei, Ant Group, China Mobile, Alibaba Cloud, ByteDance (Volcano Engine), ZTE, Lenovo and CNNIC. — [https://std.samr.gov.cn/gb/search/gbDetailed?id=52A05F8113453761E06397BE0A0AFEB5](https://std.samr.gov.cn/gb/search/gbDetailed?id=52A05F8113453761E06397BE0A0AFEB5) (2026-05-22) VERIFIED - The SAMR record for GB/Z 185.7-2026 'Part 7: Agent tool invocation' carries the same publication date and technical committee. — [https://std.samr.gov.cn/gb/search/gbDetailed?id=52A05F8113493761E06397BE0A0AFEB5](https://std.samr.gov.cn/gb/search/gbDetailed?id=52A05F8113493761E06397BE0A0AFEB5) (2026-05-22) VERIFIED - The openstd.samr.gov.cn entry for Part 1 offers the full text free of charge (online preview and download). — [https://openstd.samr.gov.cn/bzgk/gb/newGbInfo?hcno=CFF03D872963466AC7F03ED0E28B6702](https://openstd.samr.gov.cn/bzgk/gb/newGbInfo?hcno=CFF03D872963466AC7F03ED0E28B6702) (2026-05-22) VERIFIED - At a SAMR press conference on 2026-06-26, the regulator described a series of seven national standards covering architecture, identity code, identity management, description, discovery, interaction and tool invocation, drafted under CESI's lead with 70+ organisations and 600+ comments; it said 100+ firms had joined the initiative and 50+ pilots were under way, and named the Agent Interconnection Protocol (AIP), whose open-source development BUPT helps lead. The page does not cite the number GB/Z 185. — [https://www.samr.gov.cn/xw/xwfbt/art/2026/art_fa730f984b2740baa248318118d77921.html](https://www.samr.gov.cn/xw/xwfbt/art/2026/art_fa730f984b2740baa248318118d77921.html) (2026-06-26) VERIFIED - The AIP project news page (2025-11-01) reports the first open-source AIP code release on 2025-10-27 by BUPT and CESI, and says AIP conforms to the TC28/SC42 agent interconnection series without naming GB/Z 185. — [https://aip.openatom.tech/explore/journalism/detail/507545311238033408](https://aip.openatom.tech/explore/journalism/detail/507545311238033408) (2025-11-01) VERIFIED [JSON](/data/protocols/gbz-185-agent-interconnection.json) · [Markdown](/protocols/gbz-185-agent-interconnection/index.md) · [OKF v0.2](/okf/protocols/gbz-185-agent-interconnection.md) --- # High-Assurance Agent Control Envelope (HAACE) High-Assurance Agent Control Envelope (HAACE) is an agentic-web standard (document format) at step 3, Permit, governed by Individual Internet-Draft by a single author, submitted to the…; its status is "Internet-Draft, Intended Status: Informational". It answers: "How can a relying party gate an exact agent action at execution time so that missing, stale, or indeterminate identity…?" Implementation status is none found, last verified 2026-10-23. ## Quick Wire Reference - **Step**: 3 Permit (What may the agent do here?) - **Version**: draft-watts-high-assurance-agent-control-envelope-00 (2026-10-14) - **Status**: Internet-Draft, Intended Status: Informational; expires 17 April 2027 · none… - **Discovery / Probe Path**: No discovery mechanism defined; the relying party declares an Assurance Requirement Profile… - **Spec URL**: https://datatracker.ietf.org/doc/html/draft-watts-high-assurance-agent-control-envelope-00 - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: A pre-flight checklist with a separate sign-off and a logbook entry: authorization… [Permit](/category/permit/) HAACE is an individual Internet-Draft (Informational) defining a protocol-neutral execution-gate profile for agent actions. A relying party declares an Assurance Requirement Profile; an Action Control Point evaluates an Action Request Record and emits a non-bearer Action Decision Receipt, followed by a separate Action Execution Receipt if an effect is attempted. Missing or indeterminate required premises must not produce ALLOW. It composes with OAuth, workload identity, attestation and transparency mechanisms rather than replacing them. ## Discovery and probe No discovery mechanism defined; the relying party declares an Assurance Requirement Profile (ARP) out of band ``` NONE parse: on absent: Support cannot be observed externally; HAACE is an internal action-time enforcement profile with no public endpoint. ``` Not probed live: no-fixed-path. candidate record; probe rule pending ## History - 2026-10-19 — auto-drafted candidate from exa (https://datatracker.ietf.org/doc/html/draft-watts-high-assurance-agent-control-envelope-00) ## Instances Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also ## References - The Internet-Draft defines HAACE, a protocol-neutral profile binding an exact agent action to identity status, authorization state, policy, assurance stage, evidence state, authority epoch, revocation state and oversight requirements, with fail-closed handling and non-bearer decision and execution receipts. — [https://datatracker.ietf.org/doc/html/draft-watts-high-assurance-agent-control-envelope-00](https://datatracker.ietf.org/doc/html/draft-watts-high-assurance-agent-control-envelope-00) (2026-10-14) REPORTED [JSON](/data/protocols/haace.json) · [Markdown](/protocols/haace/index.md) · [OKF v0.2](/okf/protocols/haace.md) --- # HTTP Message Signatures (RFC 9421) HTTP Message Signatures is an agentic-web standard (HTTP header — RFC 9421) at step 2, Identify, governed by IETF; its status is "Proposed Standard". It answers: "How can HTTP messages carry end-to-end component integrity and proof of possession, independent of transport-layer security?" Replacing or extending JWS for HTTP components, implementation status is multi-implementation (Multiple libraries and at least one profile in…), last verified 2026-10-23. ## Quick Wire Reference - **Step**: 2 Identify (Who is this agent? Who is this site?) - **Version**: RFC 9421, February 2024, Proposed Standard (2024-02) - **Status**: Proposed Standard · multi-implementation - **Discovery / Probe Path**: none — Signature and Signature-Input HTTP fields carried directly on the… - **Spec URL**: https://www.rfc-editor.org/info/rfc9421 - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: JWS for HTTP components [Identify](/category/identify/) RFC 9421 (HTTP Message Signatures) is a general-purpose IETF Proposed Standard, not specific to agents. It defines how to create, encode and verify digital signatures or message authentication codes over selected components of an HTTP message (headers, derived components like @authority or @method, and optionally the body), so that a signature survives intermediaries that might otherwise alter or drop parts of the message [[1]](#ref-1). It also defines how to request that a future message in an ongoing exchange be signed [[1]](#ref-1). ## Overview It solves message-level integrity and proof-of-possession for HTTP independent of transport security (TLS terminates at intermediaries; RFC 9421 signatures do not) [[1]](#ref-1). It does not define identity discovery, key distribution, or any notion of "bot" or "agent" — those are added by profiles built on top of it. In this map, it is the base standard that Web Bot Auth (see the webbotauth record) profiles: Web Bot Auth adds the Signature-Agent header as a signed component and defines a specific key-discovery mechanism (a well-known JWKS directory), while RFC 9421 itself stays agnostic to what a signature proves or where keys come from [[2]](#ref-2). Current state: published as a Proposed Standard in February 2024 and stable since; it is not itself under active revision as far as this check found. Who implements it: general HTTP signing libraries exist across languages (this check did not re-survey the full ecosystem); its most visible agent-relevant use is as the substrate for Web Bot Auth, which Cloudflare verifies at the edge [[2]](#ref-2). Disputed or unknown: none specific to the base standard found in this pass. Because RFC 9421 is general and widely referenced, this record exists mainly to anchor the agent-specific profiles (Web Bot Auth, and potentially others) that depend on it; it should not be read as agent-specific adoption evidence on its own. ## Discovery and probe Signature and Signature-Input HTTP fields carried directly on the message; no fixed discovery path of its own · none ``` GET n/a — inspect response/request headers on any HTTP exchange parse: Presence of Signature and Signature-Input HTTP fields (or their Content-Digest/Signature-related trailers) conforming to RFC 9421's structured-field syntax on absent: The message carries no RFC 9421 signature; any profile built on it (e.g. Web Bot Auth) cannot be verified ``` Not probed live: no-fixed-path. Signatures appear on individual messages; the webbotauth directory rule covers the published key side. ## History - 2026-09-05 — seeded from Exa Agent research run - 2026-09-06 — verified against RFC 9421 primary source and confirmed as the base standard profiled by Web Bot Auth - 2026-10-16 — use-case tags (auto) ## Instances Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Depended on by: [AAuth (Hardt)](/protocols/aauth-hardt/), [Ad Context Protocol](/protocols/adcp/), [Agent Identity and Discovery](/protocols/aid/), [Agent Network Protocol](/protocols/anp/), [Attenuated Delegation Profile for Automated Agents](/protocols/oauth-agent-delegation/), [Cloudflare Pay per crawl](/protocols/cloudflare-pay-per-crawl/), [Signature Agent Card (Web Bot Auth registry)](/protocols/web-bot-auth-signature-agent-card/), [Visa Trusted Agent Protocol](/protocols/tap/), [Web Bot Auth HTTP Message Signatures](/protocols/webbotauth/), [WIMSE AI Identity Management System](/protocols/wimse-aims/) - Pairs with: [Web Bot Auth HTTP Message Signatures](/protocols/webbotauth/), [Signature Agent Card (Web Bot Auth registry)](/protocols/web-bot-auth-signature-agent-card/), [Visa Trusted Agent Protocol](/protocols/tap/), [x402](/protocols/x402/), [Agent Identity and Discovery](/protocols/aid/), [Ad Context Protocol](/protocols/adcp/) - [Web Bot Auth HTTP Message Signatures](/protocols/webbotauth/) - [Signature Agent Card (Web Bot Auth registry)](/protocols/web-bot-auth-signature-agent-card/) - [HTTP Message Signatures](/terms/rfc-9421/) - [Signed agent](/terms/signed-agent/) - [Web Bot Auth](/terms/web-bot-auth/) - Scanners & registries: [Cloudflare Web Bot Auth documentation](https://developers.cloudflare.com/bots/reference/bot-verification/web-bot-auth/) ## Comparisons - [User-Agent & IP Allowlists vs Web Bot Auth (RFC 9421) (classic vs agentic)](/compare/user-agent-vs-web-bot-auth/) - [Web Bot Auth HTTP Message Signatures vs HTTP Message Signatures](/compare/webbotauth-vs-http-message-signatures/) - [HTTP Message Signatures vs Signature Agent Card (Web Bot Auth registry)](/compare/http-message-signatures-vs-web-bot-auth-signature-agent-card/) ## References - RFC 9421 is a Proposed Standard published by the IETF (2024) defining a mechanism for creating, encoding and verifying signatures over HTTP message components, including a means to request that a signature be applied to a subsequent message — [https://www.rfc-editor.org/info/rfc9421](https://www.rfc-editor.org/info/rfc9421) (2024-02) VERIFIED - Web Bot Auth's protocol draft explicitly builds its Agent/Origin signature exchange on top of RFC 9421's Signature and Signature-Input fields, adding the Signature-Agent field as an RFC 9421 signature component — [https://datatracker.ietf.org/doc/html/draft-meunier-webbotauth-httpsig-protocol-00](https://datatracker.ietf.org/doc/html/draft-meunier-webbotauth-httpsig-protocol-00) (2026-06-26) VERIFIED [JSON](/data/protocols/http-message-signatures.json) · [Markdown](/protocols/http-message-signatures/index.md) · [OKF v0.2](/okf/protocols/http-message-signatures.md) --- # ID MANDAT: A Machine-Readable Credential for the Agents of a Company (/.well-known/idmandat.json) ID MANDAT: A Machine-Readable Credential for the Agents of a Company is an agentic-web standard (well-known file — /.well-known/idmandat.json) at step 2, Identify, governed by Individual Internet-Draft, not an IETF working group product; its status is "Internet-Draft, Intended Status: Informational". It answers: "How can a recipient find out which company stands behind an agent and what that agent is declared to be allowed and not…?" Implementation status is prototype, last verified 2026-10-23. ## Quick Wire Reference - **Step**: 2 Identify (Who is this agent? Who is this site?) - **Version**: draft-koenig-idmandat-credential-00 (2026-10-16) - **Status**: Internet-Draft, Intended Status: Informational; individual submission… - **Discovery / Probe Path**: /.well-known/idmandat.json - **Spec URL**: https://datatracker.ietf.org/doc/html/draft-koenig-idmandat-credential-00 - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: An imprint page for agents, with a DNS TXT proof record and a signed registry lookup [Identify](/category/identify/) Describes a JSON credential file a company publishes at /.well-known/idmandat.json, naming the company and its agents with per-agent 'may' and 'mayNot' mandates. A DNS TXT record at _idmandat. ties the file to the domain. A public registry checks both and returns Ed25519-signed answers with check levels and revocation states. The agent details are operator declarations and not verified by the registry. It complements Web Bot Auth, which proves key possession but not who operates the agent. ## Discovery and probe well-known file at /.well-known/idmandat.json, linked to the domain by a DNS TXT record at _idmandat. · /.well-known/idmandat.json ``` GET /.well-known/idmandat.json parse: Parse JSON; check that 'domain' equals the fetched host and that 'agents' is present; optionally resolve the TXT record _idmandat. for 'v=idmandat1' on absent: Treat as no declaration; absence is not evidence against the agent ``` Not probed live: no-fixed-path. candidate record; probe rule pending ## History - 2026-10-19 — auto-drafted candidate from exa (https://datatracker.ietf.org/doc/html/draft-koenig-idmandat-credential-00) ## Instances Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Builds on: [Web Bot Auth HTTP Message Signatures](/protocols/webbotauth/) - Pairs with: [Web Bot Auth HTTP Message Signatures](/protocols/webbotauth/), [HTTP Message Signatures](/protocols/http-message-signatures/), [Agent2Agent Protocol](/protocols/a2a/), [Model Context Protocol](/protocols/mcp/) ## References - Internet-Draft defining a credential file at /.well-known/idmandat.json, a DNS TXT proof record at _idmandat, and a signed Ed25519 registry lookup answer format; described as a deployed beta (version 0.3). — [https://datatracker.ietf.org/doc/html/draft-koenig-idmandat-credential-00](https://datatracker.ietf.org/doc/html/draft-koenig-idmandat-credential-00) (2026-10-16) REPORTED [JSON](/data/protocols/idmandat-credential.json) · [Markdown](/protocols/idmandat-credential/index.md) · [OKF v0.2](/okf/protocols/idmandat-credential.md) --- # Identity Assertion JWT Authorization Grant (ID-JAG · /.well-known/oauth-authorization-server) Identity Assertion JWT Authorization Grant (ID-JAG) is an agentic-web standard (endpoint — /.well-known/oauth-authorization-server) at step 3, Permit, governed by IETF OAuth Working Group; its status is "Active Internet-Draft, WG Document". It answers: "How can an app or AI agent, already SSO-federated to a user's enterprise identity provider, obtain scoped access to a…?" Implementation status is multi-implementation (observed on 6/1226 probed origins), last verified 2026-10-23. ## Quick Wire Reference - **Step**: 3 Permit (What may the agent do here?) - **Version**: draft-ietf-oauth-identity-assertion-authz-grant-04 (replaces the individual… - **Status**: Active Internet-Draft, WG Document (oauth WG); Intended status: Standards… - **Discovery / Probe Path**: /.well-known/oauth-authorization-server — No dedicated well-known file; advertised via OAuth… - **Spec URL**: https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/ - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: Kerberos constrained delegation, extended to OAuth-federated SaaS: reuse the IdP's… [Permit](/category/permit/) The Identity Assertion JWT Authorization Grant (ID-JAG) is an IETF OAuth Working Group Internet-Draft that lets an application already federated to a user's enterprise identity provider (IdP) via SSO obtain a scoped access token for a different, third-party resource server, without that resource server re-prompting the user for consent [[1]](#ref-1). It is marketed by its lead editor's employer, Okta, under the informal name Cross-App Access (XAA); XAA and ID-JAG name the same specification, and 'Cross App Access' / 'XAA' are recorded here as aliases rather than a separate protocol [[1]](#ref-1)[[3]](#ref-3). ## Overview Mechanically, a client exchanges an identity assertion (an OpenID Connect ID Token or SAML assertion, or a previously issued refresh token) at the user's IdP Authorization Server for an ID-JAG, using OAuth 2.0 Token Exchange (RFC 8693); it then redeems that ID-JAG at the target Resource Authorization Server for an ordinary OAuth access token, using the JWT Profile for OAuth 2.0 Authorization Grants (RFC 7523) [[1]](#ref-1)[[3]](#ref-3). The Resource Authorization Server still applies its own local policy and can narrow or reject the request; the IdP is not granting access on the resource server's behalf, only vouching for identity and carrying the delegation. It solves the specific 'permit' problem of API/MCP-server access for enterprise-managed applications and AI agents: it lets IT admins centrally govern which agents can reach which downstream tools through the IdP they already trust, instead of every end user individually consenting per app [[4]](#ref-4). It does not solve general internet-scale agent authorization the way AAuth, DAAP, and AAP (also in this dataset, also unadopted or expired individual OAuth-for-agents drafts) attempt to; ID-JAG assumes a pre-existing enterprise SSO/federation relationship between the two Authorization Servers and is not designed for an agent approaching an arbitrary, unfederated origin. It also relies on, rather than replaces, the RFC 8414/RFC 9728 Authorization Server and Protected Resource Metadata discovery layer already recorded in this dataset as oauth-metadata-for-agents; ID-JAG adds new metadata properties (authorization_grant_profiles_supported, identity_chaining_requested_token_types_supported) on top of that base rather than defining new well-known files. Current state (2026-09-07): the WG document is at revision -04, last updated 2026-05-21, succeeding the individual submission draft-parecki-oauth-identity-assertion-authz-grant first published 2024-03; it is an Active Internet-Draft, not yet an RFC, with Intended RFC status left blank on the Datatracker's status table despite the document text's own Standards Track heading [[1]](#ref-1). Unlike AAuth and AAP, this draft is not expired and has active WG-track momentum. Who implements it: Okta and Auth0 (an Okta-owned brand) both ship production guides and configuration support for both the Requesting-App and Resource-App roles [[4]](#ref-4)[[5]](#ref-5); Descope announced its own, independently built ID-JAG issuance and validation support on 2026-09-01 [[6]](#ref-6); Okta also operates xaa.dev, a public sandbox that runs a live reference flow against RFC 8693/7523/6750 [[3]](#ref-3). No standalone client-side SDK package for ID-JAG specifically was found in this pass; implementers so far build it directly into their own IdP/Authorization-Server platforms or use their existing OAuth/OIDC libraries. What is unresolved: how many production API/MCP-server operators beyond these three identity-platform vendors and their direct customers have deployed ID-JAG; whether the spec will reach RFC status before its current expiry; and how ID-JAG's enterprise-SSO-scoped delegation model will be reconciled, if at all, with the broader, non-federated agent-authorization ambitions of AAuth, DAAP, and AAP. ## Discovery and probe No dedicated well-known file; advertised via OAuth 2.0 Authorization Server Metadata (RFC 8414) / OpenID Connect Discovery. The IdP Authorization Server lists grant_types_supported including urn:ietf:params:oauth:grant-type:token-exchange and identity_chaining_requested_token_types_supported including urn:ietf:params:oauth:token-type:id-jag; the Resource Authorization Server lists authorization_grant_profiles_supported including urn:ietf:params:oauth:grant-profile:id-jag and grant_types_supported including urn:ietf:params:oauth:grant-type:jwt-bearer · /.well-known/oauth-authorization-server or /.well-known/openid-configuration ``` GET https://{resource_authorization_server}/.well-known/oauth-authorization-server parse: RFC 8414 JSON metadata document; presence of "urn:ietf:params:oauth:grant-profile:id-jag" in authorization_grant_profiles_supported (and "urn:ietf:params:oauth:grant-type:jwt-bearer" in grant_types_supported, which this profile requires alongside it) indicates the Resource Authorization Server implements the Identity Assertion JWT Authorization Grant / Cross-App Access profile on absent: The Resource Authorization Server does not advertise support for ID-JAG/XAA; an app cannot obtain access to this API via identity-assertion cross-app access without out-of-band, vendor-specific configuration. Absence is not conclusive proof of non-support, since the spec allows a server to omit the discovery signal and instead disclose acceptance only via a protected, per-client mechanism ``` Live check run by [the MCP probe](/mcp/server-card): GET /.well-known/oauth-authorization-server. draft-ietf-oauth-identity-assertion-authz-grant advertises the id-jag profile in authorization server metadata; the key alone shows the server publishes grant profiles, so check for urn:ietf:params:oauth:grant-profile:id-jag in the value. ``` { "path": "/.well-known/oauth-authorization-server", "expect": { "json_keys": [ "authorization_grant_profiles_supported" ] }, "note": "draft-ietf-oauth-identity-assertion-authz-grant advertises the id-jag profile in authorization server metadata; the key alone shows the server publishes grant profiles, so check for urn:ietf:params:oauth:grant-profile:id-jag in the value." } ``` ## History - 2026-09-07 — created and verified against datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/ (rev -04, 2026-05-21), xaa.dev, and vendor implementation announcements from Okta, Auth0 and Descope - 2026-10-16 — use-case tags (auto) - 2026-10-23 — draft-ietf-oauth-identity-assertion-authz-grant-04 expires on 2026-11-22 ## Instances - [Zuplo API Gateway (zuplo.com)](https://zuplo.com/) · Observed 2026-10-25 · origin - [Lovable AI Full-Stack Builder (lovable.dev)](https://lovable.dev/) · Observed 2026-10-25 · origin - [Figma (figma.com)](https://figma.com/) · Observed 2026-10-23 · origin - [Okta and Auth0 Cross App Access (XAA)](https://auth0.com) · Observed 2026-08-29 · authority Every instance with its source is listed on the [instances page](/instances/). Verified SDKs, reference implementations & validators: - [xaa.dev (Okta Developer sandbox: live end-to-end ID-JAG flow, requesting-app and resource-app test harness)](https://xaa.dev) · validator (2026-09-07) Our probe: seen on 6 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Builds on: [OAuth Protected Resource and Authorization Server Metadata (as used for agent authorization)](/protocols/oauth-metadata-for-agents/) - Depended on by: [auth.md](/protocols/auth-md/), [Identity Continuation Assertion for OAuth 2.0 Token Exchange](/protocols/oauth-id-continuation/) - Pairs with: [OAuth Protected Resource and Authorization Server Metadata (as used for agent authorization)](/protocols/oauth-metadata-for-agents/), [Model Context Protocol](/protocols/mcp/), [Agent Authorization Grant](/protocols/aauth/), [WIMSE AI Identity Management System](/protocols/wimse-aims/), [Agent Authorization Profile](/protocols/aap/), [SPIFFE (Secure Production Identity Framework for Everyone)](/protocols/spiffe/) ## Comparisons - [OAuth 2.0 Consent & DCR vs CIMD & Agent OAuth Metadata (classic vs agentic)](/compare/oauth-vs-cimd/) - [Agent Authorization Grant vs Identity Assertion JWT Authorization Grant](/compare/aauth-vs-identity-assertion-authz-grant/) - [Identity Assertion JWT Authorization Grant vs OAuth Profile for Delegated AI Agent Authorization](/compare/identity-assertion-authz-grant-vs-daap/) ## References - draft-ietf-oauth-identity-assertion-authz-grant-04 (authors Aaron Parecki/Okta, Karl McGuinness/Independent, Brian Campbell/Ping Identity; last updated 2026-05-21) is an Active Internet-Draft and WG Document of the IETF OAuth Working Group, replacing the individual submission draft-parecki-oauth-identity-assertion-authz-grant (first published 2024-03). Its abstract states the mechanism lets an application use an identity assertion to obtain an access token for a third-party API via Token Exchange (RFC 8693) and the JWT Profile for OAuth 2.0 Authorization Grants (RFC 7523), and that this pattern is informally called Cross-App Access (XAA). — [https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/](https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/) (2026-05-21) VERIFIED - Section 7/8 of the same draft defines the discovery signals: a Resource Authorization Server advertises support via authorization_grant_profiles_supported containing urn:ietf:params:oauth:grant-profile:id-jag (and MUST also list urn:ietf:params:oauth:grant-type:jwt-bearer in grant_types_supported); a client advertises support via the same property plus urn:ietf:params:oauth:grant-type:token-exchange. Appendix A.4.2.1 shows a worked example of an AI Agent discovering an enterprise IdP's OpenID Connect configuration, including identity_chaining_requested_token_types_supported containing urn:ietf:params:oauth:token-type:id-jag, before performing the ID-JAG token-exchange flow on the agent's own behalf. — [https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/](https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/) (2026-05-21) VERIFIED - xaa.dev, an Okta Developer-authored sandbox, states that Cross App Access (XAA) implements the OAuth Identity Assertion Authorization Grant (ID-JAG) draft, and lets a visitor run a live 4-step XAA flow (Auth Code+PKCE sign-in, ID-JAG token exchange per RFC 8693, access-token issuance per RFC 7523, Bearer resource call per RFC 6750) against a pre-configured Identity Provider, Authorization Server, and Resource App with no account or setup required. — [https://xaa.dev](https://xaa.dev) (2026-09-07) VERIFIED - Okta Developer published a paired guide series (Aug 21 and Aug 24, 2026) showing how an OIDC-federated application implements XAA as both a Requesting Application (exchange a refresh token for an ID-JAG, then the ID-JAG for an access token) and a Resource Application (validate the ID-JAG, resolve the user, issue a scoped access token), including registering apps in Okta and verifying the connection on xaa.dev; the requesting-app guide explicitly frames the flow as used by 'an agent (like one running in Claude)'. — [https://developer.okta.com/blog/2026/08/21/xaa-oidc-requesting](https://developer.okta.com/blog/2026/08/21/xaa-oidc-requesting) (2026-08-21) REPORTED - Auth0 (an Okta-owned identity platform, operated as a distinct product/brand) published guides (Aug 6 and Aug 20, 2026) describing XAA as the protocol underlying MCP's 'Enterprise-Managed Auth' extension, and walking through configuring Auth0 as an XAA Resource App to let AI agents such as Claude or Cursor reach a customer's MCP server under IT-admin-managed authorization rather than per-user consent. — [https://auth0.com/blog/xaa-protocol-auth0-ai-agents/](https://auth0.com/blog/xaa-protocol-auth0-ai-agents/) (2026-08-06) REPORTED - Descope announced (2026-09-01) Cross-App Access (XAA) support in its Agentic Identity Hub, stating it can both validate ID-JAG tokens issued by a customer's own identity provider and issue ID-JAG tokens for a customer's internal agents, positioning this as a third, independent implementation of the same draft alongside Okta and Auth0. — [https://martechseries.com/sales-marketing/id-mgmt/descope-unveils-cross-app-access-xaa-support-letting-enterprises-manage-ai-agent-access-with-their-existing-identity-providers/](https://martechseries.com/sales-marketing/id-mgmt/descope-unveils-cross-app-access-xaa-support-letting-enterprises-manage-ai-agent-access-with-their-existing-identity-providers/) (2026-09-01) REPORTED [JSON](/data/protocols/identity-assertion-authz-grant.json) · [Markdown](/protocols/identity-assertion-authz-grant/index.md) · [OKF v0.2](/okf/protocols/identity-assertion-authz-grant.md) --- # Identity Continuation Assertion for OAuth 2.0 Token Exchange Identity Continuation Assertion for OAuth 2.0 Token Exchange is an agentic-web standard (document format) at step 3, Permit, governed by Individual IETF Internet-Draft targeting the OAuth Working Group; its status is "Active Internet-Draft, Intended status: Standards Track". It answers: "How can a workload obtain an ID-JAG for another service after the user who started the session is no longer present?" Implementation status is none found, last verified 2026-10-24. ## Quick Wire Reference - **Step**: 3 Permit (What may the agent do here?) - **Version**: draft-mcguinness-oauth-id-continuation-assertion-02 (2026-09-09) - **Status**: Active Internet-Draft (individual submission), Intended status: Standards… - **Discovery / Probe Path**: OAuth 2.0 token exchange (RFC 8693). The assertion is a subject token, not a file on the… - **Spec URL**: https://www.ietf.org/archive/id/draft-mcguinness-oauth-id-continuation-assertion-02.txt - **Last Verified**: 2026-10-24 (current) - **Classic Web Analog**: A short-lived stand-in for the user, exchanged for an ID-JAG after the user has left [Permit](/category/permit/) draft-mcguinness-oauth-id-continuation-assertion-02 is a Standards Track Internet-Draft of the IETF Web Authorization Protocol (OAuth) working group, dated 9 September 2026 and expiring 13 March 2027 [[1]](#ref-1). It defines a short-lived, sender-constrained JWT used as a token-exchange subject token, so a workload can obtain an Identity Assertion JWT Authorization Grant (ID-JAG) for another service after the user has left [[1]](#ref-1). ## Overview It extends the ID-JAG profile already tracked as identity-assertion-authz-grant. It is a separate record from the Workload Authorization Grant, the Agent-Delegation header, and both AAP documents. The datatracker entry for the draft is [[2]](#ref-2). ## Discovery and probe OAuth 2.0 token exchange (RFC 8693). The assertion is a subject token, not a file on the origin. ``` n/a n/a (token-exchange subject token; no fixed origin artifact) parse: n/a. The assertion is presented as a subject token in a token-exchange request. on absent: No public artifact is defined, so absence at an origin is expected. ``` Not probed live: needs-credentials. The identity-continuation assertion is a token-exchange subject token; it is not published at a fixed path. ## History - 2026-10-20 — added from staged research 2026-10-20; header read from draft-mcguinness-oauth-id-continuation-assertion-02 ## Instances Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Builds on: [Identity Assertion JWT Authorization Grant](/protocols/identity-assertion-authz-grant/) - Pairs with: [Identity Assertion JWT Authorization Grant](/protocols/identity-assertion-authz-grant/), [OAuth Protected Resource and Authorization Server Metadata (as used for agent authorization)](/protocols/oauth-metadata-for-agents/), [Workload Authorization Grant](/protocols/workload-authz-grant/), [Attenuated Delegation Profile for Automated Agents](/protocols/oauth-agent-delegation/) ## References - draft-mcguinness-oauth-id-continuation-assertion-02 is a Standards Track Internet-Draft of the Web Authorization Protocol (OAuth) working group, dated 9 September 2026 and expiring 13 March 2027. It defines a short-lived sender-constrained JWT used as a token-exchange subject token so a workload can obtain an ID-JAG after the user has left. — [https://www.ietf.org/archive/id/draft-mcguinness-oauth-id-continuation-assertion-02.txt](https://www.ietf.org/archive/id/draft-mcguinness-oauth-id-continuation-assertion-02.txt) (2026-09-09) VERIFIED - Datatracker document page for draft-mcguinness-oauth-id-continuation-assertion. — [https://datatracker.ietf.org/doc/draft-mcguinness-oauth-id-continuation-assertion/](https://datatracker.ietf.org/doc/draft-mcguinness-oauth-id-continuation-assertion/) (2026-09-09) VERIFIED [JSON](/data/protocols/oauth-id-continuation.json) · [Markdown](/protocols/oauth-id-continuation/index.md) · [OKF v0.2](/okf/protocols/oauth-id-continuation.md) --- # JAFAR: A JSON-Based Format for Publishing IP Ranges of Automated HTTP Clients JAFAR: A JSON-Based Format for Publishing IP Ranges of Automated HTTP Clients is an agentic-web standard (document format) at step 2, Identify, governed by Individual Internet-Draft, not adopted by a working group; its status is "Active Internet-Draft, Intended Status: Informational". It answers: "How can a crawler or bot operator publish the IP ranges its automated clients use, in one machine-readable format that…?" Implementation status is none found, last verified 2026-10-23. ## Quick Wire Reference - **Step**: 2 Identify (Who is this agent? Who is this site?) - **Version**: draft-illyes-webbotauth-jafar-01 (2026-10-22) - **Status**: Active Internet-Draft (draft-illyes-webbotauth-jafar-01), Intended Status… - **Discovery / Probe Path**: None defined: the draft specifies only the JSON file's syntax and semantics (media type… - **Spec URL**: https://datatracker.ietf.org/doc/html/draft-illyes-webbotauth-jafar-01 - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: A crawler's published list of IP ranges, checked alongside reverse DNS [Identify](/category/identify/) JAFAR defines one JSON format in which operators of crawlers, AI bots and other automated HTTP clients publish the IP address ranges they send traffic from, so site operators can recognise legitimate automated traffic without maintaining a different parser per vendor [[2]](#ref-2). A file is a single JSON object with a creation timestamp and one array of prefixes covering both IPv4 and IPv6. Each prefix can be tagged with the publisher's own service names, and an optional sync token signals changes [[2]](#ref-2). The draft registers application/jafar+json, with a version parameter for future changes, and gives caching rules for consumers [[2]](#ref-2). ## Overview It says it codifies and extends common existing practice and complements forward-confirmed reverse DNS rather than replacing it [[2]](#ref-2). It defines only the file, not where it lives or how sites should use it, so there is nothing to probe at an origin [[2]](#ref-2). It sits beside Web Bot Auth, which identifies a client by signature rather than by address, and the expired crawler best-practices draft by the same author listed publishing IP ranges in a standard format as one of its six practices. Current state: an individual draft, revision -01 of 2026-10-22 (refreshing -00 of 2026-04-21 and replacing the earlier draft-illyes-aipref-jafar), expiring 2027-04-25. Discussion is on the aipref list despite the webbotauth draft name [[1]](#ref-1)[[2]](#ref-2). ## Discovery and probe None defined: the draft specifies only the JSON file's syntax and semantics (media type application/jafar+json), not where it is published or how it is retrieved ``` NONE parse: on absent: The draft defines no fixed location for the file, so absence at any given URL says nothing about whether an operator publishes one. ``` Not probed live: no-fixed-path. The draft defines the JSON format only, not where the file is published. ## History - 2026-10-20 — added from gap scout 2026-10-20; verified against the datatracker page (via Exa) and the -00 text (IETF rsync mirror); expires 2026-10-23, watch for -01 - 2026-10-22 — draft-illyes-webbotauth-jafar-00 expires on 2026-10-23 - 2026-10-23 — revision 00 → 01 (watcher) ## Instances Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Pairs with: [Web Bot Auth HTTP Message Signatures](/protocols/webbotauth/), [AI Crawler User-Agent Tokens in robots.txt](/protocols/ai-crawler-tokens-robots/), [Anonymous Bot Authentication](/protocols/anonymous-bot-auth/) ## Comparisons - [Web Bot Auth HTTP Message Signatures vs JAFAR: A JSON-Based Format for Publishing IP Ranges of Automated HTTP Clients](/compare/webbotauth-vs-jafar/) ## References - Datatracker lists draft-illyes-webbotauth-jafar-00 as an active individual Internet-Draft by Gary Illyes, Informational, dated 2026-04-21 and expiring 2026-10-23; it replaces draft-illyes-aipref-jafar. — [https://datatracker.ietf.org/doc/draft-illyes-webbotauth-jafar/](https://datatracker.ietf.org/doc/draft-illyes-webbotauth-jafar/) (2026-04-21) VERIFIED - The -00 text defines a single JSON object with a required creationTime and prefixes array (one unified IPv4/IPv6 list of Prefix Objects, each with exactly one of ipv4Prefix or ipv6Prefix and optional services), an optional synctoken and notes, fetching, caching and versioning rules via the application/jafar+json media type, and says it codifies and extends common existing practice to complement, not replace, forward-confirmed reverse DNS. Discussion is on the aipref list (ai-control@ietf.org). — [https://www.ietf.org/archive/id/draft-illyes-webbotauth-jafar-00.html](https://www.ietf.org/archive/id/draft-illyes-webbotauth-jafar-00.html) (2026-04-21) VERIFIED - Datatracker shows draft-illyes-webbotauth-jafar-01, dated 2026-10-22, expires 2027-04-25 — [https://datatracker.ietf.org/doc/draft-illyes-webbotauth-jafar/](https://datatracker.ietf.org/doc/draft-illyes-webbotauth-jafar/) (2026-10-22) VERIFIED [JSON](/data/protocols/jafar.json) · [Markdown](/protocols/jafar/index.md) · [OKF v0.2](/okf/protocols/jafar.md) --- # KYA-OS (Know Your Agent Operating System) (/.well-known/mcp) KYA-OS (Know Your Agent Operating System) is an agentic-web standard (document format — /.well-known/mcp) at step 2, Identify, governed by Decentralized Identity Foundation, KYA-OS Task Force in the…; its status is "SPEC.md declares 'Version: 1.0.0, Status: Stable' and says it…". It answers: "How can an MCP server tell which agent is calling, on whose authority it acts, and keep signed proof of what it did?" Implementation status is shipping, last verified 2026-10-23. ## Quick Wire Reference - **Step**: 2 Identify (Who is this agent? Who is this site?) - **Version**: 1.0.0 (Stable, self-declared) - **Status**: SPEC.md declares 'Version: 1.0.0, Status: Stable' and says it was ratified as… - **Discovery / Probe Path**: /.well-known/mcp — well-known JSON document on the MCP server naming its DID, capabilities… - **Spec URL**: https://github.com/decentralized-identity/kya-os-mcp/blob/main/SPEC.md - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: A signed letter of authority plus a receipt for every action [Identify](/category/identify/) KYA-OS, formerly MCP-I, is an identity and delegation layer for MCP and other agent protocols [[1]](#ref-1)[[2]](#ref-2). Each agent has a DID. A chain of W3C Verifiable Credentials links it back to the person or company that authorised it. The server can then check who is calling and on whose authority [[1]](#ref-1). Each tool response carries an Ed25519 signed proof in the MCP _meta field, giving both sides a record of what was done. Revocation uses StatusList2021 [[1]](#ref-1). ## Overview Servers SHOULD publish a JSON document at /.well-known/mcp naming their DID and which KYA-OS features they support [[1]](#ref-1). Note that this is a different path from the /.well-known/mcp.json some MCP server cards use. Vouched built it as MCP-I and donated it to the Decentralized Identity Foundation, which renamed it [[2]](#ref-2). DIF runs it as a task force inside its Trusted AI Agents Working Group and says the scope now reaches well beyond MCP [[3]](#ref-3). The spec calls itself Stable 1.0.0 and says DIF ratified it; DIF's own posts do not say so (see dispute). The repository's v1.21.1 tag versions the code package, not the spec. ## Discovery and probe well-known JSON document on the MCP server naming its DID, capabilities and endpoints (SPEC.md §10, SHOULD) · /.well-known/mcp ``` GET /.well-known/mcp parse: JSON with 'serverDid', 'version' and a 'capabilities' object (proofs, delegation, statusList); validate against schemas/well-known-mcpi.json on absent: The server does not advertise KYA-OS; the endpoint is a SHOULD, so a KYA-OS server may still attach proofs in MCP _meta without it. ``` Live check run by [the MCP probe](/mcp/server-card): GET /.well-known/mcp. KYA-OS SPEC.md section 10: servers SHOULD expose /.well-known/mcp with serverDid and capabilities. ``` { "path": "/.well-known/mcp", "expect": { "json_keys": [ "serverDid" ] }, "note": "KYA-OS SPEC.md section 10: servers SHOULD expose /.well-known/mcp with serverDid and capabilities." } ``` ## History - 2026-10-20 — added from gap scout 2026-10-20; verified against SPEC.md in decentralized-identity/kya-os-mcp (status line, §10 well-known endpoint) and DIF's posts of 2026-03-05 and 2026-04-22 ## Instances Verified SDKs, reference implementations & validators: - [KYA-OS reference implementation and documentation](https://modelcontextprotocol-identity.io) · implementation (2026-10-20) Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Builds on: [Model Context Protocol](/protocols/mcp/) - Pairs with: [Model Context Protocol](/protocols/mcp/), [x401: HTTP Proof Requirement Protocol](/protocols/x401/), [KYAPay Token](/protocols/kyapay-token/) - Not to be confused with: KYA (the generic Know-Your-Agent term in the glossary), KYAPay (Skyfire's token profile, tracked as kyapay-token, unrelated) ## Comparisons - [ERC-8004: Trustless Agents vs KYA-OS (Know Your Agent Operating System)](/compare/erc-8004-vs-kya-os/) - [Visa Trusted Agent Protocol vs KYA-OS (Know Your Agent Operating System)](/compare/tap-vs-kya-os/) ## References - SPEC.md, 'KYA-OS Protocol Specification', declares Version 1.0.0, Status Stable; it defines agent DIDs (did:key, did:web), W3C Verifiable Credential delegation chains rooted at a Responsible Party, Ed25519 signed per-response proofs attached in MCP _meta, StatusList2021 revocation, and a /.well-known/mcp endpoint servers SHOULD expose. — [https://github.com/decentralized-identity/kya-os-mcp/blob/main/SPEC.md](https://github.com/decentralized-identity/kya-os-mcp/blob/main/SPEC.md) VERIFIED - DIF's post 'Why We Brought KYA-OS (formerly MCP-I) to DIF' confirms the rename from MCP-I and the donation by Vouched. — [https://blog.identity.foundation/why-dif-said-yes-to-mcp-i/](https://blog.identity.foundation/why-dif-said-yes-to-mcp-i/) (2026-03-05) VERIFIED - DIF announces a KYA-OS Task Force inside the Trusted AI Agents Working Group, with a scope extending well beyond MCP. — [https://blog.identity.foundation/kya-os/](https://blog.identity.foundation/kya-os/) (2026-04-22) VERIFIED - Vouched announces, with DIF, the launch of KYA-OS as an open trust layer for AI agents. — [https://www.vouched.id/learn/vouched-and-the-decentralized-identity-foundation-launch-kya-os-an-open-trust-layer-for-ai-agents](https://www.vouched.id/learn/vouched-and-the-decentralized-identity-foundation-launch-kya-os-an-open-trust-layer-for-ai-agents) (2026-07-29) REPORTED Disputed: The spec's own status line says Stable 1.0.0 and claims ratification as a DIF standard, but DIF's posts describe a task force still developing it, and no DIF ratification notice was found. [JSON](/data/protocols/kya-os.json) · [Markdown](/protocols/kya-os/index.md) · [OKF v0.2](/okf/protocols/kya-os.md) --- # KYAPay Token KYAPay Token is an agentic-web standard (document format) at step 7, Pay, governed by Individual Internet-Draft, not adopted by an IETF working group; its status is "Active Internet-Draft, individual submission, intended status…". It answers: "How can an authorization or resource server from one vendor check which agent is calling and accept its payment token…?" Implementation status is shipping, last verified 2026-10-23. ## Quick Wire Reference - **Step**: 7 Pay (Settle the bill) - **Version**: draft-skyfire-oauth-kyapay-token-02 (2026-10-02) - **Status**: Active Internet-Draft, individual submission, intended status Standards Track… - **Discovery / Probe Path**: tokens are presented to the resource server; verifiers fetch the issuer's signing keys… - **Spec URL**: https://datatracker.ietf.org/doc/draft-skyfire-oauth-kyapay-token/ - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: A signed ID card and a payment card in one envelope, readable by any shop [Pay](/category/pay/) KYAPay Token defines JWT profiles that let an agent show who it is and pay in one step [[2]](#ref-2). There are three token types: kya+jwt for agent identity, pay+jwt for payment and kya-pay+jwt for both together [[2]](#ref-2). The aim is for authorization and resource servers from different vendors to verify the agent and accept its payment without a bilateral integration. The draft lists settlement types, including card schemes such as visa_vic and mastercard_scof [[2]](#ref-2). ## Overview It is an individual Internet-Draft from Skyfire, co-authored by Michael B. Jones, and has not been adopted by an IETF working group [[1]](#ref-1). Revision -02 is dated 2026-10-02 and replaces the earlier draft-skyfire-kyapayprofile [[1]](#ref-1)[[2]](#ref-2). Skyfire publishes live signing keys for its tokens [[3]](#ref-3). It lives under Pay because of the combined token and settlement types, but it does Identify work too. ## Discovery and probe tokens are presented to the resource server; verifiers fetch the issuer's signing keys (Skyfire publishes its own at app.skyfire.xyz/.well-known/jwks.json) ``` GET none — tokens are presented per request by the agent parse: No artefact at a fixed path on the resource server; a verifier would check the token's typ (kya+jwt, pay+jwt or kya-pay+jwt) against the issuer's JWKS. on absent: Not probeable from a resource server's origin. ``` Not probed live: needs-credentials. KYAPay tokens are presented per request by the agent; nothing is published at a fixed path on the resource server. ## History - 2026-10-20 — added from gap scout 2026-10-20; verified against the datatracker record and -02 text of draft-skyfire-oauth-kyapay-token, and Skyfire's live JWKS ## Instances Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Pairs with: [x402](/protocols/x402/), [Agent Payments Protocol](/protocols/ap2/), [KYA-OS (Know Your Agent Operating System)](/protocols/kya-os/) - Not to be confused with: KYA-OS (DIF identity layer for MCP, tracked as kya-os, unrelated) ## Comparisons - [KYAPay Token vs x402](/compare/kyapay-token-vs-x402/) - [KYAPay Token vs Agent Payments Protocol](/compare/kyapay-token-vs-ap2/) ## References - Datatracker lists draft-skyfire-oauth-kyapay-token-02, 'KYAPay Token', as an Active individual Internet-Draft by Ankit Agarwal (Skyfire Systems Inc.) and Michael B. Jones (Self-Issued Consulting), intended Standards Track, last updated 2026-10-01, replacing draft-skyfire-kyapayprofile. — [https://datatracker.ietf.org/doc/draft-skyfire-oauth-kyapay-token/](https://datatracker.ietf.org/doc/draft-skyfire-oauth-kyapay-token/) (2026-10-01) VERIFIED - The -02 text, dated 2 October 2026 and expiring 5 April 2027, defines the kya+jwt, pay+jwt and kya-pay+jwt token types and settlement types including visa_vic and mastercard_scof. — [https://datatracker.ietf.org/doc/html/draft-skyfire-oauth-kyapay-token-02](https://datatracker.ietf.org/doc/html/draft-skyfire-oauth-kyapay-token-02) (2026-10-02) VERIFIED - Skyfire's JWKS endpoint returns live signing keys (HTTP 200). — [https://app.skyfire.xyz/.well-known/jwks.json](https://app.skyfire.xyz/.well-known/jwks.json) (2026-10-20) VERIFIED [JSON](/data/protocols/kyapay-token.json) · [Markdown](/protocols/kyapay-token/index.md) · [OKF v0.2](/okf/protocols/kyapay-token.md) --- # L402 L402 is an agentic-web standard (HTTP header) at step 7, Pay, governed by Lightning Labs; its status is "Active, registered as an HTTP Authentication scheme". It answers: "How can a client pay for, and then authenticate to, a metered API resource over the Lightning Network with no accounts…?" Implementation status is shipping, last verified 2026-10-23. ## Quick Wire Reference - **Step**: 7 Pay (Settle the bill) - **Version**: current protocol-specification.md on the master branch - **Status**: Active, registered as an HTTP Authentication scheme (RFC 7235-style) · shipping - **Discovery / Probe Path**: none — signalled per-request, no well-known file — HTTP 402 response carrying a… - **Spec URL**: https://raw.githubusercontent.com/lightninglabs/L402/master/protocol-specification.md - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: HTTP 402 plus a bearer credential (like an API key you buy per-use) [Pay](/category/pay/) L402 (formerly LSAT, Lightning Service Authentication Token) is an HTTP authentication scheme, developed by Lightning Labs, that combines the dormant HTTP 402 status code with Lightning Network micropayments to let a client pay for and then authenticate to a metered API resource in a single credential [[1]](#ref-1)[[2]](#ref-2). A server challenges with HTTP 402 plus a WWW-Authenticate: L402 header containing a macaroon and a BOLT-11 Lightning invoice; the client pays the invoice, receives a payment preimage, and re-presents macaroon:preimage in an Authorization header on retry — the server verifies statelessly by checking that the preimage hashes to the payment hash embedded in the macaroon, with no database lookup [[1]](#ref-1). ## Overview It solves pay-per-use API access without accounts, passwords, or centralized session state, and its macaroon-based credentials support caveats and attenuation, so a holder can mint a narrower, delegated sub-credential for another party (including another agent) without contacting the issuing server [[2]](#ref-2). It does not itself define a currency or settlement rail beyond the Lightning Network, and it is explicitly scoped to authentication plus payment proof, not to cart-building, catalog discovery, or dispute resolution — those are left to whatever service sits behind the challenge. The specification is precise about status-code discipline: 402 is reserved exclusively for the initial payment challenge, while a 401 is returned once any credential (valid-looking or not) has been submitted, so clients can distinguish "you must pay" from "your credential is broken" [[1]](#ref-1). As of this verification, the specification lives on the master branch of lightninglabs/L402 with no separately dated release tag observed, and Lightning Labs also operates a reference reverse-proxy implementation (Aperture) that gates access to metered services with L402 in production. No independent, dated count of production L402 deployments was located during this verification, so adoption is recorded as unmeasured rather than claimed or observed — Lightning Labs' own materials assert active use but do not publish a number in the sources checked. ## Discovery and probe HTTP 402 response carrying a WWW-Authenticate challenge · none — signalled per-request, no well-known file ``` GET {origin}/{paid-path} parse: HTTP 402 status with a WWW-Authenticate: L402 macaroon="...", invoice="..." header on absent: A 200, 401, or a 402 without an L402-scheme WWW-Authenticate header means this path does not issue L402 challenges; the credential scheme is registered under RFC 7235 so a server could in principle offer it alongside other schemes on the same 401/402 responses. ``` Not probed live: no-fixed-path. L402 challenges appear only on paid URLs. ## History - 2026-09-05 — seeded from Exa Agent research run - 2026-09-06 — verified against lightninglabs/L402 README.md and protocol-specification.md on GitHub - 2026-10-16 — use-case tags (auto) ## Instances - [SatGate L402 API Gateway](https://satgate.io) · Observed 2026-08-29 · venue - [Lightning Labs Aperture L402 Facilitator Proxy](https://docs.lightning.engineering/the-lightning-network/l402) · Observed 2026-08-29 · venue Every instance with its source is listed on the [instances page](/instances/). Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Pairs with: [x402](/protocols/x402/), [Machine Payments Protocol](/protocols/mpp/), [HTTP Message Signatures](/protocols/http-message-signatures/), [Model Context Protocol](/protocols/mcp/), [s402](/protocols/s402/) - [x402](/protocols/x402/) - [Machine Payments Protocol](/protocols/mpp/) - [s402](/protocols/s402/) - [Cloudflare Pay per crawl](/protocols/cloudflare-pay-per-crawl/) ## Comparisons - [API Keys & Subscriptions vs x402 & MPP (HTTP 402) (classic vs agentic)](/compare/api-keys-vs-x402/) - [x402 vs L402](/compare/x402-vs-l402/) - [Cloudflare Pay per crawl vs L402](/compare/cloudflare-pay-per-crawl-vs-l402/) - [L402 vs Machine Payments Protocol](/compare/l402-vs-mpp/) - [L402 vs s402](/compare/l402-vs-s402/) ## References - L402's protocol specification defines the credential as a `:` pair, the challenge as `WWW-Authenticate: L402 macaroon=..., invoice=...` on a 402, and requires servers to switch to 401 (not 402) once a credential has been presented but fails verification. — [https://raw.githubusercontent.com/lightninglabs/L402/master/protocol-specification.md](https://raw.githubusercontent.com/lightninglabs/L402/master/protocol-specification.md) VERIFIED - The L402 README states it was developed by Lightning Labs, evolved from the earlier LSAT (Lightning Service Authentication Token) concept, and is designed to fit agentic use cases where an AI agent discovers, pays for, and authenticates to a service without human intervention, including delegated sub-credentials via macaroon caveat attenuation. — [https://raw.githubusercontent.com/lightninglabs/L402/master/README.md](https://raw.githubusercontent.com/lightninglabs/L402/master/README.md) VERIFIED [JSON](/data/protocols/l402.json) · [Markdown](/protocols/l402/index.md) · [OKF v0.2](/okf/protocols/l402.md) --- # llms.txt (/llms.txt) llms.txt is an agentic-web standard (well-known file — /llms.txt) at step 4, Read, governed by Jeremy Howard / Answer.AI; its status is "This is v2 of the proposal — explicitly a community proposal…". It answers: "Where can an agent find a concise, curated map of a site's content, written for language models rather than browsers?" Replacing or extending sitemap.xml / a README for a site's documentation, implementation status is multi-implementation (Rankability and SE Ranking — independent third-party…; observed on 519/1226 probed origins), last verified 2026-10-23. ## Quick Wire Reference - **Step**: 4 Read (Give me the content) - **Version**: v2 (2026-08) - **Status**: "This is v2 of the proposal" — explicitly a community proposal open for input… - **Discovery / Probe Path**: /llms.txt — Fixed filename at the site root or at any subpath, covering the pages… - **Spec URL**: https://llmstxt.org - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: sitemap.xml / a README for a site's documentation [Read](/category/read/) llms.txt is a proposed convention for publishing a small, curated, markdown-formatted index of a site's content at /llms.txt (or a subpath such as /docs/llms.txt), intended to be read by language models and AI agents rather than crawled and scraped like a full site [[1]](#ref-1). The file is one required H1 heading naming the project, an optional blockquote summary, optional free-form context, and then H2-delimited "file lists" of markdown links to more detailed content — typically clean .md mirrors of a site's HTML pages [[1]](#ref-1). ## Overview It solves a narrow problem: HTML pages are built for browsers, wrap information in navigation and scripts that are wasteful to parse into an LLM's limited context window, and give an agent no small, authoritative starting point for a large site. llms.txt gives a site a place to say "start here" and to link to markdown-native content instead of full HTML [[1]](#ref-1). It does not solve discovery for sites that don't publish one, does not replace robots.txt (a permission signal, not a content index) or sitemap.xml (exhaustive, for search-engine crawlers, and usually not markdown-native) [[1]](#ref-1), and — critically — it does not guarantee that anything reads it. Google's own Search Central documentation, last updated 2026-07-10, explicitly tells site owners they "don't need to create ... llms.txt" because "Google Search itself doesn't use them," filing it alongside other AEO/GEO "hacks" to ignore [[3]](#ref-3). No answer engine has published documentation describing llms.txt consumption in its retrieval pipeline. The current text is v2, published August 2026, revising the original September 2024 proposal by Jeremy Howard (Answer.AI). v2's main addition is standard discovery link relations (rel="alternate" type="text/markdown" for a page's markdown twin, rel="describedby" for the covering llms.txt file), expressible as HTML tags or an HTTP Link: header; it also loosened the markdown-mirror URL convention and dropped the v1 context-expansion tooling and the special meaning of the "Optional" section [[1]](#ref-1)[[2]](#ref-2). The specification remains an informal, single-maintainer GitHub proposal, not a standards-track document of any kind [[1]](#ref-1). On the producer side, several documentation platforms and CMSs generate llms.txt automatically — Mintlify, GitBook, Yoast SEO, AIOSEO, and Wix — and OpenAI, Anthropic, and Google publish llms.txt for their own developer docs [[1]](#ref-1). This is genuine, if modest, publisher-side adoption: independent Tranco-based studies put it at roughly 8.7% of the top 1,000 domains (June 2026) and 5.6% of the top 10,000 [[4]](#ref-4), while a broader ~300,000-domain analysis found 10.13% overall, spread fairly evenly across traffic tiers rather than concentrated among high-traffic sites [[5]](#ref-5). What is disputed or unknown is consumption, not existence. The gap between "a file exists" and "a model reads it" is large and, per the sources available, mostly unmeasured by anyone with visibility into model retrieval internals. One large-scale server-log study of 137,000 llms.txt-publishing sites found 97% of the files were never fetched by any client during the observation window, and of the requests that did arrive, 96% came from generic bots rather than identifiable AI assistants [[6]](#ref-6). Combined with Google's explicit statement that its own systems ignore the file, the safest characterization is: llms.txt is a real, growing publisher-side convention with no documented reader among major answer engines as of mid-2026. ## Discovery and probe Fixed filename at the site root or at any subpath, covering the pages under that path · /llms.txt (or //llms.txt, e.g. /docs/llms.txt) ``` GET {origin}/llms.txt parse: 200 response beginning with an H1 heading (`# `) followed by a blockquote summary, per the llms.txt v2 grammar on absent: No llms.txt at this path; a more specific subpath file (e.g. /docs/llms.txt) may still exist and take precedence for that subpath ``` Live check run by [the MCP probe](/mcp/server-card): GET /llms.txt. llms.txt must begin with an H1 line. ``` { "path": "/llms.txt", "expect": { "text_match": "(?m)^# \\S" }, "note": "llms.txt must begin with an H1 line." } ``` ## History - 2026-09-05 — seeded from Exa Agent research run - 2026-09-06 — verified against llmstxt.org (v2, Aug 2026), llmstxt.org/changes.html, Google's AI optimization guide, and three independent third-party adoption studies (Rankability, SE Ranking, Ahrefs) - 2026-10-16 — llms-txt Python package 0.0.7 released 2026-09-24 (tooling, spec unchanged at v2) - 2026-10-16 — use-case tags (auto) - 2026-10-16 — version 0.0.7 (watcher) - 2026-10-16 — version label restored to 'v2'; the repository's latest tag (0.0.7) is a package, SDK or build tag, not the specification version, so the GitHub watch no longer drives version ## Instances - [Zuplo API Gateway (zuplo.com)](https://zuplo.com/) · Observed 2026-10-25 · origin - [Zoom Developers (developers.zoom.us)](https://developers.zoom.us/) · Observed 2026-10-25 · origin - [Zep Long-Term Agent Memory (getzep.com)](https://getzep.com/) · Observed 2026-10-25 · origin - [Zapier (zapier.com)](https://zapier.com/) · Observed 2026-10-25 · origin - [Webflow Developers (developers.webflow.com)](https://developers.webflow.com/) · Observed 2026-10-25 · origin - [Warp Agentic Terminal (warp.dev)](https://warp.dev/) · Observed 2026-10-25 · origin - [Vellum AI Workflow Platform (vellum.ai)](https://vellum.ai/) · Observed 2026-10-25 · origin - [Vast.ai (vast.ai)](https://vast.ai/) · Observed 2026-10-25 · origin - [Taskade (taskade.com)](https://taskade.com/) · Observed 2026-10-25 · origin - [SurrealDB (surrealdb.com)](https://surrealdb.com/) · Observed 2026-10-25 · origin - [Supermemory (supermemory.ai)](https://supermemory.ai/) · Observed 2026-10-25 · origin - [Supabase (supabase.com)](https://supabase.com/) · Observed 2026-10-25 · origin - [StackOne Agentic Integration Hub (stackone.com)](https://stackone.com/) · Observed 2026-10-25 · origin - [Speakeasy (speakeasy.com)](https://speakeasy.com/) · Observed 2026-10-25 · origin - [Skyvern Browser Automation Agent (skyvern.com)](https://skyvern.com/) · Observed 2026-10-25 · origin - [Sentry (sentry.io)](https://sentry.io/) · Observed 2026-10-25 · origin - [Semgrep (semgrep.dev)](https://semgrep.dev/) · Observed 2026-10-25 · origin - [Scalar API Platform (scalar.com)](https://scalar.com/) · Observed 2026-10-25 · origin - [SavvyCal (savvycal.com)](https://savvycal.com/) · Observed 2026-10-25 · origin - [Sanity Content Operating System (sanity.io)](https://sanity.io/) · Observed 2026-10-25 · origin - [RunPod GPU Cloud (runpod.io)](https://runpod.io/) · Observed 2026-10-25 · origin - [Revid AI Video Platform (revid.ai)](https://revid.ai/) · Observed 2026-10-25 · origin - [Replicate (replicate.com)](https://replicate.com/) · Observed 2026-10-25 · origin - [Reducto Document AI (reducto.ai)](https://reducto.ai/) · Observed 2026-10-25 · origin - [React Email by Resend (react.email)](https://react.email/) · Observed 2026-10-25 · origin - [Pydantic & Logfire (pydantic.dev)](https://pydantic.dev/) · Observed 2026-10-25 · origin - [Publica.la (publica.la)](https://publica.la/) · Observed 2026-10-25 · origin - [Proof API (api.proof.com)](https://api.proof.com/.well-known/ard.json) · Observed 2026-10-25 · origin - [Prisma ORM & Postgres (prisma.io)](https://prisma.io/) · Observed 2026-10-25 · origin - [Podscan Podcast Intelligence API (podscan.fm)](https://podscan.fm/) · Observed 2026-10-25 · origin - [PlanetScale (planetscale.com)](https://planetscale.com/) · Observed 2026-10-25 · origin - [Plane (plane.so)](https://plane.so/) · Observed 2026-10-25 · origin - [Perplexity API Docs (docs.perplexity.ai)](https://docs.perplexity.ai/) · Observed 2026-10-25 · origin - [Papermark Open-Source DocSend (papermark.io)](https://papermark.io/) · Observed 2026-10-25 · origin - [OpenStatus (openstatus.dev)](https://openstatus.dev/) · Observed 2026-10-25 · origin - [Novita AI (novita.ai)](https://novita.ai/) · Observed 2026-10-25 · origin - [Nomads.com (nomads.com)](https://nomads.com/) · Observed 2026-10-25 · origin - [MotherDuck Serverless DuckDB (motherduck.com)](https://motherduck.com/) · Observed 2026-10-25 · origin - [Morph Fast Apply LLM (morphllm.com)](https://morphllm.com/) · Observed 2026-10-25 · origin - [Model Context Protocol Docs (modelcontextprotocol.io)](https://modelcontextprotocol.io/) · Observed 2026-10-25 · origin - [Mintlify (mintlify.com)](https://mintlify.com/) · Observed 2026-10-25 · origin - [MetricSpot (metricspot.com)](https://metricspot.com/) · Observed 2026-10-25 · origin - [Lovable AI Full-Stack Builder (lovable.dev)](https://lovable.dev/) · Observed 2026-10-25 · origin - [LibreChat Open-Source AI Workspace (librechat.ai)](https://librechat.ai/) · Observed 2026-10-25 · origin - [LanceDB (lancedb.com)](https://lancedb.com/) · Observed 2026-10-25 · origin - [Lago (getlago.com)](https://getlago.com/) · Observed 2026-10-25 · origin - [Intercom Developers (developers.intercom.com)](https://developers.intercom.com/) · Observed 2026-10-25 · origin - [Infisical Secrets Management (infisical.com)](https://infisical.com/) · Observed 2026-10-25 · origin - [Hyperbrowser Cloud Browser for Agents (hyperbrowser.ai)](https://hyperbrowser.ai/) · Observed 2026-10-25 · origin - [Hostinger (hostinger.com)](https://hostinger.com/) · Observed 2026-10-25 · origin - [Gumroad Creator Commerce (gumroad.com)](https://gumroad.com/) · Observed 2026-10-25 · origin - [Graphlit Knowledge Retrieval Platform (graphlit.com)](https://graphlit.com/) · Observed 2026-10-25 · origin - [Glama MCP Gateway & Directory (glama.ai)](https://glama.ai/) · Observed 2026-10-25 · origin - [Fly.io (fly.io)](https://fly.io/) · Observed 2026-10-25 · origin - [Eodly (eodly.io)](https://eodly.io/) · Observed 2026-10-25 · origin - [docs.warp.dev](https://docs.warp.dev/) · Observed 2026-10-25 · origin - [Devin Origin (devin.ai)](https://devin.ai/) · Observed 2026-10-25 · origin - [Desvela (desvela.dev)](https://desvela.dev/) · Observed 2026-10-25 · origin - [Descope Identity & Agent Auth (descope.com)](https://descope.com/) · Observed 2026-10-25 · origin - [DC Hub (dchub.cloud)](https://dchub.cloud/) · Observed 2026-10-25 · origin - [DataFast Analytics (datafa.st)](https://datafa.st/) · Observed 2026-10-25 · origin - [Customer.io (customer.io)](https://customer.io/) · Observed 2026-10-25 · origin - [crewai.com](https://crewai.com/) · Observed 2026-10-25 · origin - [Convex Reactive Backend (convex.dev)](https://convex.dev/) · Observed 2026-10-25 · origin - [Coinbase (coinbase.com)](https://coinbase.com/) · Observed 2026-10-25 · origin - [Circle (circle.so)](https://circle.so/) · Observed 2026-10-25 · origin - [Checkly Synthetic Monitoring (checklyhq.com)](https://checklyhq.com/) · Observed 2026-10-25 · origin - [Cerebrium Serverless AI (cerebrium.ai)](https://cerebrium.ai/) · Observed 2026-10-25 · origin - [Cal.com Scheduling Infrastructure (cal.com)](https://cal.com/) · Observed 2026-10-25 · origin - [cafe24.com](https://www.cafe24.com/) · Observed 2026-10-25 · origin - [Browser Use Web Agent Runtime (browser-use.com)](https://browser-use.com/) · Observed 2026-10-25 · origin - [Bird (bird.com)](https://bird.com/) · Observed 2026-10-25 · origin - [beehiiv Newsletter Platform (beehiiv.com)](https://beehiiv.com/) · Observed 2026-10-25 · origin - [Baseten Docs (docs.baseten.co)](https://docs.baseten.co/) · Observed 2026-10-25 · origin - [Augment Code Docs (docs.augmentcode.com)](https://docs.augmentcode.com/) · Observed 2026-10-25 · origin - [Attio Docs (docs.attio.com)](https://docs.attio.com/) · Observed 2026-10-25 · origin - [Atlan (atlan.com)](https://atlan.com/) · Observed 2026-10-25 · origin - [Arcade AI Tool-Calling Runtime (arcade.dev)](https://arcade.dev/) · Observed 2026-10-25 · origin - [Appwrite Backend Platform (appwrite.io)](https://appwrite.io/) · Observed 2026-10-25 · origin - [Apideck Unified API (apideck.com)](https://apideck.com/) · Observed 2026-10-25 · origin - [Amplitude (amplitude.com)](https://amplitude.com/) · Observed 2026-10-25 · origin - [Agent Skills Specification (agentskills.io)](https://agentskills.io/) · Observed 2026-10-25 · origin - [Agent Client Protocol (agentclientprotocol.com)](https://agentclientprotocol.com/) · Observed 2026-10-25 · origin - [AG-UI Documentation Origin (docs.ag-ui.com)](https://docs.ag-ui.com/) · Observed 2026-10-25 · origin - [Ad Context Protocol Docs (docs.adcontextprotocol.org)](https://docs.adcontextprotocol.org/) · Observed 2026-10-25 · origin - [2s.io](https://2s.io/) · Observed 2026-10-25 · origin - [Yoast SEO (yoast.com)](https://yoast.com/) · Observed 2026-10-23 · origin - [x402 Foundation Spec Origin (x402.org)](https://x402.org/) · Observed 2026-10-23 · origin - [Webhooks.cc (webhooks.cc)](https://webhooks.cc/) · Observed 2026-10-23 · origin - [Vercel (vercel.com)](https://vercel.com/) · Observed 2026-10-23 · origin - [Universal Commerce Protocol Spec (ucp.dev)](https://ucp.dev/) · Observed 2026-10-23 · origin - [Tempo (tempo.xyz)](https://tempo.xyz/) · Observed 2026-10-23 · origin - [Telnyx (telnyx.com)](https://telnyx.com/) · Observed 2026-10-23 · origin - [Sunil Prakash / AIP (sunilprakash.com)](https://sunilprakash.com/) · Observed 2026-10-23 · origin - [Stripe Documentation (docs.stripe.com)](https://docs.stripe.com/) · Observed 2026-10-23 · origin - [Stripe (stripe.com)](https://stripe.com/) · Observed 2026-10-23 · origin - [STM Association (stm-assoc.org)](https://stm-assoc.org/) · Observed 2026-10-23 · origin - [SleekNova (sleeknova.com)](https://sleeknova.com/) · Observed 2026-10-23 · origin - [Slack (slack.com)](https://slack.com/) · Observed 2026-10-23 · origin - [shopify.com](https://shopify.com/) · Observed 2026-10-23 · origin - [SAP (sap.com)](https://sap.com/) · Observed 2026-10-23 · origin - [Samsung (samsung.com)](https://samsung.com/) · Observed 2026-10-23 · origin - [Salespeak B2B Buyer Concierge Agent](https://salespeak.ai) · Observed 2026-10-23 · agent - [RudderStack (rudderstack.com)](https://rudderstack.com/) · Observed 2026-10-23 · origin - [rtblint.org](https://rtblint.org/) · Observed 2026-10-23 · origin - [Resend (resend.com)](https://resend.com/) · Observed 2026-10-23 · origin - [Railway (railway.com)](https://railway.com/) · Observed 2026-10-23 · origin - [QuickNode (quicknode.com)](https://quicknode.com/) · Observed 2026-10-23 · origin - [QAIL (qail.ai)](https://qail.ai/) · Observed 2026-10-23 · origin - [Proof (proof.com)](https://proof.com/) · Observed 2026-10-23 · origin - [pmg.com](https://pmg.com/) · Observed 2026-10-23 · origin - [packalyst.com](https://packalyst.com/) · Observed 2026-10-23 · origin - [oreilly.com](https://oreilly.com/) · Observed 2026-10-23 · origin - [openknowledge.ai](https://openknowledge.ai/) · Observed 2026-10-23 · origin - [OpenAI Developer Docs (developers.openai.com)](https://developers.openai.com/) · Observed 2026-10-23 · origin - [okta.com](https://okta.com/) · Observed 2026-10-23 · origin - [Next.js (nextjs.org)](https://nextjs.org/) · Observed 2026-10-23 · origin - [Neuronto Agentic Web Index](https://neuronto.com) · Observed 2026-10-23 · venue - [Neon Serverless Postgres (neon.com)](https://neon.com/) · Observed 2026-10-23 · origin - [n8n Documentation Origin (docs.n8n.io)](https://docs.n8n.io/) · Observed 2026-10-23 · origin - [mcp.sentry.dev](https://mcp.sentry.dev/) · Observed 2026-10-23 · origin - [mastra.ai](https://mastra.ai/) · Observed 2026-10-23 · origin - [mapsoft.com](https://mapsoft.com/) · Observed 2026-10-23 · origin - [Loops (loops.so)](https://loops.so/) · Observed 2026-10-23 · origin - [Linear (linear.app)](https://linear.app/) · Observed 2026-10-23 · origin - [kochava.com](https://kochava.com/) · Observed 2026-10-23 · origin - [kilo.ai](https://kilo.ai/) · Observed 2026-10-23 · origin - [karangoyal.cc](https://karangoyal.cc/) · Observed 2026-10-23 · origin - [juliamaehler.com](https://juliamaehler.com/) · Observed 2026-10-23 · origin - [IMG.LY (img.ly)](https://img.ly/) · Observed 2026-10-23 · origin - [HubSpot (hubspot.com)](https://hubspot.com/) · Observed 2026-10-23 · origin - [Honeycomb AI (honeyb.ai)](https://honeyb.ai/) · Observed 2026-10-23 · origin - [GitHub (github.com)](https://github.com/) · Observed 2026-10-23 · origin - [GitBook (gitbook.com)](https://gitbook.com/) · Observed 2026-10-23 · origin - [getdbt.com](https://getdbt.com/) · Observed 2026-10-23 · origin - [Firecrawl (firecrawl.dev)](https://firecrawl.dev/) · Observed 2026-10-23 · origin - [factory.com](https://factory.com/) · Observed 2026-10-23 · origin - [etsy.com](https://etsy.com/) · Observed 2026-10-23 · origin - [Dreaming Press (dreaming.press)](https://dreaming.press/) · Observed 2026-10-23 · origin - [docs.github.com](https://docs.github.com/) · Observed 2026-10-23 · origin - [devtoollab.com](https://devtoollab.com/) · Observed 2026-10-23 · origin - [dev.to](https://dev.to/) · Observed 2026-10-23 · origin - [deepmind.google](https://deepmind.google/) · Observed 2026-10-23 · origin - [danilchenko.dev](https://danilchenko.dev/) · Observed 2026-10-23 · origin - [danads.com](https://danads.com/) · Observed 2026-10-23 · origin - [Cursor Origin (cursor.com)](https://cursor.com/) · Observed 2026-10-23 · origin - [crawlytics.app](https://crawlytics.app/) · Observed 2026-10-23 · origin - [copilotkit.ai](https://copilotkit.ai/) · Observed 2026-10-23 · origin - [code.visualstudio.com](https://code.visualstudio.com/) · Observed 2026-10-23 · origin - [Cloudflare (cloudflare.com)](https://cloudflare.com/) · Observed 2026-10-23 · origin - [cloudandsre.com](https://cloudandsre.com/) · Observed 2026-10-23 · origin - [cloud.tencent.com](https://cloud.tencent.com/) · Observed 2026-10-23 · origin - [ClickHouse (clickhouse.com)](https://clickhouse.com/) · Observed 2026-10-23 · origin - [circle.com](https://circle.com/) · Observed 2026-10-23 · origin - [Chris Hood (chrishood.com)](https://chrishood.com/) · Observed 2026-10-23 · origin - [byteiota.com](https://byteiota.com/) · Observed 2026-10-23 · origin - [bmdpat.com](https://bmdpat.com/) · Observed 2026-10-23 · origin - [blakecrosley.com](https://blakecrosley.com/) · Observed 2026-10-23 · origin - [AWS Strands Agents (strandsagents.com)](https://strandsagents.com/) · Observed 2026-10-23 · origin - [auth.md Specification Origin (auth-md.com)](https://auth-md.com/) · Observed 2026-10-23 · origin - [Atlassian (atlassian.com)](https://atlassian.com/) · Observed 2026-10-23 · origin - [Asana (asana.com)](https://asana.com/) · Observed 2026-10-23 · origin - [Apify (apify.com)](https://apify.com/) · Observed 2026-10-23 · origin - [Anthropic Support (support.claude.com)](https://support.claude.com/) · Observed 2026-10-23 · origin - [Anthropic Claude Platform (platform.claude.com)](https://platform.claude.com/) · Observed 2026-10-23 · origin - [Ant International (ant-intl.com)](https://ant-intl.com/) · Observed 2026-10-23 · origin - [All in One SEO (aioseo.com)](https://aioseo.com/) · Observed 2026-10-23 · origin - [aitxt.ing](https://aitxt.ing/) · Observed 2026-10-23 · origin - [Agentman (agentman.ai)](https://agentman.ai/) · Observed 2026-10-23 · origin - [agenticweb.wiki Reference Agent and MCP Server](https://agenticweb.wiki) · Observed 2026-10-23 · agent - [Agentic AI Foundation (aaif.io)](https://aaif.io/) · Observed 2026-10-23 · origin - [agent-ready.dev Conformance Scanner Agent](https://agent-ready.dev) · Observed 2026-10-23 · agent - [0G Labs (0g.ai)](https://0g.ai/) · Observed 2026-10-23 · origin Every instance with its source is listed on the [instances page](/instances/). Our probe: seen on 519 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Pairs with: [AGENTS.md](/protocols/agents-md/), [Agent Readability Spec](/protocols/vercel-agent-readability/), [AI Catalog well-known file](/protocols/ai-catalog-well-known-file/), [NLWeb](/protocols/nlweb/), [AI Crawler User-Agent Tokens in robots.txt](/protocols/ai-crawler-tokens-robots/), [Agent Skills](/protocols/anthropic-agent-skills-format/) - [llms.txt](/terms/llms-txt-file/) - [Markdown twin](/terms/markdown-twin/) - [Context compaction](/terms/context-compaction/) - [Coding agent instruction files](/terms/coding-agent-instructions/) - Scanners & registries: [Agent Ready](https://agent-ready.dev/), [Agents Welcome — Agent Protocol Atlas](https://agentswelcome.dev/protocols), [CrawlIndex](https://crawlindex.org/), [llmstxt.org](https://llmstxt.org/), [Lumar Agentic Readiness Scanner](https://agentic-readiness.lumar.io/) ## Comparisons - [sitemap.xml vs llms.txt & ARD (classic vs agentic)](/compare/sitemap-xml-vs-llms-txt/) - [llms.txt vs AGENTS.md](/compare/llms-txt-vs-agents-md/) - [Agentic Resource Discovery vs llms.txt](/compare/ard-vs-llms-txt/) - [Agent Readability Spec vs llms.txt](/compare/vercel-agent-readability-vs-llms-txt/) - [llms.txt vs agents.txt](/compare/llms-txt-vs-agents-txt/) - [Open Knowledge Format vs llms.txt](/compare/okf-vs-llms-txt/) - [Markdown for Agents vs llms.txt](/compare/cloudflare-markdown-for-agents-vs-llms-txt/) - [Agent Skills vs llms.txt](/compare/anthropic-agent-skills-format-vs-llms-txt/) ## References - Full v2 proposal text: file grammar, discovery link relations (rel="alternate" type="text/markdown", rel="describedby"), relationship to robots.txt/sitemap.xml, and that AI labs (OpenAI, Anthropic, Gemini) publish llms.txt for their own docs — [https://llmstxt.org](https://llmstxt.org) (2026-08) VERIFIED - v2 (August 2026) changelog: adds standard link relations for discoverability, allows both `page.html.md` and `page.md` forms, defines what a subpath file covers, and drops the v1 context-expansion tooling and the mechanical meaning of the "Optional" section — [https://llmstxt.org/changes.html](https://llmstxt.org/changes.html) (2026-08) VERIFIED - Google's official Search Central guidance (last updated 2026-07-10) lists "LLMS.txt files and other 'special' markup" under things site owners can ignore, stating Google Search's generative AI features do not use them — [https://developers.google.com/search/docs/fundamentals/ai-optimization-guide](https://developers.google.com/search/docs/fundamentals/ai-optimization-guide) (2026-07-10) VERIFIED - 8.7% of the Tranco top-1,000 domains and 5.6% of the top-10,000 published a valid llms.txt file as of June 2026 — [https://www.rankability.com/data/llms-txt-adoption/](https://www.rankability.com/data/llms-txt-adoption/) (2026-06) REPORTED - Across a dataset of nearly 300,000 domains, 10.13% carried an llms.txt file, with adoption not concentrated among high-traffic sites (8.27% for 100,001+ visit sites vs 10.54% for mid-traffic sites) — [https://seranking.com/blog/llms-txt/](https://seranking.com/blog/llms-txt/) (2026) REPORTED - Analysis of 137,000 sites publishing llms.txt found 97% of the files were never fetched by any client in the observation window; of requests that did reach a file, 96% came from bots rather than identifiable AI assistants — [https://ahrefs.com/blog/llmstxt-study/](https://ahrefs.com/blog/llmstxt-study/) (2026) REPORTED - llms-txt Python package 0.0.7 released 2026-09-24 (tooling, spec unchanged at v2) — [https://github.com/AnswerDotAI/llms-txt/releases](https://github.com/AnswerDotAI/llms-txt/releases) (2026-09-24) REPORTED - 0.0.7 released 2026-09-24 — [https://github.com/AnswerDotAI/llms-txt/releases/tag/0.0.7](https://github.com/AnswerDotAI/llms-txt/releases/tag/0.0.7) (2026-09-24) VERIFIED Disputed: Publisher-side adoption (thousands of sites, roughly 8-10% of measured domain samples) is separate from and should not be conflated with consumption: no answer engine has documented reading llms.txt, Google explicitly says its generative AI features don't use it, and a large-scale log analysis found the great majority of published files are never fetched. [JSON](/data/protocols/llms-txt.json) · [Markdown](/protocols/llms-txt/index.md) · [OKF v0.2](/okf/protocols/llms-txt.md) --- # LMOS (Language Model Operating System) (/.well-known/wot-thing-description) LMOS (Language Model Operating System) is an agentic-web standard (document format — /.well-known/wot-thing-description) at step 1, Discover, governed by Eclipse Foundation open-source project; its status is "LMOS Protocol spec is explicitly work in progress and contains…". It answers: "How does an agent or tool from one organization describe itself and get discovered by agents from another organization…?" Replacing or extending UPnP / Matter device discovery, adapted to agents, implementation status is shipping, last verified 2026-10-23. ## Quick Wire Reference - **Step**: 1 Discover (What is here, and where?) - **Version**: LMOS Protocol v1 (draft, namespace https://eclipse.dev/lmos/protocol/v1) - **Status**: LMOS Protocol spec is explicitly "work in progress and contains empty… - **Discovery / Probe Path**: /.well-known/wot-thing-description — Three-layer protocol: Application layer defines a… - **Spec URL**: https://eclipse.dev/lmos/docs/lmos_protocol/introduction/ - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: UPnP / Matter device discovery, adapted to agents [Discover](/category/discover/) LMOS (Language Model Operating System) is an Eclipse Foundation open-source project that defines both a protocol and a cloud-native platform for building an "Internet of Agents" (IoA) — an internet-scale multi-agent system where agents and tools from different organizations can be published, discovered, and interconnected regardless of the technology they are built on [[1]](#ref-1). The LMOS Protocol itself is the discovery-and-description layer: it standardizes how an agent or tool describes its capabilities in JSON-LD (borrowing the W3C Web of Things Thing Description model), how that description propagates (DNS-SD/mDNS locally, agent registries globally), and how agents authenticate each other using W3C Decentralized Identifiers [[2]](#ref-2). ## Overview It solves cross-organization agent/tool discovery and description in a transport-agnostic way — the same agent description can be served over HTTP, MQTT, WebSocket or AMQP without changing application logic, echoing how Matter/Thread lets smart-home devices from different vendors interoperate and how ActivityPub lets different social platforms federate [[2]](#ref-2). It explicitly does not attempt to be a single fixed transport or wire format: transport selection and negotiation is left to a separate Transport Protocol Layer, and identity/security is a separate layer supporting both DIDs and conventional OAuth2/Bearer schemes [[2]](#ref-2). As of this check (September 2026), the LMOS Protocol specification is, in the project's own words, "work in progress and contains empty sections" and is explicitly "not a W3C Standard nor... on the W3C Standards Track," though the project states an intent to pursue formal W3C standardization once the spec matures [[2]](#ref-2). This is a meaningfully earlier stage than the platform around it: the surrounding Eclipse LMOS platform (LMOS Operator, Runtime, Router, and the Arc Kotlin DSL framework for building agents) is actively developed, with commits across its 15 repositories within days of this check [[3]](#ref-3). Governance sits with the Eclipse Foundation as an open-source project, with Apache License 2.0 code and Deutsche Telekom's engineering lineage visible in the top-committer history (the project descends from the same team behind openHAB) [[3]](#ref-3). Implementations exist — the LMOS Runtime, Operator, and Router are real, shipping Kotlin/Java components integrating with LangChain4j, LlamaIndex, and LangChain — but they are platform components rather than independent third-party implementations of the LMOS Protocol specifically, since the protocol's own spec is still incomplete. What is unresolved: how much of the described three-layer protocol is actually implemented end-to-end today versus aspirational, given the spec's own "empty sections" caveat, and whether any organization outside the Eclipse LMOS core contributor group has implemented LMOS-protocol-compliant discovery against a production deployment. ## Discovery and probe Three-layer protocol: Application layer defines a JSON-LD Agent/Tool Description Format (built on W3C Web of Things Thing Descriptions) plus DNS-SD/mDNS for local discovery and agent registries for global discovery; Identity layer uses W3C Decentralized Identifiers (DIDs) to sign description documents ``` GET {origin}/.well-known/wot-thing-description parse: A JSON-LD document whose @context or @type references the LMOS namespace (https://eclipse.dev/lmos/protocol/v1) confirms an LMOS-described Thing; this well-known path is the W3C WoT discovery convention LMOS explicitly builds on, not yet a path LMOS itself mandates. on absent: No response, or a WoT Thing Description without the LMOS namespace: this origin either doesn't participate in LMOS or (more likely for most origins) simply predates/ignores the still-draft protocol; the LMOS spec itself does not yet fix a single discovery path, so absence here is weak evidence. ``` Live check run by [the MCP probe](/mcp/server-card): GET /.well-known/wot-thing-description. An LMOS Thing Description references the LMOS namespace. ``` { "path": "/.well-known/wot-thing-description", "expect": { "text_match": "eclipse\\.dev/lmos" }, "note": "An LMOS Thing Description references the LMOS namespace." } ``` ## History - 2026-09-06 — added from arXiv 2504.16736 survey comparison, verified against eclipse.dev/lmos/, eclipse.dev/lmos/docs/lmos_protocol/introduction/, github.com/eclipse-lmos - 2026-10-16 — use-case tags (auto) ## Instances - [Deutsche Telekom Frag Magenta (Eclipse LMOS Agent)](https://eclipse.dev/lmos/) · Observed 2026-07-15 · agent Every instance with its source is listed on the [instances page](/instances/). Verified SDKs, reference implementations & validators: - [Arc (Kotlin DSL agent framework)](https://github.com/eclipse-lmos/arc) · sdk (2026-09-06) - [LMOS Runtime](https://github.com/eclipse-lmos/lmos-runtime) · implementation (2026-09-06) - [LMOS Operator (Kubernetes operator)](https://github.com/eclipse-lmos/lmos-operator) · implementation (2026-09-06) - [LMOS Router](https://github.com/eclipse-lmos/lmos-router) · implementation (2026-09-06) Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Pairs with: [Agent2Agent Protocol](/protocols/a2a/), [Model Context Protocol](/protocols/mcp/), [Open Agentic Schema Framework](/protocols/oasf/), [Agent Network Protocol](/protocols/anp/), [Agent Name Service v2 (ANS)](/protocols/ans/) ## References - LMOS is an open-source, vendor-neutral platform for multi-agent systems built on Kubernetes, aiming at an 'Internet of Agents' where agents/tools from different organizations can be published, discovered and interconnected; it is a project of the Eclipse Foundation. — [https://eclipse.dev/lmos/](https://eclipse.dev/lmos/) (2026-09-06) VERIFIED - The LMOS Protocol defines a three-layer architecture (Application/discovery+description, Transport, Identity+Security using W3C DIDs), is built on the W3C Web of Things architecture, and is explicitly stated by the project to be 'work in progress and contains empty sections' and 'not a W3C Standard nor on the W3C Standards Track.' — [https://eclipse.dev/lmos/docs/lmos_protocol/introduction/](https://eclipse.dev/lmos/docs/lmos_protocol/introduction/) (2026-09-06) VERIFIED - The eclipse-lmos GitHub organization maintains 15 repositories (LMOS Operator, Runtime, Router, Arc framework, etc.) with recent commit activity (within days of this check), licensed Apache 2.0. — [https://github.com/eclipse-lmos](https://github.com/eclipse-lmos) (2026-09-06) VERIFIED [JSON](/data/protocols/lmos.json) · [Markdown](/protocols/lmos/index.md) · [OKF v0.2](/okf/protocols/lmos.md) --- # LWS 1.0 Authentication Suite: Self-signed Identity using Controlled Identifiers (LWS-SSI-CID) LWS 1.0 Authentication Suite: Self-signed Identity using Controlled Identifiers (LWS-SSI-CID) is an agentic-web standard (document format) at step 2, Identify, governed by W3C Linked Web Storage Working Group, Recommendation track…; its status is "W3C Working Draft 15 October 2026". It answers: "How can an agent that signs its own JWT identity tokens authenticate to a Linked Web Storage server, with verifiers…?" Implementation status is none found, last verified 2026-10-23. ## Quick Wire Reference - **Step**: 2 Identify (Who is this agent? Who is this site?) - **Version**: W3C Working Draft (2026-10-15) - **Status**: W3C Working Draft 15 October 2026; published by the Linked Web Storage Working… - **Discovery / Probe Path**: The verifier dereferences the JWT sub claim (an HTTPS URI or DID URI) to fetch the controlled… - **Spec URL**: https://www.w3.org/TR/lws10-authn-ssi-cid/ - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: Self-issued OpenID-style JWT client authentication, where the public key is… [Identify](/category/identify/) Defines an authentication suite for the Linked Web Storage (LWS) protocol for agents that can sign their own identity tokens. The credential is a signed JWT in which sub, iss and client_id carry the same URI, with exp and iat required and alg none forbidden. Verifiers dereference the subject URI to get a W3C Controlled Identifier document and check the signature against the verification method matching the kid. It works with HTTPS URIs and DID URIs, and uses the token type urn:ietf:params:oauth:token-type:jwt. ## Discovery and probe The verifier dereferences the JWT sub claim (an HTTPS URI or DID URI) to fetch the controlled identifier document and selects a verification method by the JWT kid header. ``` NONE parse: on absent: Support cannot be observed passively. It would require an authenticated request to an LWS authorization server using a self-issued JWT. ``` Not probed live: no-fixed-path. candidate record; probe rule pending ## History - 2026-10-19 — auto-drafted candidate from exa (https://w3.org/TR/lws10-authn-ssi-cid) ## Instances Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also ## References - W3C Working Draft of 15 October 2026 defining an authentication suite for Linked Web Storage that lets clients sign their own identity tokens (JWT) validated through W3C Controlled Identifiers documents. — [https://www.w3.org/TR/lws10-authn-ssi-cid/](https://www.w3.org/TR/lws10-authn-ssi-cid/) (2026-10-15) REPORTED [JSON](/data/protocols/lws10-authn-ssi-cid.json) · [Markdown](/protocols/lws10-authn-ssi-cid/index.md) · [OKF v0.2](/okf/protocols/lws10-authn-ssi-cid.md) --- # Machine Payments Protocol (MPP) Machine Payments Protocol (MPP) is an agentic-web standard (HTTP header) at step 7, Pay, co-authored by Tempo and Stripe; its status is "Open protocol". It answers: "How can a machine client (an agent, script, or another server) pay for an HTTP resource using any payment network, not…?" Implementation status is multi-implementation, last verified 2026-10-23. ## Quick Wire Reference - **Step**: 7 Pay (Settle the bill) - **Version**: draft-httpauth-payment-01 (2026-09-09) - **Status**: Open protocol; developer docs distinguish the normative IETF specification… - **Discovery / Probe Path**: none — signalled per-request, no well-known file — HTTP 402 response carrying a… - **Spec URL**: https://datatracker.ietf.org/doc/html/draft-httpauth-payment-01 - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: A payment-method-agnostic HTTP 402 challenge/credential/receipt exchange [Pay](/category/pay/) The Machine Payments Protocol (MPP) standardizes HTTP 402 "Payment Required" as an extensible, payment-network-agnostic machine-to-machine payment flow: a client requests a resource, the server issues a 402 challenge with WWW-Authenticate: Payment, the client fulfills the payment (signing a transaction, paying an invoice, or completing a card charge depending on the method) and retries with Authorization: Payment, and the server verifies and serves the resource with an optional Payment-Receipt header [[1]](#ref-1). It solves the same core problem as x402 and L402 — metered, account-free API access for agents and machines — but is explicitly designed to be method-agnostic: the same core Challenge/Credential/Receipt shape can carry Tempo, EVM, Stripe Card, Lightning, Solana, Stellar, Monad, or NEAR Intents payments [[1]](#ref-1)[[3]](#ref-3). ## Overview It does not itself pick a payment network or currency: the core specification "makes no claims or affordances to any specific payment method" and is designed to work with any rail [[2]](#ref-2). MPP is precise about status-code semantics in a way that differs from typical HTTP auth schemes — it uses 402 consistently for all payment-related failures (a fresh challenge, a malformed credential, an expired challenge, or a failed verification), reserving 401 for authentication failures unrelated to payment and 403 for cases where a valid payment was made but policy still denies access [[1]](#ref-1). MPP's governance is deliberately split in two: the core specification is co-authored by Tempo and Stripe and has been submitted to the IETF standards track under the name "Payment HTTP Authentication Scheme," while individual payment methods are maintained separately by whoever supports that rail, which the project says "keeps the protocol neutral while letting payment rails move at their own pace" [[2]](#ref-2). On the IETF Datatracker, the specification is published as the individual Internet-Draft draft-httpauth-payment-01 (dated 2026-09-09, replacing -00) [[4]](#ref-4). SDKs exist for TypeScript, Go, Ruby, Rust, and Python per the project's own site, and MPP maintains a direct compatibility/comparison page against x402 [[3]](#ref-3). No independent adoption count was found; adoption is recorded as unmeasured. ## Discovery and probe HTTP 402 response carrying a WWW-Authenticate: Payment challenge · none — signalled per-request, no well-known file ``` GET {origin}/{paid-path} parse: HTTP 402 status with a WWW-Authenticate: Payment ... challenge header; a subsequent authorized retry returns 200 with a Payment-Receipt header on absent: A 200, 401, or a 402 without a Payment-scheme WWW-Authenticate header means this path is not gated by MPP; MPP also has MCP/JSON-RPC and WebSocket transport bindings, so an HTTP-only probe cannot rule out MPP support offered solely over those transports. ``` Not probed live: no-fixed-path. MPP challenges appear only on paid URLs. ## History - 2026-09-05 — seeded from Exa Agent research run - 2026-09-06 — verified against mpp.dev (homepage, /protocol, /governance) - 2026-10-16 — The MPP draft was renamed draft-httpauth-payment; draft-httpauth-payment-01 is dated 2026-09-09 - 2026-10-16 — use-case tags (auto) - 2026-10-16 — version spec-artifacts-fe0d414f3d71469d5784a2ce973aa7269ee0c8b7 (watcher) - 2026-10-16 — version label restored to 'draft-httpauth-payment-01'; the repository's latest tag (spec-artifacts-fe0d414f3d71469d5784a2ce973aa7269ee0c8b7) is a package, SDK or build tag, not the specification version, so the GitHub watch no longer drives version ## Instances - [Stripe and Tempo Machine Payments Protocol (MPP) Directory](https://mpp.dev) · Observed 2026-09-04 · venue - [Privy (by Stripe) Agent and Server Wallets](https://privy.io) · Observed 2026-09-04 · authority - [pay.sh (Agent Payment CLI and Runtime)](https://pay.sh) · Observed 2026-09-04 · harness Every instance with its source is listed on the [instances page](/instances/). Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Pairs with: [x402](/protocols/x402/), [L402](/protocols/l402/), [HTTP Message Signatures](/protocols/http-message-signatures/), [Agent Payments Protocol](/protocols/ap2/), [Agentic Commerce Protocol](/protocols/agentic-commerce-protocol/), [Cloudflare Pay per crawl](/protocols/cloudflare-pay-per-crawl/) - [x402](/protocols/x402/) - [L402](/protocols/l402/) - [s402](/protocols/s402/) - [Cloudflare Pay per crawl](/protocols/cloudflare-pay-per-crawl/) - [HTTP 402 Payment Required](/terms/http-402-payment-required/) - [Idempotency-Key header](/terms/idempotency-key/) - [Buyer of Record & Merchant of Record (Agentic Commerce)](/terms/buyer-of-record/) - Scanners & registries: [The Agent Almanac](https://agentalmanac.org/) ## Comparisons - [API Keys & Subscriptions vs x402 & MPP (HTTP 402) (classic vs agentic)](/compare/api-keys-vs-x402/) - [x402 vs Machine Payments Protocol](/compare/x402-vs-mpp/) - [Cloudflare Pay per crawl vs Machine Payments Protocol](/compare/cloudflare-pay-per-crawl-vs-mpp/) - [L402 vs Machine Payments Protocol](/compare/l402-vs-mpp/) - [Machine Payments Protocol vs s402](/compare/mpp-vs-s402/) ## References - MPP's protocol overview documents the flow as: client GETs a resource, server returns 402 with WWW-Authenticate: Payment, client retries with Authorization: Payment, server verifies and responds 200 with a Payment-Receipt header — and explicitly uses 402 (not 401) even for failed credential verification, reserving 401 for authentication failures unrelated to payment and 403 for policy denial after a valid payment. — [https://mpp.dev/protocol](https://mpp.dev/protocol) VERIFIED - MPP's Governance page states the protocol is co-authored by Tempo and Stripe, is 'neutral by design' and operates independently of any single company, payment method, or rail, and splits governance between the core specification (submitted to the IETF standards track as the Payment HTTP Authentication Scheme) and separately maintained payment methods. — [https://mpp.dev/governance](https://mpp.dev/governance) VERIFIED - mpp.dev's homepage lists SDKs across TypeScript (mppx), Go, Ruby, Rust, and Python, plus a comparison page contrasting MPP with x402, and blog posts describing added EVM and x402-exact-flow support as of June 2026. — [https://mpp.dev](https://mpp.dev) (2026-08-12) VERIFIED - The MPP draft was renamed draft-httpauth-payment; draft-httpauth-payment-01 is dated 2026-09-09 — [https://datatracker.ietf.org/doc/draft-httpauth-payment/](https://datatracker.ietf.org/doc/draft-httpauth-payment/) (2026-09-09) VERIFIED - spec-artifacts-fe0d414f3d71469d5784a2ce973aa7269ee0c8b7 released 2026-09-09 — [https://github.com/tempoxyz/mpp-specs/releases/tag/spec-artifacts-fe0d414f3d71469d5784a2ce973aa7269ee0c8b7](https://github.com/tempoxyz/mpp-specs/releases/tag/spec-artifacts-fe0d414f3d71469d5784a2ce973aa7269ee0c8b7) (2026-10-15) VERIFIED [JSON](/data/protocols/mpp.json) · [Markdown](/protocols/mpp/index.md) · [OKF v0.2](/okf/protocols/mpp.md) --- # Markdown for Agents (Accept: text/markdown) Markdown for Agents is an agentic-web standard (HTTP header — Accept: text/markdown) at step 4, Read, governed by Cloudflare; its status is "Vendor feature, available to Pro, Business and Enterprise plans…". It answers: "Can an agent ask a site for a Markdown version of an HTML page, instead of parsing the HTML itself?" Implementation status is shipping (Cloudflare's own developer docs and blog answer…; observed on 214/1226 probed origins), last verified 2026-10-23. ## Quick Wire Reference - **Step**: 4 Read (Give me the content) - **Version**: Generally available on Pro, Business and Enterprise plans; docs last updated… - **Status**: Vendor feature, available to Pro, Business and Enterprise plans and SSL for… - **Discovery / Probe Path**: HTTP content negotiation: the client sends Accept: text/markdown and an enabled zone answers… - **Spec URL**: https://developers.cloudflare.com/fundamentals/reference/markdown-for-agents/ - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: HTTP content negotiation (as used for languages and image formats), applied to… [Read](/category/read/) Markdown for Agents is a Cloudflare network feature: when an agent requests a page with Accept: text/markdown, an enabled zone fetches the HTML from the origin, converts it to Markdown at the edge and returns it as text/markdown with Vary: Accept, so caches keep the HTML and Markdown variants apart [[1]](#ref-1). The output has a fixed layout: optional YAML frontmatter built from the page's title, description and og:image meta tags, the body with navigation, scripts and styles stripped, and any JSON-LD kept in a fenced block at the end [[1]](#ref-1). Only HTML is converted, up to 6 MiB [[1]](#ref-1). ## Overview It is a vendor feature, not a standard: any server can do the same content negotiation, and Vercel's Agent Readability Spec lists Accept: text/markdown as one of its checks. Cloudflare's version is free on Pro, Business and Enterprise plans and for SSL for SaaS, and is switched on in AI Crawl Control, per path or host by a Configuration Rule, or through the content_converter zone setting [[1]](#ref-1). Cloudflare launched it on 2026-02-12 and serves its own docs and blog this way [[2]](#ref-2)[[3]](#ref-3). Two details matter. First, if the origin sends no content-signal header, Cloudflare adds Content-Signal: ai-train=yes, search=yes, ai-input=yes to the converted response [[1]](#ref-1)[[3]](#ref-3), so a site that turns the feature on without setting its own header advertises consent to every use the Content Signals Policy names. Second, the launch post describes an x-markdown-tokens header with an estimated token count [[2]](#ref-2), but the current docs do not mention it and our check on 2026-10-20 did not receive it [[3]](#ref-3). ## Discovery and probe HTTP content negotiation: the client sends Accept: text/markdown and an enabled zone answers with Content-Type: text/markdown; charset=utf-8 and Vary: Accept. There is no manifest or well-known file. ``` GET {origin}/ (request header Accept: text/markdown) parse: Content-Type is text/markdown; a Content-Signal response header is present (Cloudflare adds ai-train=yes, search=yes, ai-input=yes when the origin sets none); an x-markdown-tokens header is described in the launch post but was not returned in our 2026-10-20 check on absent: An HTML response means the zone has not turned the feature on, or is not on Cloudflare; the site may still offer Markdown by other means, such as .md mirrors or llms.txt ``` Not probed live: no-fixed-path. Needs an Accept: text/markdown request header on any page; although skipped in static rule evaluation, probe, has, and validate_manifest observe it live on GET / with Accept: text/markdown. ## History - 2026-10-20 — added from gap scout 2026-10-20; verified against developers.cloudflare.com/fundamentals/reference/markdown-for-agents/ (updated 2026-10-09), blog.cloudflare.com/markdown-for-agents/ (2026-02-12) and our own Accept: text/markdown requests on 2026-10-20 ## Instances - [Zuplo API Gateway (zuplo.com)](https://zuplo.com/) · Observed 2026-10-25 · origin - [Zep Long-Term Agent Memory (getzep.com)](https://getzep.com/) · Observed 2026-10-25 · origin - [Zapier (zapier.com)](https://zapier.com/) · Observed 2026-10-25 · origin - [Webflow Developers (developers.webflow.com)](https://developers.webflow.com/) · Observed 2026-10-25 · origin - [Vercel v0 Generative UI (v0.app)](https://v0.app/) · Observed 2026-10-25 · origin - [Vellum AI Workflow Platform (vellum.ai)](https://vellum.ai/) · Observed 2026-10-25 · origin - [Vast.ai (vast.ai)](https://vast.ai/) · Observed 2026-10-25 · origin - [Taskade (taskade.com)](https://taskade.com/) · Observed 2026-10-25 · origin - [SurrealDB (surrealdb.com)](https://surrealdb.com/) · Observed 2026-10-25 · origin - [Supermemory (supermemory.ai)](https://supermemory.ai/) · Observed 2026-10-25 · origin - [Supabase (supabase.com)](https://supabase.com/) · Observed 2026-10-25 · origin - [StackOne Agentic Integration Hub (stackone.com)](https://stackone.com/) · Observed 2026-10-25 · origin - [Speakeasy (speakeasy.com)](https://speakeasy.com/) · Observed 2026-10-25 · origin - [Skyvern Browser Automation Agent (skyvern.com)](https://skyvern.com/) · Observed 2026-10-25 · origin - [Sentry (sentry.io)](https://sentry.io/) · Observed 2026-10-25 · origin - [Scalar API Platform (scalar.com)](https://scalar.com/) · Observed 2026-10-25 · origin - [Sanity Content Operating System (sanity.io)](https://sanity.io/) · Observed 2026-10-25 · origin - [RunPod GPU Cloud (runpod.io)](https://runpod.io/) · Observed 2026-10-25 · origin - [Replicate (replicate.com)](https://replicate.com/) · Observed 2026-10-25 · origin - [Reducto Document AI (reducto.ai)](https://reducto.ai/) · Observed 2026-10-25 · origin - [React Email by Resend (react.email)](https://react.email/) · Observed 2026-10-25 · origin - [Pydantic & Logfire (pydantic.dev)](https://pydantic.dev/) · Observed 2026-10-25 · origin - [Prisma ORM & Postgres (prisma.io)](https://prisma.io/) · Observed 2026-10-25 · origin - [Podscan Podcast Intelligence API (podscan.fm)](https://podscan.fm/) · Observed 2026-10-25 · origin - [PlanetScale (planetscale.com)](https://planetscale.com/) · Observed 2026-10-25 · origin - [Plane (plane.so)](https://plane.so/) · Observed 2026-10-25 · origin - [Perplexity API Docs (docs.perplexity.ai)](https://docs.perplexity.ai/) · Observed 2026-10-25 · origin - [OpenStatus (openstatus.dev)](https://openstatus.dev/) · Observed 2026-10-25 · origin - [Novita AI (novita.ai)](https://novita.ai/) · Observed 2026-10-25 · origin - [MotherDuck Serverless DuckDB (motherduck.com)](https://motherduck.com/) · Observed 2026-10-25 · origin - [Morph Fast Apply LLM (morphllm.com)](https://morphllm.com/) · Observed 2026-10-25 · origin - [Model Context Protocol Docs (modelcontextprotocol.io)](https://modelcontextprotocol.io/) · Observed 2026-10-25 · origin - [Mintlify (mintlify.com)](https://mintlify.com/) · Observed 2026-10-25 · origin - [Lago (getlago.com)](https://getlago.com/) · Observed 2026-10-25 · origin - [Kent C. Dodds (kentcdodds.com)](https://kentcdodds.com/) · Observed 2026-10-25 · origin - [Infisical Secrets Management (infisical.com)](https://infisical.com/) · Observed 2026-10-25 · origin - [Hostinger (hostinger.com)](https://hostinger.com/) · Observed 2026-10-25 · origin - [Fly.io (fly.io)](https://fly.io/) · Observed 2026-10-25 · origin - [Eodly (eodly.io)](https://eodly.io/) · Observed 2026-10-25 · origin - [Devin Origin (devin.ai)](https://devin.ai/) · Observed 2026-10-25 · origin - [Descope Identity & Agent Auth (descope.com)](https://descope.com/) · Observed 2026-10-25 · origin - [DC Hub (dchub.cloud)](https://dchub.cloud/) · Observed 2026-10-25 · origin - [Customer.io (customer.io)](https://customer.io/) · Observed 2026-10-25 · origin - [crewai.com](https://crewai.com/) · Observed 2026-10-25 · origin - [Convex Reactive Backend (convex.dev)](https://convex.dev/) · Observed 2026-10-25 · origin - [Checkly Synthetic Monitoring (checklyhq.com)](https://checklyhq.com/) · Observed 2026-10-25 · origin - [Cal.com Scheduling Infrastructure (cal.com)](https://cal.com/) · Observed 2026-10-25 · origin - [Bird (bird.com)](https://bird.com/) · Observed 2026-10-25 · origin - [Better Stack Observability (betterstack.com)](https://betterstack.com/) · Observed 2026-10-25 · origin - [beehiiv Newsletter Platform (beehiiv.com)](https://beehiiv.com/) · Observed 2026-10-25 · origin - [Baseten Docs (docs.baseten.co)](https://docs.baseten.co/) · Observed 2026-10-25 · origin - [Augment Code Docs (docs.augmentcode.com)](https://docs.augmentcode.com/) · Observed 2026-10-25 · origin - [Attio Docs (docs.attio.com)](https://docs.attio.com/) · Observed 2026-10-25 · origin - [Atlan (atlan.com)](https://atlan.com/) · Observed 2026-10-25 · origin - [Arcade AI Tool-Calling Runtime (arcade.dev)](https://arcade.dev/) · Observed 2026-10-25 · origin - [Apideck Unified API (apideck.com)](https://apideck.com/) · Observed 2026-10-25 · origin - [Amplitude (amplitude.com)](https://amplitude.com/) · Observed 2026-10-25 · origin - [Agent Skills Specification (agentskills.io)](https://agentskills.io/) · Observed 2026-10-25 · origin - [Agent Client Protocol (agentclientprotocol.com)](https://agentclientprotocol.com/) · Observed 2026-10-25 · origin - [AG-UI Documentation Origin (docs.ag-ui.com)](https://docs.ag-ui.com/) · Observed 2026-10-25 · origin - [Ad Context Protocol Docs (docs.adcontextprotocol.org)](https://docs.adcontextprotocol.org/) · Observed 2026-10-25 · origin - [x402 Foundation Spec Origin (x402.org)](https://x402.org/) · Observed 2026-10-23 · origin - [Vercel (vercel.com)](https://vercel.com/) · Observed 2026-10-23 · origin - [Tempo (tempo.xyz)](https://tempo.xyz/) · Observed 2026-10-23 · origin - [Telnyx (telnyx.com)](https://telnyx.com/) · Observed 2026-10-23 · origin - [Stripe Documentation (docs.stripe.com)](https://docs.stripe.com/) · Observed 2026-10-23 · origin - [Resend (resend.com)](https://resend.com/) · Observed 2026-10-23 · origin - [Railway (railway.com)](https://railway.com/) · Observed 2026-10-23 · origin - [QuickNode (quicknode.com)](https://quicknode.com/) · Observed 2026-10-23 · origin - [Proof (proof.com)](https://proof.com/) · Observed 2026-10-23 · origin - [openknowledge.ai](https://openknowledge.ai/) · Observed 2026-10-23 · origin - [okta.com](https://okta.com/) · Observed 2026-10-23 · origin - [Next.js (nextjs.org)](https://nextjs.org/) · Observed 2026-10-23 · origin - [Neon Serverless Postgres (neon.com)](https://neon.com/) · Observed 2026-10-23 · origin - [n8n Documentation Origin (docs.n8n.io)](https://docs.n8n.io/) · Observed 2026-10-23 · origin - [mastra.ai](https://mastra.ai/) · Observed 2026-10-23 · origin - [Loops (loops.so)](https://loops.so/) · Observed 2026-10-23 · origin - [IMG.LY (img.ly)](https://img.ly/) · Observed 2026-10-23 · origin - [GitBook (gitbook.com)](https://gitbook.com/) · Observed 2026-10-23 · origin - [getdbt.com](https://getdbt.com/) · Observed 2026-10-23 · origin - [Firecrawl (firecrawl.dev)](https://firecrawl.dev/) · Observed 2026-10-23 · origin - [factory.com](https://factory.com/) · Observed 2026-10-23 · origin - [Elsevier (elsevier.com)](https://elsevier.com/) · Observed 2026-10-23 · origin - [docs.github.com](https://docs.github.com/) · Observed 2026-10-23 · origin - [Cloudflare (cloudflare.com)](https://cloudflare.com/) · Observed 2026-10-23 · origin - [ClickHouse (clickhouse.com)](https://clickhouse.com/) · Observed 2026-10-23 · origin - [circle.com](https://circle.com/) · Observed 2026-10-23 · origin - [blog.cloudflare.com](https://blog.cloudflare.com/) · Observed 2026-10-23 · origin - [Asana (asana.com)](https://asana.com/) · Observed 2026-10-23 · origin - [Apify (apify.com)](https://apify.com/) · Observed 2026-10-23 · origin - [agenticweb.wiki Reference Agent and MCP Server](https://agenticweb.wiki) · Observed 2026-10-23 · agent - [Agentic AI Foundation (aaif.io)](https://aaif.io/) · Observed 2026-10-23 · origin - [agent-ready.dev Conformance Scanner Agent](https://agent-ready.dev) · Observed 2026-10-23 · agent - [0G Labs (0g.ai)](https://0g.ai/) · Observed 2026-10-23 · origin Every instance with its source is listed on the [instances page](/instances/). Our probe: seen on 214 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Pairs with: [Content Signals Policy](/protocols/cloudflare-content-signals-policy/), [llms.txt](/protocols/llms-txt/), [Agent Readability Spec](/protocols/vercel-agent-readability/), [AI Crawler User-Agent Tokens in robots.txt](/protocols/ai-crawler-tokens-robots/) - [Markdown twin](/terms/markdown-twin/) - [Context compaction](/terms/context-compaction/) ## Comparisons - [HTML DOM & RSS vs Accept: text/markdown & OKF (classic vs agentic)](/compare/html-dom-vs-markdown-for-agents/) - [Open Knowledge Format vs Markdown for Agents](/compare/okf-vs-cloudflare-markdown-for-agents/) - [Markdown for Agents vs llms.txt](/compare/cloudflare-markdown-for-agents-vs-llms-txt/) - [Markdown for Agents vs Agent Readability Spec](/compare/cloudflare-markdown-for-agents-vs-vercel-agent-readability/) ## References - Cloudflare's docs page (last updated 2026-10-09) says a client that sends Accept: text/markdown to an enabled zone gets the HTML converted at the edge, with Content-Type: text/markdown; charset=utf-8 and Vary: Accept. Output is optional YAML frontmatter from meta tags, the body as Markdown, and any JSON-LD in a fenced json block. Only HTML is converted, up to 6 MiB. When the origin sends no content-signal header, Cloudflare adds Content-Signal: ai-train=yes, search=yes, ai-input=yes. It is enabled in AI Crawl Control, by a Configuration Rule, or via PATCH /zones/{zone_tag}/settings/content_converter, and is free on Pro, Business, Enterprise and SSL for SaaS. — [https://developers.cloudflare.com/fundamentals/reference/markdown-for-agents/](https://developers.cloudflare.com/fundamentals/reference/markdown-for-agents/) (2026-10-09) VERIFIED - The launch post (datePublished 2026-02-12) introduces the feature and says converted responses carry an x-markdown-tokens header with the estimated token count of the Markdown document. — [https://blog.cloudflare.com/markdown-for-agents/](https://blog.cloudflare.com/markdown-for-agents/) (2026-02-12) VERIFIED - Our own request on 2026-10-20 to this post and to the docs page with Accept: text/markdown returned HTTP 200, content-type: text/markdown; charset=utf-8 and content-signal: ai-train=yes, search=yes, ai-input=yes, and no x-markdown-tokens header. — [https://blog.cloudflare.com/markdown-for-agents/](https://blog.cloudflare.com/markdown-for-agents/) (2026-10-20) VERIFIED Disputed: The token-count header promised at launch is not in the current docs and was not returned in our check, so agents should not rely on it. The feature also attaches a permissive Content-Signal by default, which a site owner may not expect from a format-conversion switch. [JSON](/data/protocols/cloudflare-markdown-for-agents.json) · [Markdown](/protocols/cloudflare-markdown-for-agents/index.md) · [OKF v0.2](/okf/protocols/cloudflare-markdown-for-agents.md) --- # MCP Apps MCP Apps is an agentic-web standard (endpoint) at step 8, Present, governed by modelcontextprotocol GitHub org; its status is "Active extension to MCP". It answers: "How does an MCP tool deliver an interactive UI (chart, form, dashboard) that renders inline in a chat client?" Implementation status is multi-implementation, last verified 2026-10-23. ## Quick Wire Reference - **Step**: 8 Present (Show a human the result) - **Version**: v2.0.3 (2026-09-25) - **Status**: Active extension to MCP; own repo describes it as extending 'the Model Context… - **Discovery / Probe Path**: ui:// (declared per-tool, not a fixed site-wide path) — A tool's definition… - **Spec URL**: https://github.com/modelcontextprotocol/ext-apps/blob/main/specification/2026-01-26/apps.mdx - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: An iframe-embedded widget returned by a web API, rendered inline by the calling app [Present](/category/present/) MCP Apps is an extension to the Model Context Protocol (MCP) that lets an MCP server's tools declare an interactive UI — a chart, form, dashboard, or design canvas — that a compliant chat client renders inline, in the conversation, rather than as plain text or structured JSON. A tool definition declares a ui:// resource containing bundled HTML/JavaScript; when the LLM calls the tool, the host fetches that resource over the ordinary MCP resources/read call and displays it in a sandboxed iframe; a bidirectional channel then lets the host push tool data into the UI via notifications and lets the UI call other MCP tools through the host [[1]](#ref-1). It solves the specific gap that 'MCP tools return text and structured data... but not... an interactive UI' [[1]](#ref-1), and it explicitly targets the same problem A2UI and AG-UI's generative-UI feature address, but scoped to MCP-native tool calls rather than a general-purpose agent-to-frontend event stream. ## Overview It does not define a new transport (it rides on ordinary MCP JSON-RPC), does not specify how a host discovers that a server supports it beyond ordinary MCP capability negotiation and per-tool ui:// metadata, and does not address payment, identity, or non-MCP agent frameworks. Current state (as of 2026-09-05): the canonical repository is github.com/modelcontextprotocol/ext-apps, Apache-2.0 licensed, with a dated spec file at specification/2026-01-26/apps.mdx and a companion blog post on blog.modelcontextprotocol.io dated 2026-01-26 announcing it. The repo shows sustained activity (666 commits, latest merge 2026-08-12, 2.8k stars) and ships an official npm package (@modelcontextprotocol/ext-apps, at v2.0.3 as of 2026-09-25) plus a React binding and a server-helpers package. The repo's own README lists ChatGPT, Claude, and VS Code as supported clients, each with first-party integration docs, which is stronger implementation evidence than a single reference build [[1]](#ref-1). A separate, earlier community project, MCP-UI (github.com/idosal/mcp-ui, now under the MCP-UI-Org), predates MCP Apps and originally proposed its own ui:///ui-app:// resource convention starting around April 2025; it has since repositioned itself explicitly as 'an SDK implementing the MCP Apps standard,' with a legacy rendering path kept only for pre-standard MCP-UI hosts [[2]](#ref-2). The ext-apps repo itself credits MCP-UI's client as 'a fully-featured MCP Apps framework used by a few hosts,' alongside the possibility that a client rolls its own implementation. What is disputed or unknown: this is a new record on agenticweb.wiki, not previously tracked, so there is no prior baseline to compare against. Its governance track is marked 'community' here because the ext-apps repo, while living under the modelcontextprotocol GitHub org, is an 'ext-' (extension) project and it is not yet confirmed whether it has been formally folded into the same Agentic AI Foundation/Linux Foundation governance this site's core mcp record cites — that should be checked against MCP's own governance documents on a future pass. No independent, counted adoption figure exists; the evidence here is qualitative (named supported clients, repo activity), not a probe-based census. ## Discovery and probe A tool's definition declares a ui:// resource; the host fetches it via the standard MCP resources/read call after a tool call, rather than via a separate well-known path · ui:// (declared per-tool, not a fixed site-wide path) ``` POST {mcp-endpoint} — call tools/list then tools/call on a known MCP server, per JSON-RPC parse: Tool definition metadata includes a ui:// resource reference (or _meta.ui.resourceUri); a follow-up resources/read on that URI returns a resource with mimeType text/html (optionally ;profile=mcp-app) on absent: Server exposes ordinary MCP tools with text/structured-data results only; no interactive UI capability ``` Not probed live: no-fixed-path. MCP Apps are declared inside an MCP server's tools/list; find the server first. ## History - 2026-09-06 — new record: verified against github.com/modelcontextprotocol/ext-apps, its dated spec file, and github.com/MCP-UI-Org/mcp-ui; found via search for other agent-rendered-UI specs during A2UI/AG-UI verification - 2026-10-16 — MCP Apps SDK ext-apps v2.0.3 was released on 2026-09-25 (spec dated 2026-01-26) - 2026-10-16 — use-case tags (auto) - 2026-10-16 — version v2.0.3 (watcher) ## Instances - [CopilotKit](https://www.copilotkit.ai) · Observed 2026-08-14 · harness Every instance with its source is listed on the [instances page](/instances/). Verified SDKs, reference implementations & validators: - [@modelcontextprotocol/ext-apps (app, react, app-bridge, server packages)](https://github.com/modelcontextprotocol/ext-apps) · sdk (2026-09-05) - [mcp-ui-server (Python) and mcp_ui_server (Ruby)](https://github.com/MCP-UI-Org/mcp-ui) · sdk (2026-09-05) Our probe: seen on 0 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Builds on: [Model Context Protocol](/protocols/mcp/) - Pairs with: [Model Context Protocol](/protocols/mcp/), [A2UI (Agent to UI) Protocol](/protocols/a2ui/), [Agent-User Interaction Protocol](/protocols/ag-ui/), [Official MCP Registry](/protocols/mcp-registry/), [OpenAI Plugins (formerly Apps SDK)](/protocols/openai-apps-sdk-manifests/), [WebMCP](/protocols/webmcp/) - [Generative UI](/terms/generative-ui/) - Not to be confused with: MCP-UI (a separately-branded client SDK that implements this spec) ## Comparisons - [Iframes & Server-Driven UI vs MCP Apps, AG-UI & A2UI (classic vs agentic)](/compare/iframes-vs-mcp-apps/) - [MCP Apps vs OpenAI Plugins (formerly Apps SDK)](/compare/mcp-apps-vs-openai-apps-sdk-manifests/) - [MCP Apps vs Agent-User Interaction Protocol](/compare/mcp-apps-vs-ag-ui/) - [MCP Apps vs A2UI (Agent to UI) Protocol](/compare/mcp-apps-vs-a2ui/) ## References - Canonical repo github.com/modelcontextprotocol/ext-apps (Apache-2.0 license, 2.8k stars, 666 commits, latest commit 2026-08-12): 'MCP Apps extend the Model Context Protocol by letting tools declare UI resources' via a 4-step flow (tool definition, tool call, host renders in a sandboxed iframe, bidirectional communication via notifications/tool calls). Spec file at specification/2026-01-26/apps.mdx. Supported clients listed in the repo's badges/table include ChatGPT, Claude, and VS Code, each linking to first-party docs for building MCP Apps in that client. — [https://github.com/modelcontextprotocol/ext-apps](https://github.com/modelcontextprotocol/ext-apps) (2026-09-05) VERIFIED - MCP-UI (github.com/MCP-UI-Org/mcp-ui) describes itself as 'an SDK implementing the MCP Apps standard for UI over MCP,' offering a client (@mcp-ui/client) that can render via the MCP Apps AppRenderer or via a legacy UIResourceRenderer for pre-standard MCP-UI hosts — evidence that MCP Apps formalized and superseded an earlier, informally-specified MCP-UI proposal from mid-2025. — [https://github.com/MCP-UI-Org/mcp-ui](https://github.com/MCP-UI-Org/mcp-ui) (2026-09-05) VERIFIED - MCP Apps SDK ext-apps v2.0.3 was released on 2026-09-25 (spec dated 2026-01-26) — [https://github.com/modelcontextprotocol/ext-apps/releases](https://github.com/modelcontextprotocol/ext-apps/releases) (2026-09-25) VERIFIED - v2.0.3 released 2026-09-25 — [https://github.com/modelcontextprotocol/ext-apps/releases/tag/v2.0.3](https://github.com/modelcontextprotocol/ext-apps/releases/tag/v2.0.3) (2026-09-25) VERIFIED [JSON](/data/protocols/mcp-apps.json) · [Markdown](/protocols/mcp-apps/index.md) · [OKF v0.2](/okf/protocols/mcp-apps.md) --- # MCP Server Cards (SEP-2127) (/mcp/server-card) MCP Server Cards (SEP-2127) is an agentic-web standard (document format — /mcp/server-card) at step 1, Discover, governed by Model Context Protocol project; its status is "SEP-2127 Final, Extensions Track charter". It answers: "How can a client learn what an MCP server offers before connecting to it?" Replacing or extending A2A Agent Card, for MCP servers, implementation status is multi-implementation (observed on 131/1226 probed origins), last verified 2026-10-23. ## Quick Wire Reference - **Step**: 1 Discover (What is here, and where?) - **Version**: SEP-2127 (Final) (2026-10-06) - **Status**: SEP-2127 Final (2026-10-06), Extensions Track charter; the MCP Registry… - **Discovery / Probe Path**: GET /server-card — An AI Catalog at /.well-known/ai-catalog.json.… - **Spec URL**: https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/seps/2127-mcp-server-cards.md - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: A2A Agent Card, for MCP servers [Discover](/category/discover/) An MCP Server Card is a static JSON description of an MCP server that a client can fetch before connecting. It is specified in SEP-2127, which reached Final on 2026-10-06 [[1]](#ref-1). ## Overview The MCP Registry working group is aligning the registry's server.json schema with the Server Card [[2]](#ref-2). SEP-2127 reserves GET /server-card and leaves domain-level discovery to AI Catalog entries; GitHub (api.githubcopilot.com/mcp/server-card, linked from its AI Catalog) and Hugging Face (huggingface.co/mcp/server-card) serve conformant cards there. A different, unofficial convention has also appeared: on 2026-10-20 Zapier, Proof, Coinbase, Cloudflare, Sentry and Twilio all served JSON at /.well-known/mcp/server-card.json, a path the SEP does not define. None used the v1 server-card $schema; three were card-shaped (two following the registry's server.json) and three were ad hoc. The working group page still calls Server Cards experimental, while the SEP is marked Final, so the status here is candidate until the specification release that includes it. SEP-2127 is an Extensions Track charter, merged on 2026-10-06 [[7]](#ref-7). The SEP text is the charter. The normative wire format lives in the server-card extension repository, pinned at review to snapshot 526201bb [[8]](#ref-8). Discovery is an AI Catalog at /.well-known/ai-catalog.json. The reserved card location is GET /server-card, media type application/mcp-server-card+json. Cards carry identity, transports, and protocol versions. They do not carry tools. /.well-known/mcp.json is the earlier SEP-1649 shape. When the static card and a live server/discover response disagree, the live call wins [[7]](#ref-7). ## Discovery and probe An AI Catalog at /.well-known/ai-catalog.json. SEP-2127 (Final 2026-10-06) is an Extensions Track charter; the normative wire format lives in the server-card extension repository (snapshot 526201bb at review). /.well-known/mcp.json is the earlier SEP-1649 shape. · GET /server-card ``` GET {endpoint}/server-card parse: A JSON document served as application/mcp-server-card+json at GET /server-card, the location SEP-2127 (Final, Extensions Track) reserves. The card carries identity, transports, and protocol versions, and does not carry tools. The normative wire format lives in the server-card extension repository. When this static card and a live server/discover response disagree, the live call wins. on absent: 404 or non-JSON means no Server Card is published at the SEP-2127 location; the server may still be a working MCP server. Discovery is via /.well-known/ai-catalog.json. /.well-known/mcp.json is the earlier SEP-1649 shape. ``` Not probed live: no-fixed-path. SEP-2127 reserves GET /server-card as application/mcp-server-card+json. Although not a single fixed path in the static rule engine, probe, has, and validate_manifest check /mcp/server-card, /.well-known/mcp/server-card.json, and /.well-known/mcp.json live. ## History - 2026-10-15 — curated update 2026-10-15 - 2026-10-16 — use-case tags (auto) - 2026-10-16 — version 2026-07-28 (watcher) - 2026-10-16 — version label restored to 'SEP-2127 (Final)'; the repository tag 2026-07-28 is the MCP specification repository's revision tag, not the Server Card SEP, so the GitHub watch no longer drives version - 2026-10-20 — location per Final SEP-2127, conformant publishers, and the unofficial /.well-known/mcp/server-card.json convention recorded (gap scout 2026-10-20, every URL fetched) - 2026-10-20 — SEP-2127 recorded as an Extensions Track charter: AI Catalog discovery, server-card media type, extension-repo wire format, and the SEP-1649 /.well-known/mcp.json path ## Instances - [Zuplo API Gateway (zuplo.com)](https://zuplo.com/) · Observed 2026-10-25 · origin - [Zoom Developers (developers.zoom.us)](https://developers.zoom.us/) · Observed 2026-10-25 · origin - [Zep Long-Term Agent Memory (getzep.com)](https://getzep.com/) · Observed 2026-10-25 · origin - [Zapier (zapier.com)](https://zapier.com/) · Observed 2026-10-25 · origin - [Wistia (wistia.com)](https://wistia.com/) · Observed 2026-10-25 · origin - [Warp Agentic Terminal (warp.dev)](https://warp.dev/) · Observed 2026-10-25 · origin - [Vast.ai (vast.ai)](https://vast.ai/) · Observed 2026-10-25 · origin - [tldraw Infinite Canvas SDK (tldraw.com)](https://tldraw.com/) · Observed 2026-10-25 · origin - [Taskade (taskade.com)](https://taskade.com/) · Observed 2026-10-25 · origin - [SurrealDB (surrealdb.com)](https://surrealdb.com/) · Observed 2026-10-25 · origin - [Supermemory (supermemory.ai)](https://supermemory.ai/) · Observed 2026-10-25 · origin - [Skyvern Browser Automation Agent (skyvern.com)](https://skyvern.com/) · Observed 2026-10-25 · origin - [Sentry (sentry.io)](https://sentry.io/) · Observed 2026-10-25 · origin - [Scalar API Platform (scalar.com)](https://scalar.com/) · Observed 2026-10-25 · origin - [SavvyCal (savvycal.com)](https://savvycal.com/) · Observed 2026-10-25 · origin - [Revid AI Video Platform (revid.ai)](https://revid.ai/) · Observed 2026-10-25 · origin - [Replicate (replicate.com)](https://replicate.com/) · Observed 2026-10-25 · origin - [Reducto Document AI (reducto.ai)](https://reducto.ai/) · Observed 2026-10-25 · origin - [Pydantic & Logfire (pydantic.dev)](https://pydantic.dev/) · Observed 2026-10-25 · origin - [Publica.la (publica.la)](https://publica.la/) · Observed 2026-10-25 · origin - [Prisma ORM & Postgres (prisma.io)](https://prisma.io/) · Observed 2026-10-25 · origin - [Podscan Podcast Intelligence API (podscan.fm)](https://podscan.fm/) · Observed 2026-10-25 · origin - [PlanetScale (planetscale.com)](https://planetscale.com/) · Observed 2026-10-25 · origin - [Plane (plane.so)](https://plane.so/) · Observed 2026-10-25 · origin - [Perplexity API Docs (docs.perplexity.ai)](https://docs.perplexity.ai/) · Observed 2026-10-25 · origin - [Papermark Open-Source DocSend (papermark.io)](https://papermark.io/) · Observed 2026-10-25 · origin - [OpenStatus (openstatus.dev)](https://openstatus.dev/) · Observed 2026-10-25 · origin - [Novita AI (novita.ai)](https://novita.ai/) · Observed 2026-10-25 · origin - [Nomads.com (nomads.com)](https://nomads.com/) · Observed 2026-10-25 · origin - [MotherDuck Serverless DuckDB (motherduck.com)](https://motherduck.com/) · Observed 2026-10-25 · origin - [Morph Fast Apply LLM (morphllm.com)](https://morphllm.com/) · Observed 2026-10-25 · origin - [Model Context Protocol Docs (modelcontextprotocol.io)](https://modelcontextprotocol.io/) · Observed 2026-10-25 · origin - [Lago (getlago.com)](https://getlago.com/) · Observed 2026-10-25 · origin - [Kent C. Dodds (kentcdodds.com)](https://kentcdodds.com/) · Observed 2026-10-25 · origin - [Intercom Developers (developers.intercom.com)](https://developers.intercom.com/) · Observed 2026-10-25 · origin - [Infisical Secrets Management (infisical.com)](https://infisical.com/) · Observed 2026-10-25 · origin - [Hostinger (hostinger.com)](https://hostinger.com/) · Observed 2026-10-25 · origin - [Fly.io (fly.io)](https://fly.io/) · Observed 2026-10-25 · origin - [Eodly (eodly.io)](https://eodly.io/) · Observed 2026-10-25 · origin - [docs.warp.dev](https://docs.warp.dev/) · Observed 2026-10-25 · origin - [Devin Origin (devin.ai)](https://devin.ai/) · Observed 2026-10-25 · origin - [Descope Identity & Agent Auth (descope.com)](https://descope.com/) · Observed 2026-10-25 · origin - [DC Hub (dchub.cloud)](https://dchub.cloud/) · Observed 2026-10-25 · origin - [Customer.io (customer.io)](https://customer.io/) · Observed 2026-10-25 · origin - [crewai.com](https://crewai.com/) · Observed 2026-10-25 · origin - [Coinbase (coinbase.com)](https://coinbase.com/) · Observed 2026-10-25 · origin - [Circle (circle.so)](https://circle.so/) · Observed 2026-10-25 · origin - [Checkly Synthetic Monitoring (checklyhq.com)](https://checklyhq.com/) · Observed 2026-10-25 · origin - [Cerebrium Serverless AI (cerebrium.ai)](https://cerebrium.ai/) · Observed 2026-10-25 · origin - [Cal.com Scheduling Infrastructure (cal.com)](https://cal.com/) · Observed 2026-10-25 · origin - [Bird (bird.com)](https://bird.com/) · Observed 2026-10-25 · origin - [Better Stack Observability (betterstack.com)](https://betterstack.com/) · Observed 2026-10-25 · origin - [beehiiv Newsletter Platform (beehiiv.com)](https://beehiiv.com/) · Observed 2026-10-25 · origin - [Baseten Docs (docs.baseten.co)](https://docs.baseten.co/) · Observed 2026-10-25 · origin - [Augment Code Docs (docs.augmentcode.com)](https://docs.augmentcode.com/) · Observed 2026-10-25 · origin - [Attio Docs (docs.attio.com)](https://docs.attio.com/) · Observed 2026-10-25 · origin - [Arcade AI Tool-Calling Runtime (arcade.dev)](https://arcade.dev/) · Observed 2026-10-25 · origin - [Appwrite Backend Platform (appwrite.io)](https://appwrite.io/) · Observed 2026-10-25 · origin - [Apideck Unified API (apideck.com)](https://apideck.com/) · Observed 2026-10-25 · origin - [Amplitude (amplitude.com)](https://amplitude.com/) · Observed 2026-10-25 · origin - [Agent Skills Specification (agentskills.io)](https://agentskills.io/) · Observed 2026-10-25 · origin - [Agent Client Protocol (agentclientprotocol.com)](https://agentclientprotocol.com/) · Observed 2026-10-25 · origin - [AG-UI Documentation Origin (docs.ag-ui.com)](https://docs.ag-ui.com/) · Observed 2026-10-25 · origin - [Ad Context Protocol Docs (docs.adcontextprotocol.org)](https://docs.adcontextprotocol.org/) · Observed 2026-10-25 · origin - [2s.io](https://2s.io/) · Observed 2026-10-25 · origin - [Twilio (twilio.com)](https://twilio.com/) · Observed 2026-10-23 · origin - [Telnyx (telnyx.com)](https://telnyx.com/) · Observed 2026-10-23 · origin - [Salespeak B2B Buyer Concierge Agent](https://salespeak.ai) · Observed 2026-10-23 · agent - [Resend (resend.com)](https://resend.com/) · Observed 2026-10-23 · origin - [Railway (railway.com)](https://railway.com/) · Observed 2026-10-23 · origin - [Neon Serverless Postgres (neon.com)](https://neon.com/) · Observed 2026-10-23 · origin - [n8n Documentation Origin (docs.n8n.io)](https://docs.n8n.io/) · Observed 2026-10-23 · origin - [Loops (loops.so)](https://loops.so/) · Observed 2026-10-23 · origin - [Hugging Face (huggingface.co)](https://huggingface.co/) · Observed 2026-10-23 · origin - [GTmetrix (gtmetrix.com)](https://gtmetrix.com/) · Observed 2026-10-23 · origin - [GitHub Copilot MCP API (api.githubcopilot.com)](https://api.githubcopilot.com/mcp/server-card) · Observed 2026-10-23 · origin - [ClickHouse (clickhouse.com)](https://clickhouse.com/) · Observed 2026-10-23 · origin - [blog.cloudflare.com](https://blog.cloudflare.com/) · Observed 2026-10-23 · origin - [Apify (apify.com)](https://apify.com/) · Observed 2026-10-23 · origin - [Anthropic Claude Platform (platform.claude.com)](https://platform.claude.com/) · Observed 2026-10-23 · origin - [agenticweb.wiki Reference Agent and MCP Server](https://agenticweb.wiki) · Observed 2026-10-23 · agent - [Official MCP Registry](https://registry.modelcontextprotocol.io) · Observed 2026-08-29 · venue Every instance with its source is listed on the [instances page](/instances/). Our probe: seen on 131 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Part of: [Model Context Protocol](/protocols/mcp/) - Builds on: [Model Context Protocol](/protocols/mcp/) - Pairs with: [Model Context Protocol](/protocols/mcp/), [Official MCP Registry](/protocols/mcp-registry/), [AI Catalog well-known file](/protocols/ai-catalog-well-known-file/), [api-catalog: A Well-Known URI and Link Relation to Help Discovery of APIs](/protocols/api-catalog-rfc9727/), [OAuth Protected Resource and Authorization Server Metadata (as used for agent authorization)](/protocols/oauth-metadata-for-agents/), [OpenAI Plugins (formerly Apps SDK)](/protocols/openai-apps-sdk-manifests/) - [MCP](/terms/model-context-protocol/) ## Comparisons - [OpenAPI & REST APIs vs Model Context Protocol (MCP) (classic vs agentic)](/compare/openapi-vs-mcp/) - [sitemap.xml vs llms.txt & ARD (classic vs agentic)](/compare/sitemap-xml-vs-llms-txt/) - [Agent2Agent Protocol vs MCP Server Cards (SEP-2127)](/compare/a2a-vs-mcp-server-cards/) - [MCP Server Cards (SEP-2127) vs Agentic Resource Discovery](/compare/mcp-server-cards-vs-ard/) - [MCP Server Cards (SEP-2127) vs Official MCP Registry](/compare/mcp-server-cards-vs-mcp-registry/) - [MCP Server Cards (SEP-2127) vs AI Catalog well-known file](/compare/mcp-server-cards-vs-ai-catalog-well-known-file/) - [Discovery of Model Context Protocol Servers via DNS TXT Records vs MCP Server Cards (SEP-2127)](/compare/mcp-dns-discovery-vs-mcp-server-cards/) ## References - SEP-2127 (MCP Server Cards) is marked Final as of 2026-10-06. — [https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/seps/2127-mcp-server-cards.md](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/seps/2127-mcp-server-cards.md) (2026-10-06) VERIFIED - The MCP Registry working group page states that the server.json schema is being aligned with the Server Card (charter changelog entry 2026-07-30). — [https://modelcontextprotocol.io/community/working-groups/registry](https://modelcontextprotocol.io/community/working-groups/registry) (2026-07-30) REPORTED - 2026-07-28 released 2026-10-06 — [https://github.com/modelcontextprotocol/modelcontextprotocol/releases/tag/2026-07-28](https://github.com/modelcontextprotocol/modelcontextprotocol/releases/tag/2026-07-28) (2026-10-16) VERIFIED - GitHub serves a SEP-2127-conformant card at api.githubcopilot.com/mcp/server-card (linked from github.com/.well-known/ai-catalog.json); Hugging Face at huggingface.co/mcp/server-card. — [https://api.githubcopilot.com/mcp/server-card](https://api.githubcopilot.com/mcp/server-card) (2026-10-20) VERIFIED - Six domains (Zapier, Proof, Coinbase, Cloudflare, Sentry, Twilio) served JSON at /.well-known/mcp/server-card.json on 2026-10-20; none at /server-card and none with the v1 server-card $schema. — [https://zapier.com/.well-known/mcp/server-card.json](https://zapier.com/.well-known/mcp/server-card.json) (2026-10-20) VERIFIED - The extension's wire format (schema.ts, docs/discovery.md) lives in the ext-server-card repository, renamed from experimental-ext-server-card. — [https://github.com/modelcontextprotocol/ext-server-card](https://github.com/modelcontextprotocol/ext-server-card) (2026-10-20) VERIFIED - SEP-2127 (MCP Server Cards) is Final on the Extensions Track. It is a charter: discovery is an AI Catalog at /.well-known/ai-catalog.json, the reserved card is GET /server-card as application/mcp-server-card+json, and /.well-known/mcp.json is the earlier SEP-1649 shape. When the static card and live server/discover disagree, the live call wins. — [https://modelcontextprotocol.io/seps/2127-mcp-server-cards](https://modelcontextprotocol.io/seps/2127-mcp-server-cards) (2026-10-06) VERIFIED - The normative server-card wire format lives in the extension repository. At review it was pinned to snapshot 526201bb. SEP-2127 merged on 2026-10-06 in PR 2127. — [https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2127](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2127) (2026-10-06) VERIFIED [JSON](/data/protocols/mcp-server-cards.json) · [Markdown](/protocols/mcp-server-cards/index.md) · [OKF v0.2](/okf/protocols/mcp-server-cards.md) --- # Model Context Protocol (MCP) Model Context Protocol (MCP) is an agentic-web standard (endpoint) at step 5, Act, governed by Agentic AI Foundation; its status is "Active open specification, current dated release 2026-07-28". It answers: "How does an AI application call tools and pull structured context, prompts, and data from an external server?" Replacing or extending Language Server Protocol, implementation status is multi-implementation (Three independent registry censuses, kept separate…; observed on 140/1226 probed origins), last verified 2026-10-23. ## Quick Wire Reference - **Step**: 5 Act (Do something for me) - **Version**: 2026-07-28 (2026-07-28) - **Status**: Active open specification, current dated release 2026-07-28 ·… - **Discovery / Probe Path**: GET {endpoint}/server-card (SEP-2127 Final, application/mcp-server-card+json, discovered via… - **Spec URL**: https://modelcontextprotocol.io/specification/2026-07-28/index - **Last Verified**: 2026-10-23 (current) - **Classic Web Analog**: Language Server Protocol [Act](/category/act/) The Model Context Protocol (MCP) is a JSON-RPC 2.0 based protocol that lets an AI "host" application (an IDE, a chat client) connect, through a "client" it embeds, to one or more "servers" that expose tools (functions the model can call), resources (data or content), and prompts (reusable templates) [[1]](#ref-1). It also defines client-side elicitation (a server asking the user a question) and utilities for progress, cancellation, and structured errors. Anthropic published the first version in November 2024; the current dated release is 2026-07-28 [[1]](#ref-1). ## Overview MCP solves the M×N integration problem: rather than every AI application writing bespoke connectors to every tool and data source, both sides implement one protocol once, similarly to how the Language Server Protocol standardized editor-to-language-server integration [[1]](#ref-1). It is transport-agnostic (stdio for local processes, streamable HTTP for remote servers). The 2026-07-28 specification made the protocol stateless: the initialize / initialized exchange and the Mcp-Session-Id header are retired [[10]](#ref-10). A request carries MCP-Protocol-Version, and the method and tool name travel in Mcp-Method and Mcp-Name, so a gateway can route on headers. A client that wants capabilities before any other call uses server/discover. That call is optional, and any other request can land on any instance [[10]](#ref-10). initialize remains the legacy fallback for servers that still speak 2025-11-25 and earlier. MCP does not itself define a machine-readable way to discover a server before connecting to it, nor an interactive-UI format; both live in extensions. The MCP Server Card, a static document giving a server's identity and remote endpoints, is SEP-2127, which reached Final status on the Extensions Track on 2026-10-06 [[8]](#ref-8); the normative schema lives in the modelcontextprotocol/ext-server-card repository (graduated from its experimental name on acceptance) [[4]](#ref-4). Its reserved location is GET /server-card, served as application/mcp-server-card+json, and cards are discovered through an AI Catalog at /.well-known/ai-catalog.json. /.well-known/mcp.json is the earlier SEP-1649 path. When the static card and a live server/discover response disagree, the live call wins [[8]](#ref-8). Cards carry identity, transports and protocol versions only, never tools or prompts, which clients list live. MCP Apps, a separate extension for sandboxed-iframe interactive UI returned by tools, is an accepted extension with multi-vendor host support (Claude, VS Code Copilot, Microsoft 365 Copilot, Goose, Postman, and others) [[7]](#ref-7). As of September 2026, MCP is implemented by ten official SDKs spanning three support tiers, with the Python SDK alone carrying 24,200+ GitHub stars, and by an official cross-language server registry (7,200+ stars) [[5]](#ref-5)[[6]](#ref-6). Vendor and press claims sit beside those counts: Wikipedia states OpenAI adopted MCP in ChatGPT's desktop app in March 2025 and extended support to ChatGPT apps in September 2025, and that Microsoft integrates it with Semantic Kernel and Azure OpenAI [[2]](#ref-2); WorkOS separately describes MCP as adopted by "OpenAI, Google DeepMind, Microsoft, and thousands of development teams" [[3]](#ref-3). The official registry API does not publish a catalogue total (metadata.count on a one-row page is the page size). Three independent censuses exist. They use different units and dates, so this record keeps each figure and does not average them. VerifyMCP, as of 2026-10-19, reports 47,870 logical servers in an hourly recount: 45,953 active, 601 deprecated, and 1,316 deleted; 31,337 remote; 30,842 Streamable HTTP. Among components they handshook, 20,031 spoke 2025-11-25 and 6,571 spoke 2026-07-28 [[11]](#ref-11). Registry discussion 1580, as of 2026-08-27, walked the cursor to the end: 82,994 version records, 25,125 distinct isLatest servers, 15,468 publishers, and 13,279 Streamable HTTP remotes. Counting version rows makes the registry look heavily duplicated; that duplication is release cadence [[12]](#ref-12). Registry discussion 1548, as of 2026-08-19, counted version=latest registrations without connecting to endpoints: 22,636 active, of which 12,077 declare an HTTPS remote [[13]](#ref-13). Governance sits with the Agentic AI Foundation under the Linux Foundation, with day-to-day specification work happening in public via SEPs (Specification Enhancement Proposals) and topic-specific working groups (e.g. the Server Card working group) in the modelcontextprotocol GitHub org — this is a materially more open, standards-body-adjacent process than the seed record's placeholder "Agentic AI Foundation / Linux Foundation" implied but did not source. What remains open is how widely Server Cards are deployed now that SEP-2127 is Final, and that the three registry counts above answer different questions. ## Discovery and probe On protocol 2026-07-28, an optional JSON-RPC server/discover call over a stateless transport. Each request carries MCP-Protocol-Version, and the method and tool name travel in Mcp-Method and Mcp-Name. initialize, initialized, and Mcp-Session-Id are retired. initialize remains the legacy handshake for 2025-11-25 and earlier. A static Server Card is the pre-connection signal. · GET {endpoint}/server-card (SEP-2127 Final, application/mcp-server-card+json, discovered via /.well-known/ai-catalog.json; /.well-known/mcp.json is legacy SEP-1649) ``` POST {endpoint}/mcp parse: For protocol 2026-07-28, POST a JSON-RPC 2.0 request with method server/discover. The 2026-07-28 specification made MCP stateless and retired initialize, initialized, and Mcp-Session-Id. Each request carries the MCP-Protocol-Version header, and the method and tool name travel in Mcp-Method and Mcp-Name. server/discover is optional; any other request can land on any instance. On success, the returned protocol version (for example 2026-07-28) and the server name prove an MCP server is present. For servers that still speak 2025-11-25 and earlier, fall back to the legacy initialize handshake and read response.result.protocolVersion and response.result.serverInfo.name. on absent: Connection refused, 404, or a non-JSON-RPC response means no MCP server is exposed at that endpoint. SEP-2127 is Final: GET {endpoint}/server-card as application/mcp-server-card+json is a static discovery signal, discovered via /.well-known/ai-catalog.json. /.well-known/mcp.json is the legacy SEP-1649 path. When the static card and a live server/discover response disagree, the live call wins. ``` Not probed live: no-fixed-path. MCP endpoints are not at a fixed well-known path. On 2026-07-28, capabilities are read with server/discover; initialize is the legacy handshake for 2025-11-25 and earlier. The server card is GET /server-card. ## History - 2026-09-05 — seeded from Exa Agent research run - 2026-09-06 — verified against modelcontextprotocol.io/specification/2026-07-28, github.com/modelcontextprotocol/experimental-ext-server-card, github.com/modelcontextprotocol/registry, modelcontextprotocol.io/docs/2026-07-28/sdk, modelcontextprotocol.io/docs/extensions/apps, en.wikipedia.org/wiki/Model_Context_Protocol, workos.com MCP-2026 blog - 2026-10-16 — Server Cards (SEP-2127) Final 6 Oct 2026; Skills over MCP (SEP-2640) Final 13 Sep 2026; next spec release cadence under discussion (SEP-3398) - 2026-10-16 — use-case tags (auto) - 2026-10-17 — prose brought in line with the infobox and history: SEP-2127 Server Cards are Final (2026-10-06), not experimental; reserved location, media type and the superseded /.well-known/mcp.json noted - 2026-10-20 — server-card evidence line marked superseded (SEP-2127 Final; repo renamed to ext-server-card) - 2026-10-20 — probe now uses server/discover for 2026-07-28 with initialize as the legacy fallback; SEP-2127 card is Final; three registry censuses recorded with their units and dates ## Instances - [Zuplo API Gateway (zuplo.com)](https://zuplo.com/) · Observed 2026-10-25 · origin - [Zoom Developers (developers.zoom.us)](https://developers.zoom.us/) · Observed 2026-10-25 · origin - [Zep Long-Term Agent Memory (getzep.com)](https://getzep.com/) · Observed 2026-10-25 · origin - [Zapier (zapier.com)](https://zapier.com/) · Observed 2026-10-25 · origin - [Wistia (wistia.com)](https://wistia.com/) · Observed 2026-10-25 · origin - [Warp Agentic Terminal (warp.dev)](https://warp.dev/) · Observed 2026-10-25 · origin - [Vercel v0 Generative UI (v0.app)](https://v0.app/) · Observed 2026-10-25 · origin - [tldraw Infinite Canvas SDK (tldraw.com)](https://tldraw.com/) · Observed 2026-10-25 · origin - [Taskade (taskade.com)](https://taskade.com/) · Observed 2026-10-25 · origin - [SurrealDB (surrealdb.com)](https://surrealdb.com/) · Observed 2026-10-25 · origin - [Supermemory (supermemory.ai)](https://supermemory.ai/) · Observed 2026-10-25 · origin - [Supabase (supabase.com)](https://supabase.com/) · Observed 2026-10-25 · origin - [Speakeasy (speakeasy.com)](https://speakeasy.com/) · Observed 2026-10-25 · origin - [Skyvern Browser Automation Agent (skyvern.com)](https://skyvern.com/) · Observed 2026-10-25 · origin - [Sentry (sentry.io)](https://sentry.io/) · Observed 2026-10-25 · origin - [Semgrep (semgrep.dev)](https://semgrep.dev/) · Observed 2026-10-25 · origin - [Scalar API Platform (scalar.com)](https://scalar.com/) · Observed 2026-10-25 · origin - [SavvyCal (savvycal.com)](https://savvycal.com/) · Observed 2026-10-25 · origin - [Revid AI Video Platform (revid.ai)](https://revid.ai/) · Observed 2026-10-25 · origin - [Replicate (replicate.com)](https://replicate.com/) · Observed 2026-10-25 · origin - [Reducto Document AI (reducto.ai)](https://reducto.ai/) · Observed 2026-10-25 · origin - [Pydantic & Logfire (pydantic.dev)](https://pydantic.dev/) · Observed 2026-10-25 · origin - [Publica.la (publica.la)](https://publica.la/) · Observed 2026-10-25 · origin - [Proof API (api.proof.com)](https://api.proof.com/.well-known/ard.json) · Observed 2026-10-25 · origin - [Prisma ORM & Postgres (prisma.io)](https://prisma.io/) · Observed 2026-10-25 · origin - [Podscan Podcast Intelligence API (podscan.fm)](https://podscan.fm/) · Observed 2026-10-25 · origin - [Plane (plane.so)](https://plane.so/) · Observed 2026-10-25 · origin - [Perplexity API Docs (docs.perplexity.ai)](https://docs.perplexity.ai/) · Observed 2026-10-25 · origin - [Papermark Open-Source DocSend (papermark.io)](https://papermark.io/) · Observed 2026-10-25 · origin - [OpenStatus (openstatus.dev)](https://openstatus.dev/) · Observed 2026-10-25 · origin - [Novita AI (novita.ai)](https://novita.ai/) · Observed 2026-10-25 · origin - [Nomads.com (nomads.com)](https://nomads.com/) · Observed 2026-10-25 · origin - [MotherDuck Serverless DuckDB (motherduck.com)](https://motherduck.com/) · Observed 2026-10-25 · origin - [Model Context Protocol Docs (modelcontextprotocol.io)](https://modelcontextprotocol.io/) · Observed 2026-10-25 · origin - [Mintlify (mintlify.com)](https://mintlify.com/) · Observed 2026-10-25 · origin - [Lago (getlago.com)](https://getlago.com/) · Observed 2026-10-25 · origin - [Kent C. Dodds (kentcdodds.com)](https://kentcdodds.com/) · Observed 2026-10-25 · origin - [Intercom Developers (developers.intercom.com)](https://developers.intercom.com/) · Observed 2026-10-25 · origin - [Hostinger (hostinger.com)](https://hostinger.com/) · Observed 2026-10-25 · origin - [Gumroad Creator Commerce (gumroad.com)](https://gumroad.com/) · Observed 2026-10-25 · origin - [Graphlit Knowledge Retrieval Platform (graphlit.com)](https://graphlit.com/) · Observed 2026-10-25 · origin - [Eodly (eodly.io)](https://eodly.io/) · Observed 2026-10-25 · origin - [Dries Buytaert (dri.es)](https://dri.es/) · Observed 2026-10-25 · origin - [docs.warp.dev](https://docs.warp.dev/) · Observed 2026-10-25 · origin - [Devin Origin (devin.ai)](https://devin.ai/) · Observed 2026-10-25 · origin - [Desvela (desvela.dev)](https://desvela.dev/) · Observed 2026-10-25 · origin - [Descope Identity & Agent Auth (descope.com)](https://descope.com/) · Observed 2026-10-25 · origin - [DC Hub (dchub.cloud)](https://dchub.cloud/) · Observed 2026-10-25 · origin - [DataFast Analytics (datafa.st)](https://datafa.st/) · Observed 2026-10-25 · origin - [crewai.com](https://crewai.com/) · Observed 2026-10-25 · origin - [Coinbase (coinbase.com)](https://coinbase.com/) · Observed 2026-10-25 · origin - [Circle (circle.so)](https://circle.so/) · Observed 2026-10-25 · origin - [Checkly Synthetic Monitoring (checklyhq.com)](https://checklyhq.com/) · Observed 2026-10-25 · origin - [Cerebrium Serverless AI (cerebrium.ai)](https://cerebrium.ai/) · Observed 2026-10-25 · origin - [Cal.com Scheduling Infrastructure (cal.com)](https://cal.com/) · Observed 2026-10-25 · origin - [cafe24.com](https://www.cafe24.com/) · Observed 2026-10-25 · origin - [Browser Use Web Agent Runtime (browser-use.com)](https://browser-use.com/) · Observed 2026-10-25 · origin - [Bird (bird.com)](https://bird.com/) · Observed 2026-10-25 · origin - [Better Stack Observability (betterstack.com)](https://betterstack.com/) · Observed 2026-10-25 · origin - [beehiiv Newsletter Platform (beehiiv.com)](https://beehiiv.com/) · Observed 2026-10-25 · origin - [Baseten Docs (docs.baseten.co)](https://docs.baseten.co/) · Observed 2026-10-25 · origin - [Augment Code Docs (docs.augmentcode.com)](https://docs.augmentcode.com/) · Observed 2026-10-25 · origin - [Attio Docs (docs.attio.com)](https://docs.attio.com/) · Observed 2026-10-25 · origin - [Arcade AI Tool-Calling Runtime (arcade.dev)](https://arcade.dev/) · Observed 2026-10-25 · origin - [Appwrite Backend Platform (appwrite.io)](https://appwrite.io/) · Observed 2026-10-25 · origin - [Apideck Unified API (apideck.com)](https://apideck.com/) · Observed 2026-10-25 · origin - [Agent Skills Specification (agentskills.io)](https://agentskills.io/) · Observed 2026-10-25 · origin - [Agent Client Protocol (agentclientprotocol.com)](https://agentclientprotocol.com/) · Observed 2026-10-25 · origin - [AG-UI Documentation Origin (docs.ag-ui.com)](https://docs.ag-ui.com/) · Observed 2026-10-25 · origin - [Ad Context Protocol Docs (docs.adcontextprotocol.org)](https://docs.adcontextprotocol.org/) · Observed 2026-10-25 · origin - [2s.io](https://2s.io/) · Observed 2026-10-25 · origin - [WorkOS AuthKit and Agent Auth](https://workos.com) · Observed 2026-10-23 · authority - [Twilio (twilio.com)](https://twilio.com/) · Observed 2026-10-23 · origin - [Telnyx (telnyx.com)](https://telnyx.com/) · Observed 2026-10-23 · origin - [Salespeak B2B Buyer Concierge Agent](https://salespeak.ai) · Observed 2026-10-23 · agent - [Resend (resend.com)](https://resend.com/) · Observed 2026-10-23 · origin - [Railway (railway.com)](https://railway.com/) · Observed 2026-10-23 · origin - [Neon Serverless Postgres (neon.com)](https://neon.com/) · Observed 2026-10-23 · origin - [n8n Documentation Origin (docs.n8n.io)](https://docs.n8n.io/) · Observed 2026-10-23 · origin - [Mnemom Cryptographic Agent Trust Service](https://mnemom.ai) · Observed 2026-10-23 · authority - [Loops (loops.so)](https://loops.so/) · Observed 2026-10-23 · origin - [Kakao PlayMCP Gateway and Toolbox Registry](https://playmcp.kakao.com) · Observed 2026-10-23 · venue - [Hugging Face (huggingface.co)](https://huggingface.co/) · Observed 2026-10-23 · origin - [GTmetrix (gtmetrix.com)](https://gtmetrix.com/) · Observed 2026-10-23 · origin - [GitHub Copilot MCP API (api.githubcopilot.com)](https://api.githubcopilot.com/mcp/server-card) · Observed 2026-10-23 · origin - [Coinbase AgentKit and CDP Server Wallets](https://github.com/coinbase/agentkit) · Observed 2026-10-23 · authority - [ClickHouse (clickhouse.com)](https://clickhouse.com/) · Observed 2026-10-23 · origin - [blog.cloudflare.com](https://blog.cloudflare.com/) · Observed 2026-10-23 · origin - [Apify (apify.com)](https://apify.com/) · Observed 2026-10-23 · origin - [Anthropic Claude Platform (platform.claude.com)](https://platform.claude.com/) · Observed 2026-10-23 · origin - [agenticweb.wiki Reference Agent and MCP Server](https://agenticweb.wiki) · Observed 2026-10-23 · agent - [Visual Studio Code (Copilot and MCP Client)](https://code.visualstudio.com) · Observed 2026-08-29 · harness - [Official MCP Registry](https://registry.modelcontextprotocol.io) · Observed 2026-08-29 · venue - [IBM BeeAI Multi-Agent Runtime](https://github.com/i-am-bee/beeai-platform) · Observed 2026-08-29 · agent - [Goose (Block)](https://github.com/block/goose) · Observed 2026-08-29 · harness - [GitHub Copilot Coding Agent](https://docs.github.com/en/copilot/how-tos/use-copilot-agents/coding-agent/create-custom-agents) · Observed 2026-08-29 · harness - [Shopify Agentic Storefronts and Catalog Venue](https://shopify.com) · Observed 2026-08-21 · venue - [CopilotKit](https://www.copilotkit.ai) · Observed 2026-08-14 · harness - [8004.org / ERC-8004 Trustless Agents Registry](https://www.8004.org) · Observed 2026-08-13 · venue - [Google Agent Development Kit (ADK)](https://google.github.io/adk-docs/) · Observed 2026-07-31 · harness - [Nevermined x402 Facilitator and Metering Clearinghouse](https://docs.nevermined.app) · Observed 2026-07-23 · venue - [AGNTCY Agent Directory Service (Linux Foundation)](https://agntcy.org) · Observed 2026-07-23 · venue - [Infoblox DNS-AID Registry (Linux Foundation)](https://github.com/infobloxopen/dns-aid-core) · Observed 2026-07-15 · venue - [GoDaddy Agent Name Service (ANS) Authority](https://github.com/godaddy/ans) · Observed 2026-07-15 · authority - [OpenA2A Agent Authorization Protocol (AAP) Authority](https://github.com/opena2a-standards/agent-authorization-protocol) · Observed 2026-07-02 · authority Every instance with its source is listed on the [instances page](/instances/). Verified SDKs, reference implementations & validators: - [TypeScript SDK (Tier 1)](https://github.com/modelcontextprotocol/typescript-sdk) · sdk (2026) - [Python SDK (Tier 1)](https://github.com/modelcontextprotocol/python-sdk) · sdk (2026) - [C# SDK (Tier 1)](https://github.com/modelcontextprotocol/csharp-sdk) · sdk (2026) - [Go SDK (Tier 1)](https://github.com/modelcontextprotocol/go-sdk) · sdk (2026) - [Rust SDK (Tier 1)](https://github.com/modelcontextprotocol/rust-sdk) · sdk (2026) - [Java SDK (Tier 2)](https://github.com/modelcontextprotocol/java-sdk) · sdk (2026) - [Ruby SDK (Tier 2)](https://github.com/modelcontextprotocol/ruby-sdk) · sdk (2026) - [Swift SDK (Tier 3)](https://github.com/modelcontextprotocol/swift-sdk) · sdk (2026) - [PHP SDK (Tier 3)](https://github.com/modelcontextprotocol/php-sdk) · sdk (2026) - [Kotlin SDK (Tier 3)](https://github.com/modelcontextprotocol/kotlin-sdk) · sdk (2026) - [Claude / Claude Desktop (Anthropic)](https://modelcontextprotocol.io/docs/extensions/apps) · implementation (2026) - [OpenAI ChatGPT / Codex (Plugins, formerly Apps SDK)](https://developers.openai.com/plugins/concepts/mcp-server) · implementation (2026) Our probe: seen on 140 of 1226 probed origins, last 2026-10-25. Probed origins are whoever was asked about, not a sample; the count is a floor. ## See also - Component: [MCP Server Cards (SEP-2127)](/protocols/mcp-server-cards/) - Depended on by: [Ad Context Protocol](/protocols/adcp/), [Agentic Real Time Framework](/protocols/artf/), [Coral Protocol (CoralOS)](/protocols/coral-protocol/), [Discovery of Model Context Protocol Servers via DNS TXT Records](/protocols/mcp-dns-discovery/), [KYA-OS (Know Your Agent Operating System)](/protocols/kya-os/), [MCP Apps](/protocols/mcp-apps/), [MCP Server Cards (SEP-2127)](/protocols/mcp-server-cards/), [NLWeb](/protocols/nlweb/), [Official MCP Registry](/protocols/mcp-registry/), [OpenAI Plugins (formerly Apps SDK)](/protocols/openai-apps-sdk-manifests/), [Per-Call Proof for Local Tool Invocation by AI Agents](/protocols/local-tool-call-proof/), [WebMCP](/protocols/webmcp/) - Pairs with: [MCP Apps](/protocols/mcp-apps/), [Official MCP Registry](/protocols/mcp-registry/), [MCP Server Cards (SEP-2127)](/protocols/mcp-server-cards/), [OAuth Protected Resource and Authorization Server Metadata (as used for agent authorization)](/protocols/oauth-metadata-for-agents/), [Agent2Agent Protocol](/protocols/a2a/), [Agent Client Protocol](/protocols/agent-client-protocol/) - [MCP Server Card](/terms/server-card/) - [Agentic web](/terms/agentic-web/) - [MCP Registry](/terms/official-mcp-registry/) - [Protected Resource Metadata](/terms/protected-resource-metadata/) - [Tool](/terms/tool/) - [Agent skill](/terms/agent-skill/) - [MCP](/terms/model-context-protocol/) - [Streamable HTTP](/terms/streamable-http/) - [Elicitation](/terms/elicitation/) - [Sampling](/terms/sampling/) - [Roots](/terms/roots/) - [MCP Resource](/terms/mcp-resource/) - [MCP Prompt](/terms/mcp-prompt/) - [Agent2Agent (A2A)](/terms/agent-to-agent/) - [Dynamic Client Registration & Client ID Metadata](/terms/dynamic-client-registration/) - [Context compaction](/terms/context-compaction/) - [AI agent](/terms/ai-agent/) - Scanners & registries: [Agents Welcome — Agent Protocol Atlas](https://agentswelcome.dev/protocols), [Kakao PlayMCP](https://playmcp.kakao.com/), [Lumar Agentic Readiness Scanner](https://agentic-readiness.lumar.io/), [MCP Registry](https://github.com/modelcontextprotocol/registry), [The Agent Almanac](https://agentalmanac.org/) - Not to be confused with: Microsoft Cloud Partner, Master Control Program ## Comparisons - [OpenAPI & REST APIs vs Model Context Protocol (MCP) (classic vs agentic)](/compare/openapi-vs-mcp/) - [DOM Browser Automation vs WebMCP & MCP (classic vs agentic)](/compare/browser-automation-vs-webmcp/) - [Agent2Agent Protocol vs Model Context Protocol](/compare/a2a-vs-mcp/) - [Agent Skills vs Model Context Protocol](/compare/anthropic-agent-skills-format-vs-mcp/) - [Model Context Protocol vs WebMCP](/compare/mcp-vs-webmcp/) - [Model Context Protocol vs Agent Client Protocol](/compare/mcp-vs-agent-client-protocol/) - [NLWeb vs Model Context Protocol](/compare/nlweb-vs-mcp/) - [Model Context Protocol vs agents.json](/compare/mcp-vs-agents-json/) - [Model Context Protocol vs OpenAI Plugins (formerly Apps SDK)](/compare/mcp-vs-openai-apps-sdk-manifests/) - [Agent Protocol vs Model Context Protocol](/compare/agent-protocol-aief-vs-mcp/) - [Agent Network Protocol vs Model Context Protocol](/compare/anp-vs-mcp/) ## References - Canonical dated specification is 2026-07-28; MCP is a JSON-RPC 2.0 protocol standardizing how hosts, clients, and servers share resources, prompts, and tools, with optional extensions (Tasks, Skills over MCP, MCP Apps). — [https://modelcontextprotocol.io/specification/2026-07-28/index](https://modelcontextprotocol.io/specification/2026-07-28/index) (2026-07-28) VERIFIED - OpenAI officially adopted MCP in March 2025 (ChatGPT desktop app integration) and added MCP support to ChatGPT apps in September 2025; MCP integrates with Microsoft Semantic Kernel and Azure OpenAI. — [https://en.wikipedia.org/wiki/Model_Context_Protocol](https://en.wikipedia.org/wiki/Model_Context_Protocol) (2026) VERIFIED - MCP has become the de facto protocol for connecting AI to external tools and data, adopted by OpenAI, Google DeepMind, Microsoft, and thousands of development teams as of 2026. — [https://workos.com/blog/everything-your-team-needs-to-know-about-mcp-in-2026](https://workos.com/blog/everything-your-team-needs-to-know-about-mcp-in-2026) (2026) REPORTED - Superseded: as of 2026-08-12 SEP-2127 was an experimental extension, not yet accepted. SEP-2127 reached Final on 2026-10-06, and the extension repo moved from experimental-ext-server-card to ext-server-card (301 observed 2026-10-20). It reserves GET /server-card; domain-level discovery routes through AI Catalog entries. — [https://github.com/modelcontextprotocol/ext-server-card](https://github.com/modelcontextprotocol/ext-server-card) (2026-08-12) VERIFIED - The MCP GitHub org publishes ten official/community SDKs tiered 1-3 (TypeScript, Python, C#, Go, Rust = Tier 1; Java, Ruby = Tier 2; Swift, PHP, Kotlin = Tier 3); the Python SDK has 24.2k GitHub stars and the TypeScript SDK 13.3k, both far larger than any competing protocol's SDK repos checked in this pass. — [https://modelcontextprotocol.io/docs/2026-07-28/sdk](https://modelcontextprotocol.io/docs/2026-07-28/sdk) (2026) VERIFIED - The MCP Registry (modelcontextprotocol/registry) is the official server registry, with 7.2k GitHub stars and 979 forks as of this check. — [https://github.com/modelcontextprotocol/registry](https://github.com/modelcontextprotocol/registry) (2026-09) VERIFIED - MCP Apps is an accepted extension (distinct from the Server Card, which is SEP-2127) letting servers return sandboxed-iframe interactive UI; it is supported by Claude, Claude Desktop, VS Code GitHub Copilot, Microsoft 365 Copilot, Goose, Postman, MCPJam, and Archestra.AI, and is also the standard OpenAI's ChatGPT plugin UI builds on. — [https://modelcontextprotocol.io/docs/extensions/apps](https://modelcontextprotocol.io/docs/extensions/apps) (2026) VERIFIED - MCP Server Cards (SEP-2127) reached Final on 2026-10-06; Skills over MCP (SEP-2640) reached Final on 2026-09-13; next spec release cadence is under discussion (SEP-3398) — [https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/seps/2127-mcp-server-cards.md](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/seps/2127-mcp-server-cards.md) (2026-10-06) VERIFIED - MCP Server Cards (SEP-2127) reached Final on 2026-10-06; Skills over MCP (SEP-2640) reached Final on 2026-09-13; next spec release cadence is under discussion (SEP-3398) — [https://plan.modelcontextprotocol.io/releases/2](https://plan.modelcontextprotocol.io/releases/2) (2026-10-06) REPORTED - The 2026-07-28 specification made MCP stateless. initialize and initialized, and the Mcp-Session-Id header, are retired. A request carries MCP-Protocol-Version, and the method and tool name travel in Mcp-Method and Mcp-Name. A client that wants capabilities before any other call uses server/discover, which is optional. — [https://blog.modelcontextprotocol.io/posts/2026-07-28/](https://blog.modelcontextprotocol.io/posts/2026-07-28/) (2026-07-28) VERIFIED - VerifyMCP's hourly recount of the official registry, as of 2026-10-19 (published in the page's