Do you wonder how to keep an immutable trail of every query an MCP server sends to BigQuery using session recording?
Most teams hand a shared Google service‑account key to their AI runtime, then let the MCP server issue queries without any visibility. The key lives on the host, developers can copy it, and every request bypasses audit, masking, or approval. If a model accidentally runs a data‑exfiltration prompt, the organization has no record of which query caused the leak, nor any way to redact the returned rows.
Why session recording matters for MCP‑driven BigQuery queries
Session recording captures the full request‑response exchange, preserving who asked what, when, and what data was returned. That evidence satisfies internal governance, helps forensic teams trace misuse, and supports compliance audits that require per‑user query logs. Without a recording layer, the only proof of activity is the BigQuery audit log, which often lacks context about the originating MCP process and cannot be correlated with internal approval workflows.
The gap in typical MCP‑to‑BigQuery setups
In a naïve deployment, the MCP server authenticates directly with a static service‑account credential. The setup satisfies the setup requirement – the identity is known and the token can be exchanged for Google OAuth. However, the data path remains a straight line from the MCP process to BigQuery. No component in that path inspects the SQL, masks sensitive columns, or forces a human to approve risky queries. Consequently, the organization loses the ability to enforce just‑in‑time access and cannot guarantee that every session is recorded.
Introducing hoop.dev as the data‑path gateway
hoop.dev sits between the MCP server and BigQuery, acting as an identity‑aware proxy that enforces policy at the protocol layer. When the MCP runtime initiates a query, the request first passes through hoop.dev. The gateway validates the user’s OIDC token, maps group membership to a per‑user policy, and then forwards the query to BigQuery using its own credential. Because hoop.dev is the only point where traffic is inspected, it can apply the required controls.
How hoop.dev records each session
hoop.dev records every request and response pair, attaching the authenticated user ID, timestamp, and the full SQL payload. The recording is stored outside the MCP process, ensuring the agent never sees the raw credential. hoop.dev provides a reliable audit trail that can be replayed for investigation or exported to a SIEM.
Inline masking and just‑in‑time approval
Before forwarding the query, hoop.dev can mask columns that match a sensitive‑data policy, replacing them with placeholders in the response. If a query matches a high‑risk pattern, such as a full table scan on a production dataset, hoop.dev can pause the request and route it to an approval workflow. Only after an authorized reviewer grants access does the query continue, preserving the principle of least privilege.
Deployment checklist for reliable session recording
- Deploy the hoop.dev gateway in the same VPC or subnet as your BigQuery endpoint so that all traffic is forced through the proxy.
- Configure OIDC authentication against your corporate IdP; hoop.dev will verify tokens and extract group claims.
- Register a BigQuery connection in hoop.dev, selecting the credential type that matches your organization’s policy (service‑account key or per‑user OAuth via IAM federation).
- Enable the session‑recording flag in the connection’s policy definition. Verify that recordings appear in the UI after a test query.
- Define masking rules for columns that contain PII or PCI data, and set up approval workflows for queries that exceed a row‑count threshold.
- Integrate the hoop.dev audit logs with your SIEM or log‑aggregation pipeline to retain evidence for the required retention period.
Getting started with hoop.dev and MCP servers
To add session recording to your MCP‑BigQuery pipeline, follow the getting‑started guide. Deploy the gateway, configure the BigQuery connection, and enable the session‑recording feature in the policy definition. The documentation walks you through the required OIDC configuration, the agent deployment model, and how to verify that recordings appear in the UI.
For deeper insight into masking rules, approval workflows, and replay capabilities, learn more about hoop.dev features. The open‑source repository contains example policy files and Helm charts for production deployments.
Explore the source code on GitHub to see how the gateway is built and to contribute improvements.
FAQ
- Is session recording optional for each connection? Yes. hoop.dev lets you enable recording per‑connection, so you can start with critical workloads and expand over time.
- Does hoop.dev store query results? It stores the metadata and the exact bytes that pass through the gateway, which includes masked results when masking policies are active.
- Can existing MCP server code be changed? No. The MCP runtime continues to use its standard BigQuery client libraries; hoop.dev intercepts traffic transparently, so no code changes are required.
