OpenAI Codex: 關於敏感檔案排除的爭議
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."
建議的隔離策略
為了防止機密資訊外洩，開發者建議了幾種架構模式：
- Containerization: 運行 agent 在一個沒有掛載敏感檔案的容器中，或者使用像 Apptainer 這樣的工具來僅掛載任務所需的特定儲存庫 (repository) 。
- Clean Virtual Machines: 為每個 agent 對話啟動一個專用的雲端 VM。這能確保 agent 沒有權限存取本機機器或信任的上下文 (context) ，且除非獲得明確授權，否則無法與遠端來源通訊。
- Opt-in Access: 從「排除制」(blocklist) 轉向「加入制」(allowlist) 模式，即在工作階段開始前，僅將使用者配置的基礎資料夾複製到沙箱中。
- Unix Permissions: 使用
chmod來確保運行 Codex 程序的程序帳號缺乏對敏感目錄的讀取權限。
.agentignore 與黑名單的局限性
雖然有人要求建立標準的 .agentignore 檔案（類似於 .gitignore），但技術專家認為這種功能會提供「虛假的安全感」。
為什麼黑名單會失效
- 不可預測性: LLM 有能力繞過高層級的限制。在程序內實施的限制可能會被惡意或產生幻覺的 agent 破壞。
- Tool Redundancy: 如果 agent 正在開發的程式碼需要存取
.env檔案才能運行，agent 可能會透過記憶體或其正在除錯的應用程式輸出中觀察到這些值。 - 不完整性: 從統計學上來說，使用者定義的黑名單不太可能足以涵蓋所有通往敏感資料的所有可能路徑。
儘管存在這些安全缺陷，有些人認為 .agentignore 檔案作為給 agent 的「提示」仍有價值，可以避免在無關檔案上浪費 token，前提是不要依賴它來確保安全性。
替代性的機密管理方法
除了對 agent 進行沙箱化之外，討論也強調了根本原因通常在於機密資訊是如何儲存在檔案系統中。
- Eliminate
.envFiles: 停止在儲存庫 (repository) 中以明文檔案的形式儲存 API keys。相反，機密資訊應該在執行時注入，或者透過像ssh-agent這樣的代理程式來處理，以避免 bearer token 的外洩。 - Runtime Injection: 在執行期間直接將機密資訊注入環境中，使其不再以檔案的形式存在，從而避免被 agent 發現。
社群驅動的工具與補丁
幾位開發者分享了開源專案與本地補丁，以解決這些問題：
- Rumpelpod: 一個用於在遠端/安全 devcontainers 中的 agent 編排器 (orchestrator) 。
- YoloAI: 一個 FOSS AI 沙箱。
- Drop: 一個專為隱藏 AI agent 的敏感檔案而設計的 Linux 沙箱。
- Custom Patches: 一些使用者實施了本地補丁來統一規則實施，將原本分開的基於工具與基於 shell 的限制，替換為單一的沙箱設定檔 (profile) （例如，使用
bwrap使用者命名空間），來管理所有的檔案系統存取權限。