We all love MCP. 

Model Context Protocol is open, simple, and powerful, making it much easier to plug tools into AI agents in a consistent way. It has quickly become a core building block for many agentic architectures. 

We all understand the risks. 

When you give an agent access to powerful tools, you also give them the power to break things, leak data, or generate unexpected costs. So naturally, the industry started thinking: “We need a way to control MCP usage.” 

That is where MCP Gateways come in. 

The idea is attractive: Put a gateway in front of all MCP servers, and you can monitor tool calls, approve or deny specific actions, and enforce policies at a central control point. It sounds good at first. In practice, MCP Gateways are the wrong abstraction for securing modern agents. 

Let’s look at why. 

Why MCP Gateways are a Bad Idea 

The instinct to put a gateway in front of MCP servers is understandable. It’s the same thinking that gave us firewalls, DMZs, and perimeter security. Put everything behind a checkpoint, monitor what flows through, and enforce policies from one central place. 

We know how that story ends. Perimeter security creates a hard shell with a soft center. Once you’re past the gate, you’re trusted. And in modern systems with APIs, microservices, and distributed agents, there are too many ways past the gate. 

MCP Gateways repeat this mistake at the protocol level. They try to solve a runtime problem with a network control, and that mismatch creates more issues than it solves.  

Here’s why they fall short: 

1. They only cover MCP, not everything your agent can do 

Gateways only see what goes through MCP. Most real-world agent systems use much more than that. They execute shell commands and scripts, call native SDKs and libraries, connect directly to databases, and use framework-specific connectors for tools like Slack, GitHub, Jira, or cloud providers. A risky or buggy workflow does not care whether it uses MCP, a shell, or a built-in connector. From a security perspective, shell access is often far more dangerous than a typical MCP tool. 

If your security model only protects MCP, you are left with big blind spots. You are securing one door while the windows, back door, and garage are wide open. 

2. They introduce a new secret management risk 

To work, many gateways require you to route requests, and often credentials, through them. API keys, OAuth tokens, service accounts, and other sensitive secrets may now live in or pass through a third-party system. 

Instead of reducing risk, you have just increased the number of places where your secrets exist, the number of systems that could be compromised, and the number of new vendors or services in your threat model. You tried to solve one problem, uncontrolled tool use, and created another, centralized secret exposure. 

3. They lack full agent context 

Security is all about context. To decide whether a tool call is safe, you need to know the user prompt, the agent goal, the session history, what other tools were called before, and whether this call is part of a larger workflow or just a strange one-off. A gateway usually sees something like “Call tool X with arguments Y from client Z.” That is useful but incomplete. 

Without full session context, advanced detection is almost impossible. You cannot reliably flag suspicious sequences of actions, distinguish benign calls from data exfiltration, or enforce nuanced, context-aware policies like “only allow this if the user is in group A and the data is tagged B.” You end up with either overly permissive rules or very basic, noisy ones. 

4. They are a single point of failure 

Most MCP Gateways are built as proxies or reverse proxies. If the gateway is down, misconfigured, rate-limited, or suffering from network issues, your agents are effectively offline. 

Instead of building resilient systems, you centralize everything behind one piece of infrastructure that now has to be highly available, low-latency, secure, and correctly configured across all environments. That is a lot of operational overhead for something that is supposed to “just” add security. 

5. They are hard to enforce across all clients 

Even with a perfect design, you still face a major practical problem. How do you force every client and every agent to use the gateway? Agents can run in local developer environments, CI pipelines, different services or microservices, IDEs and notebooks, and on machines you do not fully control. If a client can talk directly to an MCP server, it can bypass the gateway unless you apply strict network and configuration controls everywhere. 

In practice, this often results in some traffic passing through the gateway and some not. You think you have control, but you do not have full coverage. Partial security can be worse than no security because it creates a false sense of safety. 

The good news is that there’s a better approach, one that actually addresses these fundamental problems instead of working around them. If MCP Gateways are the wrong layer, what is the right one? 

Runtime Hooks – Securing the Entire Layer, Not Just the Protocol 

The best place to secure agents is inside the agent runtime itself, not at the edge of a single protocol. That is where runtime hooks come in. 

Hooks are built into the agent framework and trigger whenever tools are used. 

 Runtime hooks solve the core limitations with gateways as a security guardrail: 

• Full coverage across all tooling, not just MCP 

• No credential exposure to third parties 

• Access to full session and prompt context 

• No single point of failure 

• Easy configuration and rollout 

Because hooks live at the agent layer, they can see MCP tools, shell commands, native SDK calls, HTTP requests, and framework-specific connectors. If the agent invokes something, a hook can catch it. You are not limited to monitoring just one protocol while everything else runs unobserved. 

In addition, to avoid credential exposure, hooks run inside your environment and inside your agent code. They do not require you to send your secrets to a third party. Secrets remain in your existing systems, no extra proxy or gateway needs to store API keys, and you keep complete control over secret management. Hooks can inspect metadata and arguments without becoming a new storage location for credentials. 

Running inside your code and environment provides additional value, where hooks can see the full conversation history, the current prompt, the agent state or plan, and previous tool calls in the same session. Your security logic can be truly context-aware. You can write policies like “block this call if the user is external and the data is marked internal only” or “alert if the agent chains several export-style tools suspiciously.” This is extremely hard to do from a protocol-level gateway that only sees isolated tool call requests. 

Because hooks are typically implemented as part of the agent SDK or runtime, they avoid creating a single point of failure. If a hook fails, you can design it to fail safely, denying only the risky call, or to degrade gracefully while the agent continues to run. You are not routing all traffic through one central network bottleneck. You are adding behavioral controls inside each agent process. 

Finally, hooks are easier to deploy and manage. Instead of managing complex network paths and proxies, you enable hooks in your agent framework, configure policies in one place, and ship that configuration with your agents. This is far easier to standardize across teams and environments than enforcing gateways for every client. On top of that, no code changes are required if hooks are integrated at the framework or platform level. Teams can adopt security controls by configuration alone, without modifying each agent implementation. 

MCP Registries: Control at the Source 

Runtime hooks secure how tools are used, but decades of security practice have taught us that good hygiene requires defense in depth. You need controls at multiple layers, and one of the most effective is controlling what exists in your environment in the first place. 

This is not a new or novel idea.  

We learned this lesson with package managers, container registries, and API gateways. Allowlists and approved registries prevent unauthorized code and tools from entering your systems, and the same principles should be applied to MCP servers. 

An MCP Registry lets you maintain an allowlist of approved MCP servers in your organization, define which tools are available to which teams or environments, and prevent agents from discovering or using unapproved MCPs. 

Combined with runtime hooks, this gives you a strong two-layer model. The registry controls what is allowed, which MCPs and tools exist in your environment, while the hooks control how those tools are used, including policies, context checks, and detections. This applies years of proven runtime security principles to a new attack surface, rather than trying to retrofit network-layer controls that were never designed for this problem. 

Beyond MCP Security – Securing the Entire Agentic Attack Surface 

MCP is powerful and here to stay. It deserves a security model that actually matches how agents work in practice. 

MCP Gateways repeat the mistakes of perimeter security by focusing on a single protocol, while agents are not limited to a single use case.  They employ shell commands, native SDKs, database connections, and framework-specific tools. This introduces secret management risks through centralized credential handling, a lack of the full agent and session context needed for effective policy decisions, and creates both a single point of failure and enforcement challenges across distributed environments. 

We do not need to reinvent security models to secure agentic systems in production. Decades of running complex, distributed systems have already taught us what works and which layers are most critical to secure.  

Runtime hooks combined with MCP registries. Hooks give you full coverage across all tooling, complete session context for policy decisions, no credential exposure to third parties, no central bottleneck, and easy rollout with no code changes when integrated at the framework level. 
This, combined with well-maintained registries give you governance and control over which MCPs exist in your environment in the first place. 

The agentic world is evolving too fast to bet on protocol-level controls – secure the agent where it actually runs, not just the protocol it happens to use today.