A practical look at what "UK data residency" actually means when you wire Claude into an enterprise stack, and the controls that matter more than the region string.
Most teams treat data residency as a dropdown. Pick the region closest to your legal entity, screenshot it for the compliance folder, move on. With Claude that approach breaks quickly, because the region you call from and the region inference runs in are two different things, and the API will happily tell you so if you ask it.
This piece walks through where the data actually goes, what you can lock down, and why the residency question is the smaller half of the problem.
The first-party API has no UK option
Anthropic's own API exposes an inference_geo parameter on POST /v1/messages. It takes exactly two values: global, which is the default and routes anywhere, and us, which pins inference to US infrastructure. There is no uk and no eu. Workspace geography is currently limited to us as well, and it cannot be changed after the workspace is created.
Pinning to us is also not free. Per Anthropic's data residency documentation, US-only inference costs 1.1x the standard rate across input, output, cache writes, and cache reads on Claude 4.6 and later. Older models reject the parameter with a 400.
So if your requirement is "processed in the UK," the first-party API does not get you there. You end up on a cloud route, and that is where the interesting failure mode lives.
Bedrock in London does not mean inference in London
Amazon Bedrock exposes a London region, eu-west-2, and that is usually the box people tick. But Claude models on Bedrock are served through inference profiles, and profiles are cross-region by design.
Check the Opus 5 model card and the pattern is clear. For bedrock-runtime, eu-west-2 does not support in-region inference at all. It supports Geo and Global profiles. Call eu.anthropic.claude-opus-5 from London and your request can land in Frankfurt, Stockholm, Milan, Madrid, Dublin, or Paris, as well as London. The EU profile is an EU boundary, not a UK one.
You do not have to take anyone's word for it. Ask the control plane:
import boto3
client = boto3.client("bedrock", region_name="eu-west-2")
profile = client.get_inference_profile(
inferenceProfileIdentifier="eu.anthropic.claude-opus-5"
)
print(profile)
Run that from your actual source region, because the routing set depends on where you call from. Do it per model, not once, because support levels differ model by model and change over time. A deployment that was EU-bounded last quarter is worth rechecking.
If your legal position genuinely requires UK-only processing, the honest answer today is that most managed routes give you a regional boundary rather than a national one. Write that into the DPIA instead of papering over it. The original NeuralTrust breakdown of Claude routes for UK buyers goes deeper on the per-platform differences, including Microsoft Foundry and Vertex.
Residency is the easy half
Here is the uncomfortable part. Even if you solved residency perfectly, you would have solved the problem of where bytes sit at rest and in transit. You would not have touched the problem of what the agent does with them.
An agent with a browsing tool, a shell, and three MCP servers can exfiltrate data without a single packet leaving your chosen region in a way your network logs would flag. Prompt injection is the delivery mechanism. A poisoned web page, a crafted issue comment, a document in a shared drive, and suddenly the model is following instructions that did not come from you, using credentials that did.
OWASP's agentic risk list puts this front and centre with goal hijack, tool misuse, and identity and privilege abuse as the top three entries. If you want the full breakdown of the ten categories and how they map to real architectures, the OWASP Top 10 for Agentic Applications walkthrough covers it.
Two practical notes for anyone deploying Claude Code or similar coding agents:
Deny rules are not a security boundary on their own. Blocking one tool does not block a second path to the same capability. If you deny a network fetch tool but leave shell access open, curl is still there. Model your permitted action set by effect, not by tool name.
MCP servers are supply chain. Each one is third-party code running with your agent's context and credentials. Allowlist them explicitly and treat an unreviewed server the same way you would treat an unreviewed npm dependency with filesystem access.
For a broader view of how these agent-layer risks are being catalogued across the industry, agentsecurity.com is a useful reference point.
What the UK regulator actually asks for
The NCSC published Managing the cyber risk of agentic AI on 20 August 2026. It is interim guidance, not a standard, and it is short enough to read in one sitting. Seven considerations, and none of them are about regions:
- Identify what could go wrong, with explicit red lines and threat modelling before deployment
- Prompt carefully, using prompts alongside technical controls rather than instead of them
- Set the right level of oversight, choosing between human-in-the-loop, on-the-loop, and out-of-the-loop
- Control the agent's environment with a robust sandbox, denying network traffic by default
- Log, audit, and monitor agent activity as part of security operations, with tamper-resistant logs
- Make your AI activity easy to attribute, for example through identifying HTTP headers
- Maintain the ability to pull the plug, including cutting the link to model inference
Point 4 is the one most teams skip, and point 7 is the one most teams discover they do not have at 2am. Our read on applying the NCSC guidance in enterprise environments expands on the sandboxing maturity levels.
Where to put your effort
If you are building the plan this quarter, the ordering that tends to hold up is this. Verify your actual inference routing with a tool call rather than a product page. Document the residency boundary you genuinely have, not the one you wanted. Then spend the rest of your budget on the agent layer, because that is where the exploitable surface is.
Concretely, that means a single choke point for model and tool traffic so policy is enforced in one place rather than scattered across application code, inline inspection of prompts and responses, and adversarial testing before rollout rather than after an incident. A gateway in front of model and tool calls gives you the enforcement point and the audit trail the NCSC guidance asks for, which is awkward to retrofit once a dozen services are calling providers directly.
The region string is a one-line config change. The controls around what the agent is allowed to do are the actual engineering work.