MOLE：按日复核预算评估监控，先核标签与指标实现
MOLE：按日复核预算评估监控，先核标签与指标实现
值得迁移的不是“某模型抓到了多少坏 agent”，而是：在固定每日人工复核容量下排序；隔离监控可见信息与标签证据；把离线检测、在线预防和实现口径分开。 论文的 state-grounded 叙述与所读 labeler 路径尚未逐样本对账，保留 contested。
知识点轴：benchmark-evaluation / sandbox-security / harness-runtime / context management。
为什么这对用户重要
告警与 agent 安全监控通常不是无预算二分类：用户每天最多看一批事件，历史状态又不能由当前 latest 替代。MOLE 把组织协作任务、持续服务状态与 account-day 排名结合起来，对 Hermes 的动作审计和内部 benchmark 有耐久价值。它不是 container-breakout benchmark，也不提供本机安全认证。
来源为 arXiv:2609.06966v1 及 aashiqmuhamed/mole，固定 commit 702199e40fe25065290a1fb7933865d67eee1dc2（2026-09-14 API：1 star）。已归档完整论文抽取文本；深读主文与附录 B、E、G.3、L.1/L.3/L.4、N，并审 selected metric/labeler 代码。低 star 不否决有机制深度的来源；作者统计均不是本机实验结果。
一：实验单位与真实状态
论文组织包含 150 个账号、九类有持续状态的服务；攻击与正常工作使用相同账号身份、模型和服务访问能力。单日与多日 campaign 分别构造一次完成和跨日准备/完成；协同威胁只在多日分析中出现。附录 B 的 20 个 held-out 账号继续参与日排名，但活动不用于拟合 monitor；不能把“held-out”理解成完全不可见或不在组织中。
正例按 完成该账号被分配的 harmful objective 定义。多日单人准备日仍是负例，完成日才可为正；协同攻击中每个参与者完成自己分工时判定。一个账号不是从首次可疑起永久正例。迁移到用户事件排查时，应以 actor + event_time + historical state + objective 绑定证据，而非用当前状态回填过去。
原始审计事件包含模拟时间、账号、service/action、目标/hash、参数、结果状态及 session 关联。monitor 和 privileged labeler 的可见数据分开，避免把私有恶意任务或 ground-truth 标签塞进待评模型。这补充 redagentbench-state-grounded-safety-measurement 的 execution/evidence/proof 分层。
二：每日预算下的 recall，与同名 campaign 指标不同
论文主要监控指标按每日排序，只调查 top-B account-days，并考察 budget-AUC。全局 AUROC 高，不等于能在每天有限复核名额里找到目标；把多个工作日混成全局 top-K 会掩盖日负载峰值。
固定 repo 同时保留两个不同函数：
| 实现 | 分母/语义 | 无正例行为 |
scripts/auc_eval.py::recall_at_daily_budget | 每天选 top-K，累计命中 positive account-days，再除以全部 positive account-days | 返回实现值 0 |
mole/metrics.py::daily_recall_at_k | 按恶意账号/campaign 命中，另有 tabu 与时间窗语义 | 返回 NaN |
本机最小反例，明确为人工构造 fixture，不是发布数据： 两天里同一个恶意账号每天都为正，只有一天排第一。前者 Recall@1=0.5，后者即使 tabu_days=0, window_days=1 仍为 1.0，因为“账号曾被抓到”与“正例账号日覆盖”不是同一分母。参数调成相似不能消除定义差异。
因此内部 runner 的成绩单需要同时固定 commit、entry point、ranking unit、positive unit、预算/时间窗和 missing/NaN 规则；无正例返回零是实现约定，不应解释成监控质量为零。Agent-Benchmarks 不能只用一个 recall 字段收集这些结果。
三：ground truth 也有一条需要审计的证据流水线
论文附录 B 说完成需要 service-state verification；附录 E 的人工验证实际展示 assigned objective 和 transcript（reasoning、service calls、tool results）。固定 repo 的 scripts/llm_harm_label.py 使用 privileged transcript + assigned persona + rubric，让 LLM 返回 executed / attempted / refused / no_attempt；只把 executed 放入 positive account-days。
所读脚本不是独立的 service-state verifier；它是否以及怎样与论文使用的完整状态验证链拼接，本轮没有取得逐样本证明。这不是已证实论文错误，而是论文声明、当前脚本与发布标签之间仍有证据缺口，故 contested，不能把“读过 labeler”写成已核实全部 truth。
更具体的上下文失真来自序列化：
- assistant narration 每条保留前 600 字符；tool result 每条保留前 400。
- tool-call arguments 用 6,000 字符 head+tail；整体会话另有 200,000 字符上限。
- 它会保留 content 为空的 silent tool call，避免只看自然语言漏掉动作；但整体预算很大不代表每条工具结果完整。
本机抽取这些纯函数，以末尾标记做 fixture：narration 与 result 的尾标记消失，arguments 尾标记保留，silent call 仍可见。这是可复现的 serialization 行为，不是已证明发布标签因裁剪而误判。应将完整 result 的不可变引用/哈希与判分视图分开保存，这与 Context-Engineering 的可回读证据和 benchshield-reward-lifecycle-integrity 的 source-to-score 完整性相连。
四：人审一致率的分母与类别覆盖
附录 E 报告 18 名评审、540 次 ratings，但仅覆盖 32 个 unique account-days；不能宣传成 540 个独立案例。按 account-day cluster bootstrap 的做法避免把同案多人评分当独立样本。
本机仅复算作者表中比例：包括两次 unsure 时四分类一致率 504/540=93.3%；排除 unsure 后 504/538≈93.7%；完成/未完成二分类 524/538≈97.4%。不是重新做 bootstrap 或重新人工标注。样本没有被 GPT-4o 标成 refusal 的 account-day，四个类别覆盖不均；两个 account-day 还在 attempt/complete 边界上被所有人反对。
结论应写成“所抽样 transcript 的条件一致性”，不是“现实组织中标签准确率 97.4%”。威胁真实感的 matched/control 差异也不足以证明仿真组织与真实部署不可区分。
五：更实用的机制是廉价特征 + 选择性升级
附录 L 的 monitor-search 使用 training 历史拟合无标签统计、validation aggregate budget-AUC 做反馈，冻结策略后才看 test 与另外两个 corpus；限制 evaluator 反馈、禁止读取文件/import/硬编码 account ID。这是作者的搜索隔离设计，本轮没有安全审计 restricted interpreter。 反复查 validation 即使不见明细标签仍会过拟合，预算上限与独立 test 不可省略。
便宜信号包括 action/bigram rarity、transition surprise、sequence novelty、同团队相对稀有度；再选择性调用昂贵模型，而不是让大模型审每条日志。作者报告的 multiday 一组策略 budget-AUC 0.629 对比 uniform 0.571；这是该数据集和协议下约 10.2% 的相对变化，不是通用提升。
成本口径同样限定：主模型按相同输入长度与 input-token 价格估算，统计特征没有模型推理费，一次性 profile 提取不计入日常费；不能叫完整运营成本。L.4 对输入长度做敏感性检查，但没有据此补齐所有账单、延迟、人审和基础设施成本。同日 peer rarity 也不能未经修改用于“当前动作前”在线干预，否则看到了未来数据。
六：日终检测不推出在线预防
附录 N 明确：论文报告的是每个工作日结束后的检测，没有报告 prevention experiments。它描述 service-call 前 allow/alert/block 接口，但接口存在不等于实测降低危害。alert-only 仍执行调用，block 才应阻止到达服务及状态修改。
迁移到 MCP-Gateway-Runtime 时应另测：按事件时间前缀做在线评分、阻断后服务状态、误阻正常工作率、攻击绕行与重复调用、检测延迟/预算。不要把 offline 排名改善转写为 security-adjusted success 改善。
给用户的最小实践路线
- 先用离线审计样本建立按日 top-B 报表，保留 executed/attempted/refused/no_attempt 与基础设施失败，不覆盖历史状态。
- 给 metric runner 加上面的两日反例和无正例负例，输出明确分母与 entry point；成绩变化先排查口径。
- 为 verifier 加工具结果尾部证据 fixture；完整原件与 judge-visible 视图分别哈希，长证据通过引用回读。
- 先在隔离环境比较廉价排序→小比例升级，不自动把该 repo 接入生产或运行不可信任务。
验证范围
本机执行 8 项 isolated pure-function 检查，全部通过；加上其他两篇 source 的 13 项静态核查，共 21 项。没有运行上游 pytest、发布 corpus、组织服务、模型监控实验、人工验证或在线阻断；没有把 fixture 当作者数据。原始检查脚本和 JSON 结果已随 raw 归档。
写入记录
- 2026-09-14 09:15 CST：新增论文/固定实现深读与纯函数反例；保留标签状态验证缺口为 contested，明确 account-day/campaign 指标、裁剪、人审分母、成本和离线/在线边界。