Drop_S5_Ultra

§5 Security model

A test guest runs agent-authored, potentially hostile code — buggy or prompt-injected, on our infra, time-boxed and disposable. That single fact sets the bar. The honest adversary is not a nation-state attacking internet-submitted code; it is our own agent writing escape/exfil code inside one timeout_ms window on a clean-snapshot guest with no 0-day supply. Don't over-spec (microVM-for-everything) nor under-spec (gVisor-waves-everything).

The ultra pass broke all six v0 hypotheses and broke the first-draft hardening of each. The binding finding: the bar aimed containment at the hypervisor boundary, but the real risk has moved OFF the kernel boundary and ONTO two channels the v0 bar was silent on — the test-result trust oracle and the collect / filesystem exit path. Both are backend-independent; neither gVisor-vs-Firecracker touches them.

§5.1 The gVisor-vs-microVM ruling (gates §4.3 / OQ1, falsifiable)

gVisor-on-lab (Systrap platform) CLEARS the bar for the stated own-reviewed-code threat model. Firecracker is correctly DEFERRED. To escape, a guest must chain two breaks — compromise the memory-safe Go Sentry (realistic class: logic/type-confusion in netstack or the unsafe-Go host-FFI edges, not the C heap overflow that breaks runc), then defeat the host-side seccomp-bpf cage that confines the Sentry to ~68 host syscalls (execve/open/socket denied). That two-link chain is not a credible single-shot for an agent that cannot author a novel chained gVisor 0-day in one timeout window. Accepting gVisor's single shared-kernel boundary here is a sound, bounded risk.

Two corrections this RFC must fold: (1) "weaker because no KVM" is false. On a no-KVM host gVisor runs the Systrap platform (seccomp-trap + SIGSYS + shared-mem, designed to run without hardware virt); the ~68-syscall seccomp cage is platform-independent. "No KVM" changes interception mechanism/perf, not the escape surface. gVisor's real weakness vs Firecracker is the shared-kernel single-boundary fact. (2) The "~24-syscall passthrough" figure in §4.3 is Firecracker jailer's VMM seccomp filter, not a gVisor host count; gVisor's relevant number is ~68, and neither is a guest→host passthrough.

Register Firecracker the instant ANY trigger trips (host-side, falsifiable): T1 a guest gets a live-internet research loop (egress widened beyond a fixed mirror) → 0-day supply + exfil channel. T2 the membrane runs code that is not our-own-agent-authored (third-party PRs, multi-tenant) → the own-code limit that carries this ruling evaporates. T3 a guest needs a host-syscall the ~68-cage denies (GPU/CUDA, raw devices, nested containers) forcing --network=host or runsc passthrough → the cage is being widened. T4 two correlated Sentry/netstack CVEs in one cycle (chainability). T5 a workload genuinely requires PR-authored harness/workflow control (cannot run under a host-pinned harness) → the trust oracle is no longer host-reconstructable.

Co-location corollary: gVisor-on-lab is sound only under a dedicated unprivileged service user with no read access to the orchestrator user's $HOME, and only if the pressure/kill monitor lives OFF the gVisor box. Co-tenancy with the credential-bearing user — not kernel-sharing — is the actual exfil/DoS hole. If commander insists on one box at v0, label it DIAGNOSTIC / NON-HOSTILE-ONLY and forbid unreviewed agent code on it until the monitor is off-host — exactly §4.3's "lab is orchestrator, never hypervisor" line, which a one-box gVisor backend violates.

§5.2 Allowlist-only is NOT sufficient — two named exfil paths survive it

§3.2(b)'s scrub_env_for_test_guest allowlist and the "creds file never bind-mounted" promise are env-var-scoped and by-name. Both are bypassed: the secret crosses on the filesystem, not env, and exits via collect(), not egress.

Path A — mesh-identity forge (critical, the sharpest hole). A prompt-injected guest never escapes the kernel. It reads /home/ubuntu/.config/swarph/drop-on-meta-edge.peer_token (verified 0600, a live mesh bearer secret; sibling of the repo checkout under one $HOME) off whatever host path the runtime mount namespace exposes, POSTs it to mesh-gateway, and authenticates as that peer (mint-once; gateway stores only the sha256; _authorize resolves token→peer → 200). This defeats the §7.3 identity-privacy-IN boundary — the first direction of the very principle this RFC calls the third direction of. The guest never needed claude OAuth; it forges a node identity. The first-draft fix ("guest image contains no path under ~/.claude, ~/.codex, ~/.gemini") is a 3-dir denylist wearing the word allowlist — the same §3(b) failure-class one layer down. Verified: a dozen+ 0600 bearer secrets sit outside those three dirs (7 *.peer_token, ~/.gemini/antigravity-cli/antigravity-oauth-token nested two deep, ~/.ssh keys, ~/.kaggle/access_token, ~/.docker/.token_seed, slapshotscience-pipeline/.claude/.mesh_token). And it checks the wrong artifact: gVisor composes the guest filesystem view at provision from a runtime mount spec, not a baked image, so a backend that mounts host $HOME or / "for convenience" passes an image-clean check while exposing everything.

> MUST (host-side): invert to a deny-by-default filesystem allowlist over > the guest's resolved mount namespace — the guest sees only > `{ref-under-test, tmpfs scratch, read-only runtime PATH dirs, declared test > inputs}. Enforce at provision in the runsc config.json` mounts / Firecracker > drive list. Ancestor-aware: reject any mount source that is, or is a > parent of, any secret-bearing path. The membrane refuses provision when the > resolved mount set exceeds the allowlist. This excludes the next $HOME > secret that ships after this RFC — which a named denylist cannot. State the > §5.2 promise in its general form: *no secret-bearing path is reachable from the > guest, on every registered backend.*

Path B — collect-channel via JUnit free-text leaves (critical, backend-independent). JUnit XML is an agent-authored document; testcase@name, failure@message, the / #text traceback and system-out/err are free-text leaves the test code writes. `assert False, base64_chunk_N(open(SECRET).read())` produces a structurally valid JUnit doc; collect() parses "N failures" (schema satisfied) and §3.1(a) requires the failure detail be carried to the host-side, mesh-readable sink so a human can read why it failed — the base64 rides out inside the failure detail the RFC's own rule mandates surfacing. "Structured schema can't smuggle a blob" is false: the schema constrains the container, the attacker writes the leaves.

> MUST (host-side): the verdict is a fixed-arity numeric tuple > {exit_code, passed/failed/skipped/errored, duration}, host-parsed, and the > source document is discarded before anything reaches a mesh-readable sink. > No attacker-authored free-text leaf transits the trust boundary. Failure detail > goes to a quarantined, non-mesh-readable, access-gated store with explicit > human-unseal. The green/red bit is five integers — it cannot carry 16 KB of > base64. If a deployment insists on surfacing messages, add a host-side per-leaf > byte cap (≤256 B) + entropy/base64/hex detector with redact-or-quarantine, at > the leaf, where the smuggle lives.

§5.3 The trust oracle — do not trust guest-emitted verdicts (the killer app)

The §1 killer app retro-validates PR#46 + 0.9.5 by trusting guest output. A prompt-injected guest doesn't break the kernel — it forges a green. `pytest || true, continue-on-error: true (which sets job conclusion=success` over outcome=failure), a pytest_collection_modifyitems hook that deselects the ctypes test, a conftest.py that writes green and sys.exit(0) — all make a host-observed exit code / job conclusion honest about a process the adversary shaped. Host-pinning the transport secures provenance, not semantics.

> MUST (host-side, the load-bearing fix): (a) host-pin the execution > harness, not just the transport — the .github/workflows/*.yml (windows) / > guest entrypoint (gVisor) is host-authored on a host-controlled ref; the agent > supplies code under test, never the runner spec; continue-on-error/|| true > forbidden in the pinned harness. (b) re-derive the verdict from per-test > records (the §5.2 numeric tuple), distrusting artifact pass/fail AND exit > code AND conclusion equally. (c) required-node-id floor — the 0.9.5 > ctypes/CreateToolhelp32Snapshot ancestry test and the PR#46 > session-UUID-on-cwd-change test MUST appear by node-id in the executed set, > zero xfail/skip masking, tests-collected ≥ a host-known minimum; > green-but-named-tests-not-executed is collect-suspect, never silent-green > (extends §3.1(a) collect-failed to collect-FORGED). (d) forbid agent > authorship of the harness layer — a diff touching workflows / conftest.py > collection hooks / sitecustomize.py / pytest.ini addopts is > collect-suspect + escalate. > > Residual (named, no containment closes it): host exit + node-id floor prove > the suite ran and passed, not that it was honest. A guest that poisons the > binary under test still ships a subtly-wrong validated artifact. Needs > reproducible-build / pinned-test-ref discipline — out of membrane scope, but > the PR#46/0.9.5 oracle must not be over-trusted.

§5.4 windows-cloud is the v0 marquee AND it is guest-honor-system (primary hole)

§6 ships v0 = browser + windows-cloud; gVisor/microVM are deferred — so at v0 none of the kernel/cgroup/host-egress controls exist on the path that ships. On GitHub-hosted windows-latest the mesh owns no host: no netns/nftables (egress), no sweeper (GitHub destroys the runner), no cgroup hierarchy. The current SWARPH_SKIP_NETWORK=1 (ci.yml:20) is a voluntary pytest.mark.skipif (test_smoke_discovery.py:22-24) — hostile code ignores it on a runner with full outbound internet. pip install -e ".[dev]" runs the ref's build backend and pytest auto-loads the ref's conftest.py/plugins, so agent-authored code detonates with the runner's token before a single assertion. "Run the ref as DATA" is a category error for a CI-validation workload.

> MUST: classify backend isolation-class as a first-class, > host-validated registry property (parallel to the VALID_ENVIRONMENTS↔membrane > lockstep): each backend declares `{egress: host-enforced|best-effort|none, > teardown: host-sweeper|provider-auto, code-exec: contained|honor-system}`. > GitHub-hosted windows-cloud is honestly `{best-effort/none, provider-auto, > honor-system}`. The membrane refuses to dispatch an unreviewed/hostile ref > to any backend whose row is not all-host-enforced. windows-cloud honesty > gate: accept only refs git-ancestry-pinned to a human/CI-reviewed commit > (default branch / signed tag) — never a raw agent branch HEAD; unreviewed agent > code requires a mesh-owned isolation host (self-hosted runner inside > gVisor/Firecracker, e2b self-hosted, or a cloud VM in a mesh-owned VPC with > host-set default-deny egress). This removes the hostility rather than pretending > to contain it — matching the honest own-reviewed-code threat model. > > Dispatch-token custody (second exfil surface): provision/collect uses the > orchestrator's broad gh oauth token (~/.config/gh/hosts.yml, darw007d). Use > a least-privilege fine-grained PAT scoped to workflow-dispatch + > actions-read on the single repo, never the user-scoped token. Every dispatched > workflow runs permissions: contents:read, id-token never write, > secrets: {}, pull_request_target forbidden — and since "free for OSS = > public repo," JUnit artifacts + job logs are world-visible, so treat the > sanctioned output channel as an assumed-exfil surface and inject no secret > into a windows-cloud cell.

§5.5 Egress, build-isolation, DoS, snapshot-at-rest (host-side, condensed)

Egress (§5#3) is no flag. Host-enforced default-deny: dedicated netns + nftables drop-all-egress allowing only a content-logging, rate/volume-capped forward proxy; DNS pinned host-side (kills label-encoded exfil a host allowlist misses); package-pull from a host hash-pinned mirror fed an offline-resolved lockfile. The egress allowlist is a host-side constant, never a cell-supplied extra value (§2.2 round-trip applied to the most dangerous flag). Residual: the one allowlisted hop (the mirror) is a bounded in-band/timing covert channel — capped + anomaly-reviewed, not eliminated.

Build-isolation (the cliff network-deny cannot cover). Install uses --only-binary=:all: / pre-built hash-pinned wheels — no setup.py/PEP517 build-hook execution under guest-controllable manifests. The lockfile is re-resolved only by a host process on a reviewed manifest diff; an unreviewed manifest change with no reviewed lock-bump is refuse-to-provision. This is where §5.1 is forced concrete: arbitrary-code-at-install defeats network-deny on a kernel-shared sandbox, so unreviewed code belongs on the own-kernel backend (trigger T2).

DoS (§5#4) — reap on causation, not footprint. §5#4 names only CPU/mem/pids; add blkio/disk quota + inode cap + PID-creation-rate + per-veth HTB/conntrack rate-limit (gVisor's internal netstack hides per-sandbox attribution otherwise). Reaping on PSI must select the highest pressure-contribution slope, not the "heaviest" sandbox — the killer-app CI is legitimately heaviest and must be class=protected, reaped last. Bound the Sentry/gofer host-process class explicitly (same accounting cgroup as the guest; FD/thread caps; same oom_score band so OOM reaps guest+delegates atomically). The pressure-monitor + out-of-band kill clock must live off the gVisor box, or "who reaps the reaper" recurses to "who clocks the clock."

Snapshot-at-rest (§5#5/#6). "Pristine" is a host-enforced invariant over the base + cache + staging triple, not the VM image: content-addressed sha256-pinned read-only base; per-run COW overlay destroyed on teardown, never promoted back; warm-pool = discard-not-reset; cross-run caches (actions/cache, pip cache) disabled or host-content-verified, never workflow-honor-system-scrubbed. The pinned-digest allowlist + dependency-hash lockfile live in host-only custody (signed/off-repo), mutable only via the sweeper's authenticated path — never an in-repo frozenset the agent can PR. pause/warm memory snapshots are encrypted-at-rest with a host-held key, TTL-bound (the reaper destroys stale snapshots too); the sweeper authenticates scoped, past-lease-only destroys against a host-signed lease stamp; and collect() reconciles the guest verdict against a host-side egress-event count keyed by a host-minted run-nonce the guest never sees, so a forged green cannot suppress a host-observed block. Residual: a leaked memory dump carries whatever the guest touched, in cleartext — the upstream fix is §5.6.

§5.6 Provider × Environment compose (resolves §7-OQ4) — the gap is real

OQ4 answers YES, the double-scrub creates a gap, and it is critical. A provider nucleus authenticates by a credential file on disk, not an env var (subprocess_env.py is, by its own docstring, "denylist not allowlist by design"). For a billed nucleus to run inside a guest, ~/.claude/.credentials.json must be readable there — but §3.2(b) says it is never bind-mounted. So "billed-nucleus-inside-a-creds-denied-guest" is a contradiction. Both scrubs are env-var-scoped; the OAuth file rides a third channel (the $HOME filesystem mount) neither sees, and hostile guest code exfiltrates a refresh-capable subscription token over the collect path.

> RESOLUTION (host-side): rule the §3.2(c) compose OUT for the hostile-guest > case. A billed nucleus is never spawned inside an untrusted guest; the > nucleus orchestrates from the trusted host and reaches in only over > collect/RPC (the claude-service auth-surface-minimization pattern). Enforce at > spawn_agent as a MEMBRANES↔VALID_PROVIDERS-style lockstep refusal. The > allowed compose is `provision(world) → run UNTRUSTED payload → collect over > RPC → teardown`, nucleus host-side. Generalize the refusal from "no billed > nucleus in-guest" to "no host-identity secret reachable in-guest" — the > in-guest nucleus was just the first instance of host-secret-leakage-via-mount, > and the §5.2 deny-by-default filesystem allowlist (ancestor-aware, over the > resolved mount namespace) is the one host-side check that covers nucleus > creds and peer-tokens and SSH keys. That is §7.3 stated correctly: > test-containment-IN is also identity-privacy-IN — the guest must not be > able to read a credential or forge a peer.

Net for §5: the deferred-Firecracker decision is correct today, and gVisor-on-lab genuinely clears the kernel bar for own-reviewed-code. The binding risk has moved off the hypervisor boundary onto the trust oracle (§5.3), the filesystem/collect exit path (§5.2), and the honor-system v0 marquee (§5.4) — which is exactly where the v0 bar was silent and where hardening goes first.