Benchling has documented a defense-in-depth architecture for running AI agent-generated scientific code with Amazon Bedrock AgentCore Code Interpreter in VPC mode, giving its life-sciences tenants per-job access to their own data while restricting the network paths available to untrusted code. For security and infrastructure teams operating multi-tenant agents, the implementation shows how account isolation, DNS filtering, endpoint policies and temporary credentials can work together without requiring a separate IAM role for every tenant.
The company’s threat model treats agent- and user-generated code as potentially unintended and requires each execution to remain isolated from other tenants. Benchling wanted customer-controlled restrictions defining which domains could resolve and which endpoints could be reached, rather than relying exclusively on a sandbox’s application-managed network controls.
Separate accounts contain untrusted execution
Benchling dispatches tasks from its production account to a dedicated untrusted-code AWS account containing the AgentCore Code Interpreter VPC. Customer data, production roles and broader credentials remain in the production environment. The isolated VPC has neither an internet gateway nor a NAT gateway, while the interpreter runs in a dedicated security group with no public-internet path.
The untrusted account also contains Benchling’s existing gVisor-based execution environment. AWS’s post identifies gVisor as a pre-existing compute-isolation layer rather than part of the AgentCore pattern. Both execution environments use scoped IAM roles, while AgentCore sessions are ephemeral, isolated and have no persistent state between jobs. AWS manages the underlying sandbox lifecycle, including patching, scaling and hardening; Benchling applies its own network controls around it.
DNS policy closes an often-permitted channel
Route 53 Resolver DNS Firewall evaluates requests under a three-priority policy. Priority 10 explicitly blocks known unintended domains and produces logs that can flag suspicious resolution attempts. Priority 100 allows only approved domains, principally the S3 endpoints needed for a job. Priority 200 returns NODATA for every remaining query.
That final catch-all is important for Benchling’s tested threat model because malicious code can encode data in subdomain labels and attempt to send it through DNS recursion. Returning NODATA for domains outside the allow list stops those queries at the first resolver hop. The policy also makes the approved DNS boundary an artifact that Benchling can audit, version and change itself.
Network and credentials enforce separate boundaries
With public egress removed, permitted AWS service traffic passes through VPC endpoints. Benchling uses a Gateway endpoint for in-region S3 access and an Interface endpoint for cross-region S3 access. Policies attached to those endpoints enumerate authorized buckets, causing requests for other buckets to be rejected before reaching S3.
This creates a network restriction independent of IAM authorization: possession of otherwise valid credentials does not make an unlisted bucket reachable through the endpoint. Prefix-list routing limits traffic to the endpoints, while network access control lists permit port 443 and ephemeral return ports. The dedicated security group has no default fallback rules.
Benchling avoided creating one static IAM role for each of thousands of tenants. Instead, its production account generates temporary, job-specific credentials through AWS Security Token Service and injects them into the AgentCore session at dispatch. A session policy narrows S3 access to the relevant tenant’s path prefix inside an authorized bucket. The endpoint policy constrains which storage destinations the network can deliver traffic to, while the credentials constrain what that individual session may do.
Exfiltration checks run in CI
Benchling first tested the layers separately in a proof-of-concept VPC. According to the AWS account, DNS-tunneling attempts received NODATA for domains outside the allow list; direct-IP tests found no route to arbitrary external hosts; and requests for S3 buckets outside the endpoint-policy scope were rejected. The tests also checked the combined absence of an internet gateway, NAT gateway and default security group.
The company then moved exfiltration simulations into its continuous-integration suite. The checks attempt encoded DNS queries, direct connections to unauthorized endpoints and access to S3 buckets beyond the VPC endpoint policy. A successful unauthorized resolution, external connection or transfer outside approved buckets fails the pipeline and blocks the release. This is intended to catch regressions as VPC configuration, endpoints and IAM policies change.
Reported production scale and limits
Benchling says it deployed AgentCore Code Interpreter in VPC mode in early April 2026 and now handles more than 600 code-execution sessions per day across more than 250 distinct tenants per week. It reports zero security incidents and zero cross-tenant data leakage since deployment. Those figures and outcomes are operational claims from Benchling presented in an AWS-authored implementation report, not independently corroborated measurements.
The evidence supports a tested implementation pattern, not a claim that any single control guarantees security. Its central lesson is the combination of account separation, short-lived execution, default-deny DNS, narrowly scoped VPC endpoints, per-job credentials and recurring adversarial tests. Benchling says the combined design closed every exfiltration vector it tested, including DNS; that claim is bounded by the vectors covered in its test suite.
Source: AWS Machine Learning Blog.
Definition. Benchling’s defense-in-depth architecture is a multi-layer AWS design that limits how untrusted, agent-generated code can reach tenant data, storage services and external networks.
| Defense layer | Implemented control |
|---|---|
| Account isolation | Dedicated untrusted-code AWS account separated from production data, roles and broader credentials. |
| Public egress | No internet gateway or NAT gateway; dedicated security group has no public-internet path. |
| DNS | Block known unintended domains, allow approved domains and return NODATA for all other queries. |
| S3 network access | Gateway and Interface endpoints with policies enumerating authorized buckets. |
| Session authorization | Temporary job-specific credentials with a policy restricted to the relevant tenant path. |
| Execution lifecycle | Ephemeral, isolated AgentCore sessions with no persistent state between jobs. |
| Regression testing | CI simulations test DNS tunneling, unauthorized endpoints and out-of-scope S3 access. |
Key takeaways
- Untrusted execution runs in a dedicated AWS account separated from customer data, production roles and broader credentials.
- The isolated VPC has no internet gateway or NAT gateway, and its security group provides no public-internet path.
- Route 53 Resolver DNS Firewall blocks known unintended domains, allows approved domains and returns NODATA for all remaining queries.
- S3 VPC endpoint policies restrict reachable buckets independently of IAM authorization.
- Temporary job-specific credentials use session policies to limit each execution to the relevant tenant path.
- CI exfiltration simulations test DNS tunneling, unauthorized connections and access beyond approved S3 buckets.
FAQ
How does Benchling isolate untrusted AI-generated code?
It dispatches jobs from the production account to a dedicated untrusted-code AWS account containing the AgentCore Code Interpreter VPC, while customer data, production roles and broader credentials remain in production.
How does the design restrict DNS exfiltration?
A three-priority Route 53 Resolver DNS Firewall policy blocks known unintended domains, allows approved domains and returns NODATA for every other query.
How is S3 access limited?
VPC endpoint policies enumerate authorized buckets, while temporary job-specific credentials and session policies restrict each session to the relevant tenant path.
Why does Benchling use temporary credentials?
Temporary credentials avoid maintaining a static IAM role for each tenant and allow access to be narrowed for every dispatched job.
How are security regressions tested?
The CI suite attempts encoded DNS queries, direct connections to unauthorized endpoints and access to S3 buckets outside the endpoint policy; successful unauthorized activity fails the pipeline.
Are Benchling’s reported security outcomes independently verified?
No. The reported deployment scale, zero incidents and zero cross-tenant leakage are Benchling claims presented in an AWS-authored implementation report, not independently corroborated measurements.
