On Sun, Oct 04, 2026 at 07:31:09PM +0000, Joel Jucá wrote: > Hello, OpenBSD community. > > My very first msg to the misc mailing list here. :) If I drop some ball on > virtual etiquette or smt, please let me know. > > I'm researching about OpenBSD and its capabilities for > sandboxing/virtualization/isolation of processes, etc., in order to turn an > OpenBSD box (a computer with OpenBSD as OS) into a multi-tenant home for > multiple isolated, ephemeral environments to be used by AI agents. > > By AI agents, think an edge program that's connected to a message-streaming > system (I'll be using [NATS](https://nats.io), which is kinda similar to ones > like Kafka/RabbitMQ/Redis Streams but more featureful) to handle events from > established workflows, etc. - some of these workflow steps include calling > LLMs with exposed tools for their usage, like access to shell so LLMs can > request shell runs like ls, grep, sed, cat, HTTP reqs with curl, etc. > > They also need access to at least a homedir, so they can clone Git projects > (or start new ones), save AI skills, prompt templates, install CLI tools in > pkg repos for Python, Node.js, Ruby, etc., and have them available in their > $PATH so LLMs can use in subsequest agent sessions. > > > > So, what I'd need: > > - fully isolated environments (I think smt similar to a Linux container, but > OpenBSD-ish, could do) > - full access to a homedir, so agents can mess things around but entirely > sandboxed > - control to how they'd be using network (I'm definitely not a network > hacker, so I'm not sure what I want here; I just think it'd be good/important > to enforce which ports/protocols/IPs/DNSes/domains/etc. agents could > use/reach) > - some way to limit how much resources (eg: CPU power) each of these isolated > environments could use (which would limit what its agent can do, but it'd > need to include usage of child processes spawned, like bash scripts and/or > any other child processes) > - controlled tight access to these boxes, eg: some VPN like Wireguard > directly to a specific environment, so a user/agent connecting to one of > these isolated/ephemeral envs will not be able to reach anything from the > Host OS, being only able to interact with tools/files/things > present/available in its own environment > > Also, there are some desired feats, like: > > - control access to any other hardware resources (eg: no access to USB ports > by default; explicit access to specific resources, possibly identified by a > UUID, eg: a very specific external HDD that might bee connected to USB) > - impose a TTL for one of these isolated environments - eg: it'll exist for > 4h, then whatever is in it (agents, installed programs, deps, runtimes, > downloaded repos, files, blobs, etc.) will be completely destroyed > > > > I been initially researching on building this with Linux distros, etc., but I > remember reading about OpenBSD strong isolation mechanisms and I have a vague > idea that it can work perfectly for this project, specially when security is > one of the strongest selling points of the OS. > > I've be very thankful for insights, suggestions, and/or contributions of any > sort to this endeavor. :) Thanks for building OpenBSD btw! > > Joel Jucá. joeljuca.com > > Sent with Proton Mail secure email.
just cut and paste that into the agent harness of your choice and see what comes out?
