Compatibility: Pactmark 0.1.x. Status: unsafe reference fixture. This page exists to prevent a specific misreading, so it is short and blunt.

​
What the fixture does

The container conformance fixture runs with a deliberately hostile configuration:

Non-root user

No privileged process inside the container.

No network

Egress is unavailable during the probe run.

Read-only root filesystem

With a tmpfs workspace as the only writable surface.

No mounts, no Docker socket

The classic escape paths are simply absent.

Dropped capabilities

Plus no-new-privileges.

Hard resource bounds

Process, memory, CPU, time and output limits.
And it actively probes for escape: traversal, symlinks, secrets, sockets, loopback, cloud metadata, fork bombs, infinite loops and unbounded output.

​
What that proves

That the fixture’s declared controls behave as declared, for those probes, in that environment.

​
What that does not prove

These controls do not prove resistance to kernel exploits, container-runtime or engine vulnerabilities, side-channel attacks, or multi-tenant attacks. The fixture is explicitly not production arbitrary-code isolation.

​
The practical consequences

1

Do not run untrusted code on it

If the code came from a model, a user upload, or an external repository, this fixture is not the thing standing between it and your host.
2

Do not run untrusted stdio MCP servers on it

A local MCP process is arbitrary code execution with your process’s privileges. Without a production SandboxAdapter, stdio MCP remains preview-only.
3

Select and assess a real isolation system

Production arbitrary-code execution requires a separately selected, independently assessed isolation system — microVMs, gVisor-class sandboxes, or an equivalent, with its own threat model.
4

Then wire it in as a SandboxAdapter

Pactmark’s capability metadata will let you declare it, and agents that require it will refuse to run where it is absent.

​
Capability declaration

unsafe_local is a capability label, not a sandbox guarantee — the workspace-agent example says so directly in its README. An agent that declares a required sandbox capability the runtime cannot provide fails with KAF_RUNTIME_CAPABILITY_MISSING before it starts. Workspaces are capabilities with normalized paths, size limits and explicit export boundaries. They prevent an agent from wandering out of an allowed root — covered by property-based canonicalization tests and traversal and symlink probes (threat model row TM-09). That is a correctness control over paths. It is not isolation of the code that walks them.

Workspace agent example

Allowlisted roots, path and symlink denial, command and output limits, cancellation, redaction.

Threat model TM-13

The full row, with its residual-risk statement.