Use your own model provider keys on AWS

What this is

A model key is your org's credential for one model provider. An org admin sets it once, in Settings → Model keys. It covers every agent in the org that uses that provider's models, in every environment. There is one key per provider per org. You can't use one key in Test and a different one in Production.

A model key changes who pays for inference and where it runs. It doesn't change how your agents are built. Everything else your org holds stays on the Mindset deployment it lives on.

What you can set

Bedrock serves Claude models. Which ones depends on the region you pick.

On the shared Mindset deployment, your own agents need a model key to run. Mindset's built-in agents (Orca and the builders) run on keys Mindset provides, so you can start building before you add one. An admin can move the built-in agents onto your own key with the Run the built-in agents on our own key setting.

Before you start

• You need to be an org admin. Members can't see the Model keys tab.
• Have the provider account ready, because the form takes the whole credential in one go.
• Agents and MCP tools can't set or read model keys. An admin sets them in AMS, or through the SDK while signed in as an admin.

Set an Anthropic or OpenAI key

1. Go to Settings → Model keys. Every provider has a row, configured or not.
2. On the provider's row, choose Set key. The row links to the page in that provider's console where keys are issued.
3. Paste the key into Provider key. Add a Label if you want one, for example "Production Anthropic".
4. Choose Save key.

Mindset checks the key with the provider when you save. If the check passes, the row shows Verified. If the provider is slow or refuses, the key is still saved, the row shows Not verified, and the provider's reason appears on the row. A key that isn't verified is still used at runtime.

Set up AWS Bedrock

With Bedrock, you don't give Mindset an AWS access key. You create a role in your AWS account that trusts Mindset, and Mindset assumes it for an hour at a time.

Create the role in your AWS account

1. In Settings → Model keys, choose Set key on the AWS Bedrock row. The dialog shows the exact principal ARN your role must trust. Copy it.
2. In the AWS account you want billed, create an IAM role with:
   • A trust policy that lets that principal call sts:AssumeRole, on the condition of an external id you choose.
   • A permissions policy that allows bedrock:InvokeModel, bedrock:InvokeModelWithResponseStream and bedrock:GetFoundationModelAvailability.
3. In the AWS console, enable model access for the Claude models you want, in the region you will use. Bedrock grants model access per region.

The trust policy looks like this. Replace the principal with the ARN the dialog shows.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "AWS": "<the principal ARN shown in the Set key dialog>" },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": { "sts:ExternalId": "your-chosen-external-id" }
      }
    }
  ]
}

Treat the external id as a credential. It is what stops anyone else asking Mindset to assume your role on their behalf.

Add it in Mindset

1. In the same dialog, enter the Role ARN.
2. Enter the External id your trust policy requires.
3. Enter the AWS region, for example eu-west-1. There is no default. A region AWS doesn't offer Bedrock in is refused.
4. Tick the acknowledgement about where your inference will run.
5. Choose Save connection.

Once saved, the row shows the region your inference runs in. Some models are served inside that region. Others are routed by AWS across the region's geography, which can include other countries. Where that applies, the row lists the exact regions. Mindset records who saved the region and when, in the audit log.

What Mindset does with the role

When an agent needs a model, Mindset makes one sts:AssumeRole call against your role and gets credentials that last one hour. It reuses them until shortly before they expire. Nothing long-lived is stored. In your CloudTrail, these calls appear under the session name mindset-bedrock.

The permissions on your role are the limit of what Mindset can do in your account.

Where your data goes

With Bedrock set up, two things are true:

• Inference for chat and model calls runs on your AWS account, in the region you named (or that region's geography, per model).
• Everything else stays on the Mindset deployment your org lives on.

The region is your choice. Mindset doesn't keep a list of approved regions for your compliance position, and it doesn't check your choice against one.

Knowledge search uses a separate key. Embeddings always use OpenAI text-embedding-3-large, so a whole knowledge base sits in one vector space. You can set your own OpenAI embedding key in Settings → Embedding keys. Without one, the deployment's own embedding key is used. Bedrock doesn't move embedding traffic to AWS.

Replace or remove a key

Mindset never shows a saved key back to you, in AMS, the API or an error message. This includes the Bedrock external id. To replace a key, choose Replace and type the whole credential again. The form is never pre-filled.

Remove takes effect immediately. For Bedrock, the cached session is dropped as well. Any agent using that provider's models stops working on its next message until a new key is set.

If you remove the only key your agents use, they stop. Admins see "Your organization needs a model key" with a link back to Settings → Model keys. Members see that the organization isn't set up yet.

Where this is available

Model keys, including Bedrock, are available on the EU deployment and on self-hosted deployments. A US deployment is coming. This is about where your Mindset org is hosted. You can name any Bedrock region from either.

On a self-hosted deployment, your Bedrock role trusts the deployment's own task role. Ask whoever installed it for that ARN.

What can go wrong

• The Bedrock row saved but shows Not verified. Mindset couldn't assume your role. The note on the row says why. The usual causes: the trust policy doesn't name the principal from the dialog, the external id doesn't match, or the role lacks one of the three Bedrock permissions.
• Agents fail with an assume-role error after working fine. Something changed in AWS. Check the role still exists, its trust policy is intact, and the external id wasn't changed in AWS without being updated in Mindset.
• The row says no Bedrock models are available in your region. AWS serves none of Mindset's Bedrock models from that region. Choose a different one.
• A model isn't available. Check model access is enabled for that model in your region in the AWS console.
• You can't find Model keys. Only org admins see it.

Mindset's errors name the field that failed and the provider's refusal, never the credential. You can share them with us safely.