Skip to main content

tai42-sandbox-docker

Docker sandbox provider for the TAI ecosystem — per-session containers on a REMOTE Docker engine over the Docker Engine API.

Each session runs as its own hardened container on a remote engine reached over mTLS. The app container spawns no local process, holds no host Docker socket, and mounts no host path; real work is driven through the engine's exec API against an idle session container.

Enable it

sandbox_module: tai42_sandbox_docker

Configuration

The SANDBOX_DOCKER_ env group. SANDBOX_DOCKER_HOST is required (a unix:///var/run/... socket path or a tcp://host:port); the mTLS client certificates are read from the canonical /certs/client mount, never from the environment. Resource-cap fallbacks (SANDBOX_DOCKER_DEFAULT_CPU / SANDBOX_DOCKER_DEFAULT_MEMORY_MB), the image SANDBOX_DOCKER_PULL_POLICY, the opt-in egress-firewall readiness probe (SANDBOX_DOCKER_READINESS_PROBE_ENABLED / SANDBOX_DOCKER_READINESS_PROBE_IMAGE / SANDBOX_DOCKER_READINESS_PROBE_TIMEOUT_SECONDS), and the shared TTL / reap / exec-timeout knobs round out the group.

Security model

  • Remote engine over mTLS — no host Docker socket, no privilege in the app container.
  • Per-session containers hardened with no-new-privileges, all capabilities dropped, never privileged, and no host bind mount.
  • Single-workspace-mount isolation invariant: a session mounts ONLY its own workspace volume and can never read the engine's mTLS client identity.
  • Network tiers none / internal / egress map onto the engine's network mode; egress default is OPEN, so tool-result data is exfiltratable under open egress (the egress firewall is provisioned by the deployment that runs the engine).
  • Egress-firewall readiness (opt-in): with SANDBOX_DOCKER_READINESS_PROBE_ENABLED, a create first proves the engine's egress firewall is in force — a throwaway, unprivileged probe container on the egress tier must not reach the engine's control address and must reach its own resolver — and refuses the create loudly otherwise. Both probe targets are derived, so there is nothing to mis-set.

Durability model

An ephemeral session's workspace is an anonymous volume reaped with the session; a persistent session binds a durable named tai-sbx-<workspace_key> volume that survives the session and its reap, removed only by an explicit unforced teardown. The durable store is provisioned by the deployment that runs the engine.

See docs/index.mdx and the tai-docs operate page for the full settings table and deployment topology.

Metadata

Release files for tai42-sandbox-docker 2.1.0

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for tai42-sandbox-docker 2.1.0
File Size Uploaded Provenance
tai42_sandbox_docker-2.1.0.tar.gz 46.8 kB Without provenance Details

Built distribution (wheel)

Table of built distributions (wheels) for tai42-sandbox-docker 2.1.0
File Interpreter ABI Platform
tai42_sandbox_docker-2.1.0-py3-none-any.whl Python 3 none any Details

Total release size: 76.6 kB

Release files / tai42_sandbox_docker-2.1.0.tar.gz

Download URL tai42_sandbox_docker-2.1.0.tar.gz
Size 46.8 kB
Tags Source
SHA-256 checksum
How to use checksums
0b67dfe391f9037bf046668a5e26c50b0a7ff692e763528a9e3151957ddbb901
BLAKE2b-256 checksum
How to use checksums
817dd274382fada29e1ff966b373f570c87adf9c107a2d6279e61b3256077ff4
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
No
Uploaded via twine/7.0.0 CPython/3.13.14

Release files / tai42_sandbox_docker-2.1.0-py3-none-any.whl

Download URL tai42_sandbox_docker-2.1.0-py3-none-any.whl
Size 29.9 kB
Tags Python 3
SHA-256 checksum
How to use checksums
6a0dfaa42875da606753e8198b169aa73b484c124bede5036c0d45889f818f2b
BLAKE2b-256 checksum
How to use checksums
1cf2ea218f865e3d8b4013a791b4097ad904a014b5f1ad6154d2a706ae4df5f2
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
No
Uploaded via twine/7.0.0 CPython/3.13.14

Security for tai42-sandbox-docker 2.1.0

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

No provenance found

None of the files in this release were uploaded with provenance metadata.

A note on package security

PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.

Release history Release notifications | RSS feed

This release

2.1.0 This release

2 release files No provenance

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page