Many assume that attaching a monitoring agent to a BigQuery MCP server automatically gives you a complete audit trail, but it does not provide session recording. The reality is that the agent runs inside the same trust boundary as the service account and can see every query, but nothing records what was run, when, or by whom.
In most teams today, engineers connect their internal analytics pipelines to BigQuery through a shared service‑account key that the MCP server uses. The key lives on the host, is checked into CI pipelines, and is reused across dozens of jobs. Access is granted at the project level, so a single compromised credential can read or write any table. No central component inspects the traffic, so there is no way to know which query altered a production dataset, nor is there any replay capability for forensic analysis.
Even when organizations adopt OIDC federation to obtain per‑user OAuth tokens, the request still travels directly from the MCP server to BigQuery. The token proves identity for the initial handshake, but the data path remains unmediated. The result is a system that can authenticate users but cannot enforce runtime guardrails, cannot capture a session for later review, and cannot mask sensitive fields in query results. Those gaps leave compliance programs under‑documented and incident response teams blind to the exact sequence of commands that caused a problem.
Why session recording matters for BigQuery MCP servers
Session recording provides a tamper‑evident log of every query, including parameters, results, and timestamps.
For teams subject to internal audits or external regulations, that evidence is essential to prove who accessed what data and when. It also enables replay of a problematic query in a sandbox environment, dramatically reducing the time to root‑cause analysis. Finally, recording creates a deterrent: engineers know their actions are visible, which reduces reckless use of powerful analytics workloads.
Current practice without a gateway
Without a dedicated gateway, the only logs available are the native BigQuery audit logs, which capture request metadata but not the full query payload. They also lack correlation with the originating MCP server or the specific CI job that triggered the request. Engineers often resort to sprinkling ad‑hoc logging statements in their code, a practice that is brittle and easy to forget. Because the service account key is static, any compromise gives an attacker unrestricted read/write access without triggering an alert.
What you need beyond identity
Identity verification is a necessary first step, but it is not sufficient to meet an adequate security posture. The missing piece is a control plane that sits on the data path, intercepts each request, and applies policy before the query reaches BigQuery. That control plane must be able to record the full session, enforce just‑in‑time approvals for risky operations, and optionally mask sensitive columns in the response. Importantly, the request still reaches the target service; the gateway does not replace the underlying connection, it merely observes and governs it.
hoop.dev as the data‑path gateway
hoop.dev fulfills the role of a Layer 7 gateway that proxies connections between the MCP server and BigQuery. When a user or an automated job initiates a query, the request first passes through hoop.dev. The gateway validates the OIDC token, checks group membership, and then forwards the request to the BigQuery endpoint using the credential it holds internally. Because hoop.dev sits in the data path, it can record each session in real time. hoop.dev records each session, stores the full query text, parameters, and result metadata, and makes the replayable artifact available for auditors. The gateway also supports inline masking, so if a query returns personally identifiable information, hoop.dev can redact those fields before they reach the client.
Architectural flow
- Deploy the hoop.dev gateway alongside the MCP server. The gateway runs in a container or Kubernetes pod within the same network segment as the server.
- Register the BigQuery connection in the hoop.dev console, providing the service‑account credential that the gateway will use to talk to BigQuery.
- Configure OIDC authentication so that engineers obtain short‑lived tokens from the corporate IdP. hoop.dev validates those tokens on each request.
- When a query is issued, the MCP server sends it to hoop.dev instead of directly to BigQuery.
- hoop.dev applies the session‑recording policy, optionally masks columns, and forwards the request to BigQuery.
- BigQuery processes the query and returns results to hoop.dev, which records the response metadata and then delivers the (potentially masked) payload back to the MCP server.
- All recorded sessions are stored in the configured backend and can be replayed through the hoop.dev UI or API for audit, compliance, or forensic analysis.
Getting started
To add session recording to your BigQuery MCP workflow, start with the getting started guide. It walks you through deploying the gateway, registering a BigQuery connection, and enabling the session‑recording policy. For deeper details on how masking and approval workflows work, see the learn section. The full source code, contribution guidelines, and example configurations are available on GitHub.
Explore the hoop.dev repository on GitHub to see the implementation details and to start contributing.
FAQ
- Does hoop.dev replace my existing BigQuery credentials? No. hoop.dev holds its own credential for the BigQuery service account. Users never see that credential; they authenticate with OIDC tokens that hoop.dev validates.
- Can I retroactively replay a session that happened before I installed hoop.dev? Session recording only captures traffic that passes through hoop.dev. Historical queries that bypassed the gateway are not automatically recorded.
- Is the recorded data stored securely? hoop.dev writes session artifacts to a backend you configure. The gateway itself does not impose a specific storage mechanism, allowing you to choose an encrypted, access‑controlled store that meets your compliance requirements.
