Agent Card: Agent2Agent (A2A) Protocol Metadata Format
An Agent Card is a JSON metadata document that an A2A-compliant agent publishes to advertise its identity, skills, endpoint, and supported authentication schemes. It enables discovery and capability negotiation between agents, but the A2A specification does not verify that a published Agent Card's claims are accurate. Enterprises must independently validate identity, capabilities, and access boundaries before granting trust at runtime.
What an Agent Card Declares
Before examining how discovery and trust work in practice, it helps to see what information an Agent Card actually contains.
Identity
Name, description, and provider information for the publishing agent.
Capabilities
Skills, default input/output modes, and supported task types.
Endpoint
The service URL other agents use to initiate interaction.
Security schemes
Declared authentication methods such as OAuth2 or API key.
What Is an Agent Card
An Agent Card is a JSON-formatted document defined by the Agent2Agent (A2A) protocol. A2A is an open protocol originally announced by Google in April 2025 and now governed by the Linux Foundation under a technical steering committee. It is designed to let independent AI agent systems discover and communicate with one another, distinct from protocols like Anthropic's Model Context Protocol (MCP), which address agent-to-tool and agent-to-data connections rather than agent-to-agent communication.
An Agent Card functions as a self-published capability manifest. It typically includes the agent's name, description, and provider information, a version identifier, declared capabilities, supported input and output modes, a list of skills, and the security schemes the agent supports for authentication. Conceptually, it resembles service discovery documents such as OpenAPI or WSDL, but scoped to agent-to-agent interaction rather than general API description.
How Agent Cards Enable Discovery and Negotiation
The A2A specification defines a well-known URI convention, typically /.well-known/agent.json, as a standard location for hosting an Agent Card. This allows a requesting agent to retrieve another agent's card by resolving a predictable path on the target domain. The specification also describes alternative discovery mechanisms, including curated registries and direct configuration, rather than mandating a single approach.
Once an Agent Card is retrieved, capability negotiation follows a straightforward pattern: the requesting agent parses the card to determine whether the target agent supports compatible input and output modes and the specific skills required for a given task. This negotiation happens before any task is initiated, allowing agents built by different teams or vendors to establish compatibility without prior manual integration.
The Trust Gap: Declared Versus Verified
The core limitation of the Agent Card model is that it is declarative, not verified. The A2A specification allows an agent to state its authentication scheme, but it does not itself confirm that the publishing agent's identity claims are accurate or that its declared capabilities match its actual runtime behavior. Security scheme metadata describes how to authenticate to an endpoint; it is not proof that the endpoint is trustworthy or that the agent behind it performs as advertised.
Discovery via well-known URI also depends on the security of underlying web infrastructure. Because this discovery method assumes DNS and TLS-level trust in the hosting domain, the integrity of an Agent Card is partially inherited from infrastructure controls outside the A2A protocol itself, rather than guaranteed by the specification. The protocol documentation is explicit that implementers, not the protocol, are responsible for validating Agent Card authenticity and enforcing access control. There is no built-in trust or reputation verification system.
Key point: a declared authentication scheme tells you how to authenticate to an endpoint. It does not tell you whether that endpoint, or the agent behind it, should be trusted.
Governance Considerations
Because Agent Cards are self-published, the burden of verifying identity and capability claims falls on the enterprise, not the protocol. This has direct implications for least-privilege access: an agent's declared skills and authentication scheme should be treated as a starting point for policy definition, not as an authorization decision in themselves.
Enterprises in regulated environments should evaluate whether relying on unverified Agent Card claims is sufficient for internal risk and compliance requirements around access control. Since A2A has no native reputation or certification system, governance controls such as internal approval workflows, independent attestation, and audit logging of agent-to-agent interactions must be layered on separately. Specification changes managed by the Linux Foundation's technical steering committee may also alter Agent Card fields or security guidance over time, so tracking version changes is a recurring governance task rather than a one-time integration step.
Architecture Decisions for Enterprise Adoption
- 1
Discovery method selection
Well-known URI discovery is decentralized and harder to govern at scale; curated registries allow centralized vetting of which Agent Cards are trusted.
- 2
Provenance mechanism
A registry, allowlist, or signing process is needed to establish Agent Card provenance beyond what the base specification provides.
- 3
IAM reconciliation
Declared authentication schemes in the Agent Card must be reconciled with existing enterprise identity and access management systems, since they are informational rather than enforced.
- 4
Schema versioning
The Agent Card schema is versioned and evolving under Linux Foundation stewardship, requiring architecture that tolerates backward-compatible field changes.
Evaluation Checklist Before Relying on Agent Cards
- Confirm whether the Agent Card's identity and provider claims are corroborated by an independent source, not just self-declared.
- Verify that declared skills and input/output modes are reconciled against actual observed runtime behavior.
- Map declared security schemes to existing IAM policy rather than treating them as pre-approved access.
- Establish a provenance mechanism (registry, allowlist, or signing) beyond default well-known URI discovery.
- Log and audit agent-to-agent interactions independently of what the Agent Card claims.
- Track Agent Card schema and specification changes as an ongoing governance task, not a one-time review.
Frequently Asked Questions
Does the A2A protocol verify an Agent Card's claims?
No. The A2A specification allows agents to declare identity, capabilities, and authentication schemes, but it does not include a mechanism to independently verify that these declarations are accurate. Verification is left to the implementing organization.
How is an Agent Card different from an API specification like OpenAPI?
Both serve a discovery and description function, but an Agent Card is scoped to agent-to-agent interaction, including skills and negotiated input/output modes, rather than describing a general-purpose API surface.
Is A2A a replacement for MCP?
No. A2A addresses communication between independent agents, while MCP addresses how an agent connects to tools and data sources. The two are described as complementary rather than competing protocols.
Govern Agent-to-Agent Trust at Runtime
Agent Cards describe what an agent claims to be. Runtime governance determines what it is actually allowed to do. Trussed AI provides runtime policy enforcement, agent identity controls, and audit logging for agent-to-agent interactions.
Explore Runtime Governance