Definition
An attacker impersonates a legitimate Model Context Protocol (MCP) client to gain unauthorised access to an MCP server and its resources. The attack may involve credential theft or exploitation of weaknesses in the client authentication mechanism. Once impersonating the legitimate client, the attacker can invoke tools, retrieve resources, and access data sources that the MCP server exposes, with the full apparent authority of the legitimate client.
What it looks like in practice
An attacker obtains the long-lived API token used by a legitimate MCP client to authenticate with an MCP server that provides access to a company’s financial data store. The token was committed to a developer’s dotfiles repository and discovered via an automated secret-scanning sweep. The attacker uses the token to connect to the MCP server, issues a series of resource retrieval requests, and downloads the contents of the financial knowledge base (T28 RAG Data Exfiltration path). The server’s per-client access controls register all requests as coming from the legitimate client; nothing in the server’s access logs distinguishes the attacker from the genuine agent.
Why it’s dangerous in multi-agent context
MCP’s trust model is client-server: the server grants access based on client identity. If client identity can be spoofed, the attacker inherits all the data access and tool invocation rights of the impersonated agent. Because MCP standardises the access pattern, the same credential-reuse technique can work across multiple servers simultaneously if credentials are not scoped per-server. T30 (Insecure Inter-Agent Communication Protocol) creates a credential interception path: an attacker who can eavesdrop on unencrypted MCP traffic can harvest the client credentials in transit.
Detection signals
An impersonating client has the right credential but tends to behave differently from the genuine agent it is mimicking: different network origin, unfamiliar query patterns, or access to resources the legitimate agent has never requested.
- An MCP client authenticating from an IP address or CIDR range not seen in that client’s prior 30-day connection history: the MCP server should record the source IP on every session establishment and alert on first-seen network locations.
- A burst of resource retrieval requests immediately after authentication, retrieving a broad cross-section of the knowledge base rather than the focused set of resources the legitimate agent normally accesses. Alert when the breadth of distinct resource identifiers retrieved in a single session exceeds the client’s historical 95th percentile.
- A valid long-lived token used outside the business hours or time zone of the legitimate agent: session tokens should carry not just expiry but expected usage window metadata, enabling anomaly detection.
- The same client token appearing in connection logs from two geographically distinct IP addresses within a short window (credential sharing or simultaneous impersonation): flag concurrent sessions from non-adjacent network locations for the same token.
- A secret-scanning tool (e.g., trufflehog, gitleaks) reporting a match for MCP credential patterns in any public or developer repository: integrate secret scanning into CI and alert on any hit that matches the MCP token format.
Mitigations
- Use short-lived tokens bound to a specific session and server; reject tokens that are replayable across different servers or that exceed a defined lifetime.
- Enforce mutual TLS (Transport Layer Security) on all MCP client-server connections: both parties present verified certificates, eliminating credential-only impersonation.
- Store MCP client credentials in a secrets manager and rotate them on a defined schedule; never commit them to version control or configuration files.
- Monitor per-client access patterns on the MCP server; alert on unusual resource retrieval volumes, unfamiliar query patterns, or access from unexpected network locations.
Relation to base threat (T1–T17)
T40 extends T9 Identity Spoofing and Impersonation. Where T9 addresses the broad class of agent identity compromise, T40 is the MCP client identity instantiation: the trust anchor that an MCP server uses to grant access is the client credential, and its theft or forgery grants the attacker the agent’s full resource access scope. T30 (Insecure Inter-Agent Communication Protocol) is the transport-layer precursor that enables credential interception.
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. T40 is covered by the following Top 10 entries:
-
ASI03 Identity & Privilege Abuse contributing 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 T40 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-Depth A long-lived API token committed to a dotfiles repository is a single credential whose theft grants the attacker the legitimate client's full resource access scope. Because the access pattern is indistinguishable from normal agent operation, the server's access logs provide no signal. Relying on a single credential as the trust anchor means one discovery event yields complete compromise. Depth means short-lived session-bound tokens that cannot be replayed across servers as the credential layer, mutual TLS so both client and server present verified certificates and credential-only impersonation is eliminated, secrets manager storage with rotation on a defined schedule so that a committed credential expires before it can be exploited, and per-client access pattern monitoring with alerts on unusual retrieval volumes or unfamiliar query patterns as the detective layer.
- Zero Trust MCP's trust model grants access based on client identity verified at session start; but once an attacker obtains the long-lived token, every subsequent request is authenticated as the legitimate client and no further verification occurs. Zero trust requires that authorisation is re-checked at every resource retrieval, not just at session establishment, and that no implicit trust flows from network location or prior authentication. Short-lived session-bound tokens enforce re-authentication at a frequency that limits the exploitation window, mutual TLS ensures that both parties present verified identities on every connection, and per-client access pattern monitoring applies continuous verification against expected behaviour rather than treating a valid credential as a perpetual grant.
- Agent-as-principal Identity The MCP client credential is the agent's identity on the server, and because the stolen token is a long-lived, server-unscoped secret, its compromise transfers the agent's complete resource access authority to the attacker with no time limit and no server restriction. The identity controls that directly counter this are short-lived tokens bound to a specific session and server so that a stolen credential is valid only for the remaining session lifetime and cannot be replayed against other servers, mutual TLS so that client identity is tied to a certificate rather than a replayable secret, and secrets manager storage with rotation so that credentials discovered after the fact are already expired: converting a static identity credential into a continuously verified, short-lived assertion.
Recommended mitigations
Auto-generated from the mitigation catalog: every mitigation whose coverage map includes T40, sorted by maturity tier (Tier 1 production-canonical first, then Tier 2, then Tier 3 research-stage).
- Tier 1 SPIFFE (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 MCP client impersonation requires the attacker to produce a valid identity credential for the target client. SPIFFE mutual TLS at the MCP transport layer binds each client connection to a short-lived SVID tied to workload attestation. An attacker cannot impersonate a client without producing a valid SVID, which requires compromising the attestation mechanism, not merely stealing a token.
- Tier 2 MCP server attestation (MCP server attestation — cryptographic proof of server identity and binary integrity)
An MCP client connecting to a server has no built-in way to verify that the server at a given address is the expected workload or that its binary has not been replaced. An attacker who can intercept or substitute the server exploits that gap directly. MCP server attestation closes it by requiring the server to present cryptographic proof of two properties before the connection proceeds: that it holds a valid workload identity bound to a trusted certificate, and that its binary matches a signed hash recorded at build time.
why it helps MCP client impersonation is the threat where an attacker operates a server that passes as a legitimate one to an unsuspecting client. Cryptographic attestation makes impersonation structurally infeasible: the attacker must produce a valid SPIFFE SVID issued by the trusted SPIRE control plane and a Rekor-anchored binary hash matching the expected binary, neither of which is available without access to the signing infrastructure.
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.
AML.T0073 Impersonation view on ATLAS ↗ Adversary poses as a trusted entity (user, service, peer agent) to gain access or influence decisions.
AML.T0012 Valid Accounts view on ATLAS ↗ Adversary obtains and abuses legitimate user or service credentials for initial access, persistence, privilege escalation, or defence evasion.
Agentic angle: Agents often run under long-lived service accounts whose blast radius exceeds the original task scope.
AML.T0055 Unsecured Credentials view on ATLAS ↗ Adversary discovers credentials stored in plain configuration files, environment variables, or model context where they should not be exposed.
Agentic angle: Agent configuration files (system prompts, tool descriptors, MCP manifests) are a fresh credential exposure surface.
References
- OWASP MAS Threat Modelling Guide v1.0 (April 2025) §5 Anthropic MCP — Layer 3 Agent Frameworks.
Sources
- OWASP-MAS-Guide ↗ · 1.0 (Apr 2025) · §5 Anthropic MCP — Layer 3 Agent Frameworks