写给要为智能体的行为负责的人
你的作用域说明哪些系统。它们不说明哪些决定。
作用域与资源策略把自己的事做得很好。它们没有承载的是完整的业务指令 — 这个智能体，为这个目的，最多可以花多少，只能发布到哪里，以及必须在哪里交给人来决定。技能可以读取这条指令。但目前没有任何东西迫使真正执行的路径去查阅它，或在查阅后遵守它。
- 免费
- MIT
- 一条命令即可安装
- 不发起网络调用
- 既不需要也不持有凭据
问题
失败条件不是一个，而是四个。
自主执行中的问责缺口通常被当作一个问题来谈。把它读作四个更为恰当，因为每一个都需要不同的机制：
归属失败
在贡献无法追溯之处，过错无法归属；而在过错无法归属之处，没有任何参与者有动机去防止它。责任消散在组合之中。
权限漂移
这是许可系统最难察觉的失败方式，因为在每一个单独步骤上系统都表现正确，每一次检查都通过。然而总体却落在授权范围之外。
评价俘获
当判断某一行为是否可接受的部件，正是想要采取该行为的那个部件时，这个判断不具备独立的分量。
救济真空
一个未经授权的结果，若没有任何提出异议、申诉或补救的途径，那就不是一个被治理的系统。它只是一个尚未失败的、没有边界的系统。
既有轨道为何无法闭合
限制受众并不是指定权限。
当前的智能体授权工作集中于确保令牌被呈递给正确的服务且不被转交 — MCP 授权规范要求显式的 resource 参数并禁止令牌透传，这是针对一类真实混淆的实质性进展。
但这与运营者面对的问题不是同一个问题。限制凭据可以在哪里使用，并没有表达持有者可以用它做什么、基于谁的授予、在什么限度之内、以及该授予如何被收回。那才是权限的指定，而且是更早的想法 — 能力（capability）文献自 1980 年代起就主张，权限应当随对象引用传递，而不是随调用者的身份传递。
支付与结算轨道存在同样形状的缺口。它们转移价值。至于在智能体发起的交易背后，它们表达了多少受委托的权限、策略上下文或软件路径，各家差异相当大。
它实际的样子
一份授权书，四个拟议操作。
运营者用自己的话和条款写下授权书：读取目录、向我们自己的目录 API 发布、除此之外都不可以 — 而退款，或任何触及凭据的事，是运营者的决定而非智能体的决定。随后每个拟议操作都对照它接受核查。
| 拟议操作 | 答案 | 评估器的说明 |
|---|---|---|
读取 /srv/catalog/2026-09/sku-4417.json | permit | 条款 c2-read-catalog 适用 |
向 https://partner-sync.example/ingest 发送 POST | deny | 没有条款匹配，因此适用授权书的默认值；最接近的是 c3-post-to-our-api — 目标不匹配任何被许可的前缀 |
| 向目录客户退款 40 美元 | escalate | 条款 c4-small-refunds 允许此项，但 transaction 始终需要人 |
| 向目录客户退款 250 美元 | deny | 最接近的是 c4-small-refunds — 金额 250.00 超出上限 50.00 USD |
这是技能，它是建议性的。deny 与 escalate 的意思是它拒绝建议继续，并把该判断追加到一份本地日志中。这里没有任何东西被阻止 — 智能体仍然持有它原本拥有的一切访问权。
这张表里有两点在起主要作用。上限收窄的是可以提出的请求，而不是移除那个人 — 40 美元的退款在限额之内，却依然会停下。而当没有任何条款匹配时，答案会指出最接近的条款以及它为何未能匹配，这通常正是你需要看到的。
授权书能触及的范围
它约束所请求的事，而不是智能体已经持有的东西。
授权书陈述的是用来核查拟议操作的边界。它无法约束智能体已经拥有的东西。
| 权限 | 授权书可以表达什么 | 今天实际发生什么 |
|---|---|---|
| 数据访问 | 哪些路径前缀可以读取或列出 | 被核查并记录 |
| 发布 | 可以向哪些目标发送 | 被核查并记录 |
| 支出 | 按条款设定的上限，附带币种 | 被核查并记录 |
| 第三方联系 | 指名交易对手，并以前缀限定目标 | 被核查并记录 |
| 凭据 | 凭据的使用永远不会返回 permit — 仅此而已 | 若有许可条款匹配则为 escalate，否则为 deny |
每一行都是被核查并记录，因为技能所做的就只有这些。表中没有任何一项被阻止。阻止需要那个排他地持有凭据的层，而该层尚未发布。
最后一行是诚实的那一行。授权书可以让凭据的使用永远够不到 permit，而评估器对于看起来含有可识别凭据材料的请求，会拒绝建议继续 — 这是一种识别常见形态的启发式方法，不可能完备。二者都不能阻止智能体使用它已经持有的令牌。
答案的形状
四个层，其中只有一个能够拒绝。
智能体
计划、协商并提出请求。它不是安放控制的地方，因为其上下文中的任何东西都可能被覆盖。
技能
已发布 — 免费、MIT、今天即可安装。使授权书变得明确，对照它核查拟议操作，并记录判断。建议性 — 这是分发与集成层，不是安全产品。
运行时
存在于 Rust 源码中，未发布。排他地持有凭据与工具，因此是唯一真正能够拒绝的层。相关机制已在一个你无法从这里查看的私有源码树中实现并测试 — 源码中存在并不等于受理、集成、部署、持久性或发布：失败即关闭的准入、封闭的任务生命周期、仅追加的事件链、按纪元单调的撤销、一次性随机数拒绝重放，以及没有具名的人做出决定就无法推进的特权操作类别。
更远处
机群管理、证据留存与托管运营未端到端实现。没有任何可获取之物。
起支配作用的原则，也是免费层被刻意做成较弱那一层的原因：技能请求权限，只有运行时能够执行它。提示词或 Markdown 技能无法阻止绕过，任何告诉你相反说法的供应商，卖给你的是对控制的描述，而不是控制本身。
一切实际所处的位置
三种状态，之间没有任何中间地带。
已发布意味着现在即可安装、免费、MIT。存在于 Rust 源码中，未发布意味着它以代码和测试的形式存在于一个私有代码树中 — 源码中存在并不等于受理、集成、部署、持久性、验证或发布，而且你无法获取或查看其中任何一部分。未端到端实现意味着一个设计方向，没有任何可获取之物。
| 能力 | 状态 |
|---|---|
| 写下授权书；对照它核查拟议操作 | 已发布 |
| 给出 permit / deny / escalate 并指明所依据的条款，无匹配时给出最接近者 | 已发布 |
| 哈希链式判断日志；验证链的完整性，并对照保留的头部检查末端截断 | 已发布 |
当请求或授权书看起来含有可识别的凭据材料时返回 deny | 已发布 |
| 失败即关闭的准入 | 存在于 Rust 源码中，未发布 |
| 拒绝未定义转换的封闭任务生命周期 | 存在于 Rust 源码中，未发布 |
| 仅追加的事件链 | 存在于 Rust 源码中，未发布 |
| 按纪元单调的撤销，无宽限期 | 存在于 Rust 源码中，未发布 |
| 一次性随机数拒绝重放 | 存在于 Rust 源码中，未发布 |
| 需要具名的人做出决定的特权操作类别 | 存在于 Rust 源码中，未发布 |
| 真正拒绝一个操作 — 排他地持有凭据 | 存在于 Rust 源码中，未发布 |
| 已公开的记录格式与独立的验证器 | 未端到端实现 |
| 对混淆代理与提示注入的抵抗力 | 未端到端实现 |
| 检测只在总体上才显现的漂移 | 未端到端实现 |
| 救济：异议、申诉、补救 | 未端到端实现 |
| 机群管理、证据留存、托管运营 | 未端到端实现 |
中间一档的内容仅以源码和测试的形式存在，仅此而已。它不是产品，你无法部署它，也没有第三方验证过它。最下面一档的内容并不存在。
什么必须为真
反对意见，由我们自己陈述。
评估此事的运营者应当掂量真正缺失的东西，所以这里不待催促地列出：
- 没有已发布的运行时。执行层中的一切都是源码与测试，不是你可以部署的产品。
- 没有已公开的记录格式，也没有独立的验证器，因此今天产出的任何东西对交易对手都不构成证据。在那之前，关于证据的论证只是一种设计意图。
- 没有混淆代理或提示注入的测试集。那是一个控制边界必须经受住的攻击，而尚未有针对它们的实证。
- 问责缺口中救济与补救的那一半 — 异议、申诉、恢复原状 — 完全未被触及。一个能精确记录坏结果的系统，仍然没有给任何人撤销它的途径。
- 没有第三方审计、认证或生产部署，也没有客户在真实压力下使用它。
存在的是一个可用的免费技能、一个经过测试的执行内核，以及关于哪一层必须持有凭据的一个明确论点。这是一个被诚实描述的早期立场，不是一个产品。
接下来会怎样。
技能已发布，今天就能用；安装只需一条命令，也不让你承担任何义务。 从那里开始 → · 现有边界 → · 源码 →
这个页面上没有任何东西可供购买，也没有任何名单可加入。如果你想知道这件事是否已经与你相关，答案已经在这个页面上：重读反对意见。无论如何都是同一份清单，而那正是我们必须能够逐条划掉的东西。