Why I don’t want AI agents executing code in someone else’s cloud

A developer has built VaultRun, a self-hosted runtime for AI agents that executes code in Docker containers on the user's own infrastructure, with network access disabled by default and a signed audit trail. The project aims to give developers control and inspectability over agent execution, addressing concerns about isolation, network access, and auditability when agents interact with production systems.

AI agents are getting access to increasingly powerful tools. They can execute code, query databases, call APIs, work with files, and potentially interact with production infrastructure. That’s useful, but it also creates a question I kept coming back to: Where should that execution actually happen? A common answer is a hosted sandbox. Send the task somewhere, let the agent execute it in an isolated environment, and get the result back. That’s convenient. But once an agent starts working with credentials, customer data, internal APIs, or production systems, I’m less comfortable with that being the default. I wanted the execution environment to live on infrastructure I control. My first thought was mostly about isolation. If an agent executes arbitrary code, that code shouldn’t just run directly on the host. Giving each session its own container is a fairly obvious starting point. But while working on this, I realized isolation isn’t the only boundary that matters. Network access matters just as much. An isolated container that can freely reach the internet — or internal services — can still do quite a lot. So I started thinking about the safer default as: no network access unless it is explicitly allowed. That changes the model from “let the agent do things and try to restrict the dangerous parts” to “start with almost nothing and explicitly grant what it needs.” The other problem is auditability. Knowing that an agent “used a tool” isn’t always enough. If something goes wrong, I want to be able to answer questions like: That becomes especially important when agents are allowed anywhere near real infrastructure. These questions are what led me to start building VaultRun , a self-hosted runtime for AI agents. The basic idea is that agent workloads run on your own infrastructure, with each session isolated in a Docker container. Network access is disabled by default, actions can be recorded in a signed audit trail, and the runtime can be used through APIs and MCP. I’m also keeping the core open source under Apache 2.0. I don’t think self-hosting automatically makes agent execution “secure.” There are still plenty of difficult questions around credentials, permissions, container escapes, policy, replay, secrets, and what an agent should be allowed to access in the first place. But I like having the security boundary somewhere I can actually control and inspect. VaultRun is early, and one reason I’m building it publicly is that I don’t think the right boundaries for AI agents are completely settled yet. Different workloads probably need very different levels of isolation. An agent generating throwaway code is very different from one that can query a production database or deploy infrastructure. I’d be interested to hear how other developers are approaching this. If you let an AI agent execute code or interact with internal systems, what would you need before you trusted that setup near production? Disclosure: I used AI assistance to help structure and edit this article. The technical ideas, project, and opinions are my own. VaultRun: https://vaultrun.dev https://vaultrun.dev GitHub: https://github.com/nickvd7/vaultrun https://github.com/nickvd7/vaultrun