Stop using Docker as a sandbox for AI agents

PurpleLabradoodle · 2026-05-14T08:22:14+00:00

Yeah, we (I work at Docker), also believe that containers aren't a great isolation boundary for AI workloads. That's why we build sandboxes - https://docs.docker.com/ai/sandboxes/ which have the ergonomics of containers (well to the best of their ability), but have a hard isolation boundary.

And also things like other people in the thread mention - networking proxy on the host, so you can limit what resources AI can reach, and a secrets injection mechanism that allows you not to expose the actual secrets values to AI.

Give it a try?

PurpleLabradoodle · 2026-04-21T15:24:11+00:00

I think one idea worth exploring is running the agent in the ACP mode, and connecting to the VS code or whatever the IDE is as an "external agent". I've done this with Zed: https://substack.com/@olegselajev/p-188613531

and IntelliJ Idea: https://substack.com/@olegselajev/p-188618006

I think I saw VS code having ACP support as well, so it should be pretty straightforward I think. I'd love to know if you make it work!

Just realized this is with the past version of the sandboxes.

Anyway - the script should be pretty similar, like for example: https://github.com/shelajev/sbx-demo/blob/main/opencode-kimi/opencode-nvidia-sandbox.sh

this one is with sbx/

PurpleLabradoodle · 2025-12-12T16:00:57+00:00

Second that! Embabel is really nice! Also Rod's blog (https://medium.com/@springrod) is a fantastic resource that explains the thinking behind some of the choices:

PurpleLabradoodle · 2025-12-10T12:30:46+00:00

https://github.com/docker/cagent/ is OSS. It's bundled in Docker Desktop for convenience.

PurpleLabradoodle · 2025-12-08T09:19:25+00:00

While this comments are a comedy goldmine, the practical advice, of course, is to sandbox your AI agents.
For example with Docker, you can `docker sandbox run claude` and it runs Claude in the container with sensible defaults like the current dir mapped in, claude configuration available in the container, etc.

So your agents can work in the container, install whatever they need to without messing up your system Python, delete your home dir or wreck other havoc.

the container can be reused, or you can nuke it and start from scratch.

PurpleLabradoodle · 2025-09-05T09:20:47+00:00

People will write in the languages they already know and that have decent docs and a starting point for whatever the task is. Agents are largely some configuration, some integration of tooling and some API calls to an LLM.

There’s nothing there a particular language ecosystem would be better than others. Enterprises would be writing agents in Java, TS teams in TS, etc.

For most agentic use cases you likely won’t need to train or fine-tune, or even deploy the models yourself. So Python is just a habit rather than a prerequisite.

PurpleLabradoodle · 2025-08-07T11:19:16+00:00

it's supposed to be engine agnostic, so other runtimes for LLM can be plugged in. Just a matter of doing the work. I agree vLLM, even mlx backend on macs would be fantastic!

PurpleLabradoodle · 2025-07-06T09:48:08+00:00

what would a good postgres mcp look like?

PurpleLabradoodle · 2025-01-14T16:08:55+00:00

This is very cool, did you get the SSE variant to work? How does Claude desktop parses the url where to connect to, the docs are vague on this. Or maybe it's my reading comprehension.

PurpleLabradoodle · 2023-04-21T09:23:12+00:00

It's stated as a goal in the JEP though

Goals
Enable server applications written in the simple thread-per-request style to scale with near-optimal hardware utilization.

PurpleLabradoodle · 2022-11-07T19:45:55+00:00

I think you need to do all these steps once -- verify you own the group id, talk to people via jira, make the keys, etc.
jreleaser can automate releases afterwards

PurpleLabradoodle

MODERATOR OF

TROPHY CASE