SPA：跨查询持久化不应洗白信息来源
SPA：跨查询持久化不应洗白信息来源
结论与深度判断
SPA 的核心不是“让 agent 记得更多”，而是规划不读不可信 payload，执行要检查数据与控制依赖，持久化后标签不变。昨天网页里的可疑内容，即使今天被摘要成 wiki 或记忆，也不应自动获得用户指令的权限。
知识点轴：sandbox-security / context management / harness-runtime / benchmark-evaluation。晋升设计分析，因为它将 plan-first、双格信息流和跨查询 artifact 复用连成一条可解释的机制；不是据其低 ASR 宣称长期 agent 已安全。contested 标记的是评测文字/数字口径问题，非否定整个架构。
为什么对用户重要
Hermes 雷达会把外部网页编译成长期知识，后续 coding、数据和发布任务又会读这些知识。一次 ingest 没有造成坏事，不代表后续消费没有风险：外部收款账号、目的地 URL 或部署参数可以留存到下一次高权限操作。
Context-Engineering 负责什么进入上下文，Harness-Engineering 负责什么获准执行；agentflow-flow-centric-agent-security-policy 已讨论沿路径的数据和权限约束，SPA 进一步追问“这些属性是否穿过了存储和下一次查询”。
机制：三个边界不能混成一句安全提示
1. 先定可执行计划，而非边读工具结果边改计划
每个查询的 planner 只生成一次完整 JSON DSL，支持 retrieve / tool / q-llm / display / condition / loop。先做结构验证与信息流验证，再由确定性解释器执行；一般验证/执行失败不回传 planner 反复修补。这样工具结果不能成为重新规划的指令。
Concrete 模式仍向 planner 暴露真实工具 metadata；Abstract 模式先由用户请求合成抽象能力，再绑定具体工具，试图隔离恶意工具描述，但引入 mapping failure。plan-first 不保证工具参数正确：计划“读发票→支付”没被改写，也可能把不可信账号传给支付工具。
2. 两条标签轴：机密性与完整性
每个值同时记录“有多敏感”和“有多可信”。合并来源时，敏感性只能保守升高，可信度只能保守降低。工具既有可接收的敏感级别，也有输入可信度要求；工具输出再合并其预设来源标签。
条件/循环的 program-counter label 记录控制依赖：即使危险参数本身是常量，若某次外部调用是否发生取决于低信任内容，也需要通过策略。q-llm 可以将不可信文本转成 schema-constrained 结构，但输出继承输入标签；摘要、格式化和结构化不是安全背书。普通工具违规阻止执行；display 的违规项按设计替换为 redaction，而不把所有展示失败都描述成全计划拒绝。
3. 存储分成 metadata、value、label
planner 只看到 artifact 的 schema、引用、以及从可信规划输入生成的 intent/output_semantics；真实 payload 和其标签只在执行 retrieve 时取回。随后照常执行 IFC，不能因为“来自自己的数据库”就升级信任。
这些 metadata 不能是任意外部 payload 的无约束摘要，否则隔离层被重新打穿。其工具策略、标签、绑定和执行 runtime 都属于 trusted computing base；Docker 只是可选 per-tool backend，不等于所有工具天然在沙箱里。
评测应读成安全—效用—覆盖率三张表
读取范围：arXiv 2608.27234v1 完整 HTML 文本、公开匿名 artifact README 和 ARCHITECTURE；未运行代码或重现模型实验。原文使用 AgentDojo v1.2.2 的 97 个任务，将其依赖图人工标注后拆成 2–5 轮，构成 AgentDojo-MQ。注入在 episode 开始应用，跨轮保留状态，episode 间重置，末轮按原有任务/安全判据评分。
| 论文报告的配置 | 无注入 utility | 注入 ASR | 必须同时读取的含义 |
| 单查询 Concrete No IFC | 53.0% | 0.4% | plan-first 本身已经使该攻击集成功率很低 |
| 单查询 Concrete IFC | 29.0% | 0.0% | 加强完整性检查也拒绝大量合法数据依赖操作 |
| 多查询 Concrete No IFC | 62.5% | 0.3% | 表 2 按 attack-run 权重汇总，不等于每任务等权 |
| 多查询 Concrete IFC | 35.3% | 0.2% | 被拒绝也可能仍被环境判为攻击成功，不能只看最终回复 |
以上是作者报告值，不是本机复现。文中称当前 tool_knowledge 只弱覆盖跨查询延迟投毒；低 ASR 不能外推为“记忆污染被解决”。Abstract 约四分之三运行先卡在能力映射，低攻击率需要和实际执行覆盖一起看。
表 3 的 Concrete No IFC 复用率同时有 95.4% soft-hit、80.1% strict、16.8% unscorable：前者只对 producer 产生过 artifact 的机会计分，strict 才把缺失 producer 算失败。可见 payload 时 planner 还可能直接抄值，retrieve-hit 又会漏记这种使用。不要把某一个“95.4%”当端到端记忆成功率。
原文内部问题：保留，不静默修成确定事实
- §7.2 写每配置 97 个 baseline 加 949 个 attack，却给总数 1,081。本机算术检查为 1,046；README 也沿用约 1,081。未取得足够运行清单解释差额，因此保留各项陈述并标记待核。
- §7.4 文字将 Figure 11 描述成 ASR 降幅，但附录与图注明确是 baseline utility cost。本页按表 1/2 和附录读取，不传播“ASR 下降 25–35 个百分点”的混淆。
- SQ/MQ 的另组比较用 baseline-run 权重且任务表述/会话/评分同时改变；不能把其提升纯归因于 persistence。原文还指出部分 banking 初始状态可满足 checker，进一步说明“判分通过≠实际做过任务”。
这些问题正是 Agent-Benchmarks 中对象、分母、判据和实际状态必须分开的例子。
对 Hermes / llm-wiki 的可执行启发
- 低风险先做内容规范：source/concept 摘要保留原始 URL、版本、raw hash 和证据等级；“wiki 已收录”不是“可信指令”。当前知识库不声称已经实现 IFC。
- 将外部目的地、身份、收款/发布对象等高影响字段与普通描述分开；未来运行时只允许在独立检查/明确授权后做 scoped endorsement，而不是把整篇摘要提升为高可信。
- 评测持久状态至少分 producer 成功、可召回、实际消费、最终合法完成四阶段；加入延迟到下一查询才使用危险参数的用例，而非只测当轮拒绝。
- arc-addressable-recall-context-compaction 解决准确找回原文，SPA 解决找回后允许如何使用；无损回读也可能无损带回恶意 payload，二者不互相替代。
开放问题包括字段级标签、论证充分的 endorsement、错误 policy 的代价、长程动态重规划能力损失、元数据可信性和更强延迟攻击集。本轮不修改 Hermes 运行时、权限、cron 或模型配置。
原始入口
写入记录
- 2026-09-11 09:09 CST：新增 plan-first、双格信息流与标签保留持久化分析；读取完整原文及架构文档，记录 utility/ASR/复用分母和两处原文口径问题，未运行外部 benchmark。