Deploying Claude in a UK enterprise: the three decisions that actually matter

Residency, retention, and agent permissions. Everything else is paperwork.

Here is a configuration that looks secure and is not:

{
  "permissions": {
    "deny": ["WebFetch"],
    "allow": ["Bash"]
  }
}

You have blocked Claude Code's HTTP tool. You have also left curl wide open. The agent can still reach the internet, exfiltrate a repo, or pull down a payload, because Bash is a superset of almost every other tool you tried to restrict. Deny rules are a filter on tool names, not on capability. You need the sandbox underneath them or the list is decoration.

That gap is a decent model for the whole problem of running Claude inside a UK enterprise. The hard parts are not the ones the procurement checklist asks about. They are the ones where a reasonable-looking setting does less than its name implies.

Three decisions carry most of the weight. Where inference runs, how long data sticks around, and what the agent is allowed to touch.

1. There is no UK region, and you should plan around that

Start with the fact that changes your architecture. Anthropic's first-party API supports exactly two inference geographies: global and us. No EU region. No UK region.

response = client.messages.create(
    model="claude-opus-5-5",
    max_tokens=1024,
    inference_geo="us",
    messages=[{"role": "user", "content": "..."}],
)
print(response.usage.inference_geo)  # "us"

US-only inference is billed at 1.1x the standard rate across input, output, cache writes and cache reads, on Claude 4.6 and later. Workspace geography is a separate setting, it is currently US-only, and it is fixed at workspace creation. You cannot migrate it afterwards. Decide before you click create, because the fix is a new workspace. The details are in Anthropic's data residency docs, and they move, so read them at rollout time rather than trusting a blog post from last quarter, including this one.

If your DPIA genuinely requires UK processing, the first-party API is not the route. The cloud resellers are. Amazon Bedrock exposes London as eu-west-2, Microsoft Foundry offers a US Data Zone with Europe listed as upcoming, and Google Vertex AI has its own regional story.

The trap on Bedrock is that a European geographic profile is not a UK-only profile, and in-region processing support varies per model rather than per region. A model available in London may still be routed through a geo or global profile. Check the live model card for the exact model ID you are pinning, not the region page. NeuralTrust's longer write-up on securing Claude for UK enterprise goes through each provider in more detail, with the caveat that this is the fastest-moving part of the stack.

The architectural answer, if you are running more than one model or more than one provider, is to stop making residency a per-call parameter and make it a routing policy. That is the case for putting an AI gateway in front of the whole thing, so that jurisdiction, redaction and logging are enforced in one place instead of in every service that holds an API key.

2. Retention has a long tail

API inputs and outputs are deleted on a 30 day cycle. The number people miss is the exception: content flagged by safety classifiers can be retained for substantially longer, on the order of years, for trust and safety review. For most workloads this is irrelevant. For a workload handling special category data under UK GDPR, it is a question your DPO will ask, and "30 days" is the wrong answer to give them.

Zero data retention is available, but it is not blanket. Batch processing and the Files API are among the exclusions. If your compliance story depends on ZDR, enumerate which of your code paths actually fall under it.

Enterprise audit logs run on a 180 day window and are reachable through the Compliance API. 180 days is shorter than most UK incident retention policies, which means the logs are an export source, not a system of record. Ship them to your SIEM on a schedule and alert on them there.

3. The agent is the attack surface

Everything above is about data at rest and in transit. The interesting risk is at runtime.

Prompt injection sits at number one in the OWASP Top 10 for LLM Applications, and it has stayed there because it is not a bug with a patch. It is a consequence of mixing instructions and data in one channel. The agentic extension of that list adds goal hijacking, tool misuse and privilege abuse, which are the same problem with a blast radius attached.

Model vendors publish improving numbers on injection resistance with each release, and those improvements are real. They are also not a control you own, not auditable by you, and not something you can point at during an incident review. Treat them as defence in depth under your own policy layer, never as the policy layer.

What you actually own:

• Sandboxing. Filesystem and network isolation for any agent that can execute code. This is what makes a deny list mean something.
• Least privilege per tool. Approve connectors individually with scoped permissions. An agent with read access to one repo is a different risk from an agent with a workspace-wide token.
• Distinct identity per agent. Shared service accounts make attribution impossible after the fact.
• A kill switch. Something that stops a long-running agent session immediately, tested before you need it.
• Red teaming before rollout. Injection, tool misuse and privilege escalation, against your actual tool configuration rather than a generic benchmark.

That list is not invented. It tracks closely with the NCSC's interim agentic AI guidance published in August 2026, which recommends sandboxing, unique agent identities, log capture and emergency shutdown. It is interim and non-statutory, which in practice means it is what an auditor will reach for in the absence of anything binding. NeuralTrust has a breakdown of the NCSC guidance and how to implement it if you want the control-by-control version.

For the broader threat model of autonomous agents acting through real credentials and real tools, agentsecurity.com is a useful reference point on how these failure modes are being categorised.

The UK regulatory position, briefly

There is no AI-specific statute aimed at this. The NCSC guidance is interim. The DSIT AI Cyber Security Code of Practice is voluntary. The Data (Use and Access) Act 2025 is commencing in phases and changes the rules around automated decision-making and international transfers, so check which provisions are actually in force for your use case. The ICO's code on AI and automated decision-making is still in development. The FCA and PRA are applying existing principles rather than writing new AI rules.

The practical reading is that nobody is going to hand you a compliant configuration. You are expected to derive one from existing data protection and operational resilience obligations, and to show your working.

What I would actually do

1. Pick the deployment route from the residency requirement, not the other way round. Confirm it against the live model card.
2. Run the DPIA and the transfer risk assessment before the pilot, not after it.
3. Turn on SSO, SCIM, role-based access, custom retention and IP allowlisting on day one.
4. Lock down Claude Code with managed settings, deny rules, the sandbox and an MCP allowlist. Remember that the sandbox is what makes the deny rules real.
5. Approve connectors and tools one at a time, scoped.
6. Export audit logs to your SIEM and alert on tool-use anomalies, not just auth events.
7. Red-team the configuration you are about to ship.

Model safeguards get better every release. They still do not help when an agent does exactly what it was told by text it found in a Jira ticket. The controls that matter are the ones running on your side of the API call.