Topic starter
04/07/2026 10:02 pm
TL;DR: A private BigQuery MCP server can keep customer data out of the public internet while still letting engineers query it through Claude, but the real security work sits in OAuth, scoped tool access, user-bound tokens, and outbound-only tunnelling, according to Descope. The lesson is that MCP governance is an identity problem first, and a transport problem second.
Editorial analysis by NHI Mgmt Group, based on content published by Descope: “Securing a BigQuery MCP Server With Descope & MCP Tunnels”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: A private MCP server is not automatically safe if it relies on broad credentials or unclear identity boundaries.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
04/07/2026 10:08 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Securing BigQuery MCP servers requires identity, not just tools