Recap
In Part I and Part II, we:
- Explored the AgentCore Runtime microVM from a reverse shell and discovered an AWS-internal logging pipeline through the MMDS
- Escaped the container via an exposed containerd socket to reveal four platform binaries running alongside our code
- Redirected the platform logger’s output to our own S3 bucket by spoofing the MMDS
- Intercepted live invocation traffic through the proxy’s graceful upgrade mechanism
- Discovered a JWT authentication scheme that – from within the microVM – could be forged with values available from the metadata service (AWS has since closed this path with mTLS)
- Reconstructed the end-to-end invocation architecture from the captured traffic
Networking and VPC Mode
Network Isolation Testing
The microVM is assigned an IPv6 address matching the value in the JWT. Across multiple runs, all addresses shared the same 2600:1f18::/32 prefix, but cross-microVM communication always failed.
We attempted to reach the host EC2 IMDS by manipulating the route table – unsuccessful. Firecracker intercepts metadata requests at the TAP device level, making it impossible to route around the hypervisor’s metadata interception.
VPC Mode
AgentCore supports a VPC mode that connects the Runtime to the customer’s VPC for accessing private resources:
In VPC mode, an ENI (Elastic Network Interface) appears in the customer’s VPC. The ENI’s interface type is agentic_ai, created by a Service Linked Role:
The Runtime isn’t actually deployed in the customer’s network – it runs in AWS’s AgentCore account and attaches to the customer’s VPC via a cross-account ENI. It was plausible to assume that behind the scenes it would look something like this:
Meaning that in VPC mode, the Logger’s S3 writes should route through the customer’s S3 VPC Endpoint:
VPC Endpoint Policy Bypass
We set a VPC Endpoint policy to deny cross-account access. The expectation: the Logger’s writes to AWS’s kepler bucket would be blocked:
But our expectation was wrong. S3 operations from the Runtime went through despite the following VPC Endpoint policy:
CloudTrail revealed why. The request’s vpcEndpointId and vpcEndpointAccountId were both “AWS Internal”, with a private source IP (10.71.17.66):
The Runtime’s S3 requests were routing through an internal VPC Endpoint in AWS’s own AgentCore account – completely bypassing the customer’s VPC Endpoint and its policies:
Using S3 bucket policy conditions with aws:VpceAccount, we enumerated the AWS internal account that own this VPC endpoint – a previously unknown infrastructure account:
The implication: an attacker/malicious insider with code execution on a victim’s Runtime could reach external S3 endpoints, bypassing the customer’s data perimeter controls that rely on VPC Endpoint policies.
In this scenario the attacker can use their credentials from their personal AWS account and make API calls against their resources. None of the data perimeter controls would block them and they could abuse it to establish a C2 channel:
Remediation: In later testing, CloudTrail showed the Logger’s S3 requests arriving from the customer’s NAT gateway IP rather than an internal VPC Endpoint – indicating AWS rerouted the traffic path through the customer’s network:
This fix effectively closes the door on the C2 possibility described earlier.
Identity
Using a technique from previous research, that allows us to send GET requests from AgentCore’s network, we attempted SSRF to the kepler... domain – DNS didn’t resolve it. The cells are only reachable through AWS’s internal routing, not the public internet:
Cross-Service Connections – The Lambda Link
AgentCore Runtime code contained Lambda references. One of the four platform binaries we extracted with many Lambda references, suggesting a possible shared codebase with AWS Lambda’s container orchestration layer.
AWS recently launched Lambda MicroVMs – a feature that provides similar Firecracker-based isolation for Lambda functions:
The shared references suggest that the sandbox layer may share components with other similarly built services.
What AWS Got Right – Defense in Depth
It would be easy to focus on the findings and lose the bigger picture. The bigger picture is that AWS built a robust platform.
Firecracker isolation is solid. The container escape gave us access to the host filesystem inside the microVM – but the microVM boundary held completely. No cross-VM communication was possible. The escape’s blast radius was confined to a single session’s microVM.
Network isolation is absolute. Cross-microVM traffic fails. IPv6 is inbound-only from the control plane. The host EC2 IMDS is unreachable – Firecracker intercepts at the TAP device level, and no route table manipulation could circumvent it.
Defense in depth with continuous remediation. AWS fixed rough edges as they were identified – the JWT forging scenario was remediated with mTLS, the VPC Endpoint bypass seems to have been mitigated. In some cases, fixes appeared before our report.
AWS’s own security documentation accurately describes the architecture:
This held true. The platform components inside the microVM – proxy, logger, agent, sandbox – contain no service-critical code and cannot access other sessions. The shared responsibility model is clear: everything inside the microVM is within the tenant’s isolation boundary.
Conclusion
AWS Bedrock AgentCore Runtime – internally known as Project Kepler – is a well-engineered platform built on Firecracker’s proven isolation model. We bypassed internal controls, escaped the container, hijacked the logging pipeline, forged JWTs, and bypassed VPC Endpoint policies. Every finding was contained within the microVM boundary.
Platform security has been evaluated over time and rough edges were fixed – some proactively. The Firecracker microVM boundary held against every technique we threw at it. For a platform that runs arbitrary tenant code alongside internal control-plane components, that’s a strong result.
This research is a starting point. There is plenty more to build on – the binaries, the networking, the cross-service connections to Lambda, etc.
This research was presented at Cloud Village, DEF CON, by Dan Gansel of Upwind Security.
