我用 Claude Code 改一份线上的配置文件，它只扫了开头几行，就把整份文件重写了一遍，把我没打算动的那段直接删掉，还顺手把注释格式全改了。我盯着 diff 愣了两秒：它干得很对，只是它理解的范围比我允许的大。代价是半天的回滚和一次团队复盘。那一刻我才反应过来，问题不在它聪不聪明，在我没把「不许动」焊进结构里。
==agent 系统的安全，不能指望它自觉守边界，只能把边界做成结构上不允许。==
它看到开头，就敢覆盖整份文件
10-27 Anthropic 发的 claude-code v2.1.312，修的正是这类事故：以前 agent 只读到超大 CLAUDE.md、规则文件或者 @-包含文件的开头，就直接 Write 覆盖整份；现在 Write 会要求先读全，或者就地编辑。这不是修一个 bug，是承认一条工程事实——把「能不能改」的开关交给模型自己判断，迟早出事。
我每天用编码助手做真实生产改造，这种「只看了头就动手」的翻车不是个案。上个月我让它改一个 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 分发。==把「不许做」写进结构，比教它「应该做」可靠十倍。==
数据说明
- claude-code v2.1.312 于 2026-10-27 发布，修复 agent 在只读到大文件开头时即整体 Write 覆盖的行为；改动来自官方 release notes，非我方实测复现。
- eMudhra 八张中间 CA 私钥可被从证书恢复的披露发生在 2026-10-22，10-28 观察到 macOS Git 仍信任相关证书；Go 1.27.3 已修复对应校验，但下游环境跟进滞后属行业普遍现象。
- 文中个人经历（编码助手改坏下游字段、腾讯云自运维信任清单、国网体系审批门与执行点分工）为本人真实工程经验，用于说明「边界必须长在结构里」这一判断，不构成对任何具体系统的评价。
- 本文为基于个人视角的原创分析，非厂商发布稿。