Agent impersonation
An attack where an agent poses as another agent or a trusted provider to borrow its access or reputation, via copied names, look-alike domains or stolen keys.
Agent impersonation is an attack in which one agent falsely presents itself as another agent, or as an agent of a trusted provider, to obtain access, trust or reputation that belongs to the real one.
Common routes.
| Route | What the attacker relies on | Standard countermeasure |
|---|---|---|
| Copied labels | Self-asserted names: a User-Agent string, or the name and provider fields in an Agent Card |
Cryptographic identity: signed requests (RFC 9421), signed Agent Cards |
| Look-alike domain | A client that trusts a card from a domain resembling the real provider’s | Check the serving domain and signing key against a trusted source |
| Stolen signing key | Valid signatures from a compromised key | Key rotation and revocation; A2A forbids verifying with revoked keys |
| Reused credential | A token issued to one agent, replayed by another | Credentials bound to the requesting agent; certificate-bound tokens (RFC 8705) |
The IETF Web Bot Auth charter names protection against impersonation as one reason for its work, and its draft notes that a User-Agent string used alone can be spoofed by anyone.
What signatures settle. A signed Agent Card or signed request proves that the holder of a key produced it. It does not prove that the key belongs to the organization the card names. The A2A specification lets clients keep a trusted key store for known providers, but it does not define how keys are mapped to providers. That mapping is where impersonation is stopped or missed.
In chains of agents. A2A warns that credentials exchanged in-band can pass through every agent in a chain. It recommends binding each credential to the agent that requested it, so an intermediate agent cannot reuse it to act as the original requester.
A different “impersonation”. RFC 8693 uses the word for a legitimate token exchange in which A receives a token that makes it indistinguishable from B within a defined set of rights. Delegation, the alternative the RFC describes, keeps A identifiable as A. For agents acting for people, delegation lets a business see which agent actually acted.
Neighbouring terms. Agent identity is what an impersonator fakes. Know Your Agent (KYA) checks are the business-level defence.
Sources
- A2A Protocol Specification, section 8.4.3: Signature Verification (accessed )
- A2A Protocol Specification, section 7.6.3: In-Task Authorization Security Considerations (accessed )
- IETF draft: HTTP Message Signatures for automated traffic (draft-ietf-webbotauth-httpsig-protocol) (accessed )
- IETF Web Bot Auth (webbotauth) working group charter (accessed )
- RFC 8693: OAuth 2.0 Token Exchange, section 1.1: Delegation vs. Impersonation Semantics (accessed )
- RFC 8705: OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens (accessed )