Provider Selection Is Not Data Residency: What Breaks When You Conflate the Two

In a multi-provider AI stack, a provider allowlist and a geographic processing constraint look similar on paper but enforce at different points in the stack. Understanding where each control lives determines whether a governance claim holds under audit review.

By Tahir Mahmood, Co-founder & CTO, OpenBox  ·  Last updated 25 September 2026

A provider allowlist prevents a prompt from reaching an unapproved provider. A data residency requirement constrains where a prompt is processed. Governance teams often treat these as the same control. They are not, and the difference has direct consequences for how a governance policy is written, where it can act, and what it can honestly claim.

Throughout this article, “data residency” refers specifically to the geographic location at which prompts and completions are processed by the AI routing infrastructure. This is sometimes called processing-region residency. The full legal concept of data residency can encompass storage, transfer, and other handling; those broader considerations are outside the scope of this article.

This article examines why these two constraints occupy different positions in the enforcement stack, what the OpenBox integration with OpenRouter does for each, and why a governance system that acknowledges this distinction provides clearer evidence for audit review than one that does not.

Two Constraints, Two Enforcement Points

Consider what an organisation typically needs from each control:

Provider allowlisting: the prompt must reach only approved providers. This constraint can be expressed inside the API call itself, before the request is sent.

Processing-region residency: inference must remain within approved geographic regions. In the standard path described here, there is no dedicated generic region parameter in the provider object equivalent to provider.only. OpenBox (docs.openbox.ai) states this directly: “An approved-region list cannot travel in the request: OpenRouter honours provider.only but has no region parameter.”

OpenBox’s documentation on Proof of Routing makes the resulting enforcement difference explicit:

Source: OpenBox, “Proof of Routing” (docs.openbox.ai/developer-guide/openrouter/proof-of-routing.md), accessed 15 September 2026.

How Provider Allowlisting Works

OpenRouter’s standard request body includes a provider object. One field within it, provider.only, accepts a list of provider slugs the request will accept. When an OpenBox routing policy writes an allowlist into the outgoing request, the directive includes both provider.only and allow_fallbacks: false. allow_fallbacks defaults to true in OpenRouter; OpenBox explicitly sets it to false alongside provider.only, which causes OpenRouter to return an error rather than routing to a provider outside the approved list.

Enforcement happens before the prompt is sent. If the only approved provider is unavailable, OpenRouter returns an error rather than routing elsewhere. No prompt leaves the process toward an unapproved destination, because the combination of provider.only and allow_fallbacks: false leaves nowhere else to go. OpenBox describes this control category as “prevented”.

A policy can also narrow the provider list rather than refusing outright. It issues a BLOCK verdict with a routing directive attached, and the SDK applies that directive to the outgoing request, pairing provider.only with allow_fallbacks: false. This narrowing can only ever reduce what the caller already named; a policy cannot route a prompt somewhere the caller did not allow.

Why Processing-Region Residency Cannot Enforce the Same Way

OpenRouter’s standard provider object has no dedicated region parameter. The fields it exposes are order, only, ignore, allow_fallbacks, zdr, and several performance and cost controls. None of these is a generic geographic-region constraint.

It is possible to achieve some geographic influence by targeting region-specific provider endpoint slugs. For example, specifying provider.only: ["google-vertex/us-east5"] pins to a particular Google Vertex region. However, this is a named-provider approach: the caller must know and name a specific provider endpoint, not express a general geographic constraint. It does not produce the same governance semantics, does not apply across all providers, and does not give a caller a single field that enforces processing location regardless of which provider serves the call.

OpenRouter does provide dedicated regional endpoints, us.openrouter.ai and eu.openrouter.ai, which route and process requests entirely within the named region and fail with a 404 rather than routing outside it. These are available on Business and Enterprise plans. OpenRouter launched EU In-Region Routing in October 2025 and US In-Region Routing on 9 September 2026. However, this is an endpoint-selection decision, not a parameter within the standard request body.

This is why OpenBox’s approved-region list is stored as policy intent rather than as a request parameter. In the standard path described in this integration, there is no request field that enforces geographic processing the way provider.only enforces provider selection.

What the OpenBox Integration Does Instead

OpenBox, an AI agent governance platform, handles processing-region residency by separating what can be acted on before a call from what can only be observed after it. Per docs.openbox.ai, an approved-region list lives in policy and is stamped on the routing record before the prompt goes out. This seals the approved list under the session’s signed root at a point where the outcome is not yet known.

After the answer returns, the SDK reads the generation record from OpenRouter’s GET /api/v1/generation?id=<gen-id> endpoint. That record includes data_region, the field name OpenRouter returns in the generation record. OpenBox maps this into the gen_ai.upstream.data_region attribute in its routing record and compares it against the policy’s openbox.residency.approved_regions list, and the result is sealed in openbox.residency.region_honored.

The four key attributes the audit trail carries for processing-region residency governance:

Source: OpenBox, “Routing Attributes“ (docs.openbox.ai/developer-guide/openrouter/routing-attributes.md), accessed 15 September 2026.

A breach seals openbox.residency.region_honored as false. A policy reading that attribute on the following call can refuse it and terminate the session via a HALT decision.

The One-Call-Late Boundary

This is the most important point to state precisely: in the standard path described here, a residency breach is not treated as though OpenBox prevented the violating call. The integration observes the region only after OpenRouter produces the generation record. The prompt already sent cannot be recalled.

The Routing Integrity panel surfaces this on screen rather than in a footnote. Per OpenBox (docs.openbox.ai), in the standard integration path, the standard provider object has no region parameter that constrains geographic processing, so a residency breach is evidence caught one call later, not a prevented event. A policy can refuse the next call and halt the session.

The governance action available after a breach is a HALT decision, which terminates the entire agent session. OpenBox enforces five governance decisions: ALLOW, CONSTRAIN, REQUIRE_APPROVAL, BLOCK, and HALT. CONSTRAIN runs the action inside a sandbox rather than stopping it outright, sitting between ALLOW and BLOCK in the decision hierarchy. HALT takes precedence over all other decisions. See docs.openbox.ai/core-concepts/governance-decisions.md for the full decision reference.

What OpenBox provides for the standard path is that it:

1. Declares and records the approved region as policy intent before the outcome is known.

2. Observes the region reported by the gateway after the call ends.

3. Determines whether the region was honoured and seals the result under the session’s cryptographic attestation.

4. Can halt subsequent session activity following a confirmed breach.

A statement that “OpenBox prevents prompts from leaving an approved region” would not be accurate for this standard path. The accurate framing is that it provides sealed, independently verifiable evidence of whether the processing-region requirement was honoured, and stops the session from continuing after a confirmed breach.

What ‘global’ Means in the Record

When a call is served through OpenRouter’s global endpoint rather than a regional one, the generation record reports data_region: global. The OpenBox docs note a specific example: a plain openai/gpt-4o-mini call can report data_region: global while being served by Azure. “global” means no regional endpoint was used.

If the approved region list is ["eu"], a call reporting global fails the comparison. That is the intended behaviour for an operator who requires EU processing: a call without a confirmed regional endpoint did not satisfy the requirement.

The docs specify that global is compared literally and is never silently treated as a match against a regional list. Approving ["global"] is the explicit way to state that any zone is acceptable. A policy approving ["global", "eu"] says something materially different from one approving only ["eu"].

Provider and Region Are Separate Dimensions

A provider can be on the approved list while the resulting processing region is not. Conversely, a call could land in an approved region while using a provider not in the allowlist. This is why a thorough routing audit requires separate dimensions:

The integration records these as distinct attributes rather than collapsing them into a single routing-compliance indicator. This matters because collapsing them would mask cases where the two constraints produce different results.

One further nuance: for calls routed via openrouter/auto, model substitution checks are not available. The openbox.model.honored attribute is absent rather than false for such calls, because the caller delegated model selection. Per the OpenBox docs, the documentation treats this three-valued result (honoured, dishonoured, or unconstrained) as intentional: a call that promised nothing and broke nothing is excluded from the honoured rate rather than counted as a pass. An unconstrained call carries no allowlist, so counting it as a success would make coverage rates meaningless.

The Wider Principle: Control Placement Follows Infrastructure Exposure

The provider/region enforcement distinction reflects a general architectural fact: a control can only act at the point where the underlying infrastructure accepts the relevant input or produces the relevant output.

Provider selection is an input the request body carries. The gateway accepts it, acts on it, and can fail closed. Geographic processing location, in the standard integration path described here, is an output of the gateway’s routing decision, produced after the call. The standard provider object has no dedicated region parameter that enforces it before execution.

Governance controls should therefore be described by their actual enforcement point. The OpenBox documentation on Proof of Routing deliberately separates two categories: “prevented” (the operation does not happen) and “evidence” (the operation happened, the event is sealed, and subsequent activity can be refused). Collapsing both into the word “enforced” obscures the difference and produces governance claims that become harder to defend under audit review.

An honest governance architecture acknowledges this classification and designs accordingly. Provider allowlists sit in the “prevented” category; processing-region residency, in the standard path described by the OpenBox integration, sits in the “evidence” category. Both have value. Neither substitutes for the other.

For organisations with strict geographic processing requirements, the appropriate structure includes both: a provider allowlist that prevents calls to unapproved providers, and a residency policy that records the approved region before each call, observes what the gateway reports, and halts the session on a confirmed breach. The first provides certainty about the provider before execution; the second provides sealed, verifiable evidence of where the provider processed the call, and stops the session from continuing when that evidence shows a violation.

The AI Agent Governance Guide for Enterprise Teams covers the broader Trust Lifecycle and how these controls sit within the Authorise phase.

Frequently Asked Questions

Does a provider allowlist also enforce data residency?

No. A provider allowlist, expressed via OpenRouter’s provider.only parameter, when paired with allow_fallbacks: false, restricts routing to the approved provider set. allow_fallbacks defaults to true in OpenRouter; OpenBox’s routing directive sets both fields together to produce fail-closed behavior. The allowlist does not constrain where the approved provider processes the call. It does not constrain where the approved provider processes the call. While region influence is possible through region-specific provider endpoint slugs, this is a named-provider approach, not a generic geographic constraint. Provider selection and processing-region residency are separate governance dimensions and require separate controls.

What does “observed” mean for processing-region residency in governance terms?

“Observed” means the geographic processing location is recorded after the fact rather than prevented beforehand. In the standard path described here, OpenBox stamps the approved region list on the routing record before the call, reads the actual region from the gateway’s generation record after the answer returns, compares the two, and seals the result under the session’s cryptographic attestation. If the region was not honoured, the next call in the session can be refused and the session halted. The prompt that produced the breach was already sent and cannot be recalled.

What happens when OpenBox detects a processing-region breach?

The breach is sealed as openbox.residency.region_honored = false in the session’s attestation. A routing policy reading that attribute on the subsequent call can issue a HALT decision, terminating the session. The Routing Integrity panel and the Run Receipt both surface the unapproved call, including the generation ID from OpenRouter so the claim can be re-checked at source independently of OpenBox.