[dead]
Agent Safehouse – macOS-native sandboxing for local agents
91–100 of 207 posts
Re: Agent Safehouse – macOS-native sandboxing for local agents
#92Creator 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…
i toyed around with policy builder for a few seconds, i was really impressed. great UX
Re: Agent Safehouse – macOS-native sandboxing for local agents
#93The 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…
Thank you for your work - I have sent many of your links to my people. Your point is totally fair for evaluating security tooling. A few notes - 1. I implemented this in Bash to avoid having an opaque binary in the way. 2. All sandbox-exec profiles are split up into individual files by specific agent/integration, and are easily auditable ( https://github.com/eugene1g/agent-safehouse/tree/main/profil... ) 3. There are…
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?
Re: Agent Safehouse – macOS-native sandboxing for local agents
#94As I understand it, the problem nowadays doesn't seem to be so much that the agent is going to rm -rf / my host, it's more like it's going to connect to a production system that I'm authorized to on my machine or a database tool, and then it's going to run a potentially destructive command. There is a ton of value of running agents against production systems to troubleshoot things, but there are not enough guardrails…
As I understand it, the problem is these apps/agents can do all of these and lot more (if not absolutely everything, while I am sure it can go quite close to doing that).
Solution could be two parts:
OS bringing better and easier to use OS limitations (more granular permissions; install time options and defaults which will be visible to user right there and user can reject that with choices like:
- “ask later”
- “no”
- “fuck no”
with eli5 level GUIs (and well documented). Hell, a lot of these are already solved for mobile OS. While not taking away tools away from hands of the user who wants to go inside and open things up (with clear intention and effort; without having to notarise some shit or pay someone).
2. Then apps[1] having to, forced to, adhere to use those or never getting installed.
[1] So no treating of agents as some “other” kinds of apps. Just limit it for every app (unless user explicitly decides to open things up).
It will also be a great time to nuke the despicable mess like Electron Helpers and shit and app devs considering it completely fine to install a trillion other “things” when user installed just one app without explaining it in the beginning (and hence forced to keep their apps’ tentacles simple and limited)
Re: Agent Safehouse – macOS-native sandboxing for local agents
#95Creator 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…
What’s the difference between running natively and in a container, really?
On Linux, not much. On a Mac, quite a bit.
Re: Agent Safehouse – macOS-native sandboxing for local agents
#96Earlier quoted context omitted.
This is what I was going for with Treebeard[0]. It is sandbox-exec, worktrees, and COW/overlay filesystem. The overlay filesystem is nice, in that you have access to git-ignored files in the original directory without having to worry about those files being modified in the original (due to the COW semantics). Though, truthfully, I haven’t found myself using it much since getting it all working. [0] https://github.com…
This approach is too complex for what is provided. You're better off just making a copy of the tree and simply using sandbox-exec. macFUSE is a shitshow. The main issue I want to solve is unexpected writes to arbitrary paths should be allowed but ultimately discarded. macOS simply doesn't offer a way to namespace the filesystem in that way.
Completely agree; my approach was not the most practical. I mostly wanted to know how hard it would be and, as I said, haven’t used it much since. Yes, macFUSE is messy to rely upon.
I feel as though the right abstraction is simply unavailable on macOS. Something akin to chroot jails — I don’t feel like I need a particularly hardened sandbox for agentic coding. I just need something that will prevent the stupid mistakes that are particularly damaging.
Re: Agent Safehouse – macOS-native sandboxing for local agents
#97I think this is the right approach to building sandbox for agents ie. over existing OS native sandbox capabilities so that they are truly enforced.
However the challenge is, sandbox profiles (rules) are always workload specific. How do you define “least privilege” for a workload and then enforce it through the sandbox.
Which is why general sandboxes wont be useful or even feasible. The value is observing and probably auto-generating baseline policy for a given workload.
Wrong or overly relaxed policies would make sandbox ineffective against real threats it is expected to protect against.
Re: Agent Safehouse – macOS-native sandboxing for local agents
#98Earlier quoted context omitted.
isn't sandbox-exec already deprecated?
Yes, for about a decade. But it’s available everywhere, and still works - and protects us - like brand new!
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.
Re: Agent Safehouse – macOS-native sandboxing for local agents
#99I wonder why you believe that running agents locally is the best approach. For most people, having agents operate remotely is more effective because the agent can stay active without your local machine needing to remain powered on and connected to the internet 24/7.
It’s nice having control and ownership of your software. I’m assuming it’s similar to why people run plex, web servers, file sharing, etc Also personally I’d rather not pay monthly fees for stuff if it can be avoided.
These agents are all calling APIs that are well beyond your control. How does it matter whether a thin CLI wrapper is running on your computer or not?
Re: Agent Safehouse – macOS-native sandboxing for local agents
#100Earlier quoted context omitted.
What’s the difference between running natively and in a container, really?
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.