AWS Lambda MicroVM 让 AI 智能体沙箱更易部署，也让治理更容易被意外忽略

AWS 发布了一套参考架构，用于在 Lambda MicroVM 上运行自托管的 AI 智能体沙箱。这篇文章的重点很务实：API 接收任务，启动隔离环境，让智能体执行工作，流式传输或保存结果，并在工作完成后销毁环境，或者将其挂起。它面向那些希望让智能体在自己的 AWS 账户内运行，而不是在供应商托管的开发工作区中运行的团队。

这项消息很容易被简化成性能故事。Lambda MicroVM 具备快速启动、虚拟机级隔离、基于快照的状态保存以及托管网络能力，这些当然有用。但更重要的变化在别处：一个能够按需创建、接入真实 VPC、并获得内部服务访问权限的沙箱，不再只是安全功能。它是一个短生命周期的生产工作负载，只不过里面有一个模型在做决定。

因此，对平台团队来说，第一个问题不应只是微型虚拟机是否比容器更安全，而应是组织能否让整个执行路径都可观测、可约束、可丢弃。强大的隔离原语很重要，但它不会替团队决定智能体拿到哪些凭据、能够访问哪些域名、可以把哪些数据复制进工作区，也不会自动判断某个被挂起的环境是否应该在相关策略已经改变后继续恢复。

AWS 发布了什么

AWS Compute Blog 于 9 月 18 日发布的文章介绍了一套自托管架构，使用 AWS Serverless Application Model 和多项托管服务构建。文章列出的组件包括 Amazon S3、IAM、Systems Manager Parameter Store、API Gateway、Lambda、AWS WAF、CloudWatch Logs 和 Lambda MicroVM。这套设计面向那些超出短时函数调用能力的 AI 智能体工具调用：安装软件包、运行命令、操作文件系统、启动进程，以及在交互式会话中保存状态。

底层的 Lambda MicroVM 服务是一种较新的计算原语，建立在 Firecracker 虚拟化技术之上。AWS 将其描述为具备完整操作系统能力、支持基于快照启动，并能够控制入站和出站网络访问的无服务器环境。MicroVM 可以在运行时关联网络连接器。根据配置不同，它可以访问公共互联网、VPC，或通过 VPC 端点访问私有 AWS 服务。

这组能力解决了当前智能体系统中的一个真实错位。普通函数很方便，却相对狭窄：它有受限的执行模型、短暂的本地文件系统和有边界的运行时。传统虚拟机或 Kubernetes Pod 提供了更多自由，但平台团队必须自己管理容量、镜像发布、隔离、调度和清理。容器可以快速启动，却与其他工作负载共享主机内核。MicroVM 在任务与底层主机之间放置了一个客户操作系统，同时保留了托管、按需的生命周期。

AWS 的参考架构并不是适用于每一种智能体的现成安全边界。它是一组构件和一种部署模式。这个区别很重要，因为最关键的控制措施位于虚拟化层之上。平台仍然必须决定请求如何认证、租户如何隔离、任务如何授权、产物如何扫描、会话可以持续多久，以及当智能体反复请求本不应拥有的权限时系统要如何处理。

这与普通无服务器代码为何不同

传统无服务器函数通常用途相当明确。事件触发一个已知处理器，处理器调用一组已知服务，而部署流水线预先定义了大部分行为。它同样存在严重的安全问题，但运营者往往可以根据函数代码、IAM 策略和输入契约来推断其行为。

AI 智能体改变了执行路径的形状。它可能动态选择工具、解释不可信文本、安装依赖、检查代码仓库、调用命令行客户端、在出错后重试，或者判断任务需要新的网络请求。最终的动作序列并没有完全写在部署清单中，而是在运行时根据提示词、工具描述、检索到的文档、文件内容以及前序命令的结果部分生成。

这会产生几个必须分开处理的边界。模型边界涉及智能体能够解释哪些指令，以及它如何处理恶意内容。工具边界涉及它可以调用哪些 API 和命令。计算边界涉及运行在环境中的代码能够影响什么。数据边界涉及哪些内容可以被读取、复制或保留。组织边界则涉及一个客户、项目或团队是否能够观察或影响另一个客户、项目或团队。MicroVM 主要强化的是计算边界，并不会自动解决另外四个边界。

所以，“沙箱”这个词可能会误导人。它可能指一个全新的操作系统环境、一个限制了文件系统的容器、一个带 seccomp 配置的进程、一个浏览器隔离层，也可能只是一个被标记为临时的工作区。这些机制的失效方式并不相同。客户内核和虚拟机监控器可以降低恶意进程逃出容器后对主机造成的影响，但如果智能体拿到了有效凭据，它仍然能够在完全没有越界的情况下发起一个已获授权却具有破坏性的 API 调用。

实际的设计目标不是“什么坏事都不可能发生”，而是控制爆炸半径：每个任务都应该只拥有完成工作所需的最小身份、最小数据集、最短网络路径、最短运行时间、最小存储寿命和有限的动作预算。系统应保留足够证据来解释发生了什么，然后让环境的销毁成本尽可能低。

值得重点审查的架构组件

1. 请求网关

API 层首先是政策决策点，而不只是入口。API Gateway 和 WAF 可以帮助认证请求、拒绝明显的滥用流量并执行速率限制，但一个有效请求仍然需要经过针对任务的授权判断。一个可以为文档任务创建沙箱的用户，不应因此自动获得创建一个能够访问生产数据库的沙箱的权限。

请求应携带明确的工作负载类别。有用的字段包括项目或租户标识、允许访问的数据源、允许使用的网络配置、最长运行时间、要求的输出类型，以及任务是否允许产生外部变更。启动器应根据这套策略派生环境，而不是接受调用方任意提交的 IAM 角色名称、VPC 标识符或安全组参数。

配额也应在这里定义。如果没有按用户和按项目设置限制，智能体循环可能创建大量环境、挂载昂贵存储，或通过持续活动让会话长期存活。请求预算不应只计算 API 调用次数，还应包括并发 MicroVM 数量、累计 CPU 和内存、出站字节数、产物大小以及特权工具调用次数。

2. 镜像与文件系统

一次性环境的可信度取决于它启动时所使用的镜像。镜像应有版本记录，并通过签名或其他方式关联到发布记录；还应定期重建，并扫描操作系统软件包和智能体工具中的漏洞。团队需要明确任务使用的是稳定基础镜像、项目专用镜像，还是叠加在基础镜像之上的可变工作区。每种选择都会改变可复现性和补丁管理方式。

智能体经常需要安装软件包或编译本地代码。对完整操作系统而言，这是合理用例，但也会扩大攻击面，让最终状态更难推断。更安全的模式是将可写任务文件系统与受信任的基础镜像分离，采用较短的保留期限，并把所有生成的二进制文件、缓存和脚本都视为不可信产物。

快照引入了一个不那么显眼的生命周期问题。快照可以改善启动速度并保存交互式会话，但也会保存内存和磁盘状态。如果环境挂起时其中存在令牌、会话 Cookie、私有源文件或命令输出，那么这些内容可能继续存在于恢复后的状态中。运营者需要明确规定哪些内容可以跨挂起保存，并在恢复前提供使敏感材料失效或轮换敏感材料的机制。

快照还反映了创建时的策略。如果组织后来修改了允许访问的网络目的地，或撤销了某个依赖项，恢复旧状态时不能悄悄恢复之前的权限。网络和身份策略应在启动和恢复时重新评估，而不应只在首次构建镜像时评估。

3. IAM 与秘密交付

为 MicroVM 分配 IAM 角色很方便，但角色并不是智能体策略。它是一种云授权机制。角色应针对工作负载类别专门创建，并尽可能通过资源级权限、条件、会话标签和短期凭据加以限制。一个能够读取所有项目存储桶或调用所有内部服务的通用角色，会把沙箱变成高价值凭据持有者。

Parameter Store 可以把秘密移出镜像，但获取秘密本身仍然是一项必须有理由的动作。启动器不应暴露一个宽泛的参数命名空间，然后让模型自行选择需要的值。相反，智能体进程之外的代理可以在检查任务策略后，发放范围狭窄、时间有限的凭据。代理还可以防止原始秘密出现在提示词、日志和模型可见的命令输出中。

同样的原则适用于源代码仓库。一个允许克隆仓库的令牌，也可能允许向仓库推送、创建拉取请求，或读取无关项目。读路径和写路径应分开。如果智能体需要提出修改，默认结果应是供审查的补丁或保存起来的产物，而不是一个能够修改规范分支的凭据。

短期凭据可以降低暴露时间，但无法消除审计需要。被攻陷的智能体仍可能在令牌有效期间使用它。因此，每次敏感操作都应记录任务标识、主体、环境标识，以及允许该操作的策略决策。CloudTrail 和具体服务的日志应与环境内部的命令和工具轨迹关联起来。

4. 出站访问是智能体能力集合的一部分

AWS 文档提供了入站和出站控制能力。这一点很重要，因为很多智能体任务需要下载软件包、获取源代码或调用外部 API。但这也是沙箱可能变成不受控中继的地方。如果环境拥有不受限制的互联网访问，模型可能上传源文件、联系攻击者控制的端点、获取未经审查的工具，或参与命令与控制通信。

安全默认值应当是与任务匹配的一小组目的地允许列表。可行时，软件包安装应使用批准的镜像或仓库。Git 访问应限制在任务所需的组织或主机范围内。内部服务应通过明确的 VPC 端点和安全组访问，而不是通过宽泛路由访问。DNS 请求也值得关注：如果域名允许列表忽略 DNS 重绑定、重定向或新解析出的地址，那么它的实际防护能力会比表面看起来弱。

网络策略应与身份和工作负载类别绑定，而不只是与共享子网绑定。开发智能体、代码审查智能体和迁移智能体可能运行同一个基础镜像，却需要完全不同的网络路径。架构应在部署对象和日志中清楚呈现这种差异。

当数据敏感时，出站内容控制很有价值。代理可以记录目的地、方法、响应大小和策略结果。对于高风险工作负载，它可以阻止上传、可执行文件下载，或包含已知秘密模式的请求。这些控制并不完美，也不应被描述成数据丢失防护保证，但它们能够留下证据并减少意外泄露。

5. 工具调用需要策略层

不能仅仅因为沙箱已经隔离，就给智能体一个不受限制的 shell。对软件工作而言，shell 往往是最有用的工具，但它同时组合了文件访问、进程创建、网络使用和凭据发现能力。工具代理应当按影响对命令分类，并对发布软件包、修改基础设施、删除数据、改变访问控制或发送外部消息等动作要求额外批准。

一种有用的设计是把观察与变更分开。读取构建日志、运行测试或检查依赖树可以自动允许。向分支写入内容、创建工单、修改部署清单或调用生产 API，则可以先生成一个提案，再由另一项服务或人工批准。MicroVM 负责容纳工作，但它不决定这项工作是否可以触及生产环境。

工具描述也是策略输入。如果某工具声称操作是只读的，实际却调用了具有副作用的端点，那么智能体可能在周围系统以为安全的情况下做出危险选择。工具模式、实现和审计记录应当结合测试。权限应基于调用的实际效果，而不是工具的友好名称。

新架构给平台团队带来的变化

最大的运维收益，是让智能体计算成为一种平台原语。团队可以提供内部“运行任务”服务，配备一致的 API、统一日志、镜像管理、配额和生命周期规则。开发人员不必为每个新的智能体工作流部署专用工作池。安全团队也可以审查少量工作负载配置，而不必面对一长串各自定制的主机。

但只有在平台拥有控制平面时，这种收益才会出现。如果每个产品团队都创建自己的启动器、IAM 角色、网络连接器和日志存储桶，MicroVM 可能会把原本想简化的治理问题复制并放大。内部平台应把安全能力作为产品暴露出来：只读仓库任务、隔离测试运行器、依赖分析作业，或者变更提案工作器。每种配置都应有已知镜像、网络策略、凭据契约和保留规则。

成本核算也会变得更精确、更必要。无服务器计费可能让短任务看起来很有吸引力，但交互式智能体可能花费大量时间等待、重试或持有状态。挂起可以减少空闲消耗，却不会让工作负载免费。存储、API Gateway 请求、日志记录、网络传输、WAF 处理、模型调用和产物保留都会计入总成本。一个在计算层看似便宜的任务，可能因为智能体反复轮询或下载大型工作区而变得昂贵。

创建环境时应强制打标签。至少要记录负责人、项目、任务类型、环境过期时间、数据分类和成本中心。标签还应流入日志和计费报告。如果一个平台无法回答哪个团队创建了环境、使用了什么策略，以及环境为什么仍然存活，那么它还没有准备好广泛提供自主执行能力。

隔离问题：优于容器，但不是完整答案

AWS 将 Lambda MicroVM 定位为虚拟机级隔离，并使用与 Lambda 相关的 Firecracker 技术。这与普通容器有实质区别，因为容器中的进程共享主机内核。对于执行不可信或半可信代码，尤其是工作负载需要语言级沙箱难以提供的操作系统能力时，这可能是合适的底层基础。

但隔离机制应按完整系统比较，而不能只看一个标签。一个 MicroVM 可能拥有存在漏洞的客户操作系统、权限过大的角色、开放的网络路径、被污染的软件包缓存、危险的主机侧集成，或者会暴露秘密的日志流水线。对于低风险任务，策略设计周全的容器可能已经足够；而拥有不受限制凭据的 MicroVM，仍然可能造成严重事故。

近期关于 AI 代码沙箱的研究也从测量角度提出了类似观点。相关变量包括主机攻击面、信息泄露、纵深防御、漏洞历史、补丁节奏以及上游模糊测试的质量。隔离类别很重要，但产品的更新和运营实践同样重要。MicroVM 应被视为纵深防御中的一层，而不应被当作任务安全的认证。

这一点对提示注入尤其重要。恶意 README、工单、网页或依赖项可能诱骗智能体在环境内执行某项动作。如果该动作只改变了可丢弃文件，损害可能被限制住。如果智能体可以读取源代码令牌、把令牌发送到外部主机、调用内部 API，或修改共享产物存储桶，那么它是否始终停留在 MicroVM 内，并不能让结果变得可以接受。

一套实际的上线顺序

评估这项服务的团队，应先选择一个有用但失败后可以恢复的任务。依赖分析、针对合成仓库运行测试、根据公开材料生成文档，以及构建验证，都比基础设施变更或生产支持更适合成为首批工作负载。首次部署的目的不仅是衡量任务是否成功，也包括观察控制平面。

在启用模型前先定义契约。明确输入数据、允许使用的工具、预期产物、最长运行时间、网络目的地、身份、日志字段和过期行为。写下智能体绝不允许做什么。一份可以执行的短策略，比一份只出现在审查文档中的宽泛政策声明更有价值。

然后测试不应出现的路径。把恶意指令放进仓库文件；加入带安装脚本的依赖；返回一个鼓励智能体以更宽权限重试的工具错误；在测试夹具中放入类似秘密的字符串。尝试让智能体访问内部主机名、创建第二个环境、写入任务目录之外、把令牌保存在快照中，并在截止时间之后继续维持会话。目标是测试策略行为，而不是教会生产环境中的智能体绕过防护。

为完整链路建立监测。一个有用的记录应包括请求、主体、策略配置、镜像摘要、MicroVM 标识、任务开始和结束时间、工具调用、命令、网络目的地、凭据发放、导出的文件、挂起和恢复事件，以及清理结果。日志应具备防篡改能力，并与任务可写文件系统分离。如果无法根据证据重建一次失败，平台就很难区分模型错误、用户错误、服务错误和攻击。

把清理作为一等工作流。每个环境都需要由智能体之外的机制强制执行截止时间。清理应撤销临时凭据，按照数据策略删除或隔离产物，移除网络关联，结束会话，并记录最终状态。智能体运行时如果工作器崩溃，不能因此留下一个无限期有效的环境。定期协调机制应找出失去控制平面记录的资源，并对其应用相同的过期规则。

只有这些控制措施正常工作后，平台才应加入私有数据或变更权限。即便如此，权限边界也要保持狭窄。修复代码的智能体可以创建补丁，却不必拥有合并补丁的能力。迁移规划智能体可以生成 SQL，却不必拥有执行 SQL 的能力。支持智能体可以起草回复，却不应直接发送。平台应在从分析过渡到外部效果的节点保留人工或确定性的审查点。

运营者应向 AWS 和自己的团队提出的问题

公开文档解释了核心服务模型，但生产采用仍需要针对具体账户和工作负载的答案。运营者应确认镜像如何打补丁、快照状态如何加密和过期、网络连接器在恢复时如何工作、并发和存储适用哪些限制，以及哪些事件可用于审计。他们还应确认计划使用的 MicroVM 能力在目标区域的可用性、定价维度和支持模式。

在组织内部，团队应追问谁负责基础镜像，谁批准网络配置，谁可以添加秘密，如何停止任务，事件响应人员如何取得证据，以及员工或客户在任务运行期间撤销访问权限时会发生什么。这些不是可以留到后续运维阶段的问题。它们决定了这套架构究竟是受控平台，还是一个方便的启动器。

这里还有一个产品设计问题：当智能体想要跨越边界时，用户能看到什么？一个有用的系统会让拟议动作清晰可理解。它应展示仓库、目的地、数据类别、预期副作用和请求原因。“允许”不应是唯一的交互选项。平台还需要提供更安全的替代方案，例如生成补丁、保存报告、申请范围更窄的令牌，或停止任务。

更广泛的意义

AWS 正在回应一种不断扩散到各云平台的模式：智能体需要真实的执行环境，但组织不希望每个团队都自行搭建临时远程 shell。托管 MicroVM 可以减少提供这项能力所需的基础设施工作，也可能把智能体安全的重心从提示词过滤转向工作负载工程。

这是一个健康的转向。提示词过滤可以减少明显的指令攻击，却无法表达每一条数据流和授权规则。工作负载配置可以规定：任务可以读取这个仓库，访问这些软件包镜像，只能写入这个产物存储桶，并且运行十分钟。即便模型行为不可预测，IAM、网络策略、工具代理和外部清理控制器仍然可以分别执行这份契约中的不同部分。

风险在于，无服务器配置的便利性可能掩盖治理成本。开发人员只需几次 API 调用就能启动一个能力完整的执行环境，为它绑定角色、开放互联网访问，然后把结果称为沙箱。这足以演示一个功能，却不足以围绕私有数据或生产控制运营自主系统。

因此，下一轮评估应遵循一套具体建议：构建一个狭窄的任务配置，使用合成数据或公开数据，拒绝宽泛的出站访问，不发放长期秘密，记录每一次工具和网络动作，执行外部截止时间，并验证清理结果。衡量指标不应只有启动延迟和任务完成率，还应包括策略违规、无法解释的网络请求、快照卫生、产物保留情况，以及调查一次失败运行所需的工作量。

Lambda MicroVM 可以让隔离的智能体执行环境更容易部署，但它不会让信任自动出现。真正能从中受益的团队，会把 MicroVM 当作受控执行服务的计算层，并从一开始就围绕它设计身份、网络、数据、可观测性和生命周期策略。

来源

本文依据 AWS Compute Blog 关于“使用 AWS Lambda MicroVM 运行自托管 AI 智能体沙箱”的文章、AWS Lambda MicroVM、MicroVM 网络和 PrivateLink 相关文档与公告，以及 AWS Compute Blog 对 Lambda MicroVM 的介绍进行改编；关于 AI 代码沙箱引擎级属性的背景，参考了 arXiv 上的比较性安全研究。文中还保留了原文对 Reddit 讨论内容作为讨论背景的来源归类。