Docs / Deploy / Model keys

Use your own model provider keys — AWS

Run agents on your own model provider account, including AWS Bedrock inside your own AWS account.

Your organization can run its agents on your own model provider account rather than ours. You supply the credential, the provider bills you directly, and with AWS Bedrock the inference itself runs inside your own AWS account, in an AWS region you pick.

An org admin sets this up once, in Settings → Model keys. It applies to every agent in your organization.

What this covers

Setting a model key changes two things: whose account pays for inference, and which endpoint serves it. For AWS Bedrock it also changes where the inference physically runs.

It doesn't change which models you can pick, how your agents are built, or where the rest of your data lives. Your organization's data stays on the Mindset AI deployment you're on.

Supported providers

Bedrock is the one that works differently, because it doesn't use a bearer key at all. It has its own section below.

Before you start

You'll need to be an org admin. Model keys are configured in the Mindset AI console only. There's no API, no SDK method and no agent tool for setting or reading them, which is deliberate: it removes a whole class of credential exposure rather than guarding against it.

You'll also want the provider account ready first, since the console asks you to paste the credential in one go.

Set a provider key

For Anthropic, OpenAI, Google and open-weights hosts, the flow is the same.

1. Go to Settings → Model keys. You'll see a row for every supported provider, whether or not you've configured it.
2. On the provider you want, choose Set key. Each row links straight to where that provider's console issues keys.
3. Paste the credential and give it a label, something like "Production Anthropic". The label is how you tell your keys apart later.
4. Save.

We run a quick check against the provider when you save. If it succeeds, the row shows as verified. If the provider is slow or unreachable, the key is still saved and the row shows as unverified with a note about what the check failed on. An unverified key still works at runtime, so a provider outage never blocks you from saving.

You'll never see the credential again after you save it. More on that below.

Set up AWS Bedrock

Bedrock runs Claude models on your own AWS account. Rather than handing us a long-lived AWS access key, you create a role in your account that trusts ours, and we assume it for the length of each session.

Create the role in your AWS account

In the AWS account you want the inference billed to, create an IAM role with:

• A trust policy naming the Mindset AI principal, with an external ID you choose.
• A permissions policy scoped to bedrock:InvokeModel.

The external ID is a shared secret between your trust policy and your Mindset AI configuration. It's what stops anyone else persuading us to assume your role on their behalf, so pick something unguessable and treat it as a credential.

Your trust policy will look roughly like this:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "<ask your Mindset AI contact for the current principal ARN>"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "your-chosen-external-id"
        }
      }
    }
  ]
}

Make sure the models you want are enabled on Bedrock in the region you're going to pick. Bedrock model access is granted per region in your own AWS console.

Add it in Mindset AI

1. Go to Settings → Model keys and choose Set key on the Bedrock row.
2. Enter the role ARN from the step above.
3. Enter the external ID your trust policy requires.
4. Enter the AWS region you want inference to run in, for example eu-west-1 or us-east-1. There's no default and nothing is pre-selected, so you have to state it.
5. Confirm the acknowledgement about where your inference will run.
6. Save.

The region field is free text rather than a dropdown. That's on purpose. A curated list would imply we'd vetted those regions for your compliance position, and we haven't. You know your requirements and we don't, so the choice is yours to state. An unrecognized region is refused rather than quietly replaced with a default.

What we do with the role

Each time your agents need to run, we make a single sts:AssumeRole call against your role and get back temporary credentials that last one hour. We cache them until shortly before they expire, then get fresh ones. Nothing long-lived is ever stored.

In your own CloudTrail, these appear under the session name mindset-bedrock, so you can audit exactly what we did and when.

We only ever assume the role you named. The permissions your role grants are the outer limit of what we can do in your account.

Where your data goes

With Bedrock configured, your organization has two answers to "where does our data go", and they're both true:

• Your inference runs on your AWS account, in the AWS region you named.
• Everything else stays on the Mindset AI deployment your organization lives on.

Those can be different places, and that's the point of the feature.

A few things to be clear about, because they're the questions a compliance review will ask.

The region is your choice, not a boundary we police. We don't keep a list of which AWS regions are acceptable for which customers, and we don't check your choice against one. We're not in a position to know your legal requirements, and a list that looked authoritative would be worse than no list at all. What we do instead: you pick the region explicitly, you acknowledge it, we record who made that choice and when, and the region stays visible on the panel afterwards so whoever inherits your organization can see it without re-running the setup.

Retrieval runs on a separate key. Searching your knowledge for relevant context is a different call from generating a reply, and it uses a different credential. You can set an embedding key for your own organization under Settings → Embedding keys.

That key is OpenAI only, and the embedding model is fixed at text-embedding-3-large. Neither is arbitrary. Anthropic has no embeddings API at all, and Google and Bedrock embed into a different vector space, not a wider or narrower one, so results from a different provider wouldn't be comparable to what's already stored. Your whole knowledge base is indexed into one space, and every search has to land in that same space to mean anything.

So configuring Bedrock covers your chat and completion traffic. It doesn't move your retrieval traffic to AWS, and no setting available today would.

One key per organization, across every Environment. A model key belongs to your organization, not to a particular Environment within it. If you keep separate Environments for testing and production, they share the same key. There's no way today to run a sandbox key in one and a production key in another.

Replacing and removing a key

We can't show you a key back. Not in the console, not through an API, not in a log line, not in an error message. Once you save it, the value has left our servers and only a reference remains. This applies to every provider, and to your Bedrock external ID.

That means replacing a key means typing the whole thing again. The form is never pre-filled, because there's nothing to pre-fill it with. It's friction, and it's the same property that makes the credential safe.

Removing a key takes effect immediately. For Bedrock, we also drop any cached session, so a removal is a real revocation rather than one that takes effect an hour later.

Be careful with this one. If you remove your only configured key, your organization stops being able to run agents at that moment. Admins will see a message pointing them back to Settings → Model keys. Anyone else will see a note saying the organization isn't set up yet, rather than a chat box that accepts a message and then fails.

Where this is available

Model keys, including Bedrock, are available on our integration and EU deployments today. US production is planned, and model keys will be available there when it launches.

This is about where your Mindset AI organization is hosted, which is separate from the AWS region you choose for Bedrock inference. You can run Bedrock inference in any AWS region from either of the deployments above.

Troubleshooting

The Bedrock row saved but shows as unverified. Our check couldn't assume your role. The note on the row names what failed. The usual causes are a trust policy that doesn't name the Mindset AI principal, an external ID that doesn't match what you entered, or a role without bedrock:InvokeModel.

Agents fail with an assume-role error after working fine. Something changed on the AWS side. Check the role still exists, its trust policy is intact, and the external ID hasn't been rotated in AWS without being updated in Mindset AI.

A model isn't available. Bedrock model access is granted per region in your AWS account. Check that the model is enabled in the region you configured.

Error messages never contain your credentials. If you're reporting a problem to us, our errors name the field that failed and the provider's own refusal, never the value. You can share them safely.

An admin needs to change this and can't find it. Model keys are org-admin only and live under Settings → Model keys. Members can't see the panel.