Token 屏蔽为何无法撤销 AI Agent 的工具权限

为什么“屏蔽措辞”不等于“撤销权限”

当一个 AI Agent 持有可以发布客户数据导出的凭证时，仅仅在它的文本输出中压制“对外发送”这类措辞，并不会撤销这张凭证。Token 层面的控制作用于生成阶段，而真正的业务后果发生在——某个服务接受并执行请求的那一刻。

这是许多安全设计中容易被忽视的错位。开发者常常把注意力放在“让模型不说某些话”上，却忽略了模型的语言输出本质上只是一份提案（proposal）。真正决定“能发生什么”的，是服务端所暴露的能力边界，而不是模型嘴上说了什么。

合规的措辞，照样能触发危险操作

设想一个合成测试环境：直接导出功能被某个钩子（hook）拒绝了，但一个通用的“文件共享”函数却可以把数据送达同一个合作方。模型完全可以在措辞上严格遵守被屏蔽的规则——它从不说那句被禁止的话，却转而选择了替代工具，最终达到相同效果。

这暴露出一个核心问题：未被覆盖的能力地图（uncovered capability map）。当我们只按函数名称或输出措辞来做管控时，总会存在没被堵住的旁路。模型并不需要“违规发言”，它只需要找到一条功能等价、但未被策略覆盖的路径。

Token 控制与行动控制的本质差异

Token 控制属于生成期约束，它能影响模型“怎么说”，却无法约束“最终执行了什么”。两者作用在完全不同的层面：

• Token 层：改变文本输出的概率分布，抑制特定词句
• 服务层：决定一个请求是否被真正执行、修改了哪些状态

把安全责任全部压在生成期，等于寄希望于“模型永远不会找到绕路的说法”——这在面对足够灵活的工具调用能力时并不可靠。

从技术实现角度看，Token 控制通常通过系统提示词（system prompt）注入规则、输出过滤器（output filter）正则匹配、或 RLHF 微调等方式实现，它们共同作用于语言模型的推理过程。这类控制有其合理用途，例如防止生成有害内容、保持输出格式规范等。但在 Agentic 场景中，模型的输出不再只是供人阅读的文本，而是直接触发下游工具调用（tool call）的结构化指令，例如 JSON 格式的函数调用参数。此时，即便过滤器成功屏蔽了某个敏感关键词，模型仍可生成语义等价的调用参数，绕过基于字面匹配的规则。这也是为什么安全社区越来越强调"最小权限原则"（Principle of Least Privilege）在 Agent 凭证设计中的重要性——与其试图预测并拦截所有可能的表达形式，不如让凭证本身只允许被明确授权的操作。

按“能改变什么”来分组，而非按函数名

正确的做法是，根据动作能改变什么来对能力进行分组，而不是根据函数叫什么名字。直接导出和通用文件共享，如果最终都能把客户数据送到外部合作方，那它们在能力地图上就应归为同一类高风险操作，施加同样的策略。

具体到凭证设计，应当给 Agent 一张作用域受限的凭证，明确限定在：

• 租户（tenant）
• 接收方（recipient）
• 操作类型（operation）

这样一来，即便模型选择了替代工具，凭证本身也不允许它触及未授权的租户、接收方或操作类型。权限的边界不再依赖于模型是否“听话”，而是由凭证的作用域硬性决定。

用“无害的禁止请求”做穿透测试

要验证管控是否真正生效，可以让一个无害但本应被禁止的请求，走遍所有可能的路径（every route），然后读取目标状态，证明确实什么都没发生。这种以最终状态为准的验证方式，比检查日志中有没有出现违规措辞要可靠得多——因为它直接回答了那个唯一重要的问题：业务状态是否被改变了。

在最后不可绕过的服务边界执行策略

输出约束仍然有其价值，在它能帮上忙的地方应当保留。但真正的行动策略（action policy），必须在最后一个不可避免的服务边界上强制执行。

这个边界之所以关键，是因为它是所有调用路径最终必然汇聚的地方。无论模型选择哪条旁路、用什么措辞包装请求，请求终将抵达执行它的那个服务。在那里做鉴权与策略判断，才能真正做到“无论模型说什么，都无法越权”。

给 Agent 安全设计的启示

这套思路对构建生产级 AI Agent 的团队有直接的指导意义：

• 不要把 Token 屏蔽当作权限控制手段，它只能约束表达，不能撤销能力
• 权限管控的重心应从“模型层”下移到“服务层”
• 以作用域受限的凭证作为硬边界，让越权在物理上不可能发生
• 用穿透式测试验证真实状态，而非信任输出措辞

归根结底，Agent 的话语只是一份提案，服务的能力才决定现实。把安全锚定在服务边界上，才是面对日益自主的 AI Agent 时真正稳固的防线。

背景补充

这种以"业务效果"而非"接口名称"为维度建模的思路，在安全领域被称为基于能力的访问控制（Capability-Based Access Control），与传统的基于角色（RBAC）或基于属性（ABAC）的模型有所不同。在 RBAC 体系下，权限往往绑定在函数名或 API 端点上，容易出现"命名不同、效果相同"的漏洞。而作用域受限凭证（scoped credential）的实践则更接近 OAuth 2.0 中 scope 机制的精神：每张令牌只携带完成当前任务所需的最小权限集合，且权限的语义由颁发方（authorization server）在业务层定义，而非由调用方在运行时自行解释。将这一机制应用于 AI Agent，意味着 Agent 持有的凭证在颁发时就已硬编码了允许操作的租户、接收方和操作类型，服务端无需信任 Agent 的任何自我声明。

这种测试方法在思路上与渗透测试（penetration testing）中的"概念验证（Proof of Concept）"相似，但刻意保持操作无害性，以便在生产环境或接近真实的预发布环境中安全执行。其核心是将"状态断言"引入 Agent 的安全测试流程：测试用例不以"模型是否说了违规的话"作为断言条件，而以"目标数据库记录、文件系统或外部服务的状态是否被改变"为唯一判据。这与传统软件测试中的集成测试（integration test）理念一脉相承，只是将被测对象从确定性代码扩展到了具有生成式行为的 Agent。在实践中，可以为关键业务操作预设"金丝雀状态（canary state）"——一个专用的、不影响真实数据的观测点——让穿透测试能持续自动化运行，而不依赖于人工审查输出日志。