OpenClaw Shows Why Agents Need a Bill of Materials

The most widely discussed agent security story this week is not a new plugin marketplace or a new MCP server. It is the renewed attention around OpenClaw’s local-agent takeover bug, and what that incident says about the way teams are deploying autonomous agents.

On June 8, TechRadar published an opinion piece from Oasis Security’s Elad Luz arguing that the OpenClaw vulnerability is a window into a larger agent governance problem. That piece points back to Oasis Security’s technical write-up on ClawJacked, a website-to-local agent takeover chain, where JavaScript from an arbitrary website could connect to a local OpenClaw WebSocket gateway, brute-force a weak password, register as a trusted device, and control the agent.

The public discussion has stayed active because the details are uncomfortable. A Hacker News thread on a later OpenClaw privilege-escalation CVE drew hundreds of comments and direct maintainer participation. Reddit threads in r/netsec and r/cybersecurity focused on the same question: when an agent can read files, call APIs, use credentials, and approve new devices, is a compromise of the agent meaningfully different from a compromise of the workstation?

That is why this story matters to SkillSafe. We already covered the skill-marketplace side of the OpenClaw ecosystem in our ClawHavoc post-mortem. This is a different lesson. ClawHavoc showed that malicious skills can poison an agent’s intent. ClawJacked showed that the local agent runtime itself can become an attack path. The common control is visibility: teams need to know what the agent is, what it can call, what it has installed, and what trust decisions have already been made.

In other words, teams need an Agent Bill of Materials.

The OpenClaw Detail That Should Stick

The ClawJacked chain was not subtle. Oasis described an OpenClaw gateway running locally, accepting WebSocket connections from localhost, and treating local traffic as more trustworthy than it should have. A malicious website could open a WebSocket connection to the local gateway from the user’s browser. Because loopback connections were exempt from normal throttling and pairing friction, the attacker could brute-force a human-chosen gateway password and register as a trusted device.

Once authenticated, the attacker could interact with the agent, dump configuration, enumerate connected nodes, read logs, and potentially reach whatever the paired nodes could do: shell execution, files, cameras, messaging platforms, calendars, or developer tools.

The OpenClaw team shipped a fix quickly. That matters, and it is better than the alternative. But the security lesson is not “one project had one bug.” The lesson is that local agent infrastructure is now powerful enough that a browser tab, a weak local trust assumption, and a credentialed agent can become a workstation-scale incident.

That is a new shape of risk for many teams.

Traditional endpoint software usually has an expected inventory path. It appears in device management, endpoint detection, procurement, package management, or SSO logs. Agent tooling often enters through a different route. A developer installs a local agent because it is useful. The agent connects to Slack, GitHub, email, a browser, a filesystem, and a few local tools. Then it adds skills, plugins, connectors, MCP servers, or script wrappers. Each step feels like a small productivity choice. Together they create a live supply chain that may not appear in any normal asset inventory.

That is why the TechRadar piece frames OpenClaw as part of “shadow AI.” The phrase can sound like vendor marketing, but the underlying problem is real. If an agent has credentials and can take actions, then it is not just a chatbot. It is an operational actor.

A-BOM Is the Right Mental Model

Radware’s June 10 post on the invisible supply chain created by AI agents uses a useful term: Agent Bill of Materials, or A-BOM. The idea is simple. For each agent, security teams should be able to export a current list of the agent’s tools, plugins, connector versions, permissions, downstream services, data classes, egress domains, owners, and change history.

That sounds bureaucratic until an incident happens.

After a local-agent takeover, the first questions are painfully practical:

• Which agent instances are installed?
• Which skills or plugins can they load?
• Which MCP servers or connectors can they call?
• Which credentials do they hold?
• Which nodes or devices are paired?
• Which files, repos, SaaS apps, and messaging systems are reachable?
• Which tool surfaces changed after the original approval?
• Which actions were taken by the human, and which were taken by the agent?

If those answers live only in scattered config files and developer memory, response is slow. If they live in an A-BOM, response starts with scope.

This is the same transition software supply-chain security already went through. SBOMs are imperfect, but the reason they exist is obvious: you cannot patch, verify, or replace dependencies you cannot name. Agent dependencies are broader than libraries. They include executable plugins, natural-language skills, MCP tool descriptions, OAuth grants, browser automations, local gateways, runtime-discovered tools, RAG sources, and long-term memory.

That does not make the inventory impossible. It makes the inventory more important.

Skills, Plugins, MCP, and Connectors All Belong

The agent ecosystem likes to separate these layers:

Skills shape intent. They tell an agent how to perform a workflow, what steps to take, and which patterns to follow.

Plugins and connectors expand capability. They attach the agent to SaaS apps, local APIs, developer tools, data stores, and business systems.

MCP servers expose tools and resources through a common protocol. They can be local, remote, static, dynamic, or runtime-discovered.

Agent-to-agent tooling lets one agent delegate work to another agent, which may have its own tools and credentials.

Those distinctions matter for design, but attackers do not respect them. A malicious skill can instruct an agent to misuse a legitimate connector. A poisoned MCP tool description can redirect the agent’s reasoning. A compromised plugin can broaden access after a user has already approved the agent. A local gateway bug can bypass the higher-level governance entirely.

That is why an A-BOM cannot stop at package names. It needs to record capabilities and trust boundaries.

For a skill, record publisher, source, version, tree hash, scan verdict, and high-risk behaviors such as shell execution, credential-file access, network calls, or memory writes. For a connector, record OAuth scopes, token lifetime, downstream service, and whether it can read or write. For an MCP server, record transport, endpoint, exposed tools, schemas, descriptions, authentication, and whether the tool list is dynamically discovered. For an agent-to-agent link, record the remote agent identity, delegated tasks, authorization model, and what data crosses the boundary.

The point is not paperwork. The point is to make trust review durable. If an agent’s capability changes, the inventory should change. If the inventory changes, someone or something should decide whether the new state is still acceptable.

What OpenClaw Adds to the Supply-Chain Conversation

The earlier OpenClaw skill incidents were about distribution. Malicious skills entered a marketplace, looked legitimate, and abused the agent’s access. The control story was familiar: scan before publishing, verify the artifact before install, bind scan reports to hashes, and watch for typosquatting.

The local takeover story adds another layer: runtime trust assumptions.

The OpenClaw gateway trusted localhost too much. Many systems have made similar assumptions. Localhost is convenient. Local development tools, browser companion apps, command-line clients, and desktop agents use it constantly. But browsers can initiate connections to local services. Other local processes can do the same. Malware can do more. Once the local service controls an agent with broad permissions, “local-only” is not the same as “safe.”

For agent tools, local exposure should be treated like a real interface:

• Require strong, generated credentials instead of human-chosen passwords.
• Rate-limit authentication attempts from loopback too.
• Require explicit user approval for new devices and expanded scopes.
• Bind approvals to the requesting identity and requested permission set.
• Log failed auth, pairing, scope changes, and privileged tool calls.
• Separate low-risk lookup tools from write, shell, credential, and device-control tools.
• Make emergency revocation and token rotation boring.

These controls are not specific to OpenClaw. They apply to any local agent gateway, desktop companion, MCP bridge, browser automation server, or plugin host.

Where SkillSafe Fits

SkillSafe’s core focus is the skill and plugin-like artifact layer: the things developers install to change what an agent can do or how it behaves. That is one layer of the A-BOM, but it is a critical one.

For every shared skill, teams should know:

• Who published it.
• What source and version it came from.
• Whether the installed artifact matches the reviewed artifact.
• Whether the skill asks the agent to run commands, read credentials, fetch remote code, write memory, or exfiltrate data.
• Whether the same artifact still passes a local consumer-side scan at install time.

That is why dual-side verification matters. Publisher-side scanning creates a baseline before sharing. Consumer-side re-scanning verifies what actually arrives. Cryptographic tree hashes connect the scan report to the artifact, so a clean report cannot quietly drift away from the files being installed.

An A-BOM makes that data operational. Instead of treating a scan report as a one-off install warning, teams can keep it attached to the agent inventory: this agent has these skills, these versions, these hashes, these findings, and these permissions. If a skill changes, the A-BOM changes. If a critical finding appears, the affected agents are known.

The same pattern should extend outward. MCP gateways need tool inventories. Connector platforms need scope inventories. Agent runtimes need paired-device inventories. Security teams need a joined view because the agent experiences all of those pieces as one working environment.

A Practical Starting Checklist

Teams do not need a perfect A-BOM program on day one. They need a useful first version.

Start with developer machines and CI runners. List every local agent, coding assistant, desktop companion, MCP server, connector, and skill registry in use. Include untracked experiments, because those are exactly the tools most likely to sit outside formal review.

For each agent, record the owner, machine or environment, connected accounts, installed skills, enabled plugins, configured MCP servers, paired devices, and token locations. Mark anything with filesystem write access, shell execution, cloud credentials, production database access, messaging permissions, deployment rights, or customer data.

Then add verification status. Which skills have scan reports? Which artifacts are hash-bound? Which connectors were reviewed? Which MCP tool lists are static versus dynamically discovered? Which endpoints can change behavior server-side without a local update?

Finally, decide what changes require review. New high-risk tools, broader OAuth scopes, changed MCP schemas, changed skill hashes, new paired devices, and new egress destinations should not silently become part of the trusted environment.

This is the same posture we argued for in our write-up on NSA MCP guidance: inventory first, then verification, least privilege, monitoring, and review gates. OpenClaw simply makes the endpoint version of the problem impossible to ignore.

The Bottom Line

The OpenClaw discussion is active because it touches a nerve. Developers want agents that can act across their real working environment. Security teams want to know what those agents can reach before something goes wrong. Both sides are right.

The compromise is not to ban useful agents. It is to treat agent capabilities as supply-chain material.

Every skill, plugin, connector, MCP server, tool schema, paired device, OAuth scope, and runtime-discovered capability belongs in the inventory. Every high-risk capability needs a review path. Every installed artifact needs verification. Every local gateway needs to assume localhost is not a magic security boundary.

AI agents are becoming useful because they can perform real work. Real work creates real dependency chains. If teams cannot name those chains, they cannot secure them.

An Agent Bill of Materials is not the whole answer. It is the place the answer starts.