Why MCP Gateways and Runtime Hooks Are Complementary, Not Competing

A recent Security Boulevard piece titled “Why MCP Gateways Are a Bad Idea” has been making the rounds in MCP security circles. The article raises legitimate concerns about gateway architectures — credential centralization, loss of agent-level context, and the illusion of security through chokepoints. These are real problems worth taking seriously.

But the conclusion — that gateways should be avoided in favor of runtime hooks — presents a false binary. The security challenges facing MCP deployments are too varied and too layered for any single architectural pattern to address. The real answer, as with most defense-in-depth questions, is that you need both.

This post examines where gateways genuinely fall short, where runtime hooks have their own blind spots, and why the most robust MCP security posture combines perimeter-level gateway enforcement with runtime hook-based context awareness. Neither pattern is sufficient alone. Together, they cover each other’s weaknesses.

The Gateway Critique: What Security Boulevard Gets Right

The core argument against MCP gateways boils down to three concerns, and each has merit.

Credential centralization creates a high-value target. When a gateway holds credentials for every downstream MCP server, compromising the gateway means compromising everything behind it. This is the classic “keys to the kingdom” problem, and it is not trivial. A gateway that stores OAuth tokens, API keys, and service account credentials for dozens of MCP servers is an extraordinarily attractive target. If the gateway’s credential store is breached, the blast radius is total.

Gateways lack agent-level context. A gateway sitting between an MCP client and a set of servers sees requests in isolation. It does not know what the agent is trying to accomplish, what its current reasoning chain looks like, or what previous tool calls have been made in the session. This context gap means the gateway cannot make nuanced policy decisions. Should this agent be allowed to call the write_file tool? The gateway can enforce a blanket allow/deny, but it cannot evaluate whether the write operation makes sense given the agent’s current task. That requires runtime awareness the gateway does not have.

Chokepoint security can create false confidence. Organizations that deploy a gateway sometimes treat it as a complete security solution — checking the box and moving on. This is dangerous. If the gateway becomes the entirety of the security strategy, rather than one layer of it, the organization is vulnerable to any attack that bypasses or operates within the gateway’s trust boundary.

These are valid concerns. Anyone building MCP infrastructure should take them seriously. But they do not lead to the conclusion that gateways should be abandoned. They lead to the conclusion that gateways are insufficient alone — which is a very different claim.

What Gateways Actually Do Well

The critique tends to overlook the problems that gateways solve particularly effectively — problems that runtime hooks cannot address at all.

Centralized observability across all MCP traffic. In any deployment with more than a handful of MCP servers, understanding what is happening across the system requires a single point of visibility. Which servers are being called? How often? What patterns are emerging? Are new tools appearing that were not present yesterday? A gateway provides this visibility without requiring instrumentation of every individual client, server, and agent. Runtime hooks, by definition, operate within a single agent’s execution context and cannot provide cross-system observability.

Pre-connection threat assessment. When a new MCP server appears in the ecosystem — whether added by a developer, discovered through a registry, or introduced by an agent’s autonomous exploration — someone needs to evaluate it before it gets access to production infrastructure. Gateways can quarantine new servers, inspect their tool manifests, compare advertised capabilities against known-good baselines, and enforce approval workflows. This happens before the server ever interacts with an agent. Runtime hooks cannot perform this evaluation because they only execute after a connection is established and a tool call is in progress.

Tool discovery and context window management. The practical reality of MCP deployments is tool sprawl. Organizations running 50 or 100 MCP servers expose hundreds of tools. Clients like Cursor have a 40-tool limit. Claude Code performs differently with 20 tools versus 200. A gateway that provides intelligent tool discovery — routing the right subset of tools to each agent based on the task at hand — solves a problem that has nothing to do with security and everything to do with making MCP work at scale. BM25-based tool filtering, as implemented in projects like MCPProxy, addresses this directly at the gateway layer.

Supply chain verification. When a tool’s schema changes between versions — a parameter is added, a description is modified, a permission scope is expanded — this represents a potential supply chain attack vector. ContextCrush demonstrated how tool descriptions can be weaponized. A gateway that maintains a baseline of known-good tool schemas and flags deviations provides early warning that is architecturally impossible at the hook level, where the tool schema has already been accepted and parsed.

Where Runtime Hooks Fall Short

The “hooks instead of gateways” position has its own set of problems that deserve equal scrutiny.

Framework lock-in. Runtime hooks require deep integration with the agent framework. A hook system built for LangChain does not work with CrewAI. One built for Claude Code does not transfer to a custom agent framework. This means every framework needs its own hook implementation, its own policy engine, and its own security model. In heterogeneous environments — which is every enterprise — this creates a fragmented security landscape where each agent framework has different security properties.

No visibility before connection. Hooks execute at runtime, which means the MCP server has already been connected, its tools have already been registered, and the agent has already started interacting with it. If the server is malicious, the hook must catch the attack in progress. There is no pre-flight check, no quarantine period, no opportunity to evaluate the server’s trustworthiness before it has access to the agent’s context and capabilities.

Policy consistency is hard. When security policy lives in runtime hooks distributed across dozens of agents, ensuring that every agent enforces the same policy becomes an operational nightmare. Did every agent get the updated blocklist? Is the new data exfiltration detection rule deployed to all hook instances? Did the staging environment’s hooks get updated when production was patched? Centralized policy at a gateway eliminates this coordination problem.

No help with tool sprawl. A runtime hook cannot reduce the number of tools presented to an agent. It can block individual tool calls, but it cannot solve the fundamental problem of an agent receiving 200 tool definitions when it only needs 10 for its current task. Tool discovery and filtering is inherently a gateway-layer concern.

The Convergence: Defense in Depth for MCP

The best architecture is not gateway-only or hooks-only. It is both, with each layer handling the problems it is best positioned to solve.

Gateway layer responsibilities:

• Tool discovery, filtering, and context window optimization
• New server quarantine and approval workflows
• Schema integrity verification and supply chain monitoring
• Centralized observability, logging, and audit trails
• Credential management with proper rotation and vault integration
• Cross-agent policy enforcement and consistency
• Rate limiting and abuse detection across the system

Runtime hook responsibilities:

• Context-aware policy decisions (does this tool call make sense given the current task?)
• Agent identity and session-level access control
• Dynamic rules that adapt based on conversation state
• Behavioral analysis (is the agent’s behavior consistent with its declared intent?)
• Fine-grained data loss prevention with access to the full reasoning context
• Framework-specific safety guardrails

The gateway handles the perimeter: what comes in, what is allowed to exist in the environment, and what the overall traffic patterns look like. The hooks handle the runtime: whether a specific action, in a specific context, by a specific agent, should be permitted right now.

This is not a novel architectural insight. It is defense in depth — the same principle that leads organizations to run both a WAF and application-level input validation, or both network firewalls and host-based intrusion detection. Each layer catches what the other misses.

A Practical Example: Quarantine Meets Log-To-Leak Defense

Consider the Log-to-Leak attack pattern, where a compromised MCP server instructs an agent to exfiltrate sensitive data by embedding it in log messages, error reports, or seemingly innocuous API calls to external services.

Gateway-level defense: When a new MCP server is registered, the gateway places it in quarantine. During quarantine, the server’s tool manifest is inspected: does it request network access? Does it register tools that accept arbitrary URLs as parameters? Does its schema match known patterns associated with exfiltration? The gateway can also monitor outbound traffic patterns from agents interacting with quarantined servers, flagging unusual data volumes or connections to unexpected endpoints.

MCPProxy implements this quarantine pattern, placing new servers in a restricted state until they pass inspection. But quarantine alone is not sufficient — a server can pass quarantine with a clean manifest and then deliver malicious instructions through legitimate tool responses during normal operation, exactly as ContextCrush demonstrated.

Hook-level defense: Runtime hooks within the agent framework monitor the actual content flowing through tool calls. When the agent attempts to include contents of .env files in a log message, or when it tries to construct an HTTP request with base64-encoded sensitive data in the URL parameters, the hook detects the data exfiltration attempt in context. The hook knows what data the agent has accessed in this session, what the agent’s stated task is, and whether the current action is consistent with that task. This contextual awareness is what allows the hook to distinguish between a legitimate log statement and an exfiltration attempt — a distinction the gateway cannot make from its vantage point.

Together: The gateway catches obviously malicious servers before they reach agents. The hooks catch subtle attacks that pass through the gateway’s perimeter checks. Neither layer alone provides complete coverage. Both together create overlapping defense that an attacker must defeat at two separate architectural layers with two different detection approaches.

The Credential Question

The credential centralization critique deserves a direct response because it is the strongest argument against gateways. And the answer is: yes, credential management at the gateway layer must be done properly, or it becomes a liability.

This means:

• Secrets vault integration (HashiCorp Vault, AWS Secrets Manager) rather than local credential storage
• Short-lived tokens with automatic rotation rather than long-lived API keys
• Per-agent credential scoping so that compromising one agent’s gateway session does not expose credentials for servers that agent should not access
• Audit logging of every credential access, not just tool calls

A gateway that stores credentials in a plaintext config file is worse than no gateway at all. A gateway that integrates with a secrets vault, enforces least-privilege credential access, and logs every token issuance is materially more secure than credentials scattered across individual agent configurations and environment variables — which is what the no-gateway alternative actually looks like in practice.

What the Ecosystem Needs

The gateway-versus-hooks debate is a symptom of a maturing ecosystem that has not yet converged on standard security architecture. Both patterns exist because both solve real problems. The productive path forward involves several things.

Standardized hook interfaces. If runtime hooks are going to be a core security layer, they need a standard interface that works across frameworks. The current situation — where every agent framework invents its own hook system — is unsustainable for enterprises that run multiple frameworks.

Gateway transparency. Gateways need to be explicit about their trust model, their credential management approach, and their limitations. The criticism of gateways-as-false-confidence is valid, and the best way to counter it is transparency about what the gateway does and does not protect against.

Composable defense. Security tooling should be designed to work in layers rather than as monolithic solutions. A gateway that assumes it is the only security layer is poorly designed. A hook system that assumes no perimeter defense exists is equally poor.

The organizations that will have the strongest MCP security posture are those that treat gateways and hooks as complementary layers of a defense-in-depth strategy, not as competing philosophies. The debate about which one is “right” misses the point. They are both right. They are both incomplete. And they are better together.