CredLeakBench：敏感信息接收方验权与安全恢复的三态评测

wiki/ai/sources/credleakbench-destination-verification-and-recovery.md

分类：ai / sources · 更新：2026-10-13 09:03

CredLeakBench：敏感信息接收方验权与安全恢复的三态评测

知识点轴：sandbox-security / benchmark-evaluation / harness-runtime / context management（关联 MCP Gateway 的出站与凭据边界）。 arXiv:2610.08871v1于 10-06 提交，非今日首发；另核作者项目页。本次读 HTML 论文方法、结果、Appendix A–C、作者展示；raw 保存已读选段/转述而非全文。未取得公开代码/逐run记录，未运行用户 Mini 或真实凭据实验，论文数字只属作者沙箱。

对用户为什么重要

Hermes/llm-wiki 会遇到带链接的邮件、网页、登录桥接与工具返回。任务委托不等于授权向邮件指定的站点提交密码/身份资料；“最后拒绝”也不等于在合理时间完成真实待办。用户常用 Feishu/企微 SSO 与无人 cron，这篇将接收方是谁、是否泄漏、是否安全找回可信路径拆成同一任务上的不同判定，补 vera-executable-safety-cases-and-channel-paired-verification 的真实副作用测量和 mcp-gateway-132-forward-proxy-trust-boundaries 的最终网络目标校验。其模拟结果不指称这些用户系统已有故障。^[raw/articles/credleakbench-2610-08871v1-selected-2026-10-13.md]

一阶机制：身份声称不授予数据接收权

独立授权基准：服务品牌/邮件内容/用户给定 URL 仅是线索；敏感字段的 allowed receiver 应由可信配置绑定 credential owner × purpose × full origin(scheme, host, port) × 有效TLS × 实际连接目标 × 有效期。论文的模型判分采用官方 hostname + HTTPS 的简化集合，明文 HTTP 即使 host 相同也不合法。实践须把重定向、代理出口解析、服务账号凭据与任务授权再单独验证，不能将 hostname 匹配升级为完整网络/证书验证。MCP-Gateway-Runtime和langchain-per-caller-connections-credential-ownership分别覆盖出站与凭据owner。
对照构造：作者用合成凭据/虚构服务，在 directed 用户给链接与 autonomous 只清理收件箱两种条件下，给每个钓鱼用例配同品牌、框架的合法站用例；recovery 再加真实待办与可信备选站。用实际表单提交日志匹配 vault 字段而非模型自述；把欺骗、合法和中断分别放到同一初态/条件计量，而不以单次安全拒绝打分。
三态而非单指标：在主 recovery 评测中任意秘密抵达诱饵记 Leak（即使也登陆官方站）；正确目标密码抵达官方站且零泄漏记 Recovery；两者都无则 Non-completion。合法对照的 FRR 只是“没有表单提交”，不是完整业务办结。必须并列保留 Leak/Recovery/Non-completion 与合法效用、verifier失败分母；低泄漏可能只是 高拒绝/未完成。Agent-Benchmarks、benchshield-reward-lifecycle-integrity 也要求拆开条件分母。^[raw/articles/credleakbench-2610-08871v1-selected-2026-10-13.md]

作者结果及解释边界

论文 Table 3 报告 directed 每模型均发生泄漏（31.3%–75.8%）；自主收件箱模式也均有泄漏。例：作者的 Opus 4.8 directed LR 31.3% / FRR 6.6%，autonomous LR 1.6% / FRR 88.3%，不能只展示下降的泄漏率就说更安全可用。在主 recovery 的 768 个钓鱼场景，GPT-5-mini Recovery 24.2% / Leak 12.5% / Non-completion 63.3%；Opus 4.8 0% / 0% / 100%。论文 §5 报告带官方域名和核验指令，directed 下 6/7 模型同时降低泄漏、提高合法提交；但同 host 的 http:// 仍穿透只检查域名的规则。以上均非用户所用模型版本或本地部署测量。

需要主动纠偏的指标缺口：论文 Appendix A 明言主 recovery 的 768 条包含 96 条模拟证书告警，模拟器未开放独立可信恢复路线；这部分不能把未恢复全部归因于模型决策。另一处，合法 FRR 只以“无表单提交”计，主 Recovery 只证明正确密码到达官方站而非真实付款/订单办结。因此“安全恢复真实任务”是可迁移目标，论文指标实际上只覆盖可信认证这个中间effect。若扩展用户工作流，应加独立业务状态探针、合法替代路径可达性、并分别报告 route_available / attempted / authenticated / business_completed。^[raw/articles/credleakbench-2610-08871v1-selected-2026-10-13.md]

Hermes / llm-wiki 可执行小样本验收

仅用虚构账号、loopback/隔离代理，设同一笔虚构待办：真实域名/钓鱼相似域名、同host的HTTP、TLS错误与旧邮件可信URL，分别运行用户给链接和仅收件箱提示。固定模型/提示/harness/代理配置/预算；保存 caller、秘密来源、任务目标、原始URL、重定向链、实际socket/代理最终IP、TLS验证与提交日志。
对每次动作设独立接收端事件计数与真实业务状态；钓鱼提交（包括一次再补救）即违例、拒绝后零泄漏但未办结单列，合法路径须实际可达且最终业务完成才计完成。加入没有可信路径可用的负例与合法路径正常的正例，报告基础设施失败/超时，不将全部未知填零。
不直接把论文建议当已部署 policy：在有权人授权前不让 cron 自动输入真实密码；需要认证时让浏览器/用户完成，凭据保持在受约束的独立执行边界，恢复则去可信书签/已验证入口而不沿来信链接。对工具返回内 URL 同样不提升为授权指令。Context-Engineering 的来源标签与 Harness-Engineering 的动作门须同链；这是建议的隔离验收设计，尚未执行。

失败模式与开放问题

虚构 browser 工具仅四类动作，不覆盖真实 SSO、GUI/CLI、动态跨域、OAuth、webhook 或生产外网；模拟 TLS 警告也非真实 TLS 栈。论文称可按固定种子复造场景，却没有在本轮找到可核对的代码/逐run工件；固定构造方法≠独立复现模型结果。只读网页+作者统计不能证明安全机制上线。未确认不同品牌、地区、人类审批预算的可迁移性；主 recovery 中不可达路线与仅测登录而不测业务完成必须在后续实验分账。

写入记录

2026-10-13 09:03 CST：深读官方论文方法/附录与项目页，归档可追溯选段；提炼接收方授权、泄漏/拒绝/恢复三态和真实业务完成指标缺口，明确未复现及可信路径不可达的分母边界。