Technical guide · Standard or specification
A2A Agent Card: capability discovery without hidden authority
How an A2A Agent Card describes identity, interfaces, skills, and security requirements while keeping credentials and execution authority out of public discovery.
- Published
- Updated
Scope: this guide explains a technical signal observed by AI Web Check. It does not claim that the signal causes ranking, indexing, citation or inclusion in AI answers.
Role of the Agent Card
A2A uses an Agent Card as a public description of an agent: identity, capabilities, skills, supported interfaces, and security requirements. The standard well-known path is /.well-known/agent-card.json.
The card helps a client decide how to interact with the agent. It should not disclose private credentials, internal state, or technical details that are unnecessary for interoperability.
What AI Web Check evaluates
For confirmed commerce context, AI Web Check performs one bounded fetch of the public Agent Card and validates a supported current or legacy structure. It does not send A2A messages, create tasks, or invoke skills.
The audit stops at discovery metadata and safety of declared endpoints.
Public versus authenticated information
Public discovery can include the agent name, description, provider, capabilities, skills, interface URLs, and security schemes. API keys, bearer tokens, private keys, cookies, signed sessions, or credential-bearing URLs do not belong there.
If an implementation needs an extended card with sensitive information, authenticated access should be treated as a separate boundary.
Common mistakes
- Publishing an HTTP, localhost, private-network, or credential-bearing interface URL.
- Advertising a transport or skill that the server cannot actually execute.
- Describing a security scheme while accepting the operation without authorization checks.
- Embedding API keys, bearer tokens, or private JWK material in the card.