沙箱化AI代理工作流的安全实践指南

沙箱化代理工作流与执行风险管理的实用安全指南

AI编码代理能够通过简化任务和推动自动化、测试驱动开发，帮助开发者更快地工作。然而，它们也引入了显著且常被忽视的攻击面，因为代理会以与用户相同的权限和授权从命令行运行工具，这使得它们成为计算机使用代理，并带来所有相关风险。

这些工具面临的主要威胁是间接提示注入。攻击者通过恶意代码库、拉取请求、包含提示注入的git历史记录、.cursorrules、CLAUDE/AGENT.md文件或恶意的MCP响应等途径，向驱动模型的大语言模型提供部分恶意内容。这些恶意指令可能导致大语言模型采取受攻击者影响并产生不良后果的行动。

手动批准代理执行的行动是管理此风险的最常见方式，但这也会持续增加开发者的阻力，要求开发者反复回到应用程序中审查和批准行动。这会产生用户习惯化风险，即用户可能会不经审查就批准潜在危险的行动。保障代理系统安全的关键要求是在人工实操与自动化之间找到平衡点。以下控制措施是某机构AI红队认为必需或强烈推荐的，但应根据您的具体用例和组织的风险承受能力来实施。

根据某机构AI红队的经验，以下强制性控制措施可以减轻通过间接提示注入实现的最严重攻击：

• 网络出口控制：阻止对任意站点的网络访问，可以防止数据外泄或在无需额外漏洞利用的情况下建立远程shell。
• 阻止写入工作区外的文件：阻止对工作区外文件的写操作，可以防止多种持久化机制、沙箱逃逸和远程代码执行技术。
• 阻止写入配置文件，无论其位于何处：阻止对配置文件的写入，可以防止利用钩子、技能和本地模型上下文协议配置（这些通常运行在沙箱环境之外）进行攻击。

以下推荐的控制措施可以进一步减少攻击面，使主机枚举和探测更加困难，限制钩子、本地MCP配置和内核漏洞带来的风险，并堵住其他漏洞利用和信息泄露风险。

• 阻止读取工作区外的文件。
• 将整个集成开发环境及其所有衍生功能（如钩子、MCP启动脚本、技能和工具调用）进行沙箱化，并且在可能的情况下，以它们自己的用户身份运行。
• 使用虚拟化技术将沙箱内核与主机内核隔离（例如，微型虚拟机、Kata容器、完整虚拟机）。
• 对于特定操作的每个实例（例如，网络连接），如果该操作会违反隔离控制措施，则要求用户批准。“批准一次/运行多次”不是充分的控制措施。
• 使用密钥注入方法，防止密钥（例如环境变量中的密钥）被共享给代理。
• 建立沙箱的生命周期管理控制，防止代码、知识产权或密钥的累积。

为什么要在操作系统级别强制执行沙箱控制？

代理工具，尤其是用于编码的工具，本身设计上就会执行任意代码。自动化测试驱动或规范驱动开发要求代理创建并执行代码以观察结果。此外，使用工具的代理正趋向于编写和执行一次性脚本来完成任务。

这使得应用程序级别的控制措施不足。它们可以在执行前拦截工具调用和参数，但一旦控制权传递给子进程，应用程序就无法再看到或控制该子进程。攻击者经常使用间接方式——通过一个更安全、已批准的工具来调用一个受限制更严格的工具——作为绕过应用程序级控制（如白名单）的常用方法。操作系统级别的控制，如macOS Seatbelt，在应用程序层之下工作，覆盖沙箱中的每个进程。无论这些进程如何启动，它们都无法接触到危险的系统能力，即使通过间接路径也不行。

强制性沙箱安全控制措施

本节简要概述了红队认为对代理应用程序是强制性的控制措施及其帮助缓解的攻击类别。当这些措施共同实施时，可以阻止在实践中观察到的简单漏洞利用技术。本节最后提供了在实际部署中分层实施控制措施的指南。

除已知安全位置外的网络出口

网络访问最明显和最直接的威胁是远程访问（网络植入、恶意软件或简单的反向shell），使攻击者能够访问受害机器，直接探测和枚举控制措施，并试图横向移动或逃逸。

另一个重大威胁是数据泄露。开发者机器通常包含大量对攻击者有价值的密钥和知识产权，甚至包括当前工作区（例如，包含API令牌的.env文件）。泄露 ~/.ssh 等目录的内容以获取对其他系统的访问权限是一个主要目标，泄露敏感源代码同样如此。

未经手动批准，不应允许沙箱进程创建网络连接。通过HTTP代理、IP或基于端口的控制执行的严格范围限定的白名单可以减少用户交互和批准疲劳。同时建议将DNS解析限制在指定的可信解析器，以避免基于DNS的数据泄露。“默认询问”策略与无法被本地用户覆盖的企业级黑名单相结合，可以在功能性和安全性之间取得良好平衡。

阻止写入活动工作区外的文件

在活动工作区外写入文件是一个重大风险。像 ~/.zshrc 这样的文件会自动执行，可能导致远程代码执行和沙箱逃逸。各种关键文件（如 ~/.gitconfig 或 ~/.curlrc）中的URL可能被覆盖，将敏感数据重定向到攻击者控制的位置。恶意文件（如被植入后门的Python或Node二进制文件）可能被放置在 ~/.local/bin 中以建立持久性或逃逸沙箱。

必须在操作系统级别阻止在活动工作区外进行的写操作。与网络控制类似，使用企业级策略阻止任何对已知敏感路径的此类操作，无论用户是否手动批准该操作。这些受保护文件应包括点文件、配置目录以及企业策略列举的任何其他路径。其他工作区外的文件写操作可以在用户手动批准后允许执行。

阻止对所有代理配置文件或扩展的任何写入

许多代理系统（包括代理IDE）允许创建扩展以增强功能，这些扩展通常包含可执行代码。“钩子”可以定义在特定事件（如提交提示时）执行的shell代码。使用stdio传输的MCP服务器定义了启动服务器所需的shell命令。Claude技能可以包含脚本、代码或辅助函数，在技能被调用时立即运行。像 .cursorrules、CLAUDE.md、copilot-instructions.md 这样的文件可以为攻击者提供一种持久的方式来塑造代理的行为，在某些情况下甚至可以完全控制或执行任意代码。

此外，代理IDE通常包含全局和本地设置，包括命令白名单和黑名单，以及在活动工作区中的本地配置设置。如果这些本地设置被修改，攻击者可能获得横向移动或扩大其影响范围的能力。例如，向工作区中的Git仓库添加恶意的钩子配置可能会影响克隆它的每个用户。此外，钩子和MCP初始化函数通常在沙箱环境之外运行，这为逃逸沙箱控制提供了机会。

应用程序特定的配置文件，包括位于当前工作区内的文件，必须受到保护，防止被代理修改，并且IDE不可能批准此类操作。用户直接手动修改是修改这些敏感文件的唯一可接受机制。

控制措施的分层实施

鉴于代理工具可能应用于广泛的用例，定义普遍适用的允许/拒绝列表很困难。目标应该是阻止可利用的行为，同时保留人工干预作为针对意外情况的、不常用的后备方案，采用如下分层方法：

1. 建立明确的企业级黑名单，禁止访问当前工作区外的关键文件，该黑名单不能被用户级白名单或手动批准决策覆盖。
2. 允许在代理工作区内进行读写访问（配置文件除外），无需用户批准。
3. 允许特定的白名单操作（例如，从 ~/.ssh/gitlab-key 读取），这些操作可能是特定功能正常运行所必需的。
4. 对所有其他操作采用“默认拒绝”原则，允许逐案用户批准。

本文未专门讨论命令允许/拒绝列表，因为操作系统级别的限制应使命令级拦截成为冗余，尽管它们可作为针对潜在沙箱错误配置的纵深防御缓解措施。

推荐的沙箱安全控制措施

前面讨论的强制性控制措施为抵御间接提示注入提供了强有力的保护，并有助于减少批准疲劳。然而，仍然存在一些潜在漏洞，包括：

• 摄取恶意的钩子或本地MCP初始化命令。
• 导致沙箱逃逸和完全主机控制的内核级漏洞。
• 代理对密钥的访问。
• 特定产品的手动批准缓存失败模式。
• 沙箱中密钥、知识产权或可利用代码的累积。

以下附加的控制措施和考虑因素有助于堵住其中一些剩余的潜在漏洞。

沙箱化IDE及所有衍生功能

许多代理系统仅在调用工具时（通常仅针对使用shell/命令行工具时）应用沙箱化。虽然这确实防止了广泛的滥用机制，但仍有许多代理功能通常默认在沙箱外运行。这些包括钩子、生成本地进程的MCP配置、“技能”使用的脚本或应用程序层管理的其他工具。当沙箱仅与命令行工具关联，而文件编辑工具或搜索工具在沙箱外执行并由应用程序级控制时，这通常是必需的。这些未沙箱化的执行路径可能使攻击者更容易绕过沙箱控制或获得远程代码执行。

应为所有代理操作强制执行所讨论的沙箱限制，而不仅仅是命令行工具调用。阻止写入当前工作区外和配置文件的操作是最关键的，而沙箱的网络出口仅应允许用于配置正确的远程MCP服务器调用。

使用虚拟化将沙箱内核与主机内核隔离

许多沙箱解决方案（macOS Seatbelt、Windows AppContainer、Linux Bubblewrap、Docker化开发容器）共享主机内核，使内核暴露给沙箱内执行的任何代码。由于代理工具本质上是设计来执行任意代码的，内核漏洞可能成为完全攻陷系统的直接途径。

为了从架构层面防止这些攻击，应始终在完全虚拟化的环境中运行代理工具，使其与主机内核隔离，包括使用虚拟机、单内核或Kata容器。像gVisor这样的中间缓解措施（通过单独的用户态内核调解系统调用）比完全共享的解决方案更可取，但其提供的安全保证与完全虚拟化不同且可能更弱。

虽然虚拟化通常会引入一些开销，但与LLM调用所产生的开销相比，这种开销通常不大。应针对相关开销调整虚拟化环境的生命周期管理，以最大限度地减少开发者阻力，同时防止信息积累。

阻止读取工作区外的文件

沙箱解决方案通常需要访问工作区外的某些文件，如 ~/.zshrc，以重现开发者的环境。不受限制的读取访问会暴露对攻击者有价值的信息，使用户能够枚举和探测其设备、密钥和知识产权。

这遵循与最小权限原则一致的分层方法：

1. 使用企业级黑名单阻止从沙箱运行不需要的高度敏感路径或模式进行读取。
2. 将白名单外部读取访问限制在绝对必要的范围内，理想情况下仅在沙箱初始化期间允许读取，之后阻止读取。
3. 阻止工作区外的所有其他读取，除非用户手动批准。

要求每次行动违反默认拒绝隔离控制时都需手动用户批准

正如分层实施方法中所述，未列入白名单或未明确禁止的“默认拒绝”行动在执行前应需要手动用户批准。企业级黑名单绝不应被用户批准覆盖。

关键的是，批准永远不应被缓存或持久化，因为一次合法的批准会立即为未来的攻击者滥用打开大门。例如，为了执行合法功能而允许修改一次 ~/.zshrc，可能会允许后续的对抗活动在后续执行中植入代码而无需重新批准。每个潜在危险的操作都应需要新的用户确认。

使用密钥注入方法防止密钥暴露给代理

开发者环境通常包含各种密钥，例如环境变量中的API密钥、~/.aws中的凭证、.env文件中的令牌以及SSH密钥。这些密钥通常被沙箱化进程继承或在文件系统内可访问，即使它们对于当前任务并非必需。这造成了不必要的暴露。

即使网络控制措施已到位，暴露的密钥仍然构成风险。

沙箱环境应依赖显式的密钥注入，将凭证范围限定为给定任务所需的最小权限，而不是继承主机环境的全部凭证集。在实践中：

1. 使用空凭证集或简单的凭证集启动沙箱。
2. 移除当前任务不需要的任何密钥。
3. 仅基于特定任务或项目注入所需的密钥，理想情况下通过代理无法直接访问的机制（例如，按需提供短期令牌的凭证代理，而非环境变量中的长期凭证）。
4. 持续执行标准安全实践，例如对所有密钥应用最小权限原则。

目标是限制任何安全漏洞的影响范围，使得假设获得代理行为控制权的攻击者只能使用为当前任务明确配置的密钥，而无法使用主机系统中可用的全部凭证集。

建立沙箱的生命周期管理控制

长期运行的沙箱环境会随时间累积构件，如下载的依赖项、生成的脚本、缓存的凭证、以前项目的知识产权以及持久化时间超出预期的临时文件。这扩大了潜在的攻击面，并增加了安全漏洞的价值。当攻击者获得对在过时沙箱中运行的代理的访问权限时，他们可能会找到可用于其他目的的密钥、专有代码或早期工作所需的工具。

生命周期管理的细节因沙箱架构、初始化开销和项目复杂性而异。关键原则是确保沙箱状态不会无限期持久化，可以通过以下方式实现：

• 临时沙箱：使用环境仅存在于特定任务或命令持续期间的沙箱架构（例如，每次执行时创建和销毁的Kata容器），防止累积。
• 显式生命周期管理：定期销毁沙箱环境并以已知的良好状态重新创建（例如，对于基于虚拟机的沙箱每周一次），确保按已知时间表清除累积的状态。

虽然代理工具的提供商负责确保生命周期管理，但组织应评估其沙箱架构并建立生命周期策略，在初始化开销和开发者阻力与累积风险之间取得平衡。

了解更多

代理工具代表了开发者工作方式的重大转变。它们通过自动化代码生成、测试和执行带来生产力提升。然而，这些好处伴随着攻击面的相应扩大。随着代理工具的不断发展，获得新功能、集成和自主性，攻击面也随之演变。本文概述的原则应在新功能推出时重新审视。组织应定期验证其沙箱实现是否提供了所期望的隔离和安全控制。FINISHED