Now, presumably GitHub Agentic workflows are the proper 1st party solution for this exact issue, but seems like they still have some work to do, either on the security model, or at least in making it easier to use securely.

More on this here: https://haulos.com/blog/do-not-give-your-agent-github-access...

The system I’ve developed for this is open source and detailed at https://airut.org

I’ve been developing last three months by emailing Claude, with email threads mapping to an isolated workspace and claude -p. Works super well, especially when trying to get some coding done between everything else.

With right CLAUDE.md and a bit of workflow tooling this extends itself to building other kinds of agents as well. For example, I do my bookkeeping by emailing Claude my statements and receipts, which it then imports into a plain-text accounting system. And we’ve proven this in corporate environment as well, creating agent that can troubleshoot more complex issues by correlating diagnostic logs against product source code.

Once the basic “email agent” infrastructure is there, creating new agents becomes super simple.

If the cost of security audit becomes marginal, it would seem reasonable to expect projects to publish results of such audits frequently.

There’s probably a quite hefty backlog of medium- and low-severity issues in existing projects for maintainers to suffer through first though.

Couple of learnings to share that I hope could be of use:

1) Execution sandboxing is just the start. For any enterprise usage you want fairly tight network egress control as well to limit chances of accidental leaks or malicious exfiltration if theres any risk of untrusted material getting into model context. Speaking as a decision maker at a tech company we do actually review stuff like this when evaluating tools.

2) Once you have proper network sandboxing, you could secure credentials much better: give agent only dummy surrogates and swap them to real creds on the way out.

3) Sandboxed agents with automatic provisioning of workspace from git can be used for more than just development tasks. In fact, it might be easier to find initial traction with a more constrained and thus predictable tasks. E.g., “ask my codebase” or “debug CI failures”.

[1] https://airut.org [2] https://haulos.com/blog/building-agents-over-email/

Now, as other commenter pointed out, maybe this is just inherent complexity in this space. But more secure defaults could go a long way making this more secure in practice.

[1] https://github.com/airutorg/sandbox-action

Comments URL: https://news.ycombinator.com/item?id=47547186

Points: 2

# Comments: 0

> Credentials never leak into the sandbox filesystem; they are injected as environment variables at runtime.

If anyone from the team is reading - you should copy surrogate credentials approach from here to secure the credentials further: https://github.com/airutorg/airut/blob/main/doc/network-sand...

Another thing I did was to allow configuring which hosts each credential is scoped to. Replacement /resigning doesn’t happen unless host matches. That way it is not possible to leak keys by making requests to malicious hosts.

1) Not all systems respect HTTP_PROXY. Node in particular is very uncooperative in this regard.

2) AWS access keys can’t be handled by simple credential swap; the requests need to be resigned with the real keys. Replicating the SigV4 and SigV4A exactly was bit of a pain.

3) To be secure, this system needs to run outside of the execution sandbox so that the agent can’t just read the keys from the proxy process.

For Airut I settled on a transparent (mitm)proxy, running in a separate container, and injecting proxy cert to the cert store in the container where the agent runs. This solved 1 and 3.

Comments URL: https://news.ycombinator.com/item?id=47350795

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=47326502

Points: 1

# Comments: 0

I’ve built this in Airut and so far seems to handle all the common cases (GitHub, Anthropic / Google API keys, and even AWS, which requires slightly more work due to the request signing approach). Described in more detail here: https://github.com/airutorg/airut/blob/main/doc/network-sand...

Email is perfect fit for async long-form conversation, naturally threaded, and with excellent UX across platforms. Each email thread becomes a Claude Code session within automatically created sandboxed workspace. Working on multiple things in parallel requires no additional thought - they just exist as independent email threads in your inbox. Friction to start a new task is what I would consider zero - just send an email (without having to worry about a human judging your poor grammar even!)

I recently added slack support as well, inspired by Spotify’s “Honk”. Slack having native threading maps to Airut’s model reasonably well. Although I wish Slack had better UX for switching between threads.

Airut works best when the project is set up for agentic development and the agent has necessary access to push code for review. I’ve tried to make this possible securely; Airut for example has “masked secrets” feature where the container running Claude Code doesn’t hold the real authentication tokens, only look-alike surrogates which are swapped to real ones on the way out by a proxy.

Project is open-source (MIT) and should be straightforward to set up on a Linux machine or VM. I’d love to hear feedback about the conceptual model and the sandboxing implementation.

Comments URL: https://news.ycombinator.com/item?id=47101752

Points: 1

# Comments: 0

Another useful primitive is surrogate credentials: the agent never handles real API keys or tokens. A proxy swaps in real values only for scoped hosts on the way out. This keeps the access the agent has locked inside the container; surrogate credentials are not valid outside.

My Claude Code over email project demonstrates both of these: https://github.com/airutorg/airut

With the latest models and a solid CLAUDE.md, I could reliably go from prompt to PR using Claude Code with --dangerously-skip-permissions. But that left me with two problems:

1. Safety: Running permissive mode on my host machine felt reckless. I needed real sandboxing — not just a container, but network isolation too.

2. Session management: I needed a way to run multiple long-running Claude Code sessions without juggling terminals.

I realized the ideal interaction model matches email: asynchronous, threaded, long-form. So I built a service that runs headless Claude Code inside rootless Podman containers, mapping email threads to agent sessions.

The security model goes beyond container isolation. All network traffic routes through an mitmproxy instance that enforces a per-repo allowlist — the agent can only reach pre-approved hosts. Credentials use a masked secrets system where containers get surrogate tokens; real values are swapped in by the proxy only for scoped hosts. Even if the agent is compromised via prompt injection, exfiltration paths are significantly constrained.

Today I develop two large projects (plus Airut itself) almost exclusively over email. I send a task, the agent works in its sandbox, and I get a PR to review. And I often do this from my phone while on the go.

Compared to OpenClaw, Airut is more opinionated — email-only, Claude-only, git-native — with a deeper sandbox (network allowlist, masked secrets, DNS exfiltration protection). Compared to enterprise agents, there's no issue tracker or web UI to fight with.

It's open source (MIT) and self-hosted. I'd love feedback on the security model and whether this async email workflow resonates.

Comments URL: https://news.ycombinator.com/item?id=46947714

Points: 2

# Comments: 0

1. 30 Hz frame rate and 50ms photon-to-photon latency sound so bad that I'm surprised they launched this at all. I would be very interested in trying this out to see how (un)comfortable the experience is. What I would have expected is pass-through feed rate synchronized to display frame rate (i.e., 90 Hz) and photon-to-photon latency no more than perhaps 2 frames (22ms). At 90 Hz and 11ms you can actually play ping-pong while wearing a pass-through headset.

2. I can relate with the exposure, saturation, and noise issues. The existing well-tuned video ISP pipes aren't suitable for low latency, and building a new one that achieves low latency and gives a good picture in indoor lighting from an essentially smartphone sensor with exposure time < 11ms and doesn't add multi-frame latency is HARD.

3. Above points to one possible explanation for the 30Hz capture; maybe they used a cheap sensor that can't produce usable picture in < 11ms exposure time (in dimly lit indoor environment) and thus had to go with 30Hz capture. Would be interesting to repeat the experiment in well-lit (outdoor) environment to see if the capture pipe kicks into a higher framerate.

4. I wonder if they do any warping to correct for the camera positions and how well that works. For AR-focused headset the ideal pass-through camera positions would approximate eye positions to minimize need for distortion. Even shifting capture positions a few centimeters forward from the eyes (which you'd need to do if you don't replace eyes with cameras or play tricks with optics) creates a subtle but noticeable effect unless corrected.