When data exfiltration from BigQuery is fully contained, every query that leaves the warehouse is either approved, masked, or blocked, and you have an immutable record of who attempted what.
Current practice: open BigQuery access
Most teams grant engineers and service accounts a static service‑account key or a long‑lived OAuth token that lets a client connect directly to the BigQuery endpoint. The client talks straight to the Google API, and the request bypasses any central control point. Because the credential is stored on the workstation or in a CI pipeline, anyone who obtains it can run arbitrary SELECT statements, export tables, or copy data to external storage without additional oversight. Auditing is limited to the logs that Google Cloud generates, which often lack the granularity needed to tie a specific query to a human decision.
Why that model leaves data exfiltration open
The direct connection model satisfies the first two layers of identity – an OIDC token proves who the caller is, and IAM policies give the caller the least‑privilege permissions needed for the job. Those layers, however, do not provide a place to enforce runtime guardrails. The request reaches BigQuery unchanged, so there is no opportunity to inspect the SQL, to require an approval step for large result sets, or to mask columns that contain personally identifiable information. In short, the setup decides who may start a session, but it does not control what the session does.
Introducing an MCP gateway as the data‑path control
Placing an MCP (Model‑Control‑Proxy) gateway between the identity layer and BigQuery creates a single, enforceable boundary. The gateway runs on a host inside the same network as the BigQuery proxy endpoint, and every client – whether a human, a CI job, or an AI‑assisted tool – must route its queries through this proxy. Because the gateway terminates the wire‑protocol, it can examine each SQL statement before it reaches the warehouse.
How the gateway enforces protection
- hoop.dev requires just‑in‑time approval for queries that exceed a configurable result‑size threshold, sending the request to a designated approver before it is forwarded.
- hoop.dev masks sensitive columns in query results in real time, replacing values that match policy‑defined patterns with placeholder text.
- hoop.dev blocks prohibited commands such as EXPORT, COPY TO GCS, or any statement that references a black‑listed dataset.
- hoop.dev records every session, storing the full request, the decision path (approved, blocked, or masked), and the identity that initiated it for replay and audit.
All of these outcomes exist only because the gateway sits in the data path. The identity configuration that grants a token does not, by itself, prevent a rogue SELECT that pulls an entire table. By routing traffic through the gateway, you gain a single point where policy can be applied consistently, regardless of the client language or automation framework.