Microsoft Foundry Is Now a Claude Code Control Plane, Not Just a Model Catalog
Microsoft’s most interesting Claude Code update this week is not a model benchmark, a slick IDE demo, or another argument about which coding assistant “feels smarter.” It is a documentation page. That sounds like faint praise until you look at what the page actually does: it turns Claude Code from a developer-installed tool into something an enterprise platform team can route through Microsoft Foundry, authenticate with Entra ID, deploy in approved Azure regions, and reason about as part of its governed AI estate.
That is a bigger shift than the headline implies. Claude Code, by Microsoft’s own description, is an agentic coding tool that can read a codebase, edit files, run commands, and integrate with development workflows. In other words, it is not autocomplete. It is a software actor with repo context and side effects. The moment a tool has that shape, the important question stops being “can it generate code?” and becomes “who controls the boundary around what it can see, what it can call, and what it is allowed to change?”
The updated Microsoft Learn guidance gives teams a concrete answer: run Claude Code through Microsoft Foundry. The prerequisites are not casual. You need a paid Azure subscription, Foundry access with Contributor permissions, a Foundry project in a supported Claude region, Contributor or Owner role on the Foundry resource group, and Azure Marketplace access for partner models. The regional note matters too: the documentation currently calls out Claude availability for this path in East US 2 and Sweden Central. That is not global “flip a switch” coverage. It is a controlled deployment surface.
Foundry is becoming the neutral zone for non-Microsoft agents
The model split Microsoft recommends is practical: claude-sonnet-4-6 as the primary coding model, claude-haiku-4-5 for quick operations and smaller edits, and optional claude-opus-4-6 for extended thinking and more complex reasoning. The broader Claude-in-Foundry docs also list newer Opus, Sonnet, Haiku, and Mythos variants, with Mythos gated for defensive cybersecurity research at Anthropic’s discretion. That catalog detail is useful, but the strategic detail is simpler: Microsoft is positioning Foundry as the place where competing model families can be made operationally acceptable.
That changes the usual “Claude Code vs. Copilot” framing. Copilot remains Microsoft’s native coding assistant across GitHub, VS Code, enterprise policy, and the developer workflow Microsoft already owns. But Foundry support means Microsoft can still win the control-plane layer even when a team chooses Anthropic’s coding experience. If developers prefer Claude Code for certain tasks, Microsoft’s answer is not necessarily to block it or pretend Copilot has no competition. The more pragmatic answer is: fine, bring it through Foundry, attach Azure identity, deploy approved models, and keep the enterprise boundary intact.
That is a good move. It is also a trap if teams mistake “routed through Foundry” for “governed.” Foundry gives you better handles; it does not write your policy. Entra ID authentication is available through the Anthropic SDK’s AnthropicFoundry client and Azure Identity token providers, while API keys remain an option. Platform teams should treat API-key fallback as a migration crutch, not the default operating model. If a coding agent can run commands and touch files, individual long-lived secrets are exactly the kind of convenience that becomes an incident report with timestamps.
The VS Code configuration shows how real this is becoming. Environment variables such as CLAUDE_CODE_USE_FOUNDRY, ANTHROPIC_FOUNDRY_RESOURCE, and optionally ANTHROPIC_FOUNDRY_API_KEY point Claude Code at the Foundry resource. Validation happens through Claude Code’s /status, where the provider should show as Microsoft Foundry with the configured resource and deployed model. This is boring setup work, which is precisely why it matters. Boring setup work is how experimental tools become sanctioned enterprise workflows.
The context files are policy, whether you admit it or not
The documentation also supports project context through CLAUDE.md, project rules under .claude/rules/*.md, and local memory through CLAUDE.local.md. Engineers will recognize these as useful ergonomics: every repo can teach the agent its conventions, test commands, architecture boundaries, and “please do not touch this” warnings. Security teams should recognize them as something else too: executable-adjacent operating instructions for an agent that can modify software.
That means context files need review discipline. If a repository’s CLAUDE.md says “run this deployment script after changes,” that is not just documentation. If local memory contains stale credentials, private operational notes, or instructions copied from someone’s debugging session, that becomes part of the agent’s working environment. Teams already learned this lesson with CI configuration: YAML looked like plumbing until it became the supply-chain control surface. Agent context files are heading the same direction.
There is also a Model Router wrinkle. Microsoft says Foundry Model Router can be used as an alternative path for some Claude Code workloads, but the version described in the docs does not currently support claude-sonnet-4-6 or claude-opus-4-6. If teams need those exact models, direct deployments are required. That distinction matters for reproducibility. A router may optimize cost and availability; a direct deployment gives you tighter control over the model actually doing the work. For coding agents, especially those touching security-sensitive code, migrations, auth flows, or public APIs, that trade-off should be explicit.
The practitioner move is straightforward: pilot this like infrastructure, not like a productivity hack. Pick one or two repositories. Require Entra ID unless there is a documented exception. Define which Claude models are approved for quick edits, normal implementation, and high-risk reasoning. Decide whether Claude Code can run in GitHub Actions, and if so, under what branch protections, review gates, and logging requirements. Review CLAUDE.md and rules files the same way you review CI workflows. Put cost alerts on the Foundry deployment. Then measure whether accepted diffs, test pass rates, and review rework actually improve.
The best read on this update is that Microsoft is no longer treating third-party coding agents as an awkward outside category. It is absorbing them into the Azure control plane. That is exactly what enterprise AI needs: not fewer tools, but fewer ungoverned boundaries. Claude Code through Foundry is useful because it acknowledges reality. Developers will use the agents that work. Platform teams need a place to make that use survivable.
Sources: Microsoft Learn, Microsoft Learn: Claude in Foundry, Claude Code docs, Microsoft Learn: Model Router