Agent Safehouse – macOS-native sandboxing for local agents

Original Article ↗ Hacker News Discussion ↗

Mac users are experimenting with Agent Safehouse, a bash-based wrapper around macOS’s deprecated `sandbox-exec`, to tightly restrict what local AI coding agents can read, write, and execute on their machines. Supporters like that it leverages native OS sandboxing without containers or VMs, but others point out that it only really mitigates accidental filesystem damage and doesn’t address deeper risks like prompt-injected agents abusing credentials or external APIs. The exchange highlights a broader need for standardized, auditable sandboxing and fine-grained, task-scoped permissions for agents across macOS, Linux, and production environments.

macOS sandboxing vs containers / VMs

  • Many want a “Docker for macOS” to run native toolchains (e.g., Xcode) in reproducible, isolated environments.
  • Others argue macOS lacks Linux primitives (namespaces, cgroups), so containers must be VM-based; ephemeral macOS VMs + APFS snapshots are suggested as the realistic path.
  • Some note that VM-based Docker on macOS is actually safer in some ways, but can have FS latency and lacks things like iOS USB passthrough.

What Agent Safehouse does

  • Seen as a thin, transparent wrapper around sandbox-exec with well-curated presets for popular agents and workflows.
  • People appreciate it being pure Bash, dependency-free, and easy to audit; policies are split per integration and can be generated via a web “policy builder.”
  • Users like that it defaults to tight filesystem access (mostly CWD, optional dotfiles) and avoids leaking env vars/credentials by default.

Limitations, risks, and sandbox-exec deprecation

  • sandbox-exec is officially deprecated and has been bypassed in past CVEs; some expect new vulnerabilities and eventual removal.
  • Others counter that the underlying sandbox is heavily used by macOS itself and still effective in practice.
  • Several note macOS lacks overlay/union FS or simple chroot-like jails, so “allow writes but discard later” semantics are hard.

Threat models: filesystem vs credentials / prompt injection

  • Strong agreement that filesystem protection is only “problem 1.”
    • Prevent accidental damage: rm -rf, bad git operations, config corruption.
  • “Problem 2” is agents misusing legitimate credentials after prompt injection or confused behavior. Sandboxing the host doesn’t help if the agent already has powerful API keys.
  • Proposed mitigations:
    • Scoped, short-lived credentials or JWTs per task/tool.
    • Supervisor layers that inspect/approve tool calls.
    • Dynamic reduction of permissions once the agent is “tainted” by untrusted input.

Comparisons and alternatives

  • Many related tools mentioned: other sandbox-exec wrappers, macOS GUIs, Linux sandboxes (bubblewrap, firejail, landlock), VM-based workflows, user-level isolation, snapshot/rollback systems.
  • Some prefer remote sandboxes or cheap VPS/containers instead of touching their main machine; others explicitly want local agents for latency, control, and Apple-specific workflows.

Open concerns

  • How to evaluate sandbox wrappers’ real safety—desire for better tests, docs, and “destroy-my-computer” style harnesses.
  • How agents behave when blocked; some go into frantic workaround loops unless the block is clearly explained.
  • Consensus that sandboxing will be table stakes, but not a complete solution on its own.