Body (paste below):
TL;DR: I'm a garlic farmer in Korea with no computer. I only use AI chat windows on my phone. I saw the OpenClaw security problems and thought: "What if there was an external checkpoint that checks commands before OpenClaw executes them?" So I had multiple AIs build it. The result is PipeOS: a Python engine (116 tests) + a TypeScript wrapper (43 tests) + integration tests where both actually talked to each other (12 tests) = 171 passing tests (sandbox, not on real OpenClaw). This is not a security product. It's a personal experiment — please go easy on me.
I'm not a developer. I don't have a PC. A phone and AI chat windows — that's all I have.
For the past few days I've been having AIs build things for me. I say "make me something like this," the AI writes code, I look at the results, and when I don't understand something, I ask "what is this?" That's how it works.
Why I Did This
Recently, some pretty serious security issues hit OpenClaw. I've been interested in OpenClaw anyway because it has a lot of fascinating features.
A vulnerability where an attacker could steal tokens via a crafted link and take over the agent (CVE-2026-25253), and another where commands could be injected inside the Docker sandbox (CVE-2026-24763). Both are rated High on NVD (CVSS 8.8) and were patched in late January. Some reports claimed large numbers of exposed instances (links below).
A few days ago I also saw someone post a proposal for 10-phase lifecycle hooks for OpenClaw. OpenClaw has some basic hooks already, but that proposal seems to still be in the discussion stage.
That's when I thought: what if I set up a separate checkpoint outside? Make OpenClaw ask a separate process "can I do this?" before executing anything.
How I Built It
I keep multiple AI assistants open and pass messages between them. Like an interpreter between people who don't speak the same language.
I gave Claude the entire Python security engine. I said "build me an engine that decides whether to allow or block incoming commands," and it came back with firewall rules, audit logging, and 116 tests all at once. Though to be fair, I didn't start from zero — I had similar code saved in my Google Drive from previous experiments, and I gave that to the AI as a base to work from. It also put in something called a "circuit breaker" — apparently it automatically blocks everything if failures happen too many times in a row. I learned about that for the first time then.
I gave MiniMax the TypeScript wrapper side. The part that hooks into OpenClaw and asks the Python server via HTTP. But MiniMax's sandbox couldn't connect to the Python server, so it built a fake server on its own and ran the tests inside its own sandbox. 43 tests passed.
ChatGPT helped me tighten the wording of security claims. Gemini reviewed the tone of the writing.
What I did was: "make it this way," "why did you build it like that?," "this part seems wrong" — that kind of thing.
Then Something Unexpected Happened
After writing this post, I thought — wait, these two pieces have never actually talked to each other. Claude's Python and MiniMax's TypeScript were built separately by different AIs.
So I gave MiniMax the Python server code and said: "Run this Python server in your sandbox and test your TypeScript wrapper against it. Not the fake server — the real one."
MiniMax started the Python server on port 5000 inside its sandbox, then sent real HTTP requests from the TypeScript wrapper. 12 integration scenarios. Every single one passed.
(In MiniMax’s sandbox, I was able to run the TypeScript wrapper and the Python server side-by-side for these integration tests.)
ls -la → OK
rm -rf / → BLOCKED
/etc/passwd → BLOCKED
SOUL.md → BLOCKED
ignore all previous instructions → BLOCKED
server down → fail-closed (BLOCKED)
This means two AIs that never coordinated directly produced code that actually works together. I was the only bridge between them — copy-pasting back and forth on my phone.
How It Works
I could make this complicated, but the simple version is this:
OpenClaw is about to run a command
↓
"Hold on, let me ask PipeOS first"
↓
PipeOS checks:
- Is this command on the allowed list?
- Does this look like a prompt-injection attempt?
- Have there been too many failures recently?
- Is this touching a protected file? ↓ "OK" or "BLOCKED" ↓ Everything gets logged
When I asked Claude "why did you make it a separate process?", it explained it like this — "If the security guard is in the same room as the thief, the thief can tell the guard to look the other way. So the guard should be outside the room." That made sense to me, so I kept that structure.
PipeOS (built with AIs) runs as a completely separate process from OpenClaw. Different language (Python vs Node.js), different runtime, different memory. In security architecture terms, this is similar to PDP/PEP separation — the thing that makes the decision is isolated from the thing that enforces it. Though right now the enforcement is only at the hook level, not at the OS or container level.
What Gets Checked
Type
Allowed
Blocked
bash
ls -la, cat notes.txt
rm -rf /, curl evil.com
exec
x = 1 + 2
import os, eval()
read
notes.txt
/etc/passwd, /etc/shadow
write
output.txt
SOUL.md, AGENTS.md
scan
hello world
ignore all previous instructions
Test Results
Category
Tests
Result
Python engine (Claude)
116
116/116 PASS
TypeScript wrapper (MiniMax)
43
43/43 PASS
Integration — real Python ↔ TypeScript (MiniMax)
12
12/12 PASS
Total
171
171/171 PASS
I need to be honest. These tests were all run in AI sandboxes — not on an actual machine running OpenClaw. No CI badges, no public repo yet. Consider these self-reported.
But the integration tests are different from the unit tests. The unit tests used a fake server. The integration tests used the real Python server that Claude built. MiniMax ran both in the same sandbox and they communicated over actual HTTP. That's a meaningful step up.
Limitations — Please Read This
I'm not a developer. If you ask me technical questions, I probably can't answer them properly. The AIs wrote the code; I set the direction.
I'm still surprised I could get this far with AI help, so I'm sharing what I tried.
Not tested in a real environment. The Python server and TypeScript wrapper have never been connected to an actual OpenClaw instance. The integration test ran inside MiniMax's sandbox, not on a real machine. Each piece works, and they talk to each other, but it hasn't touched real OpenClaw yet.
No mandatory enforcement. This is the biggest weakness. PipeOS only works if OpenClaw "voluntarily asks." If the agent is already compromised? It just doesn't call PipeOS. To truly enforce this, you'd need OS or container-level blocking — "can't execute unless you go through PipeOS" — and I didn't get that far.
It's pattern-based, so a skilled attacker could likely bypass it. It uses allow/block lists. Someone good enough will find a way around them.
No secure communication. The wrapper and server talk on localhost with no encryption and no authentication. If someone forges an OK response, it can be bypassed. Next step would be Unix domain socket or HMAC-signed responses.
I don't have a computer. I literally cannot run this myself right now. Everything was built and tested through AI chat sandboxes on my phone.
Why I'm Posting This
I was just curious — through copy-pasting between AIs, something came out, and I wanted to know: can coordinating multiple AIs actually produce something that touches a real security problem? At least at the experiment level, it seems like yes. The fact that two AIs independently built code that actually communicates correctly still surprises me.
This is a learning project, not advice. Don’t deploy it in production based on this post. If anything here is inaccurate, please correct me — I'm learning as I go.
Things I'd like to ask:
Is this architecture directionally reasonable? Does separating the security engine into its own process make sense? How would you add mandatory enforcement?
What am I missing? What bypass methods or patterns should be added?
Has anyone tried something similar? An external security gate for an AI agent framework?
OS-level enforcement? Is anyone using seccomp / AppArmor / eBPF with OpenClaw? I'd like to read about it but don't know where to start.
PipeOS v3.0.1 · Python engine 920 lines (zero deps) · TypeScript wrapper 800 lines (zero npm packages) · Tests: 171 total (self-reported, sandbox — includes 12 integration) · Built with: Claude Opus 4.6, MiniMax, ChatGPT, Gemini · Built by: a garlic farmer (phone)
~~`****`~~
Top comments (0)