引言：现象级爆发与安全崩塌：OpenClaw 启示录
2026年初，随着 OpenClaw 等自主智能体（Autonomous Agents）框架的病毒式爆发，人工智能领域经历了一场深刻的范式转移。从“对话式 AI”向“代理式 AI（Agentic AI）”的跨越，人们期望的数字员工正在变成现实。硬币的另一面是，为了让 OpenClaw 高效运作，用户往往必须授予其所谓的“上帝模式”（God Mode）——即对其文件读取、代码执行和互联网访问不加限制的广泛权限。已经开始有用户完全授权代OpenClaw替人类进行股票交易、在线购物付款了。
OpenClaw 现象揭示了一个危险的趋势：随着 AI 能力的增强，人们倾向于赋予其更大的权限，以换取更高的效率。随着人们胆子越来越大，Agent管理失控的可能性呈指数级上升。
截止目前，OpenClaw 已爆出多个大型安全风险：
1. 过度权限导致的系统级风险
OpenClaw 可以运行 Shell 命令、读写文件、执行脚本。一旦配置错误或用户下载了注入恶意指令的 Skill，这种高级别权限会使其执行有害操作。 Cisco 团队测试了一个名为"What Would Elon Do?"的恶意 Skill ，验证了 AI Agent 可以成为绕过传统 DLP、Agent和端点监控的隐蔽数据泄漏通道，模型本身也可以成为执行编排器。
Koi Security 发现了针对ClawHub 的大规模投毒事件ClawHavoc。2,857个 Skills 进行审计后，发现341个恶意 Skills。这些伪装成加密货币工具和 YouTube 工具的 Skills 包含虚假依赖项，实际安装了键盘记录器和 Atomic macOS Stealer 恶意软件，能够窃取加密货币钱包、浏览器数据和系统凭证。
2. 未认证的公网暴露实例
研究人员 @fmdz387 通过 Shodan 搜索引擎发现了近千个公开可访问的 OpenClaw 实例，且全部无任何身份认证。研究人员 Jamieson O'Reilly 成功获取了 Anthropic API 密钥、Telegram Bot Token、Slack 账户及数月的完整聊天记录，还能以用户身份发送消息，甚至以系统管理员权限执行命令。
3. 一键远程代码执行（1‑click remote code execution）
DepthFirst 安全研究人员发现漏洞 CVE‑2026‑25253 允许攻击者通过让 OpenClaw 渲染或访问恶意网页内容，即可在本地执行任意代码，窃取存储的 API 密钥、Token 和数据，几乎不需要用户交互。
1. 核心论点：身份控制是Agent安全的唯一防线
1.1 Agent风险的“致命三要素”
安全研究员 Simon Willison 提出的“致命三要素”（Lethal Trifecta）已成为2026年理解Agent漏洞的标准框架。当一个智能体同时具备以下三个特征时，灾难性的安全事故几乎是不可避免的：
访问私有数据（Access to Private Data）： Agent能够读取用户的电子邮件、文档、数据库或代码库。包括 .env、~/.ssh/id_rsa、credentials.json 等一切敏感配置。
外部通信能力（External Communication）： Agent 通常需要调用外部 API 来完成任务，这意味着它拥有将数据发送到任意网络端点的合法通道。
处理不可信内容（Exposure to Untrusted Content）： Agent能够接收并处理来自外部世界的数据（网页内容、外部电子邮件、用户提示词）。
并且Agent 的行为不是由确定性代码决定的，而是由 LLM 基于上下文的概率推理驱动的——这意味着它的行为本质上是不可预测的。在这种架构下，在自主Agent时代，传统的网络边界已不复存在，身份（Identity）成为了唯一的安全边界。身份和访问管理（Identity & Access Management - IAM） 成为了唯一的防线。
1.2 为什么传统 IAM 在Agent面前失效
现有的企业级 IAM 系统（如基于 OAuth、SAML 的方案）是为人类用户和静态服务设计的，面对动态的智能体，它们显得力不从心：
身份会发生传递：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) 等命令，将密钥以明文形式提取出来并发送出去。
根据以上特征再使用传统IAM管理方案，就容易出现“一放就乱，一抓就死”的治理的两极误区。
2. Agent时代的 IAM的应该具备的核心要素
那么怎么设计IAM 框架才能适应这个日新月异的Agent时代呢？需要完整一下这些因素：
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 无法理解语义，只有意图感知能防御逻辑层面的攻击。
3. 市场主流方案深度解析：
我们对当前市场上的主流 Agent IAM 方案进行了深度剖析，看看它们是如何将这些理论转化为防御能力的。
3.1 AWS AgentCore Identity：
AWS 将 AgentCore Identity 作为其 Bedrock 体系的核心，其设计哲学完美契合了AI原生的安全需求。
身份传播：当用户登录并调用Agent时，AgentCore 能将用户身份通过Token置换变成含委托关系以及用户身份信息的Token, 一路透传给后端的资源。
无秘钥验证：AgentCore 的Outbound Gateway 以及背后的Token Vault来实现隔离和密钥托管。Agent 不直接与外部 API 通信，而是通过一个受控的 Gateway（API 网关或Agent层）来中转所有请求，密钥都托管到Token Vault中，Agent只通过ID引用密钥，然后Gateway负责注入凭据并执行操作。
上下文感知 (Context Awareness)：AWS AgentCore 深度利用 sessionAttributes 来传递状态。当Agent执行多步任务时，IAM 策略可以根据 aws:PrincipalTag/SessionId 或 sessionAttributes 中的字段来动态允许或拒绝访问。这意味着权限是跟随“会话状态”流动的，而不是静态赋予Agent的
意图感知授权：AWS AgentCore 最新新发布了Evaluation 模块的Preview版本补足了这一块的缺失。模块可以通过意图感知来识别Agent行为是否符合用户发起请求的初衷。
3.2 Microsoft Azure Entra Agent ID：上下文感知的集大成者
微软将Agent纳入了其庞大的 Entra（原 Azure AD）体系，重点在于环境控制和企业合规 。
上下文感知：Azure 的条件访问（Conditional Access）策略是目前最强大的上下文引擎。管理员可以设定：“只有当Agent运行在合规的云容器中、且源 IP 属于公司内网、且威胁情报评级为低时，才允许访问 SharePoint” 。
身份传播：通过“工作负载身份联合”（Workload Identity Federation），Azure 允许Agent（即使运行在 AWS 或 GCP 上）交换 Token 来获得 Azure AD 的身份，确保了跨云环境下的身份一致性 。
身份归因：Azure 的日志系统（Sign-in Logs）经过升级，可以清晰地记录“是哪个Agent，代表哪位用户，在什么环境下”执行了操作，提供了完善的审计归因能力 。
4. 火山Agent Identity：源于字节的Agent身份标准方案
目前，字节内部已孵化且并行运行多个不同的Agent平台，很多平台已经走到Agent身份的深水区，触及到很多Agent身份权限控制的核心痛点。字节安全团队在长期服务这些平台的过程中，对各类风险进行了充分调研、分析和应对，沉淀出一套完备的Agent IAM解决方案，并且在火山引擎上以标准产品的形式提供给业界。具体方案如下：
核心机制：入站（Inbound）与出站（Outbound）认证分离
入站认证： 验证调用Agent的用户身份（支持自建用户池和外部IDP: 字节SSO, 飞书, Google Identity等）。
出站认证： 管理Agent在访问下游服务时行为，以及管理相应凭证（Token、API Key、密码）。
通过入站认证实现
身份传播（Identity Propagation）将用户身份，换成Agent 专用身份文件 Agent Workload Identity ，置换时候，有效缓解了Agent使用超级管理员服务账号导致的“上帝模式”风险。同时解决了 Agent A 委托B，B委托C的“递归委托”难题。
通过出站管理实现
出站Gateway:充当一个安全Agent层实现无秘钥验证。智能体本身永远看不到真实的 API 密钥。当Agent请求操作时，Gateway验证策略并从TokenVault 中取出密钥。然后在请求离开网络边界时动态注入密钥。TokenVault 也解决密钥容易泄漏的问题。
权限管理模块：通过上下文感知 (Context Awareness) 和意图感知的能力实现每次访问行为的细粒度的权限管控。策略引擎基于Cedar 语言，支持各类灵活定制。
该产品目前已完成与火山 ArkClaw 平台、火山 AgentKit 平台、 Coze 2.0 和 MCP Marketplace 的深度集成，覆盖了高代码 Agent、低代码 Agent 以及 MCP Marketplace 等 AI 应用的关键业务形态。
