别再给 Agent 塞 API Key 了：它值得一把复制不走的钥匙

别再给 Agent 塞 API Key 了：它值得一把复制不走的钥匙

给 Agent 配置一个 API Key，把密钥粘贴进配置文件，跑通了，皆大欢喜。但只要多想一步"这把钥匙的属性"，就会发现它和 Agent 的工作方式处处相悖：Key 是共享秘密，同一份值同时躺在 Agent 的机器和服务端，任何一端泄露，双方一起沦陷；它可复制，任何读到这个文件的人，都能在任何地方"变成"这个 Agent，服务端看不出任何异常；它经手多人，生成、复制、粘贴，每一双手都是潜在的留存点；它活得还久，轮换麻烦，所以一放就是几个月。

个人 Agent 把问题放大到极致——它跑在一台笔记本上，而不是有人值守的数据中心，它的主人很可能根本不是安全工程师。

Passkey 到底改变了什么

Passkey 本质是一对密钥。Agent 在自己的机器上生成密钥对，只把公钥注册到身份提供方。之后每次登录都是一次全新签名：服务端下发挑战值，Agent 用私钥签名应答。

对照 API Key 的四个问题，逐一消解：服务端不再存任何秘密，身份库被拖库，攻击者拿到的只是一堆没用的公钥；每次登录都是新鲜签名，被截获的登录无法重放；没有证书体系，注册即一次公钥登记，不需要 CA、证书链和续期流程；吊销也简单，把公钥从记录里删掉，这个 Agent 立刻再也登不上来。

Agent 自己当认证器

Passkey 的设计初衷是给人用的：指纹、人脸、安全钥匙上敲一下。Agent 无人值守，这些都不适用——那就让 Agent 自己扮演认证器。它创建密钥、组装标准 Passkey 报文、签名挑战值，全程没有浏览器，没有人的动作。在身份提供方眼里，这是一次再普通不过的 Passkey 注册和登录。

这里有一个语义上的微妙转变：Passkey 登录里的"user present"标志，现在说的是"Agent 在场"，而不是"人在场"。人的在场与授权属于另一个环节——任务执行前，由所有者审批。

最难的永远是第一把钥匙

任何凭证体系都有冷启动问题：Agent 还没有密钥时，如何证明"我就是你刚刚创建的那个 Agent"？

可以借用新设备的思路：所有者在账户门户创建 Agent，拿到一个一次性、几分钟内有效的安装凭证；通过聊天把它交给 Agent；Agent 生成自己的 Passkey，用安装凭证注册公钥；身份提供方在注册完成的同时，作废这个安装凭证及其派生的一切。

第 4 步最关键。一个活得比装机流程更久的引导凭证，就是第二条更弱的大门。如果作废靠人手动执行，总有人会忘，而且没有任何东西会提醒他。注册完成后，Agent 手里只剩一个 Passkey，别无其他；要换钥匙，就把整套流程重跑一遍。

Passkey 不是终点

软件里的私钥仍然存在被复制的可能——存在笔记本上的 Passkey 比 API Key 安全，因为私钥从不外发，但拿到机器权限的人还是能拷走文件。把密钥绑定到硬件才能关上这扇门。

登录之后的 Token 是另一个问题。如果拿到的是普通 Bearer Token，偷到就等于偷到身份，直到它过期。缩短生命周期有用，把 Token 绑定到 Agent 的密钥上更有用。

还有一件事 Passkey 永远给不了：它证明"是哪个 Agent 在调用"，但不证明"这个 Agent 在做正确的事"。行为约束靠的是所有者审批和最小权限，而不是更强的凭证。

结论

给 Agent 发凭证时，按照你早已对人要求的属性来要求它：私钥不出机器、每次登录一个新签名、服务端零秘密。首次安装用短命凭证完成，真正的密钥注册成功那一刻，引导凭证自动退役。密钥可以更强，但授权和限权，永远是另外两件事。