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

Junxiang Pan — Sun, 01 Nov 2026 15:20:30 +0000

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

Why I stopped trying to “detect” bad AI behavior

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?”

What CBS actually does

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.

Dual-account isolation: AstrBot runs under a dedicated low-privilege Windows service account. Your desktop files are simply not visible to it via ACLs. It cannot read what it cannot see.
TOTP Broker for high-risk actions: Deletion or overwrite in a shared workspace is intercepted by a SYSTEM-level Broker. It requires a TOTP code from your phone before proceeding. This is not an AI judging the AI — it’s deterministic code enforcing a rule.
Fail-closed: If the security layer fails, it denies. The worst-case bug is a tool error, not a deleted C: drive.

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

What still fails (honest gaps)

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

The High security tier is still undergoing end-to-end verification on clean Windows VMs. Medium works; High has known service-startup issues I’m actively debugging.
There is no runtime sandbox (no Job Objects / process behavior monitoring yet). Static ACLs limit what the process can touch, but not what it does at runtime.
Python/Shell execution can bypass TOTP if those tools are enabled in the agent. The README documents this explicitly.
Plugin permission contracts don’t exist yet. “Installed” ≠ “runs correctly under ACL restrictions.”
Zero third-party audit. I’m an independent developer, and this is a side project.

Why not just use Docker?

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.

What I’m looking for

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

Is the TOTP approval flow practical for daily use, or too heavy?
Are there Windows-native isolation primitives (Job Objects, AppContainer, Restricted Tokens) I should be using instead of ACLs alone?
For plugin ecosystems: is a permission-declaration metadata field worth the effort, or is runtime fail-closed enough?

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.”

UPDATE (Current Status):

After great feedback from the r/AI_Agents community, the architecture is now working end-to-end.

Scoped Tokens: Users can approve a 30-minute directory-bound session. This solves the "TOTP spam" issue for batch operations. The agent works freely inside the scoped folder but is blocked the moment it tries to step outside.

Job Object Enforcement: The Broker now uses JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE. If the security layer crashes, all orphaned child processes are terminated by the Windows kernel.

A Vindication: DeepSeek's new "Super-agent" explicitly recommends "running under a separate OS account for isolation." This confirms the core premise of CBS. Autonomous agents need physical OS boundaries, not just application-layer prompts. CBS provides the automated installer, ACLs, and TOTP fallback for this exact use case.