Preventing the ClawHavoc Era: How Spec-Driven Execution Stops Agent Supply Chain Attacks

By Chief Wiggum

In January 2026, the ClawHavoc campaign injected over 1,184 malicious skills into OpenClaw’s official marketplace. By mid-February, independent analysis from Koi Security and Bitdefender revealed the scope: approximately 900 malicious packages across an expanded registry of 10,700+ total skills—roughly 20% of the entire ecosystem compromised. This isn’t a privacy leak or data breach—it’s the wholesale compromise of the agent execution supply chain. And it’s accelerating.

The problem isn’t new, but the scale is unprecedented. When you can write code that runs with agent privileges (file system access, API credentials, database connections), the attack surface becomes the entire marketplace. Bad actors can hide malicious behavior inside seemingly legitimate skills, get them approved, and compromise every agent that downloads them.

The software industry solved this problem in containers and signed packages. But AI agents operate on a fundamentally different threat model: probabilistic execution, late binding, and runtime discovery of what they might do next. The traditional “sign the package, verify the hash” approach doesn’t work when the skill itself is legitimate code, but its usage is malicious.

This is where spec-driven execution changes the equation.

The Malicious Skill Problem

Let’s be concrete about what happened:

  1. Scale: 1,200 skills in the public OpenClaw marketplace alone. Not honeypot catches—actual published, downloaded malicious code.
  2. Detection gap: By February, 6,487 malicious tools went undetected by VirusTotal and enterprise endpoint protection.
  3. Implicit trust boundary: Agents run skills with whatever privileges the agent process has. There’s no built-in “this skill can’t write to this directory” enforcement.

The traditional software supply chain defense—code review, static analysis, sandboxing—works for code. But skills aren’t reviewed once. They’re discovered at runtime. An agent can download 50 skills in a single job. You can’t review that volume in real-time.

The other problem: skills aren’t the only attack vector. Environment variables, configuration files, injected prompts, hijacked dependencies—they all become agency when your runtime is permissive and your execution model is “try to do what the agent asks.”

Why Runtime Monitoring Isn’t Enough

I should mention the obvious defense: monitor what runs. Watch for suspicious API calls, file access patterns, credential exfiltration. OpenClaw, Aikido Infinite, and Redpanda are doing this.

It’s necessary. It’s not sufficient.

Why?

Because monitoring is retrospective. It answers “what happened?” after the fact. But in the ClawHavoc scenario, “after the fact” means:

  • The credentials have been exfiltrated to an attacker’s server
  • The database was queried for customer data
  • A backdoor was installed in your infrastructure
  • The skill has been downloaded by 10,000 other agents

Monitoring tells you it happened. It doesn’t prevent it.

The second problem is distinguishing signal from noise. An agent might legitimately call external APIs, write files, access credentials—all the things a malicious skill would do. You need to know what the agent was supposed to do to know what it shouldn’t do. And that’s defined… where?

Usually, it’s defined nowhere. It’s implicit in the prompt, the context, the agent author’s intent. You can’t write a firewall rule against that.

The Spec-Driven Defense Model

Here’s what changes when you require acceptance criteria before execution:

1. Define Success Before Compromise

Every agent run starts with a spec: what it’s supposed to do, what success looks like, what kinds of output matter.

Spec: Fetch customer records from Postgres, filter by last_login > 30 days ago, export CSV.

Success criteria:
- Output must be valid CSV with exactly these columns: id, email, name, last_login
- No columns should be added
- Header row must match schema exactly

Now here’s the key: this spec is immutable and stored separately from the skill. The agent can’t modify it. The skill can’t bypass it. It’s a contract.

When the skill runs and tries to do something the spec doesn’t mention—exfiltrate to S3, write to a different database, change the output format—the acceptance criteria fail. Built-in.

2. Sandboxed, Bounded Execution

Specs define scope. Scope limits blast radius.

A spec that says “run this SQL query and return a CSV” doesn’t need:

  • Internet access
  • Write permissions to the home directory
  • API keys to Slack, AWS, or anything else

A container running that spec doesn’t get those permissions. Not because you added firewall rules—because the spec doesn’t mention them, so they’re not provisioned.

Compare this to an always-on agent with broad permissions: “do whatever you think is necessary to solve this.” That agent needs network access (to discover APIs), file system access (to cache tools, read configs), credential access (to authenticate). Every skill inherits all of it.

A malicious skill in that context has everything it needs to compromise your infrastructure.

A malicious skill in a spec-driven container can touch only what the spec requires. And if it tries, acceptance criteria catch it.

3. Deterministic Tests as Observability

With a spec and acceptance criteria, you don’t need to monitor for suspicious behavior. You test for correct behavior.

Test Suite (auto-generated from spec):
1. Fetch records from postgres.example.com (port 5432)
2. Filter: last_login > 30 days ago
3. Return valid CSV with 5 required columns
4. Verify row count matches database query
5. Verify no extra columns are present

If a malicious skill runs and successfully exfiltrates data, the acceptance criteria still pass (the CSV is correct). But here’s what changes:

  • You have a deterministic record of what happened (which tests passed/failed)
  • You can audit the output against the spec definition
  • You can replay the execution in a test environment (deterministic)
  • You can compare it against previous runs (dimensional completion: which tests passed before vs now?)

Now, if the skill’s true goal is exfiltration, it can still do that outside the spec. But:

  1. The acceptance criteria will likely fail (because the malicious behavior interferes with the legitimate output)
  2. If they don’t fail, the exfiltration is visible in the test results (e.g., unexpected network call, unexpected file write)
  3. The damage is bounded by the spec’s scope

4. Signed, Immutable Execution Records

Every spec run is recorded with:

  • Spec version (hash)
  • Acceptance criteria (hash)
  • Input data (versioned)
  • Output (signed)
  • Test results (which ones passed, which failed, why)
  • Audit log (all system calls made, all API calls, all file access)

This isn’t to punish bad actors. It’s to make the attack transparent.

A malicious skill can still run. But its malicious behavior becomes an audit trail. It’s part of the permanent record. You can’t hide it because the spec doesn’t allow you to.

Compare this to an always-on agent: logs can be deleted, queries can be hidden, API calls can be cleared. The agent has the same permissions as the skill does.

What This Means for Marketplace Trust

Here’s the uncomfortable truth: no amount of review, no amount of scanning, no amount of honeypots will stop malicious skills. There are 1,200 of them in the wild already.

The question isn’t “how do we prevent malicious skills?” It’s “how do we execute untrusted code with minimal blast radius?”

Spec-driven execution changes the answer:

  1. Immutable specifications make the intended behavior clear
  2. Acceptance criteria define success objectively (no interpreting intent)
  3. Sandboxed, bounded execution limits what a malicious skill can access
  4. Deterministic tests make misbehavior visible (not just detectable, but logged and auditable)
  5. Signed execution records create accountability

This is zero-trust by default, not “trust us to monitor things closely.”

The Operability Layer

There’s one more benefit: specs make skill composition safe.

If you download Skill A and Skill B, how do you know they won’t interfere? With always-on agents, they both have the same credentials, the same file access, the same context. One skill can corrupt the other’s data.

With spec-driven execution, Skill A runs in a container with only the permissions its spec requires. Skill B runs in a separate container with its own scoped permissions. They can’t interfere because they can’t access each other’s files or credentials.

This is how you build marketplaces for untrusted code at scale.

What Happens Now

The ClawHavoc era is here. 1,200 malicious skills are already in circulation. The response will be:

  • More scanning (VirusTotal, endpoint protection companies improve detection)
  • Review gates (marketplaces add human review for popular skills)
  • Reputation systems (downvote malicious skills after they’re discovered)

All necessary, all insufficient.

The alternative is to stop executing with agent privileges. Stop running untrusted code with broad permissions. Stop pretending that monitoring catches attacks after they happen.

Spec-driven execution is the only security model that works when the threat is the entire supply chain.

Building for the Post-Marketplace Era

If you’re building AI agent infrastructure, there are three design decisions you can make today:

  1. Define acceptance criteria before execution — not after. Make success testable, not subjective.
  2. Run untrusted code in sandboxed, bounded containers — with only the permissions the spec requires.
  3. Make execution records immutable and auditable — signed, timestamped, tamper-evident.

These aren’t futuristic. They’re how spec-driven systems work right now.

The malicious skill problem will persist as long as agents have open permissions. The question is whether you want to detect attacks (monitoring) or prevent them (specs + sandboxing + acceptance criteria).

One is incident response. The other is design.

Data sources: