An Agent Card can tell another system how to find and communicate with an agent. It cannot, on its own, prove that the agent should be trusted for a particular decision.
The A2A Protocol uses an Agent Card as a machine-readable description of an agent service. A card can publish the agent's name, provider, endpoint, supported interfaces, capabilities, skills, input and output modes, and security requirements. Clients use this metadata to discover a suitable agent and configure an interaction.
This is essential infrastructure. Without a common description, discovery becomes a collection of private integrations. The danger begins when discovery metadata is treated as a trust decision.
What the Agent Card actually establishes
| Card field or mechanism | What it helps establish | What remains unanswered |
|---|---|---|
| Name, description, provider | Declared service identity and purpose | Whether the claims are accurate or complete |
| Skills and capabilities | What the service says it can perform | Quality, safety, independence, and current permission |
| Endpoint and interface | Where and how a client can communicate | Which runtime, model, and tools are behind the endpoint |
| Security schemes | How a caller should authenticate | Whether the requested action is within a valid mandate |
| JWS signature | Origin and integrity of the signed card | Truth of the claims and safety of future behavior |
Five trust questions live outside the card
- Principal. Which human, team, or organization is the agent representing in this interaction?
- Mandate. Which action was authorized, under what conditions, for how long, and with which approval limits?
- Runtime. Which model, policy, memory system, and tool configuration are currently serving the endpoint?
- Interest. Which commercial relationships, reward signals, or shared dependencies could affect the agent's choice?
- Relationship. How is this agent connected to the counterparties, evaluators, and beneficiaries of the outcome?
Public identity and private capability need separation
A2A supports public Agent Cards and authenticated extended cards. This matters because detailed skills, internal endpoints, or operational metadata can reveal sensitive information. Public discovery should expose enough information to begin a safe interaction without publishing the complete attack surface.
Selective disclosure also creates a verification problem. Two clients may receive different descriptions of the same agent. A trust layer should record which card version and disclosure scope informed each transaction, then bind that evidence to the resulting task.
Stale cards create silent authority drift
Agent Cards are cacheable because capabilities and endpoints usually change less often than messages. Caching improves performance, but it introduces time into the trust model. An agent may change its tools, model, provider, security requirements, or available skills while a client continues using an older card.
Cache controls and ETags help clients refresh metadata efficiently. High-impact actions still need transaction-time checks. A card that was valid yesterday cannot prove that a delegation, permission, or policy remains valid now.
How Agent Card abuse can look
- Capability inflation. An agent advertises a skill but routes the work to an unreviewed third party.
- Identity laundering. Several related agents present separate providers while sharing the same controlling operator.
- Endpoint substitution. A valid-looking service name points to a runtime whose model or tool permissions changed after review.
- Evaluator collusion. An agent and its supposed verifier share an incentive to approve the same outcome.
- Card replay. Old metadata remains accepted after a provider, skill, or mandate should have been revoked.
A practical verification sequence
| Stage | Check | Decision |
|---|---|---|
| Discovery | Retrieve the expected card and verify its signer | Is this the intended service? |
| Qualification | Validate skill evidence and disclosure scope | Is it suitable for this task? |
| Authorization | Bind principal, mandate, limits, and expiry | May it perform this action now? |
| Execution | Track runtime, tools, messages, and counterparties | Is observed behavior consistent with the mandate? |
| Outcome | Record beneficiaries, dependencies, and final effects | Did a suspicious joint pattern emerge? |
AgentCollusion starts where self-description ends
The Agent Card is a useful input to oversight. It provides a declared baseline that can be compared with runtime evidence. AgentCollusion's research question is what happens after discovery: whether agents act within their mandates, whether supposedly independent actors share hidden dependencies, and whether individually acceptable actions form a suspicious collective outcome.
The right mental model is a business card, not a passport. Read it, verify it, and use it to begin due diligence. Do not confuse it with a complete trust decision.
