Benchling built a separate AWS account for untrusted AI-generated scientific code, then restricted DNS, storage and credentials around each execution session.
The most important lesson from Benchling AI agent security is that blocking ordinary web traffic is not enough. Code can attempt to leak data through DNS queries, shared storage or overly broad temporary credentials. Benchling’s design treats every generated program as untrusted and isolates the execution plane from the application account.
Start with the threat model, not the sandbox product
Benchling serves life-sciences customers in a multi-tenant environment. A code session acting for one tenant must not read another tenant’s information or send sensitive results to an external destination. The system also has to scale without creating one permanent identity role for every tenant.
- Assume generated code may be malicious even when the user is trusted.
- Assume a dependency can attempt network access during execution.
- Assume DNS can carry encoded information if resolution is left open.
- Assume a reusable role will eventually receive more permission than one job needs.
- Assume logs and temporary files are part of the data boundary.
Benchling’s isolation layers
| Layer | Control | Risk reduced |
|---|---|---|
| Account | Dedicated untrusted-code AWS account | Limits blast radius outside the main application estate |
| Network | VPC mode without internet gateway or NAT | Removes ordinary outbound internet paths |
| DNS | Route 53 Resolver DNS Firewall | Blocks unapproved resolution and DNS exfiltration paths |
| Storage | S3 endpoints and endpoint policies | Restricts buckets reachable through the VPC |
| Identity | Scoped STS credentials per job | Avoids broad permanent tenant roles |
| Session | AgentCore Code Interpreter isolation | Separates individual execution environments |
Why DNS needs its own control
A network policy can block HTTP and restrict ports while still allowing name resolution. Malicious code may encode small pieces of a secret into a sequence of subdomain lookups. The attacker does not need a normal web response if the query itself reaches a DNS service they observe.
Benchling uses a prioritized DNS policy: deny known malicious domains, allow only explicitly required endpoints, then deny everything else. That final default-deny rule is the important one. A long allowlist creates maintenance work, but it makes every new destination an intentional review decision.
Temporary credentials should describe one job
Instead of a permanent role per tenant, the application obtains temporary credentials scoped to the exact job and data objects. The execution environment receives only those credentials. Session duration, object paths and allowed actions become part of the policy boundary.
This is the same design principle behind our private npm credential guide: the model should not receive the reusable secret, and the runtime should receive only the capability needed for the current operation.
How to test the containment claim
- Attempt DNS queries to random and attacker-controlled names.
- Try direct IP connections on common and uncommon ports.
- Request storage objects outside the job prefix.
- Read instance metadata and environment variables.
- Attempt to reuse credentials after the job expires.
- Write oversized outputs and archives to test resource limits.
- Inject a dependency that performs installation-time network calls.
- Confirm that every denied action creates an attributable audit event.
Company-reported scale is not an independent audit
AWS and Benchling report more than 600 code-execution sessions per day across more than 250 tenants per week, with no security incidents or cross-tenant leakage since early April 2026. Those figures are useful operating context, but they remain company-reported. Absence of a detected incident is not proof that every isolation property is correct. Independent review, alert coverage and recurring adversarial tests are still required.
The reusable architecture decision
Teams do not need Benchling’s exact services to copy the pattern. Separate the untrusted execution account, default-deny outbound traffic, govern DNS explicitly, mint job-scoped credentials and validate containment continuously. Pair those controls with the session evidence described in our AI agent session-recording analysis so incident responders can reconstruct what the agent saw and attempted.
The architecture should also have a documented emergency stop. Security operators need a way to prevent new sessions, invalidate outstanding temporary credentials and preserve evidence without depending on the application that may be under investigation. DNS and endpoint-policy changes should be versioned, reviewed and tested in a non-production environment before rollout. A blocked dependency download can look like a model failure, so user-facing errors should identify the policy boundary without exposing sensitive network details. These operational controls turn isolation from a static diagram into a maintainable security system.
Primary source
Checked September 22, 2026. Architecture details come from the co-authored technical report. Operational results remain company-reported.
