Amazon Bedrock Authentication

Managed deployment

Self-hosted

Amazon Bedrock accepts an API key, AWS access keys, or an IAM role. The Authentication Method field, shown under Custom setup on the AgentQ Settings page once Amazon Bedrock is selected, selects between them, and each reveals only the fields it needs. This page explains what each method expects and what your AWS administrator has to set up. To connect the provider, see Add Integration.

Authentication Methods

Method	What Qualytics stores	Use it when
API Key (bearer token)	The Bedrock API key, encrypted	You have a Bedrock API key and want the shortest setup
AWS Access Keys	The Secret Access Key, encrypted; the Access Key ID is stored as ordinary configuration	You authenticate with a long-lived IAM user credential
IAM Role (pod identity or assumed role)	Nothing	You want no AWS credential stored in Qualytics at all

IAM Role is the recommended method wherever it is available. Qualytics stores no secret: it authenticates with an AWS IAM identity, so there is nothing to rotate and nothing to leak.

How IAM Role Authentication Works

Qualytics runs with an AWS identity of its own: an IAM role attached to the pods that run the platform. Under IAM Role authentication, the Role ARN field decides what happens next:

Left blank, Qualytics calls Bedrock directly as the identity it already runs as.
Filled in, Qualytics assumes that role first and calls Bedrock as the assumed role.

Which one you want follows from where Bedrock lives relative to where Qualytics runs.

Self-hosted, Bedrock in the same AWS account

Leave Role ARN blank. Qualytics is already running inside your account under an identity you control, so all your AWS administrator has to do is grant that identity permission to invoke Bedrock:

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

Narrow the Bedrock Resource to the model or inference-profile ARNs you intend to use if you prefer. There is no second role and no trust policy in this setup.

The aws-marketplace statement matters the first time your AWS account uses a model that AWS sells through AWS Marketplace, which includes the Anthropic Claude models. That first call subscribes the account to the model, and AWS makes it as the identity calling Bedrock. Without these two actions, Bedrock refuses the call even though bedrock:InvokeModel is granted. Once the account is subscribed, later calls no longer need them. You can leave the statement out if an AWS administrator has already enabled every model you plan to use, for example by invoking each one once from the Bedrock console.

If Qualytics has no AWS identity yet, choose one of these deployment options:

EKS Pod Identity (recommended): Enable the EKS Pod Identity Agent, create an IAM role that trusts pods.eks.amazonaws.com, and associate it with the ServiceAccount used by the Qualytics application pods.
IAM Roles for Service Accounts (IRSA): Create an IAM role that trusts your cluster's OIDC provider and annotate the same ServiceAccount with that role ARN.
Node instance role: Grant the permissions to the EKS node role. This is the simplest option, but every pod on those nodes receives the same access.

The AWS workload identity setup provides the Helm values and trust-policy examples for the first two options.

Bedrock in a different AWS account

Bedrock has no cross-account invoke: the call has to be made with credentials belonging to the account that has model access. Your AWS administrator creates a role in that account, gives it the policy above, and trusts the identity Qualytics runs as:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "<the identity Qualytics runs as>" },
    "Action": "sts:AssumeRole",
    "Condition": { "StringEquals": { "sts:ExternalId": "<your external id>" } }
  }]
}

Enter that role's ARN in Role ARN, and the same value in External ID if you used one.

Managed deployments

This is the cross-account case above: Qualytics runs in a Qualytics AWS account and your Bedrock models are in yours, so a role in your account is the only way in. Role ARN is required. A blank value would select a Qualytics-owned AWS identity, so the configuration is refused when you save it.

Ask your Qualytics account manager for the AWS identity that AgentQ runs as before you start. Qualytics does not display it on the Settings page; it appears only in the message of a save that fails because the role cannot be assumed (see When Validation Fails). Ask for it by name. It is a separate identity from the base role that datastore connections trust under IAM Role authentication, so do not reuse that ARN. Create the target role with the AgentQ identity as the Principal of its trust policy, enter the role's ARN, and save the configuration. Use the External ID as well: it prevents a role that trusts Qualytics from being assumed on behalf of another customer.

Things Worth Knowing

Trust the role ARN, not the session ARN. The principal in a trust policy is arn:aws:iam::…:role/name. An arn:aws:sts::…:assumed-role/name/session string identifies one session and will not work.
Assumed sessions last at most one hour. Qualytics' own identity is already a role, so assuming another one is role chaining, which AWS caps at 60 minutes regardless of the role's MaxSessionDuration. Qualytics refreshes credentials before they expire; there is nothing to configure.
The External ID only matters across accounts. It protects a role that trusts a third party from being assumed on someone else's behalf. It is accepted but pointless when Qualytics and Bedrock are in the same account.
Switching to IAM Role clears any stored credential. Moving an existing Bedrock configuration from API Key or AWS Access Keys to IAM Role discards the encrypted secret rather than leaving it in place.
Configurations saved before this release keep working. A Bedrock integration set up under the earlier Assume IAM Role (cross-account) option now reads IAM Role, with the Role ARN and External ID it already had. It still assumes that role, because its Role ARN is filled in. Nothing has to be reconnected or re-entered.

When Validation Fails

Qualytics tests the provider before saving. When AWS refuses that test under IAM Role authentication, the message ends with the AWS identity that was refused and what to change on it. Which identity it names depends on which of the two calls failed.

The Bedrock call was refused. With Role ARN blank, the message names the identity Qualytics runs as:

Could not validate the LLM configuration: Validation request to bedrock:… failed: … AccessDeniedException …
  — AWS caller identity: arn:aws:sts::123456789012:assumed-role/prod-nodes/i-0abc.
    Grant bedrock:InvokeModel and bedrock:InvokeModelWithResponseStream to arn:aws:sts::…

With a Role ARN set, the role was assumed successfully and Bedrock then refused the call made as that role. The message names the role, because the role's permissions are what is missing. Its trust policy already works and needs no change.

  — Qualytics assumed arn:aws:iam::123456789012:role/qualytics-bedrock, and Bedrock refused the request
    made as that role. Grant bedrock:InvokeModel and bedrock:InvokeModelWithResponseStream to …

If AWS's own text mentions aws-marketplace:ViewSubscriptions and aws-marketplace:Subscribe, the account has not yet subscribed to the model (see Self-hosted, Bedrock in the same AWS account). The message then names those two actions instead of the Bedrock ones. Grant them to the identity it names, or have an AWS administrator enable the model once from the Bedrock console. AWS can take a few minutes to apply the subscription, so wait before saving again.

The role could not be assumed. If its trust policy does not allow Qualytics yet, or the External ID does not match, the message names the identity Qualytics runs as and says that the configured role must trust it:

  — ambient AWS identity: arn:aws:sts::…:assumed-role/…. The configured role arn:aws:iam::…:role/… must trust that identity.

Put the role form of that identity (arn:aws:iam::…:role/name, not the assumed-role session ARN) in the trust policy's Principal. Check the External ID, then save again.

A message saying Qualytics could not resolve any AWS credentials means the platform has no AWS identity. On a self-hosted deployment, complete one of the workload-identity options above.

A failure that is not an AWS permission problem, such as a timeout or an unknown model ID, carries no identity note, because changing IAM will not fix it.