Maintaining Agent Sandbox Systems: Rollout, DX, and the Cost of the Boundary Over Time

The compute and filesystem-custody boundaries are the parts that stay true with no maintenance. Reproduced directly on macOS (Darwin 24.1.0):

sandbox-exec -p '(version 1)(allow default)(deny file-read* (subpath "/Users/<me>"))' \
  cat ~/.zsh_history          → cat: ...: Operation not permitted     ✓ blocked
sandbox-exec -p '(version 1)(allow default)(deny network*)' \
  curl http://1.1.1.1/        → Failed to connect ... (000)           ✓ blocked

These can be treated as load-bearing and unattended: they are enforced by the kernel sandbox, not by a policy that drifts. This is the good news, and it is why the rest of the cost is concentrated in the two axes below.

A field experiment on Darwin 25.4.0 found that a Seatbelt rule that looks like it restricts egress to loopback — (allow network-outbound (remote tcp "localhost:*")) — actually matched arbitrary remote destinations, leaking to the LAN. The natural conclusion would be "never trust per-host SBPL narrowing."

Attempting to reproduce it on Darwin 24.1.0 produced the opposite result: the same rule blocked both a public IP and a LAN host. The connection that leaked on one macOS version is refused on another.

# Darwin 24.1.0, same rule the field report saw leak on 25.4.0:
sandbox-exec -p '(version 1)(allow default)(deny network*)
                 (allow network-outbound (remote tcp "localhost:*"))' \
  curl --connect-timeout 4 http://<public-ip>/   → could not connect (blocked)
  curl --connect-timeout 4 http://<lan-host>/    → could not connect (blocked)

That contradiction is the finding, and it is the one that matters most: a security control whose behavior depends on the macOS point release is not a control you can roll out and forget. It must be re-tested on every OS update, across every developer's machine, or it provides assurance on some laptops and a false sense of it on others. The Apple sandbox's network grammar is coarse and its semantics are not a stable contract across versions.

The durable consequence (which both the field report and the runbook reach independently): do not make per-host SBPL rules the egress boundary. Put the boundary at an egress proxy chokepoint — a thing whose behavior you control and can test once, not a rule whose meaning Apple changes between releases. On FreeBSD/Linux the equivalent (pf / jail egress filtering) is stable; on macOS the proxy is the only egress control worth depending on over time.

Consolidating egress onto one proxy is the right architecture — one chokepoint to audit, one place to inject credentials, one boundary to test. But it concentrates risk: the proxy is the one process that holds the keys to everything behind it, and in 2026 that process had a bad year. Both events are verified against primary sources:

• CVE-2026-42208 — a pre-authentication SQL injection in the LiteLLM proxy's API-key verification path: the Authorization: Bearer value was concatenated into a query against the token table without parameter binding. CVSS 9.3, fixed in 1.83.7; Sysdig observed targeted exploitation roughly 36 hours after disclosure, enumerating exactly the tables holding virtual keys and stored provider credentials.
• PyPI supply-chain compromise — versions 1.82.7 and 1.82.8 shipped a credential-stealer (a .pth launcher that ran on interpreter start, no import needed), published with maintainer credentials stolen in the Trivy attack. GHSA-5mg7-485q-xm76; last clean release 1.82.6; the malicious wheels were live for ~3 hours against a package pulled millions of times a day.

The maintenance consequence is concrete: the egress proxy is not install-and-forget infrastructure. Pin it by hash (not just version range), track its advisories like you track your own dependencies, bind its admin/management routes to loopback, TLS-terminate with strict Host: validation in front, and audit guardrails for fail-closed behavior (LiteLLM's defaulted to fail-open on provider errors). The chokepoint earns its place only if it is patched with the discipline its blast radius demands.

The secret-custody axis is where teams assume they lack a capability when they actually lack a contract. The isolation primitives exist; what is missing is the spelled-out handoff: who mints a scoped, short-TTL credential, who consumes it, who revokes it, and on what signal. A field run confirmed the full lifecycle works at the tmpfs-file layer, and that the credential never needs to enter the sandbox at all if a host-side proxy injects it (the strongest channel).

The naming that makes this legible borrows from OIDC: the component is a Session Issuer — it holds the master key, mints scoped ephemeral credentials per session, keeps the audit, and presents a single revocation surface. The verb is issue; the artifact is a credential bundle. Treating it as an Issuer (rather than an ad-hoc "broker") is what lets the same contract serve different agents without coupling to one implementation — which is the whole point at rollout time, when you have more than one kind of agent.

Drawing from the above, the questions that separate a sandbox you can operate from one that quietly rots:

• Boundary re-test on OS update. Is the macOS sandbox network behavior re-tested on every point release, on a representative laptop? (It changed between 24.1.0 and 25.4.0 — proven above.) If not, your egress assurance is stale.
• Egress at a proxy, not per-host rules. Is the egress boundary a controllable chokepoint (proxy / pf / jail filter), not an OS sandbox rule whose semantics you do not own?
• Proxy patch discipline. Is the egress proxy pinned by hash, its advisories tracked, admin bound to loopback, guardrails fail-closed? (See the 2026 LiteLLM record.)
• A credential contract, not a credential. Is there a named Issuer with per-session scoped keys, a single revocation surface, and an audit trail — or are long-lived keys handed around?
• DX cost honestly counted. Every layer (jail, Seatbelt, proxy, broker) is a thing a developer must understand to debug a failure. Is the boundary documented as a runbook the next operator can follow, or is it tribal?

The throughline: the cheap part of sandboxing is the part the kernel enforces; the expensive part is everything that depends on a vendor's changing behavior (the OS sandbox grammar, the proxy's CVE posture). Budget for the expensive part as recurring maintenance, not a one-time setup.

Per the annotation-systems methodology, each load-bearing heading above carries a :VERIFIED: drawer with a verdict:

• reproduced — re-ran on this machine (sandbox-exec, Darwin 24.1.0, 2026-06-23).
• disputed — reproduction contradicted the source claim across OS versions.
• verified — confirmed against primary sources (CVE/advisory).
• attributed — taken from a field report, not independently re-run here.

The homelab field experiment that drives the secret-custody and egress findings is kept as internal evidence (not published); this note carries only the generalizable, re-verified result.

• Practical Agent Sandbox Configurations — the hands-on runbook (FreeBSD jails, Seatbelt, egress proxy)
• Agent Sandbox Systems — the four-axis decomposition
• Deployment Systems — credential-less targets / the distributed surface
• Team Topologies for the Agentic Platform — who maintains the boundary
• Annotation Systems — the verdict / proof methodology used here

• Sysdig — "CVE-2026-42208: Targeted SQL injection against LiteLLM's authentication path" (sysdig.com)
• Bishop Fox — "CVE-2026-42208: Pre-Authentication SQL Injection in LiteLLM Proxy" (bishopfox.com)
• GitHub Security Advisory — GHSA-r75f-5x8p-qvmc (CVE-2026-42208); GHSA-5mg7-485q-xm76 (PyPI 1.82.7/1.82.8 credential-harvesting compromise)
• LiteLLM — "Security Update: CVE-2026-42208 in LiteLLM Proxy" (docs.litellm.ai)