Signed Agent Card

also known as Verifiable Agent Card, Signed Agent Capability Card

Cryptographically sign an agent's published capability card so a consuming agent can verify it was issued by the claimed domain before binding to or delegating to it, closing the spoofing gap in agent-to-agent discovery.

Context

Agents discover each other at runtime by fetching a published descriptor — an agent card or capability manifest — that advertises identity, endpoint, skills, and authentication needs. In an open, cross-vendor setting, a client agent reads such a card and then binds to the remote agent, sending it tasks and sometimes delegated credentials. Discovery assumes the card it fetched genuinely belongs to the party it names.

Problem

A plain capability card is just a JSON document at a URL, and anything can serve one. Nothing stops a hostile party from publishing a card that claims another organisation's identity and skills, or from tampering with a card in transit, so a client that trusts the card at face value can be steered into delegating work or credentials to an impostor. Discovery needs a way to check that a card truly came from the domain it claims, without a central registry vouching for every agent.

Forces

Open cross-vendor discovery wants any agent to publish a card and any client to read it; trust wants the client to know the card is authentic before acting on it.
A central authority vouching for every agent would add a bottleneck and a single point of control that decentralised discovery is meant to avoid.
Verification has to ride with the card itself, because the consuming agent has no prior relationship with the publisher and may never contact a third party.

Example

A travel agent service and an airline's booking agent have never interacted. The travel agent fetches the airline agent's card from a well-known URL to learn its endpoint and skills. Because the card is signed with a key tied to the airline's domain, the travel agent verifies the signature before sending a booking task and a scoped credential; an impostor card served from a look-alike host fails verification and is dropped.

Diagram

sequenceDiagram participant P as Publisher (issuer domain) participant W as Well-known URL participant C as Consumer agent P->>W: publish card + signature (domain key) C->>W: fetch agent card C->>C: canonicalise and verify signature vs issuer alt signature valid C->>P: bind, send task / scoped credential else missing or invalid C->>C: reject card end

Solution

Therefore:

Add a signature to the agent card. The publisher signs the card's canonical content with a key whose authority traces to the domain that issued it — for example a JWS signature the consumer can validate against the issuer's published key — and embeds the signature in the card. A consuming agent that fetches the card first canonicalises and verifies the signature: a card whose signature is missing, malformed, or not traceable to the claimed issuer is rejected before any binding. Only a card that verifies is trusted enough to drive endpoint selection, capability binding, and credential delegation. Because the proof travels in the card, verification needs no central broker, and each consumer checks authenticity independently.

What this pattern forbids. A consuming agent must not bind to or delegate to a remote agent on an unsigned card; a card whose signature is missing or does not verify against the claimed issuer is rejected before any task or credential is sent.

And the patterns that stand alongside it, or against it —

complementsAgent Capability Manifest★— Let each agent publish a standardized self-description — identity, skills, endpoint, and auth needs — at a well-known location, so others discover it and bind by capability at runtime instead of through hardcoded coupling.
complementsCryptographic Instruction Authentication·— Wrap system/developer instructions in cryptographically signed blocks that user-generated text cannot reproduce; train or scaffold the model to refuse instructions lacking a valid signature.
complementsDelegated Agent Authorization★— Have an agent act for a principal using scoped, short-lived, revocable delegated credentials rather than the principal's own static secrets, so each action stays attributable across the principal-to-agent-to-subagent chain and a compromise is contained.