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.
Isolation is only part of the problem
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.”
I also want to know what actually happened
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:
- What command was executed?
- What arguments were passed?
- When did it happen?
- What was the result?
- Can the execution history be trusted afterwards?
That becomes especially important when agents are allowed anywhere near real infrastructure.
This led me to build VaultRun
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.
Still figuring this out
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
GitHub: https://github.com/nickvd7/vaultrun
Top comments (0)