苹果让 AI 自动改密码，难点不是点按钮

Apple 在 WWDC26 展示了一个很顺手、也很敏感的功能：Passwords 应用以后不只提醒你密码弱了、泄露了，还可能直接替你去网站改掉。

按苹果目前展示的方向，在 iOS 27、iPadOS 27 和 macOS 27 中，Passwords 会借助 Apple Intelligence 与 Safari 进入网站流程，登录、生成强密码、提交修改，并保存新凭据。过程会通过 Live Activity 展示。

这件事有意思的地方不在于 AI 会不会找到“修改密码”按钮。真正的问题是：当一个代理能登录账户、访问凭据、替你更换账户控制权时，它怎么保证自己不被网页带偏？

截至 2026 年 6 月 8 日，这项功能仍处于开发者测试阶段。安全架构、支持网站范围、失败处理和用户审批模型还没有完整公开。所以现在不能断言它一定安全，也不能断言它一定危险。能判断的是，苹果把密码管理器从“提醒你”推向了“替你办”。

自动改密解决的是一个真痛点

密码管理器早就能发现弱密码、重复密码和泄露密码。苹果的 Passwords 也已经有密码监测，并强调用隐私保护方式比对泄露密码库。

卡住的是最后一步。

用户看到警告后，经常不改。不是所有人都不在乎安全，而是改密码这件事太碎：入口难找，规则不同，有的网站还要二次验证。一个人如果同时看到几十条泄露或复用提醒，很容易拖到下次再说。

自动化的价值就在这里。它能减少用户忽视泄露密码警告、拖延改密，或者继续复用旧密码的概率。对普通用户来说，这不是炫技，是把安全建议变成可完成的动作。

这里可以拿一个行业现实作对照。Google、1Password 等工具长期在做泄露提醒、强密码生成和自动填充。Safari 也支持 W3C 的 /.well-known/change-password 地址，让网站声明改密入口。

但入口标准不是改密接口。网站没有统一的“原子化改密 API”。代理还是要面对不同网页、不同表单、不同安全策略。它不是走一条干净的后台通道，而是在开放网页里办一件高影响动作。

风险来自高权限代理，而不是 AI 本身

改密不是普通网页自动化。代理一旦开始执行，就可能登录账户、读取相关凭据，并替换控制账户的秘密。

一次误判，可能让用户被锁在账户外。一次被诱导，可能碰到恢复邮箱、MFA、会话管理等更敏感设置。这里的影响不是“点错一个按钮”，而是账户控制权发生变化。

更麻烦的是，开放网页本来就是非可信输入。页面文字、脚本、广告、嵌入组件、用户生成内容，都可能影响代理判断。恶意页面、被攻陷页面，甚至一段投放在页面里的恶意广告，都可能试图让代理偏离原任务。

行业讨论浏览器代理时，提示注入一直是核心风险之一。页面可能诱导模型忽略原指令、把信息提交到错误位置，或者把失败流程解释成成功。放在改密码场景里，这些风险会被放大。

也不能把“端侧 AI”当成万灵药。端侧运行有助于隐私，但它不能让恶意网页自动变可信。真正重要的是分工：模型可以识别页面结构，但不应接触当前密码和新密码明文；填充、提交、保存，应该由受控凭据服务执行，并校验域名、账户和用户授权。

我更在意的是这条边界能不能讲清楚。AI 负责看网页，凭据系统负责拿钥匙，用户负责确认高风险动作。三者如果糊在一起，便利会变成负担。

上线前要看边界、确认和失败处理

这项功能最先影响两类人。

普通用户会少一点“知道有风险但懒得改”的负担。尤其是长期复用密码的人，自动改密能把提醒变成修复。但在正式机制说清前，谨慎用户更适合观望，不要把所有账户都交给自动流程。

企业安全和身份管理团队会更保守。员工设备上的自动改密，可能影响共享账号、业务系统、邮件客户端或遗留应用。更现实的做法，是先延后默认开启，把它放进设备管理、密码策略和审计要求里一起评估。

苹果上线前最该说明的，不是演示有多顺滑，而是几条硬边界：

Live Activity 能告诉用户“正在发生”。但它不能替代事后记录，也不能替代失败回滚。

网站支持程度也会决定体验上限。支持 /.well-known/change-password 的站点能减少找入口的误差，但不能保证密码规则一致，也不能保证提交成功能被可靠验证。若苹果只在少数高适配网站放行，功能会更稳，覆盖会有限。若覆盖太宽，失败和注入风险会一起上来。

所以，接下来最该看的不是自动改密能不能跑完演示，而是苹果公开多少安全边界：凭据是否隔离，风险动作是否人工确认，失败是否可恢复，记录是否可审计。

自动改密补的是密码管理器的最后一公里。可最后一公里也是最容易摔的一段。替用户省事是好事，替用户改账户控制权，就必须把栅栏先立好。