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

The four supported routes for running Claude Cowork outside Anthropic's infrastructure — Bedrock, Vertex AI, Microsoft Foundry, custom gateway — with the residency posture for each.

Updated 2026-04-28Read 9 min

TL;DR. Cowork on 3P is a deployment mode of Claude Desktop that routes inference through your cloud provider instead of Anthropic's API. Four routes are supported in the current Research Preview: Vertex AI, Amazon Bedrock, Microsoft Foundry, and any compatible gateway you operate. Vertex and Bedrock give you a true no-conversation-data-to-Anthropic posture. Microsoft Foundry does not — Claude models still run on Anthropic infrastructure under that route; Foundry is a billing and access integration through Azure, not a residency solution. Pick 3P when first-party Cowork is a no-go for regulatory, contractual, or sovereignty reasons; otherwise stay on hosted Cowork because it is simpler and ships features faster.

What "3P" actually is#

Cowork on 3P (third-party) is a deployment mode of the Claude Desktop app — same Cowork tab, same Code tab, same agentic feature set — where model inference runs on a provider you configure rather than on Anthropic's API. The desktop app is loaded from a local bundle; conversation history is stored on the user's device; user identity is local rather than an Anthropic account.

The deployment is currently a Research Preview with no GA date announced. Production rollouts should be planned with that in mind: feature parity, support SLAs, and admin tooling are not yet at the level of first-party Cowork.

The four supported routes#

RouteInference runs onConversation data leaves your tenant?Residency posture
Amazon BedrockYour AWS account, your selected regionNoDetermined by your AWS region + the user's device location
Google Cloud Vertex AIYour GCP project, your selected regionNoDetermined by your GCP region + the user's device location
Microsoft Foundry (preview)Anthropic infrastructure — accessed via AzureYes — to AnthropicThis route is not a residency solution; it's a commercial integration for Azure billing and access
Custom gatewayWhatever your gateway points atDepends on what your gateway does — verify before deploymentDetermined by your gateway's downstream

The "no conversation data to Anthropic" claim that 3P content is built around applies to Bedrock and Vertex AI. It applies to a custom gateway only if your gateway does not route inference to Anthropic infrastructure. It does not apply to Microsoft Foundry. Anthropic states this directly in its 3P documentation; we restate it because it's the easiest mistake for a buyer to make when comparing routes.

Architecture, in one paragraph#

The desktop app detects 3P mode at launch from a managed-configuration key (inferenceProvider). When that key is set and credentials are present, the sign-in screen offers an option to skip Anthropic authentication and start the app from your inference-provider configuration. Inference requests go directly from the user's machine to the regional endpoint you configure (inferenceVertexRegion or inferenceBedrockRegion for the cloud routes). Tool execution, file I/O, and the rest of the Cowork sandbox behave identically to first-party Cowork; only the inference path changes.

Security posture#

Three things hold for the Bedrock and Vertex AI routes:

  • No conversation egress to Anthropic. Prompts, responses, files, and tool outputs go only to your configured inference endpoint and to local disk. The desktop app's own crash reports and product analytics still go to Anthropic by default, scrubbed of conversation and user data, and can be fully disabled.
  • Sandboxed tool execution. Shell commands run in the same hardened Cowork VM used in first-party Cowork; file access is scoped to your allowed folders.
  • Auditable telemetry. OpenTelemetry export of full session activity (prompts, tool calls, token counts) to your own collector is supported independently of the Anthropic-bound telemetry, which can be turned off in MDM configuration.

For the Foundry route, security commitments fall back to Anthropic's standard data-use terms — same posture as a first-party Cowork deployment, accessed via Azure billing.

Residency and international deployment#

For Bedrock and Vertex AI, residency is determined by two things only: the cloud region you select for inference, and the physical location of the user's device, where conversations persist on local disk. There is no Anthropic-side residency layer to negotiate.

In multi-region organisations, the standard pattern is one MDM configuration profile per geography, each pointed at an in-region endpoint. Both Bedrock and Vertex AI offer Claude models in EU, UK, APAC, and sovereign regions; consult the provider's model-availability documentation for the current list before committing.

Public sector, FedRAMP, ITAR, sovereign cloud#

Because inference runs in the customer's own cloud tenant on the Bedrock and Vertex AI routes, Cowork on 3P inherits the compliance boundary of whatever provider and region the tenant runs in. The desktop application's only outbound connections to Anthropic — crash reports, product analytics, auto-updates — can each be disabled independently via managed configuration.

With those Anthropic-bound paths disabled, the compliance posture of the deployment is determined entirely by the inference provider. A Cowork deployment in a FedRAMP High-authorised region of Bedrock or Vertex AI keeps model traffic inside that boundary; the FedRAMP relationship is between the customer's organisation and the cloud provider.

Who 3P is for (and who should stay on hosted)#

3P is the right call when:

  • A legal, contractual, or regulatory constraint prevents the customer from sending data to Anthropic's first-party infrastructure (most often: defence, federal, healthcare with PHI, certain financial services).
  • The customer requires in-region data residency that Anthropic's first-party regions don't yet offer, or requires sovereign-cloud isolation.
  • The customer is large enough on AWS or GCP that consumption-based inference billing through their existing cloud agreement is materially better than seat licensing.

Stay on first-party hosted Cowork when:

  • The customer's compliance program accepts SaaS processors with strong DPAs (most general mid-market in the US/UK).
  • The customer wants the simpler in-app admin console at claude.ai for user management, analytics, and RBAC — 3P uses OS-native MDM configuration only.
  • The customer wants the latest Cowork features as they ship; first-party releases first.

What's missing in 3P (the trade-off)#

Because inference is routed away from Anthropic-hosted endpoints, three pieces of first-party Cowork are not available in the Bedrock and Vertex AI routes:

  • The Chat tab in Claude Desktop.
  • Computer Use (currently in research preview on first-party).
  • The Skills Marketplace (the in-app discovery and install flow for skills).

Skills, plugins, and MCP connectors that the customer deploys themselves still work — what's missing is the marketplace experience, not the extension mechanism. See the Cowork on 3P feature matrix for the full table of what's in and what's out.

Deployment shape#

  • Identity. Local device identity only on the Bedrock / Vertex / gateway routes — no Anthropic account login. Tie identity to the user's OS / SSO posture upstream of the desktop app.
  • Configuration. All settings are delivered via MDM (Jamf, Kandji, Mosyle, Workspace ONE for macOS; Intune or Group Policy for Windows). Admin profiles cannot be overridden by end users.
  • Billing. Consumption-based through the customer's existing AWS / GCP / Azure agreement. No seat licensing from Anthropic for the cloud routes. Foundry billing flows through Azure.
  • Audit. Independent OpenTelemetry export of session activity to the customer's collector; no dependency on the Anthropic-bound telemetry path.

Tinkso's take#

For mid-market deployments in the US and UK, first-party hosted Cowork is the right default — simpler, fully featured, and supportable. We recommend 3P only when one of three conditions holds: (a) a compliance program that explicitly excludes US-hosted SaaS processors, (b) a defence / federal / sovereign-cloud mandate, or (c) a customer that already runs significant workload on Bedrock or Vertex and has the platform-engineering capacity to own MDM, telemetry, and the inference budget.

The Microsoft Foundry route is the one we treat with the most care. It looks like the other 3P routes in the marketing materials, but it is not a residency solution — Claude models run on Anthropic infrastructure under that route, and customers buying it for residency reasons have made a procurement mistake. We surface this in the first 30 minutes of any Foundry-shaped conversation.

3P is a Research Preview. Do not commit to a regulated production deployment without reading Anthropic's 3P documentation directly and confirming the current state of the feature matrix, telemetry controls, and supported regions for your geography. Tinkso re-verifies this page monthly.

Try this#

Walk this page to procurement, IT, and security in one meeting. For each row of the four-routes table above, mark the row in scope, out of scope, or needs review. That triage is enough to write the first procurement requirement: "Cowork must be deployable through [route], inference must remain in [region], and [list of disabled telemetry paths] must be configurable via MDM."

If the answer is in scope: Bedrock, continue to Cowork on Bedrock. For Vertex AI, continue to Cowork on Vertex AI. For Foundry, read Cowork on Microsoft Foundry before you get further into procurement.