为了让agent更安全的工作，有多少人操碎了心¶
Ch04.316 为了让agent更安全的工作，有多少人操碎了心¶
📊 Level ⭐⭐ | 10.2KB |
entities/ath-agent-trust-handshake-protocol.md
为了让agent更安全的工作，有多少人操碎了心¶
→ 原文存档
摘要¶
本文系统分析了 Agent 权限安全的核心矛盾——「单个权限无害，组合起来可能越界」，传统 RBAC 模型无法管控 LLM 非确定性决策下的权限组合涌现。在对比 MCP、A2A、CLI/GUI 自动化三类现有方案的缺陷后，详细介绍 2026 年 5 月由中国信通院联合腾讯、华为、中兴等发布的 ATH（Agent Trust Handshake）三方可信握手协议。ATH 的核心创新是引入用户作为独立第三方参与方，通过 Scope Intersection（三方权限交集）机制确保最终有效权限 = 服务方审批 ∩ 用户授权 ∩ 智能体请求。
核心要点¶
Agent 权限问题的本质¶
- 传统软件行为确定性——点击按钮 A 就执行操作 A。Agent 行为由 LLM 动态决策，是概率性的，同一请求可能走完全不同的执行路径
- 权限组合涌现：单个权限无害，组合起来可能越界。RBAC 管不住这种涌现能力
- 历史类比：iOS 6 引入运行时权限授权，行业花约 5 年才形成按需授权模式；数据库从表级权限演进到 RLS、Column Masking、ABAC
现有方案的三类缺陷¶
MCP 安全根基不稳： - Context Poisoning（上下文投毒）是架构级问题，OWASP 将 Prompt Injection 列为 LLM 应用头号风险（LLM01） - 2026 年 4 月 OX Security 报告：MCP 生态影响超 3.2 万个代码仓库，Shodan 上 7,374 台公开脆弱服务器，估算暴露超 20 万台 - 高危 CVE：CVE-2025-49596（CVSS 9.4）、CVE-2025-6514（CVSS 9.6） - 核心问题：只定义模型到工具的通信，没有引入用户和服务端作为独立授权参与方
A2A 信任鸿沟：Agent Card 只声明「我能做什么」，无法验证身份可信度，用户未被纳入信任链路
GUI 自动化：系统级权限过度、操作不可审计、屏幕截图可能捕获密码和通知内容
ATH 三方可信握手架构¶
ATH 由中国信通院联合腾讯、华为、中兴、三大运营商和港中深于 2026 年 5 月发布。
六大设计原则：用户主权、三方参与、可信握手、去中心化（非对称加密）、最小权限（到期自动失效）、全程可追溯（加密存证）
9 步握手流程： - 前置：用户预授权——签署授权凭证，明确 Agent 可代表自己行事的范围 - 第一阶段（步骤 1-4）：双向身份验证。Agent 携带 DID、公钥、能力清单和随机数 A 发起请求；服务端验证后返回身份信息 + 对随机数 A 的签名 + 随机数 B；Agent 验证后对随机数 B 签名发回 - 第二阶段（步骤 5-8）：可信握手协商。Agent 请求具体访问权限 + 用户预授权凭证；服务端向用户发起二次确认（用户可同意、拒绝或修改授权范围） - 第三阶段（步骤 9）：密钥协商 + 颁发短期访问令牌 + 建立加密通道
Scope Intersection：三方权限交集¶
这是 ATH 最关键的安全创新： - 用户误授权 + 服务端未批准 → 权限拿不到 - Agent 被批准 + 没请求的权限 → 不会被授予 - 交集为空时 → 禁止颁发令牌
与 OAuth 2.0 的关系¶
ATH 建立在 OAuth 2.0 之上而非替代。OAuth 回答「用户是否同意？」，ATH 增加第二个必答问题「服务方是否批准该智能体？」。强制 PKCE（RFC 7636）S256，访问令牌绑定 (agent_id, user_id, provider_id, scopes) 四元组。
双部署模式¶
| 模式 | 架构 | 适用场景 |
|---|---|---|
| 网关模式 | Agent → ATH Gateway → 后端服务 | 不改原有代码，企业统一管控 |
| 原生模式 | Agent 直连 ATH 原生服务 | 性能更高、延迟更低 |
网关模式三大组件：Agent Registry（身份验证和能力策略）、Authorization Engine（权限交集计算和审计日志）、OAuth Bridge（OAuth 委托和令牌管理）
深度分析¶
三方权限交集：Agent 时代的安全范式转换¶
ATH 的核心贡献不是发明新的加密算法或认证协议，而是将 Agent 权限问题从一个「二元问题」（用户 vs 服务方）提升为「三元问题」（用户 vs 服务方 vs Agent）。这一转换的意义在于：Agent 作为非人类行动者（Non-Human Actor），在协议层获得了与用户和服务方平等的身份地位。
传统 OAuth 2.0 假设权限授予是「用户同意 → 服务方放行」的线性过程，但在 Agent 场景中，权限的「实际使用者」是 LLM 驱动的非确定性决策体——用户同意的权限可能被用于完全不同的目的。ATH 的 Scope Intersection 机制在逻辑层面做了三权分立：即使服务方完全信任 Agent，即使用户过度授权，最终有效权限也必须经过三方交集而非任意两方决定。这一设计间接回应了「权限组合涌现」问题——不是通过穷举所有组合（不可行），而是通过要求每步操作的三方显式同意。
MCP 生态漏洞的深层启示¶
MCP 在 2026 年暴露的高危漏洞（CVE-2025-49596 CVSS 9.4、CVE-2025-6514 CVSS 9.6）不是偶然的配置疏忽，而是 MCP 架构设计中将身份验证视为「可选项」的系统性代价。ATH 选择在握手阶段强制双向身份验证（DID + 公钥 + 随机数挑战），本质上是将安全从「运维层的配置责任」提升为「协议层的内置约束」。
这一差异在企业落地中有实际影响：MCP 的安全依赖开发者在每次接入时正确配置认证参数（容易出错且不可审计），ATH 的安全是协议本身的执行路径上的必经步骤——即使配置错误，流程也会在握手阶段被阻断。
二次确认：从单一授权到按需授权¶
ATH 要求服务端在颁发令牌前向用户发起二次确认，这一机制看似增加了交互成本，但解决了 OAuth 2.0 的长期痛点：用户在授权页面上勾选的一堆权限，在实际被使用前没有任何干预点。ATH 将「单次授权」变为「授权 + 确认」两阶段——用户可以在智能体实际需要访问某个资源时，基于当时的具体上下文（智能体是谁、要做什么、什么场景）做出更审慎的决定。
这一模式与 iOS 运行时权限授权的演进方向一致：从安装时的全量授权，演进到实际使用时的按需授权。ATH 将这一理念从移动端扩展到了 Agent 领域。
ATH 的标准化前景与现实约束¶
ATH 由中国信通院联合腾讯、华为、中兴、三大运营商和港中深发布，这一背景暗示其有望成为国内 Agent 安全通信的推荐标准或行业规范。但与 A2A（Google 主导）和 MCP（Anthropic 主导）不同，ATH 目前缺乏国际主流云厂商的支持，也没有公开的企业级部署案例。
ATH 的三个技术优势（三权分立、强制 PKCE、短期令牌）同时也是其落地障碍：需要服务端、Agent 框架和用户端三方同时支持；如果仅一方采用，无法形成完整的信任链。转向网关模式确实降低了单边改造的成本，但「全网支持 ATH」的临界点尚未到来。
ATH 对 Agent 开发范式的潜在影响¶
如果 ATH 被广泛采用，Agent 开发流程将发生结构性变化：开发者必须在设计阶段就明确声明 Agent 所需的最小权限集（而非传统「先用再说」的宽松模式），且在身份注册阶段就需要与认证服务建立信任关系。这意味着 Agent 开发从「自由探索 + 后期安全审查」转向「设计即安全」的模式。
实践启示¶
- MCP 安全缺陷是架构级的：Context Poisoning 不是配置问题，接入 MCP 服务器需严格验证工具描述来源，关注 CVE 修复
- 三方授权的必要性：用户必须有最终否决权——服务端 + 用户 + Agent 三方缺一不可，任何两方模型都有盲区
- Scope Intersection 的工程价值：即使用户误授权，服务端未批准的权限也拿不到。这是对「权限过度授予」的结构性防护
- 最小权限 + 短期令牌：7200 秒（2 小时）过期，到期需重新握手。这强制了权限的时效性约束
- 网关模式降低落地门槛：不改原有代码即可接入 ATH，适合企业渐进式改造