Agentic AI has quietly broken a lot of assumptions that data governance teams spent the last decade building. When an application was a monolith talking to a regional database, "data residency" meant picking the right Cloud SQL instance and locking down an Organization Policy. When that application becomes an agent with a tool-calling loop — pulling a document from Google Drive, hitting a CRM connector, invoking a code execution sandbox, calling out to a partner API every one of those tool calls is a new data egress path, and potentially a new jurisdiction.
The Model Context Protocol (MCP) has become the de facto way agents discover and invoke tools. That's good news for interoperability. It's a harder problem for sovereignty, because MCP servers are, by design, pluggable and location-agnostic — a tool can live anywhere, and the agent doesn't inherently know or care where "anywhere" is. If you're running a multi-region stack on Google Cloud and you have regulatory obligations (GDPR, India's DPDP Act, sector rules like HIPAA or financial services residency mandates), you can't treat MCP tool invocation as a black box. It has to be a policy-enforced boundary, the same way network egress or IAM already is.
This post walks through how to think about and build zero-trust enforcement of MCP tool policies across regions on Google Cloud, so that "which tool can this agent call, with which data, from which region" is answered by infrastructure, not by prompt instructions.
Architectural Overview
When an agent requests a tool call (e.g., querying customer records via a database MCP server), the payload passes through an inline reverse proxy on Cloud Run.
The proxy evaluates:Agent Location & Identity (from Google IAM Workload Identity / OIDC).Target MCP Server Region (where the data reside).
Payload Sensitivity (evaluated via Google Cloud Sensitive Data Protection / Cloud DLP).
Why prompt-level restrictions aren't a control
A common first instinct is to tell the model, in its system prompt, "only use the EU-hosted search tool for EU customer data." That's a UX nicety, not a security control. Prompts are not a trust boundary: they can be overridden by injected content, ambiguous context, or simply model error. If a tool call is the thing that moves regulated data across a border, the decision to allow or block that call needs to be enforced by something that isn't the model itself — a policy engine sitting between the agent and the MCP tool registry.
This is the same lesson zero-trust architecture already taught us for east-west traffic: never trust the caller's stated intent, always verify against an external policy at the point of access.
The shape of the problem in a multi-region MCP stack
A realistic deployment looks like this: an orchestration layer (say, a Vertex AI Agent Builder or a self-hosted agent runtime on GKE) fans out tool calls to a set of MCP servers — some first-party, some third-party, some internal microservices wrapped in an MCP adapter. In a multi-region Google Cloud footprint, those MCP servers might be deployed in europe-west3, asia-south1, and us-central1, fronted by regional endpoints for latency and residency reasons.
Three things need to be true simultaneously:
Data classification travels with the request. A tool call carrying EU personal data needs to carry that fact as metadata, not as something inferred later.
Tool identity and location are resolvable at call time. The policy engine needs to know not just which tool is being called, but which region that MCP server instance is actually running in — and that this hasn't been spoofed.
Policy evaluation happens before egress, not after logging. Audit logs are necessary but not sufficient; the enforcement point has to be able to deny the call.
Architecture: a policy-enforcement sidecar in front of MCP
The pattern that works well on Google Cloud is to put a lightweight policy-decision point (PDP) in front of every MCP tool registry lookup, rather than baking region logic into the agent itself.
Tag data at ingestion, not at the tool boundary. Use Sensitive Data Protection (formerly DLP) to classify inbound context — documents, chat history, retrieved records — and attach classification labels (e.g., residency: eu, pii: high) to the request object the agent carries through its reasoning loop. This is the same principle as Assured Workloads' data boundary controls, just applied to the agent's working context instead of storage.
Register MCP tools with location metadata in a central catalog. Rather than letting agents discover MCP servers via arbitrary URLs, run an internal MCP tool registry (a Cloud Run or GKE service) that records, for every registered server: its deployed region, the data categories it's certified to handle, and its VPC Service Controls perimeter membership. Treat this registry as the single source of truth — agents query it, they don't hardcode endpoints.
Enforce with VPC Service Controls perimeters per region/data class, not per project. Group MCP servers into VPC-SC perimeters that mirror your data classification tiers rather than your org chart. An EU-resident perimeter contains only MCP servers physically deployed in EU regions and approved for EU personal data; cross-perimeter calls are denied by default, and any legitimate cross-border tool call goes through an explicit bridge with its own audit trail. This gives you the "default deny" posture that zero-trust requires, enforced at the network layer where it can't be argued around by application logic.
Use IAM Conditions and Organization Policy as the last-mile gate. Even inside an allowed perimeter, use IAM Conditions on the service accounts your agent runtime assumes to restrict which MCP tool identities can be invoked based on request attributes (time, classification tag, requesting workload identity). Pair this with the resourcelocations Organization Policy constraint so that any new MCP server or supporting resource (a Cloud SQL backing store, a Cloud Storage bucket used by a tool) can't be created outside its intended region in the first place — prevention, not just detection.
Route through a policy-decision point that speaks MCP. Concretely, this can be a small Envoy or custom Cloud Run proxy sitting in the call path between your agent runtime and MCP servers, which:
Reads the classification tags on the incoming request.
Looks up the target tool's region and certification in the registry.
Evaluates a policy (OPA/Rego is a natural fit) that says, effectively: "a request tagged residency: eu may only be routed to a tool tagged region: eu with certified: [eu_pii]."
Allows, denies, or — for genuinely ambiguous cases — routes to a human-in-the-loop approval step before the call proceeds.
This is the piece that turns "the model was told to behave" into "the infrastructure cannot do otherwise."
Handling model-side ambiguity
Even with the PDP in place, there's a softer problem: what happens when the agent's own reasoning conflates data from two residency domains in a single tool call — for example, summarizing an EU customer record alongside a US one before calling an external tool? This is where classification needs to propagate at the field level, not just the request level, so the PDP can catch a call that mixes tags rather than only checking the dominant one. It's also a strong argument for keeping cross-region context merges out of tool-call payloads entirely, and instead having the agent make separate, region-scoped calls that get synthesized after the fact in a control-plane component you trust.
Observability: prove it, don't just do it
Regulators and auditors want evidence, not architecture diagrams. Two things are worth wiring up from day one:
Cloud Audit Logs on every PDP decision, including denials, exported to a region-appropriate BigQuery dataset so the audit trail itself doesn't become a residency violation.
A drift detector that periodically re-verifies the registry's claimed region metadata for each MCP server against reality (e.g., via the actual serving location of the Cloud Run/GKE workload), since a misconfigured deployment silently moving a tool to the wrong region is a more likely failure mode than a malicious one.
The trade-offs worth naming honestly
This pattern adds latency (an extra hop through the PDP) and operational surface area (a registry and a policy engine to maintain). For low-stakes, single-region deployments, it's probably overkill plain VPC-SC perimeters and IAM may be enough. It earns its cost specifically when you have (a) genuine multi-jurisdictional data, (b) third-party or dynamically-discovered MCP tools you don't fully control, and (c) regulatory obligations with real audit teeth. If your MCP tool set is small, static, and entirely first-party, a simpler static allow-list per region may get you 90% of the benefit for a fraction of the complexity.
Closing thought
MCP made tool use composable and dynamic, which is exactly what makes it powerful and exactly why it can't be trusted to self-police on sovereignty. The fix isn't a smarter prompt; it's treating "which tool, which region, which data class" as a first-class policy decision enforced at the network and IAM layer, the same way Google Cloud already asks you to treat storage residency. Get that boundary right once, in infrastructure, and every agent built on top of it inherits the guarantee for free
Top comments (0)