CapScope: A Capability-Scoped Harness for Prompt-Injection-Resistant Coding Agents 精读

论文链接：Authority Is Not a String: A Capability-Scoped Harness for Prompt-Injection-Resistant Coding Agents 发表信息：已录用 Proceedings of the 2nd ACM SIGPLAN Workshop on Language Models and Programming Languages（LMPL ‘26），2026年10月，Oakland，DOI: 10.1145/3843750.3843843 发表时间：2026年9月（arXiv） 机构：Peking University 高可信软件技术教育部重点实验室（Key Lab of HCST (PKU), MoE）—— 高校团队，程序语言与软件工程传统强项 领域标签：cs.SE / Coding Agents / Prompt Injection / Capability Security / Least Authority

一、论文背景

编码 Agent 要干活就得有系统级工具：读文件、执行命令、改源码。当前主流 harness 里，这些工具携带的是环境权威（ambient authority）——只要"说得出名字"就能操作：Agent 提到某个文件路径就能读它，写出某条命令就能执行它。这是 Unix shell 传统下的默认权威模型。

**间接提示注入（indirect prompt injection）**精确利用了这一点。攻击者不需要碰 Agent 本身，只需要在 Agent 会读到的内容里埋指令：仓库里的一个文件、一个被投毒的测试夹具、一条工具输出——Agent 读了，指令就进了它的上下文，然后它"自愿地"执行了用户从未请求的动作：外传凭据、植入后门、修改无关代码。这类攻击的阴险之处在于：Agent 是"共犯"而非"受害者"——所有操作都是它自己的合法工具调用。

现有防御分两派，都有结构性弱点：

• 模型侧防御：让模型识别并忽略恶意指令（提示词声明、输入过滤、训练）。弱点：注入文本与正常内容没有可靠的表面区分，识别本质上是不可靠的分类问题；
• harness 侧粗防线：允许列表（allowlist）或全局策略。弱点：攻击所需的操作（写文件、跑命令）往往就是任务所需的操作——一个任务级的允许列表挡不住"用任务需要的权限干任务外的事"。

核心矛盾：权威是按"资源名"（字符串）授予的，而安全边界需要按"主体+能力"划分。同一个"写文件"权限，orchestrator 该有、runner 子 Agent 不该有——但在环境权威模型下它们共享同一套工具面。

二、论文定位和关联工作

脉络一：能力安全（Capability Security）经典。 从 Dennis & Van Horn 的能力机到 object-capability 系统（E、Cajeta），最小权威原则有五十年积累：权威应该是不可伪造的引用，持有即可用、无持有即不可用，且可被细分与收窄（attenuation）。本文把这套路数第一次系统搬进 LLM Agent harness。

脉络二：提示注入的模型侧防御。 指令层级（system vs user vs tool 的信任分级）、 Spotlighting（标记不可信内容）、训练式抵抗。本文立场鲜明：不与"模型能否识别恶意文本"缠斗，把安全性从模型认知问题改写为权限系统问题。

脉络三：harness 级防御。 工具沙箱、权限模式（如 Claude Code 的 permission prompt）已有工程实践，但它们是会话级/任务级的粗粒度策略；本文做到逐 sub-agent、逐能力、逐调用的细粒度。

定位结论：本文是 object-capability 理论在 Agent harness 上的落地实现，附形式语义与实证。

三、问题定义

具体问题：在多 sub-agent 的编码工作流中，如何使间接注入无法产生实际效果，同时不显著损害任务完成。

核心洞察（抽象）：注入攻击的杀伤链有两个环节——让 Agent 请求恶意动作（提示注入可以做到，且几乎不可防御），让系统执行该动作（这是 harness 可以完全掌控的）。CapScope 的抽象就是切断第二环：请求≠执行。执行与否取决于发起调用的主体是否持有对应能力，而能力是类型化的、作用域化的、存于模型上下文之外的——注入文本无法自授予权威。

形式化：权威模型四元组操作——

• Minting（铸造）：所有能力源于可信输入（用户请求+任务描述）导出的任务级权威上限，初始铸造给 orchestrator；
• Derivation（派生/收窄）：权限下放给 sub-agent 时只能收窄不能放大（路径范围、操作类型、效果类别都可裁剪）；
• Invocation（调用检查）：每次工具调用由 hook 依据发起主体当前持有的能力集做检查，无能力则拒绝；
• 效果类型系统：读/写/执行/网络等效果类别 + 作用域谓词（路径前缀等）。

这个抽象为何必要：它把安全性质从"模型不傻"（经验性质）换成"无能力则无效果"（机械性质）——前者只能概率性缓解，后者可以结构性排除。

四、问题解法

CapScope 实现在 Pi 编码 Agent 上，四个组件：

1. 能力结构：类型化的能力对象——效果类型（读/写/执行/网络…）+ 作用域谓词（如 src/**）+ 主体身份。存在模型上下文之外（hook 层的内存/磁盘），注入文本摸不到它；
2. 初始铸造：任务启动时从可信输入解析任务需求，导出权威上限（如"本任务允许写 src/、读全仓、执行测试命令"），铸造给 orchestrator；
3. 派生与转移：orchestrator 给 runner 子 Agent 下发"仅跑测试"能力、给 patcher 下发"仅写 src/“能力——各能力集互不重叠；
4. 逐主体调度检查：hook 拦截每次工具调用，核对发起主体的能力集；模型可以请求任何动作，但请求落到没持有的能力上就直接拒绝。

一个贯穿论文的例子：被投毒的测试夹具诱导 runner 去"修改测试文件以绕过失败断言”（经典后门）。在 ambient 权威下 runner 有写权限，后门落地；在全局任务策略下"写文件"在白名单内，照样落地（这正是 33/75 的来源）；在 CapScope 下 runner 只持有"执行测试"能力，无"写测试文件"能力——模型被注入了，动作被拒了。

五、评估指标与实验证据

实验设计：修复工作流（orchestrator 委派 runner 跑测试 + patcher 改源码），五个 Python 修复任务 × 五个注入面（AGENTS.md、测试夹具、工具输出、README、issue 文本）× 四种授权条件 × 三次试验 = 300 runs。

四种授权条件：B0 ambient 权威（现状）；B1 静态全局策略（通用白名单）；B2 任务级全局策略（本任务的 allowlist，所有主体共享）；C CapScope。

核心结果：

读表的三个要点：

1. B1≈B0（46 vs 47）：通用白名单几乎不比没有强——因为恶意动作（写仓库文件、跑命令）都是普通操作，通用白名单从不点名它们。这是对"加个 allowlist 就安全了"直觉的有力反驳。
2. B2 的残余 33/75：任务级白名单砍掉了任务外的操作，但"任务需要的权限"对所有主体开放——注入只需借用任意主体的任务内权限。共享权限是 B2 的死穴，正是 C 的设计靶点。
3. C 的 3/75 与 68/75：残余 3 例全部经由 AGENTS.md（任务指令本身的污染面，属可信输入被污染的极端情形）；任务完成 68/75 与最强基线持平或仅差 4 例。决策日志进一步显示：CapScope 下模型在 34/75 的运行里提出了注入动作，但只有 3 次调用被放行——“模型被骗"与"系统受害"被成功解耦。

证明力评估：注入面×授权条件的受控网格、三次重复、任务完成度与安全性的联合度量（防止"安全靠瘫痪换”），证据形态完整。局限如实报告：7 例任务失败中 2 例源于能力预检漏铸造（工程成熟度问题），残余注入面（AGENTS.md）指向"可信输入验证"这一正交课题。

六、效果优势的根源解释

ambient 权威的根本缺陷：权威绑定在"名字"上——能说出资源名即可操作。注入攻击把恶意指令放进 Agent 的上下文后，Agent 当然说得出资源名（它是全知的全能执行者），于是表达能力=操作能力，两者之间没有任何摩擦。B1/B2 的白名单没有改变这个绑定结构，只是把可用名字集合缩小——B2 的 33/75 证明缩小集合仍有巨大攻击面，因为任务所需操作本身就足够危险。

CapScope 的机制改变与因果链：

1. 权威从"名字"改为"主体持有的不可伪造能力" → 表达与执行解耦。模型被注入后依然可以"表达"恶意请求（34/75 次提出），但执行需要主体持有能力——注入文本无法铸造能力（能力存于上下文之外），派生链又保证每个 sub-agent 只拿到最小集合。机制变化：攻击的必要条件从"骗过模型"升级为"持有能力"，而后者是注入通道无法触及的。
2. 逐主体隔离 → 任务内权限不再共享 → B2 的共享死穴被填。同样的"写文件"操作，patcher 有能力、runner 没有；注入面打在 runner 上就无处着落。对比 B2（所有主体共享一份 allowlist），这是从"权限对任务收敛"到"权限对主体收敛"的粒度跃迁——33→3 的降幅正是这个跃迁的效应量。
3. 最小权威+按需铸造 → 安全性不以瘫痪为代价。能力是从可信任务输入解析出的需求上限铸造的，任务需要什么就有什么，所以任务完成度不掉（68/75）。对比"用繁琐人工审批换安全"的路线，CapScope 的安全增益与任务增益不构成权衡。

反事实验证：把能力集重新共享（退回 B2）→ 33/75；把能力存进模型上下文（可被注入文本伪造）→ 防线崩塌（论文讨论的 TCB 边界）；去掉派生收窄 → 权限放大漏洞。三个反事实分别对应三个设计支柱。

七、必要知识反推

领域知识层：

• 编码 Agent 的多主体工作流形态（orchestrator/runner/patcher 的委派结构）；
• 提示注入的攻击面解剖（AGENTS.md、工具输出、仓库内容等入口）；
• Unix 权限模型与 ambient authority 的历史包袱——不懂"名字即可操作"的传统，就无法理解本文革命的对象。

方法论知识层：

• object-capability 理论（Dennis & Van Horn、E 语言一脉）：能力=不可伪造引用、attenuation 原则、confined granting；
• 类型系统与效果系统思想（效果类型+作用域谓词正是 FX 系统的翻版）；
• 安全实验设计（攻击面×防御条件的受控网格、安全性与功能性的联合度量）。

工程知识层：

• Agent hook 机制（调用拦截点）与上下文外存储；
• 可信输入解析与任务需求导出（权威上限的推导）；
• Pi Agent 框架的内部结构。

知识融合的关键节点：融合发生在"PL 安全的形式方法（类型系统、能力计算）“与”Agent 系统的工程现实（hook、sub-agent、上下文）“之间。PL 社区四十年的能力安全理论一直没有新的大规模应用载体，Agent 的出现恰好提供了"主体异构、权限需细分、调用可拦截"的完美宿主。作者的北大赛博过敏实验室背景让形式语义（minting/derivation/invocation 的操作语义）与 harness 工程（hook 实现）在同一个设计里闭环——老理论找到了新宿主，新系统找到了老智慧。

八、论文中可以提取的通用性灵感

1. 把"模型不被骗"改为"被骗也无权执行”。 核心思想：对不可完全信任的决策者，安全性不能依赖其判断力，要依赖其权限边界——请求与执行的解耦是结构性防御。 论文证据：34/75 次提出注入动作但仅 3 次执行成功。 推广场景：企业财务的多级审批（申请人≠批准人）；数据库的只读副本策略；未成年人模式的内容分级。

2. 粒度决定安全上限：从任务级到主体级。 核心思想：权限按"谁在用"切分而不只是按"干什么"切分，共享权限池是最小权威的反面。 论文证据：B2（任务级共享）33/75 vs C（主体级隔离）3/75。 推广场景：微服务的服务间凭证隔离； API 网关的按调用方配额与路由白名单；家庭权限系统的成员级设备授权。

3. 权威应当可铸造、可收窄、可核查。 核心思想：安全权威模型的三个动词——来源可信（minting）、只能收窄（derivation）、每次调用可查（invocation）——缺一不可。 论文证据：四组件架构与 300-run 实证。 推广场景：云 IAM 的 STS 临时凭证设计；开源供应链的签名与作用域声明；组织中的临时授权工单制度。

4. 安全与功能不构成权衡的前提是"按需铸造"。 核心思想：从可信需求推导权限上限，使收紧安全的同时功能不受损——摆脱"要么松要么瘫"的两难。 论文证据：注入生效 47→3 的同时任务完成 68/75 持平。 推广场景：零信任网络的最小授权自动化；Docker 的能力按需挂载；产品风控规则与转化率的联合优化。

5. 上下文之外的安全状态不可被提示词污染。 核心思想：安全关键状态（权限、身份、审计）必须存于模型上下文之外，因为上下文是攻击面本身。 论文证据：能力集存 hook 层，注入文本无法自授权。 推广场景：RAG 系统的权限过滤放在检索层而非提示词层；AI 助手的身份凭证走硬件安全区；审计日志的独立存储。

本文基于 arXiv:2609.08371 全文精读撰写。数据与结论均引自原文。