I didn’t want AI agents running sensitive workloads in someone else’s cloud, so I built VaultRun
While experimenting with AI agents, I kept running into the same question:
What happens when an agent needs to execute code, access a database, use credentials, or interact with internal systems?
A lot of the tooling I found assumes you’re comfortable sending that execution to someone else’s cloud.
I wasn’t.
So I started building VaultRun, a self-hosted runtime for AI agents.
The idea is fairly simple: run agent workloads on infrastructure you control, isolate every session, restrict network access by default, and keep an audit trail of what the agent actually executed.
Right now VaultRun has:
isolated Docker sessions
network access off by default
53+ MCP tools
HMAC-signed audit trails
Go and Python SDKs
an Apache 2.0 open-source core
One thing I’ve learned while building it is that isolation alone isn’t enough.
If an agent does something unexpected, I want to be able to answer: what exactly did the model execute, with which arguments, and when?
That’s becoming one of the main ideas behind VaultRun.
It’s still early, and I’m deliberately trying to learn from people who are actually experimenting with agents rather than pretending I already know exactly what the product should become.
If you’re running AI agents anywhere near production systems: what would you need to see before you’d trust a self-hosted runtime with them?
The self-hosted part seems like it could mean very different things to different teams. I’m curious whether the teams you’ve spoken to are mainly trying to keep data inside their infrastructure, or if the bigger concern is having control and visibility over what the agent is actually doing.
The shift from isolation to being able to explain exactly what an agent executed is a significant distinction. I’m curious which of those two concerns comes up first in conversations with teams actually running agents.