Skip to main content
This page walks an IT administrator through a Microsoft Foundry deployment: creating the Microsoft Foundry resource, choosing the authentication path that fits your organization, and pushing the managed configuration. If you only need the list of configuration keys, skip to Configure the app.
Claude models in Microsoft Foundry are available in two hosting options, Hosted on Azure and Hosted on Anthropic. Anthropic acts as an independent processor for Microsoft, and customers are subject to Anthropic’s data use terms. For deployments hosted on Azure, prompts and completions remain within Azure; only usage metadata and content flagged by Anthropic’s safety systems egress to Anthropic. Deployments hosted on Anthropic run on Anthropic’s infrastructure. See Claude in Microsoft Foundry for details.

Choose an authentication approach

ScenarioUsePer-user identityNotes
Proof of concept, single teamAPI key (inferenceFoundryApiKey)No (shared key)A long-lived secret distributed in the managed profile. Simplest to start.
Broad rollout with per-user identityIn-app Entra ID sign-in (inferenceFoundryTenantId, inferenceFoundryClientId, inferenceFoundryAuthFlow)YesUsers sign in with their Entra ID account inside the app, through a device code or the system browser. The device-code flow requires app version 1.9255.0 or later; the browser flow requires app version 1.19367.0 or later.
Your organization already has tooling that obtains a Microsoft Foundry credentialCredential helper (inferenceCredentialHelper)Depends on what the helper obtainsAn executable that prints the credential to stdout at runtime.

Set up Azure

These steps are performed once per Azure subscription. You need permission to create resources and, for in-app sign-in, to register an application in Microsoft Entra ID.
1

Create a Microsoft Foundry resource

In the Azure portal, create a Microsoft Foundry resource in your subscription. Record the resource name; the app constructs the endpoint as <resource-name>.services.ai.azure.com.
2

Deploy the Claude models

In the Microsoft Foundry portal for your resource, deploy the Claude models you intend to serve. Record each deployment name; you will list these in inferenceModels.
3

Obtain an API key (API-key approach only)

If you chose the API-key approach, copy one of the resource’s keys from the Azure portal. You will place it in the managed configuration in Configure the app.
4

Register an Entra ID application (in-app sign-in only)

If you chose in-app Entra ID sign-in, register an application in the Microsoft Entra admin center under Identity → Applications → App registrations → New registration. On the registration:
  • Under API permissions, select Add a permission, find Azure Cognitive Services in the API picker, and add the Delegated permission user_impersonation so the issued token is accepted by your Microsoft Foundry resource. (The app requests this permission as the scope https://cognitiveservices.azure.com/.default.) Both sign-in flows need it. After adding the permission, select Grant admin consent; in tenants that disable user consent, sign-in fails with error code AADSTS65001 until consent is granted.
  • Under Authentication, complete the setup for the sign-in flow you plan to use (see In-app Entra ID sign-in for how the flows differ):
    • For the device-code flow (the default), enable Allow public client flows. Entra ID rejects device-code sign-in without it.
    • For the browser flow (inferenceFoundryAuthFlow set to browser), select Add a platform → Mobile and desktop applications and add the redirect URI http://127.0.0.1/callback. Use the literal address 127.0.0.1, not localhost: Entra ID matches the scheme, host, and path exactly and ignores only the port. The browser flow completes sign-in without Allow public client flows. Conditional Access policies that block the device-code authentication flow do not apply to the browser flow.
Record the Directory (tenant) ID and Application (client) ID.Grant the users or groups who will sign in a role on the Microsoft Foundry resource that permits inference (for example, Cognitive Services User).

Prepare devices

What each end-user device needs depends on the authentication approach you chose.

API key

No per-device preparation is required. Place the resource’s API key in the managed configuration as inferenceFoundryApiKey.

In-app Entra ID sign-in

No per-device preparation is required. Distribute inferenceFoundryTenantId and inferenceFoundryClientId in the managed configuration. To use the browser flow instead of the default device-code flow, also set inferenceFoundryAuthFlow to browser. When the tenant and client IDs are set and inferenceCredentialKind is interactive, the app shows a Sign in with Microsoft page the first time a user opens the Cowork tab. Clicking the button starts a sign-in against login.microsoftonline.com; what the user sees depends on inferenceFoundryAuthFlow:
  • Device code (the key is unset or device-code): the app displays a short verification code and opens the Microsoft sign-in page in the default browser, where the user enters the code and approves access.
  • Browser (the key is browser): the app opens the Microsoft sign-in page in the default browser, where the user signs in and approves access. The browser shows a confirmation page and the user switches back to the app; there is no code to enter.
On success, the app stores the refresh token encrypted with the operating system’s secure storage (Keychain on macOS, DPAPI on Windows) and returns to the Cowork tab. Both flows store the same token against the same app registration, so changing inferenceFoundryAuthFlow later does not itself prompt users to sign in again. If the stored refresh token expires or is revoked, the app shows a Sign in again prompt; clicking it reopens the Microsoft sign-in page in the browser. inferenceFoundryTenantId and inferenceFoundryClientId can be set only via an MDM profile, not via a bootstrap server. inferenceFoundryAuthFlow can be set via either.
In-app sign-in and a bootstrap server are separate layers that work together. In-app sign-in supplies each user’s inference credential, the Entra ID token that authorizes model calls. A bootstrap server supplies per-user configuration values when the app starts. A bootstrap server does not replace sign-in: a deployment with a bootstrap server still needs each user to sign in, and signing in does not deliver configuration.

Allow network egress

The sign-in flow reaches login.microsoftonline.com in addition to your Microsoft Foundry endpoint. Both hosts are included automatically in the Egress Requirements section of the in-app configuration window when these keys are set.

Configure the app

Open the in-app configuration window (Developer → Configure Third-Party Inference…). In the Connection section, set Inference provider to Foundry, then fill in the Foundry credentials card with the values for whichever authentication approach you chose:
FieldAPI keyIn-app Entra ID sign-in
Azure AI Foundry resource nameyour-foundry-resourceyour-foundry-resource
Azure AI Foundry API keyyour resource keyleave empty
Entra ID tenant IDleave empty00000000-0000-0000-0000-000000000000
Entra ID client IDleave empty11111111-1111-1111-1111-111111111111
Entra ID sign-in flowleave emptybrowser, or leave empty for the default device-code flow
Under Models, add at least one Model list entry using the Microsoft Foundry deployment name. Then click Export to produce a .mobileconfig (macOS) or .reg (Windows) file for your MDM. See Deploy with MDM for the export and deployment workflow.

Configuration keys

The full set of inferenceFoundry* keys is below. Set inferenceProvider to foundry, supply the resource name, and provide exactly one credential source.
SettingTypeAvailabilityDefaultDescription
Azure AI Foundry resource name
inferenceFoundryResource
stringMDM + BootstrapAzure AI Foundry resource name used to construct the endpoint URL.
Azure AI Foundry API key
inferenceFoundryApiKey
stringMDM + BootstrapAPI key for Azure AI Foundry inference.
Entra ID tenant ID
inferenceFoundryTenantId
stringMDM onlyDirectory (tenant) ID of the Entra ID app registration that has the Cognitive Services scope.
Entra ID client ID
inferenceFoundryClientId
stringMDM onlyApplication (client) ID of the Entra ID app registration. Device-code sign-in requires the app to allow public client flows.
Entra ID sign-in flow
inferenceFoundryAuthFlow
enumMDM + BootstrapHow interactive Entra ID sign-in runs: device-code (default) shows a code to enter at microsoft.com/devicelogin; browser opens the system browser for an authorization-code (PKCE) sign-in. One of: device-code, browser.
The browser flow sends a loopback redirect URI, so the app registration must include “http://127.0.0.1/callback” under the “Mobile and desktop applications” platform (Entra ignores the loopback port, but not the path), and it works with “Allow public client flows” disabled. Conditional Access policies that block the device-code authentication flow do not affect the browser flow. App versions that predate this key always use device code.
You must also set inferenceModels to a list of Microsoft Foundry deployment names. See the Configuration reference.

What users experience

ApproachFirst launchRe-authentication
API keyThe app opens directly; no user action.Never, until you rotate the key in the managed profile.
In-app Entra ID sign-in, device-code flowThe app shows a Sign in with Microsoft page; the user approves a device code in the browser, and the app returns to Cowork.When the stored refresh token expires or is revoked under your tenant’s policy. The app prompts in-app.
In-app Entra ID sign-in, browser flowThe app shows a Sign in with Microsoft page; the user signs in through the system browser, with no code to enter, and the app returns to Cowork.When the app can no longer renew the stored token. The app prompts in-app.

Troubleshoot

To confirm which keys the app read and whether credentials validated, use Help → Troubleshooting → Copy Managed Configuration Report; see Verifying the deployment for that workflow and the common causes when the app does not enter 3P mode. Application log locations are listed in Data storage and residency. If sign-in fails at the token step, confirm the Azure Cognitive Services permission is granted and consented on the app registration. For the device-code flow, also confirm Allow public client flows is enabled; Entra ID rejects device-code sign-in without it. If sign-in fails with error code AADSTS650057, the user_impersonation permission is missing from the app registration. Add it under API permissions. If sign-in fails with error code AADSTS65001, the permission has not been consented. Select Grant admin consent on the API permissions page, or have the user accept the consent prompt if your tenant allows user consent. If browser-flow sign-in fails in the browser with error code AADSTS50011, the redirect URI is missing from the app registration or does not match. Add http://127.0.0.1/callback under Authentication → Mobile and desktop applications, using the literal address 127.0.0.1, not localhost. If the browser shows the confirmation page but in-app sign-in still fails, with error code AADSTS7000218 in the application logs, the redirect URI is registered under the Web platform. Move it under Mobile and desktop applications. Each sign-in attempt has a time limit: five minutes for the device-code flow and two minutes for the browser flow. If the user does not finish within the limit, the attempt fails and the user can click Sign in with Microsoft to start again.