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.

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: in-app AWS sign-in, named profile, credential helper, bearer token. To remove ambiguity, set inferenceCredentialKind explicitly (see the Configuration reference).

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.

In the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon/), create a permission set with an inline policy that allows Bedrock inference. The minimal policy is:

```json theme={null}
{
  "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.

* **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.

In-app AWS sign-in

No per-device preparation is required. Distribute the four inferenceBedrockSso* keys in the managed configuration; the app shows a Sign in with AWS page on first launch, runs the IAM Identity Center device-authorization flow in the system browser, and stores the resulting token encrypted with the operating system's secure storage. See Sign in with AWS for Amazon Bedrock for the full flow.

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

When the cached IAM Identity Center token is missing or expired, the app prompts the user to sign in and runs aws sso login --profile claude-cowork itself, which opens the browser for IAM Identity Center sign-in and caches a token under ~/.aws/sso/cache/. Users can also run the command in a terminal; the app and the CLI share the same token cache. When the token can be refreshed silently, the app does so without prompting.

To run the login command, the app locates the AWS CLI by searching the launch environment's PATH, the user's login-shell PATH, and standard install locations such as /usr/local/bin and /opt/homebrew/bin on macOS. If your fleet installs the AWS CLI somewhere else, or you want every device to use one specific binary, set inferenceBedrockAwsCliPath to the absolute path of the executable.

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, open the in-app configuration window (Developer → Configure third-party inference) on an evaluation device. In the Connection section, set Inference provider to Bedrock and fill in the Bedrock credentials card with the values for whichever authentication approach you chose:

Under Models, add a Model list entry using the Bedrock inference-profile ID (required for profile or SSO auth; optional for bearer-token or credential-helper auth, which auto-discover), for example us.anthropic.claude-sonnet-4-20250514-v1:0.

Then click Export to produce a .mobileconfig (macOS) or .reg (Windows) file for your MDM. See Installation and setup for the export and deployment workflow.

Configuration keys

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

Set inferenceModels to a list of Bedrock inference-profile IDs, for example us.anthropic.claude-sonnet-4-20250514-v1:0. When using a bearer token or credential helper, Cowork auto-discovers available Claude models from your account if this is unset; for profile or SSO authentication, the list is required. Application-inference-profile ARNs and provisioned-throughput ARNs are also accepted; pair them with a labelOverride so the picker shows a readable name instead of the raw ARN. See the Configuration reference.

What users experience

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

If the app cannot locate the AWS CLI, it cannot drive the login itself; it instructs the user to install AWS CLI v2 and run aws sso login --profile <name> manually.

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.