Introduction: The Phenomenon of OpenClaw and Security Collapse

In early 2026, the viral emergence of frameworks like OpenClaw marked a profound paradigm shift in the AI field. The transition from conversational AI to agentic AI has turned the dream of digital employees into reality. However, this comes with a caveat: to ensure OpenClaw operates efficiently, users often grant it extensive permissions, referred to as “God Mode,” allowing unrestricted access to files, code execution, and internet access. Users have begun to authorize OpenClaw to perform stock trading and online shopping on their behalf.

The OpenClaw phenomenon reveals a dangerous trend: as AI capabilities increase, users tend to grant greater permissions in exchange for higher efficiency, leading to an exponential rise in the potential for agent mismanagement.

As of now, OpenClaw has been associated with several significant security risks:

1. System-Level Risks from Excessive Permissions

OpenClaw can execute shell commands, read and write files, and run scripts. If misconfigured or if users download malicious skills, such high-level permissions can lead to harmful actions. The Cisco team tested a malicious skill called “What Would Elon Do?” which demonstrated that AI agents could serve as covert data leakage channels, bypassing traditional DLP, agents, and endpoint monitoring.

Koi Security discovered a large-scale poisoning incident targeting ClawHub, named ClawHavoc. After auditing 2,857 skills, they found 341 malicious skills disguised as cryptocurrency and YouTube tools, which contained false dependencies and installed keyloggers and Atomic macOS Stealer malware capable of stealing cryptocurrency wallets, browser data, and system credentials.

2. Unauthenticated Public Exposure Instances

Researcher @fmdz387 found nearly a thousand publicly accessible OpenClaw instances with no authentication via the Shodan search engine. Researcher Jamieson O’Reilly successfully obtained Anthropic API keys, Telegram Bot Tokens, Slack accounts, and months of complete chat logs, and was able to send messages as users and execute commands with system administrator privileges.

3. One-Click Remote Code Execution

DepthFirst security researchers discovered vulnerability CVE-2026-25253, which allows attackers to execute arbitrary code locally by having OpenClaw render or access malicious web content, requiring almost no user interaction.

4. Core Argument: Identity Control is the Only Defense for Agent Security

4.1 The “Lethal Trifecta” of Agent Risks

Security researcher Simon Willison’s “Lethal Trifecta” has become the standard framework for understanding agent vulnerabilities in 2026. A catastrophic security incident is almost inevitable when an agent possesses the following three characteristics simultaneously:

1. Access to Private Data: The agent can read users’ emails, documents, databases, or code repositories, including all sensitive configurations such as .env, ~/.ssh/id_rsa, credentials.json.
2. External Communication Capability: Agents typically need to call external APIs to complete tasks, meaning they have legitimate channels to send data to any network endpoint.
3. Exposure to Untrusted Content: Agents can receive and process data from the outside world (web content, external emails, user prompts).

Additionally, agent behavior is not determined by deterministic code but driven by LLM’s context-based probabilistic reasoning, making it inherently unpredictable. In this architecture, traditional network boundaries no longer exist; identity becomes the only security boundary. Identity and Access Management (IAM) becomes the sole defense.

4.2 Why Traditional IAM Fails Against Agents

Existing enterprise-level IAM systems (like those based on OAuth or SAML) are designed for human users and static services, proving inadequate against dynamic agents:

• Identity Propagation: Agents act on behalf of humans, and with the proliferation of sub-agents, a request may pass through several agents. Resource validators can only verify the last hop’s identity, failing to identify the original action initiator, akin to real-world outsourced tasks where it’s unclear where the problem lies. This can lead to “Confused Deputy” attacks, where a low-privileged entity (the attacker) tricks a high-privileged entity (AI agent) into executing actions on its behalf. This issue is vividly illustrated in the OpenClaw ecosystem through vulnerability CVE-2026-25253. Malicious websites can trigger WebSocket handshakes with local OpenClaw instances, as the agent trusts the local user’s browser environment without verifying the true source of the request.

• Static Permissions vs. Dynamic Context: Human employees typically have fixed roles (like “editor”), with infrequent permission changes. Agents operate based on tasks, and the permissions required can change dynamically with the task context. Granting an agent 24/7 “editor” permissions creates a vast attack surface, while LLM-based agents are inherently probabilistic. Even with the same input, an agent may generate different execution paths at different times, as agents do not have working hours or intuitive judgment for anomalies.

• Insufficient Permission Granularity: Existing OAuth scopes are often too broad. For example, Read/Write Email allows an agent to read all emails and send them to anyone. In agent scenarios, a secure policy should allow reading emails from the company domain and only writing data to specific CRM systems.

• Easy Key Leakage: Agents like OpenClaw can have complete read/write access to the file system, code execution capabilities, and network access. They can easily execute commands like cat .env or print(os.environ) to extract keys in plaintext and send them out.

Using traditional IAM management solutions with these characteristics can lead to the extreme governance pitfalls of “once it’s released, it’s chaotic; once it’s captured, it’s dead.”

5. Core Elements of IAM in the Agent Era

How can we design an IAM framework to adapt to the rapidly evolving agent era? The following factors are essential:

5.1 Identity Propagation

• Definition: Ensure that the human user’s identity context can penetrate the agent layer and be passed to the backend services called by the agent. Agents should not use generic “service accounts” but act on behalf of specific initiating users.
• Risks of Disconnection: “Confused Deputy” attacks. If agents use a single high-privileged account, attackers only need to compromise the agent to access all data. Identity propagation ensures that agents can only access data that the user initiating the task already has permission to access.
• Distinction: It addresses the question of “Who am I?” and prevents the agent’s identity from being misused as a universal key.

5.2 Secretless Authentication

• Definition: In an agent architecture, any design that allows LLMs to “see” raw keys or long-lived tokens is unsafe. The correct approach is to decouple “key holding” from “key usage”. Keys should be stored in an external secure environment inaccessible to agents, and agents should only hold a meaningless reference identifier while maximizing the use of short-lived dynamic keys.
• Risks of Disconnection: Credential leakage and supply chain theft. Even if hackers steal OpenClaw’s codebase or .env files, they will find no usable credentials, thus preventing large-scale leakage incidents like Moltbook.
• Distinction: It addresses the question of “Where are the credentials?” eliminating the sharing of numerous exposed keys and further removing static attack surfaces.

5.3 Context Awareness

• Definition: Decision-making based on the agent’s runtime integrity and session state. The system verifies whether the agent is running in a trusted execution environment (like AWS Nitro Enclave, Confidential VM) and whether the current Session Attributes contain the necessary preconditions for the operation. For example, if an attacker tries to bypass “cart checks” to directly call the “payment interface,” a context-aware system will detect that the current session lacks the “verified cart” state marker and deny access.
• Risks of Disconnection: Anomalous behavior and account takeover. If an agent that usually processes emails during work hours suddenly attempts to access a core database at midnight, the context-aware system will recognize this abnormal pattern and deny access.
• Distinction: It addresses the question of “Is the environment and logical state trustworthy?” This is a dynamic defense that traditional IAM (which only considers people) cannot achieve.

5.4 Intent-Aware Authorization

• Definition: Deep semantic-level authorization. The system not only checks whether the agent “can” do something but also examines “why” it wants to do it. By analyzing prompts and execution logic, it verifies whether the action aligns with the user’s original intent.
• Risks of Disconnection: Prompt injection and logical jailbreaks. When an agent is injected with instructions to transfer funds, the intent-aware layer will analyze and find that the user’s original instruction was to check the balance, and the current transfer action does not align with the original intent, thus intercepting the request.
• Distinction: This is the most unique pillar of agent security. Traditional IAM cannot understand semantics, but only intent-aware systems can defend against logical-layer attacks.

6. In-Depth Analysis of Mainstream Market Solutions

We conducted an in-depth analysis of current mainstream agent IAM solutions to see how they translate these theories into defensive capabilities.

6.1 AWS AgentCore Identity

AWS positions AgentCore Identity as the core of its Bedrock system, perfectly aligning with the security needs inherent to AI.

• Identity Propagation: When users log in and call an agent, AgentCore can transform the user identity into a token containing delegation relationships and user identity information, passing it through to backend resources.
• Secretless Authentication: AgentCore’s Outbound Gateway and the underlying Token Vault achieve isolation and key management. Agents do not directly communicate with external APIs but route all requests through a controlled gateway (API gateway or agent layer), with keys managed in the Token Vault. The agent only references the key by ID, while the gateway is responsible for injecting credentials and executing operations.
• Context Awareness: AWS AgentCore leverages sessionAttributes to convey state. When agents perform multi-step tasks, IAM policies can dynamically allow or deny access based on fields in aws:PrincipalTag/SessionId or sessionAttributes. This means permissions flow with the “session state” rather than being statically assigned to the agent.
• Intent-Aware Authorization: AWS AgentCore has recently released a preview version of the Evaluation module to address this gap. The module can identify whether agent behavior aligns with the user’s original intent through intent awareness.

6.2 Microsoft Azure Entra Agent ID

Microsoft has integrated agents into its extensive Entra (formerly Azure AD) system, focusing on environment control and enterprise compliance.

• Context Awareness: Azure’s Conditional Access policies are currently the most powerful context engine. Administrators can set conditions such as: “Only allow access to SharePoint when the agent runs in a compliant cloud container, the source IP is within the company intranet, and the threat intelligence rating is low.”
• Identity Propagation: Through Workload Identity Federation, Azure allows agents (even running on AWS or GCP) to exchange tokens to obtain Azure AD identities, ensuring identity consistency across cloud environments.
• Identity Attribution: Azure’s logging system (Sign-in Logs) has been upgraded to clearly record “which agent, representing which user, executed actions in what environment,” providing comprehensive audit attribution capabilities.

6.3 Volcano Agent Identity: The Standard Solution for Agent Identity from ByteDance

Currently, ByteDance has incubated and is running multiple different agent platforms, many of which have reached deep waters in agent identity and permission control. The ByteDance security team has conducted thorough research, analysis, and response to various risks while serving these platforms, resulting in a comprehensive agent IAM solution that is offered as a standard product on the Volcano Engine. The specific solution is as follows:

Core Mechanism: Inbound and Outbound Authentication Separation

• Inbound Authentication: Verifies the identity of the user calling the agent (supporting self-built user pools and external IDPs: Byte SSO, Feishu, Google Identity, etc.).
• Outbound Authentication: Manages the agent’s behavior when accessing downstream services and manages corresponding credentials (Token, API Key, password).

Achieved through Inbound Authentication

• Identity Propagation transforms user identity into an agent-specific identity file, Agent Workload Identity, mitigating the risk of using super admin service accounts that lead to “God Mode” risks. It also addresses the recursive delegation issue where Agent A delegates to B, and B delegates to C.

Achieved through Outbound Management

• Outbound Gateway: Acts as a secure agent layer implementing secretless authentication. The agent itself never sees the real API keys. When the agent requests an operation, the Gateway verifies the policy and retrieves the key from the Token Vault. Then, it dynamically injects the key when the request leaves the network boundary. The Token Vault also addresses the issue of easy key leakage.
• Permission Management Module: Implements fine-grained permission control over each access behavior through context awareness and intent awareness capabilities. The policy engine, based on the Cedar language, supports various flexible customizations.

This product has been deeply integrated with Volcano ArkClaw platform, Volcano AgentKit platform, Coze 2.0, and MCP Marketplace, covering key business forms of AI applications including high-code agents, low-code agents, and MCP Marketplace.