MicroVM session isolation, control/data plane separation, VPC mode for production, and organization-wide SCP guardrails.
Amazon Bedrock AgentCore runs each agent session in its own MicroVM. Compute, memory, and network are isolated between sessions, so one session cannot observe or influence another — even for the same agent.
Each session gets a dedicated MicroVM. Isolation is enforced at the virtualization boundary, not just by process separation.
Management APIs (control plane) are separated from agent execution (data plane), with TLS and SigV4 authentication between them.
Any model, any framework, any external provider gets the same isolation guarantees — the controls don't change with your stack.
Session isolation guarantee: each session runs in a dedicated microVM with isolated CPU, memory, and filesystem. When the session ends, the microVM is terminated and its memory sanitized. This is an AWS responsibility (see M1) — but you still have to configure the network boundary around it, which is the rest of this module.
ValidationException. Enable it by calling UpdateAgentRuntime with requireMMDSV2: true in metadataConfiguration.
The isolation boundary is the microVM — not the agent. Any code running inside the VM can read the execution role's credentials from the metadata service (MMDS), the same way EC2 code can reach IMDS. So isolation between sessions does not protect you from your own over-permissioned role: scope the execution role to exactly what the agent needs, and keep it at or below the privileges of whoever can invoke it.
By default a Runtime can run in a public network mode. For production that's a finding, not a choice. Security Hub enforces it.
PUBLIC. Production runtimes must be deployed in VPC mode with private connectivity.
Configure Amazon Bedrock AgentCore Runtime behind VPC PrivateLink so traffic never traverses the public internet.
Pin the runtime to approved subnets and security groups using the subnets and securityGroups condition keys from M2.
Restrict which external endpoints agents can reach — an over-open egress path is how exfiltration (M1) completes.
Individual account controls can drift. Service Control Policies enforce a baseline across an entire organization or OU — no account can opt out. Four enforcement patterns cover most production baselines.
Deny create/update unless subnets & security groups are supplied.
Deny memory creation without a KMS CMK.
Deny invocations that don't originate from an approved VPC.
Deny InvokeAgentRuntimeForUser where it isn't needed.
Example — SCP 1: deny runtime and tool creation unless wired into a VPC
Condition block are AND-ed. So one statement checking Null on subnets and securityGroups together would only deny when both are missing — a request supplying subnets but no security groups would sail straight through. Splitting them means missing either one denies the request, which is what you actually want. Note the tool actions in the list too: leave CreateCodeInterpreter and CreateBrowser out and someone can still stand up a non-VPC tool through the side door.
Principal: "*" plus conditions. Use both.
Multi-account strategy: keep agent workload accounts separate from security control accounts. SCPs live at the org/OU level so the guardrail is enforced above the team that ships the agent — they can't accidentally weaken it.
bedrock-agentcore:* condition keys