ACP — discoverable identity per agent

Frequently asked questions

What is the Agent Card Protocol?

ACP (Agent Card Protocol) is the discoverable-identity layer of the agent payments stack. Every AgentWallet agent publishes a signed, machine-readable identity card at a stable URL — its DID, the Principal it answers to, its public keys, the rails and tools it supports, and its reputation history. Counterparties (other agents, merchants, APIs returning HTTP 402) resolve the card before transacting so they can verify exactly who they're paying or being paid by. Think of it as DNS + TLS certificate + Schema.org markup for agent identity, all in one signed JSON document.

Where is the Agent Card published?

At /.well-known/agent.json on the agent's stable URL — the same convention browsers use for /.well-known/openid-configuration and TLS uses for ACME challenges. The document is content-addressable, served with strong caching headers, and signed so a counterparty caching it offline can still verify the public keys. The agent's DID resolves to the same document via standard DID Core resolution, so the identity is reachable whether the consumer prefers DNS-based discovery or DID-based discovery.

What's inside an Agent Card?

Seven fields, all required. (1) agent_id — the DID (did:agentwallet:ag_… or did:web:…) that uniquely identifies the agent. (2) principal — pointer to the KYC'd human or service Principal accountable for this agent. (3) public_keys — ES256 JWKs for verifying any AP2 mandate signed by this agent. (4) endpoints — MCP URL, AP2 inbound URL, A2A messaging URL, payment receivers. (5) accepts — the rail set the agent will settle on (x402_usdc_base, spt, ach, sepa, etc.). (6) capabilities — typed list of what the agent can do (send_payment, receive_payment, sign_mandate, etc.). (7) reputation — pointer to the on-chain reputation history (optional, opt-in).

How is an Agent Card verified?

Three checks, all automatic. (1) Signature — the card is signed by the Principal's WebAuthn-bound key; the verifier checks the signature against the Principal's published public key. (2) Freshness — the card carries an issued-at timestamp and a max-age; expired cards are re-fetched before transacting. (3) Revocation — the card includes a revocation URL the verifier hits to confirm the agent hasn't been paused or killed. The identity.discover MCP tool wraps all three checks and returns a schema-validated, freshness-stamped document so callers don't have to implement the verification themselves.

How does ACP relate to AP2 and MCP?

Three orthogonal layers of the same protocol stack. MCP is the typed tool-call interface — how the LLM expresses intent. ACP is the discoverable identity layer — how the counterparty verifies who they're talking to. AP2 is the mandate layer — cryptographic authorization for what the agent is allowed to spend. They compose: an LLM uses MCP to call a tool, ACP to discover the counterparty, AP2 to prove the spend was authorized, then x402 (or a fiat rail) to actually settle. Removing any one of the three leaves the stack incomplete — you'd have identity without authorization, or authorization without discovery, or tools without trust.

Is ACP an open standard?

Yes. The Agent Card schema is published as an open JSON Schema; any agent — not just AgentWallet's — can publish a compliant card at /.well-known/agent.json and any verifier can validate it without a vendor SDK. AgentWallet implements the public spec exactly. The reputation pointer is optional and standards-tracking work is ongoing through the broader agent-payments working group alongside AP2.