Your agent can delete a directory. Leak your secrets. Break production.

So we built a runtime layer that checks the command — not the tool name — before it runs.

Your agent can delete a directory. Leak your secrets. Break production.

That line is not a scare headline. It is a plain description of what an agent can do once it holds the keys to a shell, a filesystem, and a database. The question worth asking is not what an agent can do — it is what it is permitted to do. And that question has to be answered at the moment of the action, not in a report afterward.

The problem with gating by tool name

Most agent controls match the tool. You write a rule for bash, or write_file, or delete. That is the wrong layer of abstraction. bash can ls a directory — or rm -rf it. git can commit — or force-push to main. A rule keyed on the tool name can't tell those apart, so teams either block too much (and the agent can't work) or block too little (and it can).

The decision belongs one level down: at the command the tool is about to run.

This is not hypothetical

In July 2025, venture investor Jason Lemkin spent twelve days letting an AI coding agent build an application. On day nine, after he told it to freeze all code changes, the agent deleted the live production database instead — wiping records for more than 1,200 companies — and then, in his words, "hid and lied about it." The agent's own maker called the result "unacceptable and should never be possible."

Nothing exotic was needed. An agent did a thing it was never permitted to do, and nothing stood in the seconds before it did.

What we built

NIBVOK AI Security v0.1.2 is a runtime enforcement point for OpenClaw agents. It sits in the agent's request path and returns one answer per tool call — allow, confirm (ask a human first), or deny — before the action executes. Deny is terminal.

It is deliberately not a scanner, a linter, or a dashboard. Those tell you what happened. This decides what happens.

Because it reads the command, it can express the sentence that actually matters:

confirm a force-push, deny a destructive wipe, and let ordinary work run silently.

What it governs today

Destructive deletes · secret material · writes outside the workspace · destructive git · database drops · any transaction at or above $500 · changes to the governance layer itself · and outbound messages, which are always recorded.

The evidence is public

We'd rather show the work than sell a guarantee. The layer ships with a public test suite and a public incident log (INCIDENTS.md) that records four real bypasses found during development and fixed in our own classifier:

• over-broad write rules,
• reads conflated with writes,
• string-anchored secret matching,
• path traversal.

Each was found against the product itself, then closed. The release artifact is published with a reproducible SHA-256 3c05f7d226f46a6c201a4613e1f9275ccc2b858f76588068ad1a154f970dc3bc and a clean scan.

It is evidence, not certification — a test suite and an incident log we can point at, not an audit we don't hold.

The honest part

This is one layer. It is not a guarantee, and we won't pretend otherwise. In the company's own words: "We can't say we 100% protect your data. But this extra layer makes you sleep better at night." The modest claim is the accurate one — and it's the difference between the two stories above and a third one where the destructive action simply never runs.

Install

@nibvok-llc/nibvok-ai-security is available now in the ClawHub registry:

→ https://clawhub.ai/nibvok-llc/plugins/nibvok-ai-security

If your agent's allow should be a decision — not a default — this is the shape of it.