一个正在形成的共识

UberConf 2026 的安全议题中出现了一句话：

Agents must earn autonomy rather than start with it.
（Agent 必须挣得自主权，而不是一开始就拥有它。）

这句话来自 UberConf 2026 的 Agent Governance 分享。它不是技术建议，而是工程原则——和”最小权限原则”一样，正在成为 Agent 工程的默认约束。

为什么”挣得自主权”是正确的原则

1. Agent 的 blast radius 比传统服务大得多

传统微服务的 blast radius 是可预测的：一个 API 调用失败，影响范围是调用链上的下游服务。

Agent 的 blast radius 是不可预测的：

  • Agent 可以调用任意工具（包括写数据库、删文件、执行 shell）
  • Agent 的行为路径不是预定义的，而是模型推理出来的
  • Agent 可以在”推理”中决定改变自己的行为目标

这意味着：Agent 的权限边界不能用 API gateway 那种”路径+方法”模型来管。

2. OAuth 2.1 token 生命周期和 Agent session 不匹配

这是 UberConf 2026 提到的一个具体问题：

OAuth 2.1 的 token 生命周期通常以小时计（1h-24h），但 Agent session 可能运行数天甚至数周。token 过期后 Agent 行为不可预测。

传统 Web 应用：token 过期 → 用户重新登录 → 继续。

Agent 应用：token 过期 → Agent 可能尝试用缓存 token 继续调用 → 失败 → Agent 可能”推理”出一个绕过方案 → 不可预测行为。

解法不是延长 token 生命周期，而是引入 gateway 级的 auth 管理：Agent 不直接持有 token，而是通过 gateway 代理所有外部调用，gateway 负责刷新和验证。

3. “Agent earn autonomy” 的 4 个阶段

UberConf 提出的分阶段自治模型：

阶段 自治程度 典型场景 约束
L0: Human-in-the-loop 每个工具调用都需人确认 写数据库、删文件、执行 shell 人工审批 gate
L1: Read-only autonomy 只读操作自主，写操作需确认 查询数据、搜索代码、调用分析 API 工具分类：read vs write
L2: Bounded autonomy 在定义的 blast radius 内自主 指定数据库的 CRUD、指定目录的文件操作 blast radius 限制（沙箱）
L3: Full autonomy 完全自主 实验性、内部工具 审计日志 + 告警

关键判断：大多数企业 Agent 应该停在 L1 或 L2。L3 只适用于内部实验工具，不应该用于面向用户的系统。

Policy-as-Code：Agent 安全的工程化

“Agent earn autonomy”不是靠文档和规范约束的，而是靠 Policy-as-Code。

什么是 Policy-as-Code

和 Infrastructure-as-Code 一样：Agent 的权限策略用代码定义，自动执行，版本管理。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
# 示例：Agent 权限策略
agent: code-reviewer
level: L1  # Read-only autonomy

allowed_tools:
  read:
    - git.diff
    - sonarqube.scan
    - filesystem.read  # 限定目录
  write:
    - git.comment       # 只能写评论
    - none              # 不能改代码

blast_radius:
  filesystem:
    allowed_paths:
      - /tmp/code-review/*
    denied_paths:
      - /etc/*
      - ~/.ssh/*
  database:
    allowed_tables:
      - code_review_history
    denied_tables:
      - user_data
      - payment

audit:
  log_all_tool_calls: true
  log_all_reasoning: true
  alert_on:
    - denied_tool_attempt
    - blast_radius_violation

这和 MQ + Agent 事件总线有什么关系

在之前的文章 MQ 在 AI 后端的新角色：从异步解耦到 Agent 事件总线 里，我讨论了 MQ 作为 Agent 事件总线。现在需要补充一个安全维度：

MQ 是 Agent 安全治理的天然切入点：

  1. 所有 Agent 工具调用走 MQ：Agent 不直接调用工具，而是发消息到 MQ，由 gateway 消费并执行。这样可以：

    • 在 gateway 层做权限校验
    • 记录完整的审计日志
    • 限流和熔断

  2. MQ 消息携带 policy context：每条消息附带 Agent 的权限级别和 blast radius，consumer 根据策略决定执行还是拒绝。

  3. 死信队列作为安全网：被策略拒绝的操作进入死信队列，人工审查后决定是否放行。

1
2
3
Agent → MQ（带 policy context）→ Policy Gateway → Tool执行
                                    ↓ 拒绝
                                 死信队列 → 人工审查

3 个你必须现在就做的安全检查

不管你用的是 Spring AI、Spring AI Alibaba 还是 AgentScope：

检查 1：你的 Agent 能调哪些工具？

1
2
// 列出你的 ChatClient 注册的所有工具
chatClient.defaultTools()  // 你知道这里有多少个吗？

如果你的 Agent 注册了 50 个工具，其中包含写数据库、删文件、执行 shell——那你的 blast radius 就是”整个系统”。

建议：按场景拆分 Agent，每个 Agent 只注册该场景需要的工具。用 ToolSearch（参考 Spring AI 2.0 ToolSearch 实战）做按需加载。

检查 2：你的 Agent 执行代码在沙箱里吗？

如果你的 Agent 有 ShellTools 或 FileSystemTools，问自己：

  • 它能执行的命令有限制吗？
  • 它能读写的目录有限制吗？
  • 它执行失败后会怎样？

AgentScope Java 2.0 内置 Sandbox 组件。Spring AI 目前没有——你需要自己实现（用 Docker 容器或 OS 级 sandbox）。

检查 3：你能审计 Agent 的每一个决策吗？

1
2
3
4
5
6
7
8
// 你能做到这个吗？
List<AgentDecision> decisions = agent.getDecisionLog();
// 每个决策包含：
// - 何时做的推理
// - 选了哪个工具
// - 传了什么参数
// - 返回了什么结果
// - 为什么选这个工具而不是另一个

如果你的 Agent 没有决策日志，出了问题你无法追溯。没有审计的 Agent 就是一个黑盒。

更新已有判断

在之前的文章里，我写过：

“MQ 在 Agent 架构中的角色升级为事件总线——从异步解耦到 Agent 编排。”

需要补充安全维度：

MQ 在 Agent 架构中的角色不只是事件总线，还是安全治理层。所有 Agent 工具调用通过 MQ 路由，可以在消费端做策略校验、审计日志和 blast radius 控制。这是 Agent 安全治理的工程化路径。

这意味着什么

  1. **Agent 安全治理正在从”建议”变成”工程标准”**。UberConf 2026、Spring I/O 2026 都在推这个方向。预计 2026 下半年会出现标准化的 Agent 安全框架（类似 Spring Security 之于 Web 安全）。

  2. “挣得自主权”模型会改变 Agent 设计。不再是一上来就给 Agent 所有权限，而是从 L0 开始，根据可靠性数据逐步放权。这需要一个”Agent 行为评分系统”——记录 Agent 在每个级别的成功率，作为是否升级的依据。

  3. Policy-as-Code 会成为 Agent 工程的标配。就像 K8s 的 RBAC、Spring Security 的 SecurityConfig 一样，Agent 需要一个 PolicyConfig 来定义权限边界。

参考链接