零信任解决的是“默认不信任、持续验证”的访问问题，但自主 AI 代理把问题推向了更细的粒度：一个代理可能代表用户读取邮件、修改代码、调用支付接口，甚至连续执行数十个工具动作。Google 在 BeyondCorp 之后提出 Beyond Zero，将零信任扩展到 AI 时代，核心变化是把访问决策从“应用能不能访问”推进到“某个主体能否对某个资源执行某个动作”。
这不是简单地给 AI 代理增加一个角色，而是要让每一次具体操作都经过授权，并结合静态策略与实时上下文，在机器速度下完成判断。
从应用级权限到动作级授权
传统权限模型经常围绕应用或服务展开。例如，用户拥有工单系统的访问权限，应用随后决定用户能看到哪些工单、能执行哪些操作。这个模型面对自主代理时容易出现权限过宽的问题：代理一旦拿到应用级访问权，就可能在应用内部连续执行超出原始意图的动作。
Beyond Zero 所强调的方向，是把决策对象拆成更小的单元：
- 主体：人、服务、AI 代理或代理代表的用户。
- 资源：单个文件、数据库记录、代码仓库、云资源或业务对象。
- 动作：读取、创建、修改、删除、部署、发送或付款。
- 上下文：请求来源、时间、设备状态、任务目的、风险等级和审批状态。
这种拆分让策略能够表达“允许代理读取这份文档”，而不是笼统地表达“允许代理访问文档系统”。对代理来说，身份本身不再等于权限，权限必须绑定到具体动作和资源。
静态规则加动态判断
仅靠静态 RBAC 或 ACL 很难覆盖代理执行时的复杂上下文。一个代理可能在工作日、受控环境中读取项目文档，但在异常 IP、敏感数据或高风险动作下需要拒绝或转人工审批。
因此可以把授权拆成两层：
- 静态控制负责稳定边界，例如主体类型、资源标签、动作集合和组织级禁止规则。
- 动态判断负责请求当下的上下文，例如任务是否符合用户意图、风险是否升高、是否需要人工确认。
动态判断可以由规则引擎、风险服务或 AI 模型提供，但最终结果应当落在明确的决策集合中，例如 allow、deny 和 require_approval。不要让模型直接返回一段自然语言并由调用方自行解释，否则不同客户端可能产生不一致的授权结果。
一个可改造的最小授权决策器
下面的示例是一个本地可运行的简化实现，用来展示资源级、动作级授权的结构。它不是 Beyond Zero 的官方 SDK，也没有实现生产级身份验证；真实系统需要接入可信身份、策略存储、审计日志和独立的风险评估服务。
将代码保存为 policy_demo.py 后运行 python policy_demo.py。示例把读取项目文档视为低风险动作，把删除文档视为高风险动作，并要求高风险操作经过审批。
from dataclasses import dataclass
from typing import Literal
Decision = Literal["allow", "deny", "require_approval"]
@dataclass(frozen=True)
class Request:
subject: str
subject_type: str
resource: str
resource_label: str
action: str
risk_score: int
approved: bool = False
def authorize(request: Request) -> Decision:
# Static boundary: unknown agents and sensitive resources are denied.
if request.subject_type != "ai_agent":
return "deny"
if request.resource_label == "restricted":
return "deny"
if request.action not in {"read", "update", "delete"}:
return "deny"
# Dynamic decision: high-risk actions require explicit approval.
if request.action == "delete" or request.risk_score >= 70:
return "allow" if request.approved else "require_approval"
return "allow"
requests = [
Request("agent-build", "ai_agent", "doc-123", "internal", "read", 15),
Request("agent-build", "ai_agent", "doc-123", "internal", "delete", 80),
Request("agent-build", "ai_agent", "doc-999", "restricted", "read", 10),
]
for item in requests:
print(item.action, item.resource, "=>", authorize(item))
预期输出类似：
read doc-123 => allow
delete doc-123 => require_approval
read doc-999 => deny
在真实服务中，可以继续把 authorize 拆成策略评估、动态风险评估和审计三个组件。每条决策至少记录主体、资源、动作、上下文摘要、决策结果和策略版本，这样出现误授权时才有机会还原现场。
机器速度不等于无限放权
Beyond Zero 的价值在于把授权检查放到代理的每个关键动作上，并让策略能够自动执行。但“机器速度”也带来新的风险：错误策略会在很短时间内扩大影响，模型产生的错误意图判断可能触发连续操作，代理之间还可能互相调用形成权限链。
落地时应明确几条边界：
- 对删除、支付、生产部署等不可逆动作设置硬性审批或双人确认。
- 给代理使用短时、窄范围的令牌，不要复用用户的长期高权限凭据。
- 将工具调用限制在明确的资源集合和动作集合内。
- 为拒绝、审批和允许都保留可检索的审计记录。
- 对授权策略做回放测试，验证策略升级不会扩大代理权限。
- 把“代理代表谁执行”与“代理自身是什么身份”分开记录。
采用清单
Beyond Zero 可以理解为零信任在自主代理场景下的进一步细化，而不是替换现有 IAM、RBAC 或网络控制。比较稳妥的采用路径是从高价值、高风险工具开始：先为每个工具定义资源和动作，再建立静态禁止规则，随后接入上下文风险判断，最后补齐审批、审计和策略回放。
评估一个代理系统是否真正具备这种能力，可以问三个问题：它能否精确回答“谁对哪个资源执行了什么动作”；高风险动作是否有独立的动态判断；策略变化后是否能证明权限边界没有被意外扩大。若这三个问题都能得到可验证的答案，零信任才真正从应用入口延伸到了代理执行链路。