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.
Where MCP authorization should stop and BigQuery authorization should begin
The clean split is architectural, not cosmetic. The MCP layer should decide whether a client or agent is allowed to invoke a tool and with what scope, while BigQuery should enforce what data is visible once that tool is called. That separation keeps the server from becoming a second policy engine and prevents duplicate row, column, and dataset rules from drifting apart.
This is why the MCP server should validate the token, audience, and scope, then pass a narrowly defined request to the warehouse. If the server starts reconstructing warehouse visibility rules itself, teams usually end up with two partially overlapping authorization systems and no clear source of truth for data access.
In practice, the boundary works best when the MCP layer treats authorization as MCP security for tool entry, not for dataset entitlement. The warehouse then remains the place where row-level security, column masking, and dataset permissions are actually enforced.
How this split reduces policy drift and overreach
The main advantage is consistency. Tool invocation policy and data visibility policy change for different reasons, at different speeds, and often by different owners. Keeping them separate avoids the common failure mode where a server-side allowlist is updated for one workflow but accidentally broadens access across other queries or agents.
It also limits blast radius. If the MCP layer only authorizes the action, it does not need privileged knowledge of every table, field, or classification rule in the warehouse. That makes the server thinner, easier to review, and less likely to accumulate shadow logic that silently overrides the warehouse policy.
For teams formalising the control model, authorization models are most useful when they are applied at the right layer: the tool boundary for action entitlement, and the data platform for content entitlement.
When the data side needs finer-grained enforcement, the warehouse remains the authoritative policy point. That is especially important where a single tool can reach many datasets, because duplicating entitlement checks inside the server tends to age badly as schemas, roles, and business rules evolve.
What teams should verify at the boundary
The practical question is not whether both layers can authorize, but whether each layer is doing one job well. The MCP layer should confirm identity, scope, and allowed tool use. BigQuery should confirm dataset, table, row, and column access from the authenticated caller or delegated identity that actually reaches it.
That is why teams should be explicit about token handling. If the server merely forwards a user or workload token, it must preserve the original identity context in a way the warehouse can trust. If the server exchanges credentials or acts as a broker, then the trust contract needs to be documented so the warehouse is still able to apply the right visibility rules.
This is also where delegated access patterns matter. The right design usually keeps the tool server from impersonating broader warehouse privileges than it needs, while still allowing the warehouse to make the final data decision. A useful reference point is the MCP authorization specification, which frames the server as an OAuth resource server rather than a place to embed data-policy logic.
Risk and Threat Considerations
When authorization is split poorly, the biggest risk is silent privilege expansion. A server-side check that is meant to simplify implementation can accidentally become the de facto data policy, especially if it trusts coarse scopes, broad roles, or static mappings that no longer reflect warehouse entitlements.
Failure mechanism: The MCP layer authorizes the tool call, but the warehouse no longer sees enough of the original access context to enforce row and column restrictions correctly, or the server applies its own partial visibility rules that drift from warehouse policy.
Impact: Users or agents can receive more data than intended, sensitive fields can leak across tool boundaries, and revocation becomes unreliable because fixing one layer does not necessarily fix the other.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack surface, NIST SP 800-53 Rev 5 sets the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | MCP should gate tool actions separately from data access. |
| Recommendation — Enforce distinct action checks before any tool call reaches the data layer. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Non-Organizational Users) | The server must validate the caller before delegating access to BigQuery. |
| AC-6 — Least Privilege | Separating MCP and BigQuery limits server privilege and reduces overreach. | |
| Recommendation — Authenticate the caller and bind the request to the correct identity before delegation. Scope the MCP server to tool invocation only and keep data entitlements in BigQuery. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The split depends on defined access rules at the tool and data layers. |
| Recommendation — Define and enforce access control responsibilities at both the service and warehouse boundary. | ||
Practitioner Guidance
What to prioritise: Make BigQuery the authoritative place for data visibility and treat the MCP layer as an action gate only. If a rule changes because of the dataset, field sensitivity, or tenant boundary, it belongs in the warehouse.
What to verify: Confirm that the MCP server can authenticate the caller, validate scope, and pass a request that BigQuery can still evaluate against the correct effective identity. Test the design with one denied row-level case and one denied column-level case before trusting it in production.
Common mistake: Teams often copy warehouse logic into the server “for convenience,” then forget to keep the two policies aligned. That shortcut usually creates false confidence, not better control.
Practitioner takeaway: Split action authorization from data authorization so the server decides what the tool may do, and the warehouse decides what the caller may see.
Related resources from NHI Mgmt Group
- How should teams decide between a general policy engine and a purpose-built authorization layer?
- Who is accountable when authorization logic is split between the application and the data layer?
- What is the difference between IAM controls and MCP-layer governance for AI access to BigQuery?
- What is the difference between OAuth-based MCP authorization and policy-driven authorization with a gateway layer?