Many teams assume that letting an AI coding assistant like Cursor run directly on a Kubernetes cluster is safe because the agent only executes generated code. In reality, unrestricted pod creation and command execution give the model unfettered access to production workloads, exposing secrets, configuration, and the ability to alter services without oversight. Without guardrails, this exposure is unacceptable.
In the typical ad‑hoc setup, engineers share a kubeconfig file or a static service‑account token with the Cursor process. The token carries broad permissions, often cluster‑admin or at least namespace‑wide write rights. The AI agent then talks straight to the Kubernetes API server, creating pods, applying manifests, and executing arbitrary commands. No audit log records which AI‑generated request triggered a change, and no one can intervene if the model proposes a risky operation.
Why the initial fix is still incomplete
Switching to an OIDC identity provider and granting the Cursor service account the minimum set of RBAC rules is a necessary improvement. The model now authenticates with a short‑lived token that reflects its assigned groups, and the cluster no longer trusts a permanent secret. However, the request still travels directly to the API server. The gateway that could enforce policy, request approval, or hide sensitive fields is missing. As a result, the AI can still create a pod that mounts a secret, run a command that deletes a deployment, or expose internal endpoints, all without any real‑time guardrails or recorded evidence.
How guardrails work for Cursor on Kubernetes
hoop.dev provides the missing data‑path control. It sits between the Cursor agent and the Kubernetes API as a Layer 7 gateway. Every API call passes through hoop.dev, where it is inspected, matched against policy, and either allowed, masked, or routed for human approval. The gateway records the full request and response stream, enabling replay and forensic analysis.
When Cursor attempts to create a pod, hoop.dev first checks the request against a policy that defines which namespaces, images, and volume types are permissible. If the request matches a high‑risk pattern, such as mounting a secret or using a privileged container, hoop.dev pauses the operation and triggers a just‑in‑time approval workflow. An authorized engineer can approve or deny the request from a web console, and the decision is logged alongside the original request.
If the request is allowed but contains fields that should never be exposed (for example, a secret value returned in a pod’s status), hoop.dev applies inline masking before the response reaches Cursor. This prevents the AI model from learning or leaking sensitive data.
All interactions are captured. hoop.dev records each session, preserving the exact API calls, the policy decisions, and any masked data. The audit trail lives outside the cluster, so even a compromised node cannot tamper with the evidence. Teams can later replay a session to understand why a particular change occurred.
Deploying the gateway
Deploy the gateway near the Kubernetes control plane using the provided Docker Compose quick‑start or a Kubernetes manifest. An agent runs on the same network as the cluster, holding the credentials needed to talk to the API server. Users and AI agents authenticate to hoop.dev via OIDC; the gateway validates the token and extracts group membership to drive authorization decisions.
The configuration step registers the Kubernetes target, defines the credential that hoop.dev will use, and sets up the policy rules that embody your guardrails. Because the gateway owns the credential, the Cursor process never sees the underlying service‑account token.
Why this matters
Placing guardrails in the data path eliminates the blind spot that exists when an AI agent talks directly to the API server. The approach reduces blast radius, ensures that every change has a recorded justification, and prevents accidental exposure of secrets. It also satisfies audit requirements by providing immutable evidence of who asked what, when, and with what approval.
For a step‑by‑step walkthrough, see the getting started guide. Detailed policy examples and a deeper dive into guardrail capabilities are available in the learn section.
FAQ
- Can hoop.dev block a pod creation that violates a policy? Yes. The gateway evaluates each create‑pod request against the defined policies and can reject the call before it reaches the Kubernetes API server.
- How does hoop.dev record a session? It streams the full request and response payloads through the gateway, persisting them in an audit store that is separate from the cluster. The recorded data includes the original request, any masking applied, and the outcome of any approval step.
- Do I need to modify my existing CI pipelines? No. The pipelines simply point their kubectl or client calls to the hoop.dev endpoint instead of the raw API server. The gateway handles authentication and policy enforcement transparently.
Explore the open‑source code and contribute at https://github.com/hoophq/hoop.
