The BigQuery MCP server lets Claude, Cursor, ChatGPT, and AI agents run natural-language SQL across your BigQuery datasets. Here's the official setup, the real security risks, and how to govern it with DLP-grade redaction at the MCP layer.
.webp)
list_dataset_ids, get_table_info, and execute_sql.The BigQuery MCP server is a Model Context Protocol implementation that exposes BigQuery's query engine and metadata API as a standardized set of tools to AI agents. Once connected, an agent like Claude can enumerate datasets, read table schemas, generate SQL from plain English, execute that SQL, and summarize the rows that come back — turning your data warehouse into something an AI client can reason over directly.
Google offers two official routes, both documented at Google Cloud's BigQuery MCP guide. The fully managed remote server runs on Google's infrastructure and presents an HTTP endpoint your AI client points at; it authenticates with OAuth 2.0 over IAM and explicitly does not accept API keys. The self-hosted MCP Toolbox for Databases (the googleapis/mcp-toolbox open-source project) runs as a binary you deploy yourself, supports custom parameterized queries, and covers BigQuery alongside dozens of other data sources. Either way the core tool set is consistent: list_dataset_ids, list_table_ids, get_dataset_info, get_table_info, and execute_sql (with a read-only variant).
From the analyst's perspective, the AI agent suddenly knows the warehouse — it can answer a business question without anyone writing SQL by hand. From the security perspective, the agent now holds query access to every dataset the connecting identity can read, and the rows it pulls land directly in the model's context window.
That's the value. It's also where security teams need a control layer.
Once the BigQuery MCP server is connected, an agent works your datasets the way an analyst would — except it writes the SQL itself from a plain-English question. Bounded by the IAM identity it runs as, it can:
list_dataset_ids and get_table_info to discover what datasets and columns exist, then decide which tables to query without a human pointing the way.Every one of those actions runs through BigQuery's own job engine and IAM permissions — which is what makes it genuinely useful, and exactly why the regulated columns it can reach need an inspection layer sitting in the tool-call path.
The risks fall into four categories that every healthcare, fintech, and enterprise security team should price into the deployment.
1. One prompt can scan an entire dataset. Natural-language-to-SQL has no instinct for least privilege. "Show me our customers" can compile to a SELECT * across a table holding millions of rows of PII. The execute_sql tool runs it, and the regulated columns return raw to the agent — no WHERE not_sensitive = true clause exists.
2. IAM dataset grants are usually too broad. BigQuery access is commonly granted at the dataset or project level — Data Viewer on a whole dataset, not column by column. The connecting identity can typically read far more than any single task needs, and the MCP server faithfully serves all of it. The blast radius is the credential's entire footprint, not the question that was asked.
3. Results come back in bulk. A single execute_sql call returns thousands of rows in one response. SSNs, card numbers, clinical identifiers, and financial figures arrive as a structured payload that flows straight into the model's context window — exactly the high-volume, high-sensitivity pattern that turns one query into a reportable disclosure.
4. Schemas and metadata leak sensitive structure. Before a single row is read, get_table_info exposes column names like ssn, dob, card_pan, or diagnosis_code. Metadata tells an agent — or an attacker steering one through prompt injection — precisely where the regulated data lives and how to query it.
The traditional DLP a company already runs — at the network edge, on the file share, inside the cloud-native rule engine — does not sit in the MCP path. The query result goes straight from BigQuery into the AI agent's context window. That reach is exactly why each agent's access and queries against BigQuery must be governed: controlled (what it can reach and run), the sensitive columns it touches protected, and every call audited. That is where Strac BigQuery MCP DLP lives.
Strac's BigQuery MCP DLP is the governance layer that sits between AI agents and the BigQuery MCP server. Strac governs every tool call: it sees exactly which datasets, tables, and columns each agent reaches in BigQuery, controls what it can run (allow, block, or require approval on high-risk queries, exports, and writes), protects the sensitive columns it touches by redacting, masking, tokenizing, or vaulting them, and logs every call as audit evidence. Non-sensitive, in-policy queries flow through untouched.
What this looks like in practice:
execute_sql and the result set contains SSNs / credit cards / emails / PHI / account numbers, Strac inspects the returned rows and redacts, masks, or tokenizes the sensitive columns inline, then passes the clean result to the agent. The analysis still runs; the regulated values never enter the model context.SELECT * against a known PII table, a query that exports in bulk, or any execute_sql write can require approval or be blocked outright by policy — before it ever runs against BigQuery.get_table_info and list_dataset_ids responses are governed too, so sensitive schema and dataset structure isn't handed to the agent (or a prompt-injection attacker) by default.The same Strac MCP DLP layer covers warehouse siblings like Snowflake MCP, Databricks MCP, and Postgres MCP — one control plane across every place AI agents query your regulated data.
MCP DLP protects the AI-agent surface. Strac's native BigQuery DLP protects the data-at-rest surface — the same warehouse, but scanned continuously where the regulated data actually lives. Most enterprises run both: native DSPM-for-AI discovery to know which columns hold sensitive data, MCP DLP to govern the agent queries that read them. Together they cover every path regulated data can take in and out of BigQuery.
What Strac's native BigQuery DLP includes:
This native sensitivity map is what makes the MCP DLP layer precise: Strac already knows which BigQuery columns are regulated, so query-time redaction is surgical rather than guesswork.
For the broader integration catalog — every SaaS, cloud warehouse, browser, and endpoint surface Strac covers — see strac.io/integrations.
The screenshot below shows Strac's MCP DLP redacting sensitive data from a real Claude session — patient identifiers, customer emails, and credit card numbers tokenized inline before the model received the data. The same inspection pattern runs on every BigQuery MCP query result routed through Strac, column by column.
Setup is agentless and takes under 10 minutes.
json
"mcpServers": {
"bigquery": {
"url": "https://mcp.strac.io/bigquery",
"auth": { "type": "bearer", "token": "<your-strac-token>" }
}
}
For Cursor, Gemini, OpenAI Agents, custom agents — same endpoint, same auth.The same Strac BigQuery MCP DLP control produces evidence mapped to every major compliance framework — with HIPAA and GDPR front of mind for any warehouse holding patient or EU-resident data.
For the broader AI-data-governance program this sits inside, see the AI DLP pillar.
The BigQuery MCP server is a Model Context Protocol implementation that lets AI agents (Claude, Cursor, ChatGPT, Gemini, custom agents) run natural-language-to-SQL across your BigQuery datasets via standardized tool calls. It's how an AI client lists datasets, reads table schemas with get_table_info, executes SQL with execute_sql, and summarizes the results — over every dataset the connecting IAM identity can read.
Gemini in BigQuery is Google's built-in assistant: it runs inside the BigQuery console, helps you write and explain SQL, and keeps the data within Google's boundary. The BigQuery MCP server points the other direction — it exposes BigQuery to external agents (Claude, Cursor, ChatGPT, custom) over the open Model Context Protocol, so the AI client your team already uses can query the warehouse directly. Gemini in BigQuery keeps the query and its results inside Google's native guardrails; MCP lets any agent reach in, and the result rows leave those guardrails the moment they return to the client. That hand-off is exactly where Strac BigQuery MCP DLP inspects and redacts — column by column.
By itself, no — not without an additional DLP layer. The BigQuery MCP server honors the connecting identity's IAM permissions but returns whatever that identity can query, including PII, PHI, card numbers, and financial records, in bulk. Because IAM grants are usually dataset-wide, one natural-language prompt can scan far more regulated data than the question needed. For enterprise use with regulated data, you need an MCP-layer DLP control like Strac BigQuery MCP DLP that inspects and redacts every query result before rows reach the AI model.
BigQuery's built-in protections operate at the storage and policy layer — IAM roles, column-level security, dynamic data masking, policy tags. Those are powerful, but they're configured per identity and don't sit in the MCP tool-call path the way an inspection gateway does. Strac is purpose-built for that path: it inspects every query result before rows reach the AI agent's context window, applies redaction based on a live sensitivity map of your warehouse, and produces a per-query audit log — with detection breadth (PII / PHI / PCI / financial / secrets) that travels with the agent rather than depending on every dataset being perfectly tagged in advance.
Yes. Strac exposes a standard MCP gateway endpoint, so any MCP-aware AI client routes tool calls through it with one configuration change. No SDK changes, no application code changes.
PII (SSN, driver's license, passport, address, phone, email), PHI (clinical notes, MRN co-occurrence, ICD-10 codes adjacent to identifiers, lab values), PCI (full and partial card numbers via Luhn check), financial data (account and routing numbers, balances), credentials (API keys, GCP / AWS / Azure access keys, OAuth tokens, JWTs, private keys), and custom detectors trained on your internal data classifications. Detection runs across returned rows, column metadata, and schema responses.
Yes. Policy can require approval on, or outright block, high-risk calls — a SELECT * against a known PII table, a bulk export, or any execute_sql write — before the job ever reaches BigQuery. Lower-risk, in-policy queries flow through untouched.
Under 10 minutes for the first project. OAuth Strac into your Google Cloud project, paste the Strac MCP gateway endpoint into your AI client's config, pick a policy template, done. No agents to install, no BigQuery re-permissioning, no application code changes.
Yes. Strac produces a per-call audit log: timestamp, AI client identity, user, tool invoked, dataset and table accessed, SQL executed, data classes detected, columns redacted, vault references, disposition. The log is queryable in the Strac console and exportable to your SIEM. This is the evidence trail SOC 2, HIPAA, PCI, and GDPR auditors will ask about for AI-agent activity in BigQuery.
The BigQuery MCP server is rapidly becoming the way AI agents query enterprise data warehouses. That surface contains every category of regulated and proprietary data your organization has — and unlike a CRM, a single natural-language prompt can scan the whole dataset at once. Running BigQuery MCP in 2026 without an MCP-layer DLP control is not a question of if the first over-broad query reaches your security team; it's when.
Strac BigQuery MCP DLP gives you the governance layer, the column-level protection, the audit evidence, and the framework-agnostic compliance coverage so you can let your team query the warehouse with Claude, Cursor, Gemini, ChatGPT, and any future AI client without making each one a separate security exception.
If you are running — or about to run — BigQuery MCP in production, book a 30-minute demo. We'll walk through the architecture, the policy templates, and a deployment plan for your specific BigQuery project and AI clients.
For the broader MCP DLP control plane across every data surface, see the MCP DLP pillar. For more warehouse and SaaS deep dives: Snowflake MCP, Databricks MCP, Postgres MCP, Salesforce MCP, Slack MCP.
.avif){kind=icon}
.gif)
