This is a fair assessment of what the platform actually offers, including where BitShout is not the answer. Each mechanism below is good at the job it was designed for. The problem is that none of those jobs is "constrain software whose next action is generated at runtime, without the vendor's cooperation".
Apple’s entitlement-based sandbox for App Store and hardened apps.
Good at Genuinely strong, kernel-enforced, and well understood.
Runs out Opt-in by the developer of the app being sandboxed. You cannot impose it on a coding agent you installed, and agents need broad file and execution access to function, so a sandboxed agent would ask for the entitlements that undo the point.
The command-line interface to the same underlying sandbox.
Good at Can be applied to a process you launch, without the vendor’s cooperation.
Runs out Formally deprecated by Apple, the profile language is undocumented and unstable, and profiles are static — there is no path for a human to approve an exception at the moment it is needed. You get a wall, not a door.
The consent prompts for Documents, Desktop, Downloads, Full Disk Access.
Good at Familiar to users and enforced by the OS.
Runs out Scoped to broad, coarse categories, and consent is per-application and effectively permanent. It also does not cover the paths that matter most here: ~/.ssh and ~/.aws are not TCC-protected, because they are just files in your home directory.
Run the agent inside a container image.
Good at Real filesystem and process namespace separation, and familiar to developers.
Runs out On macOS this is already a VM, so you pay the cost anyway. In practice people mount their SSH keys, git config and project directory in — which hands back most of the exposure — and container networking is usually wide open outbound.
Physically or virtually separate the work.
Good at Very effective. Nothing beats a different machine.
Runs out Expensive, slow to set up, and it fragments your workflow. It also answers only "can it touch the host" — inside the VM the agent still has every credential you put there.
Score any option — including BitShout — against these. The list is what the mechanisms above were each missing.
You must be able to apply it to software you did not write, without its cooperation.
A shell, an interpreter and a package manager must all inherit the policy.
Filesystem, network, execution and external tools are different questions.
A human must be able to approve a specific exception, narrowly, at the moment it is needed.
Path and PID are attacker-controllable. Signing identity and audit tokens are not.
When enforcement cannot be proven healthy, authority must narrow rather than persist.
An account of what happened that you did not have to get from the agent.
App Sandbox has a coarse network entitlement. sandbox-exec profiles rarely bother. Containers default to unrestricted outbound. But an agent with your network position can reach your VPN, your internal DNS, your staging database and your LAN.
For unreviewed code or a workload you have specific reason to distrust, a policy boundary is not the tool. Vault Mode is BitShout’s answer for that case — a real virtual machine, with the credential store deliberately left behind on the host.
The honest answer is that macOS does not ship a mechanism designed for this. App Sandbox is opt-in by the app’s developer, sandbox-exec is deprecated and has no approval path, TCC is too coarse and does not cover credential directories, and containers on macOS are virtual machines that people then mount their secrets into. What an agent needs is authority containment — deny-by-default per domain, inherited by descendants, with a human-approved exception path — which is a layer above sandboxing rather than a use of it.
You can, and some people do. Be aware of what you are accepting: Apple deprecated it, the profile language is undocumented and has changed without notice, profiles are static so there is no way to approve an exception mid-task, and it does not give you an audit trail. It is a reasonable stopgap for a fully known workload and a poor foundation for an agent whose next action is generated at runtime.
Only if the agent’s developer adopted it, and mostly they cannot: an agent that needs to read your project, run builds and shell out would have to request entitlements broad enough to defeat the purpose. App Sandbox is designed to constrain what an app you trust can do by accident, not to constrain software whose behaviour is generated at runtime.
It is better than nothing and worse than it looks. On macOS, Docker is already a virtual machine, so you are paying virtualisation cost regardless. The practical failure is what gets mounted in: SSH keys, git credentials, cloud config and the project directory usually all come along, which restores most of the original exposure. Outbound networking from containers is also typically unrestricted by default.
A sandbox restricts one process using platform mechanisms, and is usually adopted by the software being sandboxed. Containment is imposed from outside by the user, covers a process and all its descendants, splits authority into separate domains, and ties every exception to a narrow, expiring, human-approved grant. Sandboxing is a mechanism; containment is an architecture that may use several mechanisms including sandboxing and virtualisation.
When the blast radius matters more than the friction: unreviewed code, an untrusted repository, a workload you have specific reason to distrust. That is what BitShout’s Vault Mode is for — a pinned Linux guest under Apple’s Virtualization.framework with no host sockets and no host process visibility. For everyday work, a policy boundary at native speed is the one you will actually leave switched on, and a security control you turn off protects nothing.