按风险打分的权限

步骤 1弄清你买到的是两样东西里的哪一样。

厂商如今把两种不同的机制装在同一句营销话术底下，而两者的运维工作完全不同。

• 按任务发权限。没有常驻访问权；智能体拿到单个任务所需、只在该任务期间持有，上限是委派它的那个人的权限。这就是把凭据寿命做对，它严格优于一个服务账号，而且不需要任何新的证据机制——授权依然存在，只是短。
• 对一个算出来的分数做分级响应。一个逐智能体持续更新的数字决定它此刻可以做什么：收回写而保留读、收窄数据、插进一个人、停掉运行时。微软在 2026 年 10 月 19 日发布了第一个主流的企业版本（Dynamic Agent Risk 喂给 Dynamic Conditional Access，信号来自身份、数据、设备、云、网络以及智能体自身的动作）；ServiceNow 10 月那套漂移响应——重定向、限制、停用——是从另一个方向来的同一形状。

第一样东西不需要本页的任何内容。下面的一切都是关于第二样的，因为一个算出来的权限是一个你如今依赖、而此前并不运维的控制平面。

步骤 2档位表自己写；一个连续的分数不是一条策略。

一个 0 到 100 之间的分数是一项输入。策略是从分数到能力的那个映射，而如果你不去撰写它，你就继承了一个为「中位数客户」挑好的厂商默认值——而那个客户不是你。三档是正确的起步数量：多于三档，没人能预测智能体的行为；少于三档，降级就是一道悬崖。

给每一档起的名字要说清智能体失去了什么，而不是它的数值区间——因为区间会被重新调校，而能力契约不该随之移动：

• 正常。完整的、按任务限定的权限。智能体 99% 的时间都在这一档，也是你在优化其成本的那一档。
• 只读。每一次写、发送、提交、付款与删除都被拒绝；读取与规划继续。这一档正是分级响应的全部意义所在：它对智能体来说是活得下去的，而它关掉了致命三要素的外发那条腿——而那条腿正是一个被攻陷的智能体造成实际损害的机制。
• 停止。运行时被终止，并呼人。请把它留给那些指示「被攻陷」而非「有点怪」的信号，因为一次停止就是一次停机，而停机有它自己的事故。

有两条规则能替你省下一个糟糕的季度。第一，把档位边界显式钉住并做版本管理，这样厂商重新调校其打分分布时，不会无声地改掉你的策略——这正是未钉住的厂商默认值在别处所主张的同一种纪律。第二，加上回差（hysteresis）：要求分数在一个边界之上持续一段时间才降级，并要明显低于它才升回。没有这一条，一个靠近边界的智能体会在任务中途在两档之间来回跳，而来回跳严格劣于其中任何一档。

步骤 3把分数和决定一起记下来，否则你根本没有证据。

这是会被跳过的那一步，也正是让其余部分立得住的那一步。你现有的审计轨迹记下了智能体做了什么、什么被拒绝了。它没有记下那个做出决定的数字——也就是说，每一次复盘都会问的那一个问题：为什么这件事 14:05 被允许、14:35 被拒绝？——在你自己的系统里没有答案。

每一个被放行和每一个被拒绝的动作上都要有三个字段，不是只有被拒绝的那些：

# the minimum record for a scored decision
{
  "action":          "invoices.write",
  "outcome":         "refused",
  "risk_score":      78.4,        # value AT decision time, not now
  "band":            "read-only",
  "band_policy_ver": "2026-10-14.3", # which mapping was in force
  "score_inputs":    ["network", "agent_actions"]
}

分数与档位通常取得到；策略版本要由你自己发出；而那些起作用的信号是你得去争的那一项，也正是审计师真正想要的那一项。把保留期设成覆盖你自己的复盘窗口以及任何法定窗口，并拿它和厂商默认值对一遍——一个只保留七天的分数支撑不起一场九十天的调查。这就是一份多了一个字段的决策回执，而多出来的那个字段就是全部差别。

步骤 4在测打分器准不准之前，先测它缺席时会怎样。

每个人对一个新检测器的第一个问题都是它的误报率。那是第二个问题。第一个问题是：当打分器不应答时，你的系统会怎么做——因为静态策略的失效方向是你选的，而打分式节流阀的失效方向是从实现细节里掉出来的。在上生产之前，在预发环境把这四种情况全跑一遍，并把观测到的行为写进运行手册：

• 陈旧。打分器返回上一次已知的值。智能体保有上一个有效分数替它买来的全部权限——包括那个分数正要上升的那一个。
• 缺失。打分器什么都不返回。如果「缺失」映射为低风险，那么所有智能体会同时、无声地被提权；正是这一种会把一次打分器故障变成一起安全事故。请把它当成一个失效关闭还是失效放开的问题来定，并在策略里写明。
• 滞后。分数是对的，但晚到几分钟。请度量这个滞后；它才是这个节流阀所能围堵范围的真实上界，而它不在任何一份规格表上。
• 来回跳。分数在一个边界上下振荡。STEP 2 的回差是解法；请靠注入一个振荡的分数来验证它，而不是靠相信那个配置项。

然后再测准确率，方法见评测护栏与检测器——并且要清醒地看到：智能体天生就是异常的，这正是通用基线表现不佳的原因，也正是检测智能体被攻陷里那些轨迹形状的信号值得加权的原因。

步骤 5给降级定价：一个在任务中途失去写权限的智能体，是一件做了一半的活。

设计讨论谈的是「该不该降级」。事故永远是关于「降级对在途工作做了什么」，而这正是没人列进预算的那项成本。一个在十七步的活里走到第十二步、却在第十三步失去写权限的智能体，已经对世界做了十二次改动，而做不了第十三次。如果第十三步正是让前面十二步变得自洽的那一步——那次提交、那封确认邮件、那条账目——那么你就用一项安全控制制造出了一处不一致。

• 让降级边界成为检查点边界。如果这个循环有持久状态，就在两步之间降级并把位置持久化，这样任务可以从权限停下的地方续跑，而不是重跑。
• 在启用节流阀之前，先要求写操作是幂等的。降级之后再试就是一次重试，而幂等性正是让它不会把某人扣两次款的东西。
• 把搁住的任务送进一个队列，而不是送进虚空。一个被降级的智能体应当留下一个可审阅的条目；否则围堵是看不见的，而那件活会悄悄地不发生——这正是用户报成「它有时候跑不完」的那个失败模式。
• 把停止路径放在带外。如果档位逻辑和智能体跑在同一个控制平面里，那么控制平面被攻陷就会把两者一起拿掉——见紧急开关。

把降级当成一项一等指标来埋点，和拒绝率、错误率并列。一个一个月没人见它触发过的节流阀，要么调得很好，要么就是没接上——而这两者从仪表板上看起来一模一样。

步骤 6诚实的边界，好让你为它真正做到的事情买它。

一个打分式节流阀减少的是一个被攻陷或正在漂移的智能体接下来能做什么。这有价值，而且它很窄。它做不到的四件事：

• 它不阻止提示词注入。注入照样命中；节流阀缩短的是之后发生的事。结构性防御仍然是打断三要素的一条腿，而出站白名单比任何分数都更便宜、更确定。
• 它覆盖不到没人纳管的智能体。打分只作用于平台认识的身份。那个带着 API key 和一个循环的脚本、那个 CI 作业、那个工作站工具——都没有分数，而且它们不是无害的那一尾。请把节流阀与给智能体发目录账号配对，并把纳管缺口本身当成那个发现。
• 它不取代访问审查。它拿掉的正是审查过去所读的那些常驻授权，这让审查智能体凭据变难了、而不是变得不必要：你要审查的东西变成了那张档位表，以及每一档的可达集合。
• 它不能跨厂商迁移。由一个领地的遥测算出来的分数，与另一个领地的不可比，也无法在它之外重建。如果你的智能体跨多个云，请把每个分数都当成构造上就不完整的东西，并按那个领地真正看得见的范围来给节流阀定尺寸。