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 A

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.