AgentCards: Identity & Capability Credentials

• AgentCards are explicit, machine-verifiable identity and capability credentials that bind an agent's unique identifier with defined capabilities and policies.
• They support rapid agent discovery and secure inter-agent communication through standardized, signed JSON documents and on-chain anchoring.
• AgentCards integrate portable authorization and economic metadata, creating scalable frameworks for trust mediation and cross-boundary interactions.

AgentCards are explicit, machine-verifiable identity and capability credentials for autonomous software agents, providing a standardized schema for discoverable identity, capabilities, constraints, and—where extended—authorization and payment information. They encode self-proclaimed or externally attested properties in portable formats, enabling critical infrastructure for agentic ecosystems including agent-to-agent (A2A) communication, distributed trust mediation, cross-boundary authorization, and economic interaction. AgentCards materialize as signed JSON documents, smart contract state, or verifiable credentials, forming the foundation for scalable agent registries, inter-agent protocols, portable authorization, and composable trust mechanisms.

1. Formal Definition and Core Schemas

An AgentCard is a signed data structure binding a unique agent identifier (e.g., DID, URL, blockchain address) to an explicit set of capabilities, policies, trust modalities, and, where relevant, operational endpoints. The canonical data fields include:

• agentID: unique agent identifier
• publicKey: long-term verification key
• version: schema or semantic version
• capabilities: declared skills or API points
• policies: enumerated operational or risk constraints
• supportedTrust: declared trust models (Claim, Brief, Proof, Stake, Reputation, Constraint)
• issuedAt, expiresAt: timestamped validity window
• signature: over the canonicalized document, using the agent’s private key

In A2A web protocols, the AgentCard appears as JSON at a well-known HTTPS endpoint (e.g., /.well-known/AgentCard.json), while in Ethereum’s ERC-8004 or A2A-on-chain, the record is deployed as a smart contract with structured storage (Hu et al., 5 Nov 2025, Vaziry et al., 24 Jul 2025). Off-chain and on-chain representations are cryptographically cross-verifiable.

Example AgentCard JSON snippet (Vaziry et al., 24 Jul 2025):

{ "name": "WeatherAgent", "description": "Provides weather forecasts for given GPS coordinates", "url": "https://weather.example.com/a2a", "version": "1.0.0", "capabilities": { "streaming": false }, "defaultInputModes": ["application/json"], "defaultOutputModes": ["application/json"], "skills": [ { "id": "urn:skill:forecast", "name": "forecast", "description": "Returns 7-day weather forecast" } ] }

In portable authorization paradigms, as outlined in (Madhira, 12 May 2026), an AgentCard (or AgentCard credential) is realized as a three-layer construct: (1) credential container (JWT/JWS, VC, OAuth Rich Authorization Request), (2) authorization payload (agent_id, permissions, issuer_id, constraints, audience), (3) enforcement engine bindings for runtime evaluation.

2. Roles in Agent Discovery, Trust, and Authorization

AgentCards function as both identity assertions and discovery records in decentralized agent registries and protocol overlays. During capability discovery, a querying agent enumerates available AgentCards (directly or via indices such as NANDA or ERC-8004 Identity Registry), inspects fields for compatibility, and authenticates the public key for subsequent RPC authentication (Hu et al., 5 Nov 2025, Vaziry et al., 24 Jul 2025). The process is sub-second and minimally latent due to lightweight JSON parsing.

AgentCards can represent purely self-asserted (Claim-only) trust, but production protocols layer additional mechanisms (Briefs, Proofs, Stake, Reputation) for higher-stakes interactions. Within enterprise and economic infrastructure, AgentCards underpin portable authorization: they encode not only identity but also explicit, formally typed “permissions” and “constraints,” linked to authorization policies and runtime enforcement using OPA/Rego, Cedar, Zanzibar PDPs, or OpenID-based AuthZEN (Madhira, 12 May 2026).

3. Security Architecture, Threat Model, and Limitations

The security posture of baseline AgentCards (Claim) is weak: the data is unilaterally asserted by the agent and cryptographically self-signed, with authenticity and freshness contingent on the integrity of the HTTPS/TLS channel, the accuracy of publicKey–agentID mapping (anchored in trusted registries or on-chain), and the timely revocation/expiry of issued cards (Hu et al., 5 Nov 2025). Primary attack vectors include:

• Forgery: Malicious AgentCards for valid agentIDs (mitigated by on-chain anchoring/Briefs)
• Replay: Use of expired or superseded cards (mitigated by short TTLs, strict versioning)
• Sybil: Mass-issuance of low-cost identities (mitigated by registration fees, on-chain staking)
• Revocation Lag: Window of false acceptance proportional to revocation polling interval

AgentCards offer minimal Sybil or collusion resistance unless composed with Stake, Proof, or robust Brief registration. For high-impact tasks, protocols escalate to stake deposits and cryptographic Proof-of-Action (e.g., TEE attestation, ZK proofs). The Tiered blueprint (T0–T3) prescribes match of trust level to risk, illustrated as:

Risk Tier	Trust Requirements	Example Mechanisms
Low (T0)	Claim (+Brief optional)	AgentCard signature (HTTPS)
Medium (T1)	Stake deposit + Claim/Brief	On-chain escrow
High (T2/T3)	Stake + Proof (TEE, ZKP)	PoP + on-chain settle

4. Discoverability, On-Chain Anchoring, and Economic Integration

AgentCard publication employs both off-chain and on-chain mechanisms (Vaziry et al., 24 Jul 2025). A smart contract template (AgentCardContract) written in Solidity stores all canonical fields and exposes events for updates and payments. Discoverability flows:

• On-chain: Factory and Registry contracts store addresses of AgentCard contracts. Off-chain indexers ingest “AgentUpdated” or “ServicePaid” events, allowing GraphQL or REST-based search.
• Off-chain: Agents host /.well-known/agent.json for compatibility and redundancy.
• Hybrid: Hashes of off-chain JSON are anchored on-chain for integrity checks.

AgentCards can embed payment metadata for x402 micropayment protocols: token contract addresses, receiver, per-call price, and validity intervals. The x402 payment flow uses EIP-3009 “transferWithAuthorization” on Ethereum-compatible ledgers, mediating HTTP-402-to-blockchain payment with auditability and settlement finality. Preliminary benchmarks indicate ~50 ms lookup latency and <1 s payment confirmation on testnets, with the main economic bottleneck being on-chain gas costs for write operations; read/lookup remains performant (Vaziry et al., 24 Jul 2025).

5. Comparison with Alternative Trust and Authorization Paradigms

A systematic comparison of AgentCards (Claim) with Brief, Proof, Stake, Reputation, and Constraint models establishes:

Model	Security	Latency/Cost	Social Robustness
Claim	Low	Minimal	Weak (Sybil-prone)
Brief	Medium	Moderate	Gatekeeper robustness
Proof	High	High	Depends on cryptographic anchor
Stake	Med-High	Mod-High	Economic cost to cheat
Reputation	Variable	Low-Mod	Collusion/whitewash-exposed
Constraint	High (safety)	Dev overhead	N/A (sandbox only)

Hybridization is essential: AgentCards excel for fast discovery and baseline identity binding, but higher-stakes or adversarial settings require brief-based anchoring of keys, on-chain registration with slashing, and runtime cryptographic proof (Hu et al., 5 Nov 2025, Madhira, 12 May 2026).

In portable authorization, AgentCards map into credential containers (JWT/JWS, VC, OAuth RAR), supporting expressive policies: numeric, temporal, list, and string constraints; fail-closed conjunction; policy attenuation under delegation; and semantic resolution via profile vocabularies. This enables decision-consistent, delegation-aware, and cross-engine authorization with auditability (Madhira, 12 May 2026).

6. Engineering Guidelines, Best Practices, and Open Issues

Best practices for deployment and maintenance (Hu et al., 5 Nov 2025, Madhira, 12 May 2026):

• Persist agentID→publicKey mapping via a Brief (X.509, VC, or on-chain registry)
• Use short AgentCard lifetimes (≤1 hour) with strictly monotonic version numbers
• Serve cards over HTTPS with mutual TLS when practical; log all fetch/verify events
• Restrict fields to minimal discovery set, rotate keys with new card versions
• Publish in global registries and maintain revocation indices
• For payment-enabled cards, cross-validate off-chain JSON and on-chain state
• Integrate proof-of-action and escrow for high-risk actions via composable protocol escalation

Emerging open issues include: robust Sybil resilience at scale (beyond stake/bond), delegation semantics for complex workflows, and standardization of AgentCard interfaces for emerging multi-agent economic protocols. Empirical evaluation of on-chain discoverability and payment models suggests hybrid on-chain/off-chain patterns are optimal for balancing liveness, cost, and auditability in large-scale agentic networks (Vaziry et al., 24 Jul 2025).

7. Role in Role-Decomposed LLM Systems and Frontier Benchmarks

AgentCards, as data structures and credential primitives, are relevant to the role-decomposed benchmarking paradigm exemplified by AgentCARD in LLM agent teams (Jiang et al., 28 May 2026). While the naming is convergent rather than ontological, both frameworks emphasize role specialization, explicit capabilities, and composable aggregation of properties and cost. In AgentCARD, agent teams are evaluated over cost-accuracy fronts, with role decomposition (planner/executor/verifier) as the axis for assignment of models, deployment, and performance measurement. The ability to explicitly advertise and discover agent skills and constraints using AgentCard or equivalent mechanisms aligns with the operational requirements for scalable, heterogeneous LLM-based agent workflows.