When a newly hired data scientist leaves the company, the team forgets to rotate the service account that powers the internal LLM‑driven code‑assistant. The assistant continues to run in CI pipelines, issuing kubectl delete calls that wipe out an entire namespace before anyone notices. The incident illustrates how an AI‑enabled MCP gateway can dramatically expand the blast radius of a single credential.
Most organizations treat MCP gateways as a convenience layer: an LLM talks to a local MCP server, which then opens a direct tunnel to the Kubernetes API server using a static kubeconfig. That kubeconfig often contains cluster‑admin privileges because it is easier to manage than per‑user tokens. The result is a single point of failure that can execute any command the cluster permits, from scaling deployments to deleting persistent volumes.
Teams are beginning to adopt stronger identity practices. They move from static kubeconfigs to short‑lived OIDC tokens, restrict service accounts to specific namespaces, and enforce least‑privilege RBAC rules. Those steps are essential – they decide who can start a request and limit the set of actions a token can perform. However, the request still travels straight from the MCP server to the Kubernetes API server. No component in that path records each kubectl command, masks sensitive fields in responses, or requires a human to approve high‑impact operations. The blast radius remains large because the gateway offers no visibility or control over what actually reaches the cluster.
Why the data path matters for blast radius
The missing piece is an enforcement layer that sits in the data path. hoop.dev is built exactly for that purpose. By proxying every MCP request, hoop.dev becomes the only place where policy can be applied, where commands can be inspected, and where audit records can be generated. Because hoop.dev sits between the AI agent and the Kubernetes API, it can enforce just‑in‑time access, require approvals for dangerous actions, block unsafe commands, and record the entire session for replay.
How hoop.dev reduces blast radius
- Command‑level blocking: hoop.dev can detect a kubectl delete --all or a kubectl apply that modifies a critical ConfigMap and reject it before it reaches the API server.
- Just‑in‑time approvals: When an LLM tries to create a new namespace, hoop.dev can pause the request and present it to a designated approver. The operation only proceeds after explicit consent.
- Session recording: Every interaction is captured, enabling post‑mortem analysis. If a rogue command slips through, the team can replay the exact sequence of API calls that caused the damage.
- Inline masking: Sensitive fields such as secrets returned by kubectl get secret are redacted in logs, preventing accidental leakage.
These enforcement outcomes exist only because hoop.dev occupies the data path. Without it, the identity layer and RBAC rules can limit who can call the API, but they cannot stop a legitimate token from performing a destructive action once it is issued.
Deploying hoop.dev for MCP gateways
To bring these protections to an MCP‑driven workflow, deploy the hoop.dev gateway close to the Kubernetes cluster – typically as a Docker Compose service on a bastion host or as a pod in the same network. Configure the gateway to trust the same OIDC provider that issues the MCP server’s tokens. Then register the Kubernetes API as a connection, supplying the service‑account credential that the gateway will use. The MCP server talks to hoop.dev instead of the API server directly; hoop.dev inspects each request, applies the policies you define, and forwards only the allowed traffic.