What infosec actually needs before agentic AI gets the green light

The blocker is the sign-off, the conversation with the infosec team and the data protection officer who want to know where data is processed, who holds the keys and what stops a developer pointing an agent at production with permissions switched off. The following contains some guidelines on how to get started safely.

Decide where your data is processed

Data residency is usually the first question and the answers differ across platforms. The first-party APIs are the simplest to reason about but the most limited. Anthropic's direct API currently pins inference to the US or a global pool through the inference_geo parameter with data at rest in the US only and EU residency on the roadmap. OpenAI's direct API access follows a similar pattern. If EU processing is a hard requirement, the direct APIs are not yet the route.

The hyperscalers are where it gets practical. Every model is reachable through a global endpoint but no major cloud platform makes every model available locally in every region for inference. Where they differ is which models they pin to which regions and how much capacity you have access to.

AWS Bedrock has the strongest regional story with the highest usage limits and the broadest choice of models offered by region. A selection of Claude, Amazon Nova, Mistral and others are available regionally so you can usually find a region that satisfies both your model choice and your residency needs. Inference profiles then load balance requests across regions within a geography for greater throughput and automatic failover all while keeping every request inside its geographic boundary. The EU profile spreads traffic across Frankfurt, Ireland, Paris, Stockholm and the others with equivalent profiles for the US, APAC and a globally load-balanced pool.

Google Vertex takes the same regional approach serving Claude through regional and eu multi-region endpoints that keep inference within the chosen geography at a 10% premium over the global endpoint.

Azure Foundry organises deployments by data zone instead so a DataZone deployment keeps processing within a US or EU zone rather than pinning it to one region though that mainly only applied to OpenAI models. One other important thing to note, Microsoft's data-privacy documentation is explicit that Claude models are hosted by Anthropic and they act as the data processor. This is something we commonly see organisations not realising until it is too late.

Use off-the-shelf tools with third-party inference

Taking control of where data is processed doesn’t mean sacrificing on the tools you can make available to your team or building a custom solution. Most coding agents and Coworking tools are designed to be decoupled from their default hosted API and pointed at a backend/model you control, usually through a handful of environment variables or a config file.

The Claude ecosystem is the most complete example. Claude Code, both the CLI and the desktop app, runs against Bedrock, Vertex or Foundry directly. Claude Cowork routes through Bedrock in its third-party mode. The Claude for Excel, Word, PowerPoint and Outlook add-ins work with the same backends and no consumer Claude account at all. For Bedrock and Vertex this keeps prompts and responses inside your existing security boundary rather than transiting a vendor's infrastructure - Foundry, as the previous section noted, is the exception.

It is not a Claude-only pattern. The open-source OpenCode agent is provider-agnostic by design and will talk to Bedrock, Vertex, an Azure endpoint or any OpenAI-compatible gateway you put in front of it. GitHub Copilot supports bring-your-own-key, letting an enterprise point it at its own Anthropic, Google or Azure OpenAI account rather than GitHub's and OpenAI's Codex can be aimed at an Azure OpenAI deployment in the same way.

Manage device settings

Once you centralise access to models and tooling, the next logical step is around how you control endpoints to ensure that data is not leaving your perimeter. There are two main ways to do this.

The first is server-managed settings, delivered from Anthropic at sign-in and configured centrally in the Claude  admin console. They need no device management, which makes them quick to roll out and a good fit for smaller teams. The catch is that they are a client-side control, weaker on an unmanaged laptop and bypassed the moment a client points at a third-party provider. Setting CLAUDE_CODE_USE_BEDROCK or CLAUDE_CODE_USE_VERTEX, the very move that gives you EU residency, also switches off the server-delivered policy and BYOK deployments lose it entirely.

The second is endpoint-managed settings pushed to the device through MDM as macOS managed preferences, a Windows registry policy or a system managed-settings.json file. Because they live in an OS-protected location they survive a determined user and they apply no matter which model provider the agent is talking to. That provider-independence is exactly what closes the gap the first approach leaves open so for any organisation with an MDM endpoint-managed settings are the way to go.

With MDM in place a short list of policies covers most of the risk. Disable bypass mode so --dangerously-skip-permissions simply cannot run. Deny reads of secrets such as .env files and credential stores. Set allowManagedPermissionRulesOnly so users cannot widen their own permissions. Replace the free-for-all of MCP servers with an allowlist through allowedMcpServers and deniedMcpServers so the agent connects only to the servers your infosec team have vetted.

This is not a Claude-only concern. GitHub Copilot and OpenAI's Codex draw the same line between central admin configuration and device-enforced policy so the rule of thumb carries across whichever harness you standardise on.

Front everything with a gateway

Device policy still leaves one thing scattered across the fleet...credentials. You can distribute and rotate provider keys through MDM with an apiKeyHelper script on a short TTL which at least makes rotation an IT task rather than a developer one, but the cleaner answer is to put an LLM gateway such as LiteLLM in front of everything. The key still exists but it lives on the gateway rather than the laptop. Each device carries only a short-lived per-user token while the gateway holds the real provider credential and injects it on the way through.

That single chokepoint earns its keep well beyond credentials. Every request now flows through one point you control, which is where centralised usage tracking, per-team budgets and audit logging come for free, and it is the natural place to enforce a model and provider allowlist. Because it speaks to Bedrock, Vertex and Foundry through one interface, it is also the on-ramp to routing later, where swapping a cheap model for a capable one per task becomes a configuration change rather than a fleet-wide rollout.

Putting it all together

Safe adoption comes down to three threads that reinforce one another. Data residency settles where inference runs, keeping prompts and code in the right jurisdiction. Governance, delivered through endpoint-managed policy, sets the guardrails once at the device where a user cannot bypass them. And your wider security posture tightens once a gateway becomes the single point through which every request, key and budget flows. Get those things right then you can create a safe environment for innovation.