logoalt Hacker News

Agent Safehouse – macOS-native sandboxing for local agents

643 points • by atombender • yesterday at 8:30 PM • 152 comments • view on HN

Comments

yowang • today at 9:14 AM

[dead]

Agent_Builder • today at 5:16 AM

[dead]

openclaw01 • today at 3:06 AM

[dead]

naomi_kynes • yesterday at 9:14 PM

The "full-auto" framing is interesting. What happens when the agent hits something it can't resolve autonomously? Even sandboxed, there's a point where the agent needs to ask a question or get approval.

Most setups handle this awkwardly: fire a webhook, write to a log, hope the human is watching. The sandbox keeps the agent contained, but doesn't give it a clean "pause and ask" primitive. The agent either guesses (risky) or silently fails (frustrating).

Seems like there are two layers: the security boundary (sandbox-exec, containers, etc.) and the communication boundary (how does a contained agent reach the human?). This project nails the first. The second is still awkward for most setups.

➕ show 5 replies
aplomb1026 • yesterday at 11:32 PM

[dead]

moehj • yesterday at 10:08 PM

[dead]

poopiokaka • today at 1:45 AM

[dead]

gnanagurusrgs • yesterday at 11:06 PM

This is the right problem to solve. At Arcade, we see the same gap — agents get shell access, API keys, and network by default. The permissions model is backwards.

sandbox-profiles is a solid primitive for local agents. The missing piece in production is the tool layer — even a sandboxed agent can still make dangerous API calls if the MCP tools it has access to aren't individually authed and scoped.

The real stack is: sandbox the runtime (what Agent Safehouse does) + scope the tools (what we do with JIT OAuth at the MCP layer). Neither alone is enough.

Nice work shipping this.

https://www.arcade.dev/blog/ai-agent-auth-challenges-develop...