2026 年 AI Agent 的模式已经越来越清晰了。它不再只是一个聊天窗口------而是能帮你订机票、发邮件、管理日程、操作 GitHub、调用云服务 API 的"数字代理"。
但 AI Agent 引发了一个新的安全问题:当 AI 代替你操作账号时,传统的 2FA 模型怎么工作?
问题在哪
传统 2FA 的触发逻辑是"人正在登录一个系统"→"人输入验证码"→"验证通过"。这个闭环里有两个隐含前提:
- 触发验证的是人
- 输入验证码的也是同一个人
当 AI Agent 介入时,这两个前提都被打破了。Agent 可能在凌晨 3 点发了一个 API 请求,触发了云平台的 MFA 验证。但你在睡觉,没有人去输验证码。Agent 卡住了。
目前的三种解决思路
思路一:给 Agent 配独立的 Service Account。
不让人和 Agent 共用一个账号。Agent 用自己的 Service Account + API Key 操作,人的账号独立开来。人的账号开 MFA,Agent 的账号通过 API 网关做速率限制和审计。
这是目前最成熟的方案。GCP 的 Service Account、AWS 的 IAM Role、GitHub 的 Machine User 都是这个思路。
思路二:短期信任令牌。
人在登录时完成 MFA 验证,系统签发一个短期有效的信任令牌给 Agent。Agent 在有效期内可以直接操作,过期后需要人重新验证。
OAuth 2.0 的 refresh token 机制就是类似的逻辑。但有一个问题------如果 Agent 在凌晨 3 点 Token 过期了,还是需要人来介入。
思路三:持续行为验证。
不再依赖"登录时验一次"的模式,而是对 Agent 的每一次操作做持续的行为评估。Agent 访问了它平时不会访问的资源?触发额外验证。Agent 的操作量突然暴增?限制速率。
零信任架构里的"持续验证"就是这个方向,但对 AI Agent 做了适应性延伸。
对普通开发者来说现在怎么做
AI Agent 还没完全普及,但 AI 编程工具(Cursor、Claude Code、Copilot)已经在日常工作中广泛使用了。现在的做法比较务实:
给你的 GitHub 配 SSH Key。 Agent 通过 SSH Key 操作 Git 不会触发 2FA。但网页登录和敏感操作仍然走 MFA 保护。
关键操作的 API Key 单独创建、最小权限。 不要让 Agent 拿你的管理员权限的 AccessKey。给它单独创建一个只读或有限写权限的 Key。
你的 2FA 保护人的操作,Agent 的操作走审计日志。 微信小程序「二次验证码Free2FA」可以在你自己的日常登录中做 TOTP 验证。Agent 的操作走另外的通道,不要混在一起。