How does this compare to using something like exe.dev where you get remote isolated sandboxes over SSH, and assume you add in an http credential injection reverse proxy (bring your own)?
I'm building something that will give me peace of mind that my agents will (whether maliciously or stupidly) not negatively read/write the personal data on my machine. To me, exe.dev (with possibly a reverse proxy to preclude the agent from ever having access to my API tokens) is sufficient.
It sounds like your setup works for your case of running your agents in a sandbox. plimsoll is more for running code for agents or MCP servers. It's not for running agents.
A few interesting things:
I did read that exe.dev handles model keys properly (keeps them off the VM) if you use their built in LLM feature.
Hmm, but their Home Assistant integration at first look has no way to set path limits (but I could be wrong), so an agent that is supposed to only read the thermostat can unlock the door.
And ah! Their FAQ mentions using agent forwarding (aka "ssh -A" ). I would avoid that because anything in the VM can use your laptop's SSH keys while you are connected.
Do your agents run or write their own code? Are the agents your own programs or something like Claude Code? If you like, reply with more info on the kind of agent you have and I can look more closely at exe.dev too.
I wrote plimsoll for my own projects. Several have an agent writing and running code, and they all needed the same things: a way for that code to call my APIs without holding a credential, a record of exactly what ran with checksums I can verify, and a way to tie each run to my own logs. I also wanted one place to use several sandboxes, local or cloud, so I can test on my machine and flip a switch for production.
Plimsoll is a Go daemon you run yourself, and the switch is its configuration: WebAssembly or plain docker on a laptop; docker under gVisor, or E2B and Docker Cloud microVMs, in production. The client code doesn't change. Every result states its isolation tier (process, container, kernel or vm), and a request can set a minimum, so code that needs a VM can't quietly run on my test setup: below the floor, nothing runs. E2B and Docker Cloud bill by the second and agents never get bored, so each caller can get a daily allowance of microVM seconds. An agent that wants to loop forever loops until the allowance runs out; the next run is refused before it starts.
Sessions keep one sandbox across calls, with Python or JavaScript cells that keep their state like a notebook (on docker, E2B and NVIDIA's OpenShell). Every response carries a run record, SHA-256 hashes of the request and result that the clients recompute; in a session the records chain, and a separate tool, plimsoll-attest, signs them and refuses a chain with a call missing. Pass your own trace ID and it lands on the daemon's audit line.
The code gets no network by default. To call one of my APIs it goes through a broker outside the sandbox: the run's grant lists the exact routes allowed, and the broker adds a token minted for that run, which never enters the sandbox, and enforces call and size budgets. It traces each call by the route pattern it matched (/items/*, not /items/42), status, size and timing, never the body or token; the audit line gets the totals, and an optional advisor flags waste, like an agent fetching 200 items one at a time, which is the most agent thing an agent can do.
To try it you only need Go (process tier, so not for hostile code):
git clone https://github.com/plimsollmark/plimsoll && cd plimsoll
go run ./examples/minimal
On Linux with docker, the same example at the kernel tier:
sudo ./docker/install-gvisor.sh && make docker-images
SANDBOX_PROVIDER=docker SANDBOX_DOCKER_RUNTIME=runsc go run ./examples/minimal
Clients: Go, Python (tools for Agno, CrewAI and Google ADK) and TypeScript (Vercel AI SDK, Trigger.dev, Mastra).
What it isn't yet: pre-1.0, no other users, no outside security audit, and it's just me: the bus factor is one, and I'm careful around buses. gVisor is Linux only, so a Mac gets the container tier. The tier is configuration plus startup smoke tests, not attestation.
If you run agent-written code today, what do you run it in? Would a tier label change what you trust?
How does this compare to using something like exe.dev where you get remote isolated sandboxes over SSH, and assume you add in an http credential injection reverse proxy (bring your own)?
I'm building something that will give me peace of mind that my agents will (whether maliciously or stupidly) not negatively read/write the personal data on my machine. To me, exe.dev (with possibly a reverse proxy to preclude the agent from ever having access to my API tokens) is sufficient.
It sounds like your setup works for your case of running your agents in a sandbox. plimsoll is more for running code for agents or MCP servers. It's not for running agents.
A few interesting things:
I did read that exe.dev handles model keys properly (keeps them off the VM) if you use their built in LLM feature.
Hmm, but their Home Assistant integration at first look has no way to set path limits (but I could be wrong), so an agent that is supposed to only read the thermostat can unlock the door.
And ah! Their FAQ mentions using agent forwarding (aka "ssh -A" ). I would avoid that because anything in the VM can use your laptop's SSH keys while you are connected.
Do your agents run or write their own code? Are the agents your own programs or something like Claude Code? If you like, reply with more info on the kind of agent you have and I can look more closely at exe.dev too.
[flagged]
[flagged]
I wrote plimsoll for my own projects. Several have an agent writing and running code, and they all needed the same things: a way for that code to call my APIs without holding a credential, a record of exactly what ran with checksums I can verify, and a way to tie each run to my own logs. I also wanted one place to use several sandboxes, local or cloud, so I can test on my machine and flip a switch for production.
Plimsoll is a Go daemon you run yourself, and the switch is its configuration: WebAssembly or plain docker on a laptop; docker under gVisor, or E2B and Docker Cloud microVMs, in production. The client code doesn't change. Every result states its isolation tier (process, container, kernel or vm), and a request can set a minimum, so code that needs a VM can't quietly run on my test setup: below the floor, nothing runs. E2B and Docker Cloud bill by the second and agents never get bored, so each caller can get a daily allowance of microVM seconds. An agent that wants to loop forever loops until the allowance runs out; the next run is refused before it starts.
Sessions keep one sandbox across calls, with Python or JavaScript cells that keep their state like a notebook (on docker, E2B and NVIDIA's OpenShell). Every response carries a run record, SHA-256 hashes of the request and result that the clients recompute; in a session the records chain, and a separate tool, plimsoll-attest, signs them and refuses a chain with a call missing. Pass your own trace ID and it lands on the daemon's audit line.
The code gets no network by default. To call one of my APIs it goes through a broker outside the sandbox: the run's grant lists the exact routes allowed, and the broker adds a token minted for that run, which never enters the sandbox, and enforces call and size budgets. It traces each call by the route pattern it matched (/items/*, not /items/42), status, size and timing, never the body or token; the audit line gets the totals, and an optional advisor flags waste, like an agent fetching 200 items one at a time, which is the most agent thing an agent can do.
To try it you only need Go (process tier, so not for hostile code):
On Linux with docker, the same example at the kernel tier: Clients: Go, Python (tools for Agno, CrewAI and Google ADK) and TypeScript (Vercel AI SDK, Trigger.dev, Mastra).What it isn't yet: pre-1.0, no other users, no outside security audit, and it's just me: the bus factor is one, and I'm careful around buses. gVisor is Linux only, so a Mac gets the container tier. The tier is configuration plus startup smoke tests, not attestation.
If you run agent-written code today, what do you run it in? Would a tier label change what you trust?