IntentCap 提出按任务意图限定 LLM Agent 权限的机制

各上下文源进入同一规划通道且地位相同，任一来源都能填写任意决策字段。

• 出现场景：智能体执行代码、改文件、调用服务并委托子任务；上下文含用户请求、工具结果、文档、shell输出、Skill与MCP指令和记忆。作者认为输入有用正因它会影响后续行为，对抗注入或意外扩范围都可能让任一输入影响任一动作。
• 现有不足：作者称现有防御约束操作与信息流，包括分离控制与不可信数据、工具权限、执行隔离、信息流和OS策略。允许列表能拦被禁域名，不能表达某文档来源不得填写repository字段；无对手时，把文档文本拼成一个输出串，规划器也可能把表头当成仓库名。
• 核心观察：作者认为没有单一来源能定义完整能力，也没有程序员在编译期声明这种组合。用户请求给目标与授权目的地但不给步骤；工作流给候选步骤但不给具体目标；工具schema声明参数但不给目标；工具输出给值，却不指定应填哪个字段。
• 本文做法：IntentCap把能力限定在当前任务意图，而不是沙箱或会话寿命。四源按字段所有权合成短期lease，只收窄用户已授权的权限；LLM只提议，确定性checker在副作用前提交前裁决。
• 威胁模型：
  • 对手控制：运行时内容、文档、工具输出、网页数据、委托消息，并可在Skill或MCP文本中植入指令。
  • 对手不控制：用户的结构化选择与执行层。
  • 不受信任部分：planner与compiler可被任意操纵，只提议、不裁决。
  • TCB：intent issuer、source labeler、确定性checker及hooks、MCP gateway、OS enforcer。受害系统是会提交副作用的LLM智能体。

论文没有独立的相关工作专节，讨论在引言和Limitations。

注入与控制数据分离

• 间接提示注入：Greshake等（2023）被用作例子：文档中的隐藏文本可能改写issue的仓库字段。
• 控制与数据分离：Debenedetti等（2025）与Willison（2023）把控制与不可信数据分开。作者将其归入约束操作与信息流的防御，并在Limitations中对照：IntentCap把每个决策字段绑定到唯一授权来源。

工具权限、隔离与信息流

• 操作约束：Progent（Shi等，2025）执行工具权限；IsolateGPT（Wu等，2025）隔离执行。作者把二者归为限制操作的防御，未逐项比较实现。
• 信息流：Fides（Costa等，2025）用信息流控制保护智能体。正文称其在规划器层做污点跟踪；IntentCap在工具边界校验参数字段是否来自所有者来源。

编译期能力与OS策略

• 传统能力：作者称，与Capsicum（Watson等，2010）的文件描述符或seccomp过滤器不同，智能体能力不能在编译期声明。同句引用Denning（1976）、Dennis与Van Horn（1966）、Hardy（1988）、Saltzer与Schroeder（1975）。
• OS执行：ActPlane（Zheng等，2026）做可编程的OS级策略执行。已接受的lease编译成其文件、exec与网络策略，经eBPF执行。

基准与实验对照

• 基准：回放来自AgentDojo（Debenedetti等，2024）、MCPTox（Wang等，2025）、InjecAgent（Zhan等，2024）和tau2-bench（Barres等，2025）。
• 基线：Section 3的对照是四源并成generic trusted context、成对坍缩、无字段所有权的policy DSL、把状态拆到独立guard，以及RQ4未具名的non-IntentCap baseline。

作者把本文定位为任务范围内的多源权限合成，焦点是四个上下文源上每个能力字段由谁填写。对照还包括约束信息流、工具、OS与软件包的防御，引用为Fides、SkillGuard（Pan等，2026）、ActPlane和Zheng等（2025）。

IntentCap在运行时从四类来源合成当前任务的能力lease：每源只填自己的字段，lease只收窄用户已授权的权限。不受信任的LLM只提议，确定性checker在副作用提交前裁决。

四源与字段所有权

• 字段：lease中的具名槽，例如destination、approval scope、tool name、argument value，值必须来自恰好一个来源。
• 用户意图：目标、被选对象、授权目的地与批准。
• 工作流指令：系统策略、Skill过程或手册，提供过程范围，不能扩大approval scope。
• 工具schema：MCP定义、注册项或命令描述，提供可调用接口与凭证范围，不能授权目的地。运行时环境（工具结果、文件状态、脚本输出）只提供观测值，不能提供过程权限。

作者给出的理由是：单一来源都不够定义完整能力，也没有程序员做静态声明。这些规则构成信息流策略，规定哪条信息可以从哪个来源流入lease的哪个字段。

标注、签发与提议

Figure 1的文字标出LLM-assisted compiler、intent issuer、source labeler、deterministic checker、MCP gateway、enforcement hooks、OS-level enforcer。图注称不受信任的compiler提议lease，TCB中的checker做决定。作者称TCB在图中以虚线框标出。

• source labeler：按位置分类。用户消息始终是user intent，工具响应始终是runtime environment，Skill与MCP元数据在加载时标注。来源含糊的输入，例如用户粘贴的文档，原型不授予authority fields。OS层把标注映射为进程隔离与IPC通道标记，来源溯到产生它的进程。
• intent issuer：从用户消息的结构化字段提取最大权限，包括被选文件、指名目的地和显式批准。
• compiler：结合结构化意图与当前schema发出候选lease。可以少选目的地或缩短budget，不能新增目的地、提高approval scope，或授予用户意图未覆盖的字段。

lease与单调收窄

lease把字段贡献绑定到特定operation、object、arguments、budget、expiry与delegation depth；范围是当前任务意图，用后消耗，不能自行放宽。每次委托再衰减，子任务只得到比父任务更窄的能力。checker在一次状态转移中原子校验全部字段，副作用才提交。文中的issue lease示例是首次使用后过期。

PDF任务中，用户意图提供两个被选文件和仓库名，Skill提供extract-save-report过程，issue工具schema提供可调用接口，运行时结果提供表值。compiler为create_issue提议lease：repository字段复制用户给出的仓库名，并带指向user-intent span的witness；issue body是由文档合成的数据字段；budget为一个issue。没有对应user-intent span见证的仓库候选，在调用执行前被拒绝。

裁决与两层执行

设计要求四点：每个决策字段恰好由一个来源拥有；lease只能收窄用户已授权的权限；LLM留在TCB之外，接受或拒绝全由确定性checker做出；每次接受或拒绝都记录来源链，以便审计。

统一接口是check_and_consume，参数为事件、lease、proofs与状态，结果为allow或deny。每个适配器在副作用提交前必须调用它。checker还在上下文放置或委托交接提交前执行。论文未给出proofs的一般形式；示例中的见证是指向user-intent span的witness。

• 工具层：边界适配器拦截MCP调用，执行前校验每个参数字段是否来自其所有者来源。
• OS层：已接受的lease编译为ActPlane的文件、exec与网络策略，经eBPF执行。

论文未写迭代次数、采样设置、具体LLM名称或数值阈值。

实验设置

• 被测模型：论文未说明被测或被攻击的LLM名称。评测是事件回放和策略比对，不是对某个命名模型的在线生成。
• 安全回放：RQ1从AgentDojo、MCPTox、InjecAgent、tau2-bench回放3,746个security-sensitive events。
• 效用数据：tau2-style proxy的3,813个benign reference actions，以及2,556项applicable ground-truth checks。
• 应拒绝集：RQ2使用checker应拒绝的3,823个事件，另有7个crafted multi-step workflows。论文未说明3,746与3,823是否同一集合。
• 其余样本：RQ3在五个执行点上做38次检查。RQ4用来自InjecAgent、MCPTox与tau2的24个手标lease，以及144个scored policy entries。
• 对照与未报告项：四源并成generic trusted context；成对坍缩tool→agent、env→agent、env→tool；无字段所有权的policy DSL；独立guard；未具名的non-IntentCap baseline。指标为unsafe accepts、false accepts、良性动作覆盖、ground-truth checks、unsafe executions or placements、checker/monitor mismatches、是否匹配labeled scope、over-grant。论文未报告重复次数、LLM评审或人工一致性。

主结果

条件	结果	出处
IntentCap，四基准回放	0 unsafe accepts / 3,746	Section 3 RQ1
tau2-style proxy良性动作	覆盖3,813 / 3,813	Section 3 RQ1
适用ground-truth checks	通过2,554 / 2,556	Section 3 RQ1

• 作者称挡住了所测违规，且不拒绝良性动作；该说法对应的是良性参考动作的覆盖。两项检查未通过，论文未解释原因。
• 效用只报告在tau2-style proxy上，论文未在另外三个基准上给出同样的覆盖数字。

四源划分是否必要

• 测了什么：把四源坍成一个generic trusted context，以及成对坍缩、只检查谓词而不做字段所有权的policy DSL、把状态拆到独立guard。
• 结果：3,823个应拒绝事件中误接受3,593次，作者称94%。成对坍缩的false accepts：tool→agent为1,928（作者称50%），env→agent为1,663（43%），env→tool为1,662（43%）。7个手工多步流程上，policy DSL误接受7/7，独立guard误接受5/7。
• 作者解读：作者用这些结果追问四源划分是安全要求还是命名选择，并称成对坍缩打开的是不同的洞。论文未解释guard放过的2个流程与DSL的差别。

同一提交接口能否超出工具调用

• 测了什么：check_and_consume是否覆盖本地环境副作用、上下文放置、Skill指令槽、委托交接和OS monitor回放后端。
• 结果：38次检查中允许17次已授权效果，阻断21次违规；unsafe executions or placements为0，checker与monitor不一致为0。
• 作者解读：作者称同一提交API能用到工具调用之外的这些边界。论文未报告38次在五个执行点上如何分配。

lease是否可审计

• 测了什么：24个手标lease上，策略是否匹配标注范围；non-IntentCap baseline在144个scored policy entries上是否过度授权。
• 结果：IntentCap的策略全部匹配标注范围。作者称每个non-IntentCap baseline都至少在其中一部分条目上over-grant。
• 作者解读：作者把lease视为可审计的权限对象。论文未列出这些baseline的名称，也未给出各自over-grant的条数。

其他消融与分析

• 成对坍缩与7个工作流的数字已列于RQ2，论文没有另做参数扫描。
• 论文未报告执行延迟、查询次数或重复次数。
• RQ1的2,556项检查中有2项未通过，论文未给原因。

作者指出的局限与后续方向

均出自Section 3的Limitations and future work。

• copy-witness偏保守：跨源合成被限制在数据字段，或用户授权的选择器。
• meet-based composition：作者列为后续工作。
• 端到端攻击成功率：作者列为后续工作。
• 执行延迟：作者列为后续工作。
• 自适应攻击：针对标注和lease生成的自适应攻击，作者列为后续工作。

实验覆盖范围

• 安全回放为AgentDojo、MCPTox、InjecAgent、tau2-bench的3,746个security-sensitive events（Section 3 RQ1）。
• 效用为tau2-style proxy的3,813个良性参考动作和2,556项适用检查（RQ1）。
• 源坍缩用3,823个应拒绝事件；另有7个手工多步工作流，对照包括四源合并、三种成对坍缩、policy DSL与独立guard（RQ2）。
• 执行点为本地环境副作用、上下文放置、Skill指令槽、委托交接和OS monitor回放后端，共38次检查（RQ3）。
• 审计样本为24个手标lease与144个scored policy entries（RQ4）。论文未报告被测LLM、重复次数、端到端攻击成功率与执行延迟的测量值。

IntentCap是把智能体能力绑到当前任务意图、并按上下文来源划分字段所有权的权限机制。

• 问题：用户请求、工作流指令、工具schema和运行时输出进入同一规划通道。作者认为因此任一来源都能填写目的地或扩大权限；允许列表挡不住某来源不得填某字段。
• 方法：四源各填各的字段。lease绑定操作、对象、参数、budget、过期与委托深度，且只收窄用户的结构化授权。compiler不受信任；intent issuer、source labeler与确定性checker在副作用前裁决，工具适配器与ActPlane/eBPF执行。
• 安全回放：作者报告，AgentDojo、MCPTox、InjecAgent、tau2-bench的3,746个安全敏感事件上，unsafe accepts为0。
• 效用：作者报告，tau2-style proxy覆盖全部3,813个良性参考动作，2,556项适用检查通过2,554项。
• 源边界与审计：四源并成单一可信上下文时，3,823个应拒绝事件中误接受3,593次（作者称94%）。38次跨执行点检查中阻断21次违规、允许17次授权效果，不一致为0。24个手标lease的策略均匹配标注范围。
• 作者结论：作者认为能力应随任务意图而不是沙箱或会话生命周期来限定，且没有单一来源能定义完整能力。作者称所测违规被挡住、良性动作未被拒绝，每个源边界独立必要，checker能跨工具、执行、放置与委托边界泛化。端到端攻击成功率等被列为后续工作。