Why session recording matters for AI coding assistants
How can you be sure an AI coding assistant like Cursor isn’t silently running queries against your BigQuery data? The answer lies in session recording. Without a reliable audit trail, every generated query is a black‑box operation that can’t be reviewed, replayed, or tied back to the engineer who triggered it.
Most teams hand a service account or an API key to Cursor and let it talk directly to BigQuery. The credential often has broad read‑write permissions, and the connection bypasses any central control point. In that raw state, there is no record of which statements were issued, what results were returned, or who initiated the request. If a mistake leaks sensitive rows, or an unexpected cost spike appears, you have no forensic evidence to trace the activity.
This lack of visibility is especially risky when the same AI agent runs code on behalf of many developers. The agent can execute dozens of queries per minute, and the aggregate impact is hard to measure without systematic logging. Moreover, compliance regimes that require evidence of data access, such as SOC 2 audits, expect a complete, immutable trail of every database interaction.
What a pure token‑based setup still leaves open
Granting a token to Cursor satisfies the identity requirement: the system knows who the request originates from. However, the token alone does not enforce any guardrails on the data path. The request still travels straight to BigQuery, bypassing any point where you could inspect, mask, or record the traffic. In other words, the setup provides authentication but no enforcement outcomes such as session recording, inline masking, or just‑in‑time approvals.
Because the enforcement point is missing, you cannot retroactively add audit logs, and you cannot enforce policies that depend on the content of the query. The connection remains a blind tunnel.
hoop.dev as the data‑path gateway for session recording
hoop.dev solves this gap by inserting a Layer 7 gateway between Cursor and BigQuery. The gateway runs a network‑resident agent close to the BigQuery endpoint and proxies every client request. When Cursor initiates a query, it authenticates to hoop.dev via OIDC/SAML (for example, through Okta or Azure AD). hoop.dev validates the token, extracts the user’s groups, and then forwards the request to BigQuery on behalf of the agent.
Because the traffic passes through hoop.dev, the platform can apply session recording to each interaction. hoop.dev captures the full request and response payloads, timestamps them, and retains the records for audit and replay. The recorded sessions can be replayed later, allowing auditors or engineers to see exactly what the AI agent asked BigQuery to do and what data was returned.
All enforcement outcomes, recording, masking, just‑in‑time approval, are possible only because hoop.dev sits in the data path. The identity layer (OIDC tokens, service accounts) decides who may start a session, but hoop.dev is the sole place where the policy is enforced and the evidence is generated.
High‑level deployment steps
- Deploy the hoop.dev gateway using the provided Docker Compose quick‑start or a Kubernetes manifest.
- Configure an OIDC provider so that engineers and the Cursor agent can obtain short‑lived tokens.
- Register the BigQuery connection in hoop.dev, supplying the service account that has the minimal required permissions.
- Enable the session‑recording feature for that connection in the hoop.dev UI or via the API.
- Point Cursor’s endpoint URL at the hoop.dev proxy instead of the native BigQuery endpoint.
From that point forward, every query generated by Cursor is funneled through hoop.dev, automatically recorded, and available for replay through the hoop.dev console.
Operational benefits
With session recording in place you gain:
- Full audit trails: each query is tied to a specific user identity and timestamp.
- Forensic replay: you can reconstruct the exact sequence of calls that led to an unexpected result.
- Policy enforcement: future extensions can add inline masking of sensitive columns or require manual approval for high‑cost queries.
- Compliance support: the recorded logs satisfy evidence requirements for standards such as SOC 2.
The gateway also ensures that the Cursor process never sees the underlying BigQuery credentials. The agent only interacts with hoop.dev, which holds the secret on its behalf.
Next steps
For a hands‑on walkthrough, start with the official getting‑started guide. The documentation walks you through deploying the gateway, configuring OIDC, and registering a BigQuery target. For deeper insight into feature configuration, see the feature documentation. All of the configuration details, including the exact YAML snippets, are kept in the open‑source repository.
The source code and contribution guidelines are available on GitHub at https://github.com/hoophq/hoop. Feel free to explore the code, raise issues, or submit pull requests if you need custom extensions.
FAQ
Q: Does hoop.dev store query results?
A: hoop.dev records the request and response metadata for audit purposes. The raw data is retained according to the retention policy you configure, enabling replay without exposing the full data set to the gateway itself.
Q: Can I disable recording for a specific low‑risk connection?
A: Yes. Recording is configurable per connection, so you can turn it off where you have other controls, but the default recommendation is to keep it enabled for any AI‑driven access.
Q: How does hoop.dev handle scaling for many concurrent Cursor sessions?
A: The gateway is stateless and can be horizontally scaled behind a load balancer. Each instance runs its own agent near the target, ensuring low latency while still centralising policy enforcement.
