MCP gateways: what they mean for your blast radius (on CI/CD pipelines)

Can you trust every build step to stay within its intended scope?

Most CI/CD pipelines are assembled from a handful of scripts that run with a single service account. That account often holds a long‑lived token or SSH key that can reach every environment – development, staging, production – and every resource behind it. When a new job is added, the token is simply reused. The result is a sprawling blast radius: a compromised build step can reach any downstream service, modify databases, or spin up containers without any checkpoint.

Because the pipeline itself does the credential handling, there is no independent point that can observe or intervene in a command. Audits end up looking at log files that were written after the fact, and they rarely contain the raw commands that caused a change. If a malicious actor injects a command, the pipeline will execute it, and the damage is already done before anyone notices.

Why blast radius explodes in typical CI/CD pipelines

The core problem is the combination of three practices:

• Static, shared credentials. A single secret is baked into the pipeline configuration and propagated to all jobs.
• Unmediated direct connections. Jobs connect straight to databases, Kubernetes clusters, or SSH targets without an intervening control surface.
• Lack of real‑time audit or approval. The pipeline trusts the script’s intent and does not require a human to approve risky operations.

These choices make the blast radius effectively the entire production surface. A vulnerability in one repository can be leveraged to issue a destructive SQL statement, delete a namespace, or exfiltrate data, all without a trace that can be correlated to a specific identity.

How an MCP gateway reshapes the blast radius

Introducing an MCP (Model‑Control‑Proxy) gateway changes the architecture. The gateway sits at Layer 7, between the CI/CD runner and the target infrastructure. Identity is still provided by an OIDC or SAML provider – that is the setup that decides who may start a request. The gateway, however, becomes the sole data path for every connection.

When a pipeline step attempts to open a database session, the request is routed through the MCP gateway. The gateway inspects the wire‑protocol, applies policy, and only then forwards the traffic to the database. Because the gateway is the only place the traffic passes, it can enforce three critical outcomes:

• Session recording. hoop.dev records each command and its result, creating a replayable audit trail.
• Inline masking. Sensitive fields in query results are redacted before they reach the pipeline logs.
• Just‑in‑time approval. Dangerous commands trigger a workflow that requires a human to approve before execution.

Each of these outcomes is only possible because hoop.dev sits in the data path. If the gateway were removed, the pipeline would again talk directly to the target, and none of the controls would apply.

Reducing blast radius with an MCP gateway

With the gateway in place, the blast radius contracts to the scope defined in the policy. A job that only needs read‑only access to a staging database cannot accidentally acquire write privileges, because the gateway will block any write command that does not match the allowed pattern. Likewise, a step that attempts to execute a privileged Kubernetes command will be intercepted and either denied or sent for approval.

Because the gateway holds the credential, the pipeline never sees the raw secret. Even if an attacker compromises the CI runner, they only obtain a short‑lived token that the gateway can validate against the identity provider. The result is a much tighter containment of any breach.

Implementing an MCP gateway for your pipelines

The implementation starts with deploying the gateway near your CI/CD runners. The Getting started guide walks through a Docker Compose deployment that includes OIDC authentication, masking, and guardrails out of the box. Once the gateway is running, you register each target – PostgreSQL, Kubernetes, SSH – as a connection. The gateway stores the service credentials, so the pipeline never handles them directly.

From the pipeline side, you simply point your client (psql, kubectl, ssh) at the gateway endpoint. The client behaves exactly as it would against the real target, but every request now passes through the gateway’s policy engine.

For deeper insight into policy definitions, data masking options, and approval workflows, see the Learn section. The documentation explains how to model fine‑grained permissions that align with your organization’s risk appetite.

FAQ

Does the gateway add latency to my builds?

The additional hop is a network‑level proxy, and most pipelines see only a few milliseconds of overhead. The security benefits far outweigh the minimal performance impact.

Can I use existing CI secrets management with the gateway?

Yes. The gateway expects the credential for each target to be supplied at registration time. You can source those credentials from any secret store that your deployment process can access.

What happens to logs that contain sensitive data?

hoop.dev masks configured fields before they are written to the pipeline’s log storage, ensuring that downstream analysis tools never see raw secrets.

Ready to tighten the blast radius of your CI/CD pipelines? Explore the open‑source repository on GitHub and start building a safer, auditable pipeline today.