Agent权限管理的五层分析框架与四个核心目标

当 Agent 需要发送邮件、读取文件、执行代码或者操作银行账户时，最直接的安全设计通常是弹出一个确认框：

是否允许此次操作？

但确认框只是权限管理最外层的交互。

用户点击“允许”之后，系统究竟允许了什么？是只允许当前操作，还是允许这个工具在整个会话中持续运行？用户表达的意图会被转换成什么内部策略？最终负责放行的又是规则引擎、另一个大模型，还是 Agent 自己？

这些问题没有统一答案。

2026 年 7 月，华盛顿大学的 Alexandra E. Michael 和 Franziska Roesner 发布论文《How Agents Ask for Permission: User Permissions for AI Agents, from Interfaces to Enforcement》。

论文原文（arXiv）

论文梳理了 21 个学术研究和开源系统，并对 Claude、Claude Cowork、ChatGPT 对话模式、ChatGPT Agent 模式以及 Codex 五类商业 Agent 进行了走查分析。

这篇论文没有再提出一种新的权限系统，而是给出了一个更基础的分析框架：

Agent 权限管理不是一个确认弹窗，而是一条从用户意图到运行时执行的完整链路。

论文将这条链路拆成五层，并进一步提炼出四个核心目标。它真正揭示的问题是：当前研究和商业产品往往只解决了其中一部分，很少有系统能够同时兼顾易用性、形式化和可靠执行。

为什么传统应用权限无法直接照搬到 Agent

传统应用的行为相对确定。

一个地图应用申请定位权限，操作系统大致知道它获得定位权限后能够访问什么。一个相机应用请求摄像头权限，其能力边界也可以提前定义。

Agent 不一样。

Agent 接收到一个任务后，会由大模型动态规划执行路径。用户说“帮我整理最近的报销邮件”，Agent 可能只搜索邮件，也可能读取附件、下载表格、提取金额，再把结果写入本地文件。

同一个任务，在不同上下文中甚至可能产生完全不同的工具调用序列。

更麻烦的是，Agent 接触到的外部信息不只是数据，也可能影响后续决策。邮件正文、网页内容、工具返回结果，都可能夹带提示注入指令。模型幻觉同样可能让 Agent 偏离原始任务。

因此，论文没有沿用传统安全领域中严格分开的“数据流”和“控制流”，而是使用了一个更贴近 Agent 的概念：

任务流，Task Flow。

任务流包含 Agent 完成任务过程中流动的数据、指令和动作。权限系统需要保护的，不只是某一份敏感数据是否泄露，还包括整个执行过程是否始终处于用户授权范围内。

例如，用户允许 Agent 搜索机票，并不代表同时授权它：

• 读取本地护照扫描件
• 将护照上传到任意旅行网站
• 使用已保存的信用卡付款
• 在价格变化后自动接受更高报价

这些动作可能都服务于“订机票”，但并不天然属于同一授权范围。

五层分析框架：权限弹窗只是其中一层

论文将 Agent 权限系统拆成五个分析层次：

• 威胁模型
• 用户权限界面
• 内部权限表示
• 权限推导
• 运行时执行

这五层不是五种独立能力，而是同一条授权链路上的五个环节。

用户看到的按钮、系统内部保存的规则，以及运行时真正执行的判断，三者可能完全不同。论文认为，分析一个 Agent 权限系统时，不能只看它是否提供了“始终允许”“仅允许一次”或者“需要批准”等选项，而要继续追问这些选项在后续环节中发生了什么。

第一层：威胁模型——权限系统究竟在防谁

权限设计首先要回答两个问题：

攻击者是谁？

需要保护的对象是什么？

论文发现，接近三分之一的研究没有明确给出威胁模型。在已经定义威胁模型的方案中，最常见的假设是：Agent 本身没有恶意，但可能受到提示注入或幻觉影响，从而错误调用工具。部分研究把第三方工具视为攻击者，也有一些研究默认工具可信，只防范工具返回的恶意内容。

这种威胁模型适用于大量现实场景，但它仍然不够完整。

例如，多用户 Agent 中可能存在恶意用户；Agent 服务商也可能成为隐私威胁；恶意子 Agent 可能故意扩大权限；攻击者还可能通过消耗 Token、云资源和资金制造经济损失。

21 个研究方案中，只有 GAAP 明确将 Agent 服务商本身纳入潜在攻击者。论文认为，当前权限研究的威胁模型仍然集中在“善意但会犯错的 Agent”上，对多用户、多 Agent 和云服务商威胁关注不足。

这意味着企业在建设权限系统前，不能只写一句“防止提示注入”。

必须明确：

• 是否信任主 Agent
• 是否信任子 Agent
• 是否信任模型服务商
• 是否信任 MCP Server 和第三方工具
• 是否信任工具返回内容
• 是否允许不同用户共享一个 Agent 执行环境

威胁模型不明确，后面的权限规则再复杂，也可能防错对象。

第二层：用户权限界面——用户如何表达授权意图

第二层是用户能够看到的权限配置界面。

论文总结了几种常见形式：

• 没有用户侧配置入口
• 使用自然语言描述策略
• 使用高敏感、低敏感等权限标签
• 从固定选项中选择
• 配置结构化约束
• 编写任意规则或代码

商业产品最常见的是固定选项，例如：

始终允许、仅本次允许、每次询问、禁止。

这种设计简单，但表达能力有限。

用户可能希望表达的是：

可以搜索公司邮箱，但不能读取附件；可以创建邮件草稿，但不能真正发送；可以删除构建目录，但不能删除源代码。

单纯以“是否允许某个工具”为粒度，很难表达这些条件。

自然语言的表达能力更强。用户可以直接告诉 Agent：

公司文件不能发给外部邮箱，除非我单独确认。

但自然语言存在歧义。用户并不知道系统最终把这句话理解成了什么，也无法确认“公司文件”“外部邮箱”和“单独确认”分别被映射成了哪些条件。

因此，自然语言适合作为权限配置入口，却未必适合作为最终执行策略。

结构化约束位于两者之间。系统提前规定可选择的主体、动作、资源和条件，用户在这个范围内组合策略。它比固定选项灵活，也比直接编写代码更容易使用和审计。

论文统计的 21 个研究方案中，有 6 个支持自然语言配置，只有少数方案提供结构化约束；允许用户编写任意函数作为权限规则的方案只有 AGENTSPEC。

第三层：内部权限表示——系统真正保存了什么

用户界面上的授权选项，不一定就是系统内部执行的策略。

例如，用户选择：

创建邮件草稿需要批准。

系统内部可能保存成一条结构化规则：

action: gmail.create_draft effect: require_approval scope: current_session

也可能只是把一句自然语言加入系统提示词：

创建邮件草稿前应当询问用户。

还可能根本没有保存独立策略，而是在每次工具调用前让另一个 LLM 临时判断。

论文将内部权限表示划分为：

• 无内部策略
• 自然语言
• 权限标签
• 固定策略
• 结构化约束
• 任意规则

在研究方案中，结构化约束是相对常见的内部表示方式。它可以基于类型系统、Datalog、DSL、时序逻辑或者信息流控制描述权限。相比之下，商业 Agent 由于闭源，论文只能通过界面和外部行为观察，无法确认其内部策略究竟如何保存。

这里存在一个容易被忽略的问题：

用户界面语义和内部策略语义可能不一致。

一个看起来明确的“需要批准”，在内部可能只是“原则上需要批准，但允许自动审查器推断用户已经同意”。

用户以为自己选择的是严格规则，系统执行的却是一个概率判断。

第四层：权限推导——用户意图如何变成系统规则

权限推导指的是系统如何把用户表达转化为内部策略。

论文总结了五种主要路径。

第一种是不进行转换。用户选择什么，系统就直接保存什么。

第二种是根据用户请求和上下文自动预测权限。例如，用户说“帮我发送这封邮件”，系统可能认为这句话已经隐含授权了发送动作。

第三种是让 AI 将用户的自然语言策略编译成结构化规则。

第四种是确定性编译，例如把用户在结构化界面中的配置转换为策略代码。

第五种是直接使用用户编写的策略，不经过额外处理。

其中最值得关注的是第二种和第三种。

两者看起来都使用了 AI，但性质完全不同。

“AI 编译”是在配置阶段工作。它把自然语言翻译成结构化策略，生成后可以让用户确认，也可以对规则进行静态检查。

“AI 预测”则是在运行时替用户推断权限。系统根据一句任务描述，自行判断用户是否已经授权某个具体动作。

前者类似用大模型辅助编写防火墙规则。

后者则相当于让大模型替用户决定防火墙是否放行。

这也是论文强调的一个核心区别：

LLM 可以帮助用户表达权限，但不应在不透明的情况下替用户扩大权限。

第五层：运行时执行——最终由谁决定放行

最后一层是权限执行。

论文将执行方式分为几类：

• 不设置独立执行机制，只要求 Agent 自觉遵守
• 由第三方工具自行判断
• 由 LLM Guardrail 判断是否合规
• 每次调用时由 AI 生成检查代码
• AI 根据策略生成一次执行代码，后续固定使用
• 使用非 AI 的自动化机制执行
• 由用户实时确认

论文特别强调，运行时执行与策略生成必须分开看。

即使策略是由 LLM 生成的，后续仍然可以由确定性的规则引擎执行。反过来，即使用户在界面中选择了固定选项，系统也可能在运行时交给 LLM 重新解释。

论文将 12 个方案归为确定性执行。这些方案要么使用不依赖 LLM 的自动化执行机制，要么在动作发生前由用户直接作出决定。

需要注意的是，“用户点击确认”只能保证授权决定由用户作出，不代表用户一定理解了风险。频繁确认还可能造成权限疲劳，最终让用户形成无条件点击“允许”的习惯。

因此，人工确认是最后一道防线，而不是完整的权限架构。

四个核心目标：前三个形成三角张力

在分析 21 个研究方案和五类商业 Agent 后，论文总结了四个贯穿整个领域的核心目标：

• 低用户负担
• 形式化策略
• 确定性执行
• 持续用户控制

前三个目标主要来自学术研究，第四个目标在商业产品中更加突出。

目标一：低用户负担

一个权限系统不能要求普通用户学习 DSL、Datalog 或信息流控制。

论文统计发现，21 个研究方案中，有 12 个尝试减少用户直接配置策略的负担。其中 6 个允许用户使用自然语言表达权限，5 个直接根据上下文预测策略，还有方案会根据用户之前少量的允许或拒绝行为训练分类器。

低负担当然重要，但降低负担通常意味着系统需要替用户做更多推断。

当系统从“帮用户写规则”进一步走向“替用户猜授权”，权限边界就可能在用户不知情的情况下扩大。

目标二：策略形式化

形式化并不是把规则写得复杂，而是让权限可以被明确表达、检查和审计。

论文中的形式化方法包括：

• 信息流控制标签
• 类型化 DSL
• Datalog
• 线性时序逻辑
• 整数线性规划
• 对 Agent 生成代码进行信息流分析

21 个方案中，有 11 个在策略层采用了一定程度的形式化方法。

但“使用形式语言”不等于“完成形式化验证”。

论文指出，没有任何一个方案真正证明其实现能够正确执行所有权限策略。部分系统对架构进行了形式化分析，GAAP 也接近运行时验证，但都没有实现经过形式验证的权限执行器。

目标三：确定性执行

权限系统应该在相同条件下产生相同结果。

如果同一个工具调用今天被允许，明天却因为大模型采样结果不同而被拒绝，那么权限就不再是一条稳定的安全边界。

论文明确把“每次由 LLM 生成执行代码”的方案排除在确定性执行之外。即使模型没有接触到恶意输入，它自身的非确定性和代码生成错误仍然会成为风险来源。

确定性执行更适合依赖：

• 规则引擎
• 类型检查
• 信息流控制
• 能力令牌
• 沙箱
• 明确的用户授权结果

LLM 可以参与语义识别，但不应成为唯一执行者。

目标四：持续用户控制

权限不是只在第一次授权时存在。

用户还需要知道：

• 当前有哪些权限
• 权限由谁授予
• 权限绑定哪个会话
• 权限什么时候过期
• 能否缩小权限范围
• 能否随时撤销
• 撤销后历史会话是否继续有效

论文发现，在 21 个研究方案中，只有 6 个明确支持用户在策略创建后修改或撤销权限，其中部分方案只能在会话之间修改，不能在正在运行的长会话中生效。

还有一些系统会根据一次“允许”自动更新未来策略，却不允许用户阻止或撤销这种学习结果。它们实际上假设：

用户在一个场景中的选择，可以推广到所有未来场景。

这个假设在权限管理中非常危险。

允许 Agent 删除一次临时文件，不应自动推导为允许它以后删除所有同类文件。

最关键的发现：没有方案同时实现前三个目标

论文最值得关注的结论，不是某一种权限方案表现最好，而是：

21 个研究方案中，没有任何一个同时实现低用户负担、形式化策略和确定性执行。

在强调低负担的系统中，有 5 个同时提供确定性执行，只有 2 个同时具备形式化策略，但没有方案能够三者兼顾。

VeriSafe Agent 和 ShieldAgent 同时考虑了低负担和形式化，却没有提供确定性执行。

AC4A 和 PRUDENTIA 最接近三个目标的交集，但仍然存在明显缺口：

AC4A 提到了资源类型，却没有真正定义完整形式系统，而且依赖第三方工具提供自己的权限执行函数；

PRUDENTIA 具有形式化和确定性基础，但大量依赖用户逐次确认，用户负担较高。

这里反映的不是一个简单的技术缺陷，而是一组结构性矛盾。

自然语言降低了配置成本，却引入语义歧义。

形式化规则提高了可审计性，却增加了配置门槛。

确定性执行提高了安全保证，却可能牺牲 Agent 面对新任务时的灵活性。

用户确认看似同时解决了表达和执行问题，却把复杂的权限决策重新交给了普通用户。

论文认为，三者并非技术上无法统一。现有系统已经分别证明了两两组合的可行性，真正缺少的是一套完整架构，把自然语言交互、形式化策略和确定性执行连接起来。

商业 Agent 的现实：要么反复弹窗，要么把决定交给模型

研究方案主要在解决如何定义和执行权限，商业产品则更关注用户是否能够实际操作。

论文在 2026 年 5 月下旬至 6 月初，对 Claude、Claude Cowork、ChatGPT 对话模式、ChatGPT Agent 模式和 Codex 进行了为期三周的走查。

由于这些系统大多闭源，作者无法确认内部实现，只能根据产品界面、可见行为以及部分工具调用日志推断权限机制。因此，这部分结果更适合看作用户侧观察，而不是完整的代码审计。

1. Claude：“需要批准”不一定真的逐次批准

Claude 的工具权限界面提供：

• Always allow
• Needs approval
• Blocked

从界面语义看，“Needs approval”意味着每次调用前都需要用户批准。

但作者观察到，即使已经选择“Needs approval”，Claude 有时仍会根据用户原始请求自动判断权限已经获得。例如，在创建邮件草稿的实验中，Claude 的 MCP 调用日志将 approvalRequired 标记为 false。

问题不在于这次操作是否合理。

真正的问题是：用户看到的权限语义是“需要批准”，系统内部执行的却是“可以由自动审查器判断是否已经隐式批准”。

这意味着界面策略和运行时策略发生了偏移。

Claude 的界面权限与实际调用日志。论文作者观察到，选择“需要批准”后，系统仍可能通过自动审查推断用户已经授权。

2. Claude Cowork：权限不继承，但旧会话也未真正失效

论文作者发现，Claude Cowork 获得某个文件夹的读取或删除权限后，用户无法直接在应用中永久撤销。

新会话不会自动继承旧会话权限，但旧会话仍保存在历史记录中。用户重新打开旧任务时，原有权限可能继续有效。论文作者当时认为，彻底撤销权限可能只能依赖操作系统权限控制或者卸载应用。

这说明会话隔离并不等于权限撤销。

真正的权限生命周期需要回答：

• 旧会话何时失效
• 已签发的令牌是否撤销
• 历史任务是否还能继续调用工具
• 用户能否查看所有仍然有效的授权

3. Codex：自动审查更透明，但粒度仍然较粗

相比 Claude，Codex 明确展示了自动审查设置，并且默认关闭，用户可以随时禁用。

但开启之后，自动审查会作用于当前会话中的所有工具。用户的选择基本是：

• 所有操作都由自动审查
• 每次操作都询问用户

系统缺少更细粒度的策略，例如：

读取代码可以自动批准，修改外部文件必须询问；执行测试命令可以自动批准，访问互联网必须询问。

因此，透明度有所提高，但权限粒度仍然有限。

Claude Cowork 的目录权限与 Codex 的会话级自动审查设置。前者暴露权限撤销问题，后者则反映自动审查粒度偏粗。

4. ChatGPT：本地连接器和远程浏览器存在不同权限边界

论文作者观察到，ChatGPT 对话模式中，与权限策略相关的工具操作通常需要用户明确批准，而且没有发现提前授权或关闭逐次确认的方式。

但在 ChatGPT Agent 模式中，模型控制的是远程浏览器。远程浏览器没有被绑定同样的工具权限策略，因此可以在浏览器中完成一些本地连接器模式下需要确认的操作。

这揭示了一个比单个工具权限更复杂的问题：

权限边界可能随着执行路径变化而变化。

同一个“读取 Gmail”动作，可以通过：

• Gmail API
• MCP 工具
• 浏览器自动化
• 桌面自动化

分别完成。

如果权限系统只拦截其中一种路径，Agent 就可能换一条路线继续执行。

因此，企业权限治理不能只按工具名称配置规则，还要覆盖不同执行环境和等价能力。

商业产品真正的两难，不是“允许还是拒绝”

论文将商业 Agent 的现实困境概括为两种选择：

第一种是用户实时确认。

这种方式透明、直接，但弹窗频繁。用户需要不断判断陌生工具名、复杂参数和潜在后果，最终容易形成权限疲劳。

第二种是 LLM 自动审查。

它减少了打扰，却把权限解释交给一个概率模型。更严重的是，用户有时并不知道自动审查正在发生，也无法控制它针对哪些工具生效。

于是，用户经常面临一个并不理想的二选一：

要么手动批准几乎每一个动作，要么放弃一部分权限控制，让系统替自己判断。

这也是论文认为商业系统与学术研究之间差距最大的地方。

学术界已经研究了信息流控制、类型系统、DSL 和确定性执行，但商业 Agent 仍然大量依赖确认弹窗和 LLM Guardrail。商业产品在权限修改和撤销界面上通常做得更实际，却没有充分吸收研究中的形式化和确定性机制。

企业 Agent 权限架构应该怎么设计

这篇论文并没有给出一套最终方案，但五层框架已经能够推导出较清晰的工程方向。

1. 自然语言负责表达，结构化策略负责承载

用户可以继续使用自然语言：

可以读取这个项目目录，但不能上传代码；删除文件必须询问我。

系统随后将其编译成结构化规则：

subject: current_agent resource: /project/** allow:

• read deny:
• external_upload require_approval:
• delete scope: session: current expires_in: 2h

关键是，编译结果必须向用户展示。

不能让自然语言经过一个不可见的 LLM 转换后直接生效。

2. 将策略生成和策略执行分离

LLM 可以充当策略编译器，帮助识别“公司文件”“外部网站”“高风险操作”等语义。

但策略生成后，应交给独立的 Policy Engine 执行。

一个较合理的链路是：

用户意图
  ↓
策略编译器
  ↓
结构化策略
  ↓
确定性策略引擎
  ↓
工具运行时

主 Agent 只能提交动作请求，不能自行修改执行结果。

3. 权限执行点必须位于工具调用之前

权限控制不能只依赖系统提示词。

正确的位置应当是在 Tool Runtime 前设置强制执行点：

Agent Planner
  ↓
Action Proposal
  ↓
Policy Enforcement Point
  ↓
Tool Runtime

无论动作来自主 Agent、子 Agent、MCP 工具还是浏览器自动化，都应经过统一授权判断。

沙箱只能限制动作造成的影响范围，并不能自动判断动作是否经过用户授权。两者需要结合，而不是互相替代。

4. 权限必须包含作用域

“允许使用 Gmail”不是一条完整权限。

一项授权至少应明确：

• 主体：哪个 Agent 或子 Agent
• 动作：读取、创建、修改还是发送
• 对象：哪个账户、目录或文件
• 环境：本地、云端还是远程浏览器
• 目的：服务于哪个任务
• 时间：持续多久
• 次数：允许一次还是多次
• 传播：能否传给子 Agent

例如：

允许当前 Agent 在未来 10 分钟内读取报销邮箱中的邮件正文，仅用于生成本次报销汇总，不允许读取附件，不允许向外部服务发送内容。

这比“允许访问邮箱”更接近真正的最小权限。

5. 一次授权不能自动扩展为长期权限

系统可以根据历史行为向用户推荐策略：

你已连续三次允许执行单元测试，是否在当前项目中始终允许？

但在用户确认前，系统不应自行扩大范围。

权限学习应该生成建议，而不是静默修改授权边界。

6. 撤销能力必须与授予能力对称

权限系统不能只提供“允许”。

还需要统一管理：

• OAuth Token
• MCP 会话
• 文件系统句柄
• 浏览器登录态
• API Key
• 临时凭据
• 子 Agent 已获得的能力令牌

用户点击撤销后，权限必须真正到达运行层，而不是只修改界面状态。

7. 审计日志要记录“为什么允许”

普通日志通常只会记录：

gmail.send: allowed

真正有价值的权限日志应当记录：

Decision: allowed Policy: corporate-email-v3 Reason: recipient belongs to company domain User approval: not required LLM involved: policy compilation only Scope: current session

这样在发生越权事件后，才能判断问题究竟来自：

• 用户配置错误
• LLM 编译错误
• 策略引擎缺陷
• 工具绕过
• 作用域扩大
• 权限未正确撤销

这篇论文还留下了哪些问题

这篇论文是一项分类和综述研究，不是统一安全评测。

它能够说明各类系统如何表达、推导和执行权限，却不能直接判断哪一个系统的攻击成功率最低，或者哪一种交互的用户体验最好。

论文对商业产品的观察也具有明显时效性。测试集中在 2026 年 5 月下旬至 6 月初，商业系统可能快速更新；同时，由于系统闭源，作者无法确认界面背后的真实实现。

另外，论文把用户实时确认归为确定性执行，技术上说得通，但这不代表用户决策本身可靠。

用户可能：

• 看不懂参数
• 不理解后续影响
• 被误导性界面影响
• 因确认次数过多而直接点击允许

因此，未来还需要真正的用户研究，评估不同权限界面对理解能力、授权准确率和权限疲劳的影响。

权限必须从交互功能变成安全基础设施

很多 Agent 产品已经拥有确认弹窗。

但确认弹窗只能回答当前这一步是否执行，无法单独解决权限从哪里来、如何保存、如何解释、如何执行以及何时失效的问题。

这篇论文最大的价值，是把 Agent 权限管理拆成五个连续层次：

威胁模型、用户权限界面、内部权限表示、权限推导和运行时执行。

在此基础上，系统还要同时追求四个目标：

低用户负担、策略形式化、确定性执行和持续用户控制。

目前，21 个研究方案中没有任何一个同时实现前三个目标；商业 Agent 则经常在频繁弹窗和不透明的自动审查之间摇摆。

真正成熟的 Agent 权限体系，不应该让用户审批所有动作，也不应该让大模型在后台替用户猜测权限。

更合理的方向是：

让自然语言降低表达门槛，让形式化策略固定授权边界，让确定性组件负责运行时执行，再把查看、修改和撤销权持续交还给用户。

只有这条链路闭合，权限管理才会从一个产品交互功能，变成 Agent 系统真正的安全基础设施。