OpenClaw Shows Why Agents Need a Bill of Materials

An Agent Bill of Materials (A-BOM) is a live inventory of everything one AI agent can load or reach: skills, plugins, MCP servers, OAuth scopes, paired devices, egress domains and owners. OpenClaw’s ClawJacked flaw — a website-to-local-agent takeover Oasis Security disclosed on February 26, 2026 and the project patched inside 24 hours — is why teams need one.

Updated September 2026: the ClawJacked bug itself is long fixed. What has not changed is the inventory gap it exposed — and the ecosystem data has only gotten worse since, with Snyk finding security flaws in 36.8% of 3,984 scanned agent skills.

The primary write-up is Oasis Security’s ClawJacked disclosure, which describes a chain that starts in a browser tab and ends at a credentialed local agent. Its one-line summary of the root cause:

Any website you visit can open [a WebSocket connection] to your localhost.

Oasis measured “hundreds of password guesses per second from browser JavaScript alone,” because the gateway’s rate limiter exempted loopback traffic and a successful login from localhost auto-approved the caller as a trusted device. TechRadar later published an opinion piece from Oasis Security’s Elad Luz arguing that the vulnerability is a window into a larger agent governance problem.

The public discussion 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. Threads in r/netsec and r/cybersecurity circled one 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?

Key Figures

Figure	What it measures	Source
Feb 26, 2026	ClawJacked disclosed to OpenClaw maintainers	Oasis Security
Under 24 hours	Disclosure to patched release	Oasis Security
Hundreds per second	Password guesses achieved from browser JavaScript against the loopback gateway	Oasis Security
3,984	OpenClaw-ecosystem skills scanned in Snyk’s ToxicSkills audit	Snyk
36.8%	Of those skills carried at least one security flaw (1,467 skills)	Snyk
13.4%	Carried a critical-severity issue (534 skills)	Snyk
76	Confirmed malicious payloads after human review	Snyk
10.9%	Of ClawHub skills contained hardcoded secrets	Snyk
341	Malicious skills attributed to the ClawHavoc campaign, 335 from one coordinated operation	SkillSieve, arXiv:2604.06550
49,592	Real ClawHub skills triaged in the largest published academic run	SkillSieve
10	Risks in the OWASP Agentic Skills Top 10 v1.0-2026	OWASP

Those two halves — one local runtime bug, one ecosystem-wide audit — are the same problem seen from opposite ends. Neither is answerable without knowing what is installed.

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.

Figure: nothing is installed at any step. The victim only visits a page while an agent is running.

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 — inside a day of responsible disclosure. 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. CISA’s software bill of materials program has spent five years arguing one point: you cannot patch, verify, or replace dependencies you cannot name. Its 2024 Framing Software Component Transparency revision sets the minimum data fields an SBOM entry carries — supplier, component name, version, unique identifier, dependency relationship, author, timestamp — and an A-BOM needs the equivalent for a broader class of dependency.

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 — the mechanism we took apart in MCP tool poisoning via hidden metadata. 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.

The OWASP Agentic Skills Top 10 (v1.0-2026, still an incubator project) names all four failure modes in its list of ten: AST01 Malicious Skills, AST02 Supply Chain Compromise, AST03 Over-Privileged Skills, AST07 Update Drift and AST09 No Governance. Update Drift and No Governance are inventory problems by definition — you cannot detect drift from a state you never recorded.

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

Figure: package names are not enough. Each layer carries different trust-relevant fields.

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. We covered that side in our ClawHavoc post-mortem — the campaign accounts for 341 of the malicious skills catalogued in the SkillSieve triage paper, 335 of them from a single coordinated operation. 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 — and, per Snyk’s audit, the layer where 13.4% of published skills carry a critical-severity issue.

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.

1. Enumerate the agents. 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.
2. Record what each one holds. For each agent: 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.
3. 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?
4. 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.

Frequently Asked Questions

What is an Agent Bill of Materials?

An A-BOM is a current, exportable inventory of everything one AI agent can load or call: installed skills with their versions and tree hashes, plugins, connector OAuth scopes, MCP servers and their tool schemas, paired devices, credentials, egress domains, owners and change history. The term comes from Radware’s June 2026 write-up on the invisible supply chain AI agents create.

How is an A-BOM different from an SBOM?

An SBOM lists software components and versions; CISA’s 2024 Framing Software Component Transparency sets its minimum fields. An A-BOM covers a wider class of dependency that a package manifest never sees: natural-language skills, MCP tool descriptions, OAuth grants, runtime-discovered tools, browser automations and paired devices. Both exist for the same reason — you cannot patch what you cannot name.

Are AI agent skills a security risk?

Measurably. Snyk’s ToxicSkills audit of 3,984 skills found 36.8% carried at least one security flaw, 13.4% a critical-severity one, 10.9% hardcoded secrets, and 76 confirmed malicious payloads after human review. The OWASP Agentic Skills Top 10 ranks Malicious Skills (AST01) and Supply Chain Compromise (AST02) as the top two risks in the category.

Is OpenClaw safe to run now?

The specific ClawJacked chain was fixed within 24 hours of Oasis Security’s February 26, 2026 disclosure, so a current build is not vulnerable to it. The durable question is different: a local agent still holds credentials and can act, so treat its gateway as a real network interface — generated credentials, loopback rate limits, explicit device approval, and an inventory of what it is paired with.

What should an A-BOM record for each skill?

Six fields carry most of the value: publisher, source repository, version, tree hash of the installed files, the scan verdict bound to that hash, and the high-risk behaviours the scan found (shell execution, credential-file reads, outbound network calls, memory writes). That set is enough to answer “did this artifact change?” and “which agents are affected?” in one query.

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.

More on the agent supply chain: all supply-chain coverage · ToxicSkills: the first skill-ecosystem audit