How can an automated MCP server reliably query BigQuery without exposing a long‑lived service‑account key?
Why non-human identity matters for BigQuery
Machine‑to‑machine workloads often need read‑only or analytics access to data warehouses. Teams typically grant that ability by creating a Google service‑account key and embedding the JSON file in the container image or CI pipeline. The key never expires, is copied across environments, and can be used by any process that gains file‑system access. If the key is leaked, an attacker can exfiltrate data, run costly queries, or modify tables, all while bypassing any human review.
Beyond the credential risk, static keys provide no visibility into which automated job performed a given query. Auditors cannot tie a specific query to a particular build, deployment, or scheduled run. The result is a blind spot in both security and compliance reporting.
The missing control layer
Switching to per‑user OAuth tokens or workload‑identity federation reduces the lifetime of credentials, but the request still travels straight from the MCP server to BigQuery. The traffic bypasses any enforcement point that could:
- Inspect the SQL statement for sensitive column exposure
- Require an approval step for expensive or write‑heavy queries
- Record the full session for replay during investigations
- Mask personally identifiable information in query results before it reaches downstream systems
Without a gateway, those controls remain unavailable. The setup alone, identity federation, does not give you the audit trail or inline data protection you need.
Insert a data‑path gateway to close the gap
hoop.dev acts as a Layer 7 gateway that sits between the MCP server and BigQuery. The gateway verifies the non‑human identity presented by the workload, then proxies the SQL traffic. Because the connection passes through hoop.dev, it can enforce just‑in‑time policies, require approvals, mask result sets, and record every statement for later replay.
Setup: federated identity for machines
First, configure the MCP server to obtain a short‑lived OAuth token via Google workload‑identity federation. The token proves the server’s service account membership without ever storing a static key. hoop.dev consumes that token, extracts group membership, and maps it to the access policies you define.
The data path: hoop.dev as the only enforcement point
All BigQuery traffic is forced through hoop.dev. Because the gateway operates at the protocol layer, it can examine each SQL statement before it reaches the database. This is the sole place where masking, command blocking, or approval routing can happen.
Enforcement outcomes delivered by hoop.dev
- hoop.dev records each query, the presenting identity, and the full result set for replay.
- hoop.dev masks columns that contain personally identifiable information in real time, preventing downstream systems from seeing raw data.
- hoop.dev blocks queries that match a risky pattern (for example, full‑table scans on large partitions) and routes them to an on‑call engineer for approval.
- hoop.dev enforces just‑in‑time access, granting the MCP server permission only for the duration of the approved session.
These outcomes exist only because the gateway sits in the data path; removing hoop.dev would revert the system to the insecure direct connection described earlier.
Getting started
Follow the step‑by‑step guide in the getting‑started documentation to deploy the gateway, register a BigQuery connection, and bind it to your workload‑identity configuration. The learn section provides deeper coverage of policy authoring, masking rules, and approval workflows.
FAQ
Can I still use a service‑account key if I need to?
Yes, but hoop.dev will treat the key as just another credential and still enforce all policies on the traffic that passes through it. The gateway does not depend on the credential type.
Does hoop.dev store any data from BigQuery?
hoop.dev records session metadata and query results only for the purpose of audit and replay. Storage details and retention policies are described in the documentation.
How does this help with compliance reporting?
Because every query is tied to a non‑human identity and stored in an audit log, auditors can trace data access back to the exact automated job, time, and approval decision.
Ready to see the code in action? Explore the open‑source repository on GitHub and start securing your MCP‑to‑BigQuery pipelines today.
