2026 年，OWASP 发布了 Agentic Applications Top 10，其中 ASI04（Agent 供应链漏洞）是全新加入的条目。同期 Gartner 预测，到 2028 年，40% 的 Fortune 1000 企业会将”AI Agent 超出预期约束行事”列为头号 AI 风险。
这两个数据放在一起看，指向一个比”prompt injection”更隐蔽的问题：Agent 不需要越狱。它只需要墙慢慢变矮。
最小权限的错位
传统安全里的”最小权限”（least privilege）假设权限是静态的。一个角色需要什么，就给它什么，不多不少。但 Agent 的权限是动态加载的——每次任务启动时从上下文中读取可用工具列表，而不是从一个固定的角色模板中继承。
Cequence Security 在一篇分析里说得很直接：Agent 的权限集应该反映它的功能，而不是操作者的凭证。一个做竞品调研的 Agent 只需要访问 CRM 数据，它不应该继承操作者对财务系统、内部通讯和基础设施 API 的访问权。
问题是，大多数部署方案直接把操作者的凭据交给了 Agent。
这不是技术疏忽。这是一个认知偏差：我们把 Agent 当成了”帮我做事的工具”，而不是”用我的身份做事的独立主体”。当 Agent 用我的凭证调我的 API 时，它做的每一个操作在审计日志里都显示为”我做的”。权限边界从第一天起就是模糊的。
漂移的四种路径
我观察了 Agent 权限失控的几个真实场景，发现它们很少是单次的大失误，更多是缓慢累积：
工具叠加。 今天给 Agent 加一个搜索工具，明天加一个邮件工具，后天加一个文件读写。每个单独看都是合理的。三个月后，Agent 拥有的权限组合起来能做的事，没有人做过完整的评估。
上下文膨胀。 Agent 加载的工具上下文越来越多。某个 MCP Server 原本只提供日历查询，后来更新了版本，顺手加入了日程创建和删除。Agent 的工具列表没有审计，权限就跟着上游更新自动扩大了。
任务边界模糊。 你让 Agent “帮我整理一下最近的会议纪要”，它读完了纪要，发现里面提到了某个项目的进度问题，于是主动去查了那个项目的数据库。它没有越权——它只是在完成一个边界模糊的任务。但结果是你没有授权它去查那个数据库。
沉默累积。 Agent 的权限变化没有触发任何告警。没有”权限变更通知”，没有”新增工具审批”。它只是在某个时间点之后，能做的事变多了。操作者不知道，Agent 也不知道自己在做什么不同的事。
权限应该发生在运行时，不是部署时
AvePoint 的一份指南提出了三层执行模型：部署时最小集、任务时动态扩展、持续的任务范围执行。核心思路是——权限在工具调用的那一刻被检查，而不是在 Agent 启动时被一次性授予。
这个思路对。但实现起来有一个根本性的困难：谁来定义”这个任务需要哪些工具”？
如果由人来定义，那就回到了审批流程的老路，Agent 的灵活性被完全牺牲。如果由 Agent 自己定义，那等于让被审计者自己写审计标准。
目前看起来比较可行的折中方案是”白名单 + 范围限定”：给 Agent 一个允许使用的工具白名单，每个工具附带明确的参数约束（比如文件读写只能访问特定目录，邮件发送只能发送到内部域名）。然后在运行时，Agent 的每次工具调用都经过一层策略引擎的拦截和校验。
这不是完美的方案。但它至少让权限边界从”模糊的直觉”变成了”可审计的规则”。
审计日志的问题
当 Agent 用操作者的身份执行操作时，审计日志记录的是操作者的 ID，而不是 Agent 的 ID。这意味着一旦发生问题，你无法从日志中区分哪些是人的操作，哪些是 Agent 的操作。
BeyondTrust 在一篇关于 Agent 身份治理的文章中提到，Agent 在端点上执行时，运行在与所有其他进程相同的权限模型下。一条指令可能在几秒内触发数十个子进程，全部使用相同的权限级别。
这个问题比我最初想象的更严重。它不只是”Agent 能做太多事”的问题，而是”出了事之后无法追溯”的问题。不可追溯的权限，等于没有权限管理。
回到最小权限的本意
“最小权限”这个词来自传统安全工程，它的本意不是”给最少”，而是”给恰好够”。给多了一点，就多了一层攻击面。给少了一点，功能就跑不通。
Agent 时代，“恰好够”的定义变得更难了。因为 Agent 的”够”是随任务变化的，不是随角色固定的。
但难不等于可以不做。2025 年有 75% 的组织经历过至少一次 AI 相关的安全事件。大多数不是因为 Agent 被恶意攻击，而是因为权限边界从一开始就没有被认真定义过。
墙不是被推倒的。它是在没人注意的时候，一块砖一块砖地被拿走的。