Report privately through GitHub's advisory form, which is visible only to the maintainers until an advisory is published. Please do not open a public issue for a vulnerability.

Include what you need to demonstrate it — the request, the configuration, and what you got back. We will acknowledge within a week and tell you what we intend to do, including when we think the answer is "that is working as designed", with the reasoning.

This is a young project maintained by a small team. We do not run a bounty programme and cannot promise a fix window.

The design is easier to reason about — and to report bugs against — if these are explicit. All three are properties of AgentCore, not of this code.

The microVM is the boundary. An agent gets bypassPermissions by default, because there is nobody in an invocation to answer a permission prompt and the session already runs in its own microVM with its own filesystem. The isolation a permission dialog is asking about is the isolation AgentCore already provides. Code execution by the agent inside its own microVM is the product working, not a vulnerability.

Callers are trusted, in proportion to what they are already given. Whoever invokes the runtime chooses the prompt, the model, the tools, and the MCP servers. There is no privilege boundary between two callers of the same runtime, and the request-shaped options (allowed_tools, mcp_servers, system_prompt) are conveniences for the deployer, not a sandbox. Authorize callers at the AgentCore runtime, with IAM.

No inference credential is inside the microVM. Bedrock is reached through the runtime's IAM role, and the token the harness holds is minted per turn and worthless outside the container. A compromised agent has nothing to steal on its way out.

• One session reading or affecting another session's data.
• A credential — an MCP server's headers, the runtime role, the per-turn token — reachable by the agent or written to a log or a span.
• A caller escaping the microVM, or reaching the AWS control plane.
• A turn that can make the next turn in the same session behave differently without the caller asking (see the known gap below, which we already know about).
• Anything that lets an invocation read the container's own environment.

Stated here rather than discovered by a reporter. All three are also in the code, at the place they matter.

Persistent harness settings. HOME is the workspace, the workspace persists across turns in a session, and the agent can write to it. Claude Code reads ~/.claude/settings.json from there, which can define hooks — arbitrary commands. So a turn can arrange for a later turn in the same session to run something nobody asked for. --strict-mcp-config closes the equivalent hole for MCP servers and does nothing about this one. The blast radius is one session: no credentials are exposed and no other session is reachable. Closing it properly means settings the agent cannot write. See docs/mcp.md.

resume trusts the caller. A caller who passes resume with a session id continues that transcript. Session identity comes from the AgentCore session header, so this is only as strong as the authorization in front of the runtime.

Content capture is on by default. Prompts, replies, tool arguments and tool results are attached to spans, which means conversations reach your telemetry backend. This is the opposite of what the OpenTelemetry GenAI conventions recommend, and it is deliberate — a trace that cannot say what was asked is a trace that answers no question worth opening it for. Set CAPTURE_CONTENT=false for deployments where conversation content should not be exported. See docs/observability.md.

main only, while the project is pre-1.0. There are no maintained release branches and no backported fixes.