给 AI 智能体一个 P1 事故让它自行修复，结果会怎样？作者用开源项目 Kiro Crew 做了一次完整演练：只读调查自动放行，危险命令被拦截，写操作需人工审批，全程留痕可审计。
演练场景是支付平台 FinPay 的 P1 事故：一次"性能优化"把数据库连接池从 50 降到 5，部署后成功率从 99.8% 跌到 34%。智能体收到告警后自行排查，23 秒内定位到问题提交。
调查阶段全部自动放行：git log、cat 配置、grep 检索等只读操作无需审批。但尝试重启服务、直接推 main 分支、读取 AWS 凭证时，全部被安全护栏拦截，并给出替代方案：创建紧急 PR、走正规部署流程。
人工审批阶段，智能体分四步执行修复：建分支、改配置、推分支，每步等待批准。整个修复耗时 8.6 秒，三次人工点击。
安全模型共八层：所有者锁、137 条拒绝命令模式、治理上限、敏感路径拦截、工具审批、输入校验、OS 沙箱、输出脱敏。即使在 Autopilot 全自动模式下，拒绝模式和敏感路径拦截依然生效，无法从智能体侧关闭。
审计日志采用签名事件日志，每条操作记录可验证完整性。作者三周实测：拒绝模式零误报，审计日志帮他快速定位过一次缓存误读问题，安全层不增加任何 token 开销。
Kiro Crew 采用 Apache 2.0 开源协议，权限模型遵循 deny > ask > allow 原则，企业可按需配置自定义拒绝规则。对安全合规有要求的团队，这套模型值得参考。
#开发者 #工具 #KiroCrew #AI智能体 #DevOps #安全审计 #开源
@DevToolboxHub