Securing BigQuery MCP servers requires identity, not just tools

At a glance

What this is: This is an analysis of how a private BigQuery MCP server is secured with OAuth, scoped tools, user-bound tokens, and outbound-only tunnelling.

Why it matters: It matters because IAM teams governing NHI, agentic AI, and human access need to treat MCP as an authorization and attribution problem, not only a network-exposure problem.

Context

A private MCP server changes the exposure model for data access, but it does not remove the need for identity control. In this case, the security problem is not whether BigQuery is reachable, but who can use which tool, under whose credentials, and with what downstream data scope.

The article is really about governance around non-human access patterns that behave like delegated identity, even when a person is the one typing the prompt. That makes the control plane about OAuth, scoped permissions, and user-bound tokens, with tunnelling used to keep the server out of inbound reach.

The key architectural question is whether MCP is treated as a transport mechanism or as an access model. Descope frames it as the latter, because the server only stays safe when identity, authorization, and network exposure are all constrained together.

Key questions

Q: What breaks when MCP servers rely on a single shared credential?

A: A single shared credential breaks attribution, scope control, and revocation precision. If the server can be used by multiple people, you cannot easily tell which human authorised a specific action, and removing the credential can disrupt unrelated workflows. That makes the credential both operationally convenient and governance-heavy.

Q: Why do outbound-only MCP tunnels still need identity controls?

A: Because transport containment only reduces reachability, it does not determine who may invoke which action or what data that action may touch. A private server can still be misused if scopes are too broad or if the token represents the wrong identity. Identity controls decide entitlement, while the tunnel only narrows exposure.

Q: How should teams split authorization between the MCP layer and BigQuery?

A: Use the MCP layer for tool invocation decisions and BigQuery for data access decisions. That avoids duplicating row and column logic inside the server and keeps the tool boundary focused on role entitlement. In practice, the server should validate the token and scope, then defer the actual data visibility rules to the warehouse.

Q: What should IAM teams evaluate before exposing internal data tools through Claude?

A: They should check whether the access path preserves user identity, uses least-privilege scopes, keeps the server private, and makes every tool call auditable. If any of those are missing, the environment is functionally a proxy identity with weak governance. The safest pattern is delegated access with clear entitlement boundaries and platform-native data controls.

Technical breakdown

OAuth-bound MCP access to BigQuery

The server uses OAuth to bind access to a specific user and a specific resource server, rather than relying on a shared service credential. That matters because MCP requests are not inherently trustworthy just because they originate from an AI interface. The authorization server issues the token, the MCP server validates it, and the user identity becomes part of the access path. This is a classic delegated-access pattern, but applied to tool invocation rather than a web app session. The practical effect is that the server never needs to mint credentials itself, which reduces the size of the trust boundary.

Practical implication: validate user-bound tokens at the MCP boundary and avoid shared credentials that erase attribution.

Tool-scoped authorization versus data-scoped authorization

The article separates two control questions that are often blurred together. Tool-scoped authorization decides whether a role can call a capability such as reading customer metrics or writing annotations. Data-scoped authorization then lives in BigQuery itself, where row, table, and column permissions are enforced. That separation is important because a gateway that tries to own both layers usually ends up over-privileging the server. In identity terms, the MCP server should decide who may invoke the tool, while the data platform decides what the person may see once the tool runs.

Practical implication: keep MCP scopes narrow and let the data platform enforce its own fine-grained authorization.

Outbound-only tunnelling for private MCP servers

Anthropic's MCP Tunnels provide a reverse-connection model in which the private server opens outbound connections to a managed edge, rather than being exposed through inbound ports. That changes the firewall problem from allowlisting external IPs to controlling egress from the internal environment. The tunnel improves exposure reduction, but it does not replace identity checks, because the server is still reachable by whatever principals are authorised upstream. In practice, the tunnel is a transport control that complements, rather than substitutes for, the authentication and authorization model.

Practical implication: use outbound-only connectivity to reduce exposure, but keep authorization at the server and tool layer.

NHI Mgmt Group analysis

BigQuery MCP security is an authorization problem before it is a transport problem. The article shows that keeping the server private does not by itself answer who may invoke a tool, what data that invocation may reach, or how the action is attributed. The identity boundary is doing the real work, because the tunnel only hides the server from inbound exposure. Practitioners should treat MCP as a governed access path, not a network shortcut.

Tool-level scoping is the right unit of control for MCP, not server-level access. A token that merely proves someone can talk to the server is too coarse to protect customer data. The useful control is whether the caller can invoke bq.read.customer_metrics or bq.write.annotations, because that is where intent becomes actionable. This maps cleanly to OWASP-NHI thinking about overprivileged machine access and to NIST CSF PR.AA-05. Practitioners should scope tools as discrete entitlements.

Shared service credentials would collapse attribution and make the server the actor of record. The article avoids that pattern by using the individual engineer's own OAuth connection when queries run. That preserves accountability across the human prompt, the MCP server, and BigQuery's own authorization layer. The governance lesson is that delegated tooling should preserve per-user identity all the way through execution. Practitioners should resist any design that turns the server into a blanket proxy identity.

Outbound-only connectivity is a containment control, not a governance model. The tunnel reduces inbound attack surface and avoids public exposure, but it does not tell you whether the caller is entitled to the tool or the data. That distinction matters as hosted agents become common entry points to internal systems. The control story is therefore layered: identity first, scoped authorization second, transport containment third. Practitioners should not confuse reduced exposure with complete access governance.

MCP access for internal AI workflows should be reviewed as delegated NHI use, even when a human remains in the loop. The user is the prompt originator, but the server and its tokens are the execution path. That makes the governance problem closer to workload identity and delegated access than to ordinary chat application security. The implication is that IAM teams need to classify MCP patterns by execution identity, not by interface. Practitioners should evaluate these flows under NHI and workload identity controls.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• Read next: MCP Security Guide

What this signals

Identity-bound MCP governance will become the differentiator between a private tool and a governed access path. The more AI interfaces are allowed to reach internal systems, the more teams will need to decide whether the execution identity is human, delegated, or effectively service-like. That distinction will drive how they write scopes, review access, and attribute actions across the lifecycle.

Delegated access without shared identity is the pattern to watch. The article's model keeps the user visible, the server private, and the tool narrow, which is a cleaner governance shape than a broad proxy credential. For practitioners, that means reviewing whether their own agent workflows preserve the same separation of concerns or quietly merge them into one overprivileged path.

Tool boundary governance is now a core MCP design question. The trust boundary has moved closer to authorization than transport, especially when a hosted agent reaches a private data source. Teams should expect more scrutiny of scoped tool entitlements, connection binding, and auditability as MCP becomes embedded in internal operations.

For practitioners

• Define tools as discrete entitlements Map each MCP tool to a narrow permission boundary, such as read-only metrics versus write actions, and deny any tool call that lacks an explicit scope match.
• Preserve user-bound execution identity Run queries with the individual user's OAuth connection rather than a shared service account so every action remains attributable to the person who authorised it.
• Keep private MCP servers off inbound exposure Use outbound-only tunnelling or equivalent reverse connectivity so the server does not need a public hostname, inbound ports, or allowlisted external IP ranges.
• Separate tool authorization from data authorization Let the MCP layer decide which actions a role can invoke, then let BigQuery or the underlying data platform enforce row, table, and column permissions independently.

Key takeaways

• A private MCP server is not automatically safe if it relies on broad credentials or unclear identity boundaries.
• The article's model shows that scoped tools, user-bound tokens, and platform-native data permissions have to work together.
• For IAM teams, the main design choice is whether MCP access preserves accountability or turns the server into a shared proxy identity.

Key terms

• MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
• Tool-level Authorization: Tool-level authorization is the practice of checking permissions on each discrete action a client asks an MCP server to perform. It matters because LLMs can generate dynamic requests, so access control must be enforced where the action is executed, not only where the request is formed.
• User-Bound Token: A user-bound token is an access token tied to a specific person's identity instead of a shared service principal. In delegated AI workflows, it preserves attribution and allows the downstream system to apply that person's own permissions instead of the privileges of the server.
• Outbound-only tunnel: An outbound-only tunnel lets a private service reach an external relay without accepting inbound internet connections. It reduces exposure by removing the public entry point, but it does not replace authorization, which still has to be enforced by identity and scope controls.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.