An AI‑driven CI job spins up a temporary pod that queries internal services, using a token that was copied from a shared secret. The pod reaches the Kubernetes API through the same HTTP load balancer that serves external traffic. The mcp gateway, advertised as a model‑aware front, is expected to add another layer of control. The team trusts the load balancer’s TLS termination and its basic auth checks, assuming that this traditional API gateway is enough to keep the AI agent in line.
In practice, a traditional API gateway only sees the outer HTTP request. It can enforce authentication, rate limits, and path‑based routing, but it does not understand the semantics of the AI payload that follows. The gateway cannot inspect a prompt that asks the cluster to delete a namespace, nor can it mask a secret that the model returns in a response. Because the gateway forwards the request unchanged, the AI agent talks directly to the Kubernetes control plane with whatever permissions its token carries.
This model leaves three gaps wide open. First, the token is often a static service account key that grants broad cluster access. Second, the gateway does not record the exact commands the model issues, so there is no replayable audit trail. Third, there is no mechanism to pause a risky operation for human approval before it reaches the API server.
Why an mcp gateway alone isn’t enough
The MCP (Model Control Plane) gateway concept adds a dedicated endpoint that AI agents can call instead of the generic load balancer. The endpoint can translate model requests into Kubernetes API calls and return structured results. At a glance, this seems to give the team a place to apply policy.
However, without a data‑path enforcement layer, the request still travels straight from the MCP endpoint to the target cluster. The endpoint itself does not block a delete‑namespace call, does not redact a secret field, and does not capture the full session for later review. The risk surface remains the same: a powerful token, no per‑prompt guardrails, and no evidence of what the model actually did.
hoop.dev as the enforcement point for AI agents
Enter hoop.dev, an open‑source layer‑7 gateway that sits between identity and the Kubernetes API. hoop.dev authenticates users and AI agents via OIDC, reads group membership, and then proxies every request through its own network‑resident agent. Because hoop.dev is the only place the traffic passes, it can apply the full suite of MCP gateway controls.
hoop.dev records each session, so auditors can replay exactly what the model asked the cluster to do. It masks sensitive fields in responses, preventing a model from leaking secrets. It blocks dangerous commands before they are executed, and it can route risky operations to a human approver for just‑in‑time consent. The gateway also holds the cluster credentials, ensuring that the AI agent never sees the service account key.
How hoop.dev delivers real control
- Just‑in‑time access: Identity is verified at request time, and the gateway grants the minimal scope needed for that specific operation.
- Inline data masking: Responses that contain credentials or personal data are stripped or redacted before they reach the model.
- Command‑level approval: Any request that matches a high‑risk pattern is paused and presented to an authorized reviewer.
- Session recording and replay: Every byte that passes through the gateway is stored for forensic analysis, satisfying audit requirements.
- Zero credential exposure: The agent that runs inside the cluster never receives the service account secret; hoop.dev injects it only for the proxied connection.
All of these outcomes are possible because hoop.dev is the data path where enforcement occurs. The surrounding identity setup (OIDC, least‑privilege roles) determines who can start a request, but without hoop.dev the request would reach the Kubernetes API unchecked.
Teams that adopt hoop.dev can keep their existing OIDC provider and service‑account policies, then add the gateway as a single control surface for every AI‑driven operation. The getting‑started guide shows how to deploy the gateway alongside your cluster, and the learn section dives deeper into policy configuration.
Frequently asked questions
How does an mcp gateway differ from a regular API gateway?
An mcp gateway is designed to understand model‑generated payloads and translate them into infrastructure calls, while a regular API gateway only sees generic HTTP traffic. The mcp gateway can enforce model‑specific policies only when it sits in a data‑path that can inspect and modify each request, which hoop.dev provides.
Can hoop.dev enforce per‑prompt policies for AI agents?
Yes. Because every request passes through hoop.dev, the gateway can evaluate the content of a prompt, block commands that match a risky pattern, and require human approval before the command reaches the target system.
What audit evidence does hoop.dev generate for compliance?
hoop.dev records a full, replayable session log, captures approval decisions, and logs any data‑masking actions. These logs give auditors a complete picture of who asked what, when, and what the system returned.
Explore the source code and contribute at https://github.com/hoophq/hoop.
