AI Agent 最小权限实践：能力标签驱动的授权模型 · 行业洞察

“先跑起来”的技术债

Agent 接入的典型路径是这样的：给它一个能用的令牌，让它把流程跑通，验证价值，然后投入使用。

这个路径本身没错——先验证价值是合理的工程判断。问题在于第二步：几乎没有团队回头收紧过权限。 那个为了调试方便给的组织级令牌，一路跟着 Agent 进了生产。

后果不是理论上的。Agent 的行为由模型动态决定，而不是由代码固定。这意味着“它现在能做什么”和“它将来会做什么”之间没有确定的映射——当它拥有超出任务所需的权限时，你实际上是在依赖模型的判断力做安全边界。而模型的判断力，正是提示词注入攻击的目标。

企业已有成熟的身份与访问管理体系，直接套用到 Agent 上却会遇到三个错配：

主体不稳定。 传统 IAM 假设主体（用户、服务）的行为模式相对固定。Agent 的行为随任务、随上下文、随模型版本变化，用静态角色描述它天然不准。

权限粒度错位。 IAM 通常按资源和操作授权（“可读取 S3 桶 X”）。而 Agent 的风险单元是能力（“能读取任意本地文件”、“能发起外部网络请求”）——同一个能力可能横跨多个工具和资源，而同一个工具可能同时具备多种能力。

授权时机不同。 传统授权是接入时的一次性决策。Agent 生态中工具随时增删、MCP Server 静默更新，权限面在持续变化，需要的是持续评估而非一次审批。

可行的做法是在工具与权限之间插入一层抽象：能力标签。

不去问“这个 MCP Server 叫什么名字”，而是问“它启用后，Agent 会获得哪些能力”，并把答案标准化成一组标签。典型的能力域包括：

这套标签的价值在于可比较、可策略化。你可以规定“任何带 shell 执行标签的工具必须走人工审批”，而不必逐个工具讨论；也可以在工具更新后重新打标签，用标签变化触发重新评估——声明的能力变了，说明风险面变了。

一、按任务授权，不按工具授权。

先定义 Agent 要完成的任务需要哪些能力，再据此挑选工具与凭证。这个顺序很关键：反过来（先挑工具、再看它要什么权限）几乎必然导致过度授权，因为工具作者总倾向于要更多权限以覆盖更多场景。

二、警惕能力组合。

单个能力可能无害，组合起来则不然。“读取本地文件”加“发起外部网络请求”，等于数据外传能力；“读取环境变量”加“执行 shell”，等于凭证窃取加横向移动。授权评估必须看能力集合的交互，而不是逐项打勾。

这正是很多实际事故的成因：每一个工具单独看都合理，凑在一起就打开了一条完整的攻击链。

三、不可逆动作单独把关。

删除、支付、对外发送、生产配置变更——这类动作的共同点是出错无法撤销。它们应该从常规权限中剥离出来，要求显式确认或独立审批，无论 Agent 有多“可信”。

接入时：对每个工具/MCP Server 做能力审计，产出标签集，比对声明与实现（工具说自己只读日历，实现里却有文件写入能力——这种不一致本身就是风险信号）。据此产出 block / need_review / pass 判定。

运行时：凭证按 Agent、按任务隔离，作用域最小化，且可独立吊销。网络出口白名单作为兜底——即使工具被投毒，数据也出不去。

持续：记录 Agent 的实际工具调用，与授权范围比对。长期未被使用的能力应当回收——这是最容易被忽略、但成本最低的收紧手段。工具版本变化时触发重新评估。

Agent 安全的核心问题正在从“这个工具是不是恶意的”转向“这个工具被启用后，Agent 会获得哪些需要审批的能力”。前者是恶意检测的问题，后者是能力审计的问题——而企业的准入决策，需要的是后者的答案。

这也是 SkillSec 的方法论基础：把 Agent 生态的组件（Skills、MCP Server）按能力域拆解，用分级证据支撑判定，让权限决策建立在“它能做什么”而不是“它看起来像不像坏人”之上。

最小权限不是新概念，它只是在 Agent 场景下变得更难、也更重要——因为这一次，被授权的主体会自己决定做什么。

---