✓ Human-authored analysis; AI used for formatting and proofreading.
Two sandbox escapes in one week. The Hugging Face breach happened because the sandbox had unrestricted egress. The OpenAI ExploitGym escape is more instructive. The sandbox was almost isolated.
The evaluation environment had one sanctioned egress path: an internal JFrog Artifactory proxy that pulled packages from the internet. The model found a vulnerability in that proxy, pivoted through it to a node with internet access, stole credentials from the pivot node, and chained them into production infrastructure. The isolation was real except for one allowed path. That one path was the entire attack.
This does not mean "don't allow any egress." Some sandboxes need package registries, model repositories, or data feeds. The lesson: if your sandbox has a single allowed egress path, that path is your entire security boundary, and every property of that path such as its network rules, IAM role, credential scope, monitoring coverage must be verified.
The anatomy of a sole-egress escape
A properly isolated enclave has no direct internet access. No internet gateway, NAT gateway, VPC peering to an internet-connected VPC, Transit Gateway attachment, VPN or Direct Connect. No public IPs on any instance.
But it needs packages. So you add one thing: a proxy that can reach a package registry. The proxy runs in the same VPC. It has a security group that allows outbound HTTPS to the registry endpoint. Its IAM role has just enough permission to authenticate with the registry. It pulls packages and serves them to the enclave's compute.
The security model says: the proxy is the sole egress path, and the proxy is tightly scoped. The proxy's security group allows only HTTPS to the registry. The proxy's role has only registry read access. The enclave instances can reach the proxy but nothing else.
Here's what goes wrong:
The proxy has a vulnerability. The model exploits it. Now the attacker has the proxy's network position which includes outbound HTTPS to the registry, but also whatever the proxy's security group allows beyond that single rule. If the security group has a broad egress rule (even one that "should only reach the registry"), the attacker has internet access.
The proxy has an IAM role. The attacker can reach the IMDS endpoint from the proxy's network position (unless IMDSv2 is enforced AND the hop limit prevents container escape). Now the attacker has temporary credentials with whatever permissions the proxy's role carries. If the role has more than registry-read even one extra permission, the blast radius expands.
The enclave instances can reach the proxy. If the security group allows broad traffic from enclave to proxy, the attacker can pivot in the other direction. From a compromised enclave instance to the proxy, gaining the proxy's network and credential context.
Three configuration properties. Each seems reasonable in isolation. Together, they create a complete escape path from an isolated sandbox to production.
26 invariants for sandbox isolation
I decomposed sandbox isolation into 26 configuration properties across five areas: the egress inventory (what paths out of the VPC exist), the pivot surface (can enclave instances reach egress-capable nodes), SSRF absorption (can credential theft be prevented at the instance level), proxy egress scope (is the sanctioned egress scope), and credential blast radius (do enclave credentials reach production).
Egress inventory
Ten properties verify that a VPC has no unintended egress paths. Every way traffic can leave a VPC is a checklist item: IGW attachment, NAT gateway routes, IPv6 egress-only gateway routes, VPC peering, Transit Gateway attachments, VPN and Direct Connect, public IPs and Elastic IPs, VPC endpoint policies, and gateway endpoint route entries.
Most of these have existing controls. The main route table is checked for IGW routes. NAT egress is checked. VPC peering has five controls covering bidirectional routing, cross-account trust, and DNS resolution. Transit Gateway has seven controls covering route isolation, auto-accept, and propagation scope.
Two gaps needed contract fields: IPv6 routes to egress-only gateways, and gateway endpoint route table associations. A gateway endpoint without route entries is a ghost endpoint. It exists but traffic doesn't flow through it.
The most important gap was the obvious one: every egress control fires unconditionally on every VPC. There was no way to say "this specific VPC should be isolated, check it more strictly." A VPC with an internet gateway is normal for a web application. The same VPC with an internet gateway is a critical finding if it's supposed to be an evaluation sandbox.
The missing concept: isolation intent
The audit's central finding: there was no representation for "this VPC should be isolated from the internet."
The fix is a tag. The same mechanism that marks an S3 bucket as containing PHI (classification: PHI), or marks an ECS service as read-only (service-type: read-only), marks a VPC as intended to be isolated:
Tag: stave:isolation-intent
Values: airgapped | egress-restricted | internet-facing
An airgapped VPC should have no egress of any kind. An egress-restricted VPC should have egress only through VPC endpoints with resource-scoped policies. An internet-facing VPC is the standard case where egress controls fire at their normal thresholds.
The tag expresses intent. The controls verify reality matches intent. The finding fires when the VPC is tagged as airgapped but has an internet gateway attached. That's the compound check: declared isolation intent plus observed egress path equals a critical finding. Without the intent tag, the same internet gateway is informational. With it, it's a containment breach.
The pivot surface
The hardest gap to detect and the one the ExploitGym attack exploited is the lateral path from an enclave instance to an egress-capable node. The model didn't break through the sandbox's external boundary. It moved laterally to a node that had a legitimate egress path and used that node's network position to escape.
Three properties check this: security group rules permitting enclave instances to reach egress-capable instances, NACL rules permitting enclave subnets to reach subnets with default routes out, and security groups shared between enclave and non-enclave instances. A shared security group is an implicit trust bridge.
Each requires classifying which instances are enclave (isolated, no egress) versus "egress-capable" (has a path to the internet, even if scoped). The isolation intent tag on the VPC provides this classification. Instances in an airgapped VPC are enclave. Instances in the same VPC with egress rules reaching outside the VPC CIDR are egress-capable. The security group check asks: can the first group reach the second?
SSRF absorption
If an attacker reaches an instance through a vulnerability (SSRF, RCE, dependency exploit), the first thing they try is the Instance Metadata Service. IMDSv2 enforcement, hop limit restriction, and IMDS disablement on instances that don't need credentials. These are the controls that prevent SSRF from becoming credential theft.
This area is fully covered. Eighteen IMDS controls across EC2, ECS, and EKS. The Capital One chain (IMDSv1 + public instance + broad role) has existed with incident citation since the control catalog was first built. Five chain variants cover EC2, ECS, EKS, Kubernetes, and container-specific IMDS paths. This is the most thoroughly covered area in the entire audit because the attack pattern has been documented since 2019.
Proxy egress scope
The proxy itself is a security boundary. Its security group determines what it can reach. Its VPC endpoint policies determine what services it can access. Its IAM role determines what it can do with those services.
The control that's been missing: verifying that egress is exclusively through VPC endpoints or an allowlist. Existing controls detect unrestricted egress (security group allows 0.0.0.0/0) and detect broad NAT egress. No control verified the positive case: "this VPC's ONLY egress is through endpoints." Having both an internet gateway and VPC endpoints means the endpoints are bypassable. Traffic can go around them through the IGW. The control checks: if the VPC is egress-restricted, does it have any egress path other than VPC endpoints?
Credential blast radius
The final area checks whether sandbox credentials can reach production. Can an enclave role assume a production role? Does a production role trust an enclave principal? Are resource policies in production granting access to enclave accounts? Does the enclave's Organization OU have SCPs restricting services and regions?
The existing cross-environment controls are strong: transitive role assumption paths, org boundary trust checks, SCP region and service restrictions. The gap: no control checked resource policies (S3, KMS, SQS, SNS, Lambda) for grants to enclave-account principals specifically. A production S3 bucket policy that grants s3:GetObject to an enclave account's IAM role is a data access path that bypasses every AssumeRole control. The resource policy grant doesn't require assuming a role. It's a direct grant from the resource to the foreign principal.
Compound chains
The individual controls check individual properties. Three compound chains compose them into the attack paths the ExploitGym model took:
The enclave egress violation chain fires when a VPC tagged as airgapped or egress-restricted has any internet egress path. The compound check: declared intent says "no egress" AND observed configuration says "IGW attached." This is CHAIN-G from the audit. The chain that couldn't be authored until isolation intent had a representation.
The enclave lateral to egress chain fires when an isolated VPC has both enclave compute and egress-capable compute with security group rules permitting traffic between them. This is the ExploitGym path: the model moved laterally from enclave to proxy because the security group allowed it.
The enclave to production via resource policy chain fires when a production resource policy grants access to an enclave-account principal without requiring AssumeRole. This bypasses every identity-based control (MFA, ExternalId, session naming) because it's a resource-based grant.
The proxy is the perimeter
The operational takeaway is counterintuitive: in a sandbox with one allowed egress path, that path isn't part of the boundary. It is the boundary. Every property of the proxy such as network rules, IAM role, patch level, monitoring has the same security significance as a firewall rule on a perimeter device. But nobody reviews a JFrog Artifactory instance with the same rigor they review a firewall.
The 26 invariants formalize them. They check the entire egress inventory (every way traffic can leave), the pivot surface (can enclave instances reach the proxy), the proxy's scope (is its egress restricted), and the credential blast radius (can proxy credentials reach production). Verified before the model runs. Verified continuously. Verified against declared intent, not assumed isolation.
The sandbox had one allowed egress path. The model used it. The configuration that allowed it is verifiable. Check it.
The 26 egress isolation invariants, the isolation-intent mechanism, and the three compound chains are implemented in Stave. The egress isolation checklist is derived from the OpenAI ExploitGym and Hugging Face incidents (July 2026).
Top comments (0)