When an AI assistant can run arbitrary SQL against your data warehouse, a single mis‑prompt can expose millions of rows, trigger compliance violations, and inflate cloud bills. Over‑privileged service accounts that power these assistants become a single point of failure, and any breach of the account instantly grants the attacker unrestricted read and write access to the entire dataset, violating the principle of least privilege.
Many teams today place a static credential with broad BigQuery permissions into an MCP gateway and let the gateway forward every request. The gateway itself is often treated as a trusted conduit, so engineers focus on the convenience of a single endpoint and ignore the fact that the underlying token still carries the full set of permissions. No per‑query checks, no real‑time data redaction, and no audit trail are enforced by default. The result is a hidden attack surface that scales with the number of AI‑driven workloads.
Why least privilege matters with MCP gateways
The core problem is that the MCP gateway does not change the privilege level of the credential it forwards. If the credential can list all tables, read any column, and write to any dataset, the gateway merely becomes a convenient shortcut for that power. In practice this means:
- Accidental data leakage when an LLM hallucinates a query that touches sensitive fields.
- Uncontrolled cost spikes caused by large‑scale scans that were never intended for the AI workload.
- Difficulty proving compliance because there is no record of which user or which prompt triggered a particular query.
These risks persist even though the organization may have strong identity providers, role‑based access controls, and audit logging at the cloud provider level. The missing piece is a control point that can enforce least privilege at the moment the request crosses the network boundary.
What MCP gateways fix – and what they leave open
Deploying an MCP gateway does solve a couple of operational headaches. It centralizes endpoint management, reduces the number of secrets stored on individual machines, and gives a single place to rotate credentials. However, the gateway still forwards the original credential unchanged. The request reaches BigQuery directly, carrying the same wide‑scope permissions it started with. No inline masking of sensitive columns occurs, no just‑in‑time approval workflow can intervene, and the gateway does not retain a replayable session record. In short, the gateway eliminates secret sprawl but does not enforce least privilege on each query.
hoop.dev as the data‑path enforcement layer
To close the gap, the access control logic must sit in the data path – the point where traffic passes between the AI agent and BigQuery. hoop.dev is built exactly for that role. It acts as an identity‑aware proxy that intercepts every BigQuery request, evaluates the request against policy, and then forwards only the minimal set of permissions needed for that specific operation.
When a prompt arrives, hoop.dev extracts the user’s identity from the OIDC token, checks the requested tables against a policy that defines which columns are allowed, and can mask or redact any field that is out of scope. If a query attempts to access a restricted dataset, hoop.dev can pause the request and route it to a human approver before it proceeds. Every interaction, including the original prompt, the evaluated policy decision, and the final query sent to BigQuery, is recorded in a session log that can be replayed for audit or forensic analysis.