How can you enforce production access control for BigQuery MCP servers without exposing credentials or sacrificing agility?
Why production access control matters for BigQuery MCP servers
BigQuery hosts analytical workloads that often contain customer‑sensitive data, financial aggregates, or proprietary metrics. When a machine‑learning model or an internal reporting tool talks to a BigQuery MCP (Managed Cloud Platform) server in production, a single rogue query can exfiltrate rows, corrupt tables, or inflate costs. Organizations therefore need a guardrail that ties every query to a verified identity, limits the data that can be returned, and records the exact command sequence for later review.
Current practice without a gateway
Many teams grant a shared Google service‑account key to the application that runs the model. The key lives in a secret store, is copied into containers, and is used by every instance that talks to BigQuery. This approach has three painful side effects:
- All developers and CI pipelines inherit the same privileges, so there is no notion of “who ran what”.
- Because the service account can read any table the project allows, accidental or malicious queries can pull raw customer data without any check.
- The connection bypasses any approval workflow, and the platform does not keep a replayable audit of the query stream.
Even when teams switch to per‑user OAuth tokens via GCP IAM Federation, the token still travels straight from the client to BigQuery. The request reaches the data store directly, so the system still lacks a place to enforce masking, block dangerous commands, or require a human sign‑off before a high‑risk query runs.
What you need beyond identity
Identity verification alone does not satisfy production access control. You also need a control point that sits on the data path, where the platform can:
- Inspect each SQL statement before it touches BigQuery.
- Apply real‑time redaction to columns that contain personally identifiable information.
- Pause execution of queries that match a risk pattern and route them to an approver.
- Capture the full request and response stream for replay in an audit log.
Without such a gateway, the only enforcement you get is the static IAM policy baked into the service account, which cannot adapt to context, cannot mask data, and cannot produce per‑session evidence.
Embedding hoop.dev as the data‑path enforcement layer
hoop.dev provides a Layer 7 gateway that sits between the client (engineer, CI job, or AI agent) and the BigQuery MCP server. The gateway runs an agent inside the same network as the BigQuery endpoint and terminates the client connection. Because the gateway controls the protocol flow, it can enforce all of the production access control requirements described above.
When a request arrives, hoop.dev validates the OIDC token, extracts the user’s groups, and then evaluates the SQL statement against configurable guardrails. If the statement matches a high‑risk pattern, the gateway routes it to an approval workflow. If the statement contains columns marked as sensitive, hoop.dev masks those fields in the response before they reach the client. Every session, both the query text and the filtered result set, is recorded for later replay.
Key enforcement outcomes with hoop.dev
- Just‑in‑time approval: The gateway pauses risky queries and requires a designated approver to sign off before execution proceeds.
- Inline data masking: Sensitive columns are redacted in real time, so downstream services never see raw PII.
- Command‑level audit: Each SQL statement and its masked response are recorded as audit entries, enabling forensic analysis and compliance reporting.
- Session recording and replay: The full interaction can be replayed in a sandbox to verify that the correct policies were applied.
- Zero credential exposure: The gateway holds the service‑account key; clients never see the underlying credential, reducing the blast radius of a secret leak.
Getting started
To adopt this model, deploy the hoop.dev gateway using the official Docker Compose quick‑start or the Kubernetes manifest. Register your BigQuery endpoint as a connection, point the gateway to the service‑account key (or enable GCP IAM Federation for per‑user tokens), and configure the masking and approval policies that match your risk appetite. Detailed steps live in the getting‑started guide, and the broader feature set is described in the learn section. All source code and configuration examples are available in the GitHub repository.
FAQ
Does hoop.dev replace the need for IAM policies?
No. IAM still decides who can obtain a token. hoop.dev adds the enforcement layer that operates on the data path, turning IAM decisions into actionable guardrails.
Can I apply different masking rules per table?
Yes. The gateway lets you define column‑level masks that trigger only for the tables you specify, ensuring fine‑grained control.
How does replay work for a recorded session?
hoop.dev stores the raw request and the masked response. You can replay the session in a sandbox environment to verify policy behavior without re‑executing the query against production data.
