Bring agentic AI to your small business: Deploy Claude Cowork on third-party inference with Amazon Bedrock

Prerequisites

• An AWS account with permission to manage Amazon Bedrock model access and IAM Identity Center.
• Claude models enabled in Amazon Bedrock  in the AWS Region you plan to use for inference, for example us-west-2.
• A device running macOS or Windows that meets the Cowork requirements. You can confirm readiness without installing anything by running the Cowork readiness check  for your platform.
• For the recommended authentication path, IAM Identity Center enabled with a permission set that grants Amazon Bedrock inference, assigned to your Cowork users.

Step 1: Set up Amazon Bedrock and choose an authentication approach

• a. Open the IAM Identity Center console  in your IAM Identity Center home Region and choose Permission sets in the navigation pane.
• b. Choose Create permission set, select Custom permission set, and choose Next.
• c. Under Inline policy, paste a least-privilege policy that allows Bedrock inference. Replace the account ID, and adjust the model ID if you chose a different Claude model:json { "Version": "2012-10-17", "Statement": [ { "Sid": "InvokeClaudeOnBedrock", "Effect": "Allow", "Action": [ "bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream" ], "Resource": [ "arn:aws:bedrock:*:123456789012:inference-profile/global.anthropic.claude-sonnet-4-6", "arn:aws:bedrock:*::foundation-model/anthropic.claude-sonnet-4-6*" ] } ] } Because a cross-Region or global inference profile routes requests to the underlying foundation model in more than one Region, the policy grants access to both the inference-profile ARN and the foundation-model ARN, and uses a * in the Region position so the profile can route freely. To scope more tightly, replace the wildcards with the specific Regions your profile uses. If you prefer to grant the full set of invoke actions rather than list them, you can use bedrock:InvokeModel* as the single action.
• d. Choose Next. Set the Permission set name to BedrockInference (this exact name goes into the Claude Desktop configuration in Step 3). Optionally set the Session duration to cover a full working day (see the note in Step 4 about session length), then choose Next and Create.

Step 2: Install Claude Desktop

Step 3: Configure third-party inference

• Apply locally writes the configuration to the current machine and relaunches the app, which is ideal for evaluating on a single device.
• Export produces a .mobileconfig (macOS) or .reg (Windows) file you push through your device-management tooling.

Step 4: Sign in with AWS

1. The user clicks Sign in with AWS. The app opens the AWS access portal in the default browser with the authorization request prefilled and displays a short verification code.
2. The user confirms the code matches the one shown in the browser and approves the request. Because the browser flow runs on the host (outside the Cowork sandbox), it uses the user's existing identity-provider session, including any passkeys or security keys.
3. After approval, the app stores the IAM Identity Center token encrypted with the operating system's secure storage (Keychain on macOS, DPAPI on Windows), dismisses the sign-in page, and shows Cowork.

Note: The in-app Test connection button reports that the connection cannot be verified in this mode. This is expected for AWS sign-in and named-profile authentication and does not indicate a problem.

Step 5: Export and deploy to a fleet with MDM (optional)

Export the configuration

Deploy the configuration

• macOS: a .mobileconfig profile delivered by MDM lands in /Library/Managed Preferences/ automatically. Both the per-user (/Library/Managed Preferences/<user>/com.anthropic.claudefordesktop.plist) and machine (/Library/Managed Preferences/com.anthropic.claudefordesktop.plist) paths are read; where a key appears in both, the per-user value wins.
• Windows: a Group Policy Object or Intune profile writes to the registry policy paths. Both HKLM\SOFTWARE\Policies\Claude (machine) and HKCU\SOFTWARE\Policies\Claude (user) are read; where a key appears in both, the machine (HKLM) value wins.

Step 6: Deploy Claude for Small Business agents as organization plugins

Walkthrough: Deploy the Small Business plugin

Tip: To roll out a new version of the plugin later, update the contents in org-plugins/small-business/, then bump the version string (in version.json, or the version field of the manifest). Any change to that string triggers a re-sync on the next launch. Changing installationPreference takes effect the next time each user signs in.

Note on what you'll see in Contents, in the Plugins & skills section. The counts shown are per plugin and reflect the literal contents of the plugin folder, which may not match the "15 workflows + 15 skills" framing from the marketing materials. The small-business plugin packages its workflows, building-block skills, and router all as skill definitions and bundles its connectors, so its card shows Skills 31 and MCP servers 11 (QuickBooks, PayPal, HubSpot, Canva, Docusign, Slack, Stripe, Square, Gmail, Google Calendar, and Google Drive) with no Agents badge. If you have provisioned more than one plugin, each appears as its own entry in the Organization plugins list with its own counts.

Distribute the plugin to all your users

1. Lay the folder down with your MDM. Package the small-business folder (zipped) and have your MDM deliver it to the org-plugins path. In Jamf this is a package or a Files and Processes policy; in Microsoft Intune it's a Win32 app or a platform script; most other MDMs have an equivalent.
2. Run an install script from your MDM. Have the MDM run a script on each device that performs the clone-and-copy you tested manually (or unpacks a bundled archive). The MDM agent already runs with the administrator rights the org-plugins path requires.
3. Build an installer. Package the folder as a signed .pkg (macOS) or an .msi or script (Windows) that writes it to the org-plugins path, then push that installer through your MDM. This is the best option when you want clean versioning and a managed uninstall.

Govern the connectors your agents use

• On the plugin card (recommended for bundled connectors). In Plugins & skills, expand the plugin and use its TOOL POLICY section to mark each bundled connector's tools Allow, Ask, or Blocked. This is the quickest path for the connectors that ship with small-business.
• Under Connectors & extensions (for connectors you add yourself). Use this section to push additional admin-managed servers that aren't bundled with a plugin, and to decide how locked down the environment is.

1. In the left sidebar, choose Connectors & extensions.
2. Choose Add server and enter the connector's name and URL (for example, QuickBooks at https://ai-inc.quickbooks.intuit.com/v1/mcp), and turn on OAuth if the vendor uses it. These admin-managed servers appear in every user's connector list automatically and can't be removed by users.
3. For each server, set a per-tool policy so sensitive actions require a human: mark read-only tools Allow, mark anything that moves money or changes customer records Ask (the user must approve each time), and mark tools you never want used Blocked.
4. Choose Test this connection to confirm the server is reachable and your credentials work before you ship the configuration. The window lists the tools it discovered.
5. In the same window, choose Export and deploy the updated profile through your MDM, exactly as in Step 5.

Note: connector access is flexible, use the configuration that fits your environment. A plugin's bundled connectors are convenient defaults, but they are not the only way to give an agent data access, and you are not locked into them. The same MCP capability can be provided through any configuration that works for your setup: a remote MCP server (vendor-hosted or one you run on an internal gateway) or a local MCP server running on the device, and with whichever authentication method the provider supports, interactive OAuth, a static bearer token via headers, a short-lived token via a credential helper, or no auth for open servers. If a particular connector or auth method does not work in your environment, swap it for another: point the agent at a different endpoint, supply credentials a different way, or run the server locally. Because a managedMcpServers entry overrides a bundled plugin connector of the same name, you can always replace a bundled connector with your own definition without modifying the plugin. Configure and validate each connector with Test this connection before rolling it out.

Verify the deployment

Conclusion