Why SOC 2 matters for Cursor
A common misconception is that simply logging into Cursor satisfies SOC 2 requirements. In reality, SOC 2 demands continuous, tamper‑evident evidence of who accessed what, when, and under what policy. Teams that run data‑driven workloads on Cursor often focus on performance and cost, leaving audit and control as an afterthought.
The unsanitized starting state
Most engineering groups configure a single service account or API key that is baked into CI pipelines, shared across developers, and used to connect to Cursor directly. The credential lives in a secrets manager, but every user or automation script can invoke the same token without any per‑request check. Because the connection goes straight from the client to the Cursor server, there is no visibility into the exact query, no ability to block risky statements, and no record of who approved a data‑export operation. When a breach occurs, the logs show only that the service account ran a command, not which human initiated it or whether the command complied with policy.
The missing control plane
Organizations trying to meet SOC 2 typically adopt identity federation, least‑privilege roles, and short‑lived OIDC tokens. Those steps identify *who* can start a session, but they do not enforce *what* can be done once the session is open. The request still reaches Cursor directly, bypassing any real‑time guardrails, approval workflow, or data‑masking step. Without a gateway that can inspect each query, the system cannot generate the continuous evidence SOC 2 auditors require.
hoop.dev as the enforcement point
hoop.dev sits in the data path and records every interaction with Cursor. By proxying the connection, it can apply just‑in‑time access, enforce inline masking of sensitive fields, require manual approval for high‑risk commands, and capture a replayable session log. Because the gateway holds the credential, the end user never sees the secret, and every action is tied to the user’s identity token.
Continuous evidence for SOC 2
When a developer initiates a Cursor query, hoop.dev validates the OIDC token, checks the user’s group membership, and decides whether the request can proceed immediately or needs an approval step. If approval is required, an authorized reviewer receives a notification, and the request is blocked until the reviewer explicitly permits it. Once allowed, hoop.dev masks any columns marked as sensitive, preventing accidental exposure in logs or downstream systems.