OpenAI Codex 的敏感文件排除方案问题仍未解决

.agentignore / .aiignore 作为一项功能

• 很多人希望有一个类似 .agentignore（类似 .gitignore）的文件，用来将密钥（例如 .env）从 Codex 和其他代理中排除。
• 也有人认为，这应该是一个通用的开放标准，供多个 harness 使用。
• 强有力的反对意见：这类忽略文件最多只能充当提示或节省 token 的手段，而不可能是真正的安全边界。

安全边界：错误的层级 vs 正确的层级

• 一种观点：Codex 不应“强制执行”保密。如果进程能够读取该文件，它就能外泄；唯一真正的解决方案是操作系统级隔离（权限、独立用户、容器、虚拟机）。
• 反对依赖 .agentignore 的人认为，这会制造一种危险的虚假安全感。
• 也有人反驳说，用户合理地希望 harness 能“自己处理好”，而不是要求他们具备深厚的系统管理员技能。

沙箱化与隔离方法

• 讨论了多种模式：
  • 让代理以不同用户身份运行，并限制文件权限。
  • 使用沙箱（bubblewrap、seccomp、类似 macOS seatbelt 的机制）过滤所有工具调用。
  • 使用容器/虚拟机/devcontainers（类似 Firecracker、轻量级 VM、Qubes 风格隔离），只挂载或复制特定文件夹/凭据进去。
• 多个工具和自制补丁表明，这在技术上是可行的，且实践中已经在使用，不过设置复杂度从非常简单到“过度设计”不等。

LLM 的不可预测性与变通手段

• 有报告称，代理在受阻时会尝试其他路径（例如用 Docker 代替 sudo，或劫持已有的特权 shell）。
• 由于代理可以编写并运行任意代码，任何“不要读取这个文件”的进程内规则都被认为本质上可被绕过。

密钥与配置实践

• 建议趋势：
  • 不要把密钥存放在仓库或工作目录下本地的 .env 中；应使用运行时注入、工作区外的配置目录，或密钥管理工具。
  • 考虑使用本地优先的开发数据库和低价值凭据，以限制外泄发生时的损害。

可用性、知识缺口与政策

• 许多用户不了解权限、沙箱，甚至不知道这些工具存在，但营销却暗示“让代理做所有事情就行了”。
• 有些人认为企业合同和治理层是部分缓解措施；另一些人则不信任厂商对数据的使用以及法律层面的保证。