Podman Sandboxes

[boan-jfm]

In the era of AI Agents, will there be an equivalent to Docker Sandboxes?

https://docs.docker.com/ai/sandboxes/

[manimovassagh]

Podman already has the building blocks to do what Docker Sandboxes does, even if there is no single branded "Podman Sandboxes" feature yet.

Docker Sandboxes essentially gives you an isolated container environment with a mounted workspace, network access, and the ability to execute commands -- all behind a simplified API that AI agents can call. You can achieve the same thing with Podman today:

Basic sandbox pattern

# Create a sandbox container with a workspace mount
podman run -d --name agent-sandbox \
  --network=slirp4netns \
  -v /path/to/workspace:/workspace:Z \
  --memory=2g --cpus=2 \
  ubuntu:24.04 sleep infinity

# Execute commands in the sandbox
podman exec agent-sandbox bash -c "cd /workspace && python3 script.py"

# Copy files in/out
podman cp local-file.txt agent-sandbox:/workspace/
podman cp agent-sandbox:/workspace/output.txt ./

# Tear down when done
podman rm -f agent-sandbox

With Podman's REST API

AI agents typically need a programmatic interface. Podman's Docker-compatible API works out of the box:

# Start the API listener
podman system service --time=0 unix:///tmp/podman.sock &

# Now any Docker SDK client can connect
curl --unix-socket /tmp/podman.sock http://localhost/v4.0.0/containers/json

Any AI agent framework that supports Docker (OpenAI's Codex, LangChain tools, etc.) can point at this socket and it just works.

Security advantage over Docker

Podman's rootless mode is arguably better suited for AI sandboxes than Docker:

• No daemon running as root
• Each sandbox runs in a user namespace with no host privileges
• A container escape lands you in an unprivileged user account
• You can run multiple isolated sandboxes under different system users for multi-tenant scenarios

What would a dedicated feature look like?

If Podman were to add a first-class sandbox concept, it would probably be a thin wrapper around:

• podman run with sane defaults (tmpfs workspace, resource limits, no host network)
• A simplified exec API
• Automatic cleanup on timeout

The Quadlet/systemd integration already covers most of this for long-running sandboxes. For the AI agent use case specifically, the main missing piece is a higher-level CLI command like podman sandbox create that bundles these defaults -- but functionally, everything is there.

[quazgar]

If I understand Docker sandboxes correctly, each container has its own VM, so no shared kernel. This is rather an extra security layer, onto which the image/container conveniences then are applied. I think this goes more into the direction of Kata containers (if I understand that concept correctly.)

[giuseppe]

you can use krun as the OCI container and get a VM for your container

[quazgar]

Oh, I had not discovered that yet. Thanks! 😃

[sify21]

Nice! The create command can also include a "--init" option so the container can handle SIGTERM and be stopped quickly

[ygalblum]

I didn't look into docker sandbox, but AFAIK sandboxing is what podmansh is meant for: https://docs.podman.io/en/latest/markdown/podmansh.1.html

[zyongqing]

It features a host network filter to prevent secrets (api key) from being leaked.
https://docs.docker.com/ai/sandboxes/architecture/#credential-injection

[manderson23]

Similarly I assume one of the advantages microsandbox provides over podman is secret protection https://docs.microsandbox.dev/getting-started/introduction#secrets-that-can%E2%80%99t-leak

[manderson23]

How does using podman as outlined above (including the use of krun) compare with https://github.com/superradcompany/microsandbox ?

[musaabhasan]

Podman already has many of the primitives needed here, but the missing piece is an opinionated agent-sandbox profile that combines them into one understandable workflow.

For AI agent use cases, the profile should probably cover:

• workspace mount with explicit read/write scope
• no home-directory or credential-store access by default
• optional network profiles: none, loopback, allowlist, or proxy-mediated
• secret injection by reference rather than environment values visible to the agent
• resource limits for CPU, memory, disk, and process count
• run metadata showing effective mounts, network policy, image, and command

The value of a branded "sandbox" mode is not that containers are new; it is that the safe defaults are assembled for users who are not container/security experts. That is especially relevant for agents because the code being executed may be generated dynamically rather than reviewed ahead of time.