2026 年 5 月，Google/Alphabet Security 的两位作者 Joseph Valente 和 Michal Zalewski 在 arXiv 发布了一篇题为《Beyond Zero: Enterprise Security for the AI Era》的文章。
https://arxiv.org/pdf/2605.22985
这篇文章不算传统意义上的学术论文，它没有提出一个新的模型算法，也没有用大量实验数据证明某个检测方法有效。
它更像是一份企业安全架构宣言：当 AI Agent 开始进入企业内部系统，传统零信任架构正在被推到极限。
过去企业安全主要关心“一个人能不能访问某个应用”，现在必须关心“一个人或一个 Agent，能不能在当前上下文下，对某个具体资源执行某个具体动作”。
换句话说，Google 想把零信任继续往下推一层。
过去的零信任，是不再信任网络位置。
Beyond Zero 想表达的是：到了 Agent 时代，企业也不能再静态信任一个已经登录系统、已经拿到权限、已经通过认证的人或 Agent。
每一次动作，都要重新判断。
零信任的边界，正在从“应用”下沉到“动作”
过去十年，零信任在企业安全中已经成为主流思路。它的基本思想是，不默认相信内网，不默认相信设备位置，而是基于身份、设备状态、访问上下文等因素持续验证。
Google 很早就提出过 BeyondCorp，把传统基于内网边界的企业安全，转向基于身份和设备的访问控制。论文也明确说，Beyond Zero 是建立在 Google 2014 年 BeyondCorp 模型之上的进一步扩展。
但 Agent 出现之后，原来的模型开始不够用了。
原因很简单：人类访问系统，速度是人的速度；Agent 访问系统，速度是机器的速度。一个员工一天可能打开几十份文档，一个 Agent 可以在极短时间内读取、整理、推理大量企业数据。
更关键的是，Agent 不是单纯“访问数据”，它会把分散在文档、邮件、知识库、代码仓库、CRM 系统里的信息聚合起来，形成新的判断和行动。
这时候，安全风险不再只来自“某个系统是否被非法登录”，而来自“合法身份在合法系统里做了不合适的事情”。
论文将 Beyond Zero 的核心变化概括为：信任边界从 application / tool 下沉到 individual action / resource，也就是从“能不能访问某个应用”，变成“能不能对某个资源执行某个动作”。
这句话很关键。
因为企业安全过去经常以应用为单位授权。比如，一个销售人员可以访问 CRM，一个客服人员可以访问工单系统，一个研发人员可以访问代码仓库。
到了 Agent 时代，这种粒度太粗了。一个 Agent 可能通过不同入口访问同一份数据：前端页面、API、MCP 工具、自动化脚本、企业搜索入口，都可能成为访问路径。
如果安全边界还停留在应用层，企业就很难回答一个真正重要的问题：这个 Agent 现在读这份文件、查这条客户数据、导出这批内容，到底是不是合理？
Agent 让企业安全面对三个新冲击
这篇文章真正想解决的，不是传统意义上的“AI 模型安全”，而是 AI Agent 进入企业后，对企业访问控制体系造成的结构性冲击。
第一个冲击，是访问频率暴涨。论文提到，AI Agent 无论是自主运行，还是作为人类员工的 Copilot，都会以远高于传统人类活动的频率访问企业资源，遗留基础设施会被每秒大量机器驱动动作的授权需求压垮。
第二个冲击，是数据消费规模暴涨。Agent 不只是打开一份文件，而是可以跨大量非结构化数据做聚合和推理。过去很多敏感数据虽然“理论上可访问”，但人类很难在短时间内全部读完、关联起来、形成行动。Agent 改变了这个前提。论文把这种变化称为对系统的“geometric shock”。
第三个冲击，是攻击路径变复杂。论文特别提到 ambient authority，也就是 Agent 继承人类用户的完整权限，甚至继承了过度授权的权限。
这个问题在企业里非常现实。
很多企业最自然的做法，是让 Agent 代表员工去完成任务。员工能访问什么，Agent 就能访问什么；员工能调用什么工具，Agent 就能调用什么工具。这样做最简单，也最容易落地。但它带来的后果是，Agent 一旦被提示注入、恶意上下文诱导，或者任务边界发生漂移，就可能带着人的权限去做用户本来没有意图做的事情。
这就是 Agent 时代最麻烦的地方：权限是合法的，身份是合法的，设备也是合法的，但动作未必合理。
传统零信任擅长回答“你是谁”“你的设备是否可信”“你有没有访问这个应用的权限”。Beyond Zero 想回答的是另一个问题：在这个具体时刻，你或你的 Agent 为什么要做这个动作？这个动作和你的任务、角色、数据敏感性、近期行为是否一致？
Beyond Zero 的核心：给企业安全装一个“上下文大脑”
论文中有一句话很值得注意：Beyond Zero 在 BeyondCorp 的身份基础上，增加了一个能够实时理解请求上下文和意图的“brain”。
这个“大脑”不是简单的大模型问答，而是一套企业安全推理系统。它要把企业里的身份信息、组织关系、项目任务、资源语义、数据敏感级别、用户行为、Agent 工具调用日志都连接起来，形成一个可用于授权判断的上下文模型。
论文把这个模型称为 Enterprise Security World Model，企业安全世界模型。它借用了自动驾驶里的 World Model 概念。自动驾驶汽车需要理解道路、车辆、行人、交通规则，企业安全系统则需要理解人、Agent、资源、任务、数据和行为模式。
这个世界模型至少要回答三个问题。
第一个问题是 Who：访问者是谁。这里的访问者既包括人，也包括 Agent。系统要知道这个人的岗位、角色、资历、所属团队，也要知道 Agent 背后的控制人是谁。
第二个问题是 What：资源是什么。系统要理解数据敏感级别、数据类型、企业资源之间的关系，甚至需要把企业资源建成语义图谱或资源模型。
第三个问题是 How：这个人或 Agent 正常应该如何工作。比如，某个员工当前任务只需要处理客户 A、B、C 的数据，那么访问客户 D 的数据就应该被视为异常。
这里有一个很重要的工程细节：Beyond Zero 不是每次访问都临时调用 AI 做复杂推理。论文明确说，由于访问时延预算很严格，很多推理必须提前完成，把非结构化信息预处理成低延迟可用的属性。
这也是这篇文章非常工程化的地方。
它没有幻想用一个大模型实时判断一切，而是把复杂推理前置，把实时授权做轻，把慢速分析和快速决策拆开。真正落地时，企业需要的不是一个“会聊天的安全大模型”，而是一套可以把 AI 推理结果沉淀成策略属性、风险属性和资源标签的安全基础设施。
四层架构：治理、事件、推理、干预
Beyond Zero 的架构由四个组件构成：Autonomous Governance、Event Intake、Reasoning Engine、Challenge Infrastructure。这四个部分形成一个连续反馈环。
第一层是 Autonomous Governance，自治治理。它负责构建和维护企业安全世界模型，把组织架构、项目管理、身份系统、资源语义等信息转成授权系统能使用的属性。它解决的是“系统是否理解企业内部世界”的问题。
第二层是 Event Intake，事件接入。它负责接入服务端日志、客户端信号和 Agent 活动日志。论文特别提到，Agent 活动包括 prompt 输入、执行计划、工具调用等信息，这些信号可以用来判断 Agent 的访问是否反映了用户意图，也是否符合企业策略。
第三层是 Reasoning Engine，推理引擎。它是 Beyond Zero 的核心。论文对它的问题定义非常直接：在我们已知的用户和资源上下文中，这个具体动作安全吗？推理引擎既支持访问时的快速策略评估，也支持对一组动作进行更慢、更复杂的异常分析。
第四层是 Challenge Infrastructure，挑战基础设施。它负责在风险不确定或风险升高时增加摩擦，而不是简单地放行或拒绝。论文中的 Challenge 包括要求用户说明为什么访问某个文件、触摸安全密钥证明人在现场、请求经理审批批量导出、做自拍检测证明操作者在机器前等。
这里可以看出 Beyond Zero 的安全观：安全系统不应该只有“允许”和“拒绝”两个按钮。更好的方式是根据风险程度施加不同强度的摩擦。低风险时减少打扰，高风险时增加验证，风险持续升高时进入 Containment，也就是更强的访问限制或隔离状态。
这有点像把传统 IAM、DLP、UEBA、SOAR 和 Agent Runtime Security 合在一起，但它们的目标不再只是事后告警，而是在每一次资源动作发生时参与授权决策。
典型场景：一个“合法但不合理”的 Rogue Agent
论文最后给了一个非常典型的例子：企业内部有一个名为 SalesGenie 的销售 Agent，它被授权读取销售报告。某一天，它尝试访问 Google Drive 中一份高度敏感的战略规划文档。
如果按照传统 BeyondCorp 检查，Agent 和发起它的人都有合法身份、合法设备证书，也都被授权访问销售报告，那么访问可能会被允许。
但 Beyond Zero 不会只看到“身份合法”。它会继续检查上下文。
发起 SalesGenie 的用户只负责东北地区金融服务客户，最近又有一些与工作任务不太相关的访问尝试。被访问的数据是公司级战略数据，通常只有战略和财务团队访问，敏感级别很高，甚至可能涉及内幕交易风险。于是 Reasoning Engine 会发现，当前工作任务和数据访问需求并不匹配。系统会要求人类用户确认这是否真的是他的意图，同时要求数据所属团队审批。如果慢速推理进一步发现外传倾向，就可能触发更强的 Containment。
这个例子非常重要，因为它说明了 Agent 安全里最常见的一类风险：不是“黑客直接入侵系统”，而是“合法 Agent 借着合法身份，做了不符合业务上下文的事情”。
这也是为什么只做 Agent 身份管理还不够。
Agent IAM 可以回答“这个 Agent 是谁，它代表谁，它拥有什么权限”。Tool Gateway 可以回答“Agent 调用工具时是否经过统一入口”。ADR 可以回答“Agent 行为是否异常，是否需要检测响应”。但 Beyond Zero 进一步把问题推到了资源动作层：这个 Agent 当前对这份资源执行这个动作，是否符合用户意图、任务边界、资源敏感性和企业策略？
这才是 Agent 进入企业系统后最核心的授权问题。
把 Agent 安全从“点状防御”推向“企业架构”
过去一年，Agent 安全领域出现了很多方向：提示注入防御、工具调用安全、MCP Server 漏洞检测、Agent 身份治理、长期记忆投毒、运行时沙箱、行为审计、Agent 安全评测。
这些方向都很重要，但很多讨论仍然是点状的。
Beyond Zero 的价值在于，它试图把这些问题放进一个统一的企业安全架构里。它不是只问“Agent 会不会被提示注入”，也不是只问“MCP 工具有没有漏洞”，而是问一个更底层的问题：当 Agent 变成企业劳动力的一部分，企业应该如何重新设计访问控制？
它给出的答案是：身份、设备、资源、任务、行为、意图、策略和干预必须进入同一个授权反馈环。
这背后有一个判断非常值得重视：Agent 时代的安全边界，不能停留在模型层，也不能停留在应用层，而要下沉到资源和动作层。
这意味着未来企业安全产品可能会出现几类变化。
IAM 会从“账号和角色管理”走向“人-Agent-任务”的三元绑定。DLP 会从“内容外发检测”走向“数据动作合理性判断”。网关会从“大模型请求转发”走向“工具调用和资源访问的统一策略执行点”。安全运营会从“事后告警调查”走向“近实时推理、挑战和隔离”。
更进一步，SaaS 服务、企业应用、数据平台、MCP 工具、Agent Runtime 都需要暴露更细粒度的策略执行点。论文也在最后呼吁行业需要开放架构、Agent 身份标准、请求注解、可插拔策略评估，以及让企业自有策略决策点成为 SaaS 服务的一等公民。
落地难点：Beyond Zero 很美，但并不轻
这篇文章的方向很清晰，但落地难度也很高。
第一个难点是企业安全世界模型很难构建。Who、What、How 看起来很清楚，但企业里的组织关系、项目边界、数据分类、文档语义、客户归属、临时任务经常是不完整、不准确、过期的。如果这些基础数据不可靠，Reasoning Engine 就可能做出错误判断。
第二个难点是低延迟和高准确率之间的矛盾。访问控制必须快，但上下文理解又天然复杂。论文提出通过预处理把复杂推理前置，这是正确方向，但它要求企业有很强的数据治理、标签治理和事件处理能力。
第三个难点是推理引擎本身会成为新的可信计算基。它既然能决定 Allow、Deny、Challenge，甚至触发 Containment，就必须可审计、可解释、可回放、可测试。否则，企业只是把过去由人工安全团队做出的判断，换成了一个更难解释的自动化系统。
第四个难点是隐私和员工监控边界。论文提出接入客户端信号、浏览器状态、本地文件访问、进程活动等信息。 这些信号对安全很有价值，但也很敏感。企业必须明确采集边界、使用目的、审计机制和员工告知机制，否则很容易从安全治理滑向过度监控。
第五个难点是行业标准还没成熟。Agent 身份如何定义，Agent 动作如何标注，用户意图和 Agent 意图如何绑定，SaaS 如何支持外部策略决策点，这些都还没有完全统一。论文也提到，NIST 已经开始 Agent Security 相关工作，并期待这些努力推动行业标准化。
所以 Beyond Zero 不是一个可以马上买来部署的单点产品，而更像是一张未来企业安全架构图。它告诉企业：如果 Agent 真要进入核心业务系统，安全体系必须提前改造。
对国内企业的启示
国内很多企业现在讨论 Agent，重点还在效率上：能不能接入内部知识库，能不能自动写报告，能不能调用业务系统，能不能替人处理流程。
这些问题当然重要，但 Beyond Zero 提醒我们，Agent 真正进入企业之后，核心矛盾会很快从“能不能做”变成“做得是否可控”。
一个 Agent 能访问多少系统，能读取多少数据，能调用多少工具，能不能把结果发给外部，能不能批量导出，能不能跨系统关联客户、合同、财务、代码、战略信息，这些问题都会变成企业安全问题。
更现实地说，企业可以先从四件事做起。
第一，给 Agent 建身份，不要让 Agent 只借用人的账号。每一次 Agent 动作都应该能追溯到具体 Agent、控制人和任务。
第二，收口工具调用入口，让 Agent 调用内部 API、MCP 工具、数据库和业务系统时经过统一网关，而不是到处直连。
第三，给核心资源补标签，包括数据类型、敏感级别、所属团队、业务范围和合规要求。没有资源标签，动作级授权就没有判断基础。
第四，建立分级干预机制，不要只有放行和阻断。对于中等风险动作，可以要求说明理由、触发二次确认、请求数据负责人审批；对于高风险动作，再进入临时隔离和安全运营处置。
这四件事还不是完整的 Beyond Zero，但已经是向 Beyond Zero 迁移的起点。
写在最后
Beyond Zero 这篇文章最值得记住的，不是某个具体技术名词，而是一个判断：
企业安全的边界正在继续收缩。
从网络边界，到应用边界，再到资源边界，最后到每一次具体动作。AI Agent 的出现，让这种收缩变得不可避免。因为 Agent 既有机器速度，又能继承人的权限，还能跨系统理解和聚合数据。它越能干，企业越不能用过去那套粗粒度授权方式来管理它。
所以，Beyond Zero 不是对零信任的否定，而是对零信任的继续推进。
过去我们说，不要相信网络位置。
现在还要补上一句：不要静态相信已经拿到权限的 Agent。
在 Agent 时代，真正可靠的企业安全，不是把 Agent 拦在门外，而是让它的每一次动作都处在可理解、可授权、可追踪、可干预的体系之中。
这可能就是 Google 想通过 Beyond Zero 传达的核心信号：企业安全正在从“谁能进来”，走向“谁在什么上下文下，可以对什么资源做什么动作”。而这条路，才刚刚开始。
