Description
When a harness is deployed with --memory-mode managed, the CDK L3 construct (@aws/agentcore-cdk) generates an IAM policy for the AgentCoreManagedMemory statement that uses a harness_ prefix in the memory resource ARN. However, the AgentCore service creates the managed memory resource without this prefix, causing all memory data-plane operations to fail with AccessDeniedException.
The construct builds the IAM resource glob as:
arn:aws:bedrock-agentcore:<region>:<account>:memory/harness_<projectName>_<harnessName>*
But the service names the actual memory resource as:
arn:aws:bedrock-agentcore:<region>:<account>:memory/<projectName>_<harnessName>-<suffix>
The mismatch means the harness role has zero memory data-plane permissions against its own managed memory. This is a security-irrelevant failure (the role is under-scoped, not over-scoped), but it makes managed memory completely non-functional on any fresh deployment.
The root cause is in AgentCoreHarnessRole (source: src/cdk/constructs/components/primitives/harness/AgentCoreHarnessRole.ts):
const MANAGED_MEMORY_NAME_PREFIX_LENGTH = 34;
// ...
const memoryNamePrefix = `harness_${physicalName}`.slice(0, MANAGED_MEMORY_NAME_PREFIX_LENGTH);
role.addToPolicy(new iam.PolicyStatement({
sid: 'AgentCoreManagedMemory',
actions: [...HARNESS_MEMORY_DATA_PLANE_ACTIONS],
resources: [`arn:${partition}:bedrock-agentcore:${region}:${accountId}:memory/${memoryNamePrefix}*`],
}));The code prepends harness_ to the physical name before building the resource ARN, but the service does not use that prefix when naming the managed memory. The bedrock-agentcore-sdk-typescript repo confirms this in PR #139 (commit 2776a1c), which documents that memory IDs are generated as {name}-{suffix}, not harness_{name}-{suffix}.
Steps to Reproduce
1. Create a project with a harness using managed memory.
agentcore create --name MyProject --no-agent
cd MyProject
agentcore add harness --name MyHarness --model-id global.anthropic.claude-sonnet-4-6 --memory-mode managed
2. Deploy.
3. Invoke the harness.
agentcore invoke --prompt "Hello, remember my name is Alice."
4. Observe the error.
Error: An error occurred (AccessDeniedException) when calling the ListEvents operation:
User: arn:aws:sts::xxxxxxxxxxxx:assumed-role/MyProject_MyHarness/BedrockAgentCore-...
is not authorized to perform: bedrock-agentcore:ListEvents on resource:
arn:aws:bedrock-agentcore:us-west-2:xxxxxxxxxxxx:memory/MyProject_MyHarness-ABCDef1234
because no identity-based policy allows the bedrock-agentcore:ListEvents action
5. Inspect the IAM policy on the harness role.
aws iam get-role-policy \
--role-name MyProject_MyHarness \
--policy-name <DefaultPolicyLogicalId>
The AgentCoreManagedMemory statement's Resource is:
arn:aws:bedrock-agentcore:us-west-2:xxxxxxxxxxxx:memory/harness_MyProject_MyHarnes*
(Note: truncated to 34 chars and includes the incorrect harness_ prefix.)
The actual memory resource is:
arn:aws:bedrock-agentcore:us-west-2:xxxxxxxxxxxx:memory/MyProject_MyHarness-ABCDef1234
These do not match. The policy denies all memory operations.
Expected Behavior
The IAM policy resource ARN should match the actual memory resource naming pattern used by the AgentCore service. After deploying with --memory-mode managed, the harness should be able to invoke memory operations (ListEvents, CreateEvent, etc.) without manual IAM intervention.
Actual Behavior
Every memory data-plane operation fails with AccessDeniedException because the IAM resource ARN pattern includes a harness_ prefix that the service does not use when naming the managed memory resource.
CLI Version
0.27.0
Operating System
macOS
Additional Context
@aws/agentcore-cdk: 0.1.0-alpha.45aws-cdk-lib: ~2.261.0- Node.js: v26.7.0
- Region: us-west-2
- Project type: Harness with
--memory-mode managed, no code-based agent
The code comment in AgentCoreHarnessRole.js (lines 40–50) acknowledges that the service truncates the physical name but incorrectly states the naming pattern as harness_<physicalName>_<hash>. The actual pattern observed in production is <physicalName>-<suffix> with no harness_ prefix. This is corroborated by the bedrock-agentcore-sdk-typescript codebase (PR #139, commit 2776a1c) which documents that createOrGetMemory looks up memories by matching IDs that start with {name}-.
The managed memory feature was ungated in aws/agentcore-cli#1620, which depends on aws/agentcore-l3-cdk-constructs#289 for the CDK IAM policy generation. The harness-managed-memory e2e test in that PR apparently passed, suggesting either the test did not exercise memory operations that hit the IAM check, or the service's memory naming convention changed after the PR was tested.
This bug affects every new harness deployment with managed memory. The harness will successfully provision but fail on first invoke with no clear indication of what went wrong unless the user inspects IAM policies manually.
Description
When a harness is deployed with
--memory-mode managed, the CDK L3 construct (@aws/agentcore-cdk) generates an IAM policy for theAgentCoreManagedMemorystatement that uses aharness_prefix in the memory resource ARN. However, the AgentCore service creates the managed memory resource without this prefix, causing all memory data-plane operations to fail withAccessDeniedException.The construct builds the IAM resource glob as:
But the service names the actual memory resource as:
The mismatch means the harness role has zero memory data-plane permissions against its own managed memory. This is a security-irrelevant failure (the role is under-scoped, not over-scoped), but it makes managed memory completely non-functional on any fresh deployment.
The root cause is in
AgentCoreHarnessRole(source:src/cdk/constructs/components/primitives/harness/AgentCoreHarnessRole.ts):The code prepends
harness_to the physical name before building the resource ARN, but the service does not use that prefix when naming the managed memory. Thebedrock-agentcore-sdk-typescriptrepo confirms this in PR #139 (commit2776a1c), which documents that memory IDs are generated as{name}-{suffix}, notharness_{name}-{suffix}.Steps to Reproduce
1. Create a project with a harness using managed memory.
agentcore create --name MyProject --no-agent cd MyProject agentcore add harness --name MyHarness --model-id global.anthropic.claude-sonnet-4-6 --memory-mode managed2. Deploy.
3. Invoke the harness.
agentcore invoke --prompt "Hello, remember my name is Alice."4. Observe the error.
5. Inspect the IAM policy on the harness role.
The
AgentCoreManagedMemorystatement's Resource is:(Note: truncated to 34 chars and includes the incorrect
harness_prefix.)The actual memory resource is:
These do not match. The policy denies all memory operations.
Expected Behavior
The IAM policy resource ARN should match the actual memory resource naming pattern used by the AgentCore service. After deploying with
--memory-mode managed, the harness should be able to invoke memory operations (ListEvents, CreateEvent, etc.) without manual IAM intervention.Actual Behavior
Every memory data-plane operation fails with
AccessDeniedExceptionbecause the IAM resource ARN pattern includes aharness_prefix that the service does not use when naming the managed memory resource.CLI Version
0.27.0
Operating System
macOS
Additional Context
@aws/agentcore-cdk: 0.1.0-alpha.45aws-cdk-lib: ~2.261.0--memory-mode managed, no code-based agentThe code comment in
AgentCoreHarnessRole.js(lines 40–50) acknowledges that the service truncates the physical name but incorrectly states the naming pattern asharness_<physicalName>_<hash>. The actual pattern observed in production is<physicalName>-<suffix>with noharness_prefix. This is corroborated by thebedrock-agentcore-sdk-typescriptcodebase (PR #139, commit 2776a1c) which documents thatcreateOrGetMemorylooks up memories by matching IDs that start with{name}-.The managed memory feature was ungated in aws/agentcore-cli#1620, which depends on
aws/agentcore-l3-cdk-constructs#289for the CDK IAM policy generation. Theharness-managed-memorye2e test in that PR apparently passed, suggesting either the test did not exercise memory operations that hit the IAM check, or the service's memory naming convention changed after the PR was tested.This bug affects every new harness deployment with managed memory. The harness will successfully provision but fail on first invoke with no clear indication of what went wrong unless the user inspects IAM policies manually.