AWS Agent Registry errors after the move to the agent-registry namespace

This runbook covers the AWS Agent Registry namespace migration. For where the registry sits in the wider platform, see Amazon Bedrock AgentCore: architecture and pricing. For help planning a registry migration with no downtime, book a consulting session.

Symptoms

The error shows up in code that worked unchanged until recently, and the registry itself reports no outage.

# Calls against the old namespace start failing
AccessDeniedException / ResourceNotFoundException
# ...on operations that previously succeeded under "bedrock-agentcore"

# Or an IAM denial because the policy still names the old namespace
User: arn:aws:sts::...:assumed-role/... is not authorized to perform:
agent-registry:<Action> because no identity-based policy allows it

Observable impact:

• Registry operations (publish, search, read records) suddenly error despite unchanged code
• IAM policies still allow actions on the old namespace, so new calls are rejected
• CLI scripts and SDK clients pointed at the old endpoint stop working
• Registry records created during preview are not visible under the new namespace until you migrate them

Cause

AWS Agent Registry launched publicly under the new agent-registry namespace. The service that previously ran in preview under the bedrock-agentcore namespace has moved, and the old namespace is being discontinued.

1. The namespace changed. Since the move, registry functionality responds under agent-registry, not bedrock-agentcore. Endpoints, IAM actions, SDK clients, and CLI scripts that reference the old name hit a service that no longer answers there the way it used to.
2. The old namespace is being discontinued. Support for the preview bedrock-agentcore namespace ends on an announced date. That exact date differs between AWS documentation pages, so do not assume one: check the date for your resources in the AWS migration guide. After it passes, the old namespace stops serving traffic.
3. Registry data does not migrate itself. Registries and records created under the old namespace must be moved to the new one separately. AWS provides migration tooling that extracts your data, transforms it to the new schema, and loads it into the new namespace. The data stays in the same account and region; only the namespace changes.

Rule of thumb: this is not a service outage or a problem with your agent’s permissions. It is a rename of the namespace your whole configuration references. Until all four layers (endpoints, IAM, SDK, CLI) and your data point at the new namespace, some calls will keep failing.

Fix

Step 1: Confirm the problem is the namespace

Check whether your IAM policies and client configuration still reference the old namespace. The IAM action prefix is the fastest signal.

# Look for the old namespace prefix in IAM policies
aws iam get-role-policy --role-name <your-agent-role> \
  --policy-name <policy-name> \
  --query 'PolicyDocument.Statement[].Action' --output json | grep -i "bedrock-agentcore"

If registry actions still carry the bedrock-agentcore prefix, you have found the cause. Continue through the steps.

Step 2: Update IAM policies to the new namespace

Change the registry actions in your agent and user execution-role policies from the old namespace prefix to agent-registry, keeping least privilege.

{
  "Effect": "Allow",
  "Action": [
    "agent-registry:<SpecificAction>"
  ],
  "Resource": "<exact-registry-or-record-arn>"
}

Grant specific actions on specific resources rather than a broad wildcard. A migration is a good moment to tighten over-broad permissions left over from preview.

Step 3: Update endpoints, SDK clients, and CLI scripts

Walk through everywhere your code points at the registry service and switch it to the new namespace: endpoints in configuration, the service name in SDK clients, and the calls in CLI scripts and infrastructure as code (for example, Terraform or Pulumi resources that reference the registry).

• Update the SDK client to target the service under the agent-registry namespace
• Review CLI scripts and pipelines where the service name or endpoint is hard-coded
• Update infrastructure-as-code definitions that create or reference registry resources

Step 4: Migrate registry data with the migration tooling

Preview registries and records will not appear under the new namespace on their own. Use the AWS migration tooling described in the migration guide to extract your data from the old namespace, transform it to the new schema, and load it into the new one. The data stays in the same account and region; only the namespace changes. Plan the migration before the discontinuation date, because after it the old namespace stops serving traffic.

Validation

Confirm registry operations work under the new namespace and your data is visible.

# A registry operation under the new namespace should succeed
# (the exact command depends on your SDK/CLI - what matters is that the target
# is agent-registry, not bedrock-agentcore)
aws sts get-caller-identity --region us-west-2
# Then run a registry read operation and confirm the migrated records are
# visible under the new namespace and a previously-rejected call now succeeds.

Expected: registry operations succeed under agent-registry, migrated records are visible, and calls previously rejected by IAM because of the old namespace now pass. If you publish or discover agents and tools through the registry across many teams, this is the same governance problem we describe in agent sprawl - one consistent registry is cheaper to run than several drifting ones.

Related

• Amazon Bedrock AgentCore: architecture, components, and pricing - where the registry fits among the components
• AWS Loom: governing AI agents on AWS - the registry and approval workflow within the platform
• AgentCore Gateway MCP OAuth 401 - a related authentication failure at the Gateway layer
• AWS Agent Registry migration guide (AWS documentation)