Securing MCP Communication with Riptides

In our previous blog post about MCP, we introduced the core concepts behind this agentic technology. Today, we’ll explore how the Riptides Non-Human Identity (NHI) platform helps secure agentic applications that use the Model Context Protocol (MCP).

As a reminder, MCP servers can be either local or remote:

• Local servers are spawned as subprocesses by the agentic app and typically require environment variables to configure access to restricted resources.
• Remote servers require OAuth2 authentication so users can grant access to their resources.

Riptides secures both scenarios using our kernel-based identity platform. It provides an OS-level enforcement layer that transparently controls how agents, MCP servers, and backends securely communicate with zero changes to application code.

Why MCP Communication Is Risky

Agent-to-MCP communication introduces a new security boundary that is vulnerable to:

• Prompt injection
• Impersonation
• Token leakage
• Unauthorized access

MCP is designed to decouple agents from the implementation details of tools and services. Agents discover and invoke tools from MCP servers at runtime, sometimes across the network. While this enables powerful agentic workflows, it also introduces several risks:

• Agents may interact with malicious or misconfigured servers.
• Servers might call untrusted or malicious endpoints.
• Local servers need secrets like API keys or tokens via environment variables; using a malicious or compromised server could lead to credential leaks.

How Riptides Secures MCP Traffic

Kernel-Level TLS

Riptides transparently upgrades outbound traffic to mTLS. The agent remains unaware of handshakes, certificates, or trust anchors, Riptides seamlessly handles everything at the kernel level.

Policy Enforcement

You can define policies that specify which MCP servers an agent is allowed to communicate with (based on SPIFFE IDs) and deny all others by default. This enables a zero-trust, default-deny network model.

Secret Injection

Based on the above mentioned policies, Riptides can inject the necessary tokens and API keys and modify requests at the kernel level, as communication pass by. This way users space applications never have access to such sensitive values, yet the connection still work.

Auditability

All identity assertions and network requests are traceable back to the specific agent and its runtime environment. This is essential for debugging, compliance, and forensic analysis. When both client and server use SPIFFE aware environments, mutual TLS provides a strong, verifiable handshake, ensuring trust on both sides before any tool call is made.

Example Scenarios

Remote

An agent running in a secure environment (e.g., a container in a Kubernetes cluster) needs to invoke a tool hosted on a third-party remote MCP server: https://mcp.example.com/tools/send_email.

This MCP server might:

• Forward requests to internal or external APIs (e.g., SMTP providers, notification systems)
• Require OAuth2 tokens authorize outgoing traffic
• Be managed by third party team or vendor

If both client and server use Riptides to secure their environments, then:

• Both the agent and the server get a SPIFFE-compliant identity bound to their respective workloads (e.g., Kubernetes namespace, process name, deployment name, labels, etc.).
• All outgoing requests from the agent to the MCP server are automatically upgraded to mutual TLS using kernel level enforcement, no code changes required.
• The MCP server is also required to present a valid SPIFFE identity before any tool call is permitted.
• A policy engine verifies that:
  • The destination MCP server is on an allowlist
  • The presented identity matches a trusted SPIFFE ID
  • The protocol is mTLS with verified certificate chains
• All requests are auditable, with logs mapping agent workload identity to each outbound call.

This provides zero-trust enforcement even across organizational or network boundaries.

Local MCP Server

In the local scenario, the MCP server is spawned as a subprocess by the agent and communicates via stdio. While this communication is considered safe within a trusted runtime, the security challenge lies in the MCP server’s outbound traffic to third-party services (e.g. APIs, cloud tools).

Traditional approach:

• Secrets (API keys, tokens) are injected into the MCP server as environment variables.
• The server uses those secrets to make authenticated requests (e.g., curl -H "Authorization: Bearer $API_KEY").

This is risky because:

• Any vulnerability in the MCP server could expose those environment variables.
• Secrets may persist in memory, logs, or process introspection tools (ps, /proc).

With Riptides:

• No secrets are passed via environment variables.
• When the MCP server initiates a request (e.g., via libcurl, requests, or fetch), Riptides intercepts the call at the socket level.
• Based on the outbound domain/IP and request metadata, Riptides injects:
  • Authorization headers (e.g., Bearer tokens)
  • mTLS client certificates
  • Custom headers or request modifications
• The secrets are never visible to the MCP server process.

Best Practices for Securing Agent-to-MCP

• Use SPIFFE based identities for all agents and MCP servers
  Avoid relying on static API keys or long-lived secrets. Use ephemeral, cryptographically backed identities issued at runtime.

• Enforce mTLS in remote scenarios
  Prevent unauthorized access, impersonation, and data interception.

• Hide secrets from servers in local scenarios
  Inject secrets at the kernel level, rather than exposing them through environment variables.

• Scope agent permissions with policy
  Define exactly which MCP servers or tools an agent can communicate with.

• Trust no MCP server by default
  Only allow connections to explicitly whitelisted servers. Avoid dynamically connecting to unknown endpoints.

Conclusion: A New Trust Layer for Autonomous Agents

MCP unlocks powerful agentic capabilities but only if agent-to-server communication is secure. By combining MCP’s standardized tool interface with SPIFFE based identity using Riptides, teams can:

• Build composable, multi-agent systems
• Leverage third-party tools with confidence
• Maintain compliance and auditability
• Enforce zero-trust principles at every boundary

As AI agents grow more autonomous, identity becomes the root of security. Riptides delivers that identity without the complexity.

---

If you enjoyed this post, follow us on LinkedIn and X for more updates. If you'd like to see Riptides in action, get in touch with us for a demo.