Agreed. Network control and secret injection together with a microVM setup is as good as it gets right now, although I believe that we need more fine-grained tools down the road. It sounds like Microsandbox would be the perfect fit for what you are describing. I also built my own coding agent workbench on top of it (https://github.com/isolade/isolade). Microsandbox is quite cool, check it out: https://github.com/superradcompany/microsandbox
But in both cases, I want the secrets to be undiscoverable by the AI.
Agreed! But if you use domain-scoped header-only substitution within Isolade, then the AI really has no way to get the actual value (unless the service behind that domain echoes it back to you – but no sane API would do that). It only sees a unique placeholder.
How could an API use that without seeing the content of the token? I thought of building a universal token-injector API proxy, but that is very limited; REST might work, WebSocket connections won't work with this, and most API implementations do not allow setting alternative endpoints.
You don't need alternative endpoints. The microVM starts with a preloaded CA certificate and network proxy that allows intercepting all HTTPS traffic. Websocket works if the authentication happens as part of the header exchange. Custom protocols would indeed be unsupported, as well as pinned certificates. But so far, I have not come across the need for this.
I have also added support for git commit signing via SSH. The host sets up a tunnel and receives the commit information, signs it, and passes it back to the VM. This also guarantees that the VM has no access to the underlying private keys.
That being said, manual approval could still be useful for certain privileged operations. For example, letting the agent access information of a production system. I agree that some approval mechanism would be useful for that. I think microVMs make for a perfect separation here, such that host can decide on a case-by-case whether to allow a given operation.
Most people run their coding agents directly on the host system. In my opinion, this is not a good long-term solution. Regular usage requires some kind of isolation, unless you like living on the edge. Codex ships with a lightweight sandbox, which most of the time just gets in the way by requesting manual approval. Claude has Auto mode, which tends to work a bit better in my experience, but doesn't really protect your host in the same way a sandbox does. So, you either need a full container for your whole setup, or a microVM. The latter provides stronger protection guarantees, but is a bit more heavyweight than a container. Microsandbox microVMs start super fast though, and so far I have not had an issue with resource consumption. It also has the advantage that agents can use Docker without the usual Docker-in-Docker problems. All in all, I think microVMs are the best approach here, potentially with containers nested inside them if resource usage becomes a problem.
I would totally prefer to buy something without spyware. But so far I have not found a good alternative to my 42" C-series OLED. You do have to carefully configure it to not phone home, but besides that (and some minor problems with peak brightness), it's great. If there was a non-spyware replacement, I'd buy it.
Yes, the original motivation for me was because I did not want to mess with Make or similar build systems every time I create a new project or make a big change. It is more similar to systems like Bazel or CMake, where you define tasks in a high-level way.
I internally already have rules for Android APKs (including NDK), embedding other build systems (CMake, etc), Git and JavaScript. Once they are ready, I would like to make them builtin as well. I'm also open to contributions. (:
