The real threat is the agents access to your accounts and services.
Why always the fixation on the hardware?
Agent Safehouse – macOS-native sandboxing for local agents
181–190 of 207 posts
Re: Agent Safehouse – macOS-native sandboxing for local agents
#182Earlier quoted context omitted.
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 g…
You could apply this same reasoning to any feature or technology. Yes there could be a zero day nobody knows about. We could say that about ssh or WebKit or Chrome too.
I hear what you're saying about the deprecation status, but as I and others mentioned, the fact that the underlying functionality is heavily used throughout the OS by non deprecated features puts it on more solid footing than a technology that's an island unto itself.
Re: Agent Safehouse – macOS-native sandboxing for local agents
#183[flagged]
Matchlock[0] is probably the best solution I've come across so far WRT problem 1 and 2:
> Matchlock is a CLI tool for running AI agents in ephemeral microVMs - with network allowlisting, secret injection via MITM proxy, and VM-level isolation. Your secrets never enter the VM.
In a nutshell, it solves problem #2 through a combination of a network allowlist and secret masking/injection on a per-host basis. Secrets are never actually exposed inside the sandbox. A placeholder string is used inside the sandbox, and the mitm proxy layer replaces the placeholder string with the actual secret key outside of the sandbox before sending the request along to its original destination.
Furthermore, because secrets are available to the sandbox only on a per-host basis, you can specify that you want to share OPENAI_API_KEY only with api.openai.com, and that is the only host for which the placeholder string will be replaced with the actual secret value.
edit to actually add the link
Re: Agent Safehouse – macOS-native sandboxing for local agents
#184Creator here - didn't expect this to go public so soon. A few notes: 1. I built this because I like my agents to be local. Not in a container, not in a remote server, but running on my finely-tuned machine. This helps me run all agents on full-auto, in peace. 2. Yes, it's just a policy-generator for sandbox-exec. IMO, that's the best part about the project - no dependencies, no fancy tech, no virtualization. But I di…
Just wanted to say, this is very cool even (and especially) if it's so simple.
Thanks for making it!
Re: Agent Safehouse – macOS-native sandboxing for local agents
#185Not sure I understand this. Agent CLIs already use sandbox-exec, and you can configure granular permissions. You are basically saying - give the agents access to everything, and configure permissions in this second sandbox-exec wrapper on top. But why use this over editing the CLI's settings file directly (e.g. https://code.claude.com/docs/en/sandboxing#configure-sandbox... )?
I've had trouble with the sandbox functionality baked into agents being able to do what I want, particularly Gemini CLI. Being able to write your own .sb file is more powerful and portable.
Claude Code seemed to be able to reach outside its own sandbox sometimes, so I lost trust in it. Manually wrapping it in sandbox-exec solved the issue.
Re: Agent Safehouse – macOS-native sandboxing for local agents
#186[dead]
Re: Agent Safehouse – macOS-native sandboxing for local agents
#187Earlier quoted context omitted.
I love this implementation. Do you find the SBPL deficient in any ways? Would xcodebuild work in this context? Presumably I'd watch a log (or have an agent) and add permissions until it works?
SBPL is great for filesystem controls and I haven’t hit roadblocks yet. I wish it offered more controls of outbound network requests (ie filtering by domain), but I understand why not. Yes, Safehouse should work for xcodebuild workloads in the way you described - try to run it, watch for failures, extend the profile, try again. Your agent can do this in a loop by itself - just feed it the repo as there are many integ…
For anyone reading this later.
I read a little from sandvault and they suggest sandbox-exec doesn't allow recursive sandboxing, so you need to set flags on xcodebuild and swift to not sandbox in addition to the correct SBPL policy.
(I don't think sandvault has a swift/xcode specific policy because they're dumping everything into a sandvault userspace. And it doesn't really concern itself with networking afaict either.)
Re: Agent Safehouse – macOS-native sandboxing for local agents
#188This is a very nice and clean implementation. Related to this - I've been exploring injecting landlock and seccomp profiles directly into the elf binary, so that applications that are backed by some LLM, but want to 'do the right thing' can lock themselves out. This ships a custom process loader (that reads the .sandbox section) and applies the policies, not unlike bubblewrap which uses namespaces). The loading can b…
[dead]
Re: Agent Safehouse – macOS-native sandboxing for local agents
#189How’s this different from macOS seatbelt
Re: Agent Safehouse – macOS-native sandboxing for local agents
#190This is awesome! I think this is one of the most important technical hurdles in deploying agent applications right now.
I'm involved with a project building something very similar, which we literally open sourced an alpha version of last week:
https://github.com/GreyhavenHQ/greywall
It's a bit different in that:
- We started with Linux
- It is a binary that wraps the agent runtime
- It runs alongside a proxy which captures all traffic to provide a visibility layer
- Rules can be changed dynamically at runtime
I am so happy this problem is getting the attention it deserves!