# How Benchling secured multi-tenant AI agents with Amazon Bedrock AgentCore > Source: > Published: 2026-09-21 16:27:34+00:00 ## [Artificial Intelligence](https://aws.amazon.com/blogs/machine-learning/) # How Benchling secured multi-tenant AI agents with Amazon Bedrock AgentCore When Benchling needed to run AI agent-generated scientific code across thousands of life sciences tenants, their security team found that traditional sandboxing wasn’t enough. Today, this architecture processes more than 600 code execution sessions per day across more than 250 tenants per week with zero security incidents. Standard network controls block HTTP, restrict egress ports, and limit outbound connections. However, DNS resolution is often still permitted, and even when system defaults restrict it, you may not have visibility into or control over those restrictions. This is the challenge [Benchling](https://www.benchling.com/) faced when deploying AI agents across thousands of life sciences tenants. Their security team needed full control over network isolation beyond the system defaults to meet their threat model for executing untrusted code at scale. In this post, we show how Benchling built a defense-in-depth security architecture to run AI agent-generated scientific code across thousands of life sciences tenants. Amazon Bedrock AgentCore is a platform to build, connect, and optimize agents at scale, with any framework or model. Benchling uses AgentCore Code Interpreter, a capability of [Amazon Bedrock AgentCore](https://aws.amazon.com/bedrock/agentcore/), in [Amazon Virtual Private Cloud (VPC)](https://docs.aws.amazon.com/toolkit-for-visual-studio/latest/user-guide/vpc-tkv.html) mode. This approach combines account-level isolation, Amazon Route 53 Resolver DNS Firewall, and VPC endpoint policies to help prevent data exfiltration while enforcing per-job data access controls. ## Multi-tenant code execution security Benchling’s AI application generates scientific code that runs on behalf of researchers across thousands of tenants. The primary use case is AI agent-generated scientific code, though Code Interpreter is also used for simpler calculations and as a code-generation sandbox. The security requirements are strict. Each session must access only that tenant’s data, with no cross-tenant visibility. Code can’t establish unauthorized network connections or exfiltrate data through any vector. Every execution session must be fully isolated, and the solution cannot require one AWS Identity and Access Management (IAM) role per tenant, as that would create unsustainable role sprawl at this scale. During their security review, the Benchling team evaluated the network isolation properties of each Code Interpreter network mode against their threat model. While Sandbox mode restricts outbound access to [Amazon Simple Storage Service (Amazon S3)](https://aws.amazon.com/s3/) operations, Benchling’s security posture requires customer-controlled network isolation. They needed to define exactly which domains can resolve and which endpoints are reachable. They also needed to continuously validate those controls through their own integration test suite. For an application handling sensitive scientific data across thousands of regulated life sciences tenants, relying solely on application-managed network restrictions wasn’t sufficient. They needed a solution where Benchling owned the security controls end to end. It had to block unauthorized network vectors, including DNS, without managing per-tenant IAM role sprawl or exposing their main production account to untrusted execution environments. ## Solution architecture overview Figure 1 shows the complete solution architecture. On the left, the Production Account contains the Benchling Stack, IAM Roles, AWS STS, and Customer Data in Amazon S3. Tasks are dispatched to the Untrusted Code Account on the right, a separate AWS account containing the ACCI VPC. This VPC has no internet gateway and no NAT gateway. The Code Interpreter runs inside a dedicated Security Group restricted to port 443, with no outbound path to the public internet. DNS queries from the Code Interpreter are evaluated by Route 53 Resolver DNS Firewall, which applies a three-priority resolver policy. Priority 10 blocks known malicious domains, Priority 100 allows only explicitly listed endpoints, and Priority 200 blocks the remaining queries. Below the Security Group, VPC Endpoints provide the only permitted network paths. An S3 Gateway endpoint and an Interface endpoint handle authorized S3 access, while NACLs and Prefix List routing restrict traffic to only these endpoints. Per-job credentials are injected into each session through AWS STS from the Production Account, scoping data access dynamically. A Continuous Validation suite runs integration tests that simulate exfiltration attempts against this configuration. Benchling’s solution uses a dedicated AWS account for untrusted code execution, separate from their main production account. AI-generated code runs in this isolated “Untrusted Code Account,” providing scope containment. If something goes wrong, the main Benchling production account, with its customer data and access roles, is not directly exposed. This untrusted code account hosts AgentCore Code Interpreter (ACCI) alongside Benchling’s existing container-based execution environment, which uses gVisor (a container sandbox runtime that intercepts application system calls to provide kernel-level isolation) for per-job isolation. The gVisor environment is Benchling’s pre-existing compute isolation layer and isn’t part of the pattern prescribed in this post. Both execution environments have their own IAM roles with scoped permissions, making sure that neither can escalate access beyond its intended boundary. When a task is dispatched from the production account to the untrusted account, data access is scoped per job. Only the specific data needed for that job is made accessible. Production account credentials and the broader customer data store are not directly exposed to untrusted code. Maintaining one IAM role per tenant would create unsustainable role sprawl across thousands of tenants. Instead, Benchling injects credentials into each ACCI session on a per-job basis through AWS Security Token Service (AWS STS), scoping access dynamically without accumulating static roles. ## DNS Firewall configuration The ACCI VPC is designed with a “nothing unless explicitly allowed” philosophy. There’s no internet gateway and no NAT gateway. Code running in this VPC can’t reach the internet directly. The centerpiece of the DNS exfiltration defense is Amazon Route 53 Resolver DNS Firewall. It uses a three-priority resolver policy following a denylist, allowlist, deny all pattern: ### P10: High block (explicit deny list) The first rule evaluated, at highest priority, blocks resolution of known unintended domains. This catches obvious threats before they hit any allow logic. For example, if Benchling identifies domains associated with known data exfiltration toolkits or command and control infrastructure, those domains are blocked at this layer regardless of any other configuration. This rule exists as a fast path for threat intelligence. Rather than relying solely on the absence of a domain from the allow list, Benchling can proactively enumerate hostile endpoints and make sure they are rejected immediately. This rule also provides observability. Queries that hit the explicit deny list generate DNS Firewall logs, signaling potential malicious activity and giving the security team an early warning that code in the sandbox is attempting suspicious resolution. ### P100: Allow list (S3 buckets and explicit domains) The second tier is an allow list that permits DNS resolution only for explicitly listed domains. In practice, this is limited to the S3 endpoints needed for data access and usually nothing else. The allow list is deliberately minimal because every permitted domain represents a potential exfiltration vector. Benchling scopes resolution to only the specific S3 bucket endpoints required for job execution. Even if malicious code attempts to contact a legitimate AWS service endpoint for unintended purposes, it cannot resolve that endpoint unless Benchling has explicitly approved it. This gives Benchling full ownership of the network boundary. Unlike relying on system defaults that may change between service versions, the allow list is a customer-controlled artifact that Benchling can audit, version, and update on their own schedule. ### P200: Block all (catch-all NODATA) The final rule is a catch-all that returns NODATA for any DNS query not explicitly allowed by P100. This is what makes DNS exfiltration impossible. In a typical DNS tunneling attack, malicious code encodes stolen data as subdomain labels in a DNS query (for example, base64payload.example.com) and relies on recursive resolution to deliver that query to a bad actor-controlled authoritative nameserver. With this catch-all in place, every domain not on the strict allow list receives a NODATA response. There is no resolution path for encoded exfiltration queries to traverse. The DNS recursion chain is broken at the very first hop. This final rule is what transforms the VPC from “restricted” to “sealed.” Without it, any new domain or overlooked endpoint would default to permitted resolution. With it, the security posture is inverted: nothing resolves unless Benchling has made a deliberate decision to allow it. ## Continuous validation Benchling’s Product Security team first proved this approach effective in a proof-of-concept VPC. They tested each layer of the defense individually. DNS tunneling attempts confirmed that the Route 53 Resolver DNS Firewall returned NODATA for any domain not on the explicit allow list. Direct IP connection attempts confirmed that prefix list routing and NACLs restricted traffic to port 443 and ephemeral ports only, with no path to arbitrary external hosts. API call attempts confirmed that VPC endpoint policies rejected requests targeting any S3 bucket outside the scoped set. The absence of an internet gateway, NAT gateway, and default security group meant there was simply no outbound path for traffic that bypassed these controls. After the proof of concept validated the architecture, Benchling’s Infrastructure team incorporated these exfiltration simulations into their continuous integration test suite. The tests exercise the same vectors a real bad actor would use. These include DNS tunneling through encoded subdomain queries, direct connections to unauthorized endpoints, and attempts to reach S3 buckets outside the VPCE policy scope. If any test resolves a domain it shouldn’t, reaches an external endpoint, or moves data outside the approved buckets, the pipeline fails and blocks the release. This approach matters because security configurations are not static. VPC settings change as infrastructure evolves, new endpoints get added to support feature development, and IAM policies are updated as teams onboard new services. Without continuous validation, a configuration that was secure at deployment time could silently degrade as the environment around it changes. By treating exfiltration resistance as a testable property rather than a one-time setup, Benchling makes sure that any future infrastructure change that inadvertently weakens the security boundary is caught before it reaches production. ## VPC endpoint policies and data access controls With no internet gateway or NAT gateway in the VPC, AWS service access must flow through VPC endpoints. Benchling deploys a Gateway endpoint for in-region Amazon S3 access and an Interface endpoint for cross-region S3 access. Each endpoint has an attached policy that explicitly lists which S3 buckets it is permitted to reach. Any request targeting a bucket not in that policy is rejected at the network layer before it reaches S3. This creates a defense independent of IAM. Even if untrusted code obtains valid credentials for a bucket it should not access, the endpoint policy blocks the request. Credentials restrict what a session is authorized to do, and endpoint policies restrict what the network is physically capable of delivering. Rather than granting the ACCI role broad access to all tenant buckets, Benchling injects scoped credentials into each session on a per-job basis through AWS STS. A compromised session can only reach the one tenant it was dispatched to serve. Traffic is further constrained by prefix list routing and NACLs that restrict communication to port 443 and ephemeral return ports only. The Code Interpreter runs in a dedicated security group with no default fallback rules. There’s no port, no protocol, and no network path available for data to leave the environment except through the explicitly scoped VPC endpoints. ### S3 access through Gateway VPC endpoints Benchling configures Gateway VPC endpoints for in-region S3 access and Interface VPC endpoints for cross-region S3 access. Each endpoint has an attached VPCE policy that explicitly lists only the specific S3 buckets authorized for a given execution context. Any API call targeting a bucket not in that policy is rejected at the network layer before it reaches the S3 service. This means that even if untrusted code somehow obtained valid credentials for another tenant’s bucket, the request would still fail. The network itself refuses to carry the traffic. This creates a defense independent of IAM, so credential theft alone is not sufficient to access unauthorized data. ### Per-job credential scoping Rather than pre-provisioning IAM roles for each of thousands of tenants, Benchling injects scoped credentials into each ACCI session through AWS Security Token Service (AWS STS). Each job receives only the permissions needed for its specific tenant’s data. The production account determines what data a job can access, generates appropriately scoped temporary credentials, and injects them into the session at dispatch time. The Code Interpreter Execution Role has S3 access restricted to the main stack bucket. At launch time, a session policy is passed into each Code Interpreter execution that restricts S3 access to the specific tenant’s path prefix within the authorized bucket. This makes sure that code running inside the sandbox can only reach data belonging to the tenant it was dispatched to serve. This is the “per-job data export scoping” shown in the architecture. Benchling evaluated the alternative of granting the ACCI role broad access to all tenant buckets and rejected it because a single compromised session would then have a path to any tenant’s data. ### Network-layer lockdown Beyond DNS Firewall and VPC endpoint policies, NACLs restrict traffic to port 443 and ephemeral return ports only, prefix list routing makes sure traffic can only reach VPC endpoints, and the Code Interpreter runs in a dedicated security group with no default fallback rules. The attack surface is reduced to the Code Interpreter and its scoped VPC endpoints alone. ## Why AgentCore Code Interpreter compared to custom sandboxing Before adopting AgentCore, Benchling’s team evaluated building their own sandboxing solution. The requirements were clear. They needed ephemeral execution sessions, per-job isolation, no persistent state, and the ability to run inside a VPC where they could apply their own network security controls. Building this in-house would have meant designing custom container orchestration, implementing sandbox lifecycle management, and building network isolation primitives from scratch. They would also need to continuously patch security vulnerabilities while keeping pace with evolving threat vectors. This represents significant ongoing engineering investment diverted from Benchling’s core product, with no differentiation for their customers. AgentCore Code Interpreter in VPC mode bypassed that entire workstream. Each session is isolated and short-lived, with no persistent state between jobs. AWS handles the sandbox lifecycle, including patching, scaling, and hardening the execution environment. Running Code Interpreter inside Benchling’s own locked-down VPC meant they could layer existing AWS security primitives such as DNS Firewall, VPC endpoint policies, and NACLs on top without building custom networking. This freed Benchling’s infrastructure team to focus on product security controls rather than sandbox maintenance. *“We were able to buy instead of build a secure solution with AgentCore Code Interpreter.”* — Jeremy Stashewsky, Application Security Engineer, Benchling ## Results and business impact Since deploying AgentCore Code Interpreter in VPC mode in early April 2026, Benchling has scaled to more than 600 code execution sessions per day, serving AI agent-generated scientific workloads across more than 250 distinct tenants per week. This demonstrates broad adoption across their customer base without compromise to their security posture. Since deployment, Benchling has reported zero security incidents and zero cross-tenant data leakage. *“Giving AI agents a code interpreter is non-negotiable for the scientific accuracy our customers demand, but our threat model assumes any agent- or user-written code could be unintended. We needed a true sandbox with zero network access except for S3. AgentCore Code Interpreter in VPC mode, combined with Route 53 DNS Firewall and VPC endpoints, let us close every exfiltration vector we tested (including DNS) without building it ourselves.”* — Benchling ## Conclusion Running AI-generated code in a multi-tenant environment introduces exfiltration vectors that traditional sandboxing does not fully address. DNS resolution, in particular, is often overlooked because standard network controls focus on HTTP, egress ports, and direct connections. The pattern Benchling implemented provides a blueprint for closing this gap without building custom sandboxing infrastructure. The architecture starts with account-level isolation, separating untrusted code execution from production systems entirely. Amazon Bedrock AgentCore Code Interpreter in VPC mode provides managed, ephemeral execution within that isolated account. Route 53 Resolver DNS Firewall seals the DNS exfiltration vector with a deny list, allow list, deny all policy. VPC endpoint policies restrict service access to only the specific S3 buckets each job requires. Per-job credential scoping through AWS STS makes sure that even a fully compromised session cannot reach beyond a single tenant’s data. No single control in this architecture is sufficient on its own. It’s the combination of all these layers, validated continuously through automated testing, that bypasses entire classes of exfiltration vectors. Each layer catches what the others might miss, and the continuous validation makes sure the posture holds as infrastructure evolves. To get started with Amazon Bedrock AgentCore Code Interpreter in VPC mode, see the [Code Interpreter documentation](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/code-interpreter-tool.html) and the [VPC configuration guide](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/agentcore-vpc.html). You can deploy a locked-down VPC with Route 53 DNS Firewall and VPC endpoint policies following the patterns described in this post. If you are already running untrusted code in a sandboxed environment, consider whether your current architecture accounts for DNS as an exfiltration channel, and whether you have continuous validation proving that it does. ## About Benchling [Benchling](https://www.benchling.com/) is the AI platform for biotech R&D, unifying scientific data and automating workflows to accelerate discovery and development. Trusted by more than 1,300 companies worldwide, from pioneering startups to global leaders like Merck, Moderna, and Sanofi, Benchling gives scientists a single place to capture, connect, and act on data across the entire R&D lifecycle. With [Benchling AI](https://www.benchling.com/ai), agents and models work directly inside scientific workflows, grounded in structured data. The result is faster teams, better molecules, and breakthroughs that reach the world sooner.