Research guide · A2A trust
How to verify an A2A agent before delegation
A2A makes it possible to discover an agent and learn what it claims it can do. That is not the same as deciding whether you should trust it with a task, a credential, a dataset or a wallet. The safest implementation separates card integrity, provider identity, trust evidence and invocation authorization into different checks.
Published 12 September 2026 · sources checked 12 September 2026
v1.0
A2A release line that added signed Agent Cards for production trust
JWS
signature format defined by the A2A AgentCardSignature model
5
trust-signal categories in the current proposal — not a stable standard
The stable A2A layer
A signed Agent Card proves less than many buyers assume
The current A2A specification defines the Agent Card as the machine-readable discovery document for an agent's interfaces, skills and security requirements. It can be published at /.well-known/agent-card.json, and A2A v1.0 added JWS signatures so a client can verify card integrity and origin before interaction.
Signature verification answers a narrow question: did the canonical card arrive unchanged from a key you accept for that provider? It does not answer whether the software behind the endpoint is competent, whether its claims are current, whether its runtime has been compromised, or whether it should be allowed to spend money or act on private data.
Pre-delegation checklist
Eight checks before an agent gets authority
1
Resolve the provider-owned Agent Card
Start from the expected domain and fetch the well-known Agent Card. A directory listing, copied JSON blob or search result is discovery evidence, not the identity root by itself.
2
Validate transport and schema
Require HTTPS for production, confirm the card parses against the A2A version you support, and inspect supportedInterfaces rather than guessing which endpoint or binding to call.
3
Verify the Agent Card signature
A2A v1.0 supports JWS-signed Agent Cards. Verify at least one signature when present, canonicalize exactly as the specification requires, and resolve the signing key through a key source your policy accepts.
4
Keep metadata outside the instruction hierarchy
Descriptions, skill names and other remote card fields are untrusted input. Never concatenate them into a privileged system prompt as if they were instructions from your own operator.
5
Inspect security schemes before credentials
Read the Agent Card securitySchemes/security requirements and acquire credentials out of band. Do not hand a bearer token, API key or wallet authority to an endpoint merely because the card advertises a capability.
6
Verify trust evidence independently
Reputation, attestations, on-chain credentials and behavioral scores should be signed, fresh and scoped. The verifier's own trusted key set or registry is the trust boundary; a self-declared JWKS URL is not sufficient on its own.
7
Authorize the exact invocation
Agent-level trust is not task-level permission. Apply limits for action type, data scope, counterparties, spend, duration and side effects before each sensitive delegation.
8
Record and re-check change
Pin the accepted card version, endpoint, signing key, capabilities and trust-policy result. Re-verify when the card, key, extension set, skill surface or payment requirement changes.
Identity & integrity
Who published this card, and has it changed?
Domain ownership, TLS and a valid Agent Card signature can give a client a defensible identity/integrity chain. Pinning the accepted provider key or trusted JWKS source is stronger than blindly following whatever key URL arrives inside untrusted metadata.
Authorization
What is this agent allowed to do right now?
A trustworthy agent may still be inappropriate for a particular action. Apply per-task constraints to credentials, spend, recipients, file access, external side effects and expiry. A portable trust score should never become a portable permission token.
Current proposal · not stable A2A
What the trust.signals[] proposal is trying to solve
A2A issue #1628 is an active proposal for an Agent Card trust extension. The current draft groups independently verifiable evidence into five categories: on-chain credentials, on-chain activity, vouch chains, behavioral evidence and governance attestations. It proposes a shared signature/JWKS verification pattern and explicitly treats the consumer's configured trusted key set as the trust boundary.
That direction is useful because discovery and reputation are converging, but builders should not ship as if trust.signals[] were already a finalized A2A field. A2A has a formal extension model and governance process; proposal-stage schemas can still change. Implement behind an extension/version boundary and preserve a fallback path for peers that only speak the stable core protocol.
Untrusted metadata
Do not turn an Agent Card into a system prompt
A current A2A samples security issue demonstrates why this matters: remote Agent Card descriptions and skill text can become a prompt-injection vector when a client renders them directly into an LLM instruction template. Even a correctly signed card can contain content that is dangerous to interpret as privileged instructions.
Treat remote card fields as data. Parse them into constrained structures, quote or isolate free text, and let your own policy decide whether a skill is eligible. Integrity tells you who said something; it does not make the statement safe to execute.
Payment boundary
KYA, A2A trust and x402 answer different questions
Know Your Agent work is trying to make software identities, consent and trust legible across payment networks. A2A provides discovery and communication semantics. x402 provides a machine-native way to challenge for and verify payment. None of those layers should silently inherit authority from another.
A practical buyer flow is therefore: resolve the provider → verify the Agent Card → verify trust evidence → authorize the requested task → inspect any payment challenge → enforce spend policy → execute → record the result. Keeping those verdicts separate makes revocation and incident analysis far easier.
Minimal acceptance policy
Trust the chain, not a single score
allow delegation only if:
agent_card_origin == expected_provider_domain
transport == https
schema_version in supported_a2a_versions
signature_valid == true when signature is present
signing_key in trusted_provider_keys
remote_metadata treated_as == untrusted_data
credentials_requested <= approved_auth_scope
trust_evidence.fresh == true when required
task_authority <= human_or_policy_grant
payment_amount <= spend_limit
otherwise: deny or require escalationContinue the research
Separate identity, trust, delegation and payment
If you are building an agent that will transact, use the A2A checks here alongside zFinia's KYA and x402 verification guides. The goal is not more trust badges; it is a reproducible decision path before software gets authority.