Defense in Depth for MCP: Why Your Gateway Needs a Cryptographic Identity Layer

Algis Dumbris • 2026/03/18

TL;DR

Four new MCP security tools shipped in the span of a single week. That is not a coincidence — it is a market telling us that the “just trust the server” era of MCP is over. The interesting part is that these tools do not compete with each other. They occupy distinct layers: protocol-level cryptographic identity (MCPS), gateway-level quarantine and isolation (MCPProxy), and CI/CD-level static analysis (G0). No single layer covers the full attack surface. This post walks through why defense in depth is not optional for production MCP deployments, and how to wire these layers together.

The Security Tool Explosion

In the second week of March 2026, the MCP ecosystem saw an unprecedented wave of security tooling. MCPS launched as a cryptographic identity layer — think “HTTPS for the agent era.” G0 released a comprehensive static analysis platform with 1,180 security rules and 4,020 adversarial payloads. Cordon and MCPDome followed with their own takes on MCP security posture management.

This fragmentation is healthy. It mirrors what happened with web security two decades ago: SSL/TLS handled transport encryption, web application firewalls handled request filtering, and static analysis tools like Fortify handled code-level vulnerabilities. Nobody argued that SSL made WAFs unnecessary, or that static analysis replaced runtime protection. Each layer addressed a fundamentally different threat vector.

The MCP ecosystem is now going through the same maturation. And the OWASP MCP Top 10, published in 2025, gives us a concrete framework for understanding which layers cover which risks.

Three Layers of MCP Security

Layer 1: Protocol — MCPS

MCPS addresses the most fundamental gap in the Model Context Protocol: there is no built-in mechanism for verifying who you are talking to. Standard MCP connections use plain JSON-RPC over stdio or HTTP. Messages are unsigned. Tool definitions can be modified after registration. There is no way to revoke a compromised agent’s access.

MCPS fixes this with four core primitives:

Agent Passports use ECDSA P-256 cryptographic credentials to provide verifiable identity for every agent in the system. When an MCP server presents its passport, clients can cryptographically verify that the server is who it claims to be — not an impersonator, not a man-in-the-middle.

Message Signing wraps every JSON-RPC message in a signed envelope with a nonce and timestamp. This prevents replay attacks where an adversary captures a legitimate tool call and re-submits it later, and it prevents tampering where someone modifies a message in transit.

Tool Integrity signs tool definitions at registration time. This directly addresses MCP03 (Tool Poisoning) from the OWASP Top 10 — the attack where a malicious actor modifies a tool’s description or schema after it has been registered, causing agents to misuse the tool or leak data to unintended endpoints.

Real-Time Revocation through a Trust Authority enables instant blacklisting of compromised agents across the network. When you discover that a server has been compromised, you do not have to wait for certificate expiration or manually update every client — revocation propagates immediately.

MCPS implements five trust levels (L0 through L4), from unsigned plain MCP at L0 to fully audited with manual review at L4. Servers can enforce minimum trust levels per connection, giving operators granular control over their security posture. The project claims coverage of 8 out of 10 OWASP MCP Top 10 risks.

Layer 2: Gateway — MCPProxy

MCPProxy operates at a fundamentally different level. Where MCPS asks “is this server who it claims to be?”, MCPProxy asks “what should this server be allowed to do, and how do I contain the damage if it misbehaves?”

MCPProxy provides three key capabilities at the gateway layer:

BM25 Tool Discovery indexes tool definitions from all connected MCP servers and routes requests to the right tool based on semantic relevance. This matters for security because it eliminates the need to expose every tool to every agent — tools are surfaced only when they match a query, reducing the attack surface by default.

Quarantine isolates untrusted or newly added MCP servers in a restricted execution environment. A quarantined server can respond to tool discovery queries, but its tool calls are blocked until an operator explicitly promotes it to trusted status. This directly addresses MCP09 (Shadow MCP Servers) — rogue servers cannot silently join the network and start executing actions.

Docker Isolation runs each MCP server in its own container with configurable resource limits, network policies, and filesystem restrictions. Even if a server is compromised and begins executing malicious code, the blast radius is contained to that container. The server cannot access the host filesystem, cannot reach other servers on the network, and cannot consume unbounded resources.

These are runtime concerns that protocol-level signing cannot address. A server can have a perfectly valid MCPS passport and still be compromised at the application layer. Gateway isolation ensures that compromise does not propagate.

Layer 3: CI/CD — G0

G0 occupies the pre-deployment layer. It scans agent codebases before they ever reach production, catching vulnerabilities that neither protocol signing nor runtime isolation can detect.

G0’s static assessment identifies security issues across 12 security domains mapped against 10 compliance frameworks including the OWASP Agentic Top 10, NIST AI RMF, ISO 42001, and the EU AI Act. It detects hardcoded secrets in MCP environment variables, unverified publisher connections, version-pinning gaps, and suspicious permission requests.

The dynamic testing component goes further: 4,020 adversarial payloads across 25 attack categories test for prompt injection, jailbreaks, data exfiltration, and tool abuse scenarios. These are multi-turn adaptive strategies that evolve based on agent responses — not simple pattern matching.

For MCP specifically, G0 audits server configurations, detects credential leaks in environment variables, flags unverified skill publishers, and performs rug-pull detection on recently published tools. It integrates directly into CI/CD pipelines via GitHub Actions, pre-commit hooks, and configurable policy gates.

Why No Single Layer Is Sufficient

This is the core argument, and it is worth making explicit. Each layer has blind spots that the others cover.

Protocol signing stops tool poisoning but cannot limit blast radius

MCPS ensures that tool definitions have not been tampered with and that the server presenting them is cryptographically verified. But a verified server can still be compromised. If an attacker gains access to a legitimate server’s signing keys, or exploits an application-level vulnerability in the server code itself, every signed message from that server becomes a trusted attack vector. MCPS has no mechanism to restrict what a verified server can do at runtime — that is not its job.

Consider MCP05 from the OWASP Top 10: Command Injection. A server with a valid MCPS passport that constructs shell commands from untrusted input is just as dangerous as an unsigned one. The cryptographic envelope does not inspect the content it carries.

Gateway isolation limits blast radius but cannot verify identity

MCPProxy can quarantine untrusted servers and run everything in Docker containers with strict resource limits. But it has no way to verify that a server is who it claims to be. If an attacker deploys a malicious server that mimics the interface of a legitimate one — same tool names, same descriptions, same schema — the gateway will happily route requests to it. Without cryptographic identity, tool shadowing (a subset of MCP03) remains possible.

Gateway isolation also cannot detect subtle behavioral drift. A server that gradually modifies its tool descriptions over time to steer agents toward malicious actions will pass every gateway check because each individual request looks legitimate.

Static analysis catches known patterns but misses runtime attacks

G0 can identify hardcoded secrets, flag suspicious permission requests, and test for known prompt injection patterns before deployment. But static analysis is inherently limited to what it can see at scan time. It cannot detect a server that behaves correctly during testing and then activates malicious behavior after deployment — the classic time-of-check-to-time-of-use problem.

G0 also cannot protect against supply chain attacks that occur after the scan. If a dependency is compromised between the last CI/CD run and the current runtime, the static analysis results are stale. This is MCP04 (Software Supply Chain Attacks) in action.

The coverage gap

Map these three layers against the OWASP MCP Top 10 and the gaps become obvious:

No single column has “Yes” in every row. That is the entire argument for defense in depth in one table.

A Practical Defense-in-Depth Architecture

Here is how the three layers compose into a coherent security architecture for production MCP deployments.

Pre-deployment: G0 in CI/CD

Before any MCP server reaches production, it passes through G0’s analysis pipeline:

1. Static scan identifies hardcoded secrets, overly permissive configurations, and known vulnerability patterns. The .g0.yaml policy file defines thresholds — any finding above a configurable severity blocks the deployment.
2. Dynamic testing runs adversarial payloads against the server in an isolated environment. If the server is susceptible to prompt injection or tool abuse, it fails the gate.
3. Compliance mapping tags every finding against relevant frameworks (OWASP, NIST, EU AI Act), generating audit-ready evidence.

The output is a SARIF report that feeds into your existing security dashboard, plus a CycloneDX SBOM that tracks every dependency for future supply chain monitoring.

Runtime: MCPProxy as the gateway

Servers that pass CI/CD enter the MCPProxy gateway layer:

1. New servers start quarantined. They appear in tool discovery results (so operators can evaluate them) but cannot execute tool calls until explicitly promoted. This prevents shadow servers from entering the production path.
2. BM25 discovery ensures agents only see tools relevant to their current query. A financial analysis agent never sees filesystem manipulation tools. A code review agent never sees database admin tools. This is least-privilege at the tool discovery level.
3. Docker isolation contains each server in its own container. Network policies restrict inter-container communication. Resource limits prevent denial-of-service. Filesystem mounts are read-only where possible.
4. Request logging captures every tool call with full context for audit trails, partially addressing MCP08.

Identity: MCPS as the trust anchor

MCPS provides the cryptographic foundation that ties everything together:

1. Server identity verification ensures that the server behind the MCPProxy gateway is actually the server that passed the G0 scan. Without this link, an attacker could swap a verified server for a malicious one between scan time and runtime.
2. Message integrity guarantees that tool calls and responses have not been tampered with in transit. Even within a Docker container, a compromised network layer could modify messages — signing prevents this.
3. Trust levels allow graduated access. A new server might start at L1 (passport presented) and only gain access to sensitive operations after reaching L3 (verified plus security scan) or L4 (audited with manual review).
4. Revocation provides the emergency stop. When a server is compromised, revoking its passport immediately prevents it from participating in any MCPS-aware network, regardless of how many MCPProxy instances it is connected to.

Wiring them together

The practical integration looks like this:

MCP Client
    |
    v
MCPProxy Gateway (quarantine, discovery, isolation)
    |
    |--- MCPS verification on every connection
    |--- G0 scan results consulted for trust level decisions
    |
    v
MCP Server (Docker-isolated, MCPS-verified, G0-scanned)

G0’s scan results feed into MCPProxy’s trust decisions: a server with a clean G0 report gets promoted from quarantine faster. MCPS trust levels map to MCPProxy permission tiers: an L4 server might get access to sensitive tools that an L2 server cannot see. The layers reinforce each other rather than operating in isolation.

What Is Still Missing

Even with all three layers, significant gaps remain in the MCP security story.

Runtime behavioral monitoring. None of these tools currently perform continuous behavioral analysis during normal operation. A server that gradually shifts its behavior over weeks — subtly modifying tool descriptions, slowly escalating the scope of data it requests — would evade all three layers. We need something analogous to runtime application self-protection (RASP) for the MCP ecosystem: continuous monitoring that detects behavioral anomalies in real time.

Observability and correlation. MCP08 (Lack of Audit and Telemetry) is the most under-addressed risk in the Top 10. MCPProxy logs tool calls, but there is no standard for correlating events across protocol, gateway, and CI/CD layers. When an incident occurs, investigators need a unified timeline that shows the G0 scan results, the MCPS trust level at connection time, and the MCPProxy gateway logs — all correlated by server identity and timestamp. No tool provides this today.

The compliance gap. G0 maps findings to compliance frameworks, but the other layers do not. An auditor asking “show me evidence that all production MCP servers have cryptographic identity” has to manually cross-reference MCPS deployment records with MCPProxy server inventories. A unified compliance view across all three layers would significantly reduce audit burden.

Multi-tenant trust boundaries. In enterprise deployments where multiple teams share an MCPProxy gateway, there is no standard for enforcing per-team trust policies. Team A might require L4 verification for all servers; Team B might accept L2. MCPProxy’s quarantine model is binary (trusted or not), and MCPS trust levels are per-server, not per-tenant. This is a gap that will become acute as MCP adoption scales within larger organizations.

The Bottom Line

The MCP security market is fragmenting into layers, and that is exactly what should happen. Protocol signing, gateway isolation, and static analysis are complementary, not competing. MCPS brings cryptographic identity that the ecosystem desperately needs. MCPProxy brings runtime containment that no amount of signing can replace. G0 brings pre-deployment assurance that catches problems before they reach production.

If you are running MCP servers in production today without at least two of these three layers, you have blind spots. The OWASP MCP Top 10 is not theoretical — 82% of MCP servers have path traversal vulnerabilities, and supply chain attacks against agent toolchains are already happening.

Defense in depth is not a luxury for MCP. It is the minimum viable security posture.

MCPProxy is open source and available at github.com/smart-mcp-proxy/mcpproxy-go. For MCPS, see mcp-secure.dev. For G0, see github.com/guard0-ai/g0. The OWASP MCP Top 10 is at owasp.org/www-project-mcp-top-10.