Using bespoke sandboxing seems rather pointless, it will be brittle in ways you aren't going to be familiar with unless you spend time studying the bespoke method. Brittle as in it might break a workflow and you wouldn't know why, or give it permissions you don't understand.

It's better to just study a general sandbox method once and use that.

> Sandbox my-assistant (Landlock + seccomp + netns)

Might as well just use a custom bwrap/bubblewrap command to isolate the agent to its own directory - it will leave wide swaths of the kernel exposed to 0day attacks.

The simplest sandbox method you can use is to just use docker with the runsc runtime (gVisor). And it also happens to be among the most secure methods you are going to find. You can also run runsc(gVisor) manually with a crafted OCI json, or use the `do` subcommand with an EROFS image.

Trying to selectively restrict networking is not something I usually bother with, unless you make it iron-clad it would likely give you a false sense of security. For example Nemoclaw does this by default: <https://docs.nvidia.com/nemoclaw/latest/reference/network-po...>

github.com and api.telegram.org will trivially facilitate exfiltration of data. Some others will also allow that by changing an API key I imagine.