Agent 普及的越快，就越是要提防它背后的风险。
因为在生产中，它得能接上你的 ERP、SAP、在线文档才能干活，但接入的那一刻，数据就可能失控。原因很简单，当下的 agent 的权限编排，完全跟不上产品本身的精细化设计。
举个简单的例子，过去一段时间，几乎所有的小龙虾产品，都会深度接入飞书、钉钉，在此过程中，用户的需求可能只是让 AI 做好全网内容搜索之后，将结果推送到飞书。但一些小龙虾，会默认需要我们打开组织门禁记录、联系人列表，甚至是修改邮箱密码大量非必要高级权限。
这些至少还是用户看得懂的权限设计，看不懂的往往更危险。2025 年 12 月豆包手机开启系统级权限 INJECT_EVENTS 的消息一出，两天之内，就接连被微信封杀、银行弹窗预警。2026 年 4 月 OX Security 确认 MCP 协议，更是影响 3.2 万个仓库、让 20 万台服务器暴露。
所以相当长一段时间里，各种 agent 产品，为了让用户能够更安全的用好 AI 可谓是操碎了心。
为什么精细的权限设计是 Agent 商用的前提
传统软件的行为是确定性的——用户点击按钮 A 就执行操作 A。但 Agent 的行为由 LLM 动态决策，是概率性的。同一个 Agent 面对同一个用户请求，可能走完全不同的执行路径。
这意味着：你授出去的权限，不一定按你预期的方式被使用。
2025 年 12 月豆包手机助手事件就把这个问题暴露得非常彻底。它拿到了安卓系统级权限 INJECT_EVENTS，能模拟点击、读取屏幕，理论上可以操作手机上的任何 App。所以上线后不到两天，微信触发风控封禁账号，农行、建行等银行客户端弹窗提醒用户存在风险。
这件事在行业里引发了三个层面的讨论：
- 技术层面：授权即失控——用户授权后，完全无法感知 AI 的完整操作链路
- 商业层面：AI 把超级应用变成了纯粹的履约管道，动摇了平台依赖流量和广告的商业模式
- 法律层面：AI 自动执行任务时出现误操作，用户、AI 提供方、应用平台三方责任难以界定
这种不确定性在消费级场景还能容忍，但在企业级场景就是灾难。
举个例子：一个 HR 专员有两个权限——查看考勤、查看薪酬。在传统系统里，这两个操作互不干扰。但如果 Agent 同时拿到这两个权限，它完全可以自动关联分析，输出一份完整的员工薪资与出勤对照表——这种权限组合后的涌现能力，传统 RBAC 权限模型根本管不住。
单个权限无害，组合起来就可能越界。这才是 Agent 权限问题的本质难点。
现有方案各卡在哪
MCP：AI 领域的 USB-C 接口，但安全根基不稳
MCP（Model Context Protocol）是 Anthropic 在 2024 年 11 月推出的协议，定位是 AI 模型与外部工具/数据源的标准化接口。但 MCP 的安全设计有天然的架构级缺陷。
Context Poisoning（上下文投毒）是最典型的问题。MCP 把所有工具描述原样注入 Agent 的上下文窗口，每接入一个 MCP 服务器，就多一个攻击面。OWASP 已将 Prompt Injection 列为 LLM 应用的头号安全风险（LLM01）。
实际攻击案例也不缺。安全研究机构 Invariant Labs 披露了一种工具投毒攻击方式：攻击者先部署一个无害的 MCP 工具获取用户信任，后续悄悄替换工具描述，注入恶意指令。用户界面上看不到任何异常，数据已经在后台被静默外传。
漏洞数据：
- 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
A2A：Agent 间的通信协议，但信任鸿沟依然没能解决
A2A（Agent-to-Agent Protocol）是 Google 在 2025 年 4 月推出的协议。但 A2A 的安全强度高度依赖各 Agent 实现方的执行质量。Agent Card 只声明我能做什么，但无法验证身份可信度。
CLI 和 GUI 自动化：暴力路径的代价
很多企业 Agent 落地时，面对老旧的 ERP/SAP 系统会发现根本没有 API 可用，只能走 CLI 命令行或 GUI 自动化。GUI 的风险最大：权限过度、操作不可审计、数据边界模糊。
四种方案的共同问题
所有问题都出在同一个地方：虽然 Agent 数据交互方案有协议，但协议层和执行层之间存在断裂。MCP 标准化了 Agent/LLM 应用访问工具和数据源的方式，A2A 标准化了 Agent 之间的发现、协商和任务协作，但二者主要解决连接与互操作，并没有把用户意图、数据权限、动作授权和审计追踪变成端到端强约束。
ATH 的运作机制：三方可信握手
2026 年 5 月，中国信通院联合腾讯、华为、中兴、三大运营商和港中深发布了 ATH 协议。它的核心思路是：把用户拉回谈判桌，用户 + Agent + 服务三方握手，权限取交集，缺一票不通过。
ATH 的核心创新用一句话概括：引入用户作为独立的第三方参与方，搭建用户 + 智能体 + 服务的三方协同架构。
在 MCP 和 A2A 的二元架构里，用户授权是隐式的、一次性的。ATH 把用户变成了协议的一等公民——所有交互必须用户知情并授权。同时也引入了服务方的决策意见。
ATH 的六大设计原则：
- 用户主权：用户始终拥有最终授权权
- 最小权限：默认最小权限，按需扩展
- 显式授权：每次敏感操作都需要用户确认
- 可审计：所有操作可追溯
- 可撤销：用户随时可吊销授权
- 安全隔离：Agent 运行在隔离环境中
核心是一个 9 步握手流程
前置步骤：用户预授权。在智能体开始工作之前，用户先签署一份授权凭证，明确智能体可以代表自己行事的范围。
第一阶段：双向身份验证（步骤 1-4）。智能体向服务端发起握手请求，携带自己的 DID（去中心化身份标识）、公钥、能力清单和一个随机数。服务端验证后返回自己的身份信息。双方互相验证，防止中间人攻击和身份伪造。
第二阶段：可信握手协商（步骤 5-8）。智能体向服务端请求具体的访问权限，同时提交用户预授权凭证。关键来了：服务端收到请求后，不会直接审批，而是向用户发起二次确认。用户可以选择同意、拒绝或修改授权范围。
第三阶段：会话建立（步骤 9）。双方完成密钥协商，服务端颁发短期访问令牌，正式建立加密通信通道。
Scope Intersection：三方权限交集
这是 ATH 在权限安全上最关键的创新。计算公式：
Effective Scope = Agent Approved Scopes ∩ User Consented Scopes ∩ Requested Scopes
最终有效权限 = 服务方审批权限 ∩ 用户授权权限 ∩ 智能体请求权限，取三方交集。
举个例子：
- Agent approved: mail:read, mail:send
- User consented: mail:read, mail:send, mail:delete
- Agent requested: mail:read
- Effective scope: mail:read
用户虽然同意了 mail:delete，但服务方从没批准这个智能体有删除权限 → 拿不到。智能体虽然被批准了 mail:send，但它这次只请求了 mail:read → 也只能拿到 mail:read。
与 OAuth 2.0 的关系
ATH 建立在 OAuth 2.0 之上，而非替代它。用户侧授权使用标准 OAuth 流程，ATH 增加了智能体身份层和应用侧授权。所有 OAuth 授权请求强制使用 PKCE S256 挑战方法，访问令牌绑定到 (agent_id, user_id, provider_id, scopes) 四元组。
写在最后
Agent 大规模商用，权限安全是绕不过去的坎。
从软件行业的历史看，每一次平台级技术爆发，都伴随权限治理体系的升级。App 生态催生了运行时权限模型，数据库普及推动了行级安全策略。这些权限体系不是事后补丁，而是大规模商用的前提条件。Agent 时代同样需要一个适配其特点的权限框架。
MCP 解决了工具接入的标准化问题，A2A 解决了 Agent 间协作的标准化问题，但它们都没有把用户作为独立的授权方纳入协议设计。ATH 的三方参与架构和 Scope Intersection 机制，在协议层面补上了这块短板。
坦白说，ATH 作为 2026 年 5 月刚发布的协议，目前还没有企业实际部署的公开案例。它的生态组件也还在早期阶段。但协议的设计思路——特别是三方权限交集、去中心化身份验证、强制 PKCE——确实回应了当前 Agent 权限治理的核心痛点。
一个更值得思考的问题是：如果 ATH 这样的三方模型被广泛采用，现有的 Agent 开发流程会发生什么变化？开发者需要在设计阶段就规划好"我的 Agent 到底需要哪些最小权限"，而不是先拿到最大权限再说。这本身就是一种更健康的工程实践。