Securing MCP communication exposes the real identity boundary

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Riptides's blog post: MCP communication shifts the security problem from tool access alone to runtime identity, policy enforcement, and secret handling across agents, local servers, and remote servers.

Why it matters: IAM, PAM, and NHI teams need to treat MCP connections as governed trust boundaries because runtime tool discovery can expose credentials and widen unauthorized access paths.

Context

MCP communication creates a governance gap because agents can discover and invoke tools at runtime across boundaries that were previously implicit or trusted. In practice, that changes who and what must be authenticated, authorised, and audited when an agent reaches a server.

The NHI problem is not only whether a server can be reached, but whether the secret material used for that connection ever becomes visible to the process that handles it. Once environment variables, tokens, or client certificates are handed to the wrong layer, the boundary has already failed.

This article frames MCP as an identity and trust problem, not just a transport problem. That makes it directly relevant to NHI governance, workload identity, and policy enforcement for agent-to-server communication.

Key questions

Q: What breaks when MCP servers rely on environment variables for secrets?

A: Environment variables turn local MCP servers into secret holders, which means a compromise, debug dump, or process inspection can expose reusable tokens. The safer model is request-time credential injection, where the server can act on a secret without ever being able to read or store it in user space.

Q: When should teams prioritise mTLS and workload identity for MCP traffic?

A: They should prioritise it whenever an agent talks to a remote MCP server or any endpoint outside a fully trusted runtime. mTLS with workload identity matters when policy must verify both the caller and the server before tool execution, especially across network or organisational boundaries.

Q: What are the signs that MCP trust is being applied too loosely?

A: Common warning signs include dynamic connections to unknown servers, credentials passed through environment variables, and no auditable link between a tool call and the workload that made it. Those patterns indicate the communication path, not the tool, is the weak control point.

Q: How should security teams enforce policy when coding agents use MCP servers?

A: Security teams should treat MCP server access as a governed control surface, not an informal developer convenience. Define which servers are allowed, who can approve them, and what policy checks run before use. Visibility into active servers matters because agentic coding can otherwise expand trust faster than review processes can track. Governance should be consistent, lightweight, and enforced automatically.

Technical breakdown

Why agent-to-MCP communication becomes a new trust boundary

MCP decouples the agent from the implementation details of tools and services, which is exactly why the trust model changes. The agent can discover and invoke servers at runtime, including local subprocesses and remote endpoints, so the security question shifts from static configuration to dynamic authorisation. That runtime flexibility creates exposure to prompt injection, impersonation, token leakage, and unauthorised access because the communication path itself becomes a security boundary. In NHI terms, the identity of the calling workload and the identity of the server both matter before any tool call is allowed.

Practical implication: treat every MCP connection as a policy-controlled trust decision, not a simple application integration.

How kernel-level identity changes secret handling for MCP servers

Local MCP servers often receive API keys or tokens through environment variables, which means the server process can inspect, leak, or persist them. Kernel-level enforcement changes that by intercepting outbound calls and injecting credentials only at request time, so the server never directly handles the secret value. That matters because secrets exposed to user space can surface in memory, logs, process introspection, or compromised child processes. The technical distinction is between secret possession and secret use: the server may need to authenticate, but it should not own reusable credentials that can be extracted later.

Practical implication: move from credential exposure to request-time credential injection for local MCP workloads.

Why SPIFFE identity and mTLS matter for remote MCP traffic

For remote MCP servers, the article describes a model where both client and server carry SPIFFE identities and establish mutual TLS before any tool call is permitted. That gives the policy engine something stronger than network location or static allowlists: a verifiable workload identity bound to the runtime environment. In practice, this turns remote tool access into an identity assertion problem. The important architectural point is that the connection is validated on both sides, and unauthorised endpoints are denied by default. This is the NHI layer that keeps runtime tool use from becoming unaudited lateral access.

Practical implication: require workload identity and mTLS for remote MCP paths, and deny untrusted servers by default.

Breaches seen in the wild

• Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MCP turns identity into the control plane for agent-to-tool access. The article shows that the core risk is no longer just whether a tool works, but whether the agent, server, and downstream endpoint are each governed as separate identities. That is a different model from traditional application integration, where trust is often inherited from deployment context. Practitioners should treat runtime tool discovery as a governed identity event, not a convenience feature.

Environment-variable secrets are a structural failure mode for local MCP servers. The article’s local-server example demonstrates that once tokens are injected into process memory and environment state, the server can expose them through logs, introspection, or compromise. That is classic NHI secret handling risk, but MCP makes it more acute because the server itself may be only a temporary subprocess. The implication is that secret ownership and secret use must be separated much more tightly than conventional app patterns allow.

Runtime allowlisting is stronger than static trust in agentic integrations. The article’s default-deny policy model matters because MCP enables dynamic server discovery, which makes pre-approved integration lists less sufficient on their own. If the agent can choose endpoints at runtime, then governance has to evaluate the presented workload identity and destination identity before each call. The practical conclusion is that zero-trust controls must operate at the communication boundary, not only at onboarding.

SPIFFE-backed identity gives NHI governance a language for agent-to-server trust. The article is not just about transport security, it is about binding workload identity to runtime communication and auditability. That makes traceability, policy enforcement, and forensic reconstruction materially stronger across local and remote MCP deployments. Teams should view SPIFFE not as an implementation detail, but as the identity primitive that makes MCP governance operational.

Identity boundary drift is the real MCP security problem. When agents can invoke servers at runtime, the boundary between identity, policy, and secret handling shifts away from the application layer and toward request-time enforcement. That means legacy assumptions about trusted subprocesses, safe environment variables, and implicit server legitimacy no longer hold. Practitioners should re-evaluate whether their governance model still matches where execution and trust actually occur.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• Read next: Top 10 NHI Issues

What this signals

Runtime trust has replaced static integration trust: MCP pushes security decisions into the moment of tool invocation, which means allowlists, identity assertions, and audit logs matter more than the tool catalog itself. For practitioners, the key question is whether the control plane can still see the request before the agent acts on it.

MCP-specific risk is now visible in the secrets layer as well: 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026. That is a warning that runtime convenience can quickly turn into credential sprawl if secrets are still treated as configuration data.

Identity boundary drift: The practical failure is not just unauthorized access, but the loss of a clean boundary between the agent, the server, and the downstream service. Governance teams should expect MCP to force tighter workload identity, stronger policy enforcement, and better request-level traceability.

For practitioners

• Define explicit MCP server allowlists Allow only named servers and deny all others by default, so agent runtime discovery cannot expand trust beyond approved destinations.
• Remove reusable secrets from server environments Stop passing API keys and tokens through environment variables or process memory when a local MCP server can instead receive credentials at request time.
• Bind MCP traffic to workload identity Require SPIFFE-based identity and mutual TLS for remote agent-to-server communication so policy can verify both sides before a tool call executes.
• Trace every agent-to-server request Log the agent workload identity, destination server identity, and runtime environment for each MCP request so compliance and forensics have a complete chain of custody.

Key takeaways

• MCP changes the security model by making runtime communication, not static integration, the point where identity and policy must be enforced.
• Local MCP servers become risky when they are given reusable secrets, because those credentials can leak through the process boundary and outlive the request that needed them.
• Remote MCP traffic needs workload identity, mTLS, and default-deny policy if organisations want agentic tool use without uncontrolled trust expansion.

Key terms

• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• SPIFFE-Compatible Identity: A SPIFFE-Compatible Identity is a workload identity that can be represented and validated using the SPIFFE standard. It uses a cryptographically verifiable SPIFFE ID and associated X.509 or JWT credentials to prove what the workload is. This supports consistent authentication for services, agents, and other non-human workloads across environments.
• Secret Injection At Runtime: A method of supplying credentials only when a job or workload starts, rather than storing them in code or static configuration. This reduces the persistence of secrets in repositories and build artifacts, but it only works when lifecycle controls and rotation are enforced.
• Default Deny Policy: A default deny policy blocks access unless it is explicitly allowed. In security design, this means users, devices, applications, and non-human identities receive no permission by default, and access is granted only through defined rules, approvals, or policy conditions. It reduces unintended exposure and limits the impact of misconfiguration.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.