MCP gateways: what they mean for your prompt-injection risk (on BigQuery)

Can an LLM safely generate BigQuery SQL without exposing your organization to prompt-injection risk? Teams that let language models write queries often hand the raw prompt straight to the data warehouse, trusting the model to stay within the intended scope. In practice, a malicious or malformed prompt can cause the model to inject additional clauses, exfiltrate data, or trigger costly scans. The result is a hidden attack surface that bypasses traditional network firewalls because the request originates from a legitimate client.

Most early implementations of MCP (Model‑Control‑Plane) gateways treat the gateway as a simple pass‑through. The LLM sends a request, the gateway forwards it to BigQuery, and the response returns unchanged. This arrangement solves one problem, centralising the connection endpoint, but it leaves three critical gaps:

• There is no visibility into which exact SQL text was generated before it reaches BigQuery.
• Any injected clause executes without a chance for human review or automated policy enforcement.
• Because the gateway does not retain a record of the exchange, post‑mortem investigations lack the raw query‑response pair.

These gaps are the exact definition of the precondition this post addresses: we need a mechanism that can inspect, approve, or block LLM‑generated queries before they touch the data warehouse, while still allowing the model to operate without direct credential exposure. The gateway must sit in the data path, not merely in the surrounding orchestration layer.

Why prompt-injection risk matters for LLM‑driven BigQuery queries

Prompt injection occurs when an adversary crafts input that causes the model to output unintended commands. In the context of BigQuery, a seemingly innocuous prompt such as “Show me the top‑selling products” can be extended with “; DROP TABLE customers;”. If the model includes the malicious fragment, the query is sent to BigQuery and can cause data loss, unauthorized data exposure, or excessive billing.

Because the model’s output is generated at runtime, static code reviews cannot catch these injections. Traditional IAM policies protect the credential but not the content of the query. Consequently, the organization must enforce policy at the point where the query is formed, which is precisely the data path between the LLM and BigQuery.

What an MCP gateway does without enforcement

An MCP gateway without enforcement acts as a network‑level proxy. It authenticates the caller, forwards the request, and returns the response. The gateway’s setup phase, configuring OIDC or SAML, provisioning service accounts, and assigning least‑privilege roles, determines who may initiate a request. This setup is essential, but it does not provide any runtime guardrails. The request still reaches BigQuery directly, and there is no inline inspection, masking, or approval workflow. In other words, the gateway solves identity verification but not content validation.

Because the gateway does not intervene, any prompt‑injection payload passes through unchecked. The organization remains exposed to the very risk it sought to mitigate.

How hoop.dev closes the gap

hoop.dev is designed to sit in the data path as an identity‑aware proxy. It receives the LLM‑generated SQL, inspects the payload, and applies policy before the query ever contacts BigQuery. The enforcement outcomes are provided exclusively by hoop.dev:

• Query‑level audit: hoop.dev records each request and response, creating a replayable log that auditors can examine.
• Inline masking: Sensitive literals such as credit‑card numbers are redacted in the response before they reach the model.
• Just‑in‑time approval: If a query matches a high‑risk pattern, hoop.dev routes it to a human reviewer for explicit consent.
• Command blocking: Detected injection signatures are blocked, preventing execution entirely.
• Session recording: The full interaction is captured for later forensic analysis.

Because hoop.dev is the only component that can enforce these outcomes, removing it restores the original vulnerable state. The gateway’s setup, OIDC tokens, service accounts, and role bindings, still decides who can start a request, but without hoop.dev in the data path the request reaches BigQuery unchecked.

Putting the pieces together

The secure architecture consists of three layers:

1. Setup: Identity providers issue tokens, and administrators provision least‑privilege service accounts for the gateway.
2. The data path: hoop.dev sits between the LLM and BigQuery, acting as the sole enforcement point.
3. Enforcement outcomes: hoop.dev audits, masks, approves, blocks, and records every query, ensuring prompt‑injection risk is mitigated.

By placing the gateway in the data path, you gain deterministic control over every piece of SQL that touches your warehouse. The model never sees the underlying credential, and any malicious fragment is caught before it can cause harm.

Getting started

To experiment with this pattern, follow the getting started guide for deploying hoop.dev in a container or Kubernetes cluster. The learn section explains how to configure masking rules, approval workflows, and session replay. All configuration is expressed as policy; the gateway enforces it at runtime.

Explore the open‑source code on GitHub to see how the proxy intercepts BigQuery traffic and applies the policies described above.