Skip to main content
Version: 26.2

Bedrock setup

Co-Scientist runs Claude inference in your own AWS account through Amazon Bedrock. Before you install the Helm charts, configure your AWS account so the Co-Scientist pods can invoke the models: enable model access, grant the IAM permissions the agent backend needs, and — if you use sandboxed sessions — create an AgentCore runtime.

Complete this page after the prerequisites and before installation.

note

In agent backend versions after 1.14.1, including the version shipped with Enterprise 26.2, Co-Scientist uses a single model for text inference. Earlier agent backends route text inference across separate primary, fast, and deep models and need model access and IAM permissions for each. See the 26.1 documentation if your deployment pins one of those.

Prerequisites​

Before you begin, make sure you have:

  • An AWS account with Amazon Bedrock available in the region you plan to use.
  • Permission to modify IAM policies and to enable Bedrock model access in that account.
  • The AWS CLI v2.34.1 or later installed locally.
  • If you enable sandboxed AgentCore sessions: an Amazon ECR registry in the same account, a local container tool (Docker or Podman), and credentials for cr.seqera.io.

Enable model access​

Enable access to the models Co-Scientist uses in your chosen region. See the AWS documentation for adding or removing access to Amazon Bedrock foundation models.

PurposeModel IDRequired
Text inferenceanthropic.claude-opus-4-8Always
Text embeddingsamazon.titan-embed-text-v2:0Only when documentation semantic search is enabled

Co-Scientist uses a single model for all text inference. Earlier releases routed requests across separate primary, fast, and deep models. That tiering was removed, and only the one model above needs access.

Configure the embedding model separately from chat inference, in bedrock.embeddings.model. The chart default is amazon.titan-embed-text-v2:0. Leave embeddings.provider unset to disable documentation search and skip this model entirely.

note

The first time an account requests access to Anthropic models, AWS may ask you to submit use case details before approving access. Approval is not instant — request access before you schedule your installation.

Activate the Marketplace subscription​

Models served through AWS Marketplace can only be invoked while an active agreement exists for them. AWS creates the agreement automatically on first use, so activate each model once before you install:

If you skip this step, Co-Scientist's first inference call fails even though model access is enabled.

Use an inference profile for the Claude model​

Claude Opus 4.8 is not available for on-demand throughput, and you must invoke it through an inference profile. Use the global profile:

global.anthropic.claude-opus-4-8

Supply its full ARN to the agent backend as bedrock.inference.anthropicModel when you install the chart:

arn:aws:bedrock:<region>:<account-id>:inference-profile/global.anthropic.claude-opus-4-8

Grant Bedrock inference permissions​

Attach the following policy to the IAM role or user that the agent backend pods use:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"bedrock:InvokeModel",
"bedrock:InvokeModelWithResponseStream"
],
"Resource": [
"arn:aws:bedrock:::foundation-model/anthropic.claude-opus-4-8",
"arn:aws:bedrock:<region>:<account-id>:inference-profile/global.anthropic.claude-opus-4-8",
"arn:aws:bedrock:::foundation-model/amazon.titan-embed-text-v2:0"
]
}
]
}

Replace <region> and <account-id> with your own values. Foundation model ARNs are not region-scoped, so they have no region or account component. Both the inference profile and the foundation model it routes to must be listed, because a request through a profile is authorized against both.

Drop the amazon.titan-embed-text-v2:0 entry if you leave documentation semantic search disabled. If you override bedrock.embeddings.model with a different embedding model, list that model's ARN instead.

caution

A model missing from this policy fails with an access-denied error at runtime, not at install time. Verify the policy before you hand the deployment over.

Set up the AgentCore runtime​

Complete this section only if you enable sandboxed AgentCore sessions by setting sandbox.provider: bedrock. Leave sandbox.provider unset to run without sandboxed sessions and skip this section entirely — Bedrock AgentCore is the only sandbox provider currently supported.

Copy the runtime image into your ECR​

Seqera publishes the AgentCore runtime image. Copy it into a repository in your own Amazon ECR registry, in the same account as the runtime.

caution

The image must be stored in your own ECR registry. AgentCore cannot pull it from Seqera's container registry — it expects to resolve images through AWS IAM within your account.

The image is built for arm64. Pull it, retag it for your registry, and push:

podman pull --arch arm64 cr.seqera.io/ai/agent-backend/bedrock-agentcore-runtime:<tag>

aws ecr get-login-password --region <region> \
| docker login --username AWS --password-stdin <account-id>.dkr.ecr.<region>.amazonaws.com

docker tag cr.seqera.io/ai/agent-backend/bedrock-agentcore-runtime:<tag> \
<account-id>.dkr.ecr.<region>.amazonaws.com/agent-backend/bedrock-agentcore-runtime:<tag>

docker push <account-id>.dkr.ecr.<region>.amazonaws.com/agent-backend/bedrock-agentcore-runtime:<tag>

Pin a specific dated tag rather than latest. Contact Seqera for the tag matching your deployment.

Create the runtime​

  1. In the AWS console, create a new AgentCore runtime with the Host agent or tool option.

  2. Set its source to the image in your ECR registry, and accept the defaults for the remaining options.

  3. Copy the runtime ARN. It looks like this:

    arn:aws:bedrock-agentcore:<region>:<account-id>:runtime/<name>-<id>
  4. Supply that ARN to the agent backend as bedrock.sandbox.runtimeArn when you install the chart.

note

Creating the runtime requires the identity you use for setup to allow bedrock-agentcore:CreateAgentRuntime and bedrock-agentcore:ListAgentRuntimes. This is separate from the runtime-invocation policy below, which applies to the agent backend pods. Service control policies or permissions boundaries in your organization can block these actions even when your own role allows them.

Grant runtime invocation permissions​

Attach the following policy to the IAM role or user that the agent backend pods use:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"bedrock-agentcore:InvokeAgentRuntime",
"bedrock-agentcore:InvokeAgentRuntimeCommand",
"bedrock-agentcore:InvokeAgentRuntimeForUser",
"bedrock-agentcore:InvokeAgentRuntimeWithWebSocketStream",
"bedrock-agentcore:InvokeAgentRuntimeWithWebSocketStreamForUser"
],
"Resource": [
"arn:aws:bedrock-agentcore:*:<account-id>:runtime/*",
"arn:aws:bedrock-agentcore:*:<account-id>:runtime/*/runtime-endpoint/*"
]
}
]
}

Provide credentials to the pods​

Bedrock authentication uses AWS IAM credentials. No API key secret is needed for the Bedrock path.

MethodWhen to use
EKS Pod IdentityRecommended. Associates the IAM role with the agent backend's Kubernetes service account, with no long-lived credentials in the cluster.
IAM roles for service accounts (IRSA)Supported alternative on clusters already standardized on IRSA.
Static AWS credentialsSupported, but stores long-lived keys in a Kubernetes Secret. Use only when neither role-based option is available.

When the pods must assume a role to reach Bedrock, set bedrock.default.assumeRoleArn to that role's ARN. Leave it empty when the pods already hold credentials for the target account. Per-service overrides — bedrock.inference.assumeRoleArn, bedrock.embeddings.assumeRoleArn, and bedrock.sandbox.assumeRoleArn — are available when each capability needs a different role.

For the full values file and the surrounding chart configuration, see Install Co-Scientist.

Next steps​