编程 Agent 防泄密：钩子与沙箱的边界

给 AI 编程助手配上沙箱，再装几个 hooks，密钥就安全了吗？这篇文章的答案是：还不够。读取 .env、把凭据打印到会话、通过浏览器或 HTTP 发出去，是三条不同的泄露路径，需要分别设防。

作者对照 Antigravity 和 Codex 的文档，拆解了工具调用拦截、沙箱、审批和日志各自能管什么，也介绍了自家 ReclaimLLM 的补充方案。最值得程序员带走的一点是：规则成功命中时能拦住，不代表规则进程出故障时也能拦住。文中的厂商行为核对截至 2026 年 10 月，应当按这个时间范围理解。

密钥没发出去，就算没有泄露吗

作者把风险分成 Read、Print、Send 三步，适合拿来检查日常 AI 编程流程。

Read 是助手打开 .env、密钥文件或含凭据的配置。Print 是命令输出、日志或 MCP 响应把秘密带进会话记录。Send 才是通过 HTTP、浏览器导航或剪贴板，把内容转移到机器之外。

这三步未必连着发生。一次排查配置的命令，即使没有发送网络请求，也可能已经把生产密钥写进长期保存的 transcript。

阻止网络外发，不能替代限制密钥读取和会话留存。

原文引用了 PromptArmor 的间接提示注入研究：网页里的隐藏指令诱导 Antigravity 读取 .env，再借浏览器子代理访问攻击者控制的 URL，带走凭据。研究当时，webhook.site 出现在默认 Browser URL Allowlist 中。

这里有两个边界。首先，危险指令来自被读取的网页，并非开发者主动要求上传密钥。其次，作者截至 2026 年 10 月的核对，没有从该研究文章中找到厂商修复记录；这不能推导成已经修复，也不能推导成此后一直可利用。

这项研究及 Simon Willison 在 2025 年 11 月 25 日的评论，早于后来的 CLI 迁移。按原文记载，Google 于 2026 年 6 月 18 日宣布，Gemini CLI 和 Gemini Code Assist IDE 扩展停止服务 Google AI Pro/Ultra 及免费个人用户，替代路径是 Antigravity CLI（agy）；Gemini Code Assist Standard/Enterprise 和付费 API-key 用户仍可继续使用 Gemini CLI。不能把早期安全研究直接当成这次迁移后的实测结果。

hooks 和沙箱，究竟在哪一步起作用

两家的关键拦截点都是 PreToolUse：在工具执行前拒绝调用，或者改写输入。PostToolUse 已经晚了一步，无法撤销命令完成的外发或文件修改。

Antigravity 从项目 .agents/hooks.json 和用户 ~/.gemini/config/hooks.json 加载 hooks。文档列出的事件包括 SessionStart、PreToolUse、PostToolUse、PreInvocation、PostInvocation、Stop。

它的 PreToolUse 决策包括 allow、auto_approve、deny、ask、force_ask、deny_unless_prior_grant，还能覆盖工具输入。但文档中的 PostToolUse 载荷不包含工具输出，只在失败时带有 error 字段，不能指望它清洗已经产生的输出。

Antigravity 的沙箱默认值还要区分入口：App 默认开启终端命令沙箱，CLI agy 默认关闭，在 auto mode 下自动开启。已进入沙箱的命令默认不能联网，read_url 允许的域名会加入沙箱出站白名单；两个入口的非工作区访问默认都为 false。

企业账户使用 unsandboxed(...)，个人账户使用 command(...) 作为逃逸语法。原文没有找到除语法之外、由账户类型决定的默认沙箱差异。更关键的是，终端沙箱并不覆盖所有文件工具和浏览器子代理。

Codex 的沙箱模式是 read-only、默认的 workspace-write、danger-full-access。审批策略包括 on-request 和 never，approvals_reviewer 可以是 user 或 auto_review。审批决定是否请求越界授权，沙箱决定执行边界，两者需要一起看。作者没有从所查材料中确认沙箱默认网络策略，因此不能替团队断言「默认断网」。

Codex 默认开启 hooks，下面是原文给出的关闭配置，用来排查本地是否把这层控制关掉了：

[features]
hooks = false

要看的是 hooks = false，它关闭功能，不是加强防护。非托管 hooks 还需通过 /hooks 审查并信任；托管 hooks 经 requirements.toml 和 MDM 下发。项目 .codex/ 未受信任时，项目 hooks 不加载，用户和系统层 hooks 仍按各自配置加载。

hook 返回拒绝，与 hook 自己执行失败，是两种不同的安全结果。

Codex 明确记录：受支持的显式拒绝可以阻止动作，但回调报错、超时或响应格式错误，可能只让 hook 失败，工具仍继续执行。Antigravity 对这些故障究竟放行还是阻断，作者核对时没有找到文档说明。未知不能当成安全保证。

ReclaimLLM 补了哪些洞，又留下哪些边界

原文后半部分是产品方案介绍。ReclaimLLM 默认的 rclm-hooks-install 已包含 Antigravity 集成，覆盖 PreInvocation、PostInvocation、PreToolUse、PostToolUse 和 Stop。

它在 PreToolUse 做两类预防。Env DLP，即针对环境文件的数据泄露防护，会拒绝对已识别 env 路径使用 view_file、write_to_file、replace_file_content，并拦截 run_command 中倾倒环境文件的模式。

Egress guard 则拦截面向非白名单目的地的常见外传程序和内联 fetch 模式，还提供 GeoIP 国家防火墙。同一套出站守卫也覆盖 Codex。

但「有预防」不等于「所有检测都支持」。自动外发异常检测器 AD-015 已公布的客户端包括 Claude Code、Cursor、Codex CLI、GitHub Copilot、Gemini CLI、Windsurf、OpenCode，没有 Antigravity。原文明确提醒，不能把它算进 Antigravity 的检测覆盖范围。

日志也是单独一层。rclm-sync --antigravity 可以补录历史会话，实时会话通过 Stop hooks 上传；上传脱敏不会自动清理厂商留在磁盘上的原始记录。

Antigravity 的会话路径示例为 ~/.gemini/antigravity-cli/brain/<session-id>/.system_generated/logs/transcript.jsonl，不同版本还使用过 antigravity、antigravity-ide 目录名。MCP 配置在 ~/.gemini/config/mcp_config.json，OAuth 令牌在 ~/.gemini/antigravity/mcp_oauth_tokens.json，都应按凭据存储审查权限和轮换。

Codex 完整会话在 ~/.codex/sessions/YYYY/MM/DD/rollout-*.jsonl，另有提示索引 ~/.codex/history.jsonl。ReclaimLLM 的 rclm-sync 导入前者，不把后者当完整会话来源；团队清理记录时仍需考虑两处。

最后，ReclaimLLM 的数据驻留仅支持美国和欧盟。原文称 SOC 2 Type II 目标是 2027 年初，当时尚未获得认证，不能把计划写成已具备的资质。

我的判断

我认可作者把读取、输出、外发拆开，也认可把规则拒绝和执行器故障分开。这能避免团队看到「沙箱已开启」「hooks 已安装」，就误以为防护已经闭环。

但它是带有产品推广目的的文档对照与方案说明。PromptArmor 案例提供了攻击证据，却不是两款产品当前版本的横向测试；文中也没有给出 ReclaimLLM 的漏报率、误报率、绕过测试或性能对照。其效果应视为作者声明的能力范围，不能直接背书。

基于路径、命令模式的 hooks 适合快速建立规则；网络白名单约束连接目的地，CI 密钥扫描和凭据托管又处理不同阶段的问题。这些控制需要组合。尤其「识别到就拒绝」有两个前提：规则识别到了，hook 也正常运行了。

会话采集同样有取舍。它能提供审计证据，也会增加敏感内容的存储位置。国内团队评估这类服务时，应把数据驻留、脱敏范围和保留期限一起算进去。

能拿来做什么

• 给前端和 Node 项目列出助手不应读取的 env 路径，并把限制放到 PreToolUse；用无效测试凭据检查文件读取、命令输出和浏览器外发三条路径。
• 分别检查 IDE 与 CLI 的沙箱设置、浏览器白名单和出站策略，特别确认 Antigravity App 与 agy 的默认差异，不要直接复制另一入口的使用结论。
• 验证 hook 崩溃、超时、返回格式错误时工具是否继续执行，并检查 hooks 缺失能否告警；只测一次正常拒绝不足以确认边界。
• 把本地会话、提示索引和 MCP 令牌纳入权限、保留期限与轮换管理；接入会话采集前，确认上传脱敏与本地原始文件分别如何处理。