AML.T0073Impersonationview on ATLAS ↗Adversary poses as a trusted entity (user, service, peer agent) to gain access or influence decisions.
← Atlas · ThreatsCritical
T9 · OWASP Agentic AI v1.1
Identity Spoofing and Impersonation
An attacker abuses authentication to impersonate an agent, user, or service, gaining unauthorised access while staying undetected, often by misusing persistent agent identities.
Definition
Identity Spoofing and Impersonation, also called Agent Identity Compromise, is the exploitation of authentication mechanisms to impersonate AI agents, human users, or external services. The attacker gains unauthorised access while remaining undetected. The particular concern in agentic systems is the misuse of formal, persistent agent identities (for example, Microsoft Entra Agent ID), which grant privileged long-term API access that bypasses the agent’s conversational interface and its guardrails.
What it looks like in practice
User Impersonation. An email-management agent is granted send-on-behalf-of access for a senior executive’s mailbox as part of a scheduling workflow. An attacker who has compromised the agent’s configuration (by modifying the system prompt via an indirect injection in a fetched calendar event) redirects the agent to compose and send messages that impersonate the executive. The messages are sent from the executive’s address with a valid DKIM signature because the agent’s mail-sending permission is legitimate. Recipients have no mechanism to distinguish these from genuine messages, and the executive does not know the impersonation occurred until a recipient responds.
Agent Identity Spoofing. An HR onboarding platform uses a dedicated agent identity to create user accounts, provision mailboxes, and grant initial access rights. An attacker extracts the agent’s service account credentials from an over-permissioned secrets manager (where the credentials were stored in plaintext rather than via a secret-reference pattern). Using those credentials directly via the HR platform’s API, not through the agent’s conversational interface, the attacker creates a dormant admin account with a plausible-looking name. The account passes the platform’s audit because the API call is authenticated with the legitimate agent identity; nothing in the log distinguishes a legitimate agent session from the attacker’s direct API call.
Behavioural Mimicry Attack. A multi-agent analytics system includes a trusted “data-validation agent” that other agents consult before writing results to a shared store. An attacker deploys a rogue process that listens on the inter-agent message bus and responds to validation requests with forged approval messages that match the format and signing scheme of the legitimate validator. Peer agents accept the forged approvals and write unvalidated data (in some cases adversarially crafted) to the shared store. The legitimate validator continues to operate normally in parallel; neither it nor the orchestrator detects the duplicate responder because the message bus does not enforce agent cardinality.
Cross-Platform Identity Spoofing. A sales agent is authorised to query a CRM and a billing system using different identities: a CRM service account and a billing read-only token. An attacker who has compromised the CRM service account observes that the billing system trusts requests that include a specific CRM session header. By replaying a CRM session header alongside a direct billing API call, the attacker impersonates the billing integration without possessing the billing token. The billing system logs the call as originating from the CRM service account, attribution that is technically accurate but misleading: the CRM account was not the intended caller, and the attacker’s activity blends into normal CRM-initiated traffic.
Persistent Agent Identity Takeover. An agent’s long-lived OAuth refresh token is stored in a cloud object store bucket that was inadvertently left with public read access during an infrastructure migration. An attacker discovers the bucket via a misconfiguration scanner, downloads the token, and uses it to authenticate as the agent identity continuously (including after the agent’s software is updated and redeployed) because the refresh token is valid until explicitly revoked. The agent platform continues to operate normally; the attacker’s sessions appear as a second instance of the agent, indistinguishable in the access logs from legitimate agent calls, until the token’s age or an anomaly threshold triggers a review.
Incriminating Another User. An attacker who has compromised one user’s agent session uses the agent’s identity-switching capability (intended for on-behalf-of delegation) to perform a damaging action (mass-deleting records) while presenting another user’s identity as the authorised principal. The action is logged as initiated by the victim user. When the deletion is investigated, the audit trail points to the wrong person and the attacker’s session trace has been obscured by the identity substitution. Reconstructing the true sequence requires correlating the session token’s issuance log against the action timestamp, a check that was not automated in the platform’s monitoring.
Why it’s dangerous
Persistent agent identities have larger blast radius than user sessions: they live longer, are scoped broadly to do the agent’s job across many calls, and are increasingly treated as enterprise-grade access principals. In multi-agent systems, agents authenticate to each other and inherit trust transitively, so impersonating one trusted agent can yield access across many.
Where it manifests
Model four seams. How is agent identity provisioned and rotated? Where are long-lived agent tokens stored, and who can access them? How do agents authenticate to each other? And how does privilege inheritance work across delegation chains?
Detection signals
Monitor the agent identity lifecycle and the inter-agent trust boundary:
- An agent identity authenticating from two or more distinct IP ranges, container environments, or cloud regions within a short window (e.g. under 5 minutes). This is a reliable signal of credential reuse or active token theft, since a single legitimate agent process has a stable source address.
- A refresh token or service account credential whose last-issued timestamp is older than the organisation’s stated rotation interval, paired with an active session using that credential. Flag for immediate rotation review.
- Inter-agent message bus: more than one process responding to the same agent identity’s queue or inbox in the same time window. Enforce cardinality via a heartbeat claim that only the authoritative process can update.
- An API call attributed to an agent identity whose source user-agent header, TLS fingerprint, or SDK version string does not match the expected deployment artefact. Direct API calls from attackers reusing stolen credentials often differ in client characteristics from the legitimate agent binary.
- On-behalf-of delegation events where the acting identity differs from the identity recorded as the initiating user in the same session trace. This indicates an identity substitution that was not requested by the user and was not logged as a policy-driven delegation step.
OWASP Top 10 for Agentic Applications 2026
The Agentic Top 10 (ASI01 through ASI10) is a separate practitioner-facing publication that maps onto the master Threats & Mitigations threat numbering. T9 is covered by the following Top 10 entries:
ASI03Identity & Privilege Abuseprimary When an agent acts on a user's behalf it inherits that user's credentials and permissions for the duration of the task. Attackers exploit this by manipulating delegation chains, role inheritance, or agent-to-agent trust, turning a narrowly scoped instruction into a credential that can chain every permission the principal holds, concurrently, in a single agent turn.
Source: OWASP Top 10 for Agentic Applications 2026 (Dec 2025) · the Top 10 is a compass into the master Threats & Mitigations taxonomy, not a replacement for it.
Design principles at stake
When T9 is present, these security design principles are the ones being violated or tested. Each links to the full principle; the mitigations below are how you restore them.
- Defence-in-DepthImpersonation works precisely when identity is checked once at admission and then trusted. Depth against T9 means cryptographic workload identity (SPIFFE/SPIRE SVIDs) so possession of a token does not equal identity, short-TTL scoped tokens via OAuth token exchange that force an attacker to compromise the renewal path rather than a single long-lived credential, and continuous behavioural monitoring that detects a spoofed identity by the anomaly of acting from the wrong workload origin. Each layer is independent, so a stolen key alone cannot complete an end-to-end impersonation.
- Zero TrustPersistent agent identities are the specific target of T9: they live longer than user sessions, are scoped broadly across many API calls, and are increasingly enterprise-grade principals. This is exactly the high-value target that zero-trust's "authenticate every request, every time" is built to protect. Per-instance SVIDs with short TTLs and a policy enforcement point re-queried at every tool call mean that even after a long-lived token is extracted from misconfigured cloud storage (the Persistent Agent Identity Takeover scenario), it expires before an attacker can chain enough calls to do damage.
- Confused-Deputy PreventionThe agent is a legitimately-privileged deputy; T9 exploits that by substituting a different principal's identity while keeping the deputy's credentials in play, for example by using an HR onboarding agent's token under a fraudulent identity to create accounts. Intent attestation that binds tool calls to a signed user intent digest, and draft-then-commit with a deterministic check between phases, verify not just that the credential is valid but that the original authorised principal genuinely requested the action.
- Agent-as-principal IdentityThe core of T9 is the absence of unique, cryptographically verifiable non-human identity: a 2026 survey found 93% of agent projects still use unscoped API keys, and when an orchestrator and six sub-agents share one key, any one of them can impersonate the others without detection. Per-instance SVIDs carried through OAuth token exchange (RFC 8693) that preserve both the user's sub claim and the agent's act claim make every action attributable to a specific instance, collapsing the anonymity that the Behavioural Mimicry Attack and Cross-Platform Identity Spoofing scenarios require.
- Complete MediationT9 most directly tests complete mediation because impersonation only persists when trust established at session start is cached and not re-verified at each subsequent call. A tool-gateway chokepoint that re-checks every call against the current agent's SVID and current task scope (not a session-level grant) means that even after a long-lived agent token is extracted, the next tool call fails the per-call verification and the attack halts.
Recommended mitigations
Auto-generated from the mitigation catalog: every mitigation whose coverage map includes T9, sorted by maturity tier (Tier 1 production-canonical first, then Tier 2, then Tier 3 research-stage).
- Tier 1SPIFFE(SPIFFE / SPIRE workload identity — cryptographic identities for every agent and service)
In most deployments, agents authenticate to one another with long-lived bearer tokens or shared secrets. If any one of those credentials is stolen, the attacker has persistent, platform-wide access until someone manually rotates it. SPIFFE replaces that model: each workload is issued a short-lived, cryptographically verifiable identity document, and every connection requires both sides to present one. No long-lived secrets traverse the network, and a compromised credential is worthless within its TTL.
why it helps Credential theft attacks depend on long-lived bearer tokens that remain valid after exfiltration. SPIFFE SVIDs rotate automatically on a short TTL; there is no static credential for an attacker to steal and reuse. Mutual authentication via X.509 SVIDs also ensures that even a replayed token cannot establish a connection without the corresponding private key.
- Tier 2Agent MFA(MFA for high-privilege agent identities — step-up attestation at credential issuance and action time)
An agent identity that holds broad write authority is a high-value target: compromising its credential gives an attacker persistent, authenticated access to every system that identity can reach. Multi-factor authentication addresses this by requiring a second factor at credential issuance time, so a stolen token is bounded to its issued lifetime and cannot be silently renewed. For non-human identities the second factor is workload attestation, hardware-bound key material, or certificate-backed proof rather than a phone or one-time code.
why it helps Agent identity spoofing requires an attacker to impersonate a specific agent identity convincingly enough to be issued credentials by the identity provider. Multi-factor attestation raises the bar: the attacker must compromise both the primary credential and the independent second factor simultaneously, which are typically bound to separate hardware or infrastructure trust roots.
An AI agent operates under a non-human identity (NHI): a service principal, a task role, or a workload credential. That identity produces a stream of access events that, for a well-scoped agent, forms a narrow and predictable behavioural baseline. Identity monitoring applies User and Entity Behaviour Analytics (UEBA) to that stream, alerting when an observed access pattern deviates statistically from the baseline. Because agent behavioural distributions are tighter than those of human users, a deviation is a higher-confidence signal, and a spoofed or stolen credential used from the wrong workload origin is exactly the anomaly the technique is built to detect.
why it helps Identity Spoofing is the use of a stolen or forged agent credential to impersonate a legitimate workload. The spoofed identity will access resources from an unexpected origin, at an unusual time, or with a resource mix that does not match the legitimate agent's baseline. Behavioural monitoring detects that divergence and fires a risk signal before the attacker can complete their objective.
- Tier 2Insider program(Insider threat program — personnel security for operators of high-privilege agentic systems)
Privileged-access personnel are the human layer behind every agentic system. A person with legitimate administrative credentials can tamper with logs, manipulate approval gates, or extract training data through authorised channels, and no technical control prevents it when the access itself is valid. An insider threat program addresses that gap: it governs who holds operator access, what they agree to, how quickly credentials are revoked on departure, and whether anomalous behaviour is surfaced before damage accumulates.
why it helps Credential-based identity spoofing is more probable when stale credentials from departed operators remain active. Timely off-boarding with a documented SLA removes those credentials before they become targets, and privileged-access reviews surface unused human credentials that represent equivalent exposure.
An inter-agent message travels through channels and intermediate agents the receiver did not originate. If nothing binds the message cryptographically to its source, any intermediate hop can substitute or inject content that the receiving agent will treat as authoritative. Message signing closes that gap: the source agent signs each message payload with its private key, and the receiver verifies the signature against a distributed trust bundle before the content reaches the reasoning layer.
why it helps Identity spoofing relies on a receiver having no way to verify that a message genuinely came from the claimed peer. Signing binds each message to the signing key of the originating agent, so a peer cannot impersonate a trusted agent without possessing its private key.
A Non-Human Identity (NHI) is the service account, machine principal, or formal agent identity under which an agentic system authenticates and acts. When an NHI is provisioned with broad scope, never rotated, and has no named owner, a stolen or leaked credential gives an attacker persistent access for as long as that credential remains valid. NHI lifecycle management treats each agent identity as a first-class governance object: provision narrowly with a declared scope and owner, rotate on a short schedule using platform-native short-lived credentials, audit every authentication and rotation event, re-attest that the identity is still needed, and decommission by deletion when the agent is retired.
why it helps Persistent Agent Identity Takeover requires that a stolen formal agent identity remain valid and authoritative long enough to be weaponised across sessions or pipelines. Aggressive rotation invalidates the credential before that window closes; prompt decommissioning ensures that an identity associated with a retired agent cannot be reused. The combination converts a potentially indefinite takeover into a bounded, time-limited exposure.
- Tier 2OOB verify(Out-of-band verification — independent-channel confirmation for irreversible agent actions)
An agent that can propose payments, update banking details, or modify production configuration is, by construction, a manipulation surface. If the only thing standing between a proposed change and its execution is the agent's own UI, a successful prompt injection or RAG poisoning attack requires no additional steps. Out-of-band verification breaks that dependency by routing a one-use confirmation code through a channel that is structurally separate from the agent's primary interaction channel, so an attacker who controls the agent's context cannot complete the approval without also compromising the user's registered secondary device.
why it helps Identity Spoofing through indirect prompt injection can cause an agent to act under false authority, but it cannot manufacture possession of the user's registered secondary device. OOB verification requires physical or credential access to that device before the spoofed action can commit.
- Tier 2Token TTL(Short-lived tokens — bounding the credential exploitation window for agent identities)
An agent identity backed by a long-lived bearer token grants access for as long as that token remains valid. If the token is stolen, logged, or extracted from a running process, the attacker holds working credentials for weeks or months without any further action. Short-lived tokens address this by issuing credentials with a time-to-live measured in minutes or hours, automated and renewed by the platform rather than a human. When a token expires, access ends: the attacker must win the renewal process as well, which requires compromising a harder target than the token itself.
why it helps Identity Spoofing via replayed or stolen tokens requires the captured credential to remain valid. Short TTL forces an attacker to sustain access through successive renewals rather than benefiting from a single theft, because each renewal requires the workload attestation or mTLS certificate that the attacker did not capture alongside the token.
Multi-agent variants: OWASP MAS Guide
The OWASP OWASP MAS Threat Modelling Guide v1.0 catalogues 2 named multi-agent variants of T9, anchored to specific MAESTRO layers. Each is a concrete attack pattern that emerges when this threat compounds across agents.
- L3Trust Exploitationextends T13, T9
Compromised agents leverage established peer reputation to perform malicious actions under trusted cover.
- CLIdentity Spoofing and Impersonationextends T9
Counterfeit agents that mimic trusted behaviours and credentials.
Source: OWASP MAS Threat Modelling Guide v1.0, §2 Overview of MAESTRO Framework — Extended Threat Scenarios + Cross-Layer table.
Catalogue extensions: Helmwart T18 to T49
This normalized catalogue includes 3 multi-agent entries based on the OWASP MAS Threat Modelling Guide v1.0 that extend T9. The source guide reuses some numbers between worked systems; these Helmwart entries provide stable detail pages, MAESTRO layers, and mitigation coverage.
- T34Wallet Key Compromise
Compromise of an agent's blockchain wallet private keys enables fund theft and agent impersonation on-chain.
- T36Smart Contract Vulnerability Leading to Agent Impersonation
A smart contract vulnerability lets an attacker impersonate an agent or gain unauthorised control of its on-chain actions.
- T40MCP Client Impersonation
Attacker impersonates a legitimate MCP client via stolen credentials or auth bypass, gaining unauthorised access to server resources.
Red-team pivot: MITRE ATLAS techniques
MITRE ATLAS catalogues adversary techniques against AI systems. Where this OWASP threat has an attacker-perspective counterpart, the ATLAS technique is shown below. That is what a red team would actually be doing on the wire. Use this for detection-signal anchoring, threat-hunting hypotheses, and IR runbooks. Source: mitre-atlas/atlas-data v5.6.0.
© 2026 The MITRE Corporation. ATLAS content is reproduced and distributed with the permission of The MITRE Corporation.
AML.T0074Masqueradingview on ATLAS ↗Adversary disguises an artefact (file name, agent card, MCP server) so it appears legitimate to humans or agents that route trust by name.
AML.T0088Generate Deepfakesview on ATLAS ↗Adversary generates synthetic media (audio, video, text in a person's style) to support impersonation, fraud, or manipulation.
Sources
- OWASP-Agentic-AI ↗ · 1.1 (Dec 2025) · Agentic Threats Taxonomy Navigator §Step 4; Threat Model T9
- MAESTRO ↗ · 1.0 (Apr 2025) · Layer 7 Agent Ecosystem; Cross-Layer Identity Spoofing & Trust Exploitation
Adapted by Helmwart from the OWASP source(s) above underCC BY-SA 4.0(changes: normalized IDs, added MAESTRO-layer, agentic-factor, and mitigation mappings). This entry is licensed CC BY-SA 4.0.