MCP gateways: what they mean for your blast radius (on on-prem)

When an MCP gateway sits on the same network as your most sensitive services, it instantly widens the blast radius: a single compromise can cascade across the entire stack.

On‑premise teams often deploy an MCP (Model‑Control‑Plane) gateway as a convenient way to route AI‑driven workloads, internal tools, or batch jobs to databases, Kubernetes clusters, and other resources. The gateway is typically given a privileged service account and a static credential that every downstream client reuses. Engineers appreciate the simplicity: one endpoint, one set of credentials, and no need to modify existing tooling. The reality is far less tidy. Because the gateway terminates the connection and then forwards traffic, any breach of the gateway or a malicious client that reaches it instantly inherits the gateway’s full set of permissions. The result is a dramatically enlarged blast radius – the area of impact that a single compromised identity can affect.

Why MCP gateways expand blast radius

In the default deployment model, the gateway is the sole point of authentication for a wide range of back‑ends. The identity that reaches the gateway is often a non‑human service account with broad, standing access. No additional checks occur once the request leaves the gateway; the traffic flows directly to the target database, Kubernetes API, or SSH host. This architecture leaves three critical gaps:

• Static credentials – the same secret is reused for weeks or months, making credential rotation painful and rarely performed.
• Lack of per‑command visibility – the gateway does not record which commands were issued or what data was returned, so a breach can go unnoticed.
• No inline protection – dangerous queries, destructive kubectl commands, or privileged SSH actions are executed without any real‑time guardrails.

Because the request reaches the target directly after the gateway handoff, there is no audit trail, no data masking, and no opportunity for a human to approve risky operations. In other words, the gateway solves the connectivity problem but does nothing to contain the blast radius.

What a minimal control looks like

To shrink the blast radius you first need a policy that limits who can ask the gateway to talk to a particular resource, and for how long. This means adopting just‑in‑time (JIT) access, requiring explicit approval for high‑risk commands, and ensuring every session is recorded for later review. However, simply granting JIT tokens or adding an approval workflow in an external system does not automatically protect the data path. The request still travels straight from the gateway to the back‑end, bypassing any enforcement point. Without a gateway that sits in the data path, the policy cannot be enforced, and the blast radius remains unchanged.

Contain blast radius with hoop.dev

hoop.dev is built to sit exactly where enforcement is needed – in the Layer 7 data path between the MCP gateway and the target service. By proxying every connection, hoop.dev becomes the authority that can apply the missing controls.

When a client authenticates through an OIDC identity provider, hoop.dev validates the token, extracts group membership, and then decides whether the request may proceed. From that point onward, hoop.dev can:

• Record each session – every command, response, and timing information is stored for replay and audit.
• Mask sensitive fields – query results that contain passwords, tokens, or personal data are redacted before they reach the client.
• Enforce just‑in‑time approvals – high‑risk operations are paused and routed to an approver, preventing accidental or malicious damage.
• Block dangerous commands – destructive SQL statements or privileged kubectl actions are rejected before they touch the back‑end.
• Scope access to the minimum required – policies can limit which databases, tables, namespaces, or hosts a given identity may reach, and for how long.

Because hoop.dev sits in the data path, none of these controls can be bypassed by a compromised MCP gateway or a rogue client. The gateway still provides the convenient routing layer, but every request is filtered, recorded, and, if necessary, approved by a human before it reaches the target. This dramatically reduces the blast radius: a breach of the gateway now only yields the limited, policy‑driven view that hoop.dev permits.

Getting started with hoop.dev is straightforward. Deploy the gateway using the Docker Compose quick‑start, connect it to your on‑premise network, and point your MCP gateway at the hoop.dev endpoint. Detailed steps are available in the getting‑started guide, and the learn section explains how to configure masking, approvals, and session replay.

FAQ

• Does hoop.dev replace my existing MCP gateway? No. hoop.dev complements the gateway by becoming the enforcement layer that sits between the gateway and the back‑end.
• Can I still use my current OIDC provider? Yes. hoop.dev acts as a relying party and validates tokens from any standard OIDC or SAML provider.
• What happens to existing credentials? hoop.dev stores the credentials needed to talk to the back‑end; users never see them, reducing credential sprawl.

By inserting hoop.dev into the data path, you turn a broad, unchecked MCP gateway into a controlled, auditable access point. The blast radius shrinks from “any compromised client can walk straight to every service” to “only the actions explicitly allowed by policy can reach the service, and every action is recorded.”

Explore the source code and contribute on GitHub.