Benchling 如何借助 Amazon Bedrock AgentCore 保护多租户 AI Agent

当 Benchling 需要为数千家生命科学租户运行由 AI Agent 生成的科研代码时，其安全团队发现，传统沙箱机制并不足够。如今，这套架构每天处理超过 600 次代码执行会话，每周覆盖超过 250 个租户，且未发生任何安全事件。标准网络控制能够阻止 HTTP、限制出口端口并限制出站连接。然而，DNS 解析通常仍被允许；即使系统默认设置对其加以限制，你也未必能够获得这些限制的可见性或控制权。这正是 Benchling 在数千家生命科学租户中部署 AI Agent 时面临的挑战。其安全团队需要在系统默认设置之外，全面控制网络隔离，以满足大规模执行不受信任代码时的威胁模型要求。

本文介绍 Benchling 如何构建一套纵深防御安全架构，在数千家生命科学租户中运行 AI Agent 生成的科研代码。Amazon Bedrock AgentCore 是一个可使用任意框架或模型大规模构建、连接和优化 Agent 的平台。Benchling 使用 Amazon Bedrock AgentCore 的一项能力 AgentCore Code Interpreter，并以 Amazon Virtual Private Cloud (VPC) 模式运行。该方法结合账户级隔离、Amazon Route 53 Resolver DNS Firewall 和 VPC 终端节点策略，在实施按作业数据访问控制的同时，帮助防止数据外泄。

多租户代码执行安全

Benchling 的 AI 应用会生成科研代码，并代表数千家租户中的研究人员运行这些代码。其主要用例是 AI Agent 生成的科研代码，不过 Code Interpreter 也用于较简单的计算以及充当代码生成沙箱。安全要求十分严格。每个会话只能访问该租户的数据，不能看到其他租户的数据。代码不得建立未经授权的网络连接，也不得通过任何途径外泄数据。每个执行会话都必须完全隔离，并且该方案不能要求每个租户拥有一个 AWS Identity and Access Management (IAM) 角色，因为在这一规模下会造成难以维持的角色膨胀。

在安全审查期间，Benchling 团队根据其威胁模型，评估了每种 Code Interpreter 网络模式的网络隔离特性。尽管 Sandbox 模式限制对 Amazon Simple Storage Service (Amazon S3) 操作的出站访问，但 Benchling 的安全态势要求由客户控制网络隔离。他们需要精确定义哪些域名可以解析、哪些终端节点可以访问。他们还需要通过自身的集成测试套件持续验证这些控制措施。对于一个要处理数千家受监管生命科学租户敏感科研数据的应用，仅依赖由应用管理的网络限制并不足够。他们需要一种由 Benchling 端到端掌控安全控制措施的方案。该方案必须阻止包括 DNS 在内的未经授权网络途径，同时避免管理按租户划分的 IAM 角色膨胀，也不能让其主生产账户暴露于不受信任的执行环境中。

解决方案架构概览

图 1：Benchling 用于多租户代码执行的纵深防御架构

图 1 展示了完整的解决方案架构。左侧的生产账户包含 Benchling Stack、IAM Roles、AWS STS 以及 Amazon S3 中的客户数据。任务被分派至右侧的不受信任代码账户，这是一个包含 ACCI VPC 的独立 AWS 账户。该 VPC 没有互联网网关，也没有 NAT 网关。Code Interpreter 在一个专用安全组内运行，该安全组仅限 443 端口，且没有通向公共互联网的出站路径。

来自 Code Interpreter 的 DNS 查询将由 Route 53 Resolver DNS Firewall 进行评估，该服务应用三优先级解析器策略。优先级 10 阻止已知恶意域名，优先级 100 仅允许明确列出的终端节点，优先级 200 则阻止其余查询。在安全组之下，VPC Endpoints 提供唯一允许的网络路径。一个 S3 Gateway 终端节点和一个 Interface 终端节点处理经授权的 S3 访问，而 NACL 和 Prefix List 路由将流量限制为仅能访问这些终端节点。生产账户通过 AWS STS 向每个会话注入按作业划分的凭证，从而动态限定数据访问范围。持续验证套件会运行集成测试，针对该配置模拟数据外泄尝试。

Benchling 的解决方案为不受信任代码执行使用一个专用 AWS 账户，该账户与其主生产账户分离。AI 生成的代码在这个隔离的“不受信任代码账户”中运行，实现作用域隔离。如果出现问题，包含客户数据和访问角色的 Benchling 主生产账户不会被直接暴露。

这个不受信任代码账户托管了 AgentCore Code Interpreter (ACCI)，以及 Benchling 既有的基于容器的执行环境。后者使用 gVisor（一种容器沙箱运行时，通过拦截应用程序系统调用提供内核级隔离）实现按作业隔离。gVisor 环境是 Benchling 既有的计算隔离层，并不属于本文规定模式的一部分。两个执行环境都拥有各自权限范围受限的 IAM 角色，确保任何一方都无法将访问权限提升至其预定边界之外。

当任务从生产账户分派到不受信任账户时，数据访问将按作业限定范围。只有该作业所需的特定数据可被访问。生产账户凭证和更广泛的客户数据存储不会直接暴露给不受信任代码。

为数千家租户分别维护一个 IAM 角色会造成难以维持的角色膨胀。因此，Benchling 通过 AWS Security Token Service (AWS STS) 按作业向每个 ACCI 会话注入凭证，在不累积静态角色的情况下动态限定访问范围。

DNS Firewall 配置

ACCI VPC 遵循“除非被明确允许，否则一律不允许”的设计理念。它没有互联网网关，也没有 NAT 网关。在该 VPC 中运行的代码无法直接访问互联网。DNS 数据外泄防御的核心是 Amazon Route 53 Resolver DNS Firewall。它采用遵循“拒绝名单、允许名单、默认全部拒绝”模式的三优先级解析器策略：

P10：高优先级阻止（显式拒绝名单）

以最高优先级最先评估的第一条规则，会阻止已知非预期域名的解析。这样可在它们触及任何允许逻辑之前拦截明显威胁。例如，如果 Benchling 识别出与已知数据外泄工具包或命令与控制基础设施相关的域名，无论其他配置如何，这些域名都会在此层被阻止。这条规则为威胁情报提供快速处理路径。Benchling 不必仅依赖某个域名不在允许名单中这一事实，而是可以主动列举恶意终端节点，并确保其立即被拒绝。这条规则还提供了可观测性。命中显式拒绝名单的查询会生成 DNS Firewall 日志，表明可能存在恶意活动，并让安全团队尽早获知沙箱中的代码正尝试进行可疑解析。

P100：允许名单（S3 存储桶和显式域名）

第二层是允许名单，仅允许解析明确列出的域名。实际应用中，这通常仅限于数据访问所需的 S3 终端节点，通常不包含其他任何内容。允许名单被刻意保持在最小范围内，因为每个被允许的域名都代表一个潜在的数据外泄途径。Benchling 将解析范围限定为作业执行所需的特定 S3 存储桶终端节点。即使恶意代码尝试出于非预期目的联系合法的 AWS 服务终端节点，除非 Benchling 明确批准，否则它也无法解析该终端节点。这使 Benchling 能够全面掌控网络边界。与依赖可能在不同服务版本之间变化的系统默认设置不同，允许名单是由客户控制的工件，Benchling 可以自行审计、版本化并按自己的计划更新。

P200：全部阻止（兜底 NODATA）

最后一条规则是兜底规则：对于未被 P100 明确允许的任何 DNS 查询，均返回 NODATA。这正是使 DNS 数据外泄无法实现的关键。在典型 DNS 隧道攻击中，恶意代码会将窃取的数据编码为 DNS 查询中的子域标签（例如，base64payload.example.com），并依赖递归解析将该查询传递给由攻击者控制的权威名称服务器。在此兜底规则生效后，所有不在严格允许名单中的域名都会收到 NODATA 响应。编码后的外泄查询没有可通过的解析路径。DNS 递归链会在最初的第一跳就被切断。最后这条规则使 VPC 从“受限”转变为“密封”。如果没有它，任何新域名或被遗漏的终端节点都会默认允许解析。有了它，安全态势就被反转：除非 Benchling 有意决定允许，否则任何内容都无法解析。

持续验证

Benchling 的产品安全团队首先在一个概念验证 VPC 中证明了该方法的有效性。他们逐层测试防御机制。DNS 隧道尝试确认，对于任何不在显式允许名单中的域名，Route 53 Resolver DNS Firewall 都会返回 NODATA。直接 IP 连接尝试确认，前缀列表路由和 NACL 将流量限制为仅能使用 443 端口和临时端口，且不存在通往任意外部主机的路径。API 调用尝试确认，VPC 终端节点策略会拒绝以限定集合之外的任何 S3 存储桶为目标的请求。由于没有互联网网关、NAT 网关和默认安全组，根本不存在能够绕过这些控制措施的出站流量路径。

在概念验证确认该架构后，Benchling 的基础设施团队将这些外泄模拟纳入持续集成测试套件。测试覆盖真实攻击者会采用的相同攻击途径，包括通过编码子域查询进行 DNS 隧道、直接连接未经授权的终端节点，以及尝试访问 VPCE 策略范围之外的 S3 存储桶。如果任何测试解析了不应解析的域名、访问了外部终端节点，或将数据移出获批准的存储桶，流水线就会失败并阻止发布。

这一方法很重要，因为安全配置并非静态不变。随着基础设施演进，VPC 设置会发生变化；为支持功能开发会新增终端节点；随着团队接入新服务，IAM 策略也会更新。如果没有持续验证，部署时安全的配置可能会随着周边环境变化而在不知不觉中退化。通过将抗数据外泄能力视为一种可测试的属性，而非一次性设置，Benchling 确保任何未来无意中削弱安全边界的基础设施变更，都会在进入生产环境之前被发现。

VPC 终端节点策略和数据访问控制

由于 VPC 中没有互联网网关或 NAT 网关，AWS 服务访问必须经由 VPC 终端节点流转。Benchling 为区域内 Amazon S3 访问部署 Gateway 终端节点，并为跨区域 S3 访问部署 Interface 终端节点。每个终端节点都附加了一项策略，明确列出其被允许访问的 S3 存储桶。任何以策略之外的存储桶为目标的请求，都会在到达 S3 前于网络层被拒绝。

这构成了独立于 IAM 的一道防线。即使不受信任代码获得了其本不应访问的某个存储桶的有效凭证，终端节点策略仍会阻止请求。凭证限制会话被授权执行的操作，而终端节点策略限制网络在物理上能够传递的请求。Benchling 不会向 ACCI 角色授予访问所有租户存储桶的广泛权限，而是通过 AWS STS 按作业向每个会话注入范围受限的凭证。遭入侵的会话只能访问其被分派服务的那个租户。

流量还会受到前缀列表路由和 NACL 的进一步限制，只允许通过 443 端口和临时返回端口进行通信。Code Interpreter 在一个专用安全组中运行，没有默认回退规则。环境中不存在可用于让数据离开的端口、协议或网络路径，唯一例外是经过明确范围限定的 VPC 终端节点。

通过 Gateway VPC 终端节点访问 S3

Benchling 为区域内 S3 访问配置 Gateway VPC 终端节点，并为跨区域 S3 访问配置 Interface VPC 终端节点。每个终端节点都附加了 VPCE 策略，其中仅明确列出针对给定执行上下文获得授权的特定 S3 存储桶。任何以策略之外的存储桶为目标的 API 调用，都会在到达 S3 服务前于网络层被拒绝。这意味着，即使不受信任代码以某种方式获得了另一个租户存储桶的有效凭证，请求仍会失败。网络本身会拒绝传输该流量。这构成了独立于 IAM 的防线，因此仅窃取凭证不足以访问未经授权的数据。

按作业划分凭证范围

Benchling 并未为数千家租户预先配置 IAM 角色，而是通过 AWS Security Token Service (AWS STS) 向每个 ACCI 会话注入范围受限的凭证。每项作业只获得访问其特定租户数据所需的权限。生产账户决定什么

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 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, in Amazon Virtual Private Cloud (VPC) 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) 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: Benchling’s defense-in-depth architecture for multi-tenant code execution

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 and the VPC configuration guide. 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 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, 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.

---

About the authors

Jeremy Stashewsky

Jeremy is an Application Security Engineer at Benchling.

Meghana Sreenivas

Meghana is a Solutions Architect at AWS, where she partners with ISV customers to design secure, scalable multi-tenant architectures spanning data platforms and AI workloads. She is a co-author of this post and led the technical engagement with Benchling.

Anil Gurrala

Anil is a Sr Solutions Architect at AWS focusing on AI/ML and agentic architectures for ISV customers. He works with partners to design and deploy secure, scalable agent solutions using Amazon Bedrock and AgentCore.