研究者提出上下文权限提升攻击，12 款 Agent 框架均受影响

真实 AI 智能体 Harness 在上下文组装设计上存在不透明与规范缺失问题，容易遭受上下文特权提升攻击（Context Privilege Escalation, CPE）。

• 问题场景与重要性：Codex、Claude Code 等智能体在软件开发和科学研究中广泛使用；智能体包含模型与 Harness，Harness 负责从异构来源组装上下文作为 LLM 输入，其安全性直接决定智能体系统的运行边界。
• 现有防御与研究不足：主流模型厂商虽然定义了消息角色特权分级（如 system 高于 user、tool 等），但以往针对间接提示注入的研究主要关注第三方工具返回的内容，作者称此前尚未有人对智能体 Harness 的上下文组装开展系统性安全分析。
• 核心观察：智能体会从多种记忆文件、技能路径、配置以及目录树或 Git 提交日志等环境信息中组装上下文，缺乏透明且一致的特权角色分配策略，导致低权限内容能够传播至高权限角色或更持久的作用域。
• 提出的方案与概念：论文提出了两类新型特权提升攻击——消息角色上下文特权提升（M-CPE）与跨作用域上下文特权提升（X-CPE），归纳了 16 种攻击向量，并开发了自动化分析工具 CORA。
• 威胁模型：
  • 攻击者目标：操纵受害智能体的推理、动作与任务输出，或获取智能体宿主机的控制权（如实现远程代码执行 RCE）。
  • 攻击者知识与分类：论文考虑两类攻击者，即控制外部内容的第三方内容攻击者（实施间接提示注入），以及发布恶意工具、skills 或 MCP 服务器的第三方组件攻击者；攻击者对宿主机无预先访问或控制权。
  • 攻击者能力：能控制被智能体处理的网络内容、检索结果、仓库 PR 或 issue，或提供带有特定文件结构、标记与指令的第三方组件。
  • 受害系统：运行良性、安全且更新及时的宿主 OS 上的智能体系统；用户、智能体厂商与 LLM 提供商均设定为非恶意。

智能体安全研究此前主要聚焦于间接提示注入威胁、基于指令层级的角色防御，以及智能体扩展组件规范。

间接提示注入与智能体攻击

• Greshake 等人（2023）以及 Debenedetti 等人（2024，AgentDojo）、Zhan 等人（2024，InjecAgent）与 Yi 等人（2023）——提出了间接提示注入威胁，并构建基准评估针对 LLM 与工具集成智能体的注入攻击。
• Shi 等人（2025）、Li 等人（2026）与 Chen 等人（2026）——研究了针对智能体工具选择的注入攻击，以及多工具生态和动态恶意技能带来的安全威胁。作者称以往针对间接提示注入的研究主要考虑来自特定内容源（特别是第三方工具或技能返回的内容）的恶意指令。

指令层级与消息特权体系

• Wallace 等人（2024）——提出指令层级训练方法，促使 LLM 优先遵循特权更高的指令以抵御间接注入。
• OpenAI（2025）、Anthropic（2026）与 Google（2025，2026，Shi 等人）——在 API 架构中定义了不同优先级的角色（如 system、developer、user、assistant、tool 等），用于隔离内置安全策略与不可信第三方输入。

智能体 Harness 架构与扩展生态

• Rajasekaran / Anthropic（2026）——讨论了面向长时间运行应用的智能体 Harness 设计概念。
• Model Context Protocol（2026）与 Agent Skills 规范（2026）——提出了模型上下文协议与基于 Markdown 的技能扩展机制；Murray（2024）、LianKee（2024）与 Meareg（2024）等安全审计指出了社区贡献工具中存在的命令注入与敏感信息泄露等安全缺陷。

基线与对照基准

• 基准数据集：论文未采用通用的端到端攻击基准，而是在评估 CORA 的静态分析精度时，以作者花费 40 人时手动分析 Codex 和 Gemini CLI 得到的上下文源清单作为人工基准（Ground-truth dataset）。

本文与既有工作的定位区别：作者称，以往研究从未对智能体 Harness 的上下文组装开展过系统性安全分析；本文系统分析了智能体 Harness 组装逻辑与角色分配机制中的设计缺陷，提出了消息角色与跨作用域两类特权提升攻击。

论文形式化建模了智能体上下文组装机制，提出了两类特权提升攻击（M-CPE 与 X-CPE）及 16 种攻击向量分类法，并研发了自动化漏洞挖掘与验证流水线 CORA（Context Risk Analyzer）。

上下文组装的形式化建模与特权提升定义

• 上下文源模型：每个上下文源表示为三元组 (s_k, \rho_k, \sigma_k)，其中 s_k 为文本内容，\rho_k 为角色优先级（如 r_0 > r_1 > r_2 > r_3 > r_4），\sigma_k 为作用域（\sigma_user > \sigma_project > \sigma_session）。
• 消息角色特权提升（M-CPE）：定义为 S_j = (s_j, ρ_j, σ_j), S_k = (s_k, ρ_k, σ_k) 满足 ρ_j < ρ_k ∩ s_j ≃ s_k，表示低特权角色的恶意内容传播至高特权角色的上下文源。
• 跨作用域特权提升（X-CPE）：定义为 S_j = (s_j, ρ_j, σ_j), S_k = (s_k, ρ_k, σ_k) 满足 σ_j < σ_k ∩ s_k ≃ s_j，表示仅在单次会话有效的低作用域内容被持久化存储至项目或用户级全局作用域。

上下文组装攻击向量分类体系

作者归纳了涵盖三大类的 16 种具体攻击向量（Table II）：

• 异构上下文源（A-1 至 A-7）：包括利用厂商专有记忆文件（A-1）、跨目录搜索记忆文件如 BFS 遍历（A-2）、运行时动态加载记忆文件（A-3）、特定技能加载路径（A-4）、运行时向上遍历动态发现技能（A-5）、加载目录树或 Git 提交日志等环境信息（A-6），以及嵌套递归导入记忆文件（A-7）。
• 上下文标记语法（B-1 与 B-2）：包括利用纯文本伪造闭合标签实现语法逃逸的标记插入（B-1），以及利用模型输出标签诱导智能体执行未授权文件读写的标记解释（B-2）。
• 上下文组装逻辑（C-1 至 C-7）：包括记忆文件覆盖优先级（C-1）、技能目录加载优先级（C-2）、技能重名冲突解决策略如后胜或先胜（C-3）、YOLO 模式下的配置文件自修改（C-4）、技能或文件中的内联命令执行（C-5）、写内存后立即重新加载上下文（C-6），以及沙箱未限制写入外部用户级记忆文件（C-7）。

CORA 静态分析与上下文源识别

• 四步静态分析工作流：CORA 使用后端智能体（GPT-5.5 配合中等推理工作量），依次进行：1. 探索仓库结构与入口；2. 定位初始化边界以区分会话源与持久源；3. 分析网络请求栈与 API 字段对应的角色并识别所有可能上下文源；4. 识别 Harness 使用的上下文 XML 标记。
• 精细化路径划分：对同一上下文源包含多个加载路径的情况（例如全局配置与项目配置），CORA 将其作为独立源处理以防遗漏。

运行时插桩与两轮攻击验证

• 插桩与环境构建：CORA 插桩智能体发送至 LLM 端点的请求函数，使用 EnvInterpreter 将 LLM 生成的 EnvSpec 实例化为 Docker 测试环境，并插入随机金丝雀（canary）值。
• 角色与作用域裁定：通过比对金丝雀在端点请求中的字段判定角色；通过在目标项目启动两次、不同目录启动一次的差异测试判定作用域（全出现为用户级，仅项目出现为项目级，仅单次出现为会话级）。
• 两轮执行验证 CPE 路径：在第一轮中加载低权限攻击指令，检查高权限源是否被修改以验证可达性，随后执行清理规范抹除原始注入；在第二轮以良性提示词重启智能体，检查高权限源指令是否生效并触发预期行为（如输出特定标记或运行 hello world）。

实验设置

• 被测模型：GPT-5.5、GPT-5.4 mini；针对 Claude Code 额外评估了 Claude-Sonnet-4.6 与 Claude-Opus-4.6；针对 Gemini CLI 额外评估了 Gemini-2.5-Flash 与 Gemini-2.5-Pro；部分 PoC 攻击使用了 DeepSeek-V4-Flash。
• 被测智能体 Harness：Codex、Claude Code、Gemini CLI、Qwen Code、Kimi CLI、Aider、OpenCode、Cline、Goose、Pi-mono、OpenClaw、Hermes Agent 共 12 个智能体 Harness（Table I）。
• 基准与对比基线：以研究人员投入 40 人时手动分析 Codex（30 个源）和 Gemini CLI（42 个源）建立的人工真值集（Ground-truth）作为准确率对照基线；基于 12 个智能体 Harness 生成了 1761 条唯一候选 CPE 路径。
• 评测指标：Verified Sources（经运行时验证的上下文源数）、Loaded（注入指令成功写入高权限源的路径数及比例）、Verified（进一步触发预期行为效果的路径数及比例）、Precision 与 Recall（上下文源识别精确率与召回率）。
• 评审与判定方式：由 EnvInterpreter 进行确定性金丝雀匹配判定角色与作用域；通过执行检查判定高权限源是否被修改，并通过第二轮良性输入检查智能体是否产生预期无害行为（如运行 hello world 脚本或输出 hello to CoRA 标记）；论文未设置 LLM 评分模型或主观打分阈值。
• 样本量与重复次数：跨 12 个智能体评估 1761 条候选路径；作用域判定采用跨 3 次启动（目标项目 2 次、不同目录 1 次）的差异测试；端到端 PoC 实验的重复次数论文未报告。

主结果

主实验评估了 12 个智能体 Harness 在各模型下的攻击路径加载与行为验证表现（据 Table VII）：

Swipe horizontally to read the table

模型与评测范围	候选路径数	载入高权限源数（Loaded）	行为验证数（Verified）
GPT-5.4 mini（跨 12 个智能体汇总）	1761	1284 (73%)	1028 (58%)
GPT-5.5（跨 12 个智能体汇总）	1761	1315 (74%)	1034 (58%)
Claude-Sonnet-4.6（Claude Code）	51	40 (78%)	40 (78%)
Claude-Opus-4.6（Claude Code）	51	36 (71%)	31 (61%)
Gemini-2.5-Flash（Gemini CLI）	102	90 (88%)	65 (64%)
Gemini-2.5-Pro（Gemini CLI）	102	82 (80%)	65 (64%)

• 模型指令遵循能力差异：作者称，GPT-5.5 的载入路径数（1315 条）略高于 GPT-5.4 mini（1284 条），推测反映了指令遵循能力的差距，GPT-5.5 更容易注意到上下文中非显著位置的指令，但两者的最终行为验证率相同（均为 58%）。
• 原生模型验证表现：在 Claude Code 上，Claude-Sonnet-4.6 的行为验证率为 78%（40/51），高于 Claude-Opus-4.6 的 61%（31/51）；在 Gemini CLI 上，Gemini-2.5-Flash 与 Gemini-2.5-Pro 的行为验证率均为 64%（65/102）。
• 表格说明：上表按模型汇总了主实验结果；跨 12 个智能体单体数据中，Qwen Code 在 GPT-5.4 mini 和 GPT-5.5 下的载入率均达到 100%（55/55），而 Aider 的行为验证率最低（GPT-5.4 mini 下为 35%，GPT-5.5 下为 39%），完整单体数据参见 Table VII。

上下文源识别与运行时验证评估

• 测了什么：在 Codex 和 Gemini CLI 上对比 CORA 静态分析与人工真值，并对过滤源和待验证源进行分析。
• 结果：对于 Codex，CORA 识别了 30 个真值源中的 28 个且报告 0 个假阳性，精确率 100%，召回率 93%；对于 Gemini CLI，识别了 42 个真值源中的 38 个并报告 1 个假阳性，精确率 97%，召回率 91%（§ VI-D）。在 463 个候选源中，CORA 过滤了 161 个（人工复核确认其中 156 个正确跳过、5 个为假阴性）；对剩余 302 个源成功运行时验证 282 个（93.4%）。
• 作者解读：静态分析能够有效提取异构代码库中的上下文源；5 个假阴性源（如 Aider 的 LANG 环境变量）主要因分析工人认为其有效载荷容量不足而误跳过。

端到端 PoC 攻击评测

• 测了什么：在 12 个智能体上测试了攻击向量组合的端到端利用效果，并在附录展示了 5 个代表性案例（§ C1–C5）。
• 结果：在 Claude Code 中串联动态技能发现（A-5）与内联命令执行（C-5）实现了远程代码执行（RCE）；在 Cline 中利用标记解释（B-2）诱导文件写入覆写全局配置与规则；在 Gemini CLI 中利用 BFS 记忆遍历（A-2）与标记逃逸（B-1）突破沙箱限制写入全局用户记忆（C-7、C-6）；在 Codex 中通过 AGENTS.override.md 覆盖安全检查规则（C-1）使包含后门代码的 PR 获批；在 Claude Code 与 Aider 协同场景中通过 Git 提交日志注入（A-6.2）诱导 Aider 修改 Claude Code 配置文件。
• 作者解读：端到端 PoC 表明，即使智能体运行在沙箱中或由具备安全意识的用户进行人工审查，攻击向量组合仍能实现跨作用域持久化或代码执行。

其他消融与分析

• 上下文源角色分布：282 个验证源中，系统角色 r0 占 183 个（64.9%），用户角色 r1 占 60 个（21.3%），助手角色 r2 占 9 个（3.2%），工具角色 r3 占 30 个（10.6%）（Table VI）。
• 上下文源作用域分布：项目作用域 \sigma_project 占 181 个（64.2%），用户作用域 \sigma_user 占 74 个（26.2%），会话作用域 \sigma_session 占 27 个（9.6%）（Table VI）。
• 上下文源类型分布：配置类源 97 个（34.4%），第三方组件类 79 个（28.0%），记忆与指令文件类 68 个（24.1%），环境与运行时生成类 38 个（13.5%）（§ VI-B）。
• 候选路径维度分布：1761 条路径中，940 条涉及 M-CPE，640 条涉及 X-CPE，181 条同时提升角色与作用域（§ VI-C）。
• 配置文件自修改能力：12 个智能体中有 10 个在 YOLO 模式下能修改自身配置文件，Claude Code 与 Aider 在该模式下仍需用户批准（§ IV-D4）。
• 未载入路径原因归类：部分路径因环境变量或目录名无法承载长指令而出现容量不匹配，部分路径因高权限源依赖特定配置或启动参数等外部条件而未能触发（§ VI-C）。

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

• 复杂环境构建可能失败：在上下文源验证阶段，部分源需要复杂的智能体配置文件或运行时条件（如动态发现的记忆文件），CORA 可能无法生成有效的 EnvSpec 来构建包含目标源的环境（§ V-D）。
• 模型安全对齐导致指令未遵循：在攻击验证阶段，受测 LLM 可能因自身的安全对齐策略或指令遵循能力，未能遵循高权限源中生成的攻击指令；CORA 采用简单嵌入指令模板，自动验证的攻击路径仅构成了智能体特权提升路径的下界（§ V-D）。
• 端到端攻击成功率存在随机性：虽然提出的大多数攻击向量在机制上是确定性的，但在真实端到端攻击中存在影响最终成功率的随机因素，例如智能体在运行时不一定会自主决定调用恶意技能（§ VI-E）。
• 倡议发布上下文清单：针对智能体厂商未公开上下文源及其加载逻辑的现状，作者倡议厂商发布类似于软件物料清单的上下文清单（SBOM），记录上下文源、对应角色和作用域及组装逻辑（§ VI-E）。
• 协调披露与进一步解决方案：作者已向 12 个受影响智能体维护方报告漏洞，计划在披露期内继续与厂商合作推进协调披露与解决方案，之后再公开进一步的漏洞细节（§ VIII）。

实验覆盖范围

• 受测智能体覆盖范围：实际分析覆盖了 12 个开源或逆向构建的终端智能体 Harness（Table I）。
• 受测模型覆盖范围：主实验覆盖了 GPT-5.5 与 GPT-5.4 mini，并针对 Claude Code 补充了 Claude-Sonnet-4.6 与 Claude-Opus-4.6，针对 Gemini CLI 补充了 Gemini-2.5-Flash 与 Gemini-2.5-Pro（Table VII）。
• 上下文源识别基准覆盖范围：静态分析对照的人工基准覆盖了 Codex（30 个源）与 Gemini CLI（42 个源）两个智能体（§ VI-A）。
• 作用域判定测试范围：作用域判定均基于跨 3 次独立启动（目标项目 2 次、不同目录 1 次）的差异测试（§ V-C）。
• 未报告信息陈述：论文未报告端到端 PoC 攻击的多轮交互平均耗时与重复执行成功率（§ C）。

本文系统分析了真实世界 AI 智能体 Harness 上下文组装机制的安全性。

• 问题定位：智能体 Harness 负责将异构信息组装成提示词供模型推理，但当前设计缺乏透明度与统一特权分配规范，导致低信任数据易向高特权角色或全局作用域渗透，带来严重安全风险。
• 攻击分类与向量：形式化定义了消息角色特权提升（M-CPE）与跨作用域特权提升（X-CPE）两类攻击，并从异构上下文源、标记语法和组装逻辑三个维度归纳出 16 种具体攻击向量。
• 自动化分析工具：开发了 LLM 辅助工具 CORA，通过静态分析识别候选上下文源，结合运行时插桩与金丝雀检测判定角色和作用域，并在隔离容器中通过两轮执行验证特权提升路径。
• 主要实验发现：在 12 个智能体 Harness 中运行时验证了 282 个上下文源（系统角色占 64.9%，项目作用域占 64.2%），并自动枚举出 1761 条唯一 CPE 候选路径；在 GPT-5.5 下有 74% 的路径成功载入高特权源、58% 达成预期行为验证。
• 端到端危害与利用：通过攻击向量组合在 Claude Code、Gemini CLI 等多个智能体上完成了端到端 PoC 攻击，实现了突破沙箱写入全局记忆、篡改代码审查逻辑以及远程代码执行。
• 作者结论与治理建议：作者认为 Harness 上下文组装缺陷是智能体系统的结构性隐患，建议厂商发布类似于软件物料清单的上下文清单（SBOM）以公开上下文源与装配规则，消除防御盲区。