Agent isolation threat and platform evidence

Separates shared-kernel, credential, subprocess, and egress threats and evaluates macOS ARM isolation primitives.

Summary

Kernel escape, credential exposure, unconstrained subprocesses, and open egress are independent risk classes that require separate controls.

Question and scope

Which threats survive the Docker baseline, and which macOS ARM platform primitives can close the shared-kernel gap?

Method

Evidence combines vulnerability reports, upstream issue trackers, platform architecture, and the related jackin❯ research linked beside each finding at the 2026-07-01 cutoff.

Findings

Docker baseline

The Docker baseline provides these controls:

explicit workspace bind mounts (only operator-approved paths)
host Docker socket excluded from agent containers
per-agent Docker network
TLS-authenticated DinD sidecar for Docker workflows inside the agent

This baseline avoids direct host-Docker access but retains shared-kernel, credential, subprocess, and egress risks.

OrbStack boundary

OrbStack isolated machines remove the default full-Mac-filesystem passthrough, but their boundary remains namespace-based.

Finding: OrbStack isolated machines share OrbStack's Linux kernel. They provide namespace isolation within the existing OrbStack VM — cgroups and namespaces, not a hypervisor boundary per workload. For the current audience (100% macOS ARM operators who already use OrbStack as their Docker engine), the role container already lives inside OrbStack's Linux VM. An isolated machine would add a namespace layer on the same kernel.

Implication: OrbStack isolated machines reduce accidental host-file exposure but do not address the kernel-escape class that motivates per-workload VM separation.

Shared-kernel threat

Shared-kernel containers cannot contain vulnerabilities that cross the container boundary into their common kernel. The 2025–2026 CVE landscape provides concrete evidence:

runc vulnerabilities (November 2025): Three high-severity CVEs allowing container escape to the host system, affecting Docker, containerd, and every managed Kubernetes service. The attack path starts inside a container and reaches the host kernel.

CVE-2026-34040: Docker authorization bypass via oversized HTTP requests — allows unauthorized creation of containers with full host access. Fixed in Docker Engine 29.3.1.

CVE-2024-1086: Use-after-free in Linux's netfilter subsystem. Confirmed actively exploited in ransomware campaigns (CISA advisory, October 2025). Reachable from inside a container.

DinD --privileged: jackin❯ runs a privileged DinD sidecar today. A --privileged container has near-full access to the host kernel — in jackin❯s case, OrbStack's Linux VM kernel. Recent attack chains have started from legitimate AI agent setups that followed Docker's own security recommendations.

The shared-kernel insight: The attack surface for all of these is the kernel. Every jackin❯ session shares one OrbStack Linux VM kernel. A successful kernel exploit in one session reaches all sessions. This is not a configuration problem — it is structural.

Credential exposure

Credential exposure is independent of the kernel boundary.

The current jackin❯ model injects agent credentials (Claude API key, GitHub token, SSH keys) into the role container as environment variables or synced files. This means:

The agent process can printenv and read raw API keys
The agent can read credential files from the agent home mount
The agent retains credential values in its context window across prompts
Multiple agents sharing a workspace can access each other's credentials if one is compromised
An agent prompted to exfiltrate data can extract raw token values

This is not a kernel-level problem. It exists regardless of whether the backend is Docker, OrbStack isolated, or a full microVM. A VM boundary gives each session its own kernel — but if the API key is an environment variable inside that VM, the agent can still read it.

The two problems are independent and require independent solutions.

macOS VM landscape

A viable macOS ARM backend needs a true per-workload kernel boundary.

Firecracker: requires KVM (Linux-only). On macOS ARM, needs nested virtualization inside a Linux VM — not officially supported by the Firecracker project. Not viable.

gVisor: syscall interception in userspace — no KVM required. But confirmed broken on OrbStack macOS ARM (orbstack/orbstack#2362 — /tmp → /private/tmp symlink causes runsc to crash immediately). Claude Code hangs indefinitely in gVisor on macOS ARM (anthropics/claude-code#35454). Not viable on current platform stack.

smolvm uses Hypervisor.framework on macOS and libkrun on Linux. Version 1.0 added a Docker-in-VM path plus newer fork, memory, host-access, and SSH-agent features; the dedicated dossier remains Needs refresh until these are revalidated together. See smolvm backend research.

Docker Sandboxes: productized microVM runner from Docker Inc. (launched January 2026). Runs each agent session in a dedicated VM using a proprietary VMM on Apple's Hypervisor.framework. Has a built-in credential proxy and network proxy. It is not a backend API for jackin❯ to build on; it is a complete agent runner that replaces jackin❯'s role. See Docker Sandboxes.

Apple Container framework (macOS 26 Tahoe, WWDC 2025, apple/container 1.0): each OCI container runs in its own lightweight VM via Virtualization.framework on Apple Silicon. It provides a per-container kernel, vmnet IP, OCI-compatible lifecycle, and vminitd gRPC/vsock process control. The signed package or Homebrew install is separate from macOS.

Key finding for Apple Container: --privileged is not supported. The documented alternative is --cap-add <CAP> for specific capabilities. This means the current jackin❯ DinD sidecar (which requires --privileged) cannot run inside an apple/container VM without changes. Rootless DinD — which replaces --privileged with specific capability grants — is the compatibility path, but requires the Docker runtime hardening contract work to complete first.

Per-operation isolation

Even inside a VM with its own kernel, an agent's individual tool calls remain unconstrained.

When an agent runs npm install, that subprocess inherits every secret in the container's environment, can write to every writable path, and can reach every network endpoint. The VM boundary prevents kernel escapes — it does not prevent an agent from reading a secret it was given or writing to a path it should not touch.

This is the gap that process-level sandboxing fills. Evidence from Zerobox — the open-source library powering OpenAI Codex CLI's sandbox mode — confirmed that per-operation isolation is achievable with 10 ms overhead per invocation, using OS-native primitives (Bubblewrap + Seccomp + Landlock on Linux, Apple Seatbelt on macOS).

On-demand credentials

Credential exposure requires a different mechanism from VM isolation and process sandboxing: a two-tier workspace environment model and a jackin-exec subcommand of jackin-capsule.

Two env tiers — same env map, one new flag:

{ op = "...", path = "..." } (default): injected into container at launch, all processes see the resolved value
{ op = "...", path = "...", on_demand = true }: NOT injected at launch, NOT visible via printenv; appears in a TUI picker dialog when the agent calls jackin-exec, operator selects which credentials to attach, host resolves via op read at that moment, injected ephemerally for the command duration

jackin-exec = jackin-capsule exec: a symlink, not a separate binary. The agent calls jackin-exec gh pr create; the capsule subcommand shows the on-demand picker, resolves selected credentials via the host process, injects them as temp env vars, runs the command, scans output for leaked values, deletes temp values. Raw credential values never appear in the container's process environment.

This is the same architecture Docker Sandboxes uses for its host-side credential proxy — except jackin❯ builds it explicitly, with a TUI-native picker dialog and full operator control.