Securing MCP communication exposes the real identity boundary

At a glance

What this is: This is an analysis of how MCP changes the identity boundary for agentic applications, with a focus on securing agent-to-server communication, secret handling, and zero-trust enforcement.

Why it matters: It matters because IAM, PAM, and NHI teams now have to govern runtime tool connections, not just static credentials, across agentic, workload, and human-controlled environments.

👉 Read Riptides' analysis of securing MCP communication with workload identity

Context

MCP communication security is really an identity and trust problem. Once agents discover tools at runtime and call them across local or remote boundaries, static assumptions about trusted endpoints, stable credentials, and predictable request paths start to break down.

For IAM and NHI programmes, that shifts the question from whether a token exists to where that token can be exposed, who can invoke it, and which runtime identity can be trusted to use it. The control plane has to cover agents, MCP servers, and backend services together, not in isolation.

Key questions

Q: How should security teams govern agent-to-MCP communication?

A: Security teams should treat agent-to-MCP communication as a governed identity path, not just an application integration. That means binding access to workload identity, enforcing default-deny policy for tool destinations, and requiring traceable outbound requests. The goal is to prevent uncontrolled runtime discovery from turning into uncontrolled runtime access.

Q: Why do local MCP servers create secret exposure risk?

A: Local MCP servers often receive API keys or tokens through environment variables, which makes secrets visible to the process and potentially to logs, memory, and inspection tools. If the server is compromised, those credentials can be reused outside the intended boundary. Runtime injection reduces that exposure by keeping secrets out of user space.

Q: When should organisations require mTLS for MCP traffic?

A: Organisations should require mTLS whenever an MCP server is remote, externally managed, or able to reach third-party services on behalf of an agent. mTLS gives both sides a verifiable identity check before tool use begins. That helps prevent impersonation, unauthorized server access, and hidden network trust.

Q: What should IAM teams monitor to prove MCP governance is working?

A: IAM teams should monitor which workload identities are calling which servers, whether policy is default-deny, and whether outbound requests are auditable back to the calling agent. If those signals are missing, the environment may be relying on implied trust rather than enforced identity controls.

Technical breakdown

How agent-to-MCP traffic creates a new trust boundary

MCP decouples agents from tool implementation, which means the agent can discover and invoke servers at runtime rather than through a fixed integration path. That flexibility changes the trust model: the caller may be legitimate, but the server may be malicious, misconfigured, or a relay to untrusted endpoints. In local deployments, the server often runs as a subprocess and inherits environment variables, which creates a credential exposure path if the process is inspected or compromised. In remote deployments, OAuth2 and network reachability expand the boundary further. The core issue is that communication is now dynamic, not pre-bounded.

Practical implication: treat every agent-to-server path as an enforceable trust boundary, not an assumed-safe internal call.

Why kernel-level secret injection changes the attack surface

Kernel-level enforcement keeps secrets out of the application process by injecting them only when an outbound request matches policy. That matters because traditional environment-variable delivery exposes API keys and tokens to logs, memory inspection, and process introspection. By moving secret injection below user space, the identity layer can preserve least exposure while still letting the request succeed. This is not the same as rotation or vault storage. It is a delivery model that prevents the server from ever holding reusable credentials in the first place, which reduces both accidental disclosure and post-compromise abuse.

Practical implication: stop passing durable secrets into MCP servers when the runtime can inject credentials at the network boundary.

Why SPIFFE identities and mTLS matter for remote MCP servers

SPIFFE gives workloads a verifiable identity that can be checked before any tool call is allowed. When paired with mTLS, both sides of the exchange authenticate each other, so a server cannot simply accept traffic because it is reachable on the network. Policy then becomes identity-aware, using allowlists and trusted SPIFFE IDs to decide which server may receive a call. This is what turns remote MCP from a convenience layer into a governed communication layer. Without that, the protocol can become a path for impersonation, unauthorized calls, and hidden third-party reachability.

Practical implication: require workload identity and mTLS before permitting remote MCP tool use.

NHI Mgmt Group analysis

MCP security is an identity governance problem disguised as a transport problem. The article correctly shows that agent-to-server traffic is where prompt injection, impersonation, and token leakage converge. That means the security boundary is not the API call itself but the runtime identity that is allowed to make it. Practitioners should read MCP as a new governance surface for non-human identities.

Static secrets remain the weakest assumption in local MCP deployments. The traditional pattern of placing API keys in environment variables was designed for bounded process trust. That assumption fails when a server can be inspected, instrumented, or compromised after startup. The implication is that identity programmes must stop treating secret presence as equivalent to secret safety.

SPIFFE-backed workload identity turns remote MCP from network reachability into verified authorisation. The important shift is not that mTLS exists, but that policy can bind a specific workload identity to a specific destination. That creates a meaningful control for machine-to-machine communication across organisational boundaries. Practitioners should treat this as a workload identity governance pattern, not a narrow networking feature.

Identity blast radius is now defined by tool discovery at runtime. MCP lets agents expand their effective access path as they discover new servers and endpoints, which makes access review and entitlement scoping more complex than in static integrations. Governance teams should expect the real risk to sit in dynamically assembled communication chains, not just in the initial agent permission set.

Zero-trust language only matters here if it is enforced at the request layer. Default-deny policy, identity checks, and auditable call traces are what make the claim operational. Without those controls, MCP becomes another place where organisations assume trust because the workload is internal or the connection was previously approved. Practitioners should judge MCP by enforcement depth, not protocol branding.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• For the governance model behind this risk, see 52 NHI Breaches Analysis.

What this signals

Runtime tool discovery is widening the identity blast radius. As MCP-style integrations spread, security teams should expect policy to move closer to the request path and farther from provisioning time. The operational question is no longer whether an agent can reach a tool, but whether that reach is bound to an identity decision that can be enforced and audited.

The broader programme impact is that NHI governance and workload identity controls now need to cover dynamic communication patterns, not just credential lifecycle. For teams building that control surface, the strongest signal is whether identity assertions survive outside user space and remain visible in the logs that matter.

The underlying trend is that machine access is becoming more composable and more ephemeral at the same time. That combination favours organisations that can enforce policy at runtime and disadvantages those still relying on static trust in local processes or known endpoints.

For practitioners

• Separate agent identity from server access policy Define explicit allowlists for which MCP servers each agent may contact, then bind those decisions to workload identities rather than hostnames or environment-wide trust.
• Remove reusable secrets from MCP server environments Replace environment-variable injection with runtime secret delivery so API keys and tokens are never visible to the server process or its inspection surface.
• Require mutual TLS for remote MCP connections Make server authentication mandatory before any tool call, and reject endpoints that cannot present a trusted workload identity and certificate chain.
• Log every agent-to-server call with identity context Preserve auditable records that tie each outbound request to the calling workload, destination, and policy decision so investigations can reconstruct tool use precisely.

Key takeaways

• MCP changes the problem from tool access to governed runtime identity, because agents can now discover and invoke servers at execution time.
• Secret exposure, impersonation, and unauthorized access are all easier when MCP servers inherit static credentials or trust the network by default.
• Workload identity, mTLS, and auditable policy decisions are the controls that turn MCP communication into something IAM and NHI teams can actually govern.

Key terms

• Model Context Protocol: A protocol that lets AI agents discover and invoke tools and data sources at runtime. In security terms, it creates a new trust boundary because the caller and the tool can both change dynamically, which means identity, policy, and auditing must operate on each live request.
• Workload Identity: A machine identity assigned to a specific workload rather than a person. It allows systems to prove who they are to other services without relying on shared secrets alone, which is essential when tools, agents, and backend services exchange requests across local or remote boundaries.
• Kernel-Level Enforcement: A control pattern that intercepts network or credential handling below the application layer. It reduces exposure because the user-space process never needs to hold the secret material directly, which lowers the chance of leakage through memory inspection, logs, or process tools.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or operational governance in your organisation, it is worth exploring.

This post draws on content published by Riptides: Securing MCP Communication with Riptides. Read the original.