hardsnow

GitHub doesn’t exactly make it easy to configure agent access securely. In fact, their regular access tokens and app credentials don’t provide granular enough controls to give direct access to private repos securely. Even if tokens are tightly scoped, access to public repos is always allowed and exfiltration via public repo issues for example remains a vector. Securing this requires patching via MITM proxy that implements stricter controls than GitHub provides.

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...

I’ve been using email as an async channel with agents. Email does proper long-form async and native threaded communication extremely well and IMO is the best match UX-wise.

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

I seriously think this great! I’ve been saying that email is the right interface for agents for a while now. It is available anywhere, natively threaded, and works for asynchronous long-form communication. Comes with great clients as well.

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.

This is a sandbox escape pentest so the only tooling needed is Claude Code and a simple prompt that asks it to follow a workflow: https://github.com/airutorg/airut/blob/main/workflows/sandbo...

I’ve recently set up nightly automated pentest for my open-source project. I’m considering starting to publish these reports as proof of security posture.

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.

I’ve been developing an open-source version of something similar[1] and used it quite extensively (well over 1k PRs)[2]. I’m definitely believer of the “prompt to PR model”. Very liberating to not have to think about managing the agent sessions. Seems that you have built a lot of useful tooling (e.g., session videos) around this core idea.

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/

I would agree with this. I recently tried to figure out how to properly secure agent-authored code in GitHub Actions. I believe I succeeded in doing this[1] but the secure configuration ended up being so delicate that I don’t have high hopes of this being a scalable path.

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

OpenShell is the gem here indeed. A lot of good ideas like network sandbox that does TLS decryption and use of policy engine to set the rules. However:

> 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...

I’ve been running this with workloads accessing Anthropic, GitHub, Gemini, and AWS & CF R2 APIs for a while now, and have not ran into issues. I’m sure there’s an API out there that won’t work out of the box but I’m positive that support could be added.

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.

This is the right approach. I built a similar system to https://github.com/airutorg/airut - couple of learnings to share:

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.

Yep - requires the client to trust the SSL cert of the proxy. Cooperative clients that support eg HTTP_PROXY may be easier to support, but for Airut I went for full transparent mitmproxy. All DNS A requests resolve to the proxy IP and proxy cert is injected to the container where Claude Code runs as trusted CA. As a bonus this closes DNS as potential exfiltration channel.

Alternative, and more robust approach is to give the agent surrogate credentials and replace them on the way out in a proxy. If proxy runs in an environment to which agent has no access to, the real secrets are not available to it directly; it can only make requests to scoped hosts with those.

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...

Container isolation is a good foundation, but one layer worth adding is network sandboxing. A filesystem-sandboxed agent can still exfiltrate data over the network if it gets prompt-injected — domain allowlists and egress filtering can reduce the risk significantly.

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

As someone with first-hand experience in implementing pass-through AR, I found the review well-made (e.g., they measured photon-to-photon latency) and extremely interesting. Here's a few observations I made:

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.