零信任解决的是“每次访问都要验证”的问题，但自主 AI 智能体带来了更细的安全挑战：它可能代表用户调用多个服务、读取不同资源，并根据上下文连续执行动作。Google 在最新研究中提出 Beyond Zero，将零信任模型扩展到 AI 时代，把访问决策从应用级别推进到具体资源和具体动作。
这意味着安全策略不再只回答“这个身份能否访问这个应用”，还要回答“它此刻能否对哪一个资源执行哪一种操作”。
从应用授权转向资源和动作授权
传统系统常以应用或 API 为边界配置权限。例如，一个服务账号可以访问订单系统，接下来由应用内部决定它能读取哪些订单、执行哪些操作。这种方式在服务数量较少时可行，但对能够自主规划任务的 AI 智能体来说，授权粒度可能不够细。
Beyond Zero 的核心变化，是把决策对象拆解为更小的单元：
- 主体：人、服务、AI 智能体或代表用户工作的自动化进程。
- 资源：文档、数据库记录、代码仓库、云资源或单条业务数据。
- 动作：读取、修改、删除、发送、部署或代表用户做出决定。
- 上下文：用户身份、设备状态、请求来源、时间、任务目标和当前风险。
因此，同一个智能体访问同一个系统，也不意味着它在任何情况下都拥有相同权限。读取公开文档和删除生产数据，应该是两个独立的授权判断。
静态控制与动态判断结合
仅依靠 AI 做权限判断风险很高，因为模型输出可能不稳定、难以审计，也可能受到提示注入影响。仅依靠静态规则又难以覆盖智能体运行时的复杂上下文。
Beyond Zero 强调将两类机制结合起来：
- 静态授权控制：使用角色、资源标签、网络边界、组织策略和显式拒绝规则，限制权限上限。
- 动态 AI 驱动决策：根据当前任务、资源敏感度、用户意图和运行上下文，决定是否允许这一次具体动作。
- 机器速度执行：授权结果应由策略引擎或执行代理即时落实，而不是依赖人工逐项审批。
- 可审计与可回放：记录主体、资源、动作、上下文、策略版本和最终决定，便于调查和复盘。
这里的关键边界是：AI 可以参与动态判断，但不应成为绕过静态安全上限的通道。动态决策只能收紧权限，不能突破明确禁止的操作。
一个可改造的最小策略示例
下面的示例是假设性的最小实现，用于展示“主体、资源、动作、上下文”如何进入一次授权判断。它不是 Beyond Zero 的官方 API，而是一种可以在内部网关或工具执行层实践的设计方式。
将代码保存为 beyond_zero_demo.py 后，可以直接使用 Python 运行：
from dataclasses import dataclass
from typing import Dict, Tuple
@dataclass(frozen=True)
class Request:
subject: str
resource: str
action: str
sensitivity: str
task_id: str
user_confirmed: bool = False
# 静态策略定义权限上限：明确禁止的动作不能交给动态模型放行。
STATIC_DENY = {
("agent:report", "prod:database", "delete"),
}
def dynamic_decision(request: Request) -> Tuple[bool, str]:
key = (request.subject, request.resource, request.action)
if key in STATIC_DENY:
return False, "blocked_by_static_policy"
if request.sensitivity == "high" and not request.user_confirmed:
return False, "explicit_confirmation_required"
if request.action == "read" and request.sensitivity in {"low", "medium"}:
return True, "allowed_for_read_only_task"
return False, "default_deny"
requests = [
Request("agent:report", "docs:quarterly", "read", "medium", "task-001"),
Request("agent:report", "prod:database", "delete", "high", "task-002", True),
Request("agent:report", "prod:database", "update", "high", "task-003"),
]
for item in requests:
allowed, reason = dynamic_decision(item)
print({
"task_id": item.task_id,
"subject": item.subject,
"resource": item.resource,
"action": item.action,
"decision": "allow" if allowed else "deny",
"reason": reason,
})
这个示例体现了三个实践原则：删除生产数据的动作被静态策略直接拒绝；高敏感资源需要额外确认；没有被明确允许的动作默认拒绝。生产环境还需要补充真实身份验证、策略版本、审计日志、重放保护和工具调用隔离。
将模型放在决策链中的边界
动态 AI 决策适合处理复杂上下文，例如判断请求是否符合当前任务范围，或者识别一次工具调用是否偏离了用户目标。但模型不应该直接返回一个没有约束的“允许”结果。
可以把决策链设计成以下形式：
请求进入执行层
-> 验证主体身份和令牌
-> 检查静态策略上限
-> 提取资源敏感度与动作风险
-> 进行动态上下文判断
-> 应用最小权限和显式拒绝
-> 执行动作或拒绝
-> 写入结构化审计日志
对于发送邮件、修改权限、发布代码、删除数据等不可逆操作，还应考虑分级控制：低风险读取可以自动执行；中风险写操作需要更严格的上下文校验；高风险或不可逆操作需要用户确认或人工审批。
提示注入也必须纳入边界设计。来自文档、网页或邮件的文本只能作为不可信输入，不能直接改变系统策略、工具权限或主体身份。策略引擎应在模型上下文之外保留一份不可被提示内容覆盖的授权约束。
采用时的检查清单
落地类似 Beyond Zero 的模型时，可以从以下问题开始：
- 每个工具调用是否明确记录了主体、资源和动作？
- 权限是否已经细化到资源和动作，而不是只停留在应用级别？
- 静态策略能否阻止高风险动作，即使模型给出允许建议？
- 动态判断是否默认收紧权限，而不是扩大权限？
- 高敏感资源和不可逆动作是否要求确认？
- 是否保存了策略版本、模型判断依据和最终执行结果？
- 智能体是否使用短时令牌，并限制令牌的资源范围和动作范围？
- 是否能在不影响生产数据的环境中回放和测试授权决策？
Beyond Zero 的价值不在于简单地给 AI 增加一层身份认证，而在于重新定义访问控制的颗粒度。对人和机器统一采用资源级、动作级、上下文感知的授权，才能让自动化速度与安全边界同时得到控制。实际采用时，应从只读场景和低风险工具开始，逐步扩展到写操作，并保留明确的拒绝、确认和审计机制。