当AI编码智能体被授予无缝访问用户账户的权限时，安全风险不再来自代码漏洞，而是来自信任链中一个微妙的OAuth令牌——Vercel入侵事件虽非AI所为，但它为下一场真正的AI安全灾难画好了蓝图。

核心观点：Vercel入侵事件并非AI攻击，但它揭示了当前所有AI编码智能体共享的OAuth授权模型存在结构性缺陷，下一次此类攻击将不是“是否”而是“何时”，这要求整个行业重新思考AI代理的权限边界和安全架构。

科技界对安全事件的反应往往带有一种自我安慰式的分类学：如果攻击者没有使用机器学习模型，那它就算不上AI攻击。这种分类法在Vercel入侵事件中表现得淋漓尽致。过去几天，一名Vercel员工授权第三方AI工具Context AI访问其Google Workspace，随后Context AI的AWS环境被攻破，存储的OAuth令牌被窃取，攻击者借此通过该员工的Workspace渗透进了Vercel的部分内部系统。Mandiant和CrowdStrike被紧急动员。舆论迅速将其定性为“传统的第三方供应链攻击”，从而松了一口气：看，这不过是又一次OAuth令牌泄露，和AI无关。

但这种分类法掩盖了真正的问题。Context AI不是普通的CRM插件或邮件工具，它存在的全部意义就是让AI代理能够跨应用代表用户行事。它不是被动地读取数据，而是主动地执行行动。当这样一个工具被攻破时，受损的不仅仅是一组凭据，而是一个可以模拟用户意图的数字代理人。这次入侵虽非AI所为，但它直接发生在AI代理的授权链条上。攻击者利用了AI工具所依赖的信任机制，而这个机制的设计初衷正是为了让AI能够“自动地做事情”。换句话说，AI代理的便利性就是它的安全漏洞。

更令人不安的是，Vercel入侵事件中使用的攻击路径——从一个第三方AI工具的AWS环境切入，窃取OAuth令牌，然后横向移动——几乎可以原封不动地用于攻击任何一款当前主流的AI编码智能体。GitHub Copilot、Cursor、Replit Agent、Devin，这些工具的工作原理大同小异：它们都需要通过OAuth获得对用户代码仓库、云服务、数据库的访问权限。一旦支撑这些工具的第三方服务遭到攻破，同样的剧本就能重演。区别只在于，下次攻击者的目标不再是Vercel的内部系统，而是直接利用AI智能体修改代码、窃取密钥、植入后门，且一切操作都会以“开发者的合法操作”为伪装。

当前AI编码智能体的安全模型建立在一种危险的乐观假设上：只要授权流程是标准的、令牌是加密的、通信是TLS的，安全就得到了保证。但这一模型忽视了AI代理的特殊性——它们不是一次性的操作工具，而是持续运行的数字实体。传统OAuth流程假设用户授权一个应用后，该应用仅在有限范围内执行有限操作。但AI代理的工作模式是：它接收一个模糊的目标（“优化这个微服务”），然后自主规划并执行一系列操作，包括读取代码、修改配置文件、部署到生产环境。这意味着AI代理需要的授权范围往往远大于人类开发者实际意图允许的范畴。

这种“授权范围膨胀”是系统性的而非偶然的。当一个AI编码智能体被告知“连接我的AWS账户”时，它通常需要读写S3、操作Lambda、管理IAM角色——这几乎等同于授予完全管理权限。人类开发者可能只想让它部署一个函数，但OAuth授权无法精细到“仅允许部署特定函数”。于是，AI代理的授权集成为攻击者的理想跳板：一旦令牌失窃，攻击者就获得了与AI代理相同的全权限。

一些读者可能会反驳：但我们可以用更细粒度的权限控制来解决这个问题。的确，AWS IAM策略可以做到极度精细，Kubernetes RBAC也能限制作用域。但问题不在于有没有能力实现细粒度控制，而在于当前的AI编码智能体产品为了追求用户体验的流畅性，主动选择了“过度授权”。它们要求用户“一键授权”，然后自己管理内部权限的细分。这种做法将安全责任从用户转移到了AI平台，而AI平台的安全成熟度又参差不齐。Context AI的AWS环境被攻破，就是这种责任转移失败的实证。

还有一个更隐蔽的风险点：AI编码智能体的“回话”机制。这些工具在执行任务过程中，会频繁与服务器通信以获取上下文、汇报进度、请求下一步指令。这些通信信道如果被中间人攻击或令牌劫持，攻击者就可以实时监控甚至修改AI代理的行为。Vercel入侵事件中，攻击者利用被窃取的OAuth令牌直接访问了员工Workspace，但更高级的场景是：攻击者不直接访问Workspace，而是在AI代理的正常通信流中注入恶意指令，让AI代理自己在合法的上下文中执行有害操作。这种攻击更难检测，因为所有操作都通过官方API进行，源IP也是合法的。

反对者可能会说，这些风险被夸大了，因为大型AI平台和云服务商拥有强大的安全团队和入侵检测系统。但历史反复证明，安全链条的强度取决于最薄弱的环节。在Vercel事件中，薄弱环节是Context AI的AWS安全配置。在未来的攻击中，薄弱环节可能是某个小型AI插件的开发者疏于维护的依赖库，或者是某个被社会工程攻破的API密钥。AI编码智能体的生态越是繁荣，攻击面就越分散。

那么，出路何在？一种激进的方案是“无授权”架构——AI代理不直接持有任何永久性令牌，而是通过人类在环（human-in-the-loop）每次批准具体操作。但这种方式会严重损害AI编码智能体的核心价值：自主性。一个每次改动代码都要求弹窗确认的智能体，本质上和传统IDE的自动补差不了多少。另一种折中方案是“时间盒授权”——令牌仅在任务执行期间有效，完成后自动撤销。这能减少令牌泄露后的攻击窗口，但不能阻止任务期间的即时攻击。

我认为，真正有效的解决方案需要从两个层面入手。第一，AI平台必须采用“最小可行权限”（least viable privilege）原则，并且是默认强制执行、不可由用户随意放宽的。这意味着AI编码智能体的授权请求应该具体到操作级别，例如“读取仓库A的main分支代码，写入仓库B的feature分支”，而不是笼统的“访问您的GitHub仓库”。第二，AI代理的通信协议应该引入“操作签名”——每个由AI代理发出的API请求都必须附带该代理的身份签名，便于后端审计和异常检测。如果GitHub API发现一个请求来自“Cursor代理”但操作对象是生产环境的数据库，可以触发额外的验证步骤。

Vercel入侵事件是一记警钟。它不是AI攻击，但为AI攻击提供了完整的路线图。下一次，当某个AI编码智能体被用于攻击其用户自己的系统时，我们不能再以“这次不是AI”来安慰自己。安全行业必须认识到，AI代理的信任模型不是传统的应用授权模型的子集，而是一个全新的类别，需要全新的防御范式。否则，我们正在亲手构建一个金库，然后把钥匙交给一个我们尚未完全信任的管家。