I can only say the same: "Most people run their coding agents directly on the host system."
And the problem between the host system and the microVM approach is the same, only that the host system is not isolated. But in both cases, I want the secrets to be undiscoverable by the AI.
I use YubiKeys for SSH auth, so the AI could not use SSH without my consent. But for all other credentials like .files I almost saw the AI figure out how to use them without my consent. So your idea is good, but let's think about a bearer token for an API: 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. And I don't want to think about Mutual TLS.
So I decided to build something that tries to get consent for access to .files or passwords from password stores. There is a very early implementation only for SSH agents in github.com/mabels/project-43.
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 can only say the same: "Most people run their coding agents directly on the host system." And the problem between the host system and the microVM approach is the same, only that the host system is not isolated. But in both cases, I want the secrets to be undiscoverable by the AI. I use YubiKeys for SSH auth, so the AI could not use SSH without my consent. But for all other credentials like .files I almost saw the AI figure out how to use them without my consent. So your idea is good, but let's think about a bearer token for an API: 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. And I don't want to think about Mutual TLS. So I decided to build something that tries to get consent for access to .files or passwords from password stores. There is a very early implementation only for SSH agents in github.com/mabels/project-43.
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.
curious, what is the alternative to running a coding agent in microVM? I'm new to this.
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.