Giving an AI coding agent unrestricted production access on a Kubernetes cluster is a recipe for runaway changes.
In many organizations the Cursor service runs inside the cluster with a long‑lived service‑account token that has cluster‑admin privileges. The token is mounted into the pod at launch and never rotated. Because the token is static, any compromise of the agent or a bug in the model can issue create, delete, or edit operations across the entire namespace without any human oversight. No audit trail is kept, no secrets are hidden, and the damage can spread before anyone notices.
The immediate goal is to enforce production access – only the actions that are required for the AI to assist developers, and only when a human approves them. The request still needs to reach the Kubernetes API server directly; the gateway cannot replace the API server, it must sit in front of it. At this stage the system still lacks any inline approval, command‑level audit, or data masking.
Why the current approach fails
Relying on a static credential violates the principle of least privilege. The credential grants blanket rights, so any request, even a harmless read, travels with the same authority as a destructive delete. Without a mediation layer there is no point where policy can be enforced, no place to inject a human decision, and no record of who asked what. The result is a blind spot for security teams and an unbounded blast radius for accidental or malicious activity.
What a proper control plane looks like
A sound solution must separate three concerns:
- Setup: Identity providers (OIDC/SAML) issue short‑lived tokens that identify the calling service or user. Least‑privilege roles are attached to those tokens, and the token is presented to the gateway.
- The data path: A proxy sits on the network path between the AI agent and the Kubernetes API. All traffic is inspected before it reaches the API server.
- Enforcement outcomes: The proxy decides whether to allow, block, or require approval for each API call, masks sensitive fields in responses, and records the entire session for replay.
Only when these three layers are in place can production access be truly controlled.
How hoop.dev provides the missing guardrails
hoop.dev sits in the data path between the AI agent and the Kubernetes API server, acting as an identity‑aware proxy. It verifies the OIDC token presented by the Cursor pod, extracts group membership, and maps that to fine‑grained Kubernetes permissions.
When a request reaches the gateway, hoop.dev evaluates it against configured policies. If the operation is read‑only, it is allowed to proceed. If the operation is potentially destructive – for example, creating a Deployment, deleting a Service, or modifying a ConfigMap – hoop.dev can:
- Require a human approver before forwarding the request.
- Block the request outright if it violates a predefined rule.
- Mask secret fields such as data in ConfigMaps so that the AI never sees raw credentials.
Every interaction, successful or blocked, is recorded by hoop.dev. The session log includes the identity that initiated the call, the exact API payload, and the outcome. Because the gateway holds the credential, the AI agent never sees the service‑account token; hoop.dev supplies a short‑lived credential on its behalf.
These enforcement outcomes – just‑in‑time approval, inline masking, command‑level audit, and session replay – exist only because hoop.dev occupies the data path. Remove hoop.dev and the request would flow directly to the Kubernetes API with no guardrails.
High‑level deployment steps
- Deploy the hoop.dev gateway in a network segment that can reach the Kubernetes API. The official getting‑started guide walks through a Docker‑Compose or Kubernetes deployment.
- Register the target cluster as a connection in hoop.dev, providing the API endpoint and a service‑account credential that has only the minimal base role.
- Configure OIDC authentication so that the Cursor pod receives a short‑lived token from your identity provider. hoop.dev will validate this token on every request.
- Enable the production‑access policies: define which API verbs require approval, which resources are masked, and the audit retention period. Learn more about policy configuration for masking and approvals.
- Update the Cursor deployment to point its Kubernetes client at the hoop.dev endpoint instead of the native API server. The client library remains unchanged; only the network address changes.
After these steps, any Cursor‑driven operation must pass through hoop.dev, guaranteeing that production access is mediated, recorded, and auditable.
FAQ
Is hoop.dev compatible with existing CI/CD pipelines?
Yes. Because hoop.dev proxies standard Kubernetes API traffic, any tool that talks to the API – including CI/CD runners – can be pointed at the gateway without code changes. Policies can be scoped per‑pipeline token, ensuring that automated jobs only get the permissions they need.
What happens to existing service‑account tokens?
Existing tokens should be rotated to short‑lived OIDC tokens. hoop.dev will reject stale static tokens, forcing a migration to the safer model.
Can I still use kubectl directly?
kubectl can be configured to use the hoop.dev endpoint. The same command‑line experience is retained, but every request is now subject to the gateway’s policies.
By placing enforcement in the data path, hoop.dev turns unrestricted AI‑driven access into a controlled, auditable workflow that meets production‑access requirements.
View the open‑source repository on GitHub
