Non-human identity for MCP servers on BigQuery

Many teams assume that a non-human identity used by an MCP server can simply be handed a static Google credential and that’s enough to keep BigQuery queries safe. The reality is that a static key gives the server unrestricted access, leaves every query untracked, and provides no way to prevent accidental data leakage.

Why non-human identity matters for BigQuery

Non-human identities, service accounts, AI agents, or automated runtimes, operate without the contextual checks that a human operator would normally trigger. When such an identity runs against a data warehouse like BigQuery, the risk surface expands dramatically. A mis‑configured query can scan entire tables, an exploited credential can be reused elsewhere, and compliance auditors will struggle to prove who initiated a particular data export.

Regulatory frameworks and internal policies increasingly require per‑request justification, audit trails, and the ability to redact sensitive fields before they leave the database. Those requirements cannot be satisfied by a bare service account alone.

The missing enforcement layer

Identity providers (Okta, Azure AD, Google Workspace) can authenticate the MCP server, and IAM can limit the scopes of the underlying Google service‑account key. This setup decides who the request is, but it does not inspect the actual query, mask results, or capture a replayable session. Without a dedicated enforcement point, the request travels directly to BigQuery, bypassing any real‑time guardrails.

What teams need is a gateway that sits on the data path, intercepts the protocol, and applies policies before the query reaches BigQuery and before the response returns to the caller.

How hoop.dev provides the required data‑path control

hoop.dev is a Layer 7 gateway that proxies the connection between an MCP server and BigQuery. The deployment consists of a network‑resident agent that runs alongside the BigQuery endpoint and a central gateway that authenticates users and non-human identities via OIDC or SAML. The gateway holds the credential for BigQuery, so the MCP server never sees the raw secret.

Because the gateway sits in the data path, hoop.dev can enforce every control that a non-human identity scenario demands:

• hoop.dev records each query and its full result set, creating a replayable audit log.
• hoop.dev masks sensitive columns in the response according to policy, ensuring that downstream systems never receive raw PII.
• hoop.dev requires just‑in‑time approval for queries that match a risk profile, pausing execution until an authorized reviewer grants permission.
• hoop.dev blocks dangerous commands such as DROP TABLE or EXPORT DATA before they are sent to BigQuery.
• hoop.dev ties every session to the originating service account, preserving a clear chain of custody for compliance reporting.

All of these outcomes exist because hoop.dev is the sole component that can see and act on the traffic between the MCP server and BigQuery. The identity provider alone cannot provide them, and the BigQuery service itself does not offer inline masking or real‑time approval.

Conceptual steps to enable non-human identity with hoop.dev

1. Register the Google service‑account key (or enable GCP IAM federation for per‑user OAuth) as a credential on the hoop.dev connection definition for BigQuery.

2. Configure OIDC authentication so that the MCP server presents a token representing its non-human identity. hoop.dev validates the token, extracts group membership, and maps it to the appropriate access policy.

3. Define masking rules and approval workflows in the hoop.dev policy UI. For example, mask columns named email or ssn, and require approval for any query that touches the payments table.

4. Deploy the gateway and the agent using the Docker Compose quick‑start or the Kubernetes manifests. The agent runs near the BigQuery endpoint, ensuring that all traffic is forced through the gateway.

5. Run the MCP server as usual, pointing its client library at the hoop.dev endpoint. From the server’s perspective nothing changes; hoop.dev transparently applies the policies you defined.

When the system is live, every query from the MCP server is inspected, possibly paused for approval, masked as needed, and logged for later replay. If a malicious command is attempted, hoop.dev blocks it before it reaches BigQuery, protecting the data warehouse from accidental or intentional abuse.

Getting started

The official getting‑started guide walks you through installing the gateway, configuring OIDC, and adding a BigQuery connection. For a deeper dive into policy definition, masking, and approval workflows, see the learn section. The full source code and deployment manifests are available in the GitHub repository.

FAQ

Do I still need IAM roles on the Google service account?

Yes. hoop.dev stores the credential, but the underlying IAM policy determines what the service account can do inside BigQuery. Restrict the service account to the minimum required dataset and query permissions, then let hoop.dev add the runtime guardrails.

Can hoop.dev mask data that is already encrypted at rest?

hoop.dev operates on the response stream after BigQuery decrypts the data for the client. Masking rules are applied in real time, ensuring that downstream consumers never see the raw value, regardless of how it is stored.

What happens if an approval request is denied?

hoop.dev aborts the query and returns a clear error to the MCP server. The session is still recorded, so you have evidence of the attempted access and the denial decision.

By placing a Layer 7 gateway between non-human identities and BigQuery, hoop.dev gives you the visibility, control, and compliance evidence that static credentials alone cannot provide.