When an AI coding assistant writes code directly on a Kubernetes cluster, a single stray command can expose secrets or destabilize production.
Why session recording matters for Cursor agents
Cursor runs inside a developer’s IDE and can issue kubectl calls on behalf of the user. Most teams hand the agent a cluster‑admin kubeconfig that is shared across engineers, CI pipelines, and sometimes even contractors. The result is a landscape where every command is invisible, no one can prove who created a deployment, and a compromised AI model can act with unrestricted privileges.
Current practice – the unsanitized starting state
In many organizations the workflow looks like this:
- A single service account token is stored in a secret file that developers mount into their workstations.
- The token grants full read‑write access to every namespace.
- Cursor receives the token through the IDE extension and begins issuing API calls without any intermediate check.
- Audit logs are limited to the Kubernetes API server, which only records successful API calls and does not capture the exact command line that triggered them.
There is no guarantee that a malicious prompt or a faulty model will not delete a namespace, leak a database password, or spin up a rogue pod. The environment lacks a reliable session recording capability that could be replayed for forensic analysis.
What we need before a fix can work
To protect the cluster we must add a control point that can observe every request, decide whether it is allowed, and store a complete record. The precondition is simple: the AI‑driven request must travel through a gateway that can enforce policy. However, simply inserting a logger on the API server does not satisfy the requirement because the request still reaches the server directly; the gateway would have no authority to block or mask data, and the log would miss commands that never succeed.
Introducing hoop.dev as the data‑path gateway
hoop.dev is a Layer 7 gateway that sits between the Cursor agent and the Kubernetes API server. It proxies the connection, inspects the wire‑protocol traffic, and applies policy before the request ever touches the cluster. The gateway holds the service‑account credential, so the AI agent never sees a secret. Because hoop.dev is the only place enforcement can happen, it can:
- Record each session – every request and response is stored for later replay.
- Mask sensitive fields in responses, such as Secret objects, before they are returned to the agent.
- Block dangerous commands, for example deleting a production namespace, unless an explicit approval is granted.
- Require just‑in‑time approval for privileged operations, ensuring a human signs off before execution.
All of these enforcement outcomes exist only because hoop.dev occupies the data path. The identity layer (OIDC or SAML) decides who may start a session, but without hoop.dev the request would flow straight to the API server, bypassing every guardrail.
Common mistakes to avoid
- Giving the AI agent direct credentials. Store the service‑account token only inside hoop.dev; the agent should never receive it.
- Relying on Kubernetes audit logs alone. Those logs do not capture the exact command line or the full request payload, nor can they block actions.
- Skipping group‑based OIDC scopes. Without mapping groups to fine‑grained policies, every user of Cursor gets the same level of access.
- Forgetting to enable session recording. The gateway can operate without recording; make sure the feature is turned on so every interaction is replayable.
High‑level steps to get session recording for Cursor
- Deploy the hoop.dev gateway near your Kubernetes control plane. The quick‑start guide walks you through a Docker‑Compose deployment that includes the network‑resident agent.
- Configure OIDC authentication so that each developer’s identity is verified before a session begins.
- Register the Kubernetes cluster as a connection in hoop.dev, supplying the service‑account token that the gateway will use.
- Enable the session‑recording feature in the gateway’s policy settings. This tells hoop.dev to store every request/response pair.
- Define a policy that requires approval for any command that modifies cluster‑critical resources. The policy can be scoped to the groups that represent Cursor users.
- Test the flow with a harmless kubectl get pods command issued by Cursor. Verify that the session appears in the hoop.dev UI and can be replayed.
All of the above is described in the getting‑started documentation and the broader feature overview on the learn page. The repository at github.com/hoophq/hoop contains the source code and example configurations.
FAQ
Does hoop.dev record only successful commands?
No. hoop.dev captures the full request and response stream, regardless of whether the API call succeeds, fails, or is blocked by a policy.
Can I replay a recorded session?
Yes. The stored session data can be replayed in the UI, allowing investigators to see exactly what the Cursor agent attempted and what the cluster returned.
Will adding hoop.dev add noticeable latency?
The gateway processes traffic at the protocol layer and introduces only minimal overhead, typically a few milliseconds per request, which is acceptable for most development workflows.
By positioning hoop.dev as the authoritative data‑path gateway, teams gain reliable session recording, real‑time masking, and just‑in‑time approvals for AI‑driven Kubernetes access. This architectural choice eliminates the blind spots that have plagued traditional setups and gives security engineers the evidence they need to protect critical workloads.
