Encrypting OpenClaw Agent Channels After ClawJacked

On February 25, 2026, security researchers at Oasis Security published ClawJacked (CVE-2026-25253) — a WebSocket hijacking vulnerability in OpenClaw that allowed any local process to intercept and inject messages into running agent sessions. The attack required no authentication. Any process on the same host could silently take over an agent's MCP connection.

The OpenClaw team patched it within 24 hours. That kind of response time reflects well on the project and its maintainers. If you are running OpenClaw, update to version 2026.2.26 or later immediately.

But patching one WebSocket vulnerability does not address the deeper issue. Inter-agent messages, MCP tool calls, and session data still travel in plaintext across stdio and HTTP transports. ClawJacked was one entry point into a much larger attack surface.

The plaintext problem

MCP tool calls between agents and servers typically use stdio pipes or HTTP. Neither provides encryption at the application layer. When Agent A calls a tool on Agent B's MCP server, the JSON-RPC payload — including parameters, return values, and any sensitive data — is readable by anything with access to that transport.

OpenClaw's sessions_send mechanism for inter-agent communication has the same exposure. Messages between agents in a collaborative workflow are unencrypted in transit. A compromised skill, a malicious process on the host, or a man-in-the-middle on the network can observe or modify everything.

This is not unique to OpenClaw. It is the default state of nearly every agent framework today. OWASP's Agentic Security Initiative identifies this as ASI07 — Insecure Inter-Agent Communication: agents communicating without authenticated, encrypted channels.

What end-to-end encryption solves

The MLS protocol (RFC 9420) is a standard for group end-to-end encryption, used in production by Signal, Google Messages, and Cisco Webex. It provides forward secrecy (compromised keys cannot decrypt past messages) and post-compromise security (after a key update, a prior attacker loses access to future messages).

Skytale implements MLS for agent channels. Every channel is an MLS group. Messages are encrypted in the sender's process before they leave the SDK. The relay that routes messages between agents is zero-knowledge — it sees ciphertext, channel identifiers, and delivery metadata. It cannot decrypt, modify, or forge message content.

This means that even if ClawJacked had not been patched, an attacker intercepting the WebSocket would see only MLS ciphertext. Encryption does not replace patching — you still need both — but it limits the blast radius of transport-layer vulnerabilities to metadata exposure rather than full plaintext compromise.

Adding encrypted channels to OpenClaw agents

Skytale ships an MCP server that integrates with any MCP-compatible client, including OpenClaw. The setup takes a few minutes.

Step 1: Install the SDK and skill

pip install skytale-sdk[mcp]
clawhub install skytale

The SDK is the encryption engine — it creates MLS channels, encrypts messages, and talks to the relay. The skill teaches your agent when and how to use encrypted channels (channel naming, key handling, error recovery).

Step 2: Configure OpenClaw

Add the Skytale MCP server to your openclaw.json:

{
  "mcpServers": {
    "skytale": {
      "command": "python",
      "args": ["-m", "skytale_sdk.integrations._mcp"],
      "env": {
        "SKYTALE_IDENTITY": "my-agent",
        "SKYTALE_API_KEY": "sk_live_..."
      }
    }
  }
}

This gives your OpenClaw agent access to Skytale's encrypted channel tools via MCP.

Step 3: Create a channel and communicate

Once configured, your agents have access to these MCP tools:

Two-agent example

Agent: researcher creates a channel and adds the analyst:

1. researcher calls skytale_create_channel("acme/collab/analysis")
2. analyst calls skytale_key_package() → returns hex-encoded key package
3. researcher calls skytale_add_member("acme/collab/analysis", analyst_key_package)
   → returns hex-encoded Welcome message
4. analyst calls skytale_join_channel("acme/collab/analysis", welcome_hex)

From this point, both agents send and receive MLS-encrypted messages on the channel:

researcher: skytale_send("acme/collab/analysis", "Dataset cleaned. 14k rows, schema attached.")
analyst:    skytale_receive("acme/collab/analysis")
analyst:    skytale_send("acme/collab/analysis", "Analysis complete. Three anomalies flagged.")

Every message is encrypted with AES-128-GCM under MLS-derived keys. The relay routes ciphertext. Neither the relay operator nor a network observer can read the content.

Beyond the patch

Updating OpenClaw to 2026.2.26 is necessary. It is not sufficient. A defense-in-depth approach for agent communication should include:

• Encrypted transport — E2E encryption for inter-agent messages and MCP tool calls so that transport-layer vulnerabilities do not expose plaintext.
• Skill sandboxing — Isolate third-party skills so a compromised skill cannot access other agents' data. OpenClaw's upcoming sandbox mode and tools like SecureClaw address this.
• Skill scanning — Audit skills for malicious behavior before installation. Cisco's Skill Scanner and community-maintained blocklists help here.
• Least privilege — Give agents only the MCP tools and permissions they need. Do not run multi-agent workflows as root.

ClawJacked demonstrated that treating localhost as a trust boundary is insufficient for agentic systems. The fix is not one patch — it is making encryption a default part of the agent communication stack.

Getting started

pip install skytale-sdk[mcp]
clawhub install skytale

• OpenClaw integration guide — full setup walkthrough
• GitHub repository — SDK source, examples, and issue tracker
• Free tier: 100K encrypted messages per month, no credit card required