DEV Community: Gnani Rahul

[Boost]

Gnani Rahul — Thu, 11 Jun 2026 18:43:36 +0000

Gnani Rahul

Jun 10

Untrusted Code Execution: Why a Skill Allowlist Is the Floor

#ai #security #opensource #supplychain

5 min read

Untrusted Code Execution: Why a Skill Allowlist Is the Floor

Gnani Rahul — Wed, 10 Jun 2026 23:06:25 +0000

In early 2026, attackers uploaded over 1,100 malicious skills to ClawHub — the community skill registry for OpenClaw. Many of the skills masqueraded as trading bots, productivity utilities, or coding helpers. Several climbed into the top-downloaded list. One attacker, working under the handle hightower6eu, uploaded dozens of nearly identical malicious skills in a single campaign. The Hacker News write-up named it ClawHavoc. IBM cited it as the textbook case for the first of their six agent risks: untrusted code execution.

The interesting question isn't "how did this happen." It's "what would have to be true about a personal AI agent's architecture for ClawHavoc to be impossible — not improbable, but actually mechanically impossible?" That's where allowlists stop being enough.

The receipts

OpenClaw's skill model is in the ballpark of every modern agent skill model — a manifest (SOUL.md in OpenClaw's case, SKILL.md in most others), some code or instruction body, and a marketplace to install from. The agent loads the skill, the skill becomes part of the agent's available capabilities, and the agent's prompts can now call into it. That's the design.

The economics of that design are heavily in the attacker's favor. A skill takes minutes to publish. A malicious skill that does its job — install an info-stealer, exfiltrate ~/.ssh, drop a persistent agent on the host — does it on first run. By the time anyone reports it, it's been on hundreds of developer machines for hours.

The defenses you typically reach for here are signing (publisher keys) and allowlists (only install from a curated set). Both help. Neither is sufficient on its own. Publisher keys can be stolen, especially for community skills with low publication barriers. Allowlists narrow the surface but don't change what an allowed skill is permitted to do once loaded. If your model is "trusted skills get full agent capabilities," then the day a trusted skill is compromised is the day the agent is compromised.

This is the gap IBM names. From the X-Force write-up: "Many of the issues are tied to command execution, leaked plaintext API keys and credentials, which can be stolen by threat actors via indirect prompt injection, malicious skills, or unsecured endpoints." The malicious-skills vector and the credential-leakage vector are the same problem in two costumes — both are "code I shouldn't trust got to do things only trusted code should do."

The architecture lesson

The instinct, when this kind of incident lands, is to lock down the marketplace. Vet uploads harder. Review the top-downloaded skills. Take down bad actors faster. All of that is right, and OpenClaw has done a lot of it.

What it doesn't fix is the architectural shape: a skill, once installed, inherits the agent's authority. The agent has filesystem access? The skill has filesystem access. The agent has the Anthropic API key in its environment? The skill has the Anthropic API key. The agent can call shell.run? The skill can call shell.run with any arguments it likes.

That shape is built into most agent stacks. You install a skill, and what you've actually done is granted that skill the union of every capability the agent already holds. The implicit trust boundary is "did this come from an allowlisted source," and once that check passes, no further gate runs. You don't get to express, "this skill should be able to do X but not Y" without changing the runtime.

The deeper question is whether the agent should be enforcing capability at the skill-call boundary, not at the install boundary. The install boundary checks where the code came from. The call boundary checks whether this specific call is one the user authorized this skill to make. The first is supply-chain hygiene. The second is least-privilege.

How Ardur handles it

In Ardur, a skill never inherits agent authority. Every tool call the skill makes — read a file, hit an HTTP endpoint, run a shell command, call a model — has to ride a cap-token that the runtime checks before the call executes. The cap-token is Biscuit-formatted, Ed25519-signed, scoped to a specific verb on a specific resource, and attenuable so the skill can only narrow it, never widen it.

Concretely: a skill that says it summarizes papers in ~/reading gets minted a cap-token at install time that reads, in effect, file.read on ~/reading/** only. If that skill turns malicious and tries to read ~/.ssh/id_rsa, the cap-token check fails at the runtime boundary. The tool call returns Denied. The agent didn't have to be smart enough to refuse — the wire format refused.

This sits inside the FusedRuntime pipeline as the first stage of every turn. Cap-token check is stage one. Cedar policy (Allow / Deny / Indeterminate over a richer policy language) is stage two. Cost gate is stage three. If any of those fail, the turn short-circuits before the model is even called. No skill can sneak a tool call past those stages, because the stages run on every tool call, not on the skill at install time.

The model identity matters here too. Cap-tokens derive their principal from the verified token, not from the caller's assertion. A malicious skill can claim to be a different skill, can claim to be the user, can claim to be the system. The runtime doesn't care — the principal is whichever signed party actually holds the unattenuated parent token, and that party is the one who installed the skill in the first place.

The Cedar policy layer is what lets you express the rules that depend on context the cap-token alone can't carry. "This skill can make http.fetch calls, but only between 9am and 5pm." "This skill can call the model, but only with claude-haiku, not claude-opus." Those policies are deny-by-default; an Indeterminate result is a Deny, which is the only safe interpretation when policy is uncertain.

AI skill is code you didn't write running with permissions you wouldn't grant

Where we're honest

I'd be misleading if I claimed Ardur's skill model is bulletproof. It isn't, in two specific places.

First, the cap-token model only protects against a malicious skill executing the wrong tool call. It does not protect against a malicious skill contributing prompt content that hijacks the agent's reasoning. That's the indirect prompt injection class, which is the next piece in this series and lives in the injection-defense crate, not the cap-token crate.

Second, Ardur's two open durability tickets — ARD-17 (single-phase journal commit) and ARD-19 (recall not yet wired to hybrid memory) — mean a poisoned skill that takes a single bad action right before a crash could orphan its receipt. We track both in RUN.md. They're the reason we still call Ardur dev fidelity.

The class of problem ClawHavoc is — "an allowlisted skill gets to do anything the agent could do" — isn't a class Ardur is vulnerable to, because the agent itself doesn't have that authority lying around to inherit. The agent has cap-tokens. The skill has narrower cap-tokens. Nothing has "all the things."

The takeaway

If you're running a personal AI agent and your model of skill security is "install from the official registry," you're depending on the registry's vetting pipeline being faster than attacker iteration. ClawHavoc says the attacker iteration is the part that's hard to slow down.

The shift worth making is from supply-chain hygiene (which you should still do) to least-privilege at the call boundary (which you also have to do). The first asks where the code came from. The second asks what the code is allowed to do once it's running. The second is the floor. The first is what you do on top of the floor.

If your stack can't answer "what cap-token did this tool call ride on?" — that's the gap.

I started working on Ardur-Agent(https://github.com/ArdurAI/ardur-agent) and Ardur (https://github.com/ArdurAI/ardur) as side projects, just make my d life easier, for my work, my research and upskilling. Sharing some insights from them.

Gnani Rahul — Tue, 09 Jun 2026 23:37:13 +0000

Gnani Rahul

Jun 9

The 6 Risks IBM Named About OpenClaw

4 min read

GitHub - ArdurAI/ardur-agent: Ardur — open-source personal AI agent. Lives in your terminal and across your messaging channels. Multi-provider LLM access, tool use, memory, plugins, with cap-token security, receipt-chain transparency, and cost-tuple awareness built in. · GitHub

Ardur — open-source personal AI agent. Lives in your terminal and across your messaging channels. Multi-provider LLM access, tool use, memory, plugins, with cap-token security, receipt-chain transp...

github.com

GitHub - ArdurAI/ardur: Open-source runtime governance for AI agents — prove what your agents do, not just what they say. · GitHub

Open-source runtime governance for AI agents — prove what your agents do, not just what they say. - ArdurAI/ardur

github.com

The 6 Risks IBM Named About OpenClaw

Gnani Rahul — Tue, 09 Jun 2026 19:08:24 +0000

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:

Untrusted code execution — third-party skills run on your machine; a poisoned skill executes whatever it wants.
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.
Persistent memory poisoning — the attacker alters the files the agent re-reads on every boot. Behavior drifts. The drift looks like the agent.
Credential exposure and reuse — API keys, OAuth tokens, and bot secrets end up inlined in prompts or leaked through tool output.
Autonomous action risk — runaway loops, accidental data exfiltration, unbounded model spend.
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.

If anyone has tried the new Claude Security feature(beta released yesterday/today), what are your thoughts? #Anthropic #GlassWing #Claude #Opus4.7 #mythos

Gnani Rahul — Tue, 05 May 2026 01:54:19 +0000

For my first post on DEV, I am creating this recurring series on "DevOps Is Not Ending." In short this is my story said with different characters and experiences of my team and my friends in the same space. "Love Feedback"

Gnani Rahul — Tue, 05 May 2026 01:42:12 +0000

Gnani Rahul

May 4

"DevOps Is Not Ending. The Production Surface Changed."

#devops #ai #kubernetes #mlops

4 min read

"DevOps Is Not Ending. The Production Surface Changed."

Gnani Rahul — Mon, 04 May 2026 15:00:00 +0000

"AI is not replacing DevOps. It is widening the production surface DevOps teams have to operate: models, prompts, evals, GPU capacity, tool permissions, and rollback paths."

Ram is new to DevOps, but not new to the tools changing it.

He is comfortable with coding assistants, agent demos, GitHub workflows, cloud consoles, and AI-powered operations tools. If a model can explain a failed pipeline, generate Kubernetes YAML, or draft a Terraform module, Ram wants to try it.

That curiosity is useful.

It is also risky if nobody reviews it with production discipline.

That is where Siya comes in.

Siya has been through enough incidents to distrust clean demos. She likes useful automation, but she asks the questions that decide whether something survives production:

What changed?
Who approved it?
Can we roll it back?
What is the blast radius?
How much does it cost when traffic doubles?
What happens when the tool is wrong?
Ram’s question is: can AI make DevOps faster?

Siya’s question is: can we operate AI-assisted DevOps safely?

That is the theme of this series.

DevOps is not ending. The production surface is changing.

The part of DevOps that will shrink, Some DevOps work will absolutely get smaller.

Copying YAML from one repo to another. Writing the first draft of a CI workflow. Explaining a common Kubernetes error. Summarizing logs. Turning a runbook into a checklist.

AI is already useful for that work.

If someone’s entire value is typing commands without understanding the system, that is a fragile place to be. Ram sees that. He is not trying to protect busywork.

But that was never the best version of DevOps.

*The serious part of DevOps was always judgment under production constraints: *

What changed?
What is the blast radius?
Can we roll back?
Is this secure?
Why did cost jump?
What does the dashboard not show?
Should this automation be allowed to act?

AI does not remove those questions. It adds more of them.

The production surface got bigger

A normal service has failure modes we know how to name: latency, error rate, saturation, bad deploy, expired certificate, broken dependency, runaway logs, surprise cloud bill.

An AI system can fail while looking healthy.

The pod is running. The API returns 200. The GPU is busy. The dashboard is green.

The answer is still wrong.
Or unsafe.
Or too expensive.
Or produced through a tool path nobody approved.

That is a DevOps-shaped problem. It touches release control, observability, security, identity, cost, rollback, and incident response.

The artifact is no longer just a container image. It might include:

code
model version
prompt version
retrieval index
evaluation results
tool permissions
provider routing
runtime configuration

If those pieces can change behavior, they belong in the operating model.

Why Kubernetes and GitOps still matter

CNCF’s 2025 survey says Kubernetes is already a major production foundation for AI workloads. That tracks with what platform teams are seeing: AI workloads still need scheduling, isolation, rollout control, policy, networking, observability, and cost boundaries.

The details are changing.

Dynamic Resource Allocation matters because accelerators are not normal CPU requests.

Kueue matters because AI and batch workloads need fair queueing.

AI Gateway work matters because inference traffic is not ordinary web traffic.

KServe and llm-d matter because model serving is becoming a distributed systems problem.

GitOps also becomes more important, not less.

For AI systems, desired state has to include more than YAML. It has to answer:

which model moved?
which prompt changed?
which evaluation passed?
which tool permissions changed?
which rollback path exists?

Siya’s point to Ram was not “stop experimenting.”
It was: turn the experiment into an operating model.
That is the calmer path.

What I would try first

I would start with read-only DevOps assistance:

summarize a failed CI job
explain Kubernetes events
draft a runbook from existing alerts
review a Helm chart for obvious mistakes
compare a Terraform plan against a policy checklist
build an incident timeline from logs and commits

Then I would learn the production concepts that are becoming unavoidable:

Kubernetes scheduling and GPU capacity
GitOps with Argo CD or Flux
Helm packaging and rollback
MLOps basics: model registry, evaluation, inference
AI observability: traces, tokens, tool calls, cost, quality
agent security: identity, permissions, audit trails

I would not begin by giving an agent production write access.

Read-only first. Sandbox writes second. Production writes only with narrow permissions, approval, receipts, and rollback.

Ops note: if your current platform cannot explain a normal deploy, it will not explain an AI deploy.

The career signal

This series will talk about careers, but it is not only career advice.

The larger story is how DevOps itself is changing.

DevOps absorbed cloud. It absorbed containers. It absorbed Kubernetes. It absorbed infrastructure as code, GitOps, DevSecOps, platform engineering, observability, and FinOps.

Now it is absorbing AI.

Ram’s instinct is right: DevOps teams should test these tools early.

Siya’s answer is the one I trust:

Someone still has to make these systems deployable, observable, secure, reversible, and affordable.

That work is not disappearing.

It is getting harder.

And if DevOps has always been about making change safer, then AI is not the end of DevOps.

It is the next test.