💻 computer science

PAuth - Precise Task-Scoped Authorization For Agents

该论文针对现有授权模型导致 AI 代理权限过大的问题，提出了名为 PAuth 的精确任务范围授权机制，通过"NL 切片”和“信封”技术实现仅授权任务执行所需的具体操作，并在 AgentDojo 框架中验证了其在保障任务成功执行的同时能有效拦截越权攻击。

原作者： Reshabh K Sharma, Linxi Jiang, Zhiqiang Lin, Shuo Chen

发布于 2026-03-19

📖 1 分钟阅读☕ 轻松阅读

CC BY 4.0

原作者： Reshabh K Sharma, Linxi Jiang, Zhiqiang Lin, Shuo Chen

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

这篇论文提出了一种名为 PAuth（精确任务范围授权）的新安全机制，旨在解决 AI 智能体（AI Agents）在帮人类处理网络任务时的“权限过大”问题。

为了让你轻松理解，我们可以把整个场景想象成**“雇佣一位全能管家”**的故事。

1. 现状：旧模式的“大钥匙”问题

场景：你想让 AI 管家帮你处理一件具体的事：“从我的银行账户转 100 美元给 Bob"。

现在的做法（OAuth 模式）：
就像你为了完成这件小事，不得不把整栋房子的所有钥匙（包括保险柜、地下室、甚至邻居家的备用钥匙）都交给管家。

后果：管家虽然能帮你转那 100 美元，但他同时也拥有了“随意转走 100 万”、“把房子卖了”或者“给陌生人转账”的权力。
风险：如果管家被黑客控制（比如被网页上的恶意代码“洗脑”了），他可能会利用这些多余的钥匙做坏事，而你根本不知道。

2. 新方案：PAuth 的“任务说明书”

PAuth 的核心思想：
不再给管家一把通用的钥匙，而是给他一张精确到每一个动作的“任务说明书”。

隐含授权：只要你把任务告诉管家，系统就默认他只能做完成这个任务必须做的动作。
精确限制：如果任务说“转 100 美元给 Bob"，系统就只允许他执行“转 100 美元给 Bob"这一件事。他不能转 101 美元，也不能转给 Alice。

3. 两大核心发明：如何确保管家不“乱来”？

为了让服务器（比如银行、购物网站）相信管家真的在执行你的任务，而不是在偷偷干坏事，PAuth 发明了两个神奇的工具：

A. “任务切片” (NL Slice) —— 给每个服务器发的“剧本”

想象一下，你的任务涉及两个地方：Citi 银行（查余额）和 Chase 银行（转账）。

传统做法：Citi 银行只看到“查余额”这个请求，它不知道你要拿这个余额去干嘛。
PAuth 做法：
- 系统会根据你的任务，为 Citi 银行生成一个**“剧本片段”**：“请查询用户余额，如果超过 1000 美元，则允许后续操作。”
- 为 Chase 银行生成另一个**“剧本片段”**：“请接收转账，但金额必须是 Citi 查到的余额的四分之一，且收款人必须是 Citi 指定的账户。”
- 效果：如果管家试图转给陌生人，或者转的金额不对，Chase 银行一看剧本：“不对！这不在剧本里！”于是直接拒绝。

B. “信封” (Envelope) —— 数据的“防伪身份证”

这是最精彩的部分。当管家从 Citi 银行拿到"1200 美元”这个余额时，他不能直接把这个数字告诉 Chase 银行，因为管家可能会撒谎（比如改成 10000 美元）。

PAuth 做法：
- Citi 银行在返回"1200 美元”时，会把它装进一个**带数字签名的“信封”**里。
- 信封里写着：“这是 1200 美元，它是通过‘查询 Citi 账户’这个动作算出来的。”
- 当管家拿着这个信封去 Chase 银行转账时，Chase 银行会拆开信封检查：
  1. 数字对不对？（是不是 1200？）
  2. 来源对不对？（是不是真的来自 Citi 的查询？）
  3. 计算对不对？（剧本说转四分之一，1200 的四分之一是 300。如果管家想转 301，Chase 会发现计算对不上，拒绝执行。）
比喻：这就像管家拿着一个**“官方认证的快递单”**去取货。如果快递单上的数字被涂改过，或者来源不对，收货方（服务器）一眼就能识破。

4. 实验结果：真的管用吗？

研究人员在一个叫 AgentDojo 的测试场里，模拟了各种情况：

正常任务：管家顺利完成了所有任务，不需要用户反复确认，因为一切都在“剧本”和“信封”的允许范围内。
恶意攻击：黑客试图通过网页注入指令，让管家多转钱、转错人。
- 结果：PAuth 系统像一位铁面无私的保安，立刻发现管家拿出的“信封”和“剧本”对不上，直接拦截了所有非法操作，并提示用户：“这个操作不在你的任务范围内，请确认。”
准确率：在 700 多次测试中，没有一次误报（把正常任务拦了），也没有一次漏报（让坏任务通过了）。

5. 总结：这对我们意味着什么？

PAuth 就像是给 AI 管家戴上了“紧箍咒”。

以前：你给管家一把万能钥匙，心里总担心他会不会乱翻东西。
现在：你给管家一本**“任务执行手册”，并给每个数据都贴上了“防伪标签”**。管家只能按手册办事，任何越界行为都会被系统自动识破。

这项技术让未来的 AI 助手在处理银行转账、购物、订票等敏感任务时，变得更加安全、可信。你不再需要担心 AI 被黑客控制后把你的积蓄转走，因为它根本没有“越权”的能力。

一句话概括：PAuth 让 AI 从“拥有无限权力的管家”变成了“严格遵循任务清单的办事员”，确保每一分钱、每一个操作都精准地符合你的真实意图。

PAuth：面向智能体（Agents）的精确任务范围隐式授权技术总结

1. 研究背景与问题定义 (Problem)

背景：
随着“智能体网络”（Agentic Web）的兴起，AI 智能体被期望能够通过自然语言（NL）与现有的 Web 服务交互，自动完成购物、旅行预订、表单填写等复杂任务。然而，现有的授权模型（主要是 OAuth 2.0）是为“操作员范围”（Operator-scoped）设计的，即授权给第三方客户端对某个操作符（如 transfer 转账工具）的广泛访问权限，而不是针对具体的操作实例（如“向 Bob 转账 100 美元”）。

核心问题：
在智能体场景下，这种授权模式存在严重缺陷：

过度授权（Overprivileged）： 为了完成一个具体任务（如转账 100 元），用户必须授予智能体该操作符的所有权限（如任意金额、任意接收人的转账权限）。这违反了最小权限原则。
缺乏细粒度控制： OAuth 的 Scope 绑定在操作符上，无法感知操作的具体参数（Operands）及其计算逻辑。
安全隐患： 如果智能体被提示注入攻击（Prompt Injection）或发生幻觉，它可能利用这些过度授权的权限执行恶意操作（如将 100 元改为 10000 元，或转给攻击者），而服务器无法区分这是用户意图还是恶意篡改。

目标：
提出一种精确任务范围隐式授权（Precise Task-Scoped Implicit Authorization, PAuth）模型。其核心目标是：一旦用户提交自然语言任务，只要智能体忠实执行该任务，服务器应隐式授权执行该任务所需的具体操作，同时严格阻止任何偏离任务意图的操作，且任务结束后不留任何残留权限。

2. 核心方法论 (Methodology)

PAuth 通过两个关键创新机制来实现上述目标：**NL Slice（自然语言切片）**和 Envelope（信封）。

2.1 NL Slice (自然语言切片)

定义： 给定用户的自然语言任务，每个服务器（Server）独立生成一个符号化的调用规范（Symbolic Specification），即“切片”。
形式： 切片不是可执行的命令代码，而是对期望接收的调用的描述。它包含：
- 操作符（Operator）： 预期的工具名称。
- 符号操作数（Symbolic Operands）： 参数值的符号化表达（例如 Citi.getBalance(user)/4），而非具体的数值。
- 断言条件（Assert Clauses）： 调用该操作符必须满足的前置条件（例如 balance > 1000）。
生成过程： 服务器端的 LLM 将用户的自然语言任务转换为受限的指令式代码（Imperative Code），然后从中提取出针对该服务器特定调用的切片。
作用： 切片作为精确的授权策略。只有当实际调用与切片完全一致（包括操作符、参数值的计算逻辑和条件）时，才被视为隐式授权。

2.2 Envelope (信封)

定义： 一种数据结构，用于将具体数值（Concrete Value）与其符号来源（Symbolic Provenance）绑定。
结构： <具体值，符号表达式>。例如：<300, Citi.getBalance("Me")/4>。
签名机制： 信封由产生该值的服务器（权威方）进行签名，防止智能体伪造或篡改。
工作流程：
1. 当服务器 A 返回数据时，它返回一个签名的信封。
2. 智能体在调用服务器 B 时，必须携带这些信封作为参数。
3. 服务器 B 在收到调用时，验证信封的签名，并根据切片中的符号表达式，将具体数值“解包”并验证其计算逻辑是否符合任务定义。
作用： 确保服务器能够验证操作数是否源自合法的、符合任务逻辑的计算过程，而非智能体凭空捏造或受攻击篡改的常量。

2.3 协议流程

任务提交： 用户签署任务文本发送给智能体。
切片生成： 涉及的所有服务器根据任务文本独立生成各自的 NL Slice。
执行与验证：
- 智能体发起调用，携带 Envelope。
- 接收服务器检查调用是否符合其 Slice（操作符匹配、符号表达式计算结果匹配、断言条件满足）。
- 如果匹配，隐式授权通过；如果不匹配（如金额被篡改），则拒绝并触发显式用户确认。

3. 关键贡献 (Key Contributions)

提出了 PAuth 授权模型： 从根本上改变了 Web 授权范式，从“操作员范围”转向“任务范围”，实现了最小权限原则在智能体场景下的落地。
设计了 NL Slice 与 Envelope 机制：
- NL Slice 使得服务器能够基于任务语义生成精确的授权策略，而非依赖静态的 Scope。
- Envelope 解决了跨服务数据依赖的验证问题，确保了数据流的可信性和完整性，防止中间人攻击或智能体幻觉导致的参数篡改。
实现了原型系统并进行了全面评估：
- 在 AgentDojo（智能体安全评估框架）中实现了 PAuth 原型。
- 构建了多主机环境下的实现，模拟真实的 Web 部署（通过 TLS 和签名信封交换）。
- 扩展了测试套件，包含 100 个正常任务和 634 个强制注入攻击任务。

4. 实验结果 (Results)

研究团队在 AgentDojo 框架下对 PAuth 进行了严格评估，涵盖银行、Slack、工作区、旅行和购物等多个场景。

零误报（False Positives, FP）： 在所有 100 个良性任务测试中，PAuth 均成功执行了任务，未出现任何因授权过严导致的任务失败。
零漏报（False Negatives, FN）： 在所有 634 个强制注入攻击测试中（即攻击者试图诱导智能体执行非预期操作，如修改转账金额或接收人），PAuth 均成功识别并拦截了违规调用，未发生任何安全绕过。
Token 成本分析：
- 主要成本在于 LLM 生成指令式代码和切片的过程。
- 测试显示，使用 GPT-4.1 等模型，每个任务的平均 Token 成本在 $0.002 到$ 0.038 之间。
- 尽管每个服务器都需要独立运行切片生成，但考虑到安全性收益，该成本是可接受的，且随着 LLM 效率提升有望进一步降低。

5. 意义与展望 (Significance)

学术与工业意义：

解决智能体安全的核心痛点： 为 AI 智能体处理敏感任务（如金融交易）提供了一种可行的、基于语义的授权解决方案，填补了现有 OAuth 模型在自动化场景下的空白。
推动“隐式授权”落地： 证明了无需用户频繁进行二次确认（如 OAuth 弹窗），仅凭任务描述即可实现精确授权，提升了用户体验和自动化效率。
防御提示注入攻击： 通过验证操作数的符号来源，PAuth 能够有效防御间接提示注入（Indirect Prompt Injection）导致的恶意操作。

局限性与未来工作：

自然语言歧义性： 当前假设用户任务是无歧义的。未来需要结合意图澄清（Intent Clarification）技术来处理复杂的对话上下文。
部署路径： 目前是一个长期愿景。未来研究需探索如何在现有的 OAuth 生态中渐进式部署 PAuth（例如通过代理服务器处理中等敏感度的任务）。
多轮对话集成： 需要进一步研究如何在长对话中动态维护和更新任务切片，以支持更自然的交互。

总结：
PAuth 通过引入“任务切片”和“数据信封”机制，成功地将授权粒度从粗糙的“工具级别”细化到了精确的“任务实例级别”，为构建安全、可信的 AI 智能体网络奠定了重要的理论基础和技术原型。