2026 年 AI Agent 的模式已经越来越清晰了。它不再只是一个聊天窗口——而是能帮你订机票、发邮件、管理日程、操作 GitHub、调用云服务 API 的"数字代理"。

但 AI Agent 引发了一个新的安全问题：当 AI 代替你操作账号时，传统的 2FA 模型怎么工作？

问题在哪

传统 2FA 的触发逻辑是"人正在登录一个系统"→"人输入验证码"→"验证通过"。这个闭环里有两个隐含前提：

1. 触发验证的是人
2. 输入验证码的也是同一个人

当 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 的操作走另外的通道，不要混在一起。