e1g · HackerTrans

Unfortunately, no, MacOS sandboxing does not allow that type of blocking. Only broad categories like "local" vs "remote", but no selective targeting based on domain names or IPs.

e1g

há 9 diasdiscuss

Safehouse author here - glad you found it helpful. It didn't even occur to me to add --offline mode because my mental model is anchored in agents which often require network access. Until we add this, the easiest option is to create a custom policy and then reference it with Safehouse (I usually setup shell aliases/funciton for this)

  ;; in ~/.config/agent-safehouse/no-network.sb
  (deny network*)

  safehouse --append-profile="$HOME/.config/agent-safehouse/no-network.sb" -- <command>

e1g

há 2 mesesdiscuss

In JS land, this problem (streaming, resuming, recovering, multi-client, etc) has been fully solved by https://durablestreams.com - and it can be self-hosted, or managed via Cloudflare DO.

e1g

há 2 mesesdiscuss

We actually had to revert our rollout of CF Workers because enough of our users were in Spain and couldn’t access endpoints at seemingly arbitrary times (due to the matches)

e1g

há 4 mesesdiscuss

For jailing local agents on a Mac, I made Agent Safehouse - it works for any agent and has many sane default for developers https://agent-safehouse.dev

e1g

há 4 mesesdiscuss

Yes, you're correct about 'no nested sandboxing'.

This also applies to sandboxing an Electron app: Electron has its own built-in sandboxing via sandbox-exec, so if you're wrapping an Electron app in your own sandboxing, you have to disable that inner sandbox (with Electron's --no-sandbox or ELECTRON_DISABLE_SANDBOX=1). In the repo, I have examples for minimal sandbox-exec rules required to run Claude Code[1] and VSCode[2] (so you can do --dangerously-skip-permission in their destop app and VSCode extension)

[1] https://github.com/eugene1g/agent-safehouse/blob/a7377924efa...

[2] https://github.com/eugene1g/agent-safehouse/blob/a7377924efa...

e1g

há 4 mesesdiscuss

Claude Code and Codex quickly figure out they are inside sandbox-exec environment. Maybe because they know it internally. Other agents often realize they are being blocked, and I haven't seen them go haywire yet.

Big love for Pi - it was the first integration I added to Safehouse. I wanted something that offers strong guarantees across all agents (I test and write them nonstop), has no dependencies (e.g., the Node runtime), and is easy to customize, so I didn't use the Anthropic sandbox-runtime.

e1g

há 4 mesesdiscuss

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 integrations that are not enabled by default that will help it.

e1g

há 4 mesesdiscuss

Thanks, Codex helped to put that together in like 20 minutes. Try feeding your agent the idea about an interactive config builder, give it the upstream URL with your condos, and see if it can whip up something for you.

e1g

há 4 mesesdiscuss

That’s a great idea. I think I’ll restructure the entire project to be based around a collection of community managed rules, a UI generator to build a custom text file from those rules, and an LLM skill so people can evolve their policies themselves. The Bash script will remain in the background as one implementation, but shouldn’t be the only way.

e1g

há 4 mesesdiscuss

Let’s make something so popular and useful that they can’t drop it.

e1g

há 4 mesesdiscuss

IYKYK, it’s the new Bootstrap!

The alternative would be “no site”, which is still somehow worse.

e1g

há 4 mesesdiscuss

Yes, for about a decade. But it’s available everywhere, and still works - and protects us - like brand new!

e1g

há 4 mesesdiscuss

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

e1g

há 4 mesesdiscuss

Testing in prod! Thank you, just fixed that typo.

e1g

há 4 mesesdiscuss

playwright-cli works out of the box, and I just merged support for agent-browser. If you end up testing out Safehouse, and have any issues, just create an issue on GitHub, and I'll check it out. Browser usage is definitely among my use cases.

e1g

há 4 mesesdiscuss

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 E2E tests validating sandboxing behavior under real agents

4. You don't even need the Safehouse Bash wrapper, and can use the Policy Builder to generate a static policy file with minimal permissions that you can feed to sandbox-exec directly (https://agent-safehouse.dev/policy-builder). Or feed the repo to your LLMs and have them write your own policy from the many examples.

5. This whole repo should be a StrongDM-style readme to copy&paste to your clanker. I might just do that "refactor", but for now added LLM instructions to create your own sandbox-exec profiles https://agent-safehouse.dev/llm-instructions.txt

e1g

há 4 mesesdiscuss

> An agent inside sandbox-exec still has your AWS keys, GitHub token, whatever's in the environment.

That's not the case with Agent Safehouse - you can give your agent access to select ~/.dotfiles and env, but by default it gets nothing (outside of CWD)

e1g

há 4 mesesdiscuss

Love the feedback -

For handling global rules (like ~/.gitconfig and ~/.gitignore), I keep a local policy file that whitelists my "shared globals" paths, and I tell Safehouse to include that policy by default. I just updated the README with an example that might be useful[1]. I also enabled access to ~/.gitignore by default as it's a common enough default.

For process management, there is a blurry line about how much to allow without undermining the sandboxing concept. I just added new integrations[2] to allow more process control and lldb, but I don't know this area well. You can try cloning the repo, asking your agents to tweak the rules in the repo until your use-case works, and send a PR - I'll merge it!

Alternatively, using the "custom policy" feature above, you can selectively grant broad access to your tools (you can use log monitoring to see rejections, and then add more permisions into the policy file)

[1] https://github.com/eugene1g/agent-safehouse?tab=readme-ov-fi...

[2] https://github.com/eugene1g/agent-safehouse/pull/7

e1g

há 4 mesesdiscuss

Claude: can escape its sandbox (there are GitHub issues about this) and, when sandboxed, still has full read access to everything on your machine (SSH keys, API keys, files, etc.)

Codex: IIRC, only shell commands are sandboxed; the actual agent runtime is not.

comments