When a contract developer leaves the company, the team often forgets to rotate the service token that the Cursor AI coding agent uses to pull code snippets from the internal repository. Without audit trails, they cannot determine which AI‑generated request caused a change or who triggered it. The token lives in a shared secret file mounted into every pod, and the agent can continue to request code, execute shell commands, and write results to production databases without any visibility into who triggered the action.
Because the agent connects directly to the Kubernetes API and the underlying services, there is no central point that can observe the request, validate the intent, or record the exact sequence of commands. The result is a blind spot: engineers cannot answer basic forensic questions such as which AI‑generated request created a particular database row, which user was responsible for a risky configuration change, or whether a malicious payload was injected during a code‑generation cycle.
In short, the current setup provides the ability to run Cursor, but it offers no audit trails, no approval workflow, and no way to block dangerous operations before they reach the target system.
Why audit trails matter for Cursor agents
Audit trails are the forensic backbone for any system that performs code generation or configuration changes at scale. They allow security teams to reconstruct the exact series of API calls, command executions, and data mutations that resulted from an AI‑driven workflow. Without a reliable trail, investigations become speculative, compliance evidence is incomplete, and the organization cannot reliably enforce least‑privilege principles for automated agents.
For Cursor running on Kubernetes, the audit requirement includes capturing:
- Every request the agent makes to the Kubernetes API server.
- The full command line issued to containers or host shells.
- The responses that contain generated code or configuration snippets.
- Any approval decision that was required before a privileged operation proceeded.
Collecting these items in a durable audit log enables replay, root‑cause analysis, and the generation of evidence for internal security reviews.
How hoop.dev creates audit trails for Cursor on Kubernetes
hoop.dev acts as a Layer 7 gateway that sits between the identity that initiates a request and the Kubernetes control plane. The gateway runs a network‑resident agent inside the same cluster, so all traffic from the Cursor pod to the API server passes through the gateway before reaching the target.
Because the gateway is the only place where the request can be inspected, hoop.dev can enforce the required controls:
- Session recording: hoop.dev records the full request and response stream for each Cursor interaction, producing a complete audit trail that can be replayed later.
- Just‑in‑time approval: when the agent attempts a privileged operation, hoop.dev can pause the request and route it to a human approver before allowing it to continue.
- Command‑level blocking: dangerous Kubernetes verbs such as delete or scale can be denied automatically based on policy.
These outcomes exist only because hoop.dev occupies the data path. The identity system (OIDC or SAML) decides who the request is, but it does not enforce any of the above policies. The gateway is the enforcement point, and hoop.dev is the component that implements the policies.
To get started, follow the getting‑started guide to deploy the gateway in your cluster. The documentation explains how to configure OIDC authentication, register the Kubernetes API as a connection, and enable session recording for Cursor workloads. Once the gateway is in place, every interaction the AI agent has with the cluster will be captured as an audit trail.
Setup: identity and least‑privilege
The first step is to provision a service account for the Cursor pod that has only the permissions it needs to read source code and request code generation. hoop.dev validates the OIDC token presented by the pod, extracts group membership, and maps it to a policy that limits the scope of the request. This ensures that even if the service account is compromised, the gateway can still enforce additional guardrails.
Data path: the gateway enforcement point
All network traffic from the Cursor container to the Kubernetes API server is proxied through the hoop.dev gateway. Because the gateway terminates the protocol, it can inspect every API call, apply masking if needed, and enforce approval workflows before the request reaches the API server. No other component in the stack has visibility into the raw request.
Enforcement outcomes: immutable audit trails
hoop.dev records each session in a durable store, timestamps every event, and attaches the identity of the requesting service account. The resulting log can be queried for forensic analysis, replayed in a sandbox environment, or exported to a SIEM for further correlation. Because the recording happens at the gateway, the audit trail cannot be altered by the Cursor pod or by any downstream component.
FAQ
Do I need to modify my existing Cursor deployment?
No. hoop.dev works with standard Kubernetes clients, so the Cursor pod continues to use its normal configuration. The only change is that the pod’s network traffic is routed through the gateway.
Can I still use my existing OIDC provider?
Yes. hoop.dev is an OIDC relying party and can verify tokens from any compliant provider such as Okta, Azure AD, or Google Workspace.
What happens if an approval request is ignored?
If a request requires human approval and no decision is received within the configured timeout, hoop.dev automatically denies the operation and records the denial in the audit trail.
For deeper technical details, explore the feature documentation. The source code and contribution guidelines are available on GitHub: Explore the repository and contribute on GitHub.
