Benchling 如何用 Amazon Bedrock AgentCore 保障多租户 AI 智能体的安全

AWS ML Blog 2026-09-22T05:40:48.827390

Benchling 需要在上千个生命科学租户中运行 AI 代理生成的科学代码，其安全团队发现，传统的沙箱机制远远不够。如今，这套架构每天处理超过 600 次代码执行会话，每周覆盖 250 多个租户，实现了零安全事件。

标准网络管控会拦截 HTTP、限制出口端口、约束对外连接。但 DNS 解析往往仍然允许，即便系统默认设置做了限制，你可能也看不到、管不了这些限制。Benchling 在上千个生命科学租户中部署 AI 代理时，碰到的正是这个难题。安全团队需要完全掌控网络隔离，不能只依赖系统默认配置，才能满足大规模执行不可信代码的威胁模型要求。

本文将介绍 Benchling 如何构建纵深防御安全架构，在上千个生命科学租户中运行 AI 代理生成的科学代码。

Amazon Bedrock AgentCore 是一个用于大规模构建、连接和优化代理的平台，支持任意框架和模型。Benchling 在 Amazon Virtual Private Cloud（VPC，虚拟私有云）模式下使用了 AgentCore Code Interpreter——这是 Amazon Bedrock AgentCore 的一项能力。该方案结合了账户级隔离、Amazon Route 53 Resolver DNS Firewall 和 VPC 终端节点策略，在防止数据外泄的同时，执行按任务粒度的数据访问控制。

多租户代码执行安全

Benchling 的 AI 应用会生成科学代码，代表上千个租户中的研究人员运行。主要场景是 AI 代理生成科学代码，不过 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 中的客户数据。任务会被派发到右侧的非受信代码账户（Untrusted Code Account）——这是一个独立的 AWS 账户，里面运行着 ACCI VPC。该 VPC 没有互联网网关，也没有 NAT 网关。

Code Interpreter 运行在一个专用安全组内，只开放 443 端口，没有任何通往公网的出站路径。Code Interpreter 发出的 DNS 查询由 Route 53 Resolver DNS Firewall 处理，它会按三级优先级执行解析策略：

安全组下方是 VPC Endpoints，它们构成了唯一被允许的网络通路。S3 Gateway endpoint 和 Interface endpoint 负责处理授权的 S3 访问，NACLs 和 Prefix List 路由则把流量限制在这些端点之内。

每个任务的凭证通过 AWS STS 从生产账号注入到各会话中，从而动态限定数据访问范围。一套持续验证（Continuous Validation）测试套件会运行集成测试，模拟针对该配置的数据窃取尝试。

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 存储桶和显式域名）

第二层是允许列表，只允许对明确列出的域名进行 DNS 解析。实际使用中，仅限于数据访问所需的 S3 端点，通常没有其他内容。这份允许列表刻意保持最小化，因为每个被放行的域名都可能成为数据外传的通道。Benchling 把解析范围限制在任务执行所需的特定 S3 存储桶端点上。即使恶意代码试图联系一个合法的 AWS 服务端点用于非预期目的，只要 Benchling 没有明确批准，它也无法解析该端点。

这让 Benchling 对网络边界拥有完全的掌控权。与依赖可能随服务版本变化的系统默认值不同，允许列表是客户掌控的产物，Benchling 可以自行审计、版本化并按自己的节奏更新。

P200：全部阻止（兜底的 NODATA）

最后一条规则是兜底规则，对任何未被 P100 明确允许的 DNS 查询返回 NODATA。正是这条规则让 DNS 数据外传变得不可能。

在典型的 DNS 隧道攻击（DNS tunneling）中，恶意代码会把窃取的数据编码成子域名标签，塞进 DNS 查询里（例如 base64payload.example.com），然后借助递归解析把这个查询送到攻击者控制的权威域名服务器。有了这条兜底规则，任何不在严格白名单上的域名一律收到 NODATA 响应，编码外泄的查询根本没有解析路径可走。DNS 递归链在第一跳就被切断。

正是这条兜底规则，把 VPC 从「受限」变成了「封闭」。没有它，任何新出现的域名或被忽略的端点都会默认被允许解析；有了它，安全姿态直接反转——除非 Benchling 主动决定放行，否则什么域名都解析不了。

持续验证

Benchling 的产品安全团队先在一个概念验证（PoC）VPC 里验证了这套方案行之有效。他们逐层单独测试了每一道防线：

概念验证通过后，Benchling 的基础设施团队把这些数据外泄模拟加入到了持续集成（CI）测试套件里。这些测试复现的正是真实攻击者会用的手法，包括通过编码子域名查询进行 DNS 隧道、直连未授权端点，以及尝试访问 VPCE 策略范围之外的 S3 桶。只要有任何一项测试解析了本不该解析的域名、连上了外部端点，或把数据挪到了未经批准的桶之外，流水线就会失败并阻止发布。

这套做法之所以重要，是因为安全配置并非一成不变。

基础设施演进时 VPC 设置会变化，支持新功能开发会新增终端节点，团队接入新服务时 IAM 策略也会更新。如果没有持续验证，部署时安全的配置可能随着环境变化悄无声息地退化。Benchling 把防数据外泄当作一项可测试的属性，而不是一次性配置，从而确保未来任何无意中削弱安全边界的基础设施变更在上线前就被发现。

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

VPC 中没有互联网网关，也没有 NAT 网关，因此访问 AWS 服务必须走 VPC 终端节点。Benchling 部署了一个网关终端节点，用于访问区域内的 Amazon S3；另有一个接口终端节点，用于跨区域访问 S3。

每个终端节点都附加了策略，明确列出它被允许访问哪些 S3 存储桶。任何指向策略之外的存储桶的请求，都会在到达 S3 之前于网络层被拒绝。这就形成了一道独立于 IAM 的防线。即使不受信任的代码拿到了它本不该访问的存储桶的有效凭证，终端节点策略也会拦截请求。凭证限制一个会话被授权做什么，终端节点策略则限制网络实际能够送达什么。

Benchling 没有给 ACCI 角色授予访问所有租户存储桶的宽泛权限，而是通过 AWS STS 按任务向每个会话注入限定范围的凭证。一旦会话被攻破，它也只能访问自己被派去服务的那一个租户。

流量进一步受到前缀列表路由和 NACL 的约束，通信仅限 443 端口和临时返回端口。Code Interpreter 运行在专用的安全组中，没有默认兜底规则。除了明确定义范围的 VPC 终端节点，没有任何端口、协议或网络路径可以让数据离开该环境。

通过网关 VPC 终端节点访问 S3

Benchling 为区域内 S3 访问配置了网关 VPC 终端节点，为跨区域 S3 访问配置了接口 VPC 终端节点。

每个端点都绑定了 VPC 端点（VPCE）策略，策略里只列出某个执行上下文被授权访问的特定 S3 存储桶。任何指向策略之外存储桶的 API 调用，都会在网络层被拦截，根本到不了 S3 服务。这意味着，即便不可信代码不知通过什么途径拿到了访问其他租户存储桶的有效凭证，请求依然会失败——网络本身拒绝转发这些流量。这就多了一道独立于 IAM 的防线，单靠窃取凭证不足以访问未授权的数据。

按作业分配凭证

Benchling 没有为成千上万个租户逐一预置 IAM 角色，而是通过 AWS 安全令牌服务（AWS STS）向每个 ACCI 会话注入限定范围的凭证。每个作业只能拿到访问其所属租户数据所需的权限。生产账户先确定作业可以访问哪些数据，生成作用域合适的临时凭证，再在派发时把它们注入会话。

Code Interpreter 执行角色的 S3 访问权限被限制在主栈存储桶。启动时，每次 Code Interpreter 执行都会传入一份会话策略，把 S3 访问限制到授权存储桶中该租户专属的路径前缀。这确保沙箱内运行的代码只能访问它被派发服务的那个租户的数据。这就是架构图中标注的「按作业的数据导作用域（per-job data export scoping）」。

Benchling 评估过另一种做法：给 ACCI 角色开放所有租户存储桶的访问权限。他们否掉了这个方案，因为这样一来，只要有一个会话被攻破，就等于打开了通往任意租户数据的通道。

网络层封锁

除了 DNS 防火墙和 VPC 端点策略，NACL 把流量限制在 443 端口和临时的返回端口上，前缀列表路由确保流量只能到达 VPC 端点，Code Interpreter 则运行在一个专用的安全组中，没有任何默认回退规则。攻击面被压缩到只剩 Code Interpreter 及其限定范围的 VPC 端点本身。

为什么选 AgentCore Code Interpreter 而不是自建沙箱

在采用 AgentCore 之前，Benchling 团队评估过自建沙箱方案。

需求很明确：他们需要短期执行的会话、按任务隔离、不留持久状态，并且能跑在自己的 VPC（虚拟私有网络）里，方便套用自己那套网络安全管控。如果自研，就意味着要从头设计容器编排、实现沙箱生命周期管理、搭建网络隔离的基础组件，还得持续修补安全漏洞，跟上不断变化的攻击手法。这需要长期投入大量工程资源，而这些投入并不能为 Benchling 的客户带来差异化价值，反而会分散核心产品的精力。

VPC 模式下的 AgentCore Code Interpreter 直接跳过了整条自研路线。每个会话相互隔离、生命周期短，任务之间不留持久状态。AWS 负责沙箱生命周期，包括打补丁、扩缩容以及执行环境的加固。把 Code Interpreter 跑在 Benchling 自己封闭的 VPC 内，他们就能在现有 AWS 安全组件之上叠加 DNS Firewall、VPC 终端节点策略、NACL 等管控，无需自建网络层。这样一来，基础设施团队可以把精力放在产品安全管控上，而不是沙箱维护上。

“借助 AgentCore Code Interpreter，我们买到了安全方案，而不用自己去造。”——Jeremy Stashewsky，Benchling 应用安全工程师

结果与业务影响

自 2026 年 4 月初在 VPC 模式部署 AgentCore Code Interpreter 以来，Benchling 的代码执行会话已扩展到每天 600 次以上，每周为超过 250 个不同租户处理 AI 智能体生成的科研工作负载。这说明方案在客户群中被广泛采用，同时安全态势没有打折扣。部署至今，Benchling 报告的安全事件为零，跨租户数据泄漏也为零。

“要让 AI 智能体拥有代码解释器，才能满足客户对科学准确性的要求，这一点没有商量余地。但我们的威胁模型假设：任何智能体或用户编写的代码都可能不是出于本意。我们需要一个真正的沙箱，除了 S3 之外没有任何网络访问权限。”

“在 VPC 模式下运行的 AgentCore Code Interpreter，配合 Route 53 DNS Firewall 和 VPC 端点，让我们不用自己动手就堵住了测试过的所有外泄途径（包括 DNS）。”——Benchling

总结

在多租户环境中运行 AI 生成的代码，会引入传统沙箱隔离无法完全覆盖的数据外泄途径。DNS 解析尤其容易被忽视，因为常规网络控制关注的是 HTTP、出站端口和直接连接，很少管到这一层。Benchling 落地的这套方案提供了一份可参考的蓝图，不用自己造沙箱基础设施，就能补上这个缺口。

整体架构从账户级隔离开始，把不可信代码的执行环境和生产系统彻底分开。在 VPC 模式下运行的 Amazon Bedrock AgentCore Code Interpreter，在这个隔离账户里提供托管的、用完即弃的执行环境。Route 53 Resolver DNS Firewall 通过“拒绝列表、允许列表、默认全拒”的策略，封死 DNS 这条外泄通道。VPC 端点策略把服务访问限制在每个任务所需的那几个特定 S3 存储桶上。借助 AWS STS 为每个任务单独限定凭证权限，即使某个会话被完全攻破，也无法越权访问到其他租户的数据。

这套架构里没有任何单一控制措施能独当一面。真正管用的是这些层级的组合叠加，再加上持续的自动化测试验证，才能整类整类地阻断外泄途径。每一层都能接住其他层可能漏掉的情况，而持续验证则确保随着基础设施演进，这套防线依然站得住。

想上手 VPC 模式下的 Amazon Bedrock AgentCore Code Interpreter，可以参考 Code Interpreter 文档和 VPC 配置指南。你可以按照本文描述的模式，部署一个带 Route 53 DNS Firewall 和 VPC 端点策略的封锁式 VPC。如果你已经在沙箱环境中运行不可信代码，不妨想一想：现有架构有没有把 DNS 当作外泄渠道来防范？有没有持续的验证来证明它确实防住了？

关于 Benchling

Benchling 是面向生物科技研发的 AI 平台，把科研数据统一管理起来，并自动执行各类工作流程，加快发现与开发进程。全球超过 1,300 家公司都在用它，既有新兴创业公司，也有 Merck、Moderna、Sanofi 这样的行业巨头。Benchling 让科学家在一个地方完成整个研发周期内数据的采集、关联和操作。借助 Benchling AI，智能体（agent）和模型可以直接嵌入科研工作流，并以结构化数据为依据。最终带来的是更高效的团队、更优质的分子，以及更快走向世界的科研突破。

关于作者

Jeremy Stashewsky

Jeremy 是 Benchling 的应用安全工程师。

Meghana Sreenivas

Meghana 是 AWS 的解决方案架构师，与 ISV（独立软件供应商）客户合作，设计安全、可扩展的多租户架构，覆盖数据平台和 AI 工作负载。她是本文的合著者，并主导了与 Benchling 的技术对接工作。

查看原文