Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Agent Safehouse – macOS-native sandboxing for local agents

agent-safehouse.dev

Post reply on HN
Print view View original

121–130 of 207 posts

Re: Agent Safehouse – macOS-native sandboxing for local agents

#121

Post by dpe82 »

PlasmaPower wrote: post #15
dpe82 wrote: post #5

Earlier quoted context omitted.

Nitpick, which probably doesn't matter too much in this context but is always good to remember: Docker containers are not security boundaries.

Why not? They're definitely not perfect security boundaries, but neither are VMs. I think containers provide a reasonable security/usability tradeoff for a lot of use cases including agents. The primary concern is kernel vulnerabilities, but if you're keeping your kernel up-to-date it's still imo a good security layer. I definitely wouldn't intentionally run malware in it, but it requires an exploit in software with…

It's certainly better than nothing. Hence "probably doesn't matter too much in this context" - but of course it always matters what your threat model is. Your own agents under your control with aligned models and not interacting with attacker data? Should be fine.

But too many people just automatically equate docker with strong secure isolation and... well, it can be, sometimes, depending a hundred other variables. Thus the reminder; to foster conversations like this.

Re: Agent Safehouse – macOS-native sandboxing for local agents

#122

Post by qalmakka »

PufPufPuf wrote: post #8
garganzol wrote: post #2

While we have `sandbox-exec` in macOS, we still don't have a proper Docker for macOS. Instead, the current Docker runs on macOS as a Linux VM which is useful but only as a Linux machine goes. Having real macOS Docker would solve the problem this project solves, and 1001 other problems.

What would native containers bring over Linux ones? The performance of VZ emulation is good, existing tools have great UX, and using a virtualized kernel is a bit safer anyways. I regularly use a Lima VM as a VSCode remote workspace to run yolo agents in.

> What would native containers bring over Linux ones?

What would a Phillips screwdriver bring over a flathead screwdriver? Sometimes you don't want/need the flathead screwdriver, simple as that. There are macOS-specific jobs you need to run in macOS, such as xcode toolchains etc. You can try cross compiling, but it's a pain and ridiculous given that 100% of every other OS supports containers natively (including windows). It's clear to me that Apple is trying to make the ratio jobs/#MacMinis as small as possible

Re: Agent Safehouse – macOS-native sandboxing for local agents

#123

Post by rvz »

TheTon wrote: post #104
rvz wrote: post #98

Earlier quoted context omitted.

It's quite naive to assume that. There is a reason why it is deprecated by Apple. Apple is likely preparing to remove it for a secure alternative and all it takes is someone to find a single or a bunch of multiple vulnerabilities in sandbox-exec to give a wake up call to everyone why were they using it in the first place. I predict that there is a CVE lurking in sandbox-exec waiting to be discovered.

On the other hand, the underlying functionality for sandboxing is used heavily throughout the OS, both for App Sandboxes and for Apple’s own system processes. My guess is sandbox-exec is deprecated more because it never was adequately documented rather than because it’s flawed in some way.

> the underlying functionality for sandboxing is used heavily throughout the OS, both for App Sandboxes and for Apple’s own system processes.

The security researchers will leverage every part of the OS stack to bypass the sandbox in XNU which they have done multiple times.

Now, there is a good reason for them to break the sandbox thanks to the hype of 'agents'. It could even take a single file to break it. [0]

> My guess is sandbox-exec is deprecated more because it never was adequately documented rather than because it’s flawed in some way.

You do not know that. I am saying that it has been bypassed before and having it being used all over the OS doesn't mean anything. It actually makes it worse.

[0] https://the-sequence.com/crashone-cve-2025-24277-macos-sandb...

Re: Agent Safehouse – macOS-native sandboxing for local agents

#124

Post by rvz »

JimDabell wrote: post #107
rvz wrote: post #98

Earlier quoted context omitted.

It's quite naive to assume that. There is a reason why it is deprecated by Apple. Apple is likely preparing to remove it for a secure alternative and all it takes is someone to find a single or a bunch of multiple vulnerabilities in sandbox-exec to give a wake up call to everyone why were they using it in the first place. I predict that there is a CVE lurking in sandbox-exec waiting to be discovered.

As I understand it, Chrome, Claude Code, and OpenAI Codex all use sandbox-exec. I’m not sure Apple could remove it even if they were sufficiently motivated to.

> As I understand it, Chrome, Claude Code, and OpenAI Codex all use sandbox-exec.

Apple can still decide to change it for any reason, regardless of who uses it, since it is undocumented for their use anyway.

> I’m not sure Apple could remove it even if they were sufficiently motivated to.

It can take multiple security issues for them to remove it.

Re: Agent Safehouse – macOS-native sandboxing for local agents

#125

Post by camkego »

e1g wrote: post #78
siwatanejo wrote: post #73

Earlier quoted context omitted.

It's kinda funny that I, being skeptical about coding agents and their potential dangers, was interested to give your project a go because I don't trust AI. Yet the first thing I find in your README is that to install your tool I need to trust some random server serve me an .sh file that I will execute in my computer (not sure if with sudo... but still). Come on man, give me a tarball :) EDIT: PS: before someone give…

Fair! You don’t actually need to install anything and can just generate a text file with the security profile for sandbox-exec. You can do that online at https://agent-safehouse.dev/policy-builder.html Alternatively, you can feed these instructions to your LLM and have it generate you a minimal policy file and a shell wrapper https://agent-safehouse.dev/llm-instructions.txt

I think if the online builder could have been the whole project, that would be neat! Truly "zero-trust", what I think many HN readers want.

Anyway, thanks for building Agent Safehouse.

Re: Agent Safehouse – macOS-native sandboxing for local agents

#126

Post by vasco »

simonw wrote: post #61

The challenge I'm finding with sandboxes like this is evaluating them in comparison to each other. This looks like a competent wrapper around sandbox-exec. I've seen a whole lot of similar wrappers emerging over the past few months. What I really need is help figuring out which ones are trustworthy. I think this needs to take the form of documentation combined with clearly explained and readable automated tests. Most…

So create a 'destroy my computer' test harness and run it whenever you test another wrapper. If it works you'll be fine. If it doesn't you buy a new computer.

Re: Agent Safehouse – macOS-native sandboxing for local agents

#128

Post by scosman »

quietsegfault wrote: post #100
cortesoft wrote: post #95

Earlier quoted context omitted.

On Linux, not much. On a Mac, quite a bit.

Like mostly apple services such as iMessage? I’m asking honestly, not snarky! I don’t think performance is a big factor for agentic hyjinx.

Apple APIs yes. But there’s also an overhead when running containers like docker on Mac (and windows). Only Linux has near-zero overhead.

Re: Agent Safehouse – macOS-native sandboxing for local agents

#130

Post by niyikiza »

naomi_kynes wrote: post #13

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 (ri…

The two-layer framing is right. Sandbox-exec contains local blast radius, and that's important. But if the agent already has a credential in memory, sandboxing the filesystem doesn't help. I've been working on a primitive for scoped authorization at the tool call level: what was this agent allowed to do, for which task, signed by whom. The core is open-sourced: https://github.com/tenuo-ai/tenuo
Post reply on HN