AI Agent 安全沙箱工程指南

传统安全控制关注的是代码在哪里运行。AI Agent 带来了不同的问题，因为它们会在运行过程中自行决定要做什么。

AI Agent 沙箱会为这些决策划定边界，降低 Agent 访问不该访问的内容，或执行超出其预定职责范围操作的可能性。

本指南将介绍 AI Agent 沙箱的工作原理，以及为什么工作流层面的控制与运行时隔离同样重要。

沙箱如何约束 AI Agent 的执行

AI Agent 会在运行过程中决定采取哪些行动，而且往往会依据途中遇到的信息作出判断。当 Agent 需要适应不断变化的情况时，这种能力非常有用，但也会带来新的风险。仅仅隔离运行时并不够。沙箱还必须限制 Agent 与外部世界交互的方式，包括它能够访问哪些系统、执行哪些操作，以及可以在不同任务之间延续哪些信息。

系统中的多个环节都需要设置约束。代码运行的执行环境只是其中一部分。Agent 在工具使用、数据访问、执行状态和持久化记忆方面同样需要边界。

真正的挑战在于决策层本身：即使目标保持不变，LLM 在每次运行时也可能选择不同的操作。这使得它们比传统软件更难预测，也意味着隔离不能只停留在基础设施层面。

为什么 AI Agent 从设计之初就需要隔离

AI Agent 安全存在一些反复出现的问题。有些源自用户输入，有些则出现在 Agent 与外部系统交互或跨运行保留信息时。它们的共同点是：Agent 会自主作出决策，因此故障也更难预测。以下是一些需要考虑的风险：

这些风险并非全都是新问题。多年来，组织一直在应对访问控制和凭证滥用问题。真正不同的是 AI Agent 的运行方式。Agent 每次运行时都可能选择不同的操作顺序，因此其行为更难预判和测试。

从输入到结果的路径并不总是显而易见。因此，隔离必须从一开始就成为设计的一部分，而不能等到部署之后再补上。

AI Agent 沙箱如何设计

AI Agent 沙箱由一组协同工作的边界构成，用来限制 Agent 能做什么、可以在哪里执行，以及能够携带哪些信息。其设计的核心是 Agent 执行隔离（agent execution isolation），也就是将 Agent 的活动与它无须访问的系统和数据分离。

尽管具体实现各不相同，但大多数沙箱架构都会将运行时、Agent 的决策过程，以及它在执行期间维护的状态相互分离。

执行环境隔离

执行环境是 Agent 实际运行的地方。在 AI Agent 沙箱环境中，它可能是容器、虚拟机或浏览器沙箱。

目标是将 Agent 的执行与宿主系统分离，并限制其访问未被明确要求的资源。这种 Agent 运行时隔离（agent runtime isolation）会将 Agent 的操作约束在获批的边界内。如果 Agent 生成代码或代表用户执行操作，这些行为会发生在受控环境中，而不是直接作用于生产基础设施。

Agent 运行时与决策层

运行时之上是 Agent 本身。这一层负责理解指令、选择工具，并决定下一步做什么。在某些架构中，这个决策层运行在 LLM 沙箱内，由沙箱限制模型与外部工具和系统交互的方式。

这也是 AI Agent 与传统软件存在根本差异的地方。传统应用遵循预先定义的逻辑，而 Agent 可以在运行过程中评估上下文并生成新的操作。这种灵活性也会带来无法提前完整规划的行为。

状态与记忆隔离层

Agent 通常会维护对话历史、工作记忆、检索到的上下文或中间输出，以帮助自己完成任务。

状态层决定了这些信息如何存储和隔离。如果没有清晰的边界，一个用户会话中的信息可能泄漏到另一个会话中；原本只用于单个任务的数据也可能持续存在，进而影响无关的执行。有效的 LLM 沙箱设计会将 Agent 记忆视为独立的数据域，而不是任由它与更广泛的应用或系统数据混杂在一起。

如何保障 Agent 安全执行

隔离的运行时可以阻止 Agent 访问底层宿主系统，但它无法决定 Agent 可以使用哪些工具，或者能够访问哪些数据。

这正是执行控制需要发挥作用的地方。在实践中，要实现安全的 AI Agent 执行，就必须限制 Agent 能做什么、控制它访问敏感系统的方式，并在 Agent 开始运行后持续掌握其行为。

n8n 是一款同时提供 AI Agent 能力和确定性能力的工作流自动化工具。在这个平台中，你可以通过子工作流、作用域受限的凭证、执行历史和针对不同环境的配置，在工作流层面实现这些控制。

从一开始就在安全边界内构建 AI Agent

使用 n8n 在工作流层面限定工具范围、隔离凭证，并记录每一次执行。

能力范围限定与最小权限执行

降低风险最简单的方法之一，就是缩小 Agent 可执行操作的范围。只能访问获批工具的 Agent，执行非预期操作的机会更少——无论这些操作源于 prompt injection 攻击，还是运行时作出的错误决策。

随着工作流变得更加复杂，这一点尤其重要。团队不必开放所有可用的集成，而是可以将请求转交给预先定义的子 Agent，并且只向它们授予特定任务所需的能力。

凭证隔离与密钥管理

Agent 经常需要访问 API、数据库和内部服务，但这并不意味着它们应该直接接触凭证。

将凭证与 Agent 运行时分离，可以更轻松地执行权限边界，并在不修改工作流逻辑的情况下轮换密钥。这样还能限制 Agent 遭入侵后的影响范围，确保其访问权限仅覆盖特定任务所需的系统和操作。

可观测性与审计日志

当 Agent 出现异常行为时，人们通常会先问一个简单的问题：发生了什么？

要回答这个问题，就必须了解 Agent 作出了哪些决策、调用了哪些工具，以及信息如何在工作流中流动。执行历史和审计日志能够提供调查故障、理解 Agent 行为，以及在必要时证明合规性所需的上下文。

环境隔离

并非每个工作流都应该具备访问生产系统的权限。将开发、预发布和生产环境相互分离，可以为团队提供安全的操作空间和更大的自由度。团队可以先测试新的 prompt、工具和 Agent 行为，再将它们开放给真实用户或敏感数据。

对于 AI Agent，这种隔离还有另一层作用：它建立了一条从实验走向生产的受控路径。团队可以先评估 Agent 在某个环境中的表现，再允许它访问那些一旦出错就会造成实际后果的系统。

工作流编排在沙箱机制中的作用

基础设施沙箱可以约束 Agent，但无法控制 Agent 开始运行后会决定做什么。隔离的运行时能够限制 Agent 对宿主系统的访问，却无法决定 Agent 可以使用哪些集成、某个请求是否需要审批，或者如何在相互连接的服务之间执行权限控制。

通过工作流控制工具执行

大多数 Agent 并不直接与业务系统交互，而是通过工具完成操作。团队可以将工具调用交由预先定义的工作流处理，从而精确决定哪些操作可用，以及这些操作要在什么条件下执行。

例如，在 n8n 中，子工作流可以充当 Agent 与下游系统之间的受控接口。团队无须开放整个应用，只需开放 Agent 完成任务所必需的具体操作。同样的方法也适用于基于 webhook 的交互：工作流可以验证传入的请求，并在 Agent 生成的操作抵达外部系统之前，决定如何处理这些操作。

在不同集成之间执行权限边界

Agent 的权限不应该自动等同于其所连接系统的权限。

工作流层面的控制允许你限定凭证的作用域、限制对单个集成的访问，并确保 Agent 始终在明确定义的边界内运行。对于处理敏感数据的组织而言，这种控制能够在 Agent 从实验阶段进入生产环境后持续保障合规性。

有数据驻留要求的团队还可以更进一步，选择自行托管 n8n。本地部署可以让工作流执行和治理控制始终留在公司基础设施内部。

Agent 行为的全程可观测性

当 Agent 执行了非预期操作时，团队需要一份清晰的运行记录。工作流编排通过保存执行历史并呈现 Agent 在工作流中经过的路径，提供了这种可见性。这样一来，Agent 行为便成为团队可以持续检查、排查和改进的对象。

在 n8n 中，这种可观测性直观且可视化。借助基于节点的画布，团队可以深入查看每次运行，了解其输入、输出以及背后的执行路径。

从一开始就在安全边界内构建 AI Agent

AI Agent 需要明确的边界，规定它们可以访问什么，以及被允许做什么。为了实现安全遏制，AI Agent 沙箱会执行这些限制。n8n 则为团队提供了一种切实可行的方式，让 AI Agent 在进入生产环境的同时，仍然能够清楚掌握这些 Agent 实际执行了哪些操作。

将 AI Agent 投入生产，同时保持可见性

默认内置工作流层面的治理、凭证隔离和执行历史。

n8n 用户拥有广泛多样的背景、经验水平和兴趣。我们一直希望在博客文章中介绍不同的用户及其项目。如果你正在使用 n8n，并希望为社区带来启发，欢迎联系我们 💌