本文面向正在搭建或部署 coding agent / agentic harness的软件、平台与安全工程师。素材来自 Darktrace 2026-09-24 公开研究负责任披露 2026-08-18。文中严格区分「研究事实」与「作者架构建议」不提供可复现的本地库改写步骤不软广任何安全产品不发明 CVE、补丁状态或未公布基准。## 1. 为什么工程师该关心本地历史 未校验的信任根Agentic harness编排层负责把对话历史、系统提示、MCP 工具、shell 能力等拼进模型上下文再把模型输出落回本地。对开发者工作站而言这几乎等于-上下文窗口里的大半内容来自「上一轮声称发生过什么」-对不可逆动作的裁量要不要扫网、要不要读凭据、要不要外联高度依赖会话语境- 会话历史通常落在本机磁盘便于续聊、回退、编辑而不是每次都由模型服务端权威复述。如果本地存储里「模型说过的话」没有被校验为真的出自该模型那么会话库就变成了一块可被改写的信任根。攻击者不需要立刻攻破模型权重或云端 API key只要能改写本地历史就有机会让 agent 相信自己「正处于授权红队演练中」从而把既有 shell / 工具权限推上侦察 → 横向 → 影响的轨道。这和邮件长期缺少可靠发件人验证、早期网络协议默认互信是同一类工程债新能力默认信任校验后补。对平台团队正确的反应不是「关掉所有 agent」而是把会话完整性、工具最小权限、行为基线、高敏人闸写进默认架构。## 2. 研究事实一览仅复述已公开信息以下表格只收录 Darktrace 博客可核对的事实访问日 2026-09-25不额外发明指标或补丁状态| 项 | 公开信息 || — | — || 发布 | 2026-09-24作者 Eric Rozon 等 || 披露 | 2026-08-18 向 Anthropic、AWS、OpenAI 负责任披露约 30 天后公开发布 || 核心发现 | Agentic harness 将对话历史存在本地未校验「已存储的 AI 响应是否真由对应模型产生」 || 确认范围 | Anthropic Claude Code、AWS Kiro-CLI、OpenAI Codex、开源 Pi || 攻击思路 | 改写本地历史使 agent 相信自己处于授权红队中途 → 可驱动侦察 → 横向 → 影响 || 模型态度 |所测模型均接受伪造历史对进攻性网络行为的抗拒因模型而异部分 guardrail 会拦截 || Kiro-CLI 机制级描述 | 会话落在本地库响应内容字段可被覆盖harness信任库内容、不做真伪校验本文不复述可操作改写步骤 || 沙箱 AD 实验室结果 | Kiro-CLI Claude Opus 4.6 / Sonnet 4.5 → 完整 AD 沦陷Claude Code Sonnet 5 → 完整 AD 沦陷Opus 5 guardrail 拦截Codex GPT 5.6 Sol → 邮件外泄Luna / Terra / Sol 在实验室对「黑客尝试」触发 guardrail || 供应链叙事 | 恶意包例如植入的 MCP server安装后向本地 harness 会话库注入投毒历史再由编排环提示「红队 agent」agentic 环的费用可能由受害者支付|| 研究提出的修复方向 | 模型提供商对响应密码学签名并在服务端校验偏提供商侧防御方无法独自落地另需行为监控检测偏离正常 agent 行为 || 先前讨论 | 0DIN、Serhat Çiçek 等已讨论过 conversation history poisoning |不要把实验室 AD 沦陷结果写成「你的生产环境必然沦陷」。那是沙箱复现用来证明机制成立与 guardrail 差异不是通用渗透基准。## 3. 攻击链投毒 → 裁量覆盖 → Agent 环研究把问题拆成两层对工程师特别有用1.能力层harness 往往已把 shell、文件读写、联网工具交给 agent——技术上「能做很多事」。2.意愿 / 裁量层模型是否愿意做进攻性动作取决于训练、系统提示以及当前会话声称的授权语境。当本地历史被改写成「漫长的授权红队合规记录」后同一句请求可能从「拒绝」变成「立刻执行」。研究强调所测模型都会接受伪造历史真正拉开差距的是后续对进攻性行为的 guardrail。换句话说——历史完整性失效时guardrail 变成最后一道、且并不均匀的闸门。对平台架构师这意味着不能把「模型很安全」当成会话存储可以随便信任的理由。会话库一旦被污染你实际上是在用可被改写的上下文驱动一台已授权的自动化执行器。### 3.1 什么该写进威胁模型作者建议以下为作者架构建议不是研究原文 checklist- 将「本地会话目录 / 会话库」标为与 API token、SSH key 同级的高敏资产- 假设「任意能写该目录的进程」都能尝试投毒安装脚本、恶意 MCP、被劫持的编辑器插件、共享工作站上的其他用户- 假设「续聊 / rewind / 编辑历史」产品能力与「攻击者批量注入回合」共享同一存储面——产品便利即攻击面- 不要假设开源 harness「没有披露对象」就更安全研究明确 Pi 因无法做提供商侧历史校验而未走同一披露路径。## 4. MCP / 包安装最贴近开发者的分发向量研究给出的供应链叙事对日常工程特别刺耳因为它几乎不依赖奇技淫巧1. 开发者机器上已经装了agentic harness有 shell、有会话库2. 安装一个「看起来有用」的包——研究举例是被植入的 MCP server恰恰是 harness 用户才会装的东西3. 安装钩子向本地会话存储写入伪造历史4. 附带一个简单编排环持续提示被投毒的「红队 agent」去最大化影响5. 算力与 API 费用走受害者已付费的合法账号。这不是「远程 0-day 弹 shell」叙事而是开发者工具链信任链叙事你允许安装的扩展默认获得了靠近会话库与工具面的位置。### 4.1 平台侧可立刻收紧的安装边界作者建议研究没有给出你们公司的政策模板以下为工程常见的最小集合| 控制 | 目的 || — | — || MCP / 扩展allowlist| 阻断「随手装一个 server」成为投毒入口 || 安装进程禁止写会话目录| 即使包恶意也写不进历史信任根 || 未受信 MCP默认无 shell| 缩小「被说服之后立刻能打网」的爆炸半径 || 会话库OS ACL / 独立用户| 普通项目依赖安装不应具备写历史的权限 || 高敏工具dual control| 网扫、凭据、外联、批量改配置必须人闸 |硬规则提醒本文故意不给出「如何用一条语句改写某字段」的操作菜谱。机制理解到「响应字段可被覆盖 harness 无校验」已足够做架构决策可操作细节只会降低攻击成本。## 5. 缓解你现在能上线的与必须等提供商的### 5.1 研究明确的提供商侧方向事实研究提议harness / 模型提供商默认对返回消息做密码学签名并在每一轮往返时服务端校验历史声明。关键点- 这是提供商侧修复企业安全团队无法单靠自家 SIEM「补上签名」- 在签名方案普及前本地会话仍可能被改写- 因此需要并行建设行为层知道 agent 平时做什么偏离时告警或阻断。### 5.2 平台团队过渡层作者建议在等待签名体系之前仍可显著缩小爆炸半径1.历史不可变层本地- 会话追加写append-only 定期外送只读审计副本 - 工作副本与审计副本分离任何「编辑历史 / rewind」走显式、可审计的 API而不是直接改库 - 对会话目录做完整性监控哈希 / IMA / 文件完整性工具——选型按你们栈此处不绑定厂商。2.工具信任边界- coding agent 默认工作区沙箱 - 生产凭据、域管、云 admin 角色不要长期挂在 agent 进程上 - 网络策略默认拒绝横向扫描目标网段除非工单临时放行。3.会话异常信号- 记录每次 tool call工具名、参数摘要、是否人闸、会话 ID - 基线该项目/该角色通常调用哪些工具、频率、是否触网 - 触发熔断的例子需按环境校准勿照抄阈值突增nmap类侦察、批量凭据文件读取、向陌生外域发邮件/HTTP、短时间内跨大量主机认证。4.不可逆动作 dual control- 把「可能构成进攻或高影响」的工具单独编组 - 需要第二人批准或至少 break-glass 记录 - agent 可以起草 runbook但执行权在人控流水线。再次强调上述 5.2 为作者建议研究原文的硬结论停在「签名 行为监控」层级。### 5.3 把「信任边界」画进架构图作者建议很多团队的 agent 架构图只画「模型 ↔ harness ↔ 工具」。加上历史投毒威胁后至少应多画三条边1.磁盘 → 上下文会话库读入上下文窗口的路径谁有写权限谁就能污染下一轮裁量。 2.安装链 → 磁盘包管理器 / MCP 安装器是否与会话目录共享 UID、工作目录或组权限。 3.工具 → 侧效应shell、邮件、云 API、域查询各自落在哪条网络与身份边界上投毒成功后爆炸半径等于这些边界的并集。评审会上可以用两个问题快速压测设计- 「如果明天会话文件被换成『我已授权红队』的伪造剧本我们的哪一层会先失败」 - 「失败之后是模型 guardrail、工具 allowlist、网络策略还是人闸最先拦住」若答案只剩「指望模型拒绝」说明完整性与权限分层还没进架构只是把风险外包给了不可控的裁量。### 5.4 和经典提示注入的差别便于对内沟通提示注入通常争夺的是当前输入或检索到的不可信内容历史投毒争夺的是已被系统当作既往事实的记忆。工程上的差别是- 提示注入缓解常谈输入隔离、引用标记、工具输出消毒 - 历史投毒还要求记忆本身可验证——否则消毒只覆盖「这一轮新进来的字」覆盖不了「昨天被写进库、今天被当成模型原话读出的字」。两者可以叠加供应链投毒写入历史再在后续回合用正常用户口吻催促执行。因此平台文档里建议把它们并列为Context Integrity子类而不是只开「Prompt Injection」工单。## 6. 平台团队检查清单可直接贴进评审把下面当作变更评审 / Agent 上线门禁的草稿作者建议- [ ] 会话存储路径、权限、备份与审计副本是否文档化 - [ ] 安装 MCP / 插件是否走 allowlist 代码审阅安装脚本能否写会话目录 - [ ] 未受信工具默认是否无 shell、无生产凭据、无横向网段 - [ ] 高敏工具是否 dual control人闸证据能否回放 - [ ] tool call 审计是否完整有无「正常行为」基线与偏离告警 - [ ] 事件响应 runbook 是否包含「怀疑会话投毒 → 冻结会话、比对审计副本、吊销 agent 凭据」 - [ ] 采购 / 架构评审是否追问提供商响应是否签名、历史是否服务端校验在其落地前不把「模型品牌」当成完整性方案 - [ ] 开发者文档是否明确不要把「本地可编辑历史」当成安全边界## 7. 不确定性与披露时间线避免过度解读写进对外材料前请守住这些边界1.披露窗口研究称 2026-08-18 向 Anthropic / AWS / OpenAI 披露约 30 天后于 2026-09-24 公开。本文不声称任一厂商已发补丁、已上线签名或「已修复」——公开文未给出可引用的补丁状态。 2.实验室 ≠ 生产AD 完整沦陷、邮件外泄等结果发生在沙箱生产是否可打穿取决于网络分段、凭据卫生、guardrail、人闸与监控。 3.Guardrail 差异会变Sonnet / Opus / Sol / Luna / Terra 的拦截表现是研究当时的观察会随模型与策略更新变化不要固化成永久安全等级表。 4.开源 Pi研究说明未对 Pi 走同一披露流程因其无法做提供商侧历史校验这不等于「Pi 更危险或更安全」的定量结论。 5.先前艺术0DIN、Serhat Çiçek 等已讨论 history poisoning本文焦点是 harness 本地存储 agent 裁量被劫持的工程含义不重复学术谱系。 6.产品中立Darktrace 仅作为研究发布方提及正文不讨论其产品能力、定价或试用。检测思路只用「行为基线 / 会话异常」等通用词。—结语工程口径Agentic harness 把「会写代码的模型」变成了「能动手的执行器」。当执行器的记忆存放在可被本机改写且未校验的会话库里红队剧本不必从提示词注入开始——可以从改写昨天的对话开始。在提供商侧签名落地之前平台团队仍有大量可交付物收紧会话目录与安装链、砍掉未受信 shell、给高敏工具上 dual control、并把「agent 是否偏离日常」当成一等监控信号。