A three-rule DNS allowlist closes the last exit from Benchling's agent code sandbox

The reason DNS is the interesting control follows from the rest of the diagram. The VPC that runs the interpreter has no internet gateway and no NAT gateway, and the interpreter's security group allows port 443 only ^[4][5]. NACLs and prefix-list routing send what is left to an S3 gateway endpoint and one interface endpoint ^[7]. A connection to an arbitrary host has nowhere to route. A name lookup is different, because the resolver answers it, so the outbound paths that exist are those two endpoints and the resolver ^[15]. AWS's post puts the general case plainly: standard controls block HTTP, restrict egress ports and limit outbound connections, while DNS resolution is often still permitted, and even when system defaults restrict it you may not have visibility into or control over those restrictions ^[3].

The resolver policy has three rules. Priority 10 blocks known malicious domains, priority 100 allows only explicitly listed endpoints, and priority 200 blocks the remaining queries ^[6]. Priority 200 closes the channel. That leaves priority 10 redundant for every domain except the ones already on the allowlist, and those are the ones it exists for ^[16]. If a listed domain later shows up on a threat feed, the lower priority is evaluated first and wins.

The per-tenant boundary sits somewhere else entirely. The network controls are identical for every session, so nothing inside the VPC knows which tenant it is serving, and the scoping comes from the credentials STS injects per job from the production account ^[8][17]. Benchling's requirement was that each session reach only that tenant's data without one IAM role per tenant; role-per-tenant sprawl at this scale would be unsustainable ^[9]. A dispatcher that hands a session the wrong scope produces a cross-tenant read that the DNS firewall never sees.

Run the daily figure out to a week and the load is roughly 4,200 sessions across 250-plus tenants, about 17 each ^[14]. Both published numbers are floors, so treat that as scale and not a measurement. For the zero-incident record to say anything about your agents, your generated code has to want the same short list of destinations. Benchling's list is S3, reached through two endpoints ^[7]. Generated code that pip-installs from a public index, or calls a model endpoint outside the account, needs a resolver rule for each domain, and each rule is one someone has to justify.

I would copy the test suite first. Benchling runs integration tests that simulate exfiltration attempts against this configuration ^[11]. Those tests catch a widened allowlist before it ships. The post reports the 600 sessions a day and the zero incidents, but gives no observation window and no count of queries the firewall blocked ^[18].