Reviewing AWS Bedrock AgentCore — Runtime isolation, Identity, and the Agent Registry

Runtime gives each user session its own isolated microVM with persistent compute — a real, meaningful isolation boundary compared to agents sharing a process or container. Identity handles authentication to AWS services and third-party apps through standard identity providers. Memory provides short- and long-term stores so an agent can recall context across sessions. Agent Registry, generally available as of August 2026, is a governed catalog for discovering MCP servers, A2A agents, and other resources across an organization — accessible via console, CLI, SDK, or as its own MCP server.

The isolation and identity primitives are genuinely strong defaults — stronger than most teams would build themselves. That strength is exactly why a review has to look past the primitive to how the application actually uses it:

Runtime's Code Interpreter and Browser tools each get a dedicated Firecracker microVM per session — genuine one-session-one-VM isolation, fully terminated with memory sanitized when the session ends. But a researcher-disclosed finding (BeyondTrust, September 2025) showed the sandbox's “no network access” mode still permits outbound DNS queries — enough to run a full bidirectional command-and-control channel over DNS, including reverse shells and data exfiltration encoded in DNS A-record lookups.

AgentCore lets a developer flag a sensitive tool as requiring human confirmation before it executes. Disclosed at Black Hat USA 2026 as part of a cross-vendor pattern researchers named “CoreBreak” (CVE-2026-18830, also found independently in Google ADK and the Vercel AI SDK), the confirmation processor didn't verify that the tool being confirmed actually belonged to the executing agent, that it genuinely required confirmation, or that its name and arguments matched the originally recorded call. An attacker able to inject events into the session history could forge an approval and run an unauthorized tool without the model ever being invoked at all.

The researchers' framing is the useful part for a review: unlike prompt injection, CoreBreak requires no model interaction — the model never executes, which makes guardrails built around watching what the model says or does irrelevant to this specific attack. AWS fixed it server-side; no customer action was required, but it's a reminder that not every agent-security control lives at the model layer.

A separate, unrelated finding worth a version check on its own: CVE-2026-11393, an argument-injection flaw in the AgentCore CLI where an unescaped triple-quote in the collaborationInstruction field let a user with agent-collaborator permissions break out of a Python docstring and inject arbitrary code into generated application code. Fixed in @aws/agentcore 0.14.2.

The practical fix is procedural, not technical: pair the Registry with an explicit review gate — nothing gets built on top of a catalogued MCP server or agent until it has been through the same review any other third-party dependency would get.

For any system built on AgentCore, a design-time review should be able to answer:

• Does Runtime session isolation actually map to your tenant/user boundary, or could two sessions from the same tenant unintentionally share state?
• What scope does Identity actually grant each agent — reviewed per-agent, or copied from a broad template?
• Is Memory scoped per user/tenant, with an explicit answer for whether one session's stored memory can influence another's?
• Is there a documented policy that Agent Registry listings require a review before being built on, not just discovery?
• For third-party apps connected via Identity (Slack, Zoom, etc.), what's the blast radius if that specific integration's credential is compromised?
• If Runtime sandbox mode (not VPC mode) is used for network isolation, is outbound DNS also blocked or monitored, given it's not covered by “no network access” by default?
• Is @aws/agentcore pinned past 0.14.2, closing the CLI docstring-injection issue (CVE-2026-11393)?

See MCP security review for the questions that apply the moment an AgentCore deployment connects to an MCP server discovered via the Registry.