我用 Claude Code 改一份线上的配置文件,它只扫了开头几行,就把整份文件重写了一遍,把我没打算动的那段直接删掉,还顺手把注释格式全改了。我盯着 diff 愣了两秒:它干得很对,只是它理解的范围比我允许的大。代价是半天的回滚和一次团队复盘。那一刻我才反应过来,问题不在它聪不聪明,在我没把「不许动」焊进结构里。
agent 系统的安全,不能指望它自觉守边界,只能把边界做成结构上不允许。
10-27 Anthropic 发的 claude-code v2.1.312,修的正是这类事故:以前 agent 只读到超大 CLAUDE.md、规则文件或者 @-包含文件的开头,就直接 Write 覆盖整份;现在 Write 会要求先读全,或者就地编辑。
我每天用编码助手做真实生产改造,这种「只看了头就动手」的翻车不是个案。上个月我让它改一个 Go 服务的路由配置,它读完前几十行就自信地重写,把下游三个服务还在用的旧字段名改掉了,CI 半夜红了才被发现。复盘时我们确认,故障不在模型,在我把「能不能改」的开关交给了模型自己判断。根子在于:写权限的边界被放在了「模型该不该」这一层,而不是「工具允不允许」这一层。给 agent 写权限,等于在给它一把没有上限的钥匙。 正确做法是让写操作默认带「先读后写」的硬约束,跟模型聪不聪明无关,这是工具层的责任,不是提示词层的祈祷。后来我把那条配置改了:凡涉及下游字段,必须先读全文件、且改动走评审,不让 agent 直接落盘。
同一周还有另一件同源的事。eMudhra 有八张中间 CA 的私钥能从证书本身被恢复,10-22 我就记过一次;10-28 的新进展更扎心,macOS 上的 Git 过了十天,还在信任那些被攻破的证书。Go 1.27.3 早就修了,可大量环境根本没跟上。
我在国网体系的项目里学到过一条:审批单管的是人,真正兜底的边界在执行点上。变电站远程巡检系统上线前,任何改动都要先在执行点校验「这个人有没有权限动这台设备」,而不是靠谁在审批单上签了字。审批单管的是人,执行点管的是系统,两层少一层都会出事。 信任根也是一样。你不能指望操作系统「自觉」地收回一份已经失效的信任,必须在自己的边界上主动去拉吊销清单。我自运维腾讯云轻量服务器时就吃过亏:系统默认信任的 CA,往往比真相慢半拍。所以我在服务器上专门放了一份自维护的信任清单,每周比对一次官方公告,不靠系统替我决定信谁。信任链的失效不像软件能热修,它只会沉默地继续信任。
这两件事摆在一起,结论很清楚:默认允许最省事,也最危险。默认允许是最隐蔽的漏洞,因为它看起来什么都没发生。
第一,给编码助手的写操作加「先读后写」硬约束。在规则文件里写明:改动任何超过一定行数的文件,必须先完整读取再编辑,禁止用 Write 整体覆盖。这条我现在就写进项目的 CLAUDE.md,比事后看 diff 便宜得多。
第二,自运维环境主动拉吊销,别只信系统默认信任链。写个定时任务去查依赖的证书与漏洞公告;Docker 镜像里的 CA 包要单独版本钉住,升级要显式审批,不能跟着基础镜像悄悄漂。
第三,把「默认拒绝」写进 agent 的工具权限。每个工具先列不允许做的,而不是列允许做的;凭据按用途短时效、按 scope 分发。把「不许做」写进结构,比教它「应该做」可靠十倍。
模型会换,边界与验证这道关不会换。