OpenClaw的启示：身份权限管理是AI Agent时代的阿喀琉斯之踵

1. 过度权限导致的系统级风险

2. 未认证的公网暴露实例

3. 一键远程代码执行（1‑click remote code execution）

1.1 Agent风险的“致命三要素”

1. 访问私有数据（Access to Private Data）： Agent能够读取用户的电子邮件、文档、数据库或代码库。包括 .env、~/.ssh/id_rsa、credentials.json 等一切敏感配置。

2. 外部通信能力（External Communication）： Agent 通常需要调用外部 API 来完成任务，这意味着它拥有将数据发送到任意网络端点的合法通道。

3. 处理不可信内容（Exposure to Untrusted Content）： Agent能够接收并处理来自外部世界的数据（网页内容、外部电子邮件、用户提示词）。

1.2 为什么传统 IAM  在Agent面前失效

• 身份会发生传递：Agent 会代表人类执行操作，且随着Sub Agent 的普及一个请求可能经过几个Agent 转手，资源验证方只能根据最后一跳的身份验证权限，无法识别最原始的动作发起方。很像现实中的层层外包任务，无法确定哪个环节出了问题。这就容易出现“混淆代理人”（Confused Deputy）攻击，也就一个低权限实体（攻击者）在委托链中诱骗一个高权限实体（AI Agent）代表其执行操作。在 OpenClaw 生态中，这一问题通过 CVE-2026-25253 漏洞表现得淋漓尽致。恶意网站可以触发与本地 OpenClaw 实例的 WebSocket 握手。由于Agent信任本地用户的浏览器环境，它并未验证请求的真实来源。

• 静态权限与动态上下文的冲突：人类员工通常拥有固定的角色（如“编辑”），其权限变更频率较低。而智能体是基于任务（Task-Based）运作的，其所需的权限随任务上下文高度动态变化。赋予Agent 24/7的“编辑”权限会创造巨大的攻击面，同时基于 LLM 的Agent本质上是概率性的。即使输入相同的指令，Agent也可能在不同时间生成不同的执行路径。因为Agent不像人类那样有下班时间或通过直觉判断异常。

• 权限颗粒度不足： 现有的 OAuth 作用域（Scopes）往往过于宽泛。例如，Read/Write Email 允许Agent读取所有邮件并发送给任何人。但在Agent场景中，安全的策略应该是“允许读取来自公司域名的邮件，且仅允许向特定 CRM 系统写入数据”。

• 密钥容易泄漏：OpenClaw 这类Agent可以有文件系统的完整读写权限，有代码执行能力，并且有网络访问能力。它可以轻易的可以通过 Shell 或 Python 解释器直接执行 cat .env、print(os.environ) 等命令，将密钥以明文形式提取出来并发送出去。

2.1 身份传播 (Identity Propagation)

• 定义：确保人类用户的身份上下文（User Context）能够穿透代理层，一直传递到Agent所调用的后端服务。Agent不应使用通用的“服务账号”，而应代表具体的发起用户行事 。

• 切断的风险： “混淆代理人” (Confused Deputy)。 如果Agent使用单一的高权限账号，攻击者只需攻破Agent即可访问所有数据。身份传播确保Agent只能访问当前发起任务的用户本来就有权访问的数据。

• 区别点：它解决的是“我是谁”的问题，防止Agent身份被滥用为通用钥匙。

2.2 无秘钥验证 (Secretless Auth)

• 定义：在 Agent 架构下，任何让 LLM 能够"看到"原始密钥或长期有效令牌的设计都是不安全的。正确的做法是将"密钥的持有"与"密钥的使用"彻底解耦。 密钥应该存储在一个 Agent 无法访问的外部安全环境中，Agent 只持有一个无意义的引用标识符。同时最大程度使用短生命周期的动态密钥。

• 切断的风险：凭证泄露与供应链窃取。即使黑客窃取了 OpenClaw 的代码库或 .env 文件，也找不到任何可用的凭证，从而杜绝了像 Moltbook 那样的密钥大规模泄露事件。

• 区别点：它解决的是“凭证在哪里”的问题，消除了Agent 暴露大量密钥的分享也进一步消除静态攻击面。

2.3 上下文感知 (Context Awareness)

• 定义：权决策基于Agent的运行时完整性与会话状态。系统验证Agent是否运行在受信任的执行环境（如 AWS Nitro Enclave, Confidential VM）中，以及当前的 SessionAttributes （会话属性）是否包含完成该操作所需的前序状态。例如攻击者试图绕过“购物车检查”直接调用“支付接口”。上下文感知系统会检测到当前 Session 缺少“已验证购物车”的状态标记，从而拒绝访问。

• 切断的风险：异常行为与账号接管。如果一个通常只在工作时间处理邮件的Agent，突然在深夜尝试访问核心数据库，上下文感知系统会识别出这种异常模式并拒绝访问。

• 区别点：解决“环境与逻辑状态是否可信”的问题。这是传统 IAM（只看人）无法做到的动态防御。

2.4 意图感知授权 (Intent-Aware Authorization / The "Why" Check)

• 定义：深入语义层面的授权。系统不仅检查Agent“能不能”做某事，还要检查它“为什么”要做。通过分析 Prompt 和执行逻辑，验证操作是否符合用户的原始意图。

• 切断的风险：提示词注入与逻辑越狱。当Agent被注入指令去转账时，意图感知层会分析发现：“用户最初的指令是查询余额，现在的转账操作与原始意图不符”，从而拦截请求。

• 区别点：这是Agent安全中最独特的支柱。传统的 IAM 无法理解语义，只有意图感知能防御逻辑层面的攻击。

我们对当前市场上的主流 Agent IAM 方案进行了深度剖析，看看它们是如何将这些理论转化为防御能力的。

3.1 AWS AgentCore Identity：

3.2 Microsoft Azure Entra Agent ID：上下文感知的集大成者

• 上下文感知：Azure 的条件访问（Conditional Access）策略是目前最强大的上下文引擎。管理员可以设定：“只有当Agent运行在合规的云容器中、且源 IP 属于公司内网、且威胁情报评级为低时，才允许访问 SharePoint” 。

• 身份传播：通过“工作负载身份联合”（Workload Identity Federation），Azure 允许Agent（即使运行在 AWS 或 GCP 上）交换 Token 来获得 Azure AD 的身份，确保了跨云环境下的身份一致性 。

• 身份归因：Azure 的日志系统（Sign-in Logs）经过升级，可以清晰地记录“是哪个Agent，代表哪位用户，在什么环境下”执行了操作，提供了完善的审计归因能力 。

• 出站Gateway:充当一个安全Agent层实现无秘钥验证。智能体本身永远看不到真实的 API 密钥。当Agent请求操作时，Gateway验证策略并从TokenVault 中取出密钥。然后在请求离开网络边界时动态注入密钥。TokenVault 也解决密钥容易泄漏的问题。

• 权限管理模块：通过上下文感知 (Context Awareness) 和意图感知的能力实现每次访问行为的细粒度的权限管控。策略引擎基于Cedar 语言，支持各类灵活定制。