Many assume that simply routing a query through an MCP server automatically hides PII in BigQuery results. In reality the server forwards the raw response unchanged unless a dedicated data masking layer is inserted. Without that layer, the protection that data masking promises never materialises.
Teams that let developers or automated agents run analytics often grant a shared service‑account key to the MCP runtime. The key lives in the environment, and every query travels straight to BigQuery. No one watches the data that returns, and any column that contains personal identifiers exposes the caller to that data. The result is a convenient shortcut that bypasses the very protection many compliance frameworks require.
Even when an organization upgrades to per‑user OAuth tokens for the MCP server, the request still reaches BigQuery directly. The gateway that the MCP runtime uses knows the user’s identity, but it does not intervene in the response stream. Sensitive fields flow out of the data warehouse unchanged, and there is no audit trail that shows which rows were read.
How data masking works with hoop.dev
hoop.dev is a Layer 7 gateway that sits between the MCP server and BigQuery. The gateway runs an agent inside the network where BigQuery is reachable. The agent holds the credential that the gateway uses to talk to the warehouse, so users and agents never see the secret themselves.
When a user authenticates through an OIDC or SAML provider, hoop.dev validates the token, extracts group membership, and decides whether the user may start a session. Once the system approves the session, hoop.dev proxies the request through the gateway. At that point hoop.dev becomes the only place where enforcement can happen.
For data masking, hoop.dev inspects the response payload at the protocol level. Administrators define which columns they consider sensitive, email addresses, social security numbers, credit‑card numbers, or any custom field. As each row returns, hoop.dev replaces the configured columns with a placeholder or a redacted value before the data leaves the gateway. The original values never travel beyond the gateway, and hoop.dev logs the masking decision as part of the session record.
Because the masking occurs inside the data path, hoop.dev guarantees the outcome. Removing the gateway would deliver raw values to the caller. hoop.dev also records the entire session, enabling replay for forensic analysis or audit reviews. hoop.dev records the user identity, the exact query, and the masked result set, providing evidence that the masking policy was applied.
Why place the mask at the gateway?
- Centralised policy: a single definition of sensitive fields applies to every MCP‑driven query.
- Zero‑trust posture: the credential never leaves the agent, reducing the attack surface.
- Auditability: every masked response ties to a user and a timestamp, satisfying compliance requirements.
- Just‑in‑time control: administrators can adjust masking rules without redeploying the MCP runtime.
- Consistent evidence: hoop.dev’s session log serves as a reliable source for auditors who need to verify that data masking was enforced.
Getting started
Deploy the hoop.dev gateway using the Docker Compose quick‑start or the Kubernetes manifests. Register a BigQuery connection, point the gateway to the service‑account key (or enable GCP IAM federation for per‑user OAuth), and configure the columns you want masked. The official getting‑started guide walks through each step, and the Learn section provides deeper detail on masking policies.
For a complete example, see the documentation at Getting started and explore the masking feature guide on the Learn page. GitHub hosts the full source code, deployment scripts, and contribution guidelines at GitHub. Deploying the gateway gives you a single enforcement point for every BigQuery request that an MCP server makes.
FAQ
Does hoop.dev store the raw data after masking? No. The gateway only records the session metadata and the masked result set. hoop.dev never persists the original values; they remain inside BigQuery.
Can I mask data conditionally, based on the user or query? Yes. Masking rules can reference user attributes or query patterns, allowing fine‑grained control without changing the MCP server code.
What happens if a masking rule is misconfigured? The gateway logs a warning and continues to forward the response unmasked. Administrators can review the logs, correct the rule, and re‑run the session to verify proper masking.
How does hoop.dev help with regulatory audits? hoop.dev records every session with the identity of the caller, the exact query, and the masked output. Auditors can retrieve these logs to demonstrate that data masking was enforced consistently across all queries.
