Claude Desktop on 3P is a deployment mode of Claude Desktop in which every model call is routed through an inference provider you configure - Amazon Bedrock, Google Cloud's Agent Platform, Microsoft Foundry, a compatible gateway you operate, or the Anthropic API directly.
- You get the whole app. Chat, Cowork and Code, including file creation, multi-step research and sub-agent coordination.
- Inference lands in your account. Your region, your identity, your audit log, your existing cloud bill.
- The route is set by MDM. A managed configuration profile per device group, not a user preference.
- The trade is cadence and tooling. New capability reaches first-party products first, and there is no in-app admin console.
Claude Desktop is one application with three surfaces your team already knows: Chat, Cowork for knowledge work, and Claude Code for engineering. On 3P, that application stays exactly where it is on the laptop. What changes is the road the model traffic takes out of it.
Third-party inference, or 3P, is a deployment mode in which every model call from Claude Desktop is routed to a provider you configure: Amazon Bedrock, Google Cloud's Agent Platform, Microsoft Foundry, a compatible gateway you operate yourself, or the Anthropic API directly. The full experience comes with it: Chat, Cowork and Code, including file creation, multi-step research and sub-agent coordination.
For an IT function, that single change moves three things at once: where the inference lands, which account it is billed to, and which audit log it appears in. This post covers what the route is, how it is set across a fleet, and what you take on when you own it.
One thing to settle before any of it: 3P is built for organisations whose security, regulatory or contractual position rules out sending data through Anthropic's first-party products. If yours can use them, standard Claude Desktop with Cowork on a Team or Enterprise plan is the simpler deployment. It has an in-app UI for user management, analytics and RBAC, and it receives new features first. Choose 3P when routing inference through the Anthropic API is not an option.
What 3P actually changes
A 3P deployment is not a different product and not a different interface. Users install the standard Claude Desktop application and sign in as usual. The app then reads a configuration your IT team controls, and sends its model calls to the endpoint that configuration names.
Three consequences follow, and they are the reason security teams ask for it:
Location becomes a decision you make. Inference runs in the account and region you nominate, so residency is answered by infrastructure rather than by a policy document.
Cost joins the bill you already negotiated. Usage is consumption-priced through your existing cloud agreement, which means it sits inside commitments you have already made rather than beside them.
Evidence appears where your auditors already look. Calls show up in your provider's audit log, next to every other workload, with the identity that made them attached.
The useful way to think about 3P is that it converts an AI question into an infrastructure question. Nothing about it is novel to your cloud team: it is an endpoint, an identity, a region, a quota, and a log.
The four routes out of the app
All four routes deliver the same Claude models. They differ in the identity model you authenticate with, the network controls available, where the logs land, and how far the deployment is actually separated from Anthropic. On Bedrock and the Agent Platform, the cloud provider processes conversation data in the region you select. On Foundry, Anthropic operates the Claude models and residency follows the Foundry deployment type, so read that one closely if residency is the reason you are here.
The gateway route is the flexible one and the one to be careful with. A self-hosted proxy lets you put one policy point in front of several providers, add your own redaction, and fail over between regions. It also means you are operating a component that sees prompt content, so it needs the same review as any other system in that position.
What the managed config sets
The route is not something each user types in. It arrives as a managed settings file pushed by your MDM, such as Jamf, Microsoft Intune or Group Policy, scoped to a device group. Eight things are worth setting deliberately.
Terms you will see in the profile
Because the profile is scoped to a group, the route is per team rather than per company. Engineering can sit on one provider and region while a regulated function sits on another, from a single build of the app.
What leaves the device, and what does not
This is the section your security reviewer will read first, so it is worth being exact.
Start with the app itself. Claude Desktop runs from a bundled local web application, and conversation history is stored on the user's device rather than in a hosted account. That is a meaningful property for a regulated deployment, and it is also a backup and endpoint-encryption question you now own.
Prompt content, file excerpts and tool results go to your provider endpoint, over TLS, using the identity in the configuration. That is the inference call, and it is the whole point of the route.
Files themselves stay on the machine unless a connector or MCP server you allowed sends them somewhere. Which connectors exist is a configuration decision, which is why the allowlist matters more than any individual setting.
Aggregate telemetry such as token counts, model identifiers, error codes and an anonymous device identifier can still flow to Anthropic. It is not conversation content, it is also not nothing, and it can be disabled in configuration.
Everything else is your provider's contract, not a new one. On Bedrock, prompts, files, tool inputs and outputs and model responses are not stored and are not used to train foundation models. Vertex AI and Foundry make equivalent commitments in their own terms. You are inheriting an agreement your legal team has most likely already signed.
If a security reviewer is going to ask you these questions, it is cheaper to answer them with a working configuration than with a slide. We will review your AWS or Azure position, the region, and what that means for residency on a first call, and you keep the notes either way.
See what is included →The trade-offs to plan for
Owning the route means owning some work that Anthropic otherwise does for you.
Release cadence. New capability lands in Anthropic's first-party products first and reaches 3P afterwards. You are trading a few weeks of newness for control of the request path.
Administration. There is no in-app console for user management, analytics or RBAC. Those live in your MDM and your provider, which is precisely why the configuration profile below carries so much weight.
Capacity. Throughput quotas, model availability and region coverage are set by your provider. A rollout that outruns its quota looks like a broken app to the user, so quotas move before people do.
Model lifecycle. New models reach providers on their own schedule. Model IDs live in the config, so upgrading is a fleet change you schedule rather than something that happens to you.
Cost visibility. Consumption pricing rewards attention. Per-team tagging and a budget alert on day one are cheaper than a surprise in month three.
From a few desks to the whole organisation
The rollouts that work start narrow and instrument early. A sequence we keep returning to:
Start with engineering. Claude Code on a dozen developer machines exercises the route hard and produces usage you can measure in a fortnight, without a change-management programme.
Set the money and the identity before the second group. Tags, budgets, quota increases and the SSO path into the provider are all easier to fix at twelve users than at two hundred.
Route models by tier. A fast model for interactive work and a stronger model for planning, both pinned in the config, gives you a cost lever that needs no retraining of users.
Add connectors one at a time. Each MCP server is a new path into a system of record. Approve them individually, with the read and write scopes written down.
Then push the profile to the next MDM group. By that point the change is mechanical, and the interesting decisions are already made and documented.
AWS described a similar arc in their write-up on taking Claude Cowork from developer desks to a whole organisation on Bedrock. The details differ by provider; the order does not. Our own deployment case studies follow the same shape.
Where Moterra fits
The route is a day of work. The layer around it is the project: environment and region setup on Amazon Bedrock in your AWS tenant or Microsoft Foundry in your Azure tenant, the identity path from your SSO, the managed configuration in your MDM, the connector allowlist, the plugins that reach your SharePoint, databases and workflows, and the reporting your auditors ask for.
That layer is Moterra AI Bridge, and the deployment it sits on is Private Claude Cowork by Moterra. We build in AWS and Azure, we are an official Anthropic partner and an AWS partner, we operate as a data processor under a DPA covering UK and EU GDPR, and the stack is ISO 27001 and ISO 42001 certified across the AWS and Anthropic layers.
The comparison that matters is not Moterra against another vendor. It is Moterra against your own team's next two quarters.
What that looks like in a live deployment: Skaylink, a Vodafone group company, reached 80% team adoption within a week of go-live and cut the time their NIS2 audit process takes by 90% with a Claude-powered audit tool built on the Moterra platform. More of those in the case studies.
Pricing follows the same logic as the deployment: you pay your provider for consumption and Moterra for the managed service, with no seat licence in between. The quote configurator prices users, support tier and plugins in the open, so you can take a number to your finance team before you talk to us.
Conclusion
Claude Desktop on 3P is a small change with a large blast radius in the right direction. Same app, same models, same interface for the person using it, and a request path that terminates in an account you control, in a region you chose, against an identity you issued.
The question to settle first is not which provider. It is which team goes first, and what you want to be able to prove about their usage by the end of the month. That is the conversation we have on a first call, in your AWS or Azure tenant, and you leave it with a configuration you could hand to your own engineers.
Frequently asked questions
What is Claude Desktop on 3P?
Claude Desktop on 3P is a deployment mode of the Claude Desktop application in which every model call is routed through an inference provider you configure, rather than through Anthropic’s first-party products. The full experience comes with it: Chat, Cowork and Code, including file creation, multi-step research and sub-agent coordination. The app runs from a bundled local web application, and conversation history is stored on the user’s device.
What does 3P stand for?
3P is short for third party, meaning a third-party inference provider. 1P, or first party, is Anthropic’s own infrastructure behind claude.ai and the Claude API.
Which providers can Claude Desktop route to?
Amazon Bedrock, Google Cloud’s Agent Platform, Microsoft Foundry, a compatible gateway you operate, or the Anthropic API directly. The route is set per device group by managed configuration, so different teams can sit on different providers without shipping two versions of the app.
Does the interface change on 3P?
No. Users install the same Claude Desktop application and see the same interface. What changes is the endpoint the app calls, the account the inference is billed to, and the audit log the call appears in.
Who should use Claude Desktop on 3P?
Organisations whose security, regulatory or contractual requirements prevent them from sending data through Anthropic’s first-party products: highly regulated enterprises restricted to third-party inference, and international enterprises with in-region data residency requirements. If your organisation can use first-party products, standard Claude Desktop with Cowork on a Team or Enterprise plan is the simpler deployment.
How is a 3P route configured across a fleet?
Through a managed settings file pushed by your MDM, such as Jamf, Microsoft Intune or Group Policy. It names the provider and endpoint, the region and inference profile, the model IDs per tier, the credential source, proxy and certificate trust, the telemetry switch, and which plugins and MCP servers are allowed.
What are the trade-offs of a 3P deployment?
New capability reaches Anthropic’s first-party products before 3P, and there is no in-app console for user management, analytics or RBAC: those live in your MDM and your provider. You also own capacity planning, since model availability, region coverage and throughput quotas are set by your provider.
Does data residency depend on the provider?
Yes. On Amazon Bedrock and Google Cloud’s Agent Platform, the cloud provider processes conversation data in the region you select. On Microsoft Foundry, Anthropic operates the Claude models and residency follows the Foundry deployment type, so review that before choosing a provider if residency is the reason for the deployment.
How long does a Claude Desktop on 3P deployment take?
Most organisations are live in under a week. Moterra deploys into your own AWS or Azure tenant, on Amazon Bedrock or Microsoft Foundry, and handles environment and region setup, the identity path from your SSO, the managed configuration in your MDM, the connector allowlist and the reporting an audit asks for, so there is no internal IT project to run.
Key takeaways
- 3P changes the request path, not the product. Same app, same models, same interface.
- Pick the provider for its identity model, region coverage and audit surface, then read the residency detail before you commit.
- The managed configuration is the whole governance story: route, models, credentials, proxy, telemetry, allowlists.
- Budgets, tags and quotas are cheap to set at twelve users and expensive to retrofit at two hundred.
- If first-party products are open to you, use them. Choose 3P when routing through the Anthropic API is not an option. Talk to Moterra if you are not sure which side of that line you are on.
