给 Agent 上护栏：hooks 拦截实战，12 家主流工具都支持了

为什么是现在：拦截能力成了标配

Digital Applied 10 月初的横评确认了一个里程碑：截至 2026 年 10 月 3 日，Claude Code、OpenAI Codex、Cursor、Gemini CLI、GitHub Copilot、Windsurf、Kiro、Factory、Augment、Amp、OpenCode、Cline——12 家主流 coding agent 全部提供了拦截工具调用的官方机制，只有 Continue 还没有文档。

这意味着什么？意味着「agent 执行危险操作前先过我这一关」不再是某家独有的高级功能，而是行业标配。问题从「能不能配护栏」变成了「你配了没有」。

护栏一：密钥外泄拦截——把扫描点从 commit 提前到 prompt

传统密钥扫描卡在 git commit 那一刻。但 agent 时代，密钥泄露发生在更早的地方：agent 调试时打开 .env 看变量名、把文件内容贴进 prompt「看看哪里错了」、把 credential echo 进终端命令——这些动作都不经过 git，但密钥已经发给了模型厂商、写进了聊天记录。

GitGuardian 的 ggshield 给出的解法是：通过各家的 hook 系统实时扫描 agent 的交互，检测到密钥时在到达模型之前拦截，并告诉开发者删掉它。配置思路：PreToolUse 类钩子 + 密钥模式库，命中即阻断。记住原则：扫描点越靠近「发出」越好，commit 时已经晚了。

护栏二：危险命令确认——rm -rf 必须经过人

这是最朴素也最重要的一条：凡是不可逆操作（删文件、删库、发版、改生产配置），hook 必须弹确认。Claude Code 的做法是 permission 规则 + 询问；Cursor/Copilot 也有类似的命令白名单机制。

实操建议分三层：读操作默认放行（读文件、查日志、跑测试），写操作按目录分级（src 下可写、infra/ 需确认），破坏性操作一律人工确认（删除、覆盖、外部发布）。别把什么都设成要确认——确认疲劳比没有护栏更危险，agent 唠叨三次你就会全点「允许」，护栏名存实亡。

护栏三：文件写入围栏——agent 只能动它该动的

给 agent 划工作区：允许写的目录白名单 + 敏感目录黑名单。.env、密钥目录、CI 密钥、生产配置——这些地方 agent 连读都应该受限，更别说写。Mandiant 9 月披露的案例就是前车之鉴：攻击者劫持了开发者的 agent 会话，让它推荐了投毒的 PyPI 包——会话一旦被劫持，agent 的权限就是攻击者的权限。

围栏要配两层：路径围栏（哪些目录可写）和内容围栏（写入内容里不能出现密钥模式、不能包含可疑外联 URL）。前者防误操作，后者防投毒。

护栏四：审计留痕——出事之后能复盘

每条被拦截/放行的工具调用都要留日志：时间、agent、调用内容、决策（放行/拦截/人工确认）、确认人。Codility 这类平台已经在做「每个 prompt、每条命令、每次代码变更都进报告」——个人开发者至少要做到：hook 日志落盘，保留 30 天。

审计的价值不在平时，在出事那天：密钥是怎么 leak 的、那条删库命令是谁点的确认、投毒包是什么时候被推荐的——没有日志，这些问题一个都答不上来。

落地清单：今晚就能做的 5 件事

1）查你用的 agent 的 hooks/permission 文档，把机制先摸清楚；2）配密钥拦截钩子，先保住 .env；3）设三层确认策略，重点卡住不可逆操作；4）划文件围栏，敏感目录默认拒绝；5）开审计日志，落盘保留。Ponytail 那种「少写代码」的 skill 是油门，hooks 护栏是刹车——2026 年的 agent 工程，油门和刹车要一起装。