Security in and around MCP: Part 3 — MCP Server Identity

Read full article from Maia Iyer here: https://medium.com/kagenti-the-agentic-platform/security-in-and-around-mcp-part-3-mcp-server-identity-10d6768d96c1/?source=nhimg

Read part 2 here: https://medium.com/kagenti-the-agentic-platform/security-in-and-around-mcp-part-2-mcp-in-deployment-65bdd0ba9dc6/?source=nhimg

Read part 1 here: https://medium.com/kagenti-the-agentic-platform/security-in-and-around-mcp-part-1-oauth-in-mcp-3f15fed0dd6e/?source=nhimg

As enterprises adopt Model Context Protocol (MCP) to power agentic applications, most security discussions have centered on authorization — ensuring agents only access resources they’re allowed to. But authorization is only half of the picture. Without strong authentication and identity, authorization is meaningless. If an MCP Client cannot verify the true identity of an MCP Server, malicious actors can impersonate legitimate services, poison tool outputs, or exfiltrate sensitive data.

This post explores how workload identity can help MCP Clients distinguish trusted servers from malicious ones, preventing exploitation scenarios such as tool poisoning, rug pulls, and cross-server tool shadowing. By anchoring MCP deployments in strong identity guarantees, enterprises can build the trust fabric required for safe adoption of agent-enabled workflows.

The Threat: Malicious MCP Servers in Action

• Tool Poisoning – Hidden malicious instructions in tool descriptions (not visible to users) trick agents into exfiltrating sensitive data.
• Rug Pull Attacks – MCP Servers initially verified as trustworthy later swap implementations, silently altering behavior.
• Cross-Server Tool Shadowing / Jumping the Line – A malicious MCP Server manipulates benign agent interactions with other servers, rerouting outputs or commands.

These attacks exploit the fact that, today, MCP Clients largely assume MCP Servers are trustworthy. That assumption no longer holds in adversarial or large-scale enterprise contexts.

Why Identity is the Missing Piece

To mitigate these risks, MCP Clients must be able to ask: “Who is this MCP Server, and can I trust it?”

Just as humans prove identity with passports, workloads in modern IT environments prove identity with cryptographically signed documents from an Identity Provider (IdP). This lets systems:

• Verify that a workload is who it claims to be.
• Enforce deny-by-default trust boundaries.
• Apply granular access policies based on attested attributes (e.g., namespace, container hash, version).

This shift means MCP isn’t just about delegated access (OAuth tokens) — it must be paired with strong workload authentication.

Designing MCP Server Identities

Key design considerations for MCP Server identity:

• Attestable attributes – IdP must verify key properties (namespace, workload type, container hash).
• Immutability – Identities should only change if attributes (e.g., container version) change.
• Granularity – Enough detail to distinguish between different MCP Servers within the same namespace.
• Non-overlapping – Each MCP Server identity must be unique.

Example mappings:

• Too Broad: Namespace-based identity (“restricted-prod-mcp-servers”) — ensures some trust, but can’t distinguish individual servers.
• Too Fragile: Identity tied to tool descriptions — not immutable, changes at runtime.
• Strong: Identity tied to namespace + container SHA — hard to fake, resistant to rug pulls.

Defense Against External and Internal Attackers

• External Attackers – Without IdP-issued credentials, malicious MCP Servers cannot present verifiable identities. Clients can deny by default.
• Internal Attackers – Even if an attacker deploys a rogue MCP Server inside the IdP’s domain, a granular identity schema ensures clients only connect to vetted servers on an allow-list.

Identity also improves auditability — even if malicious servers run internally, their distinct identities allow precise logging, detection, and remediation.

Tying Identity to OAuth

OAuth handles authorization (who can do what). Identity providers handle authentication (who is this). The two are complementary:

• Instead of long-lived secrets, OAuth can leverage JWT-based client assertions (RFC 7523) or x509 certificates (RFC 8705).
• Workload identities enable secure token exchange, ensuring least-privilege delegation across MCP components.
• This removes the operational burden of managing static secrets, while ensuring each MCP component is cryptographically tied to a verifiable identity.

Key Takeaways

• Authorization without authentication is meaningless: Without strong MCP Server identity, attackers can impersonate services and trick agents.
• Identity-first MCP: IdPs provide cryptographically signed workload identities, enabling granular policies, deny-by-default trust, and full auditability.
• Granular schemas matter: Broad identity definitions are insufficient — attributes like container SHAs provide resilience against rug pulls and malicious code swaps.
• Identity + OAuth together: Delegated access (OAuth) must be paired with verified identities to ensure tokens aren’t issued to impostors.

Looking Ahead

This post focused on MCP Server identity. In the next installment, we’ll explore Agent Identity — how AI agents themselves can be issued verifiable identities, enabling MCP Servers to authenticate, authorize, and contain them safely.