Learn what changes for security, identity and spend when Claude runs through Microsoft Foundry, and the four decisions that matter if “inside the tenant” has to mean no first-party inference, period.
Where to start
- Security and compliance leaders: the next section, and “When the requirement is no first-party inference at all”
- IT and cloud platform teams: “Identity and credentials” and “How spend behaves”
- Developers: “1P, 3P and the surfaces you keep”
- Business sponsors: this box and “This isn't only a developer story”
The hesitation nobody says out loud
I've had some version of this conversation a dozen times now. A client is excited about coding agents, the pilot went well, developers are asking for licenses, and then somebody from security joins the call, and the temperature drops about 10 degrees.
A chat assistant sees whatever you paste into it. A coding agent sees your entire repository. The config directory, the internal hostnames, the auth middleware, the seed data that was supposed to be synthetic and mostly is, and that one file every codebase has that somebody should have deleted in 2019.
Point an agent at a monorepo and ask it to fix a failing test, and it will happily read 40 files you forgot existed to figure out why. The concern was never really the model, but the blast radius.
Then there's volume. A chat interaction is one request you thought about before sending. An agentic loop is hundreds of requests nobody reviewed individually. Whatever you'd be uneasy about a single prompt containing, an agent will eventually send, at three in the morning, from a build runner, while everyone's asleep. If your review process assumes a human decides what goes over the wire each time, agents break that assumption on day one.
Some of this isn’t a matter of preference at all. Plenty of organizations operate under obligations they didn't choose, such as residency mandates that name a geography, contractual commitments about retention and sector regulators who will eventually ask where a given inference request went. Banking, insurance and life sciences are the obvious cases, but these obligations show up in almost every regulated industry. The most animated version of this conversation was with an insurer whose security lead wanted to know exactly which claims data an agent could see while refactoring the adjudication service. This is a fair question, and I've since had the same one from a manufacturer.
None of this is a knock on hosted AI services generally; the major vendors have strong policies and real certifications. But “our policy commits us to X” and “here is the network path the bytes took, in a region you specified, under your own agreement” are different categories of assurance, and some organizations are required to produce the second kind. A policy is something you rely on. An architecture is something you can show somebody.
What running it in your own tenant buys you
As of June 2026, Claude models are generally available in Microsoft Foundry, including a hosted-on-Azure option. For a client already standardized on Azure, that changes the conversation considerably. Here's what moves inside your boundary:
- Region choice. Most Claude models on Foundry deploy globally, and several also offer a U.S. data zone option that constrains where requests are served. For a client with a residency mandate, that's the difference between an attestation and a deployment setting.
- Zero data retention, through your Azure agreement rather than a separate one. Confirm it specifically rather than assuming it, but it lands in a contract your legal team has already read.
- Network posture you already run. Private endpoints, controlled egress, the same story you apply to every other Azure service. Your agent stops being an exception to the firewall.
- Identity that's yours, through Entra ID rather than an API key. (More below; it's the piece that tends to sell itself.)
- Billing and audit where you already look. Consumption on your Azure invoice; telemetry in the same workspace as everything else.
- Guardrails you attach, not ones you inherit. Azure AI Content Safety and Foundry Agent Service guardrails are available to Claude workloads, but the filters aren't switched on for you at deployment the way they are for Microsoft's own models. Claude ships its own safeguards; you decide what Azure layers on top.
The development experience itself doesn't change much at all. Claude Code CLI behaves the way it does anywhere else, and so do the VS Code and JetBrains extensions, the Agent SDK, subagents, hooks, skills, plug-ins, MCP servers, checkpointing and sandboxing. Prompt caching and extended thinking work. What's different is the set of surfaces Anthropic operates on your behalf, covered in “1P, 3P and the surfaces you keep” below.
Identity and credentials
Of everything here, the authentication model has the widest downstream effect and gets the least attention.
Claude Code on Foundry can authenticate through the standard Azure credential chain and Entra ID instead of an API key. Build agents run on managed identity. Developers authenticate as themselves, so conditional access, privileged identity management and device compliance apply to model access the same way they apply to the rest of the tenant.
There's no long-lived credential to issue, rotate, leak or find in a repository three years from now. If you've spent the last few years killing static credentials across your estate, that's a bigger deal than the model swap.
How spend behaves
Billing moves into Azure. Foundry bills Claude through Azure Marketplace using Claude Consumption Units, converted from token usage at published per-model rates, on your consolidated invoice. Eligible Enterprise Agreement customers can draw this down against an existing Azure consumption commitment.
Microsoft Cost Management becomes your spend surface, and your existing budgets, tags and alerting carry over. Two things are worth settling early:
Cache and context discipline matter too. The prompt cache hit ratio is a real line item once agentic workloads are running, and a large context window is a capability and a spend risk at the same time.
Your two cost numbers won't match
Better to know now than in a chargeback review. The Anthropic analytics dashboard and Claude Enterprise Analytics API aren't available on Foundry. Per-developer and per-team attribution comes instead from Claude Code's OpenTelemetry export into Log Analytics, Application Insights or Databricks, and telemetry ships disabled, so turning it on is a deliberate step in your rollout.
The challenge is that the cost figure Claude Code emits is a client-side estimate against standard rates, while your invoice is consumption-unit based and may reflect negotiated pricing. They will diverge. Treat Cost Management as the actuals and telemetry as the attribution layer. Don't build a chargeback model that assumes the two reconcile. Finance always notices.
In exchange, your model telemetry lands in the same workspace as the rest of your platform signals. One retention policy, one SIEM, one place to go when someone asks for evidence.
Put something in front of it
Once inference is inside your tenant, you can also front it with an AI gateway, which is otherwise awkward to do cleanly when the model is a SaaS endpoint your tools call directly. It's one of the quieter advantages here.
Route Claude Code, your internal apps and Claude Desktop through a gateway you control before traffic reaches Foundry. Azure API Management's generative AI features are the Azure-native option. If your data platform is Databricks, registering the Foundry endpoint as an external model behind Unity Gateway (Mosaic) puts it under Unity Catalog. The permissions, lineage and audit model you already use for data now apply to model access, with every request landing in inference tables you can query like anything else to use for evaluations, training, or security. LiteLLM, Portkey and similar tools do the same job if you'd rather stay vendor-neutral.
You get one metering point regardless of which client made the call: cost by team, application, model and hour, from a source that saw every request. A gateway is also where governance stops being a document: rate limits, allow lists, PII checks and prompt logging with a retention period you set. The gateway enforces all of it at one chokepoint rather than trusting each client individually. And it's the natural home for your AI SDLC motion: evaluation harnesses, prompt versioning and regression checks before a new model version reaches production.
The trade-off is real. A gateway adds a hop, and it moves the authentication boundary. Clients authenticate to the gateway, and the gateway holds the path to Foundry, so the end-to-end Entra ID story now applies at the gateway edge instead. For most organizations, that's a fine trade. Just make it on purpose.
1P, 3P, and the surfaces you keep
Anthropic’s and Microsoft’s docs use the terms “1P” (first party) and “3P” (third party). The distinction refers to whose infrastructure serves the inference, not who built the app or who uses it.
First party (1P) means inference runs on Anthropic's infrastructure (the default). Third party (3P) means it routes through a provider you configure, such as Microsoft Foundry, Amazon Bedrock, Google Cloud's Vertex AI or a gateway you run. Same application either way. What changes is where the tokens are served, who bills them and what leaves your environment. That distinction also explains the feature boundary, since a handful of capabilities depend on Anthropic-hosted inference by construction:
Foundry typically covers the surfaces where Claude does work, and claude.ai covers the surfaces where people talk with Claude and where the organization supervises it. Plan for both columns on purpose. The one that catches teams late is Code Review, which is very good and lives on the seat side.
This isn't only a developer story
Claude Desktop can run against Foundry, too, which is what turns this from an engineering rollout into something the rest of the business can use. In that mode, you get the Cowork and Code tabs. Conversation history stays on the user's device; inference goes to your Foundry endpoint; and configuration arrives through your existing device management tooling rather than a vendor console. Users also can't override it when an admin profile is in place which are huge wins in regulated and highly secure environments.
Anthropic doesn't offer seat licensing on this path. Inference bills as consumption on your Azure account, which changes the arithmetic when deciding how far beyond engineering to extend access.
You can export full session telemetry to your own collector, including requests with token counts and estimated cost, tool execution outcomes, errors and session/user attribution for per-team breakdowns. Anthropic-bound crash reports and product analytics carry no conversation content, and you can switch them off entirely.
Local conversation storage also cuts both ways. Nothing is retained server-side to govern, but there’s also no central archive. If your supervision or underwriting processing agent requires retained conversations, that's an architecture problem to solve, not a footnote to skip.
Two caveats: Identity on the third-party routes is local device identity, with no vendor login and no hosted admin console, so central control is real but shaped like endpoint management rather than IAM. And Cowork on 3P is still in beta, with new features shipping to first-party first.
When the requirement is no first-party inference at all
Some clients need a hard commitment that no conversation content reaches first-party endpoints. That's achievable, but it requires four important decisions.
- Constrain the hosting option by policy. Foundry offers both hosted-on-Azure and hosted-on-Anthropic deployments, so choosing Foundry doesn't keep inference in Azure by itself. Enforce hosted-on-Azure with Azure Policy. The other route carries capabilities that somebody with rights on a resource group will reasonably want, and “reasonably wanted it” is how most architecture drifts.
- Make first-party unreachable, not just unchosen. That means centrally managed configuration, egress control, and no claude.ai seats for the population under the mandate. The configuration tooling publishes the hostnames it needs, which double as the definitive list of what to block.
- Turn off vendor-bound telemetry explicitly. It's already off by default for Claude Code on third-party providers, and you can disable it on Desktop. Document both as decisions rather than inherited defaults; “it was the default” is not an answer that survives an audit.
- Build the chat surface yourself if Cowork isn't the right fit for a given group. A thin app over the Foundry inference or agent APIs inherits your identity and networking posture, and most large enterprises already have an internal AI portal to extend.
Where this is heading
The trajectory through 2026 has been from a single API call toward something closer to a production agent platform, with structured outputs, web search and fetch, MCP connectors and tool search arriving progressively for Claude in Foundry.
Decide which column each workload belongs in, build the identity, spend and evidence plumbing once, and every agent you ship after this one inherits it. That way, you can avoid rearchitecting, and you can consume all of what Microsoft Foundry has to offer.
Nimble Gravity helps teams make this real
This is exactly the work we do for regulated FSI clients as a certified Microsoft and Anthropic partner. We stand up a governed Foundry environment, wire Entra ID and RBAC, put a gateway in front of it and enable the pilot team that proves it out. If your security team is asking these questions right now, we can walk you through a four-to-six-week accelerator that gets a production-ready answer in your own tenant.
