Benchling details controls that isolate AI-generated code across tenants

Benchling and AWS outlined a defense-in-depth system for running AI-generated scientific code while limiting each execution job to a single customer tenant’s data. Amazon Bedrock AgentCore Code Interpreter runs in a locked-down virtual private cloud, with separate controls for account exposure, domain resolution, reachable AWS services and temporary data permissions.

According to the companies, the VPC-mode deployment began in early April 2026 and now processes more than 600 code-execution sessions a day across more than 250 distinct tenants a week. Benchling also reported zero security incidents and zero cross-tenant data leakage since deployment. The case study, however, did not include an independent audit, incident record or telemetry to support those usage and security-outcome claims.

The first boundary is a dedicated “Untrusted Code Account” separate from Benchling’s production account. Agent-generated code runs there, away from the production account’s customer data and access roles. In VPC mode, AgentCore creates network interfaces with private IP addresses in selected subnets, while attached security groups determine which resources the tool can reach. Benchling’s configuration has no internet gateway or NAT gateway; a dedicated security group, network access-control lists and prefix-list routes limit traffic to approved paths. This deployment concerns Code Interpreter’s execution environment; a separate AgentCore Runtime update focuses on memory management and snapshot-based starts.

A three-tier Route 53 Resolver DNS Firewall policy governs DNS. A priority-10 rule blocks explicitly identified malicious domains, a priority-100 allow list permits required S3 endpoints and other approved domains, and a priority-200 catch-all returns NODATA for everything else. AWS documentation describes the same allow-list-before-wildcard-block pattern, with lower numeric priorities evaluated first. The NODATA response stops an unapproved domain from resolving, including one whose subdomain labels encode data for DNS tunneling.

Permitted service traffic passes through an S3 Gateway endpoint for in-region access and an Interface endpoint for cross-region access. Endpoint policies specify which S3 buckets each path can reach, while routing and network ACLs narrow traffic further. AWS notes that a VPC endpoint policy controls use of the endpoint but does not replace identity or resource policies. It therefore acts as a separate enforcement layer, not the only permission check.

Instead of maintaining a standing IAM role for every tenant, Benchling issues temporary AWS Security Token Service credentials for each job. At dispatch, a session policy limits S3 access to the assigned tenant’s path prefix within an authorized bucket. AWS documents that session permissions are the intersection of the role’s identity policy and the session policy, preventing the temporary session from gaining permissions that the underlying role lacks.

AWS and Benchling said proof-of-concept tests received NODATA for domains outside the allow list and rejected direct connections to unauthorized endpoints and requests for S3 buckets outside the endpoint-policy scope. Benchling later added those exfiltration simulations to continuous integration. A test that resolves a prohibited domain, reaches an outside endpoint or moves data beyond approved buckets blocks the release. The companies did not publish the test code, configurations, logs or results needed to reproduce those findings independently.