Least-privilege access for MCP servers on BigQuery

How can you enforce least-privilege access for an MCP server that needs to query BigQuery without handing it a blanket service‑account key?

Why shared credentials are a risk

Many teams provision a single Google service‑account key and mount it on every MCP server that needs to run analytics. The key grants project‑wide privileges, so any compromised server instantly gains read and write access to every dataset, table, and view. Because the key lives on the host, developers can copy it, scripts can embed it, and audit trails rarely capture which user or process actually issued a query. The result is a classic least‑privilege violation: a single credential opens a wide blast radius.

The missing control gap

Even when you decide to tighten IAM policies, say, by assigning the server a role that only allows the permission bigquery.tables.get on a specific dataset, the request still travels straight from the MCP runtime to the BigQuery endpoint. The gateway that carries the traffic does not see the request, so it cannot record the exact SQL statement, mask columns that contain personal data, or require a human to approve a potentially destructive operation such as DROP TABLE. In other words, the least-privilege intent remains on paper, while the enforcement gap leaves the system exposed.

hoop.dev as the data‑path gateway

hoop.dev fills that gap by sitting in the data path between the MCP server and BigQuery. The gateway runs an agent inside the same network segment as the BigQuery service. When a server wants to run a query, it authenticates to hoop.dev using an OIDC token issued by the organization’s identity provider. hoop.dev validates the token, extracts group membership, and evaluates the request against a policy that encodes least‑privilege access rules.

Because hoop.dev controls the flow, it can enforce several outcomes that directly support a least‑privilege model:

• Per‑query audit: hoop.dev records the full SQL statement, the identity that issued it, and the response size. The log is stored separately from the MCP server, providing reliable audit information for investigations.
• Inline masking: before returning results, hoop.dev can redact columns that match a PII pattern, ensuring that downstream services never see raw sensitive data.
• Just‑in‑time approval: if a query matches a high‑risk pattern, such as a DELETE or DROP, hoop.dev routes it to an approver. The request proceeds only after explicit consent.
• Command blocking: policies can outright reject statements that exceed the allowed scope, for example attempts to access tables outside the designated dataset.

All of these controls happen without the MCP server ever seeing the underlying service‑account credential. hoop.dev holds the credential securely and injects it only when a request passes the policy checks.

Putting least‑privilege access into practice

To adopt this pattern, start by deploying the hoop.dev gateway. The quick‑start guide walks you through a Docker Compose launch that includes OIDC configuration, an agent, and a default policy set. Once the gateway is running, register your BigQuery connection in the hoop.dev console. The registration step tells hoop.dev which credential to use for the backend and which datasets are in scope.

Next, define a policy that maps the MCP server’s identity (or the group it belongs to) to the exact tables it may query. The policy language lets you express rules such as “allow SELECT on project.dataset.sales_* but deny any DDL statements.” When a server initiates a connection, hoop.dev checks the OIDC claim against this policy before forwarding the request to BigQuery.

Finally, enable the audit and masking features you need. The audit stream can be shipped to a SIEM or log aggregation service, while masking rules can be configured to hide columns like email or ssn. Because hoop.dev sits in the protocol layer, these features work for any client that communicates using the BigQuery wire protocol, whether it is a standard query tool or an application library.

For step‑by‑step guidance, see the getting‑started documentation. The learn section provides deeper coverage of policy syntax, masking configuration, and audit integration.

When you’re ready to explore the code or contribute improvements, check out the open‑source repository on GitHub.

FAQ

Does hoop.dev replace the service‑account key?

No. hoop.dev stores the key securely and injects it only after a request satisfies the configured least‑privilege policies. The MCP server never receives the raw credential.

Can existing BigQuery client tools still be used?

Yes. Clients point at the hoop.dev endpoint instead of the native BigQuery endpoint. Because hoop.dev speaks the same wire protocol, no code changes are required.

How does hoop.dev enforce least‑privilege access?

Each incoming request is evaluated against a policy that ties OIDC identity attributes to allowed datasets, tables, and SQL verbs. Requests that fall outside the allowed scope are blocked or sent for approval before they ever reach BigQuery.