Comment by simonw
I've tried a whole bunch of things. I'm currently using Docker for Desktop and running containers in that, which is OK but feels like a LOT of overhead to address a problem that the core OS has features for solving already.
I want a solution I can distribute to other people where the first step isn't "install Docker".
Ah, you mean for sandboxing an agent that isn't meant to be used by developers? Apple is adding containers support to the core OS now. So for developers, it seems like it won't be difficult for them soon and agent software can manage the dev container instances. For a native Mac app you can embed one inside another and the latter can have a more restrictive set of App Sandbox entitlements.
The main reasons to prefer a Linux container are:
• The agent can install new software packages if it needs them. If you use a native Mac sandbox then it'd need to ask permission to use homebrew. Maybe you can find a way to run homebrew inside a Mac sandbox but it won't be straightforward.
• Simpler boundary. The bug I reported (in an AI agent sandbox using Seatbelt) was that it failed to properly block off access to the user's home directory dotfiles and ~/Library. This sort of mistake is easy to make with Seatbelt but harder to make with containers. There are many other sandbox escapes in the policy I saw. Note that using Apple's standard sandbox APIs would avoid this type of error.
• You can edit the SSL root store for just the agent, meaning you can MITM traffic from the agent to the internet. Doing that with native Mac apps isn't possible unless the user actually modifies the root store, which they may not want to do.