A disguised agent rejected by a verifier scanner beside a genuinely verified badge.

Defending against agent spoofing

Agent spoofing is any attempt to make a service treat an unauthorised actor as if it were a trusted agent with a trusted mandate. The goal is rarely to break cryptography; it is to exploit the gap between who the caller claims to be and what the system actually verifies. Classic spoofing is impersonation — presenting someone else’s name or token. Agent spoofing adds newer shapes that are specific to systems that reason over text and call tools: instructions hidden in content the agent reads, deputies that act with their own privileges rather than the caller’s, and messages replayed after the fact.

This guide maps the main attack patterns, the defences that actually raise the cost, and the signals that should make you look. It builds on the verification model in How to verify an agent and the scoping discipline in How to scope an agent’s permissions.

The attack patterns

PatternHow it worksWhat it defeats
ImpersonationAttacker presents a self-declared name, User-Agent string, or stolen bearer token and is believedServices that trust labels over proof; unbound tokens
Prompt-injection-driven identity abuseMalicious text in a web page, file, tool output or another agent’s message redirects the agent to act on the attacker’s behalf, using the agent’s legitimate identitySystems that conflate “the agent can do X” with “the agent should do X now”
Confused deputyAn agent or tool server acts with its own broad privileges rather than the caller’s narrow ones, so a low-privilege request triggers a high-privilege actionServices that authorise the deputy, not the principal
ReplayA captured token or message is re-sent to duplicate or escalate an actionUnbound bearer tokens; messages with no freshness check

The OWASP Top 10 for Agentic Applications (2026) captures several of these as named risks, including Agent Goal Hijack (ASI01), Tool Misuse (ASI02) and Identity & Privilege Abuse (ASI03) — where an agent’s identity or permissions are misused or escalated beyond intended limits. OWASP’s MCP Security Cheat Sheet names the confused deputy problem directly: the server executes actions with its own, often broad, privileges rather than the requesting user’s permissions, and warns about message tampering and replay after TLS termination.

Defences: proof, not labels

Require strong credentials, never self-declared identity. A name or header is a claim, not proof. An authorised agent should present something cryptographically verifiable — an attestable workload identity, an issuer-signed token, or a verifiable credential — that a relying party can check against a published trust anchor. SPIFFE’s identity documents are designed to be “proven as authentic” and “proven to belong to the presenter”; a shared service account proves neither.

Require per-action proof of possession. A bearer token is a password: whoever holds it can use it. DPoP (RFC 9449) binds the token to a key the agent holds and signs a fresh proof per request; mutual TLS (RFC 8705) binds it to a client certificate. Both are explicitly aimed at making a stolen token insufficient, and DPoP is intended to allow detection of replayed tokens. Per-action proof turns “possession of a secret” into “proven control of a key, right now”.

Bind tokens to audience and issuer. A token minted for one service should be useless at another. Check the issuer against a trust anchor you control, and check the audience (and, for MCP, the intended resource) so a token cannot be passed through to a different upstream API. OWASP’s MCP guidance is blunt: validate that each access token was issued for this server as its intended audience, and never pass an MCP access token to an upstream API.

Separate the deputy’s privileges from the principal’s. The confused deputy is defeated by authorising the request, not the component. Carry the agent’s delegation and the principal into every call, and make the tool server or gateway evaluate the scoped action against that delegation — enforcing least privilege per request rather than trusting the server’s ambient rights. The OWASP remedy for the confused-deputy case in MCP is the same shape: narrow, per-server scoped tokens and least privilege.

Treat every instruction as untrusted content. Prompt injection is the identity-abuse delivery mechanism of the agent era. OWASP LLM01 notes that injected input can “enable unauthorized access” and “execute arbitrary commands in connected systems”, and that defences should include constraining model behaviour, enforcing privilege control and least privilege, and requiring human approval for high-risk actions. Two design rules follow: enforce authorisation in code, outside the model’s interpretation, and label untrusted content so the model treats it as data rather than commands. OWASP is explicit that filtering alone does not establish safety — encoded and multilingual injections evade filters.

Use content provenance for ingested content. When an agent acts on a document, image or file, provenance helps distinguish origin from impersonation. The C2PA specification defines cryptographically verifiable Content Credentials that bind provenance claims to an asset, so a relying party can check that content came from where it claims. Provenance does not make content trustworthy in itself, but it turns “an anonymous file the agent read” into “a file with a verifiable origin” — a meaningful input to an action gate.

Prevent replay. Require freshness: short token lifetimes, per-request proofs with a unique identifier and replay cache, audience checks, and a signed nonce where a record claims to be live. The absence of a freshness signal is what lets a captured message be reused.

Detection signals

Prevention is not perfect, so watch for the shapes of an attack in progress:

  • An action that is in scope for the credential but out of character for the agent’s declared purpose.
  • New tools or servers invoked, or a known tool invoked with parameters it has never used.
  • Parameter anomalies — a payment to a new counterparty, a transfer just under an approval threshold, a query against a data store the agent never touches.
  • Lateral use of the same token — one credential appearing at several audiences, or at an audience it was not minted for.
  • Timing anomalies — bursts at unusual hours, or replayed identifiers seen twice.
  • Supplied content that reads like instructions — an ingested page, document or tool output that tries to change the agent’s goal.
  • Discontinuities in a trace — a delegated chain with a missing step.

The common thread: compare what was allowed with what was expected. That comparison needs the audit record described in Audit trails for agents — actor, principal, mandate and decision — to be possible at all.

Checklist

  • Identity is cryptographically verifiable, never self-declared
  • Every action carries per-action proof of possession, not a bare bearer token
  • Tokens are bound to an intended audience and checked against a trusted issuer
  • Authorisation evaluates the delegated scope (actor + principal), not the deputy’s ambient rights
  • Access tokens are never passed through to a different upstream API
  • Authorisation is enforced in code, independently of the model’s interpretation
  • Ingested content is labelled untrusted; instructions inside it are not obeyed
  • Provenance is checked for content that triggers consequential actions
  • Freshness (short lifetimes, nonces, replay caches) prevents replay
  • Detection compares allowed actions with expected actions, per agent and per trace

FAQ

Is agent spoofing just phishing with extra steps?

The delivery differs and so do the defences. Traditional phishing targets a human’s judgement; prompt-injection-driven identity abuse targets an agent that already holds a valid mandate, so the credential is legitimate and the goal is wrong. That is why scope, per-action proof and approval gates matter as much as identity: you are constraining what a correctly-identified agent can be pushed into doing.

Does a verifiable agent identity stop spoofing?

It stops the simplest form — presenting a fake identity — and raises the cost of the rest. It does not stop an attacker who hijacks a genuinely identified agent through injected instructions, nor a confused deputy that over-privileges the component. Identity is necessary but not sufficient; it must be paired with scoping, per-request enforcement and detection.

Why does the confused deputy keep recurring?

Because it is an authorisation mistake, not a crypto mistake: the component is trusted with broad rights and then used as a proxy for someone with fewer. The fix is architectural — carry the principal’s authority through and enforce least privilege at the point of action — and it is easy to regress whenever a new integration is added with “just enough” access for the developer, not the caller.

Not legal advice. Some of the controls here (human oversight for high-risk actions, records duties, incident reporting) have regulatory dimensions that vary by jurisdiction and risk class. Treat this as security engineering guidance and confirm compliance obligations with qualified counsel.

Primary sources

Know Your Agent (KYA) explains agent identity, verification and accountability. This is an explainer, not legal or compliance advice — see our Sources & methodology. New to KYA? Start with What is Know Your Agent? and the glossary.