Agent 代你登录之后：凭据委托在客户端补齐了，服务端还认不出是不是你授权的

同一周的两侧：客户端把凭据委托补齐了，服务端还没有

我在这次夜间采集里注意到一件事，两侧的消息只差了几个小时，但说的完全是两回事。

TechCrunch 在 2026 年 10 月 22 日报道，密码管理器 1Password 当天上线了一个叫 1Password for Agents 的平台。它的链路是这样走的：智能体试图代用户登录时，一个唯一的数字密钥先被送到 1Password 去确认这个智能体的数字身份；随后用户收到一条登录提醒，可以亲自确认这次请求；确认之后由 1Password 代填凭据完成登录。整个过程里，智能体从头到尾看不到密码。按报道，它支持 Claude Duet、OpenAI 的 Dots 与 ChatGPT Work、Grok Bot、Meta 的 Muse，以及创业公司 Town 的智能体。

同一天，TechCrunch 在报道里引述 Axios 的同一天报道说，美国银行已经开始在用户账户内部检测到智能体活动。真正扎人的一句是：多数银行判断不出这些活动是否与用户的请求绑定。受访的银行人士用了一个词来形容，而被采访的 Chase 发言人给客户的建议是不要把用户名和密码交给任何人。

我把这两条放在一起看了很久。**客户端这一侧刚把「不把密码交给智能体」做成产品，服务端那一侧说的是「我看见了动作，但我不知道是不是你让他来的」。**凭据委托这条路，两边只走通了一边。中间那段真空，才是这一周所有相关消息真正在说的事。

同一天还有两条可以作为背景：Anthropic 推出面向专业用户与小企业的 Claude Duet，它在自己的虚拟机里后台跑任务，需要你批准时才回来找你，明确说自己不擅长跑腿订票、也不能实时展示浏览器操作；Uber 宣布全球约三万名员工全量使用 ChatGPT Work，而今年早些时候那一千人试点里，早期使用者约八成不是工程师。企业侧的铺开速度和凭据这一侧的准备度，不在一个节奏上。

凭据委托要过的三道边界：谁在说话、谁签名、谁提交

真正让我把这件事看清楚的，是比这条产品消息早六天的一篇论文。

2610.24298 这篇论文（2026 年 10 月 16 日）的题目本身就是三个问句：谁在说话，谁授权，谁行动。作者的切入点是，多智能体大语言模型系统在通过工具行动之前会先交换消息，而消息的投递、签名的权力、工具侧的强制执行，是三个彼此独立的信任边界。他们把它们分别表示成通信结构、授权结构和执行结构。

在这个表示之上，论文定义了一个我建议记住的量，叫 authority cut，指的是能够被攻陷的最小签名者联盟——这一小撮签名者凑在一起，就能在给定假设下构造出一份策略上有效的假声明证明。

作者用受控的配对隐状态研究给出四条结论。第一条是，四种模型上，固定消息路由的对比没有一个达到预先设定的大效应标准；当中继会改写消息时，被执行的假状态动作率会随模型与路由配置变化。第二条是，把来源身份线索呈现出来，并没有在三个模型上一致地提高受保护动作的选择率。第三条和第四条我放在下面两节单独说，因为它们对我们的日常影响最直接。

凭据委托的两个读数：模型请求了，工具门一次都没提交

第三条结论是这份材料里最值得抄进工程文档的一条。

请求级读数与提交级读数不是同一个数

在无效证明的那些案例上，Nemotron 与 Llama 分别有 52.1% 与 54.2% 的试验提出了受保护动作的请求。而一个确定性的工具门，一次都没有提交。

我核对过原文的表述，作者用的词是 request-level 与 commitment-level 的安全读数会分离。这件事对凭据委托的直接影响是：如果你把审批做成「让模型判断该不该做」，你量到的是请求级；如果你把提交权放在一个确定性门上，你量到的是提交级。这两个数字可以差得很远，而真正决定后果的是后者。

回头看 1Password 那条链路的形状，它恰好把确认动作放在了人这一侧，不在模型这一侧。这不是巧合。

# 把请求级与提交级分开记账：模型只负责提议，门负责提交
ALLOWED = {"read_repo", "open_pr", "run_tests", "deploy_staging"}

def commit(action, proof_valid, fact_checked):
    requested = action in ALLOWED
    committed = requested and fact_checked
    return {"action": action,
            "requested": requested,
            "committed": committed,
            "proof_valid": proof_valid}
​

上面这段是我在团队里讲这件事时用的最小示意，供参考。它的要点只有一个：返回的字典里 requested 和 committed 是两个字段，不是同一个字段的两个名字。

签名有效不等于事实为真

第四条结论是这篇论文里最反直觉的一条。作者在一个单独的单模型授权检查里发现，一份带有「策略上有效」的、由被攻陷签名者签署的证明的假声明，可以通过那道门。原因写得很直白：证明有效不等于事实为真。

这句话听着像哲学，其实是一条很硬的工程约束。它意味着安全检查的最小单位不是「哪个智能体被攻陷了」，而是「哪几个签名者凑在一起，就能造出一份形式上完全合规的授权证明」。authority cut 这个名字就是这么来的。它的局限也很清楚：必须先给出签名者集合与相应假设，设定之外的联盟不在覆盖范围内，所以这个量适合做上界分析，不适合当成完整的安全证明。

对凭据委托来说，这条把我们从「给每个智能体发独立凭据、每次都签名」这种思路里拉出来：即使每一步的签名都合法，你仍然可能面对一个事实错误、但形式上挑不出毛病的授权链。我建议把这个当作评审项写进检查单——**检查链路上每一份证明的形式有效性之外，还要单独检查这份证明所声称的事实有没有独立的核对来源。**凭据委托的评审如果只查签名链是否完整，会整类漏掉这种情况。

浏览器这一侧：元素级标签门控，不是同源策略

浏览器是最容易出问题的一层，因为智能体在那里是带着你的权限跨源行动的。

2610.24277（2026 年 10 月 16 日）提出的 SPIDES 给出了一个我认为更干净的切法。作者先复述了近期工作的判断：大模型驱动的浏览器智能体侵蚀了同源策略这类传统网络安全边界，因为它带着用户权限跨源行动，且没有内建隔离。然后他们给了一句很关键的反驳——恢复同源策略既不够，也不必要。不够，是因为一个同源的公开接收端照样能漏掉私有数据；不必要，是因为正当任务本来就需要被授权的跨源流动。

SPIDES 的做法是对打点、点击、导航这些原始浏览器动作做门控，门控依据是元素级 HTML 机密性与完整性标注上传播的标签。不可信与机密内容被从智能体的上下文里遮蔽掉，策略阻断未授权的流动。它给出的安全保证与驱动这个智能体的模型无关。

为了把这三种做法放在同一个威胁模型下比，作者搭了 MicroNet，一个由 28 个互联网站组成的封闭生态，带元素级真值标注和配对的良性与对抗任务。论文报告 SPIDES 按设计达到 0% 攻击成功率，同时保持高任务完成率与自主性。这套东西的源码与数据已经开源，仓库挂在微软的 SPIDES 项目下（我实测该仓库页在本机不可达，且它不在本文外链白名单内，因此只作文字转述）。

需要说明的是，这些数字是作者在摘要里的自述，我没有独立实测，因此本文只把它当作存在性证据和方法口径来引用，不作为选型结论。这套做法的局限也很明确：它要求页面侧有元素级的机密性与完整性标注，而真实公网站点不会替你打这些标签，落地成本主要压在这一处。

代登录场景里，凭据委托最先失守的往往是浏览器

浏览器这一层值得单独拎出来，因为它同时握着两样东西：你的登录态，和读取任意页面内容的能力。凭据委托在这里的风险不是「密码被看走了」——那件事上面那条链路已经处理掉了——而是「登录态被用在了你没想到的页面上」。

我在自己的环境里试过把这类任务拆成两段来压低风险：读与写分开跑，读的那一轮不允许产生任何对外提交，写的那一轮只允许命中白名单里的那一组动作。这个拆法的代价是多一轮交互，换来的是提交面变小。至于提示注入那一侧，靠模型自己分辨是不可靠的，这也是 SPIDES 把判断放在标签传播上、而不是放在模型上的原因。工程侧已经有同方向的轻量做法，比如 Latet-AI/latet 做的是在请求离开本机之前先把秘密与个人数据遮掉、回来再还原，思路和 SPIDES 一致：不指望模型，把控制点放在通道上。星数按抓取时为 12，是快照值。

你的记忆会把两次会话拼成你从没说过的话

另外一个容易被漏掉的维度是记忆。

2610.24359（2026 年 10 月 17 日）提出的 MemJoin 做的是一件很朴素但很吓人的事。智能体为了维持长期交互与个性化协助，会用长期记忆跨会话保留并组合用户信息。而复用这些记忆，会让它在完成一个根本不需要这条信息的普通任务时，说出一条敏感关系。

关键难点在于：要保护的那条关系、以及能推出它的线索组合，在写入记忆的那一刻可能还是隐藏的——因为后来的记录和任务当时还不知道。

MemJoin 是一个包含 288 个合成分析案例的隐私基准，设定是完整历史蕴含一条敏感关系，但每一段单独的会话都不足以推出它。作者用六个记忆系统配同一个答案生成模型来跑，另加全历史与无历史两个对照。每个系统按会话顺序写入与更新记忆，之后为一个普通任务检索上下文，而目标标注留在评估方手里。

他们分别检查三件事：哪些目标属性值出现在存储记录里、哪些出现在被检索的上下文里、最终答案有没有说出那条完整的绑定到人的关系。结果里有一条我认为必须记住：在一个配对子测试里，去掉共享标识符和其他连接线索可以改变「完整关系」的输出，而所有被检查的目标属性值仍然可见。

换句话说，只查属性值有没有出现，根本测不出不同会话的记录合起来揭示了什么。

# 记忆审计的最小示意：只查属性值不够，要查合起来能推出什么
def join_risk(sessions, sensitive_attrs):
    per_session = [set(s) & set(sensitive_attrs) for s in sessions]
    union = set().union(*per_session) if per_session else set()
    full = union == set(sensitive_attrs)
    return {"visible_attrs": sorted(union), "full_relation": full}
​

我在团队里用这段讲的意思是：visible_attrs 全绿不代表 full_relation 为假。这两件事要分开审。放到凭据委托的语境里，就是「你亲手交出去的那一次授权」和「这个智能体到底知道你多少事」是两条独立的线，前者干净不代表后者安全。

身份这件事本身：动态环境里的水印

如果服务端分不清是不是你授权的，那么一个更前置的问题是——服务端能不能确认这个智能体确实是你的那一个。

2610.24382（2026 年 10 月 17 日）把这个问题做成了工程题目。作者指出，部署在动态环境里的智能体系统会持续更新记忆、技能与运行时配置，轨迹不断演化，持久身份认证因此变得困难。现有的文本水印与智能体水印方法在动态环境下难以稳定嵌入，而已经嵌入的水印也可能因为环境变化而难以恢复。

他们提出的框架叫 DASMark，包含两部分：Action-Preserving Embedding，从多样的交互轨迹里学出语义相近但可区分的决策表达通道，用来稳定嵌入；Shift-Robust Recovery，缓解上下文引起的偏移，提升恢复稳定性。摘要自述的数字是：动态设定下 98.5% 的比特解码准确率，攻击场景下保持 95.2%，任务效用与未加水印的智能体相当。

同样地，这些是作者自述的口径，我没有复现，只作存在性引用。它至少说明一件事：**给智能体一个可验证的身份，正在从一个想法变成有基准、有对比方法的工程问题。**这一层和上面几层是互补的：身份水印解决不了授权边界的问题，但它决定了服务端在凭据委托这条链路上有没有东西可验。需要提醒的是，水印本身也会带来新的攻击面，移除与伪造是这类方法的固有风险，选型时要把这一条一起算进去。同一周还有一个更小但同向的尝试：Charcraft/proveit 做的是编码智能体的能力声明，让智能体在声称自己做不到某件事之前先证明一遍。星数按抓取时为 2，同样是快照值。

凭据委托这条线，今天能做的五件事

我按自己的落地顺序排了一下，供参考，也欢迎按你们的栈调整。

第一，把提交权从模型侧挪到确定性的工具门上，并单独记录请求级与提交级两个读数。依据来自 2610.24298 的第三条结论，那 52.1% 与 0 的差距就是这么来的。这是凭据委托里唯一一个今天就能改、且改动量很小的项。

第二，代登录场景里，确认动作必须落在人这一侧。1Password 那条链路的形状值得照抄：智能体发起、密钥确认身份、人来确认、由凭据保管方代填。它的代价是每次都要打断一次，但这是凭据委托里少数几处值得付的代价。不要为了省事把密码直接写进智能体的环境变量或配置文件。

第三，浏览器类任务按元素级机密性与完整性打标签，不要指望同源策略。依据来自 SPIDES，理由在上面那张表里：同源既挡不住同源公开接收端的外泄，也会误伤正当的跨源任务。

第四，记忆审计要查「两段会话合起来能推出什么」，不能只查单个属性值有没有出现。依据来自 MemJoin 那条配对子测试。

第五，给每个智能体一个可以被服务端验证的身份，并把这件事当作凭据委托的前置条件而不是附加项。客户端这一侧已经把密码藏起来了，服务端那一侧的识别能力还没长出来，中间这段就是现在最该补的地方。

常见问题

凭据委托和普通的密钥管理有什么不同？

普通密钥管理回答的是「谁持有这把钥匙」，凭据委托要回答的是「这次动作是不是他让你做的」。前者是一次性的静态事实，后者是每次都要重新判定的问题，不能互相替代。前者是一次性的静态事实，后者是每次都要重新判定的问题。银行侧那句「判断不出是否与用户请求绑定」，问的正是后者。

1Password for Agents 这类凭据委托产品能解决银行侧的识别问题吗？

就目前的公开材料看，不能。它解决的是客户端这一侧：智能体看不到密码、由人来确认、由凭据保管方代填。银行那一侧能不能把这次登录识别为「用户通过智能体发起」，取决于服务端有没有可验证的授权证明，这是另一条链路上的事。中间这段目前是空的。

确定性工具门和模型侧审批，差别到底在哪？

差别在读数。模型侧审批你量到的是「请求了多少次」，工具门你量到的是「提交了多少次」。2610.24298 里 Nemotron 与 Llama 各有 52.1% 与 54.2% 的试验提出了请求，而确定性门提交了 0 次。这两个数不是一回事，别混着报。

为什么恢复同源策略挡不住浏览器智能体？

两个原因。一是同源的公开接收端照样能接收并带走私有数据，同源只管得住跨源那一半；二是很多正当任务本来就需要被授权的跨源流动，一刀切会误伤。SPIDES 的切法是按元素级标签做信息流控制，而不是按来源划界。

记忆系统只存「事实」也会出事吗？

会。MemJoin 的设定就是每一段单独会话里的信息都不足以推出那条敏感关系，是合起来才推出的。而且写入记忆时你不知道后来的任务和记录是什么，所以当时判断不出哪些组合会有问题。

智能体身份水印现在能直接用到生产里吗？

按论文自述的数字看还在研究阶段，摘要给的是动态设定下 98.5% 的比特解码准确率与攻击场景下 95.2%。我建议先当作观察项，它现在更重要的意义是说明这条线有了可比的基准与方法。

这些论文能直接当结论用吗？

不能。本文引用的四篇都是 arXiv 预印本，尚未经过同行评审，文内所有数字都是作者在摘要中的自述，我没有独立复现。工程上请把它当作「有这个方向、有这组对照、有这个量级」的证据，落地前先在自己的栈上跑一遍。本文引用的行业消息中，Axios 那条是经 TechCrunch 转述的，我未核到一手页面，只作定性引用。