How can you make sure every query an AI coding agent runs against BigQuery is captured for later review?
Why session recording matters for AI coding agents
Devin, an LLM‑driven coding assistant, can generate SQL on the fly and submit it directly to a data warehouse. In many teams the agent runs with a static service‑account key that lives in the CI pipeline. The key grants unrestricted read‑write access, and the agent talks straight to BigQuery. When something goes wrong, an unexpected table drop, a data‑leak query, or a compliance audit request, there is often no reliable record of what the agent actually sent or received. The result is a blind spot: engineers cannot prove whether Devin behaved correctly, and auditors cannot verify that data‑access policies were respected.
Prerequisites before you can record sessions
The first step is to have a trustworthy identity source. Configure an OIDC or SAML provider (Okta, Azure AD, Google Workspace, etc.) that issues short‑lived tokens for each engineer or service account that will invoke Devin. The token tells the access layer who is making the request and which groups they belong to. This step decides whether a request is allowed to start, but it does not enforce any guardrails on the data path itself.
Next, register the BigQuery connection in the access layer. The gateway stores the credential that the agent will use, typically a service‑account key with the minimum set of permissions required for the workload. Because the credential lives inside the gateway, the agent never sees it. This registration is a prerequisite for any enforcement, yet the request would still travel directly to BigQuery without any visibility.
Once identity and connection registration are in place, you need a place where the traffic can be inspected and recorded. That is where hoop.dev comes in. hoop.dev sits in the Layer 7 data path, intercepting the wire‑protocol traffic between the agent and the database. When Devin initiates a query, it connects through hoop.dev instead of contacting BigQuery directly. The gateway reads the incoming SQL, forwards it to BigQuery, receives the response, and then writes a complete record of the exchange to its audit store. In other words, hoop.dev records every session, capturing the exact statement, the execution timestamp, the user identity from the OIDC token, and the result set (or error) that BigQuery returned.
Because the gateway is the only point where traffic is visible, hoop.dev can also apply additional policies if you need them, inline masking of sensitive columns, command‑level blocking of dangerous statements, or just‑in‑time approval workflows. However, the core enforcement outcome that matters for this post, session recording, exists solely because hoop.dev sits in the data path. If you removed hoop.dev and let Devin talk straight to BigQuery, the session would disappear from your audit logs.
Getting started with session recording for Devin
To put this architecture into practice, start with the official getting‑started guide. It walks you through deploying the gateway with Docker Compose, configuring OIDC authentication, and registering a BigQuery connection. The guide also shows how to attach an AI‑agent client to the gateway so that Devin’s queries automatically flow through hoop.dev. For a deeper dive into the recording feature and how the audit data can be queried later, explore the learn section of the documentation.
All of the configuration details, credential files, environment variables, and policy definitions, are kept in the repository. Because hoop.dev is open source, you can inspect the implementation, contribute improvements, or fork the project to suit your internal compliance workflow.
FAQ
- Does hoop.dev store the actual data returned by BigQuery? The gateway records the fact that a query was executed, the identity that ran it, and the outcome. Whether the full result set is retained depends on the retention policy you configure in the audit store.
- Can I disable recording for specific queries? Recording is enforced at the gateway level. You can create policy rules that exclude certain low‑risk operations, but any rule that disables recording removes the audit evidence for those actions.
- Is session recording compatible with other BigQuery tools? Yes. Because hoop.dev operates at the protocol layer, any client that speaks the BigQuery API, including the standard bq CLI, client libraries, or custom scripts, can be routed through the gateway without code changes.
View the source code and contribute on GitHub.
