How can I grant engineers just-in-time access to BigQuery via MCP servers?
Most teams that run analytical workloads on BigQuery provision a single Google service‑account key and embed it in CI pipelines, notebooks, or MCP (Model‑Control‑Plane) servers. The key lives on disks, is copied between environments, and often expires only when someone remembers to rotate it. Because the credential is static, any process that can read the key can issue arbitrary queries, export data, or even drop tables. Auditors see a handful of long‑lived service accounts but no evidence of who actually ran a particular query, and there is no way to stop a risky statement before it hits the data warehouse.
Moving to per‑user OAuth tokens or GCP IAM federation improves the identity picture: each engineer authenticates with their own Google identity, and the token is short‑lived. However, the token is still presented directly to BigQuery. The request reaches the data warehouse without any intervening guardrail, so there is still no real‑time approval workflow, no automatic masking of PII in query results, and no immutable session record that can be replayed for forensic analysis.
Why the data path must enforce just-in-time access
Enforcement belongs where the traffic actually flows. By placing a Layer 7 gateway between the MCP server and BigQuery, you gain a single control surface that can evaluate every query before it is executed. This is the only place you can reliably apply policies such as:
- Require an on‑demand approval for statements that touch sensitive tables.
- Mask columns that contain personal data in the response stream.
- Block commands that match a blacklist of destructive patterns.
- Record the full request and response for later replay.
All of these outcomes are possible only because the gateway sits in the data path. Without that insertion point, the same per‑user token would simply be handed to BigQuery, and the enforcement layer would be absent.
How hoop.dev provides the gateway for BigQuery
hoop.dev is an open‑source, identity‑aware proxy that runs a network‑resident agent next to your BigQuery environment. The workflow looks like this:
- Deploy the hoop.dev gateway using the quick‑start Docker Compose file or the Kubernetes manifest. The deployment includes OIDC/SAML integration, so engineers authenticate with their corporate IdP (Okta, Azure AD, Google Workspace, etc.).
- Register BigQuery as a connection in hoop.dev. The gateway stores the service‑account credential, while the agent runs the native bq CLI on the target host.
- When an MCP server initiates a query, it connects to hoop.dev instead of contacting BigQuery directly. The gateway validates the user’s OIDC token, extracts group membership, and decides whether the request qualifies for just‑in‑time access.
- If the request matches a policy that requires approval, hoop.dev pauses the flow and routes the query to an approver. Once approved, the query is forwarded to the BigQuery backend.
- During the session, hoop.dev can mask any fields flagged as sensitive, block disallowed statements, and record the entire interaction. The recorded session lives outside the agent, providing a reliable audit trail.
Because hoop.dev is the only component that sees the raw query and response, it can enforce just‑in‑time access, inline masking, and command‑level audit without any changes to the MCP server code. The agent never sees the credential, and the user never holds a long‑lived key.
Benefits of using hoop.dev for BigQuery
Implementing just‑in‑time access through hoop.dev reduces blast radius dramatically. A compromised notebook can no longer issue unlimited queries because each statement must pass through the gateway’s policy engine. Auditors gain per‑user, per‑session logs that show exactly what data was accessed and when, satisfying many compliance requirements. Inline masking ensures that downstream consumers never see raw PII, even if the original query was overly broad. Finally, the approval workflow adds a human checkpoint for high‑risk operations without slowing down routine analytics.
Getting started
All of the architectural pieces are described in the public documentation. Begin with the getting‑started guide to spin up the gateway and register a BigQuery connection. The learn section contains deeper explanations of masking policies, approval flows, and session replay. When you are ready to explore the source or contribute, the repository is available on GitHub:
Explore the source on GitHub
FAQ
Q: Does hoop.dev replace the service‑account key?
A: No. The key remains stored inside the gateway, but it is never exposed to users or MCP servers. Access is granted on a per‑request basis, providing just‑in‑time control.
Q: Can I still use existing BigQuery client libraries?
A: Yes. Clients point at the hoop.dev endpoint instead of the native BigQuery endpoint. The protocol is unchanged, so libraries work without modification.
Q: How does masking work for query results?
A: hoop.dev inspects the response stream and replaces values in columns marked as sensitive. The original data never leaves the gateway unmasked, and the masking policy is defined centrally in the gateway configuration.
