Benchling Sealed Its Agent Sandbox at the DNS Layer

AWS published an architecture walkthrough of how Benchling, a life sciences software company, runs AI agent-generated scientific code for thousands of customer tenants without giving that code a way to phone home. The design combines a dedicated AWS account for untrusted execution, a DNS firewall that returns nothing for any domain not on an explicit allowlist, and temporary credentials minted per job rather than per tenant. The post is co-authored by a Benchling application security engineer and two AWS staff, which is worth keeping in mind when reading the conclusions.

What was built

Benchling's product generates scientific code on behalf of researchers, and that code has to actually run. The primary use case is agent-generated analysis, with the same sandbox also serving simpler calculations and general code generation. The team's threat model treats every piece of that code as potentially hostile, whether an agent wrote it or a user did.

The execution layer is AgentCore Code Interpreter, a capability of Amazon Bedrock AgentCore, running in VPC mode. AWS notes that Code Interpreter also offers a Sandbox mode that limits outbound access to Amazon S3 operations, but Benchling wanted network controls it owned and could audit itself rather than defaults that might shift between service versions. VPC mode gave them a managed sandbox they could drop inside their own locked-down network.

That network lives in a separate AWS account, described in the post as the Untrusted Code Account, distinct from the production account holding customer data and access roles. The VPC there has no internet gateway and no NAT gateway. Code Interpreter sits in a dedicated security group limited to port 443, with network ACLs allowing only port 443 and ephemeral return ports, and prefix list routing that confines traffic to VPC endpoints. Benchling's pre-existing gVisor-based container environment runs in the same account with its own scoped IAM role; AWS is explicit that gVisor is Benchling's own isolation layer, not part of the recommended pattern.

The egress channel most teams forget

The interesting part is the DNS handling, because DNS is the classic gap in otherwise tight egress rules. Teams block HTTP, close ports, and drop outbound routes, then leave name resolution working because everything breaks without it. Encoding stolen data into subdomain labels and letting recursive resolution carry it to an attacker-controlled nameserver survives precisely because it rides a channel nobody thinks of as a channel.

Benchling's answer is an Amazon Route 53 Resolver DNS Firewall policy with three priorities, described in the post as a denylist, allowlist, deny-all pattern. Priority 10 blocks domains associated with known exfiltration tooling or command-and-control infrastructure; AWS frames this partly as an observability mechanism, since a hit generates a log line that tells the security team something inside the sandbox is probing. Priority 100 permits resolution only for explicitly listed endpoints, in practice the specific S3 bucket endpoints a job needs. Priority 200 is a catch-all that returns NODATA for everything else.

The third rule is the one that matters architecturally. Without it, any newly added or overlooked domain defaults to resolvable, and the posture depends on someone remembering to deny things. With it, the default flips: nothing resolves unless it was deliberately allowed. AWS describes this as breaking the recursion chain at the first hop — the same inversion that separates a real allowlist from a denylist wearing an allowlist's clothes.

Two independent controls, not one control twice

The second design decision worth stealing is the separation between what a session is authorized to do and what the network is physically able to deliver.

Authorization is handled with per-job scoping. Maintaining one IAM role per tenant across thousands of tenants would produce what the post calls unsustainable role sprawl, so Benchling instead uses AWS Security Token Service to inject scoped temporary credentials into each Code Interpreter session at dispatch time. A session policy passed at launch narrows S3 access to a specific tenant's path prefix inside an authorized bucket. The Code Interpreter execution role itself is restricted to the main stack bucket. AWS says Benchling considered and rejected the simpler option of granting the role broad access to all tenant buckets, on the grounds that one compromised session would then reach everyone's data.

Delivery is handled separately. A gateway VPC endpoint covers in-region S3 and an interface endpoint covers cross-region S3, and each carries a policy naming the buckets it may reach. A call to an unlisted bucket is rejected at the network layer before S3 ever sees it. The post's framing is that credential theft alone is not enough, because the network refuses to carry the traffic regardless of what the credentials say.

This is the part teams building agent infrastructure most often get wrong. Scoped tokens are usually treated as the isolation boundary. They are a single boundary, and they fail in the one scenario you are defending against — code holding a credential it should not have. Pairing an identity control with an independent network control means a mistake in either one is survivable.

Isolation as a property you test, not a setup you finish

Benchling's product security team first validated the design in a proof-of-concept VPC, testing DNS tunneling, direct IP connections, and API calls to out-of-scope buckets. The more durable move was what came next: the infrastructure team folded those exfiltration simulations into the continuous integration suite. If a test resolves a domain it should not, reaches an external endpoint, or moves data outside approved buckets, the pipeline fails and the release is blocked.

The reasoning AWS gives applies well beyond this stack. VPC configurations drift, endpoints get added to support features, IAM policies change as teams onboard. A configuration that was airtight at deployment can quietly degrade without anyone making an obviously bad decision. Treating exfiltration resistance as an assertion in CI catches that drift at the point it is introduced.

Reading the numbers carefully

AWS reports that since the deployment in early April 2026, the architecture has handled more than 600 code execution sessions per day across more than 250 distinct tenants per week, with zero security incidents and zero cross-tenant data leakage.

Those figures deserve a measured read. Six hundred sessions per day is a real production workload but not an extreme one, and the post does not disclose session duration, data volumes, or how many of those sessions involve genuinely adversarial input. "Zero incidents" is a report of nothing detected, which is not the same as nothing happening — though the CI suite gives that claim more weight than a bare assertion would, since it means the controls are being actively probed rather than assumed. The quoted justification for choosing a managed sandbox, attributed to application security engineer Jeremy Stashewsky as being able to buy instead of build, is a build-versus-buy argument in a post published by the vendor being bought from. The architecture is still instructive; the endorsement is the softer half.

What to watch

• Whether AWS turns this three-tier DNS policy into documented guidance or a reference pattern for AgentCore, rather than leaving it as one customer's configuration to reverse-engineer from a blog post.
• How the allowlist scales operationally. A deliberately minimal list of S3 endpoints is easy to defend today; the pressure comes when product teams need a third-party API reachable from inside the sandbox.
• Whether exfiltration simulations in CI spread as a practice. It is the most portable idea in the post and the least dependent on any particular cloud.
• Whether comparable isolation appears for agent runtimes outside a single cloud's primitives, where DNS firewalls and endpoint policies are not available off the shelf.
• Longer-term incident data at higher volume. The security case gets much stronger at ten times the session count and a year of exposure.