Summary
e2e-tests/harness-custom-jwt.test.ts > invokes with bearer token successfully fails on the full-suite E2E run (shard 2/5) after #1624 made it a real positive assertion.
runtimeClientError: AccessDeniedException calling ListEvents:
... assumed-role/E2eHrnsJwt..._... is not authorized to perform:
bedrock-agentcore:ListEvents on resource: .../memory/harness_E2eHrnsJwt..._...
because no identity-based policy allows the bedrock-agentcore:ListEvents action
Root cause — test fixture, not the CDK
The CDK does grant bedrock-agentcore:ListEvents to the harness execution role — but only when memory is managed:
// agentcore-l3-cdk-constructs AgentCoreHarnessEnvironment.ts
const managedMemory = props.spec ? props.spec.memory?.mode !== 'disabled' : harness.managedMemory;
The test adds the harness with --no-memory, which the CLI maps to memory.mode: 'disabled' → the CDK correctly skips the ListEvents grant (disabled memory shouldn't need memory perms). But the harness still calls ListEvents on a service-managed memory at invoke time, so it 403s.
The passing harness suites (harness-bedrock/openai/gemini via harness-e2e-helper) all run with the default managed memory, which gets the grant and invokes successfully. The CUSTOM_JWT test was the only one using --no-memory.
Fix
Drop --no-memory from the CUSTOM_JWT harness so it uses managed memory like every other passing harness E2E. Test-only change; no shippable CLI or CDK behavior changes.
Summary
e2e-tests/harness-custom-jwt.test.ts > invokes with bearer token successfullyfails on the full-suite E2E run (shard 2/5) after #1624 made it a real positive assertion.Root cause — test fixture, not the CDK
The CDK does grant
bedrock-agentcore:ListEventsto the harness execution role — but only when memory is managed:The test adds the harness with
--no-memory, which the CLI maps tomemory.mode: 'disabled'→ the CDK correctly skips theListEventsgrant (disabled memory shouldn't need memory perms). But the harness still callsListEventson a service-managed memory at invoke time, so it 403s.The passing harness suites (
harness-bedrock/openai/geminiviaharness-e2e-helper) all run with the default managed memory, which gets the grant and invokes successfully. The CUSTOM_JWT test was the only one using--no-memory.Fix
Drop
--no-memoryfrom the CUSTOM_JWT harness so it uses managed memory like every other passing harness E2E. Test-only change; no shippable CLI or CDK behavior changes.