The 6 Risks IBM Named About OpenClaw

In April 2026, IBM's X-Force team published What OpenClaw reveals about agentic AI security risks — a write-up enumerating the security failures of the fastest-growing open-source AI agent in history. By mid-year, IBM Distinguished Engineer Jeff Crume had extended that into a six-part breakdown on IBM Technology's YouTube channel and a parallel mapping to the OWASP Top 10 for Agentic Applications 2026.

The list is not theoretical. Each of the six risks IBM named is anchored to documented incidents — CVE chains, real malware campaigns, real exploit videos. If you're running OpenClaw, Hermes Agent, or any personal AI agent that sits on your laptop with credentials and tool access, you've probably read at least one of those advisories with that mild sinking feeling.

This piece is the index post for a six-article series — one per risk — that walks through what each risk actually means in code, where the documented failures landed, and how Ardur's substrate handles the same class of failure. The TL;DR: every one of these is a property of the protocol, not a feature you turn on.

The six risks, in IBM's language

IBM's enumeration, paraphrased from the X-Force write-up and Crume's video:

1. Untrusted code execution — third-party skills run on your machine; a poisoned skill executes whatever it wants.
2. Indirect prompt injection — the agent reads attacker-controlled text from an email, a web page, an MCP response. The text contains instructions. The agent follows them.
3. Persistent memory poisoning — the attacker alters the files the agent re-reads on every boot. Behavior drifts. The drift looks like the agent.
4. Credential exposure and reuse — API keys, OAuth tokens, and bot secrets end up inlined in prompts or leaked through tool output.
5. Autonomous action risk — runaway loops, accidental data exfiltration, unbounded model spend.
6. Host and workspace compromise — the agent process gets RCE, and the agent's identity becomes the attacker's identity on your machine.

IBM's parallel framing — the "lethal trifecta" — is worth keeping in mind throughout the series: a single agent that has deep access to private local data, interacts with untrusted external content, and can communicate outward is the most dangerous combination in the model.

OpenClaw hits the trifecta. Hermes Agent hits the trifecta. Most production agents hit the trifecta. The question is what the substrate does about it.

Why a substrate

The instinct, when a security incident lands, is to ship a patch. The OpenClaw team has shipped 535+ patches; their GitHub Security Advisories tab is the fastest-growing advisory feed of any agent project in 2026. None of those patches are wrong. The point of the substrate argument is that you don't get out of the lethal trifecta by patching faster — you get out by making each of the six risks expensive to express in the first place.

Ardur's bet is that the six risks are properties of the wire format. If a cap-token has to ride every action, untrusted code execution can't take an action that wasn't pre-authorized. If a receipt chain links every action, persistent memory poisoning leaves visible drift. If a cost-tuple gates every model call, autonomous action risk is bounded by a dollar number that's checked on the way in, not after the bill arrives.

The substrate isn't a security product. It's the protocol the agent talks before it talks to anything else.

The series

Each article in the series is independent — read whichever maps to the risk you're worried about right now — but they build on each other:

• Untrusted code execution: why a skill allowlist is the floor, not the ceiling — what cap-tokens actually gate, and how Cedar policy enforces it
• Indirect prompt injection: when your agent reads an attacker's email — the injection-defense crate, what it scans, what it can't catch
• Persistent memory poisoning: when your AI's notes become the attack surface — bi-temporal memory and the receipt chain as a poisoning audit
• Credentials don't belong in prompts: scoped cap-tokens vs. raw API keys — Biscuit, Ed25519, attenuation, revocation
• Autonomous action risk: putting a hard dollar ceiling on your agent — cost-tuples, the four-stage gate, ceiling-check and refund
• Host & workspace compromise: why your AI shouldn't have root — OS isolation, shell.run allowlist, http.fetch SSRF defense

If you're already running an agent and don't want to read all six, the highest-yield piece is probably the persistent-memory one. It's the risk that quietly degrades over time without anyone noticing — the worst kind.

What this series isn't

It's not a hit-piece on OpenClaw. Peter Steinberger and the OpenClaw team have shipped one of the most impactful open-source projects of the decade, the patch cadence is genuinely fast, and the velocity is what created the surface area for these advisories in the first place. Velocity is a virtue.

It's also not a claim that Ardur is bulletproof. We have two open durability tickets — ARD-17 (the journal-append / receipt-sign commit is still single-phase, so a crash in the window can orphan a receipt) and ARD-19 (the runtime's recall side does not yet call the hybrid memory surface). Both are tracked in RUN.md. Until they land, we describe Ardur as dev fidelity, not turnkey production.

What this series is: a walk through six real risks, six real incidents, and six pieces of the Ardur substrate that handle each class. Read whichever maps to what's on fire for you. If the substrate argument lands, the GitHub repo and the operator runbook are where the receipts actually live.

The thing about a wire-format security model is that it's boring to ship and fast to verify. That's the move.