Unsigned Agent Cards weaken the first trust decision in an agent-to-agent exchange because consumers cannot reliably confirm who they are talking to before work begins. That creates a spoofing path for malicious agents, especially where endpoints are easy to discover and downstream actions are automatically trusted.
Why unsigned Agent Cards break the first trust check
Agent Cards are meant to let one agent identify another before any delegation, tool use, or downstream action happens. If the card is unsigned, the consumer has no cryptographic basis to distinguish a real publisher from a forged one, so the exchange starts from assertion rather than proof. That weakens the control point that should stop trust from being granted too early.
In practical terms, the break is not only “the card is missing a signature.” The larger failure is that the receiving system can no longer treat the advertised identity, metadata, or capabilities as reliable enough to drive an automated decision. In an A2A flow, that is enough to turn a discovery step into an attacker-controlled entry point.
A signed card does not solve every risk by itself, but it makes authenticity checkable. That matters because agent-to-agent integrations often rely on rapid machine decisions, and those decisions are only safe when the claimed counterparty can be verified before the first request is accepted.
How verification failure enables spoofing and trust abuse
Once verification is skipped, a malicious agent can present a convincing but false card and look legitimate enough to be selected by an orchestrator, router, or peer agent. That is especially dangerous when agent endpoints are easy to enumerate and when the consumer automatically trusts the card’s declared role, scopes, or supported actions. The result is a spoofing path that can look like normal service discovery.
Verification also protects the trust boundary between “who is this?” and “what may it do?” If the first question is answered incorrectly, later checks may be applied to the wrong principal. In agent systems, that can lead to confused-deputy behaviour, unauthorized delegation, or downstream actions being performed on behalf of an impostor.
In other words, verification failure is not just an authentication issue. It can cascade into authorization failure, because policy is only as good as the identity assertion underneath it.
What practitioners should treat as broken when signatures are absent
Unsigned or unverified cards break four things at once: identity assurance, endpoint trust, capability trust, and the safety of automated routing. That means the consumer cannot reliably answer whether the peer is genuine, whether the metadata was altered, whether the advertised capabilities are accurate, or whether the card was replayed from a different context.
The most important operational consequence is that trust becomes implicit instead of evidence-based. When that happens, an attacker only needs a discoverable endpoint and a persuasive card format to insert a fake participant into what should have been a controlled exchange.
This is why the weakness is usually more severe in systems that chain agents together or let agents act quickly without human review. A single unverified introduction can contaminate later hops, because downstream agents often assume the first trust decision was already sound.
Risk and Threat Considerations
Unsigned Agent Cards create a direct spoofing and impersonation risk in multi-agent environments. The danger is highest when card lookup is public, trust decisions are automated, or downstream actions are executed with little friction, because an attacker can present a forged identity and inherit the confidence that should have belonged to a verified peer.
Failure mechanism: The receiver accepts an untrusted card as if it were authentic, then uses that unauthenticated metadata to select a peer, route work, or grant delegated access. That can let an impostor enter the exchange before any stronger control, such as policy enforcement or step-up validation, has a chance to stop it.
Impact: Malicious agents can impersonate legitimate ones, trigger unauthorized workflows, or steer other agents into unsafe delegation paths. At scale, the same failure can produce cross-agent trust pollution, where one bad introduction makes later automated decisions easier to subvert.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Unsigned A2A cards enable fake agent identity and privilege claims. |
| ASI07 — Insecure Inter-Agent Communication | A2A card verification is part of securing inter-agent trust and exchange. | |
| Recommendation — Require verifiable agent identity before any delegated action or tool use. Validate peer authenticity before accepting inter-agent messages or routing. | ||
| CSA MAESTRO | UNKNOWN — Multi-Agent Environment, Security, Threat, Risk and Outcome | A2A trust establishment is central to multi-agent threat modelling and control design. |
| Recommendation — Model trust boundaries and verify agent provenance before coordination begins. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | Agents verifying each other is a service-to-service authenticity problem. |
| AC-3 — Access Enforcement | Spoofed cards can lead to unauthorized delegated actions if access is not enforced. | |
| Recommendation — Authenticate service-like agents before permitting inter-agent exchange. Enforce authorization after identity is verified, not before. | ||
Practitioner Guidance
What to verify: Treat signature validation as mandatory before any agent consumes card metadata. Verify both provenance and freshness, and reject cards that cannot be bound to a known trust anchor or expected issuer.
Decision rule: If the card cannot be verified, stop at discovery and require a safer onboarding path rather than allowing the agent to proceed on self-declared identity alone. If the system must allow dynamic onboarding, bound that exception tightly and review it as a higher-risk trust event.
What good looks like: The consumer only accepts cards whose authenticity, issuer, and intended scope are checkable before first contact, and every trust decision is explicit enough to be audited later.
Practitioner takeaway: The key failure is not just forged metadata, it is unearned trust at the moment the agent decides who to talk to. If that first decision is weak, every later automation step inherits the risk.