Building a Windows-native ACL sandbox for self-hosted LLM agents (and what still fails)

Disclosure: I used AI to help polish the English in this post. The architecture, code, and testing are my own.

I run a self-hosted LLM agent on Windows (AstrBot + a QQ adapter). Like many people in this space, I started by trying to block dangerous commands at the application layer — regex patterns for rm, del, shell keywords, etc.

It didn’t work. A plugin can execute arbitrary code. A prompt injection can rephrase a delete command in a dozen ways. A community member pointed out the obvious: you can’t statically predict what a Turing-complete program will do. Static scanning is not a sandbox.

So I changed the question. Instead of asking “is this action dangerous?”, I asked: “what is this process physically allowed to touch?”

Cyber-Butler-Security (CBS) is a Windows-first, OS-level security layer. It does not try to understand the agent’s intent. It restricts the agent’s physical permissions.

No extra LLM tokens are consumed. The security decisions are made by OS-level code, not by the model.

I’m not going to pretend this is a complete security product. It’s early Beta.

Docker/WSL2 is the gold standard for isolation. But a large portion of the “养鱼” community runs on Windows bare metal — gaming PCs, laptops without virtualization enabled, users who won’t set up containers just to run an agent.

CBS is a pragmatic fallback for that group. It’s not a replacement for containers. It’s a lower-effort “safety net” for people who won’t (or can’t) containerize.

If you’ve run self-hosted agents on Windows, I’d like to hear:

Repo (AGPL-3.0, not monetized, early Beta): https://github.com/JunxiangPan/Cyber-Butler-Security

README has the “not production-ready / High tier unverified” banners at the top. Feedback is welcome, including “this won’t work because X.”