--- title: AI Card: One Standard for Every AI Service date: 2026-04-15 topics: protocols-standards tags: ai-card, protocols, mcp, a2a, discovery author: markus-muller reading_time: 8 minutes word_count: 1540 url: https://agentic-academy.ai/posts/ai-card-standard/ --- ## Summary AI Card is a Linux Foundation draft for unified AI artifact metadata with built-in trust. A2A and MCP steering committees are expected to vote on adoption. Every protocol in the agentic ecosystem has solved the same problem slightly differently. A2A defines an Agent Card that describes an agent's skills and endpoints. MCP's registry tracks servers in a `server.json` format. Claude Code has a plugin marketplace format. Each one does its job within its own domain, and none of them talk to each other. The result is predictable: enterprises building multi-protocol architectures end up maintaining parallel descriptions of the same services—one for A2A consumers, one for MCP clients, one for internal registries—with no standard way to verify who published any of them. AI Card is a draft standard under Linux Foundation stewardship that addresses this directly. It proposes a single, unified metadata format that any AI artifact can use—live agents, tool servers, datasets, or nested catalogs—with verifiable publisher identity and compliance attestations built in from the start. The A2A and MCP steering committees are expected to vote on adoption once the specification stabilizes. {{< interactive src="/visualizations/ai-card.html" title="AI Card Standard" caption="Explore how the AI Catalog layer works and what the sections of an AI Card contain. Includes before/after comparison for each artifact type." height="auto" fullwidth="true" >}} ## The catalog layer The core of AI Card is a two-level structure. An AI Catalog is a discovery index, typically published at `/.well-known/ai-catalog.json`, that lists entries pointing to individual AI Cards. Each entry uses a `mediaType` field to declare what kind of artifact it references. This is where the unification happens. The same catalog format handles entries that reference A2A agent cards (`application/a2a-agent-card+json`), MCP server cards (`application/mcp-server+json`), dataset cards, nested sub-catalogs, and any future artifact type the ecosystem invents. The catalog format doesn't change. New artifact types just add new media types. The well-known URL approach matters for enterprise deployments. An orchestrator, a marketplace crawler, or a governance tool can discover every AI service an organization exposes by fetching one endpoint—no central registry required. Nested catalogs let organizations subdivide by team or domain without disrupting the top-level view. Crawlers following references recursively get the complete picture. ## What changes for A2A and MCP Both [A2A](/posts/a2a-protocol-deep-dive/) and [MCP](/posts/mcp-deep-dive/) already define their own card formats, and AI Card doesn't replace them. The relationship is a layer above, not a substitution. An A2A agent card describes capabilities, skills, and endpoints for agent-to-agent communication. That operational format stays exactly as it is. What AI Card adds is a catalog entry that references the A2A card, attaches a publisher identity, and makes the combination discoverable across protocols. A client that only speaks A2A can still ignore the catalog layer entirely and consume the A2A card directly. The same applies to MCP. The [MCP Registry](/posts/mcp-registry-deep-dive/) tracks server cards that describe tools, resources, and transports. AI Card doesn't modify that format—it wraps it. An AI Catalog entry pointing at an MCP server card adds trust metadata that the server.json format has no concept of: a publisher DID, SOC 2 attestation URIs, content digests, and verification methods. The MCP client consumes the server card as before; a security-conscious consumer can also check the catalog entry's trust manifest before deciding whether to allow the connection. For enterprises running both protocols, this creates a single authoritative list of what's deployed, who published it, and whether it carries the compliance credentials the organization requires. ## Trust as a first-class field The gap that AI Card fills most directly is one that the [protocol landscape post](/posts/protocol-landscape-agentic-systems/) identified but couldn't yet point to a solution: none of the existing card formats give you a standardized way to verify who published a card or whether the service behind it has been audited. AI Card's `trust` section is the specification's most significant departure from what exists today. It combines several things that currently require separate, proprietary mechanisms: A verifiable publisher identity binds the card to an organization via DID, SPIFFE SVID, or domain URL. The identity type determines how it can be verified independently—against a DID registry, a certificate authority, or a DNS record. This is the difference between "this card says it's from Acme Corp" and "this card is cryptographically bound to an identity that Acme Corp controls." Attestations carry links to third-party compliance certifications: SOC 2, HIPAA, ISO 27001. These aren't embedded documents—they're URIs pointing to the actual certification artifacts. A consumer that requires SOC 2 compliance can check the trust field for an attestation of that type before connecting. The policy logic stays on the consumer side; the card just provides the signal. Provenance tracks the chain from source artifact to published card, with content digests at each step. For datasets especially, this lets automated pipelines verify that the data they're consuming matches what was signed off during governance review. This trust layer is optional—the specification defines three conformance levels, and a minimal AI Card doesn't require it. But the design priority is clear: making verifiable metadata possible without forcing every publisher to build bespoke infrastructure to provide it. ## Multi-protocol services One AI Card field that has no equivalent in the current A2A or MCP formats is `protocols`, which allows a single card to declare support for multiple protocols simultaneously. A service might support both A2A for agent-to-agent task delegation and MCP for tool consumption by models that use the Model Context Protocol. Previously, those were two separate cards with no formal relationship. An AI Card with both entries in its `protocols` map establishes that the same logical service speaks both languages, under the same publisher identity, covered by the same trust attestations. This matters when an orchestrating agent needs to decide which protocol to use for a given interaction. Instead of maintaining separate registries for each protocol and trying to match entries across them, the agent gets a single card that expresses the capability set. The [agent identity and authentication work](/posts/agent-identity-authentication/) that enterprises are doing for [OAuth-based delegation chains](/posts/aauth-agent-authentication-standard/) feeds directly into the subject identity that goes into catalog lookups—the same identity infrastructure serves discovery, authentication, and runtime authorization. ## What AI Card doesn't cover Like any well-scoped specification, AI Card has clear edges worth understanding before evaluating it. The card format is metadata, not a communication protocol. AI Card describes what a service does and who published it—it doesn't define how agents talk to each other (that's A2A), how models invoke tools (that's MCP), or how access decisions are made at runtime (that's [AuthZEN](/posts/authzen-authorization-api/)). All of those layers remain separate concerns with their own specifications. Policy evaluation is out of scope. The trust section tells you what attestations a service claims and how to verify the publisher's identity. Whether those attestations are sufficient for a given use case—whether the policy requires SOC 2 or HIPAA, whether the publisher's DID is in your allowlist—is an enforcement decision made by the consuming system, not specified by AI Card. The spec is also silent on how card content is kept fresh. An agent card describes capabilities that might change: a new tool added to an MCP server, a deprecated skill in an A2A agent. AI Card includes `updatedAt` timestamps and versioning fields, but the synchronization mechanism between publisher and consumer is not defined. Something like OPAL's policy sync model—which keeps OPA instances current with policy changes—has no equivalent here yet. Finally, it's worth being explicit about status. The specification is an active draft in a temporary Linux Foundation working repository. Field names, structures, and conformance requirements are still being refined through open issues and pull requests. The formal adoption vote by the A2A and MCP steering committees hasn't happened yet. Treat this as a signal of where discovery and trust metadata for the agentic ecosystem are heading, not as a stable target to implement against today. ## Enterprise implications For enterprises operating across both A2A and MCP deployments, the most immediate value AI Card offers is governance visibility. A unified catalog that lists every AI service an organization publishes, with publisher identity attached, is the kind of inventory that compliance teams ask for and that's currently assembled by hand from multiple disconnected sources. The trust layer maps directly to the enterprise supply chain concerns that the [security boundaries post](/posts/security-boundaries-agentic-systems/) covers in detail. Every MCP server an agent connects to is a dependency. Attestations in AI Cards give automated governance tooling something to check: does this tool server's catalog entry carry the attestation type my policy requires? Does the publisher identity match an approved vendor in my registry? These checks can happen at connection time rather than during a manual quarterly review. The well-known URL pattern also supports a zero-trust model more naturally than centralized registries. Rather than trusting a marketplace's claim that a service is safe, a consuming agent can fetch the publisher's own catalog entry, verify the publisher's DID independently, and check the attestation URIs directly. No intermediary needs to vouch for correctness. Whether AI Card achieves adoption through the A2A and MCP governance processes or its ideas flow back into those specs piecemeal is still an open question. The direction it points—unified metadata, verifiable trust, protocol-agnostic discovery—reflects real gaps that every enterprise building serious agentic workloads encounters eventually. The organizations that design their internal service catalogs around these principles now, regardless of which standard prevails, will have less rework to do when the ecosystem converges. {{< source title="AI Card Specification (Draft)" authors="Agent-Card Working Group, Linux Foundation" url="https://github.com/Agent-Card/ai-card" >}} {{< source title="AI Card Published Specification" authors="Agent-Card Working Group" url="https://agent-card.github.io/ai-card/" type="report" >}} --- *This content is from Agentic Academy (https://agentic-academy.ai/)* *Published: April 15, 2026*