Securing BigQuery MCP servers requires identity, not just tools

At a glance

What this is: This is a practitioner walkthrough of securing a BigQuery MCP server, with the key finding that tool catalogs are the easy part and identity, scope, and network isolation are the real control surface.

Why it matters: It matters because IAM, NHI, and autonomous-system teams need to govern who or what can invoke tools, what data each call can reach, and how hosted agents reach private infrastructure without broadening exposure.

By the numbers:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes , and as quickly as 9 minutes in some cases.

👉 Read Descope's post on securing a BigQuery MCP server with MCP tunnels

Context

MCP security is not just about exposing a tool to an agent. The primary governance question is which identity is allowed to invoke which tool, what data that tool can reach, and whether the server is reachable without opening the network more broadly than necessary.

The Descope example shows the common failure point in modern agent tooling: teams focus on the tool layer and under-design the identity layer. For IAM and NHI programmes, that means treating MCP servers as governed access paths rather than as simple integrations.

Key questions

Q: How should security teams govern MCP tools that can reach sensitive data?

A: Treat each tool as its own authorization boundary and enforce scope at the point of dispatch. The model may choose the tool, but the server must confirm that the authenticated identity is allowed to use that exact function before any data operation begins. That keeps the agent from inheriting blanket access through a single server token.

Q: Why do shared service credentials create more risk in agent-assisted workflows?

A: Shared credentials collapse accountability and privilege into one hidden identity, which makes it hard to know who accessed what and impossible to limit access per person. In agent-assisted workflows, that also turns the agent into a proxy for broad standing privilege. Per-user delegation keeps downstream controls intact and makes access review meaningful.

Q: What breaks when MCP servers are exposed with inbound network access?

A: Exposing an MCP server with inbound access expands the attack surface beyond the actual need to serve a private tool. Once a public hostname or allowlist becomes part of the design, the server has to be defended like any internet-facing service. An outbound-only tunnel avoids that exposure while still allowing hosted agents to connect.

Q: Who should own authorization when an AI agent queries internal data on behalf of a user?

A: The identity system should own who may request the tool, while the data platform should own what that user can see inside the dataset. Splitting those responsibilities prevents the agent layer from becoming a substitute security boundary. The safest pattern is delegated access with preserved downstream enforcement and full auditability.

Technical breakdown

Why MCP authorization fails when the tool boundary is over-trusted

MCP authorization can look correct while still leaving the wrong control point in charge. If a server only checks that a token exists, but not which tool the token can invoke, the model can still reach operations that should have been isolated. The stronger pattern is to bind scopes to individual tools and enforce them at dispatch time, so the authorization decision is made before any backend query or action runs. That keeps the agent from inheriting broad server-wide power just because it reached the front door.

Practical implication: map access to tool-level scopes, not to a blanket server token.

Why per-user OAuth beats a shared service credential for MCP

A shared service account collapses identity, accountability, and blast radius into one credential. In this design, the server acts on behalf of the person, not as a privileged intermediary with its own standing access. BigQuery then applies the person’s own permissions, which preserves row, column, and table controls without recreating them in the MCP layer. That separation matters because it keeps the agent from becoming a hidden super-user and makes the access decision traceable to an individual identity.

Practical implication: use per-user tokens and preserve downstream authorization in the data platform.

How outbound-only MCP tunnels change the network trust model

An outbound-only tunnel changes the question from how to allow inbound access safely to how to expose nothing inbound at all. The server stays private, there is no public hostname, and the connection is initiated from inside the network to an external edge. For hosted agents, that is a cleaner fit than opening firewall ports or chasing allowlist changes. The real architectural shift is that the agent reaches the private service through a controlled relay, while the service remains unreachable except through the tunnel path.

Practical implication: prefer outbound-only relay patterns when hosted agents need access to internal services.

NHI Mgmt Group analysis

Tool catalogs are not the control plane for MCP. The article shows that the real security boundary is identity and scope, not the set of tools exposed to the model. When a server is allowed to answer too many questions with one credential, the tool layer becomes a convenience wrapper over standing privilege. The practitioner conclusion is that MCP governance has to start with who can invoke what, not with how many tools are available.

Per-user delegation is the only defensible way to preserve accountability in agent-assisted workflows. A shared service credential hides who actually caused the query, while user-bound OAuth keeps the identity chain intact from sign-in to downstream data access. That aligns with OWASP-NHI and NIST-CSF access control principles because the agent is acting as a proxy, not as a separate privileged subject. The implication is that auditability and least privilege must survive the handoff from human to model to backend.

Outbound-only tunnels reduce exposure, but they do not solve authorisation by themselves. The tunnel controls reachability, not entitlement, so it narrows the network path without changing who is allowed to use the tool. That is the right split of responsibilities: network isolation limits access surface, while scoped authorization limits action surface. Practitioners should treat transport privacy and identity authorization as two separate controls, not one substitute for the other.

Identity boundaries in agentic infrastructure should be designed around the data plane, not the orchestration plane. The article’s strongest lesson is that BigQuery, OAuth, scopes, and tunnelling each enforce a different part of the chain. When teams centralise agent access without preserving those separations, they create a control model that looks unified but behaves like a shared privilege bucket. The practitioner takeaway is to keep each control anchored to the system that can actually enforce it.

Named concept: MCP tool-bound scope isolation. This is the pattern where each tool has its own authorization scope and each backend call is checked at dispatch before execution. It matters because the agent can discover and choose tools dynamically, but it should never inherit broad server access from that choice. The implication is that MCP deployments need tool-granular authorization as a first-class governance pattern, not a configuration detail.

From our research:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.
• The same research says 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
• For a broader control baseline, see the Ultimate Guide to NHIs for lifecycle and access governance patterns that help define tool-level boundaries before agents are connected to sensitive systems.

What this signals

Tool-bound scope isolation: MCP deployments will keep failing if teams treat authorization as a wrapper around the server instead of a control at each tool boundary. The practical shift is toward per-action scopes, downstream user delegation, and a clean separation between network reachability and entitlement.

The reader should expect hosted-agent patterns to push more identity logic into the control plane, not less. That means stronger alignment between IAM, NHI, and data-platform permissions, plus a governance model that can prove who asked, what ran, and which backend credentials were used.

With 80% of organisations reporting AI agents acting outside intended scope in SailPoint's research, the operational signal is clear: agent governance is moving from experimentation to baseline control design. Teams that do not define tool scopes now will inherit their own ambiguity later.

For practitioners

• Bind scopes to individual MCP tools Create one scope per action, then enforce that scope at dispatch before the backend call runs. Avoid server-wide tokens that can reach every tool just because the session is authenticated.
• Preserve per-user downstream authorization Use user-bound OAuth or equivalent delegated access so the data platform applies the person’s own table, row, and column permissions. Do not replace that with a shared service identity for convenience.
• Keep hosted agent access outbound-only Run private MCP servers behind an outbound tunnel or relay so there are no inbound ports or public hostnames to harden. Separate network reachability from entitlement decisions.
• Audit the delegation chain end to end Trace every MCP call from the human identity to the model, the tool scope, and the backend token used for the query. If any step hides a shared credential, the accountability chain is broken.

Key takeaways

• MCP security is an identity problem first, because tool access without scoped authorization turns the server into a standing-privilege gateway.
• Per-user delegated access and downstream platform enforcement preserve accountability far better than shared service credentials in agent-assisted workflows.
• Outbound-only tunnels narrow exposure, but they must be paired with tool-level scopes and auditability to be effective.

Key terms

• Mcp tool scope: A tool scope is the authorization label that limits which specific MCP function a signed-in identity may invoke. In practice, it prevents a valid session from becoming blanket access to every backend operation and keeps the security decision tied to the exact action requested.
• Delegated user access: Delegated user access means the server acts on behalf of an individual identity instead of relying on a shared service credential. This preserves accountability and lets downstream systems enforce the person's own permissions, rather than inheriting a broad, hidden privilege set.
• 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.

What's in the full article

Descope's full blog post covers the operational detail this post intentionally leaves for the source:

• The exact MCP auth handshake used to register Claude as a client and issue server-bound tokens.
• The tunnel setup steps involving cloudflared, CA generation, and Docker network configuration.
• The BigQuery connection pattern for vaulting per-user tokens and letting downstream IAM enforce data visibility.
• The internal wiring for mapping workforce groups to tool scopes and write access exceptions.

👉 Descope's full post covers the auth flow, tunnel mechanics, and scope mapping in implementation detail.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.