---
title: "为了让agent更安全的工作，有多少人操碎了心"
author: "术哥无界"
source: "运维有术"
source_url: "https://mp.weixin.qq.com/s/Ib241_1rIS3A5-MThimJ1A"
created: 2026-05-25
type: raw
tags: [article]
sha256: ad0a8d9c7ac31a75ab27856ca23e822489703552976b31c99c4f17146245f41a
---

# 为了让agent更安全的工作，有多少人操碎了心

## 为什么精细的权限设计是 Agent 商用的前提

传统软件的行为是确定性的——用户点击按钮 A 就执行操作 A。但 Agent 的行为由 LLM 动态决策，是概率性的。同一个 Agent 面对同一个用户请求，可能走完全不同的执行路径。

这意味着：**你授出去的权限，不一定按你预期的方式被使用。**

2025 年 12 月豆包手机助手事件暴露了这个问题。它拿到了安卓系统级权限 INJECT_EVENTS，能模拟点击、读取屏幕，理论上可以操作手机上的任何 App。两天之内，微信触发风控封禁账号，农行、建行等银行客户端弹窗提醒用户存在风险。

**Agent 权限问题的本质难点**：单个权限无害，组合起来就可能越界。传统 RBAC 权限模型根本管不住"权限组合后的涌现能力"。

从历史看，每一次平台级技术爆发，都伴随权限治理体系的升级：
- **App 生态**：iOS 6 引入运行时权限授权，整个行业花了约 5 年才形成按需授权模式
- **数据库领域**：从表级权限到行级安全策略（RLS）、列级掩码（Column Masking）、ABAC

现在 Agent 面临的挑战更上一层楼：LLM 的非确定性决策、外部提示词攻击的变量。

## MCP、A2A、CLI/GUI：为什么现有方案都不够

### MCP：AI 领域的 USB-C 接口，但安全根基不稳

MCP（Model Context Protocol）是 Anthropic 在 2024 年 11 月推出的协议，定位是 AI 模型与外部工具/数据源的标准化接口。

**架构级缺陷**：Context Poisoning（上下文投毒）是最典型的问题。OWASP 已将 Prompt Injection 列为 LLM 应用的头号安全风险（LLM01）。

漏洞数据：
- 2026 年 4 月 OX Security 报告：MCP 生态影响超过 3.2 万个代码仓库，Shodan 上可确认 7,374 台公开脆弱服务器，估算暴露总量超过 20 万台
- CVE-2025-49596：MCP Inspector 缺乏客户端与代理之间的身份验证，导致远程代码执行，CVSS 9.4 Critical
- CVE-2025-6514：mcp-remote 连接不可信 MCP 服务器时，通过构造的 authorization_endpoint 响应 URL 实现 OS 命令注入，CVSS 9.6

**核心问题**：MCP 只定义了模型到工具的通信，没有引入用户和服务端作为独立的授权参与方。权限要么全给，要么不给，几乎没有中间态。

### A2A：Agent 间的通信协议，但信任鸿沟依然没能解决

A2A（Agent-to-Agent Protocol）是 Google 在 2025 年 4 月推出的协议，通过 Agent Card 声明能力，基于 HTTP + SSE + JSON-RPC 2.0 实现实时交互。

**核心问题**：Agent Card 只声明我能做什么，但无法验证身份可信度——它没法证明我真的是我说的这个 Agent。用户没有被纳入信任链路。

### CLI 和 GUI 自动化：暴力路径的代价

GUI 自动化的三类问题：
- 权限过度：通常需要系统级权限，远超任务实际需求
- 操作不可审计：模拟出来的点击和用户真实操作无法区分
- 数据边界模糊：屏幕截图过程中，密码、PIN 码、其他应用的通知内容都可能被捕获

## ATH 的运作机制：三方可信握手

ATH（Agent Trust Handshake）协议由中国信通院联合腾讯、华为、中兴、三大运营商和港中深在 2026 年 5 月发布。

**核心创新**：引入用户作为独立的第三方参与方，搭建用户 + 智能体 + 服务的三方协同架构。

### 六大设计原则

| 原则 | 含义 |
|------|------|
| 用户主权 | 用户对数据拥有最高控制权，任何交互须用户知情并授权 |
| 三方参与 | 用户、智能体、服务三方协同参与握手过程 |
| 可信握手 | 智能体访问资源必须同时获得用户和服务的双重授权 |
| 去中心化 | 不依赖单一中心化信任节点，身份验证基于非对称加密 |
| 最小权限 | 仅授予完成任务所需的最小权限集，到期自动失效 |
| 全程可追溯 | 所有交互行为加密存证，可审计、可追溯、不可篡改 |

### 9 步握手流程

**前置步骤：用户预授权**

在智能体开始工作之前，用户先签署一份授权凭证，明确智能体可以代表自己行事的范围。

**第一阶段：双向身份验证（步骤 1-4）**

智能体向服务端发起握手请求，携带 DID、公钥、能力清单和随机数 A。服务端验证后返回自己的身份信息，加上对随机数 A 的签名和自己的随机数 B。智能体验证服务端身份后，对随机数 B 签名发回。服务端验证通过，身份双向确认完成。

**第二阶段：可信握手协商（步骤 5-8）**

智能体向服务端请求具体的访问权限，同时提交用户预授权凭证。**关键**：服务端收到请求后，向用户发起二次确认。用户可以选择同意、拒绝或修改授权范围。确认结果由用户签名。

**第三阶段：会话建立（步骤 9）**

双方完成密钥协商，服务端颁发短期访问令牌，正式建立加密通信通道。

### Scope Intersection：三方权限交集

这是 ATH 在权限安全上最关键的创新：

```
Effective Scope = Agent Approved Scopes ∩ User Consented Scopes ∩ Requested Scopes
最终有效权限 = 服务方审批权限 ∩ 用户授权权限 ∩ 智能体请求权限
```

**权限交集为空时，禁止颁发令牌。**

### 与 OAuth 2.0 的关系

> OAuth 2.0 回答一个问题：用户是否同意？ATH 在此基础上增加第二个必答问题：服务方是否批准该智能体？

ATH 建立在 OAuth 2.0 之上，而非替代它。所有 OAuth 授权请求强制使用 PKCE（RFC 7636）S256 挑战方法，访问令牌绑定到 (agent_id, user_id, provider_id, scopes) 四元组。

### 双部署模式

| 模式 | 架构 | 适用场景 |
|------|------|----------|
| 网关模式 | 智能体 → ATH Gateway → 后端服务 | 不修改原有代码，企业级多服务统一管控 |
| 原生模式 | 智能体直连 ATH 原生服务 | 性能更高、延迟更低 |

网关模式包含三大组件：Agent Registry（身份验证和能力策略）、Authorization Engine（权限交集计算和审计日志）、OAuth Bridge（OAuth 流程委托和令牌管理）。

## Demo 代码解析

ATH 协议仓库提供了 Python Demo（demo/ath_simple_demo_zh.py），零外部依赖。

```bash
git clone https://github.com/ath-protocol/agent-trust-handshake-protocol.git
cd agent-trust-handshake-protocol
python3 demo/ath_simple_demo_zh.py
```

核心设计：Client（模拟 AI 购物助手）和 Server（模拟电商平台）两个类之间只通过 JSON 报文格式交互。

## 写在最后

ATH 作为 2026 年 5 月刚发布的协议，目前还没有企业实际部署的公开案例。但协议的设计思路——特别是三方权限交集、去中心化身份验证、强制 PKCE——确实回应了当前 Agent 权限治理的核心痛点。

**一个更值得思考的问题**：如果 ATH 这样的三方模型被广泛采用，现有的 Agent 开发流程会发生什么变化？开发者需要在设计阶段就规划好"我的 Agent 到底需要哪些最小权限"，而不是先拿到最大权限再说。这本身就是一种更健康的工程实践。