HackerTrans
TopNewTrendsCommentsPastAskShowJobs

chrismeurer

no profile record

Submissions

[untitled]

1 points·by chrismeurer·hace 3 meses·0 comments

Show HN: Multi-agent coding assistant with a sandboxed Rust execution engine

github.com
10 points·by chrismeurer·hace 3 meses·3 comments

Show HN: Lula – multi-agent coding assistant with sandboxed Rust exec engine

github.com
5 points·by chrismeurer·hace 4 meses·1 comments

Show HN: Lula – multi-agent coding assistant and sandboxed Rust execution engine

github.com
2 points·by chrismeurer·hace 4 meses·0 comments

comments

chrismeurer
·hace 3 meses·discuss
Just an update to this project:

It is now fully functional, thoroughly tested. Given the multitude of available applications that are probably more practical than Lula, I just wanted to show /share this and hope that it finds at least some application somewhere!

This is another project I'll take this opportunity to share:

https://github.com/christianmeurer/Samantha

Take a look and tell me what you think!

Christian
chrismeurer
·hace 4 meses·discuss
Hey! It's OS-level, no WASM. Three tiers depending on what's available on the host:

The full-isolation path is Firecracker. Each tool execution spins a microVM (1 vCPU, 512MB), and the runner communicates with a statically-linked guest agent over AF_VSOCK — the host process never shells out directly. Inside the VM there's a second allowlist before spawn() is called, so even if you somehow escaped the first filter you'd still hit a second one. In prod the pod itself runs under gVisor (runsc), so the microVM guest kernel is one layer inside gVisor's user-space kernel. That's three kernel-boundary crossings before you touch the real host.

When Firecracker isn't available (dev laptops, restricted CI), it falls back to unshare-based namespace isolation. If that's also absent, it's just process-level controls — allowlist, CWD scoping, cgroup v2 limits (512MB memory, 50% CPU, 256 pids), and a prompt-injection scan that looks for bidi overrides and things like reverse.*ssh patterns.

The hard part honestly wasn't the VM layer, it was the cgroup v2 writes being gracefully no-op'd when not root so the same binary works in dev and prod without ifdef soup. The AF_VSOCK path was also fiddly — you need a raw fd via libc::socket(AF_VSOCK, SOCK_STREAM, 0) and then wrap it into tokio's async I/O, which isn't exactly well-documented (got to fix that).

Kata Containers RuntimeClass is also defined if you want hardware-VM pods instead of gVisor, but it defaults to gVisor since it doesn't require nested virt support on the nodes.

Feel free to ask if you have anymore questions!