AI 应用将 Google Workspace 信任转化为现代攻击链

尽管多年来密码不断强化、多重身份验证得到普及，钓鱼防护也有所改善，Google Workspace 安全仍走到了一个冲突点。对安全团队而言，最新的 Google 新闻关注的是攻击者无需直接窃取的访问权限：他们可以通过获批的 AI 应用、被攻破的浏览器会话，或被遗弃的 OAuth 令牌继承这些权限。

这种区别改变了防御问题的本质。安全项目历来专注于在登录界面阻止攻击者，而现代攻击越来越多地始于 Google 已视为已授权的访问。

AI 工具加剧了这种矛盾，因为它们需要广泛连接才能提供有用的答案并执行操作。一个助手可能会读取 Gmail、搜索 Drive、查看 Calendar，并将发现的信息传输到另一项服务。每一项连接都会建立信任关系，即使用户更改密码后也可能继续存在，并在没有明显用户交互的情况下保持活跃。

眼前的教训并非每个 AI 工具都是恶意的，而是授权已成为企业边界的一部分。Material Security 最近的一项分析经 BleepingComputer 放大传播后指出，许多组织仍将其视为行政管理中的背景噪声。

2026 年 4 月的 Vercel 事件表明，这种做法已不再足够。根据围绕该事件披露的信息，攻击者首先攻破了一家第三方 AI 提供商，随后利用其已获授权的连接进入一名 Vercel 员工的 Google Workspace 账户。

这次攻击并不符合有人攻破 Vercel 登录防御的常见叙事。信任通过用户此前批准的集成跨越了组织边界。

Google 新闻的焦点从被盗密码转向继承的访问权限

关键变化并非出现了新的 Google 漏洞，而是利用合法访问权限的方式变得更有效。

OAuth 是一种授权框架，允许一个应用访问另一项服务中的特定资源。例如，它可让日程安排工具读取日历，而无需获得用户的 Google 密码。

这种分离带来了实际的安全优势。用户无需向每项连接服务共享凭据，管理员也可以限制应用、审核所请求的权限范围，并撤销授权。

同一模式也形成了有价值的攻击目标。OAuth 令牌代表已经通过审批流程的权限。任何窃取或控制该令牌的人，都可以在其获授权限范围内通过获批应用执行操作。

Material Security 的 OAuth 风险报告审查了生产环境中的 Google Workspace，并发现了庞大且分散的授权面。其公开发现显示，每家公司 OAuth 应用连接数的中位数为 1,807 个。

该报告还称，在观察到的授权中，47.2% 已超过 90 天未被使用。在这些休眠授权中，仍有 1,526 个保留了对 Gmail 的完全访问权限。

这些数据来自一家安全供应商的客户数据集，而非涵盖所有 Workspace 租户的代表性普查。公司规模、行业和现有安全成熟度都会影响总量。不过，这些发现仍揭示了一个结构性问题：旧授权在其业务目的消失后，往往仍然有效。

AI 的采用加速了这种累积。Material 在其 AI 和自动化类别中归类了 356 个公开应用，并表示其中 325 个是在 2024 年 1 月 1 日之后首次出现在所分析环境中的。

这意味着，观察到的 AI 应用群体中有 91% 在 16 个月内出现。据称，其中超过一半的应用拥有敏感或受限权限范围。

权限范围定义了应用可以访问或更改的内容。宽泛的权限可能允许应用读取电子邮件、查看 Drive 内容、发送消息或删除信息。

因此，组织面临艰难的分类问题。对 Drive 访问权限的请求可能支持一款有用的研究助手；但如果应用遭到攻破，同一权限也可能暴露合同、战略文件、凭据和客户记录。

威胁并不要求应用从一开始就是恶意的。合法提供商也可能在员工设备、开发者账户、签名密钥或云环境遭到入侵后成为入口点。

这种可能性使日常应用审批变成了供应链决策。用户看到的是同意授权页面，但组织继承的是提供商未来可能发生的安全失误。

一个被攻破的 AI 工具可跨越两道安全边界

Vercel 事件说明，攻击者如何能通过 AI 供应商，而非直接攻击最终目标来横向进入。

Vercel 披露，2026 年 4 月发生了一起安全事件，涉及一款被攻破的第三方 AI 工具以及一名员工的 Google Workspace 账户。公开报道将该提供商认定为 Context.ai。

根据现有披露，一名 Vercel 员工使用企业身份连接了 Context.ai 的 AI Office Suite。该连接获得了广泛的 Google Workspace 权限。

随后，威胁行为者控制了 Context.ai 持有的相关访问权限。据报道，这一访问为进入该员工的 Workspace 账户、继而进入 Vercel 内部系统提供了路径。

这一过程形成了两层相连的供应链暴露。Context.ai 依赖其自身的员工身份和基础设施；而 Vercel 则依赖 Context.ai OAuth 应用的完整性。

独立研究人员将 Context.ai 的最初失陷归因于信息窃取器感染。信息窃取器是一种旨在收集密码、浏览器 Cookie、令牌及其他身份验证材料的恶意软件。

相关报道将该感染与伪装成 Roblox 漏洞利用工具的软件联系起来。不过，Vercel 并未独立确认最初失陷的所有细节。

Vercel 所确认的事实对企业规划更为重要：第三方应用既有的授权帮助攻击者进入了一名员工的企业 Workspace 账户。

据报道，攻击者访问了未被标记为敏感的环境变量。Vercel 建议受影响客户审计活动并轮换已暴露的凭据。

一篇同期报道称，攻击者曾索要被盗数据的赎金。Vercel 聘请了 Mandiant、通知执法部门，并联系了数量有限的受影响客户。

Vercel 还表示，敏感环境变量已进行静态加密且未被访问。其开源项目，包括 Next.js 和 Turbopack，据称未受影响。

不应将这一事件简单归结为 OAuth 本身失效。OAuth 执行了用户和管理员已允许的授权。

失效出现在整个信任链中：提供商遭到攻破，应用持有广泛访问权限，而这些权限又通向高价值的企业身份。

传统登录防御只覆盖了这一链条的一部分。一旦可用授权存在，攻击者就无需重复最初的同意授权决策。

更改密码也可能不会撤销某些应用授权。这使响应工作比重置凭据和关闭活跃浏览器会话更复杂。

团队必须识别哪些令牌存在、它们持有哪些权限范围，以及哪些连接应用仍可执行操作。随后，他们必须在不破坏必要业务流程的情况下撤销访问权限。

这正是现代攻击链的核心逆转：原本旨在减少密码共享的应用，可能成为绕过以密码为中心防御体系的持久路径。

AI 代理让熟悉的 OAuth 记录提供的信息更少

AI 代理在授权日志中可能看起来很普通，但其行为远比传统集成难以预测。

传统应用通常执行一组范围有限的功能。文档签署服务可能会获取文件、收集签名，然后返回完成的副本。

它的行为可能改变，但管理员仍可将所请求的权限与相对稳定的用途进行比较。对于此类服务而言，过度的 Gmail 或 Calendar 访问权限应当显得可疑。

AI 代理并不遵循同样的行为模型。它的下一步操作可能取决于用户提示、检索到的内容、可用工具、模型输出，以及由外部系统传递的指令。

在授权层面，这些差异可能消失。授予 AI 助手的只读 Drive 权限，看起来可能与授予固定文档工具的权限无异。

Material 的代理分析认为，安全信号正从授权本身转向授权后的行为。供应商身份和权限范围仍然有用，但无法完整描述通用代理将会执行什么操作。

通常称为 MCP 的 Model Context Protocol，可能会进一步增加这种不确定性。MCP 是一种用于将 AI 系统与工具和外部数据源连接起来的标准。

一个接入 MCP 的代理可能会搜索 Workspace、将选定内容传递给另一项工具、进行总结，并触发后续操作。一个用户请求中的工作流可能跨越多项服务。

这带来了同意授权页面无法回答的若干安全问题。管理员需要知道代理实际访问了哪些信息、将这些信息发送到哪里，以及其活动是否符合用户意图。

提示词注入又增加了一层风险。提示词注入是指不受信任的内容操纵 AI 系统的指令或工具使用方式。

代理可能会在电子邮件、共享文档、日历条目或网页中遇到恶意指令。如果它将这些内容视为指令，其合法权限可能就会成为有害活动的执行机制。

这种风险不同于经典恶意软件。用户设备上未必会落地可执行文件，AI 提供商也可能没有遭到攻破。

相反，系统可能在处理对抗性内容时滥用有效工具。安全控制必须区分已获授权的自动化与行为危险的已获授权自动化。

这并不意味着每个已连接代理都需要对提示词或私人内容进行不受限制的监控。过度监控本身会带来隐私、合规和治理风险。

这意味着组织需要活动层面的证据。有用信号包括异常下载量、新出现的转发行为、快速枚举邮箱、意外的服务组合，以及超出用户正常模式的访问。

AI 还增加了需要审核的连接数量。员工可以直接采用各类助手，往往早于采购或安全团队对其进行评估。

一个知名品牌名称并不能保证同意授权页面上的应用确实属于该品牌。Material 的报告描述了一款名为“gamma.com.ai”的应用，它与合法的 Gamma 演示服务相似。

Material 表示，该发布者与 Gamma 无关，并在多个客户环境中寻求访问权限。报告将此案例描述为 OAuth 冒充，即视觉上的熟悉感促使用户批准授权。

授权页面仍显示了域名和所请求的权限。人为决策之所以失败，是因为熟悉的名称降低了审查力度。

这一路径无需伪造密码页面。它诱使用户向错误的一方提供合法授权。

MFA 保护登录，而非登录后的每一项决策

多重身份验证依然至关重要，但它无法验证一次成功登录之后的每一个令牌、应用程序和浏览器操作。

MFA 能阻挡许多基于密码的攻击，因为仅凭被盗密码并不足以完成登录。包括通行密钥和硬件安全密钥在内的抗钓鱼方法，能够更有效地抵御实时凭据转发。

Google 已在 Workspace 中扩展通行密钥支持和管理控制功能。这些措施降低了传统账户接管的风险敞口。

但 OAuth 同意通常发生在身份验证之后。用户正确登录、完成 MFA，然后批准某个应用程序。

生成的令牌记录的是一项已获授权的决策。重复使用该令牌时，未必会再次触发相同的身份验证挑战。

浏览器会话窃取造成了类似缺口。会话 Cookie 是让服务识别此前已通过身份验证的浏览器的数据。

窃取有效 Cookie 的攻击者可能会继承这一已验证状态。Google 提供了用于调查可疑会话并强制退出登录的会话 Cookie 响应流程。

应用程序令牌与浏览器会话并不相同。但两者都表明，登录事件不能定义整个安全边界。

攻击者还会利用对手中间人钓鱼（即 AiTM），通过实时伪造会话转发凭据和第二验证因素。这种技术可捕获成功完成 MFA 后生成的已验证会话。

抗钓鱼身份验证提高了攻击难度，因为凭据在密码学层面与合法网站绑定。组织仍应假定，恶意软件、遭入侵的应用程序和被盗令牌可能形成其他攻击路径。

Microsoft 曾记录涉及受信任身份提供商 URL 的 OAuth 重定向滥用。这些活动通过操纵协议参数或已连接的应用程序，将受害者引导至攻击者控制的目的地。

这一更广泛的模式并不只影响 Google。Microsoft 365、Salesforce、云开发平台和数据服务都依赖令牌及第三方集成。

多起重大攻击活动都曾瞄准这些信任关系。涉及 Salesloft Drift 的事件显示，被盗的集成令牌如何能够为后续访问客户环境提供入口。

这一比较很重要，因为它排除了“仅限 Google”的解释。企业软件正日益演变为一个由委托信任构成的图谱。

防御者必须保留 MFA，同时扩展安全模型。身份验证回答的是某个身份是否完成了登录要求；授权回答的是该身份或其连接的应用程序之后能够执行什么操作。

安全团队还需要考虑持久性。撤销一个浏览器会话并不必然撤销应用程序授权。停用用户账户后，仍可能保留需要单独调查的已连接访问权限。

事件响应计划应明确列出这些操作。否则，团队可能重置密码、关闭会话，并错误地认为访问已经终止。

这种扩展后的响应在运营上要求很高。大型组织可能拥有数千项授权、服务账号、委托权限和自动化工作流。

撤销所有权限并不是可信的长期政策。这会中断生产力，并促使员工寻找更难以察觉的替代方案。

可辩护的目标是选择性信任。团队应识别应用程序、验证发布者、限制权限范围、监控行为，并在访问目的到期时移除权限。

权衡的是有用的 AI 与未经衡量的信任

封锁所有集成虽然会降低一种风险，却会摧毁让企业 AI 发挥价值的互联工作流。

AI 助手需要上下文，才能超越泛泛而谈的回答。起草客户更新的助手可能需要访问电子邮件、会议记录、账户历史和项目文档。

将其限制在空白聊天窗口中可以降低风险敞口，但也会移除员工期望从企业 AI 获得的大部分价值。

因此，组织面临的是权衡，而不是非黑即白的安全决策。它们必须允许有用的访问，同时避免授权无限累积。

第一步是可见性。管理员需要获得覆盖整个域的应用程序、授权、用户、权限范围、发布者和近期活动清单。

该清单应区分公开的第三方应用程序与内部工具，还应识别与离职员工、承包商、测试账号和已停用项目相关的授权。

仅审查名称远远不够。团队应验证发布者身份、应用程序域名、重定向位置、所请求的权限范围，以及该工具是否完成相关的平台验证。

验证并非永久保证。合法供应商仍可能在获批后遭到入侵、被收购或发生变化。

权限范围控制提供了另一层防护。应用程序应仅获得完成明确工作流所需的最低权限。

除非存在明确需求，转录服务不应获得完整的 Gmail 访问权限。仅搜索特定 Drive 文件夹的助手，也不应自动获得所有文件的访问权限。

时间同样重要。为评估而授予的访问权限，应在评估结束后到期。组织应避免将临时实验变成永久凭据。

Google 管理员可以限制第三方应用程序访问，并将服务分类为受信任、受限或已阻止。这些控制措施在有能够跟上员工节奏的审批流程支持时效果最佳。

耗时数周的审查系统会将采用行为推向地下。只因名称熟悉便批准、却不审查权限的系统，则会造成授权泛滥。

行为监控能够应对审批无法预测的问题。团队应检测应用程序是否突然读取更多数据、访问异常用户，或开始执行新的操作。

这对 AI 代理尤其重要。它们的通用能力使静态描述不再是判断预期行为的可靠指标。

Cloud Security Alliance 的研究将 AI SaaS OAuth 链条视为系统性的企业攻击面。其信任链分析将 Context.ai 事件与其他下游令牌泄露联系起来。

该报告认为，企业应将 OAuth 生命周期管理视为一项核心安全职能，包括签发、盘点、监控、轮换、撤销和事件响应。

安全团队仍应谨慎看待供应商统计数据。Material 销售 Workspace 安全产品，其研究也支持了其平台所应对的问题。

不过，其数据集仍为任何组织提供了可验证的问题。管理员可以衡量自身的授权数量、闲置授权占比、敏感权限范围、AI 应用程序增长情况以及撤销缺口。

最有力的响应来自公司自身租户中收集的证据。本地审计可以确认报告所述模式是否适用，以及最高风险连接位于何处。

安全团队接下来应关注什么

三个信号将表明 Workspace 防御是在适应 AI 时代的授权，还是仅仅增加了另一个仪表板。

第一个信号是 Google 和安全供应商是否提供更好的授权后可见性。管理员需要的不只是显示某个应用程序获得了特定权限范围的记录。

他们需要能够实际使用的答案，了解该应用程序之后的活动。这包括它访问了哪些资源、其行为模式如何变化，以及数据是否在已连接服务之间流动。

Google 已提供调查和访问控制能力，但覆盖范围取决于版本、配置和可用遥测数据。关键检验在于，团队能否在无需从多个无关控制台拼凑证据的情况下追踪 AI 代理的操作。

如果活动级调查变得更加清晰，本文描述的安全模型就会获得实际支持。如果日志仍围绕初始同意，防御者将继续通过静态元数据来评估动态代理。

第二个信号是 AI 供应商如何收窄和管理权限。成熟的产品应说明每项权限范围为何必要，并以更小的授权足迹提供有用的工作流。

它们应支持选择性数据源、在可行情况下使用短期访问、快速撤销，以及透明的工具活动记录。它们还应将面向用户的自动化与高风险管理操作分开。

默认提供宽泛权限会削弱市场正在从近期事件中吸取教训的说法。更细粒度的控制则表明，供应商已认识到授权是产品设计问题。

第三个信号是组织是否在日常安全工作中衡量 OAuth 风险敞口。每年一次的审查无法匹配员工采用 AI 工具的速度。

团队应追踪闲置授权、新发布者、敏感权限范围、已离职用户，以及应用程序行为的突变。这些指标应出现在定期的身份和云安全审查中。

事件演练也应测试第三方令牌泄露。响应人员必须知道如何识别受影响用户、撤销授权、关闭会话、轮换下游密钥并保留证据。

最新的 Google 新闻并不能证明 Workspace 已变得本质上不安全。它表明，围绕登录保护建立的安全假设，已无法覆盖通往企业数据的完整路径。

密码和 MFA 仍然必不可少。只是当员工授权应用程序跨电子邮件、文件、日历和连接系统执行操作时，它们已不再是最终控制措施。

更困难的问题是，组织能否在不阻碍有用工作的前提下，看见并治理这些委托活动。安全负责人应从一项直接的衡量开始：现在有多少已连接应用程序能够访问公司数据，以及每一项决策仍由谁负责？