Benchling shifted AI‑generated scientific code from a shared sandbox into a dedicated AWS account that runs Bedrock AgentCore Code Interpreter in VPC mode, guarded by Route 53 Resolver DNS Firewall and strict VPC endpoint policies. The move replaces ad‑hoc network restrictions with a repeatable, account‑level isolation that scales across hundreds of tenants without proliferating IAM roles.
Why the previous sandbox model was insufficient
Benchling’s threat model required each execution session to see only its tenant’s data and to be unable to open arbitrary network connections. The default sandbox mode limited outbound traffic to Amazon S3 but still allowed DNS resolution and relied on system defaults for egress control. For a platform serving regulated life‑science data, that level of control did not meet the required assurance because DNS queries could leak information and the sandbox could not enforce explicit allow‑lists for external endpoints.
Defense‑in‑depth architecture with Bedrock AgentCore
The new design separates the production environment from code execution by using two AWS accounts:
- Production Account – holds the Benchling application stack, IAM roles, and customer data in Amazon S3.
- Untrusted Code Account – contains a VPC dedicated to AgentCore Code Interpreter (ACCI). The VPC has no internet gateway or NAT gateway, eliminating any default path to the public internet.
Within the ACCI VPC, a security group permits only outbound TCP 443 traffic, and all traffic must traverse VPC endpoints. An S3 gateway endpoint and an interface endpoint provide the sole authorized path to Amazon S3. Network ACLs and prefix‑list routing further restrict traffic to these endpoints.
DNS queries from the interpreter are inspected by Route 53 Resolver DNS Firewall, which applies three priority rules:
- Priority 10 – block known malicious domains.
- Priority 100 – allow only domains explicitly listed by Benchling.
- Priority 200 – block any remaining queries.
Per‑job credentials are generated in the Production Account via AWS STS and injected into each session, dynamically scoping S3 access to the tenant that owns the job. This approach avoids creating a separate IAM role for every tenant while still enforcing data‑level isolation.
Operational impact and validation
The architecture introduces a continuous validation suite that runs integration tests simulating exfiltration attempts. These tests verify that DNS firewall rules, endpoint policies, and security‑group settings remain effective after any change. Because the untrusted code runs in its own account, any breach is contained and does not expose the primary production resources.
Key operational considerations include:
- Maintaining the DNS firewall rule set as new services are required.
- Ensuring the STS session policy correctly reflects tenant‑specific data permissions.
- Monitoring VPC endpoint usage to detect unexpected traffic patterns.
Related CloudNinjas coverage: AWS.
What This Means For Practitioners
Engineers building multi‑tenant AI services should treat network isolation as a primary control, not a secondary sandbox feature. Using a dedicated account with VPC‑only connectivity, DNS firewall policies, and per‑job STS credentials provides a scalable way to prevent cross‑tenant data leakage without exploding IAM role count. Teams should implement automated tests that attempt common exfiltration vectors to keep the isolation guarantees verifiable over time.
