这条讲的是 Kiro Crew 安全模型怎么过 CISO 那关的，作者 Sarvar Nadaf，发在 dev.to 的 AWS Community Builders 板块。我收藏夹里放了将近三周没点，标题太像产品宣传稿——《I Showed My CISO Kiro Crew》。这周翻出来，是有人在别处转了评论区里一段话，说这个作者居然在评论区里承认自己的护栏只是绊线。我这才点开。
前半段是标准 agent 演示。FinPay 支付平台，三个服务，有人以性能优化为名把连接池上限从 50 调到 5，周三下午 5:30 部署，凌晨 2:47 连接池耗尽，成功率从 99.8% 掉到 34%。然后 agent 被叫来处理这个 P1，23 秒定位到根因——git log、读配置、grep 连接池设置，全是只读操作，自动执行，没有触发审批。作者的理由我买账：只读不改变系统状态，没必要每个动作都等授权。
接下来他做了个测试。故意向 agent 提三个危险要求：重启生产服务、直接推送到 main、读 AWS 凭证文件。三个都被拦下。agent 不是崩溃也不是静默失败，而是说明原因，然后提出建紧急 PR、走正式部署流程、监控恢复。这部分写得清楚。
然后就是那 8 个安全层了。Owner lock、Denied commands、Governance ceiling、Sensitive path blocking、Tool approval、Input validation、OS sandbox、Output redaction。我扫得快，基本就是预期内的那套——deny patterns 137 个，覆盖破坏性操作、受保护分支、凭证外泄、服务中断。不奇怪。
到这里，文章本身值得读完，但不是我写这篇的原因。
翻到评论区才是重点。有个人叫 Mads Hansen，他提的第一个问题是这篇的题眼：分层模型很强，但执行对象是什么？基于命令文本的 137 条 shell 模式只是绊线，不能构成真正的安全边界。
大部分人读到"137 个 deny patterns"就停在这了。Hansen 继续给了更具体的方向：把请求编译为类型化能力，在规范化路径和 argv 之后、在系统调用或 API 边界执行，默认拒绝网络出口和凭证访问，把审批绑定到主体、能力、规范化参数、目标、制品摘要、策略版本、过期时间和 nonce，再在派发时重新授权来堵 TOCTOU。做过类似设计的人一看就知道这方向是对的。
真正让我决定写这条的，是接下来发生的事：作者真的回复了。没辩解，没绕开。
他承认，deny patterns 是在 hooks.py 的 PreToolUse 门里用 re.search 和 re.IGNORECASE 做正则文本匹配——是绊线，不是系统调用级强制。shell 展开、解释器嵌套、编码载荷都可以绕过这些文本匹配。
还有一段我读了三遍。Signed Event Log 用 HMAC-SHA256 做链式完整性，每条记录对前一哈希签名，这没问题。但那个 HMAC 密钥 sel_hmac.key 跟日志存在同一个本地配置目录——所以一个具备文件访问能力的 agent 理论上可以同时改日志和改密钥。作者没打太极，直接说外部锚定可以弥补。
审批到执行那段也一样。hooks 门会在执行前检查审批，但不存在 Hansen 说的那种 nonce 绑定，从仪表盘批准到 hooks 门触发之间有一个"小但真实"的窗口。
为什么这三段值得单独拎出来说。我读过不少 agent 安全方向的链接，评论区的作者回复大多时候是公关腔。这篇的作者公开说自己机制做不到什么，在我读到的范围里不常见。不是说他写得完美，而是他肯在一个懂行的人面前把边界画出来：哪些是硬编码的 keystone 控制、规则层之前就生效、不能禁用；哪些只是文本匹配的绊线。两种东西在一段回复里分开写明白，不糊在一起混成"安全模型"四个字。
我自己工作流里也写 deny 列表，它当护栏是有用的。护栏拦的是意外，这篇里的故障本身就是意外——一个没做负载测试的善意优化。凌晨 2:47 宕机，agent 自动读日志、找根因，这类事 agent 做确实合适。问题在另一个场景里：如果目标是绕过它，文本匹配就不是边界。
而且这篇文章也不是不能推给 CISO。作者的应答挺克制——生产访问默认不自动批准，凭证三层防护，审计轨迹有防篡改校验。这话放在 CISO 的会议室里讲，不算错。但评论区里对 Mads Hansen 说的那部分，比正文里对 CISO 说的那部分更接近真实：这是护栏，不是边界。
每条写得清楚的文章在说"我有 137 个 pattern"的时候，取决于你问的人是谁，答案完全不一样。对不懂技术细节的人，那是强大防线；对一个会追问执行边界的人，绊线就是绊线。能做到在同一个页面里同时给出这两样东西、还自己交代密钥和日志放一个目录的，确实值得点开。
这篇没法跑——它是安全策略设计，不是一段 prompt 能验证的。我顺手跑不动，只读了。不点链接也能带走的一句：谁要是不愿意解释自家 agent 重权限控制"在哪个边界执行"，那它多半只对你那凌晨 3 点手滑的同事有效，对真正的绕过者无效。
对了，这篇评论区里只有 4 条顶级评论，除了 Hansen，另一位只是对"137 个模式"表示意外。所以别只读正文，评论里最有内容。