Notifications
Clear all
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.
NHIMG editorial — based on content published by Descope: Securing a BigQuery MCP Server With Descope and MCP Tunnels
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes , and as quickly as 9 minutes in some cases.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Bind scopes to individual MCP tools Create one scope per action, then enforce that scope at dispatch before the backend call runs.
- 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.
- 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.
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.
👉 Read Descope's post on securing a BigQuery MCP server with MCP tunnels →
BigQuery MCP identity controls: what IAM teams need to know?
Explore further
04/07/2026 10:08 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Securing BigQuery MCP servers requires identity, not just tools
