代理密钥需要风险预算

Shuriken 的 shuriken-skills 仓库打包了面向 Claude Code、Codex CLI、GitHub Copilot CLI、Gemini CLI、Cursor、OpenCode 以及兼容 AGENTS.md 的代理的说明。¹该仓库还会把这些代理引向一个平台。在该平台上，代理密钥可以读取市场数据、检查钱包、请求报价，并在用户授予相应能力后执行交易。²

重点不在交易本身。重点在于这种模式：代理如今需要凭证，才能使用那些会产生真实外部影响的工具。代理密钥不应像普通 API 密钥那样运行。它应当像一份风险预算。

代理密钥是一种有边界的授权对象。它应说明代理能做什么、不能做什么、最多能制造多大风险、操作者如何检查其行为，以及有人能以多快的速度暂停、轮换或撤销它。提示词说明有帮助，但真正划定边界的是服务器端限制。

摘要

MCP 和可移植技能让代理更容易连接外部系统。³⁴这种可移植性也提高了凭证的重要性。Shuriken 的文档描述了危险工具应采用的正确控制形态：创建代理密钥，只授予必要权限，在服务器端强制执行限制，记录活动，并在集成不再需要时撤销密钥。²⁵⁶近期关于最小权限的研究也指向同一方向：技能可能执行超出特定任务最小范围的操作，因此权限必须感知任务，而不是按整个软件包一刀切。⁹

这条经验并不限于金融领域。任何会转账、发布内容、修改基础设施、向客户发送消息或接触私有数据的代理工具，都需要带有风险预算的限定范围密钥。预算应位于模型之下，也应位于技能文件之下。即使代理非常自信地提出请求，服务器也应拒绝未授权操作。

关键要点

• 对代理工具构建者：应把凭证设计成能力预算，而不是通用的持有者令牌。
• 对安全团队：将读取范围与写入或执行范围分开，再在执行侧施加支出、速率和对象限制。
• 对产品团队：活动日志和撤销控制应放在主 UI 中，而不是埋在设置页深处。
• 对 MCP 构建者：将工具分发与凭证授权视为不同层面。技能可以传授方法。密钥必须施加约束。
• 对操作者：先从只读开始，验证集成路径，再在具备响应预案后添加写入访问。

技能分发说明，密钥分发权限

shuriken-skills 仓库展示了一种新的分发模式。一个源代码树中包含技能 Markdown、面向 Claude 和 Codex 的插件清单、Cursor 插件清单、Gemini 扩展文件、OpenCode 插件、Rust crate，以及 AGENTS.md 后备路径。¹⁷

这种打包方式很重要，因为代理说明现在会跨客户端流动。供应商可以教 Codex、Claude Code、Cursor、Gemini 以及其他工具如何接入同一个 API。MCP 文档将代理技能描述为可移植的说明集，可为编码助手提供领域知识，包括围绕部署模型、认证流程和工具模式的设计决策。⁴我在代理技能需要包管理器中讨论过分发侧；安全侧则从这些软件包请求真实权限时开始。

可移植说明解决了一个问题，也制造了另一个问题。它们能帮助代理学习正确的集成路径，却不能保证最终操作安全。技能可以告诉模型使用最小权限。提示词可以说“请谨慎”。README 可以解释推荐的权限范围。但在模型决定发出请求之后，这些控制都无法拦截已认证请求。

这种张力与MCP 服务器正在成为新的攻击面中更广泛的 MCP 问题一致：工具访问扩展操作面的速度，已经超过了旧式审批习惯所能跟上的速度。代理技能让说明路径变得可移植。密钥系统则必须让权限路径保持狭窄。

因此，凭证需要自己的设计。技能文件位于说明层。代理密钥位于授权层。混淆这两个层面会让系统变得脆弱：同一段文本既负责教代理该做什么，又试图阻止代理做得过多。

边界应由服务器承担。

Shuriken 模式是一份风险预算

Shuriken 的 Agent Kit 文档将代理密钥描述为控制 AI 工具能做什么的对象，范围从读取代币价格到执行交易不等；在代理开始行动前，限制会先在服务器端强制执行。⁵权限页面列出了 6 类权限，并说明超出已授予范围的调用会因授权错误而失败。⁶

这种表述也避免了公开代理演示中的一个常见错误：把开放代码、可见说明或可读插件清单当作边界。开放性有助于审查，但开源不是安全边界。真正的边界存在于未授权操作会失败的地方。

这种模式包含 5 个部分：

这正是高风险代理工具应有的形态。该设计并不依赖模型变得明智。它假设模型可能出错、过度自信、被输入攻陷，或只是收到了一条糟糕指令。服务器仍然会强制执行密钥限制。

我会复制这种控制模式，而不是复制它的领域。部署密钥、发布密钥、客户消息密钥、Stripe 退款密钥和交易密钥都需要回答同一个问题：在真人察觉之前，这个密钥最多能造成多大损害？

服务器端限制胜过提示词承诺

OpenAI Agents SDK 文档将护栏描述为可围绕代理运行的检查，包括带触发器的输入护栏和输出护栏。⁸护栏有价值，因为它们能在模型执行前后捕获风险。但它们与凭证权限仍处在不同层级。

输出护栏可以标记一项糟糕的拟议操作。即使护栏漏掉了，服务器端密钥限制仍可拒绝该操作。当操作超越文本本身时，这一区别至关重要。

设想一个工具可以发布文章、发送电子邮件、修改 DNS 记录、合并 pull request 或执行交易。提示词规则可以写着“请先询问”。护栏可以检查高风险文本。服务器端密钥则可以执行真正的限制：

提示词规则可能悄无声息地失效。密钥层边界会产生可观察的拒绝。这个拒绝就是证据。代理试图超出范围。服务器拒绝了。操作者可以检查失败请求，并决定该集成需要新的密钥、更窄的工作流，还是人工审批步骤。

这也是证据关口背后的同一逻辑：信任应来自可观察证明，而不是自信。最终回答说“我遵守了限制”，不如服务器日志显示哪条限制被触发来得有分量。

它也会把最终回答变成更接近审查包的东西。审查包正在成为新的最终回答认为，严肃的代理工作需要证据工件。凭证拒绝、活动日志和限定范围密钥变更，就是这种工件在安全领域的版本。

代理凭证的最低形态

任何会影响外部世界的代理凭证，都应具备 6 项属性。

Shuriken 技能也用集成语言表达了同一个核心原则：每个集成创建一个密钥，授予最低权限，妥善保管密钥，疑似泄露后轮换，并撤销已退役集成。⁷它们的范围界定技能还将读取范围与交易范围分开，并警告不要创建宽泛的“以防万一”密钥。⁷

研究语汇正在追上产品模式。SkillScope 论文将过度授权描述为受任务条件影响：同一个技能操作对某个用户请求可能有效，对另一个请求却可能过度。⁹作者报告了 7,039 个具备已验证过度授权行为的技能，并称在其框架约束权限后，触发的过度授权操作实例减少了 88.56%。⁹您无需复制它的具体机制，也能接受其产品层面的经验：代理凭证应反映当前任务，而不是工具能想象到的最大任务。

这应成为常规的代理产品设计。宽泛的 API 密钥在后端服务拥有狭窄代码路径时是合理的。代理不像一条狭窄代码路径。它们会规划、重试、组合工具、总结失败、调用辅助脚本，并响应外部输入。凭证应假设代理行为比普通服务令牌更具变化性。

这种变化性也解释了为什么代理代码搜索存在 token 预算问题即使在凭证文章中也相关。代理常常在上下文不完整时做决定。窄密钥能在上下文窗口漏掉危险细节时，给系统第二次机会。

不要照搬什么

不要照搬营销式乐观。

Shuriken 的公开文档使用了较强的措辞，描述代理可在用户离开时行动并捕捉机会。²这或许适合他们的产品。但它不应成为会产生外部影响的代理工具的默认安全姿态。

对于高风险操作，“在您离开时”需要更窄的操作含义：

• 代理可以在用户离开时收集信息；
• 代理可以在用户离开时准备操作草稿；
• 代理只能在小而明确、由服务器强制执行的预算内执行；
• 操作者事后可以检查每一次操作；
• 操作者可以立即暂停或撤销密钥。

这就是自治与放弃责任之间的区别。用户可以委派行动。系统不能委派问责。

同样的谨慎也适用于技能和插件清单。一个仓库可以支持所有代理客户端，同时仍然应采用保守默认值。我检查的 .codex-plugin/plugin.json 在接口元数据中列出了读取能力，而文档说明交易需要显式启用权限和限制。⁷这是正确方向：分发可以广泛，权限必须从狭窄开始。

决策规则

当新的代理集成请求凭证时，应先对密钥分类，再发放。

这张表给了代理一条可用路径，同时不假装边界由模型本身持有。工作流仍可改进。密钥则防止改进滑向无边界权限。代理执行追踪是执行环境契约从审计侧提出了同一点：如果系统无法展示发生了什么，就无法证明代理是在预期契约内行动。

我在代理沙箱安全只是一种建议中也写过同样的拆分：模型可能完全在已授予权限内操作，却仍然产生不安全结果。代理密钥需要风险预算，因为权限不等于安全。

FAQ

代理密钥只是换了名字的 API 密钥吗？

不是。普通 API 密钥通常会授予对某项服务的宽泛访问。代理密钥应为单个集成授予一组受边界约束的能力，并配备服务器端限制、活动日志和撤销能力，且撤销不影响用户主会话。

为什么服务器端强制执行很重要？

服务器能看到最终请求。模型说明、技能文件或护栏可能漏掉糟糕操作。若密钥缺少必要范围，或超出已配置限制，服务器端权限检查可以拒绝请求。⁶

每个代理都应从只读开始吗？

当工具会产生有意义的外部影响时，是的。先从只读访问开始，验证集成路径。只有当团队清楚日志、限制、审批和回滚步骤已经存在后，才添加写入或执行权限。

MCP 会让代理凭证风险更高吗？

MCP 让外部工具更容易跨客户端连接。³这种便利性提高了凭证设计的重要性。可移植工具访问应配套狭窄密钥，而不是更宽泛的信任。

团队应从 Shuriken 复制什么？

复制说明分发与服务器端权限之间的分离：可移植技能可以传授集成方式，而限定范围的密钥、限制、日志和撤销负责约束行动。除非产品、法律和运营控制足以支撑，否则不要复制特定于交易领域的行为。

参考资料