Amazon Bedrock Authentication

Amazon Bedrock is the one AgentQ provider that accepts more than one kind of credential. The Authentication Method field in the AgentQ Configuration dialog 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

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": "*"
  }]
}

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

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.

Create the target role, enter its ARN, and save the configuration. If its trust policy is not ready, the validation error names the exact Qualytics AWS identity that the role must trust. Copy that ARN into the trust policy's Principal value. 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.

When Validation Fails

Qualytics tests the provider before saving, and a failure under IAM Role authentication names the AWS identity resolved by the deployment:

Failed to validate API key for bedrock:… : AccessDeniedException …
  AWS caller identity: arn:aws:sts::123456789012:assumed-role/prod-nodes/i-0abc.
    Grant bedrock:InvokeModel to that identity.

That ARN is the useful part. Give it to your AWS administrator: it is the identity that needs the Bedrock grant, or the identity your cross-account role has to trust. When a Role ARN is set, the message also names the configured target role.

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.