OpenAI Codex: 关于敏感文件排除的争论

OS 级沙箱化是唯一可靠的安全措施

在 AI agent 的运行框架内实现黑名单或 .agentignore 文件对于安全性而言是不够的，因为 LLM 可以通过工具使用来绕过高层级的限制。真正的隔离需要将安全边界从应用层移动到操作系统层，使用容器、虚拟机或严格的 Unix 权限。

正如社区成员所指出的，如果一个 agent 拥有 shell 访问权限，它就可以使用像 rg (ripgrep) 这样的命令在整个文件系统中查找敏感字符串。即使特定的 read_file 工具受到限制，包含敏感数据的 shell 命令输出仍会被上传到模型。

"What if the model runs 'rg foo', and one of those files contains the string 'foo'? It uploads the tool output, which includes the file contents. And so, the only solution is to make it so the codex process is unable to access those files."

推荐的隔离策略

为了防止机密泄露，开发者建议采用几种架构模式：

• 容器化： 在不挂载敏感文件的容器中运行 agent，或者使用 Apptainer 等工具仅挂载任务所需的特定仓库。
• 干净的虚拟机： 为每次 agent 对话启动一个专用的云端 VM。这可以确保 agent 无法访问本地机器或信任上下文，并且除非获得明确授权，否则无法与远程源通信。
• 选择性加入访问： 从“选择性退出”（黑名单）模式转向“选择性加入”（白名单）模式，即在会话开始前，仅将用户配置的基础文件夹复制到沙箱中。
• Unix 权限： 使用 chmod 确保运行 Codex 进程的用户账户缺乏对敏感目录的读取权限。

.agentignore 和黑名单的局限性

虽然有人请求提供标准的 .agentignore 文件（类似于 .gitignore），但技术专家认为，此类功能提供了一种“虚假的安全感”。

为什么黑名单会失效

1. 不可预测性： LLM 能够绕过高层级的限制。在进程内实施的限制可能会被失控或产生幻觉的 agent 破坏。
2. 工具冗余性： 如果 agent 正在开发的程序需要访问 .env 文件才能运行，那么 agent 可能会通过内存或其正在调试的应用程序的输出观察到这些值。
3. 不完整性： 从统计学上讲，用户定义的黑名单几乎不可能足够全面，能够覆盖所有通往敏感数据的可能路径。

尽管存在这些安全缺陷，一些人认为 .agentignore 文件作为向 agent 提供“提示”仍有价值，即避免在无关文件上浪费 token，前提是不依赖它来进行安全防护。

密钥管理的其他替代方案

除了对 agent 进行沙箱化，讨论还强调了根本原因通常在于机密是如何存储在文件系统上的。

• 消除 .env 文件： 停止在仓库中以明文文件形式存储 API 密钥。相反，机密应该在运行时注入或通过 ssh-agent 等代理进行处理，以避免 bearer token 泄露。
• 运行时注入： 在执行期间直接将机密注入环境，使其永远不会以文件的形式存在，从而避免被 agent 发现。

社区驱动的工具和补丁

几位开发者分享了开源项目和本地补丁，以填补这些空白：

• Rumpelpod： 一个用于在远程/安全 devcontainers 中运行 agent 的编排器。
• YoloAI： 一个 FOSS AI 沙箱。
• Drop： 一个旨在向 AI agent 隐藏敏感文件的 Linux 沙箱。
• 自定义补丁： 一些用户实施了本地补丁以统一规则实施，用单一的沙箱配置文件（例如使用 bwrap 用户命名空间）取代了基于工具和基于 shell 的独立限制，从而管理所有的文件系统访问。