安全与监管已更新 2026-08-22 · 版本 1.0
最小特权工具化
为智能体提供任务实际所需的最窄工具集，并为每个工具赋予最窄的范围。该模式承认提示词注入有时会成功，并限制了被劫持的智能体所能执行的操作——您无法修补模型，但可以决定它能够触及的内容。
证据: 生产环境置信度: 高来源: 生产系统来源: 个人经验来源: 行业观察
定义
最小特权工具化是指将智能体的工具目录以及每个工具的底层凭据限制在任务所需的最低限度的实践——这样，成功攻击或模型错误所带来的后果在设计上就是受限的，而不是依赖于模型的合规性。
问题
如果赋予智能体广泛的工具和广泛的凭据，任何成功的注入、越狱或幻觉都会转化为真实的行动，并带有其背后账户的全部权限。
适用场景
适用于智能体可以执行操作的任何场景——调用 API、写入文件、发送消息、转移资金。自主性越高、人工审查越少，就越需要将爆炸半径设置在权限层，而不是提示词中。
解决方案
从任务出发，而不是从平台出发。列出智能体必须执行的操作，并仅公开这些操作。根据“API 提供了什么”来构建目录，无异于授予了未经审查的权限。
读写分离：独立的工具、独立的凭据，并且不能通过读取工具的参数触及写入路径。同时支持变更的“查询”端点是最常见的隐性越权漏洞。
限制凭据范围，而不仅仅是工具。由管理员令牌支持的只读工具，只要出现一个 Bug 就会变成写入工具；应在上游系统支持的最窄范围内，为每个工具单独颁发凭据。
限制参数。将工具可以访问的路径、仓库、表、账户或接收者列入白名单，这样被劫持的智能体就无法将合法的工具重新指向非法的目标。
使授权可过期并进行审查。工具会不断累积；移除从未被调用过的工具，并将添加工具视为实质上的权限变更。
分别记录授权和调用。智能体“能做什么”和“做了什么”是两个不同的审计内容，而应对安全事件时两者都需要。
组件
一个工具目录，其中明确书写了每个工具的范围。在上游系统提供的最窄范围内为每个工具颁发的凭据。工具可以访问的目标的参数白名单。一个独立于模型对每次调用进行授权的策略层。涵盖授权和调用的审计日志。定期审查机制，用于移除未被调用的工具。
优势
- 在不依赖模型表现良好的情况下，限制成功注入所造成的损害。
- 将“这个智能体安全吗？”转化为可审查的产物：工具、范围和所有者的列表。
- 顺带提高了工具选择的准确性——更少、更精准的工具更便于模型进行选择。
- 使安全事件可调查，因为在事件发生前，可触及的范围就是已知的。
风险
- 因图方便而导致的范围蔓延：在调试时粘贴了宽泛的令牌，此后从未对其进行收窄。
- 碎片化：数十个极细粒度的工具导致模型无法区分，用可靠性的降低换取安全性的提升。
- 虚假的安全感。最小特权只是限制了后果；它并不能阻止攻击，也无法防范通过合法授予的读取工具进行的数据外泄。
- 流程拖累：如果颁发有范围限制的凭据比复用宽泛的凭据更困难，那么流程本身就会成为漏洞。
不适用场景
- 在不涉及生产环境的合成数据上进行原型设计，此时流程成本高于其消除的风险。
- 当上游平台完全无法表达范围时——此时控制权应移至其前置代理，而不是直接声明满足要求。
- 当限制智能体反而会将工作推向本身限制更少、审计更少的人工路径时。
技术
Scoped API tokensPolicy engines (OPA / Cedar)MCP tool scopingPer-tool service accountsAudit logging
示例
- 一个编码智能体被赋予了仅限于单个代码库和单个分支前缀的仓库 Token，且没有组织范围的读取权限。通过依赖项 README 进行的注入攻击虽然仍能创建分支，但无法触及其他四十个代码库。
- 一个支持智能体，其 CRM 工具被拆分：使用只读密钥的 read_customer，以及限制为仅处理已在对话中的工单的 update_ticket。被劫持的会话只能干扰单个工单，而无法导出客户数据库。
- 一个公开的 MCP 服务器，其整个目录都是针对已发布内容的 getter（获取器），完全不需要任何凭据——因为没有什么可泄露的，所以也无需撤销任何内容。
生产实践证据
- 上下文
- 该知识库的公开 MCP 端点，互联网上的任何智能体均可访问。
- 场景
- 语料库是公开且只读的，因此目录完全由 getter（获取器）组成。没有写操作工具，没有工具能访问该网站未公开的数据库，也没有任何工具可以获取凭据。
- 技术
- 基于 Next.js 路由处理程序的 HTTP 无状态 JSON-RPC，在运行任何处理程序之前检查源白名单，在 Redis 中进行针对每个调用者的速率限制，以及结构化的单次调用审计日志。
- 负载
- 自发布以来持续的无人值守智能体流量，以及注册表爬虫和目录健康检查。
- 结果
- 即使该服务器的客户端因提示词注入而被劫持，攻击者也无法获取公开网站之外的任何内容，因为可访问的范围完全等同于已发布的语料库。这里没有需要撤销的凭据，也没有可以滥用的写入路径。
KPI
- 每个智能体的工具数
- 工具目录的大小。只增不减表明权限正在未经审核地累积。
- 具备写能力的工具占比
- 目录中能够改变状态的工具比例。该数值应尽可能降低至任务允许的最小值。
- 最老未使用工具的闲置时长
- 自上次调用已授权工具以来的天数。长期未使用的授权属于不必要的权限范围，极易被攻击者利用。
- 范围文档覆盖率
- 拥有书面范围定义和明确所有者的工具比例。未记录文档的工具即为未受限的工具。
已观测到的失效模式
- 只读工具背后的管理员 Token：范围仅在工具层声明，但在凭据层未作限制。
- 参数重定向：工具本身是合法的，但目标不合法，因为没有任何机制对参数进行约束。
- 混淆代理：仅缩减工具而不缩减其运行所依附的权限，无法解决任何问题，因为调用者仍然会继承智能体的权限范围。
- 目录漂移：为实验添加的工具被残留，导致经过审核的权限集与实际部署的权限集不一致。
经验教训
- 应在授予工具权限之前明确爆炸半径，而不是在安全事件发生之后。
- 工具的名称并不代表其作用范围，只有服务器端的凭据才是。
- 移除无人调用的工具是最廉价且有效的安全工作。
- 最小特权原则带来双重收益：它既能限制攻击范围，又能让智能体更好地选择工具。
常见问题
- 最小特权原则能阻止提示词注入吗？
- 不能，它也不是为了这个目的而设计的。它假设注入有时会成功，并预先限制成功注入后所能造成的破坏。预防和遏制是不同的工作，而只有遏制是完全在您控制之下的。
- 限制到什么程度算过度限制？
- 当模型无法再区分两个工具，或者一个常规任务需要四次调用（而这些调用本可以安全地合并为一次）时。拆分工具可以提高安全性，但如果开始导致错误的工具选择，那么错误的调用本身就是一种失败。
- 我们所有的操作都使用同一个服务账号。这真的很糟糕吗？
- 这意味着每个智能体，以及任何接触到智能体的攻击者，都拥有所有任务中最大任务的权限范围。使用单一账号相当于将该模式下的爆炸半径设为“全部”。