Deploy Cowork on 3P with Amazon Bedrock

Set up AWS, choose an authentication path for your organization, and configure Cowork on 3P to use Claude models on Amazon Bedrock

This page walks an IT administrator through a complete Amazon Bedrock deployment: enabling Claude in your AWS account, choosing the authentication path that fits your organization, preparing devices, and pushing the managed configuration. If you only need the list of configuration keys, skip to Configure the app.

Choose an authentication approach

Bedrock supports several ways to authenticate, and the right one depends on whether your end users already work with AWS and whether you need per-user identity in CloudTrail. Use the table below to pick a path before doing any AWS or device setup.

Scenario	Use	Per-device prerequisite	Per-user CloudTrail identity	Notes
Proof of concept, single team	Bearer token (inferenceBedrockBearerToken)	None	No (shared key)	A long-lived secret distributed in the managed profile. Simplest to start; not recommended for broad rollout.
Developers who already use the AWS CLI	Named profile (inferenceBedrockProfile)	AWS CLI v2 and a pushed ~/.aws/config	Yes	IT can distribute the AWS config file directly; users run aws sso login to refresh.
You already operate an LLM proxy	Gateway provider instead of Bedrock	None	At your gateway	The proxy holds the AWS credentials; the app authenticates only to the proxy.

If a static credential in the managed profile is acceptable but a Bedrock API key is not, you can also set inferenceCredentialHelper to an executable that prints a Bedrock bearer token to stdout at runtime.

When more than one credential is configured, the app uses the first one present in this order: bearer token, named profile, credential helper.

Set up AWS

These steps are performed once per AWS organization, regardless of which authentication approach you chose. You need an AWS account with permission to manage Bedrock model access and IAM Identity Center.

1. Enable Claude models in Bedrock

   In the Amazon Bedrock console, open Model access and request access to the Claude models you intend to deploy. Access is granted per region, so enable the models in the same region you will set as inferenceBedrockRegion.

2. Create an IAM Identity Center permission set

   Skip this step if you chose the bearer-token approach. The named-profile approach uses IAM Identity Center to issue per-user AWS credentials.

   In the IAM Identity Center console, create a permission set with an inline policy that allows Bedrock inference. The minimal policy is:

   {
     "Version": "2012-10-17",
     "Statement": [{
       "Effect": "Allow",
       "Action": [
         "bedrock:InvokeModel",
         "bedrock:InvokeModelWithResponseStream"
       ],
       "Resource": "*"
     }]
   }
   

   Set the permission set’s Session duration to between 8 and 12 hours. This value controls how long a user can run Cowork before needing to sign in to AWS again.

3. Federate Identity Center to your IdP (optional)

   If your organization uses Microsoft Entra ID, Okta, or another SAML identity provider, you can configure it as the identity source for IAM Identity Center so users sign in with their existing corporate credentials. The per-device steps on this page are unchanged. See Connect to an external identity provider in the AWS documentation.

4. Assign users to the permission set

   In IAM Identity Center, assign the permission set to the AWS account that hosts Bedrock, and add the users or groups who should have access.

5. Record the values you need for device configuration

   From the IAM Identity Center Settings page, note:

   • AWS access portal URL: of the form https://d-xxxxxxxxxx.awsapps.com/start (or your custom subdomain)
   • Identity Center region: the region where Identity Center is enabled, which may differ from your Bedrock region
   • AWS account ID: the 12-digit ID of the account where you enabled Bedrock
   • Permission set name: the name you gave the permission set above

Prepare devices

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

Bearer token

No per-device preparation is required. In the Amazon Bedrock console, generate an API key. The key’s underlying IAM principal must be allowed the bedrock:CallWithBearerToken action; without it, requests return an authorization error even though the key was created. You will place the key in the managed configuration in the next section.

Named profile

Each device needs AWS CLI v2 installed and an AWS config file that defines the named profile.

You do not need users to run aws configure sso interactively. That command is a wizard that writes a profile stanza to ~/.aws/config (macOS) or %USERPROFILE%\.aws\config (Windows), and you can distribute that file directly through your device-management tooling instead. A profile that uses IAM Identity Center looks like:

[profile claude-cowork]
sso_session = corp
sso_account_id = 123456789012
sso_role_name = ClaudeCoworkAccess
region = us-west-2

[sso-session corp]
sso_start_url = https://d-xxxxxxxxxx.awsapps.com/start
sso_region = us-east-1
sso_registration_scopes = sso:account:access

The recurring action for users is aws sso login --profile claude-cowork, which opens a browser for IAM Identity Center sign-in and caches a token under ~/.aws/sso/cache/. To remove that manual step, some organizations deploy a launcher that runs aws sts get-caller-identity as a probe, falls back to aws sso login if it fails, and then opens Claude.

If your AWS configuration files are not at the default location, set inferenceBedrockAwsDir to the directory that contains them.

Configure the app

With AWS set up and devices prepared, add the Bedrock keys to your managed configuration. The easiest path is to enter these values in the in-app configuration window (Developer → Configure third-party inference) on an evaluation device and export; see Installation and setup. The examples below show the raw profile formats.

macOS (.mobileconfig)

A .mobileconfig profile delivered by Jamf, Kandji, or any Apple MDM writes these keys to /Library/Managed Preferences/com.anthropic.claudefordesktop.plist.

<key>inferenceProvider</key>
<string>bedrock</string>
<key>inferenceBedrockRegion</key>
<string>us-west-2</string>
<key>inferenceBedrockProfile</key>
<string>claude-cowork</string>
<key>inferenceModels</key>
<string>["us.anthropic.claude-sonnet-4-20250514-v1:0"]</string>

Windows (.reg / Group Policy)

A .reg file or Group Policy preference writes these values under HKLM\SOFTWARE\Policies\Claude.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Claude]
"inferenceProvider"="bedrock"
"inferenceBedrockRegion"="us-west-2"
"inferenceBedrockProfile"="claude-cowork"
"inferenceModels"="[\"us.anthropic.claude-sonnet-4-20250514-v1:0\"]"

Windows (Intune)

Deploy the .reg content above as an Intune Platform script or Remediation that writes to HKLM\SOFTWARE\Policies\Claude. The app reads machine policy at this path; see Installation and setup for the full precedence rules.

$base = "HKLM:\SOFTWARE\Policies\Claude"
New-Item -Path $base -Force | Out-Null
Set-ItemProperty -Path $base -Name inferenceProvider       -Value "bedrock"
Set-ItemProperty -Path $base -Name inferenceBedrockRegion  -Value "us-west-2"
Set-ItemProperty -Path $base -Name inferenceBedrockProfile -Value "claude-cowork"
Set-ItemProperty -Path $base -Name inferenceModels         -Value '["us.anthropic.claude-sonnet-4-20250514-v1:0"]'

The example above shows the named-profile approach. For the bearer-token approach, replace inferenceBedrockProfile with inferenceBedrockBearerToken.

Configuration keys

The full set of Bedrock keys is below. Set inferenceProvider to bedrock, supply a region, and provide exactly one credential source.

Setting	Required	Description
AWS region inferenceBedrockRegion	Yes	AWS region for the Bedrock runtime endpoint, for example us-west-2 or us-gov-west-1.
AWS bearer token inferenceBedrockBearerToken	One credential source	Bedrock API key generated from the Amazon Bedrock console.
AWS profile name inferenceBedrockProfile	One credential source	AWS named profile from the device’s AWS config and credentials files.
AWS config directory inferenceBedrockAwsDir	No	Absolute path to the directory containing the AWS config and credentials files, if not the default ~/.aws.
Bedrock base URL inferenceBedrockBaseUrl	No	Override the public regional endpoint, for example with a PrivateLink VPC interface endpoint. Must be https://.

You must also set inferenceModels to a list of Bedrock inference-profile IDs, for example us.anthropic.claude-sonnet-4-20250514-v1:0. See the Configuration reference.

What users experience

The first-launch and re-authentication behavior depends on the authentication approach.

Approach	First launch	Re-authentication
Bearer token	Cowork opens directly; no user action.	Never, until you rotate the key in the managed profile.
Named profile	Cowork opens directly if the AWS SSO cache is fresh. If not, the first request fails and the user must run aws sso login in a terminal.	When the IAM Identity Center session expires (the permission set’s session duration).

When a named-profile session has expired, requests fail with ExpiredTokenException from AWS, and the user runs aws sso login again.

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.