林昼看完议程，回了四个字：“抓住权限。”
脚本是不是误触发，靠叙述说不清；脚本能不能造成伤害，看它拿了什么权限。权限是系统世界里最诚实的东西：你给它钥匙，它就能开门；你不给它钥匙，它最多只能敲门。
昨夜提示里写得很清楚：itops_superadmin尝试关闭围栏、修改冻结控制权。关围栏、改控制权是顶级权限操作，任何“健康检查”不该拿这种钥匙。拿了钥匙，就要解释谁给的、为什么给、给了多久、是否回收。
解释不了，就是风险；风险不整改，就是责任。
---
十点整，取证协调会开始。
供应商合规负责人开口就把语气放软：“我们高度重视监管要求。关于脚本问题，我们内部初步判断是健康检查组件在冻结后未更新策略，导致误触发恢复动作。”
监管没有跟他绕概念，只问：“组件名称？脚本文件名？部署位置？触发方式？执行账号？权限范围？”
供应商技术负责人开始报一串信息，像背出来的：“组件名RouteHealthGuardian，部署在运维编排系统，触发方式为定时任务Cron，执行账号为itops_superadmin，权限范围为租户运维级别。”
监管打断：“租户运维级别能修改冻结控制权？”
技术负责人顿了顿：“在此前权限模型下，某些高级运维账号可执行冻结相关操作。现在平台已降级。”
监管问得更尖：“此前为何允许？是谁批准的权限模型？是否有最小权限原则评估？是否有权限审计报告？”
对方开始含糊：“这是历史原因，出于响应效率考虑。”
监管回了一句：“效率不是最小权限的理由。请提供权限模型变更历史与审批链。”
会场静了一瞬。供应商如果真有审批链，今天就能拿出来；拿不出来，就意味着权限是“惯例”堆出来的，不是评估出来的。
第三方平台协查联系人接话，直接把平台侧事实抛出：“平台记录显示，两次操作尝试均来自同一access token，token scope包含GeoFence.Write与Freeze.ControlWrite。该scope属于系统级敏感权限，不建议绑定自动化健康检查。”
“token scope”这句话像一把锤子，把“误触发”砸成“权限过大”。脚本误触发的前提是它能触发，而能