Agent Harness 上下文权限提升

Agent Harness 上下文权限提升：Memory、Skill 与跨项目污染

作者
DeepSeekAgent.io 编辑部
发布
更新

Agent 的安全边界不只取决于模型会不会拒绝恶意指令，也取决于 Harness 把什么内容送进上下文、给它什么消息角色，以及这些内容会保留多久。

2026 年 9 月发布的论文《What's in Your Agent's Context? Context Privilege Escalation Attacks against AI Agent Harness》系统分析了 12 种主流 Agent Harness，提出“上下文权限提升”（Context Privilege Escalation，CPE）：低信任内容进入更高权限的消息角色，或者从一次会话扩散到项目乃至用户级持久上下文。

这比传统的“网页里藏了一段提示词”更进一步。真正危险的不是恶意文字被读到，而是它被 Harness 重新包装、保存并在后续任务中继续生效。

两种上下文权限提升

M-CPE：消息角色被抬高

模型 API 通常区分 system、developer、user、assistant 和 tool 等消息角色。工具返回的网页、Issue 或文档本应属于低信任内容；如果 Agent 按其中的指令把内容写进 Memory、Skill 或配置文件，下一次加载时，它可能以更高优先级重新进入上下文。

攻击者没有直接修改系统提示词，却借助 Harness 的写入与加载逻辑完成了角色升级。

X-CPE：影响范围被扩大

一段网页内容原本只影响当前会话。如果 Agent 将它写入项目规则，它会影响同一仓库的后续会话；如果继续进入用户级 Memory 或全局配置，它还可能影响其他项目。

这就是跨范围权限提升：一次性的外部内容，变成长期、跨任务甚至跨项目的指令。

论文实际测到了什么

研究覆盖 Codex、Claude Code、Gemini CLI、Qwen Code、OpenCode、Cline、Aider、Pi-mono、OpenClaw 等 12 种 Harness。作者构建了 CoRA，先从源码识别上下文来源，再拦截实际模型请求，用随机 Canary 验证内容进入了哪个角色、具有什么作用范围。

CoRA 从 463 个候选上下文来源中验证了 282 个；对可进入自动验证阶段的来源，验证成功率为 93.4%。论文进一步为 12 种 Harness 构造了端到端攻击路径，结果包括工具调用被操纵、持久 Memory 污染、拒绝服务和远程代码执行。

这些结果揭示的是 Harness 的结构性攻击面：上下文来源越多，自动加载和持久化规则越复杂，开发者越难仅凭界面判断模型究竟看到了什么。

为什么一句“忽略恶意指令”不够

论文中的部分攻击不依赖模型主动相信一段明显可疑的话。Harness 可能自动发现 Skill、读取规则文件、解释标记语法，或者把工具结果保存为以后会再次加载的内容。

因此，仅在 Prompt 中提醒模型保持警惕，无法替代以下控制：

  1. 明确记录每种上下文来源的角色、范围和加载时机。
  2. 禁止低信任工具输出直接写入用户级 Memory、全局 Skill 和执行策略。
  3. 把“读取外部内容”和“修改持久配置”拆成不同权限。
  4. 对跨项目、跨会话的写入设置单独确认。
  5. 审查最终发给模型的消息，而不只审查用户最初输入的 Prompt。

对 DeepSeek Harness 的直接启示

这篇论文没有把 DeepSeek Harness 列入 12 个测试对象，但它给 DSH 的 Plugin、Profile、MCP、Web Tool 和 Session 设计提供了一套可执行的审查方法。

为 Profile 建立 Context Manifest

一个 DSH Profile 应该能回答：启动时加载哪些提示段和插件；哪些内容来自项目、用户目录或外部服务；它们以什么角色进入模型；哪些内容会跨会话保留。

论文把这种清单类比为软件供应链中的 SBOM。对 Harness 来说，它可以叫 Context Manifest：不是列出安装了什么包，而是列出模型实际会看到什么。

限制插件修改持久状态

安装插件时，不应只看它暴露了哪些 Tool。还要检查它是否能修改 Profile、Memory、其他插件配置或用户级文件。一个低信任 Tool 如果能够改变下次启动自动加载的内容，就具备从当前会话扩散到未来会话的路径。

将作用范围写进审批界面

“允许写文件”仍然过于宽泛。更有用的审批信息是：写入工作区文件、项目规则、用户级配置，还是全局 Memory。路径相同是文件操作，安全后果却完全不同。

用 Trajectory 追踪来源迁移

DSH 的 Session 与工具轨迹适合回答“哪段外部内容触发了哪次写入”。下一步应继续标记来源：网页内容是否被复制进项目文件，项目规则是否又进入全局配置。只有保留来源链，才能识别上下文是否发生了权限和范围升级。

面向用户的检查清单

  1. 不要在不可信仓库中直接启用 Full Access。
  2. 检查仓库内的 Agent 规则、Skill、隐藏目录和配置覆盖文件。
  3. 将外部网页、Issue、PR 与下载文档视为数据，而不是任务指令。
  4. 对修改用户目录、全局配置和跨项目 Memory 的操作单独确认。
  5. 完成任务后检查文件改动、Profile 变化和新安装的插件。
  6. 处理陌生项目时使用隔离工作区与最窄权限。

Harness 安全需要从 Prompt 走向数据流

上下文权限提升把安全问题从“模型有没有听信恶意文本”推进到“内容经过 Harness 后获得了什么角色和生命周期”。Memory、Skill、工具输出和环境信息都不是普通字符串，它们在不同加载路径上拥有不同权限。

真正可审计的 Agent Harness，需要公开上下文来源、限制跨范围写入，并让每次持久化都有可追踪的来源。否则，一次看似短暂的工具调用，可能在用户不知情时变成下一次任务的高优先级指令。

相关阅读

常见问题

上下文权限提升和提示词注入有什么区别？

提示词注入描述恶意内容影响模型；上下文权限提升进一步关注这段内容是否被 Harness 放进更高权限的消息角色，或被保存到影响范围更大的持久来源。

只给 Agent 读取权限就安全吗？

读取权限能降低直接修改系统的风险，但 Harness 仍可能自动加载项目规则、Skill 和环境信息。还需要限制持久配置写入、工具调用与跨范围 Memory。

DSH 被这篇论文判定存在漏洞了吗？

没有。论文测试的 12 种 Harness 不包含 DSH。本文使用论文提出的角色、范围和来源模型，分析 DSH 应该如何审查自己的上下文装配边界。