Browse the bible
Foundations
Getting started
Capabilities
Security & governance
Workflows
Prompt library
Rollout playbook
Troubleshooting
Reference
Security & governance · Cowork on third-party platforms — running Claude Cowork on your own cloud

Cowork on Microsoft Foundry — what it actually is, and what it isn't

Microsoft Foundry is not a residency solution for Claude Cowork. Inference still runs on Anthropic infrastructure; Foundry is a billing and access integration through Azure.

Updated 2026-04-28Read 6 min

TL;DR — and please read this paragraph before procurement. Microsoft Foundry is not a residency solution. When Cowork on Foundry is in use (in the current preview), Claude models still run on Anthropic's infrastructure; Foundry is a commercial integration that lets organisations buy Claude access and route billing through Azure. Customers using Claude through Microsoft Foundry are subject to Anthropic's data-use terms — same posture as a first-party Cowork deployment, accessed via Azure billing. The "no conversation data to Anthropic" claim that applies to Bedrock and Vertex AI does not apply to Foundry. If your reason for evaluating 3P is data residency, sovereignty, or "we cannot send data to Anthropic infrastructure," Foundry is the wrong route — pick Bedrock or Vertex AI instead.

What Foundry actually is in the Cowork context#

Microsoft Foundry is a Microsoft platform for accessing AI models, including Claude, with Azure-native billing and access management. In the Cowork on 3P preview, Foundry is one of the four configurable inference providers — alongside Bedrock, Vertex AI, and a custom gateway.

The structural difference is in where inference physically runs:

  • On Bedrock, inference runs in the customer's AWS account.
  • On Vertex AI, inference runs in the customer's GCP project.
  • On Foundry, inference runs on Anthropic's infrastructure — Azure handles billing, access, and the customer-facing commercial relationship. Anthropic acts as an independent processor for Microsoft.

Bedrock and Vertex move the model to your cloud. Foundry moves the contract to Microsoft, but leaves the model on Anthropic's side.

What this means for residency#

The Cowork on 3P documentation is explicit that the data-residency, compliance, and "no conversation data sent to Anthropic" statements do not apply to the Foundry route. If a customer is evaluating 3P because:

  • They cannot send conversation data to Anthropic for regulatory reasons, or
  • Their compliance program forecloses non-AWS or non-GCP processors, or
  • They have a sovereign-cloud or data-residency mandate that excludes US-hosted Anthropic infrastructure,

…then Foundry is the wrong answer. The right answers are Bedrock or Vertex AI in an in-region endpoint, or staying on first-party Cowork with an Enterprise contract that supports the customer's posture.

What Foundry is the right answer for#

Foundry is a procurement and commercial route, not a residency route. It is genuinely useful when:

  • The customer is Azure-committed for billing and procurement, has minimal AWS or GCP footprint, and wants Claude access to flow through the existing Microsoft commercial relationship.
  • The customer's compliance program accepts Anthropic as a SaaS processor with strong DPAs (i.e., the same posture that would let them use first-party Cowork). Foundry doesn't reduce the processor surface; it changes who the contract is with.
  • The customer wants unified Microsoft billing for AI spend across vendors and Foundry consolidates that.

In each of these cases, Foundry is fine — and customers should compare it to first-party Enterprise Cowork on price, support, and feature parity. The decision is a commercial one, not a security one.

Anthropic's data commitments under Foundry#

Anthropic states in the 3P documentation that customers using Claude through Microsoft Foundry are subject to Anthropic's data-use terms, and that Anthropic continues to provide its industry-leading safety and data commitments — including zero-data-retention availability — under the Foundry route.

In practice, the Foundry route inherits Anthropic's standard Cowork data posture. It is not worse than first-party Cowork; it is structurally equivalent. The error is treating it as equivalent to Bedrock or Vertex AI, which it isn't.

Cowork features under Foundry#

Because inference still terminates at Anthropic infrastructure under Foundry, the feature subset on this route is closer to first-party Cowork than to Bedrock or Vertex AI. The exact feature matrix for the Foundry preview should be verified against Anthropic's feature matrix doc at the time of evaluation — this is the area of the 3P preview that is moving fastest. As of this page's last_reviewed date, the feature subset on Foundry tracks first-party Cowork more closely than the cloud-native 3P routes.

The procurement check#

A two-question filter for any team being pitched Foundry as a Cowork deployment route:

  1. "Is our reason for evaluating 3P a residency or sovereignty constraint?" If yes, Foundry is the wrong route. Stop, and re-scope to Bedrock or Vertex AI in an in-region endpoint.
  2. "Is our reason for evaluating 3P a billing or commercial-relationship constraint?" If yes, Foundry can be a fit — and you should also price it against first-party Enterprise Cowork to understand the commercial spread.

If neither question applies, the customer is most likely better served by first-party hosted Cowork.

Tinkso's take#

We treat Foundry as a procurement route, not a deployment route. When a buyer comes in saying "we want Cowork on Foundry," our first 15 minutes is always understanding why — because in roughly half the cases the underlying reason is a residency or sovereignty constraint that Foundry doesn't actually solve. When the reason is genuinely commercial (Azure-led billing, vendor consolidation, existing Microsoft commercial momentum), Foundry is a fine answer and we deploy it. When the reason is residency, we redirect to Bedrock, Vertex AI, or a first-party Enterprise contract with a region negotiation.

The risk with Foundry is procurement-by-press-release. A press release that announces "Claude is available on Microsoft Foundry" is true and well-shaped for marketing; it is not procurement guidance. Read the 3P documentation directly — particularly the asterisk on Foundry in the residency section — before committing.

Try this#

If your team is currently evaluating Cowork on Foundry, write down — in one sentence — why Foundry rather than Bedrock, Vertex, or first-party. If that sentence contains the words "residency," "sovereignty," "data," or "compliance," stop and re-read the 3P overview. If it contains the words "billing," "commercial," "Microsoft," or "consolidation," continue.

Need help applying this?

Book a 30-minute call. We'll ask where you are, what your team needs, and which systems Cowork should touch.

Last reviewed: 28 April 2026 · The Cowork Bible · Tinkso