Claude Code: Where It Actually Runs
· 10 min read

Claude Code: Where It Actually Runs

By Orestes Garcia


Your procurement team’s first instinct is reasonable. You’re already on Azure. You have MACC commitments. You have Entra ID managing everything that matters. Running Claude Code through Azure AI Foundry sounds like the obvious path — one throat to choke, one invoice line, one identity plane you already operate.

Here’s the thing worth knowing before that decision gets made: Claude doesn’t actually run on Azure.

Anthropic’s infrastructure processes every prompt you send through Foundry. Azure is the billing wrapper and the access control layer. That distinction doesn’t change the developer experience — the CLI works, the completions come back, the code gets written. But it changes what you actually control, what gets logged, and what your contract surface looks like. If you’re running a regulated environment and the assumption is that “Azure” means “inside our compliance boundary,” you’re starting from the wrong place.

What Foundry Actually Is

Claude Code on Azure AI Foundry is a two-level deployment hierarchy. You provision a Foundry Resource — that’s your billing envelope, your authentication configuration, and your Azure RBAC scope. Inside that, you provision individual Claude Deployments, one per model version you want to use (Opus 4.6, Sonnet 4.6, Haiku 4.5 are all available). The integration into Claude Code is a single environment variable:

CLAUDE_CODE_USE_FOUNDRY=1

That’s it. Everything else — prompt routing, inference, response generation — happens on Anthropic’s infrastructure. Azure touches the request on the way in and the response on the way out. The middle is not Azure.

Authentication options:

API key — Stateless, simple, suitable for local dev or CI pipelines where a service principal is overkill. Works the same as direct Anthropic access.

Azure Entra ID — The enterprise path. Full RBAC integration. Assign the Azure AI User or Cognitive Services User role. Your developers authenticate through your existing identity plane. This is the option that actually connects Foundry to your Azure governance posture.

Managed Identity via DefaultAzureCredential — For workloads running inside Azure (Azure DevOps agents, Azure Functions, AKS pods). No credentials to manage, no rotation, picks up identity from the execution context automatically.

Network-side, you get what Azure gives you: VNet integration, private endpoints, NSG controls. If your org requires that no traffic cross the public internet, you can route Claude Code requests through private connectivity. The request still lands on Anthropic’s infrastructure eventually, but your network posture stays clean.

Billing routes through Azure Marketplace at standard Anthropic token pricing — no premium for the Foundry wrapper. If you have Microsoft Azure Consumption Commitment (MACC) agreements, Foundry usage is MACC-eligible, which matters if you have committed Azure spend that needs somewhere to go.

What breaks. Three APIs are unavailable through Foundry: the Admin API (/v1/organizations/*), the Models API (/v1/models), and the Message Batch API (/v1/messages/batches). If your tooling depends on any of these — particularly batch processing or programmatic org management — Foundry isn’t the right path.

Model pinning is required. You cannot use model aliases like claude-sonnet-4-6 — you must pin exact version identifiers and update your deployment manually when Anthropic releases new versions. No auto-upgrade. In an enterprise environment this is probably a feature, not a bug, but it adds maintenance overhead.

Regional availability: East US 2 and Sweden Central. Those are the two options. EU data residency is listed as coming in 2026 with no confirmed timeline.

The Logging Gap

This is where the architectural reality starts to matter in practice.

Foundry gives you Azure Monitor and Log Analytics — latency metrics, error rates, token counts, request volumes. The infrastructure telemetry you’d expect from any Azure service. What it does not give you is a record of what your developers sent or what Claude returned. Microsoft’s documentation is clear on this: Anthropic is the data processor for prompt and response content. Azure handles billing and usage metadata.

Zero Data Retention is explicitly excluded from Foundry deployments. Anthropic’s ZDR documentation states directly: if you have a ZDR agreement with Anthropic, it does not extend to Foundry usage. The data handling is governed by Anthropic’s standard commercial terms, not your enterprise agreement with Microsoft.

For organizations where this matters — and the compliance tax is real in banking, healthcare, and government — the gap between “infrastructure logs” and “developer session logs” is not academic. You know who used the API. You don’t know what they asked or what came back.

Enterprise’s Full Stack

Anthropic’s Enterprise plan is a different product surface entirely, not just a governance wrapper over the same API.

Identity and provisioning. SSO/SAML integration with Azure Entra ID (and other providers). SCIM for automated developer provisioning and deprovisioning — when someone leaves your org, their Claude access terminates through the same identity lifecycle as everything else. Role-based permissions within the Claude organization.

Audit trail. The Compliance API gives you programmatic access to audit logs covering developer actions, model interactions, and session events — 180 days of retention by default. This is developer-level visibility: who, when, what model, exportable for your SIEM.

Zero Data Retention. Available via negotiated addendum. When ZDR is active, request and response data isn’t stored after the API call returns (with narrow exceptions for safety classification). The data protection lives in the same contract as the tool access.

Spend controls. Configurable limits at the organization level and per individual user. You can cap how much any single developer can spend in a month, which matters when you’re rolling Claude Code across engineering teams at scale.

Cowork. This is the feature that changes how teams actually use Claude — not just as individual coding assistants, but as shared infrastructure. Cowork lets your team create shared Claude projects with persistent context: the same codebase understanding, the same project history, the same institutional context available to every member. A senior architect sets up a project with your API standards, your security requirements, your deployment conventions — and every developer on the team inherits that context automatically. It’s Claude as team memory, not Claude as personal assistant.

Claude Desktop. Native macOS and Windows application with full model access — not just the web client. For developers who live outside the terminal and want Claude integrated into their desktop workflow, Desktop provides a richer environment than a browser tab. Claude Code CLI, claude.ai web, and Claude Desktop are all covered under a single Enterprise contract.

Data residency options. If your regulatory requirements demand that data processing happen within specific geographic boundaries, Enterprise can route through AWS Bedrock or Google Vertex AI deployments — both of which offer actual regional data residency with EU options that exist today, not “Coming 2026.” That gives you better geographic coverage than Foundry’s current two-region constraint, which is an irony worth noting for Azure shops specifically.

The floor is 50 seats. If you’re running a small team, that’s the only real barrier.

Azure AI Foundry vs Anthropic Enterprise — architectural comparison showing where Claude actually runs and what each path controls

When Foundry Is the Right Call

Foundry has a legitimate use case. It’s not a bad product — it’s a specific product.

MACC commitments. If you have Azure Consumption Commitment agreements burning, and you need to route spend through Azure Marketplace to meet them, Foundry is the pragmatic choice. The economics of hitting your committed Azure spend can outweigh the product surface differences.

Internal development and sandbox environments. Teams doing exploratory work, prototyping, building internal tooling — environments where developer session logging is not a primary requirement and where billing consolidation into Azure makes operational sense. One env var to flip. No procurement motion beyond your existing Azure subscription.

Azure DevOps-native pipelines. If your CI/CD lives in Azure DevOps and you want AI assistance integrated into that pipeline using Managed Identity, Foundry’s DefaultAzureCredential support makes the integration clean. No API key management, no rotation, identity flows from the execution context.

This is the Foundry fit: non-sensitive development work, Azure-native teams, MACC-driven spend requirements. It’s a good fit for those cases.

The Architect’s Read

I’ve been running Claude Code in an Azure-heavy environment for the better part of a year. The instinct to route through Foundry is understandable — Azure already owns identity, networking, and billing for everything else. Consistency has real operational value.

But the technical reality is that Claude Code’s enterprise value comes from depth: the audit trail of what your developers built, the governance over how the tool gets used at scale, the shared context infrastructure that Cowork provides. Foundry doesn’t surface those controls. Azure can’t surface them — they live in Anthropic’s layer, not the billing wrapper.

Running Claude through Foundry gives you Entra ID as the front door. Enterprise gives you SSO, SCIM, audit logs, ZDR, spend limits, Cowork, Desktop, and a data residency story that’s actually available today. The contract surface collapses to one vendor. Your compliance team talks to one DPA, not two.

The 50-seat minimum is the only real ask. If your engineering organization is above that threshold, the product surface comparison is not close.

Running Claude through Azure is not the same as running Claude on Azure. For an architect deciding how to deploy this across a production engineering organization, that sentence is the whole answer.

Sources

Claude Code on Microsoft Foundry · Claude in Microsoft Foundry — API Docs · Configure Claude Code for Microsoft Foundry — Microsoft Learn · Data, privacy and security for Claude in Foundry · Claude Code + Microsoft Foundry — Azure Blog · Claude Code for Enterprise · What is the Enterprise plan? · Audit logs — Claude Help · Zero Data Retention — Anthropic Privacy Center · Claude in Microsoft Foundry — Anthropic


If you’re still evaluating whether Claude Code belongs in your enterprise stack at all, the comparison with Copilot CLI covers that ground. And if the compliance overhead of AI tooling in regulated environments feels like a dead end, the compliance tax post puts a number on what you’re actually dealing with.

Find me on X or LinkedIn. I write about what happens when AI infrastructure meets regulated reality.