# Secure Agent Code Execution Architect BUYER-SPECIFIC DESIGN · Engineering Reference v1.0 · 23 October 2026 DESIGN STATUS: NEEDS DECISION RUNTIME SECURITY TESTS: NOT RUN ## 1. Verdict and reference decision Recommended architecture: One disposable Firecracker microVM per execution attempt, with a privileged host resource broker, isolated guest workload, host-initiated control transport, and independently constrained artifact extraction. This is a conditional engineering reference, not an approved production deployment. The workload consists of untrusted Python and Node.js code generated by AI, operating in a cloud-hosted SaaS where independent tenants may actively attempt isolation bypasses. A process-only container boundary is not the preferred reference for that threat model. ### Five consequential decisions | Decision | Reference choice | Condition / reversal | | ------------------- | ------------------------------------------------------------------------------- | ---------------------------------------------------------------- | | Tenant isolation | Separate KVM-backed microVM per attempt | Requires verified Linux/KVM permissions and host compatibility | | Runtime access | Immutable Python/Node.js images, no runtime NIC, no ambient secrets | Dependency preparation occurs separately | | Execution control | Host broker exclusively owns resource mutations and fencing epochs | Requires durable, independently enforceable ownership | | Artifact trust | Terminate guest, isolate extraction, validate immutable bytes, then clean up | Extraction may not trust a guest-controlled filesystem | | Production capacity | Start with 20 global job slots as an admission target, not proven host capacity | Benchmark boot latency, VMM memory and throughput before rollout | Strongest practical alternative: Dedicated hardware-virtualized worker pools, each running an equivalent disposable VM boundary, under a cloud provider offering verified VM isolation and fencing operations. This replaces Firecracker-specific integration, not the ownership, cleanup, network, or export requirements. Plain rootless containers alone are not an equivalent boundary for the confirmed potentially hostile multi-tenant threat model. ### Proposed architecture Proposed trust boundaries. Arrows indicate authorized orchestration or data transfer, not unrestricted network access. The guest is never authorized to control host resources. Firecracker documents its host Unix-socket-to-guest-vsock transport, but actual cloud/KVM support, jailer permissions and compiled security policies for this deployment remain UNVERIFIED.  [image](https://www.google.com/s2/favicons?domain=https://github.com\&sz=32) GitHub +1 The 20-concurrent-job objective is a global admission ceiling, not a statement that one machine can safely host 20 microVMs. ## 2. Protection preservation and enforcement The following table preserves all 16 baseline controls at design level. Preserved means the mechanism is specified, not installed or verified. | ID | Status | Mechanism, enforcer and failure behavior | Planned test | | --- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------- | | G01 | Preserved | API authenticates principal; server resolves tenant and checks ownership for every job/log/artifact action. Deny mismatches. | T02.api | | G02 | Preserved | Per-attempt Firecracker guest and isolated workspace; host broker controls VMM. Stop admission if VM isolation unavailable. | T03.identity, T07.fencing | | G03 | Preserved | Trusted guest init UID 0 forks workload UID/GID 10001; clears groups/capabilities/FDs, installs MAC/seccomp, no-new-privileges. Reject failed policy installation. | T03.identity, T03.channel | | G04 | Preserved | Digest-pinned read-only image and inputs; isolated bounded writable volumes; no shared caches, unauthorized devices or host mounts. Deny launch on mutation. | T03.fs_secret, T05.storage | | G05 | Preserved | Explicit environment allowlist; no inherited cloud/API/SSH credentials. Reject undeclared secret requirements. | T03.fs_secret | | G06 | Preserved | No guest NIC, host network isolation, restricted vsock control channel, AF_VSOCK denied to workload. Reject unapproved exceptions. | T04.deny, T04.exception, T03.channel | | G07 | Preserved | Guest cgroups and rlimits plus outer host VMM cgroups, rlimits, watchdog and storage quotas. Terminate at thresholds. | T05.cpu, T05.memory, T05.pid_fd, T05.storage | | G08 | Preserved | Scheduler enforces global 20-slot ceiling, per-tenant fairness, finite queue and reserved control-plane capacity. Reject/defer excess. | T05.admission | | G09 | Preserved | Pre-attached bounded stdout/stderr/console/VMM collectors, individual and aggregate caps. Drain/discard after overflow or terminate. | T05.output | | G10 | Preserved | External deadline and durable cancel intent; broker proves physical stop; no blind retries. | T01.python.wall, T07.races | | G11 | Preserved | Independent watchdog, broker-authoritative epochs and reconciliation. Quarantine unresolved ownership. | T07.fencing, T08.recovery | | G12 | Preserved | Stop proof, sealed source, disposable extractor, independent validation, immutable export, then cleanup. Reject unsafe files. | T06.export, T06.parser | | G13 | Preserved | Digest/lockfile policy, restricted offline runtime preparation, provenance checks, scanner, revocation and rollback. Block revoked inputs. | T08.supply_audit | | G14 | Preserved | Versioned event/audit schema, protected bounded retention, access checks and incident alerts. Block incomplete critical audit transitions. | T08.supply_audit | | G15 | Preserved | Resource journal and independently inventoried cleanup with retry bounds, quarantine and deletion records. | T08.recovery | | G16 | Preserved | Separate workload/artifact/cleanup outcomes, adversarial validation, benchmarks and release gates. No security certification without evidence. | T01.python.nonzero, T06.export, T08.recovery | ### Identity boundaries - Host broker: `sandbox-broker`, privileged narrowly for VMM lifecycle, jailer/cgroup setup and resource ownership. Its OS UID and granted capabilities require implementation verification. Controller and scheduler have no VMM/provider credentials. - Host VMM/jailer: reference host UID/GID `20020:20020`, in a per-attempt jail with job-scoped devices, storage and sockets. The intended mapping must be confirmed against the selected jailer implementation. - Guest trusted init: guest UID `0`, using only required guest setup privileges and without host-root authority. - Guest workload: UID/GID `10001:10001`, no supplementary groups, capabilities, setup privileges or inherited control descriptors. - Extractor: isolated disposable execution domain, unprivileged relative to host and with separate outer resource enforcement. After a guest-kernel compromise, guest UID, cgroup, seccomp and MAC boundaries cannot be treated as intact. The microVM/host VMM boundary remains the primary intended containment layer, subject to hypervisor and device-model vulnerabilities. Read-only access to necessary OS/interpreter libraries remains allowed; the prohibition concerns unauthorized tenant or host information. ## 3. Boundary policy and control channel ### 3.1 Custom launcher policy INCOMPLETE TEMPLATE REQUIRING VERIFICATION · Custom policy schema, not Firecracker configuration syntax ``` { "schema": "sandbox.policy.v1", "profile": "standard-py-node-v1", "ownership": { "attempt_id": "attempt-demo-001", "broker_epoch": 1, "exclusive_slot": true, "lease_fail_closed": true }, "host": { "vmm_uid": 20020, "vmm_gid": 20020, "jail_per_attempt": true, "api_socket": "broker-only", "vsock_socket": "broker-adapter-only", "vmm_memory_max_mib": 1280, "vmm_pids_max": 32, "vmm_nofile": 128, "vmm_cpu_quota_vcpu": 2, "vmm_cpu_budget_seconds": 75 }, "guest": { "vcpus": 2, "ram_mib": 1024, "trusted_init_uid": 0, "workload_uid": 10001, "workload_gid": 10001, "supplementary_groups": [], "workload_memory_max_mib": 512, "workload_pids_max": 16, "workload_nofile": 64, "workload_cpu_budget_seconds": 60, "workload_cpu_rate_vcpu": 2, "workload_rlimit_cpu_seconds": 45, "no_new_privileges": true, "capabilities": [], "seccomp_workload_deny_socket_families": [ "AF_VSOCK", "AF_INET", "AF_INET6" ], "root_image": "immutable_digest_pinned", "input": "read_only_authorized", "work": "private_quota_64MiB", "tmp": "private_quota_16MiB", "output": "private_quota_50MiB", "network_interfaces": [], "allow_host_mounts": false, "allow_ambient_secrets": false }, "collection": { "stdout_mib": 8, "stderr_mib": 8, "console_mib": 4, "vmm_log_mib": 2, "artifacts_mib": 28, "total_retained_mib": 50, "overflow": "drain_discard_and_mark_truncated" }, "transport": { "initiation": "host_only", "guest_runner_port": 5000, "max_frame_bytes": 65536, "max_total_bytes_each_direction": 1048576, "max_messages_each_direction": 128, "session_deadline_seconds": 60 }, "lifecycle": { "provision_boot_seconds": 20, "workload_wall_seconds": 30, "stop_proof_seconds": 10, "extraction_seconds": 20, "cleanup_seconds": 20, "attempt_hard_deadline_seconds": 100 }, "artifact_allowlist": ["results/report.json"] } ``` The 1 GiB guest reservation exceeds the 512 MiB workload limit by 512 MiB for guest kernel, init, runtimes and collectors. The provisional 1,280 MiB host VMM memory ceiling provides 256 MiB above guest RAM; whether this headroom is sufficient is UNVERIFIED. The output slices sum to exactly 50 MiB, and an independent aggregate counter rejects any retained total above 50 MiB. These are staging ceilings, not independently measured production recommendations. Internal transport counters and discard metadata must remain bounded separately. Timing contract: 20 + 30 + 10 + 20 + 20 = 100 seconds attempt-wide hard deadline. The workload's 30-second clock is not the entire attempt lifecycle. Test-specific profiles may shorten caps or alter a tested limit, but must retain the stated outer hard deadline. CPU rate throttling is different from cumulative CPU usage. Guest aggregate CPU comes from a workload cgroup plus a privileged guest monitor; host VMM aggregate CPU is independently watched. `RLIMIT_CPU` is supplementary per-process protection, not the cumulative job cutoff. Host cgroups also cannot directly count guest process threads. Linux cgroup v2 documents the relevant memory, CPU and PID controls.  [image](https://www.google.com/s2/favicons?domain=https://kernel.org\&sz=32) The Linux Kernel documentation +1 ### 3.2 Required adapter sequence ILLUSTRATIVE PSEUDOCODE · Adapter implementation not verified ``` def broker_launch(spec, epoch): assert broker_is_sole_mutation_authority() assert durable_epoch_and_exclusive_slot(spec.attempt_id, epoch) assert provider_isolation_and_fencing_verified() assert digest_and_revocation_checks_pass(spec) assert runtime_input_mounts_are_immutable(spec) assert host_jail_and_device_allowlist_verified(spec) assert host_vmm_cgroups_and_rlimits_read_back(spec) assert collector_paths_caps_and_aggregate_gate_ready(spec) assert no_nic_or_unapproved_host_socket_exists(spec) assert watchdog_and_local_monotonic_deadline_armed(spec) vm = create_vm_with_journal(spec, epoch) if not setup_evidence_complete(vm): quarantine_and_stop(vm) return "BLOCKED" # Guest init UID 0 performs trusted setup. # It mounts prepared read-only storage, sets up guest # cgroup enforcement, opens privileged runner channel. # Trusted init forks the workload child. # Child: setgroups([]), setgid(10001), setuid(10001), # clear capabilities, close control descriptors, # install verified MAC/no_new_privs/seccomp sequence, # exec workload. # Every unverified operation fails closed. return start_only_if_exclusive_epoch_still_current(vm, epoch) ``` Trusted init must retain the necessary guest mount/cgroup/UID-transition rights until setup and fork. The child, while still privileged, drops its identity and capabilities before executing the workload. The unprivileged runner never performs mounts, cgroup delegation or a privileged UID switch. A valid compiled seccomp policy must cover `socket(AF_VSOCK,...)`, including applicable compatibility syscall paths and potential descriptor-passing bypasses. Restricting `/dev/vsock` is insufficient. The MAC policy must be applied in an order compatible with `no_new_privs`; an LSM transition cannot simply be assumed to tighten after that flag.  [image](https://www.google.com/s2/favicons?domain=https://www.kernel.org\&sz=32) The Linux Kernel documentation ### 3.3 Host-initiated control channel Use a per-attempt Unix socket inside the host VMM jail, accessible only to the authorized host broker adapter. The adapter initiates the Firecracker-supported connection to guest vsock port `5000`. No host forwarding listener is created for guest-initiated requests.  [image](https://www.google.com/s2/favicons?domain=https://github.com\&sz=32) GitHub The privileged guest init/runner owns port `5000`; the non-root workload may not open AF_VSOCK sockets or inherit privileged channel descriptors. Proposed application protocol: | Contract | Requirement | | -------------- | --------------------------------------------------------------------------------------------------------------- | | Message types | `START`, `CANCEL`, `STATUS`, `EXIT`, `HEARTBEAT`, `ERROR` | | Framing | Length-prefixed frames, max 65,536 bytes; reject malformed or oversized frames | | Session limits | 128 messages and 1 MiB per direction, 60-second session deadline | | Authority | Broker binds attempt ID, epoch and immutable command contract to its own authenticated local session | | Rejection | Unknown commands, unexpected states, wrong attempt/epoch or schema violations terminate session and fail closed | The runner may return observations but cannot select host paths, identities, provisioning instructions, resource limits, arbitrary commands, secret retrieval or tenant authorization. Unix socket ownership authenticates the local host-side peer configuration, not a guest UID. A compromised guest may forge runner responses. Every guest-originated status is therefore untrusted evidence until cross-checked with broker-controlled process, VMM and resource records. ## 4. API, outcomes and authoritative records ### 4.1 API contract Authentication supplies the effective tenant context; the client may never set its authoritative tenant ID, backend, limits or host. | Endpoint | Operation | Required authorization | | ------------------------------------------ | ---------------------------------- | --------------------------------------------- | | `POST /v1/jobs` | Submit immutable job specification | Authenticated tenant, authorized profile | | `GET /v1/jobs/{id}` | Read logical and physical states | Job ownership | | `GET /v1/jobs/{id}/logs` | Bounded logs with stream/offset | Job ownership | | `POST /v1/jobs/{id}/cancel` | Set durable cancellation intent | Job ownership | | `GET /v1/jobs/{id}/artifacts` | List deliverable artifacts | Ownership and delivery gate | | `GET /v1/jobs/{id}/artifacts/{artifactId}` | Download exact sealed bytes | Ownership, manifest binding and delivery gate | Unknown client policy fields return `400`; unauthorized profile references return `403`. Resource limits are selected from server-authorized policy records. Tenant-scoped idempotency uses a canonical submission payload hash: matching key plus matching hash returns the same job; matching key plus different hash returns `409 Conflict`. This prevents duplicate submission records but does not promise exactly-once execution. ### 4.2 Synthetic submission example ILLUSTRATIVE INTERFACE EXAMPLE · Not executed ``` { "runtime": "python", "runtime_digest": "sha256:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa", "script": { "encoding": "utf-8", "content": "import json\nfrom pathlib import Path\nPath('results').mkdir(exist_ok=True)\nPath('results/report.json').write_text(json.dumps({'ok': True}))\nprint('complete')" }, "input_refs": [], "dependency_bundle_ref": null, "artifact_allowlist": [ "results/report.json" ], "requested_profile": "standard-py-node-v1", "idempotency_key": "demo-submit-001" } ``` Schema contract: `runtime` is required enum `python|node`; `runtime_digest` is a required 64-hex-character SHA-256 digest with prefix; `script` requires `encoding=utf-8` and bounded string `content`; `input_refs` is an array of authorized immutable object references; `dependency_bundle_ref` is nullable, otherwise an authorized immutable reference; `artifact_allowlist` is a unique nonempty array of safe relative file paths; `requested_profile` and `idempotency_key` are required strings. Additional properties are forbidden. The example contains no tenant field. The server resolves it from the authenticated principal. The synthetic SHA-256 string demonstrates valid syntax, not a real verified runtime digest. Maximum code/input sizes, artifact path count and request-body limits must be defined in the API schema before implementation; for the proposed staging contract use 256 KiB UTF-8 script, 16 immutable input references, 16 allowed paths and a 512 KiB maximum request body. ### 4.3 Independent outcomes - `workload_outcome`: `SUCCESS`, `NONZERO_EXIT`, `TIMEOUT`, `CANCELLED`, `RESOURCE_LIMIT`, `START_FAILURE`, `UNKNOWN`. - `artifact_outcome`: `PENDING`, `EMPTY`, `REJECTED`, `PARTIAL`, `ACCEPTED`. - `cleanup_outcome`: `PENDING`, `VERIFIED`, `FAILED`, `QUARANTINED`. `EMPTY` means no candidate artifacts; `REJECTED` means candidates existed but none passed; `PARTIAL` means at least one candidate passed and at least one failed; `ACCEPTED` means every submitted candidate passed. `SUCCESS` requires a known zero exit after confirmed stop. `UNKNOWN` cannot be converted into success because a status message appears plausible. ### 4.4 Delivery eligibility The reference rule is exactly: An accepted immutable artifact may be delivered only after guest execution has ended and required execution resources, including the extractor, have verified cleanup. Rejected artifacts are never delivered. | Artifact outcome | Guest stop proved? | Cleanup | Delivery | | ------------------ | ------------------ | ------------------------------ | -------------------- | | ACCEPTED | Yes | VERIFIED | All accepted bytes | | PARTIAL | Yes | VERIFIED | Accepted subset only | | EMPTY | Yes | VERIFIED | No files | | REJECTED | Yes | VERIFIED | No files | | ACCEPTED / PARTIAL | No | Any | Blocked | | ACCEPTED / PARTIAL | Yes | PENDING / FAILED / QUARANTINED | Blocked | Nonzero exit does not itself invalidate an explicitly permitted diagnostic artifact. Any attempt with unknown physical execution state is ineligible regardless of its logical terminal record. Synthetic terminal example for the same submitted job: ``` { "job_id": "job-demo-001", "attempt_id": "attempt-demo-001", "runtime": "python", "runtime_digest": "sha256:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa", "logical_status": "TERMINAL", "workload_outcome": "SUCCESS", "exit_code": 0, "stop_proved": true, "artifact_outcome": "ACCEPTED", "cleanup_outcome": "VERIFIED", "delivery_eligible": true, "artifacts": [ { "artifact_id": "artifact-demo-001", "path": "results/report.json", "media_type": "application/json", "length_bytes": 12, "sha256": "sha256:666c1aa02e8068c6d5cc1d3295009432c16790ee10756b7d5a86c1d2235f01ac" } ], "logs": { "stdout": { "next_offset": 9, "truncated": false }, "stderr": { "next_offset": 0, "truncated": false } } } ``` The artifact represents exactly `{"ok": true}` encoded as UTF-8, without a trailing newline; the byte length is 12 and its SHA-256 is illustrative pending validation against the exact bytes. No synthetic response is evidence that code was executed or infrastructure cleaned up. Log retrieval uses a server-issued stream identifier (`stdout`, `stderr`, `console`, `vmm`), immutable byte offsets, a bounded maximum page of 64 KiB and a truncation flag. Offsets describe retained bytes, not an assurance of lossless capture. Every request rechecks job ownership. ### 4.5 Minimum authoritative records | Record | Essential fields | Only permitted writer | | -------- | --------------------------------------------------------------------------- | ---------------------------------------- | | Job | tenant ID, canonical request hash, profile, desired state, logical status | API/controller transaction | | Attempt | job ID, attempt number, epoch, workload/stop outcomes, timestamps | Controller via validated broker evidence | | Lease | owner, durable epoch, expiry, exclusive slot, fencing evidence | Broker authority | | Resource | attempt, resource type/ID, creation state, cleanup evidence | Broker journal | | Manifest | source record, safe path, length, digest, validation, immutable destination | Export validator | | Audit | version, actor, action, outcome, sequence, retention class | Append-only audit service | Results and audit objects have independently authorized retention and deletion lifecycles. Removing a logical job record does not prove VM volume erasure or remove retained audit evidence. ## 5. Lifecycle, extraction and worker fencing ### 5.1 State transitions Normal successful path. Any unproved termination or cleanup transfers to a recorded failure/quarantine branch; no such branch rejoins artifact delivery without a new independent proof. Exit code, timeout, cancellation, failed startup, resource exhaustion and supervisor loss each require a recorded cause. Their completion paths converge on physical termination verification, not directly on export. ### 5.2 Broker and controller contract ILLUSTRATIVE PSEUDOCODE · Not runnable ``` def execute_attempt(job, epoch): slot = broker.acquire_exclusive(job.id, epoch) if not slot: return block_or_quarantine("NO_EXCLUSIVE_SLOT") try: if not broker.provision_and_verify(job, epoch): return broker.abort_and_reconcile(job, epoch) if not broker.launch_if_current(job, epoch): return broker.abort_and_reconcile(job, epoch) outcome = broker.monitor_until_exit_or_deadline(job, epoch) # Output collectors are already attached. # Cancellation is durable desired state, not stop proof. if not broker.terminate_and_prove_stop(job, epoch): return broker.quarantine(job, "STOP_UNPROVED") if not broker.seal_source(job, epoch): return broker.quarantine(job, "SEAL_FAILURE") extraction = broker.run_isolated_extractor(job, epoch) if not extraction.control_and_termination_proved: return broker.quarantine(job, "EXTRACTOR_UNPROVED") if not broker.validate_and_export_immutable( job, epoch, extraction ): # Validation rejection is recorded; accepted subset # is permitted only if independently validated. broker.record_artifact_rejections(job) if not broker.verify_required_cleanup(job, epoch): return broker.quarantine(job, "CLEANUP_UNPROVED") ``` Every resource mutation, including a stop or artifact export, must be broker authorized against the current epoch. `finally` does not override an earlier quarantine or establish cleanup proof. A subsequent reconciler may only change that status after independently verified evidence. A cancellation/completion race resolves transactionally: cancellation is a durable desired state; an already proved completion may remain completed, while an unresolved concurrent execution is terminated or quarantined. Duplicate notifications update no state unless their attempt, sequence and epoch match the authoritative record. ### 5.3 Artifact trust boundary The guest is stopped first. Its source volume is frozen and logically sealed, and a resource-journal entry records the snapshot and its ownership. A disposable extractor microVM or equivalently isolated KVM domain receives only a read-only snapshot. It has no network, tenant credentials, host-root mounts or VMM APIs. Its source filesystem parser is considered exposed to hostile bytes. The custom transfer protocol emits framed file records: `path | type | exact_length | sha256 | bytes` A separate trusted validator checks normalized relative paths, duplicate/case-colliding names, allowlist membership, digest, length, file type and bounded decoded JSON where applicable. It rejects traversal, symlinks, device files, sockets, unsafe archives and unexpected metadata. Any accepted bytes are copied into immutable internal storage and verified there before their source backing is destroyed. Provisional extractor limits: | Resource | Outer-enforced cap | | ------------------------ | ---------------------------------------------------------------------------- | | CPU | 1 vCPU rate, 15 CPU-seconds cumulative | | Memory | 256 MiB extractor process budget, 512 MiB total guest, 640 MiB host envelope | | Processes / descriptors | 8 guest tasks; 32 guest FDs; 64 host FDs | | Input / expanded content | 64 MiB snapshot input; 50 MiB total expanded candidates | | File count / depth | 16 files; depth 4; no archive recursion | | Lifecycle | 20-second total, including stop proof; failure quarantines | The extractor has its own broker-owned resource entry, independent watchdog and cleanup verification. An archive-type rejection alone does not test parser containment; the latter requires a bounded hostile structured input against the actual parser boundary. ### 5.4 Fencing semantics The privileged host broker is the sole mutation authority, holding durable epochs and serialized exclusive slots. Workers and controllers possess only constrained authenticated RPC access. At every `start`, `stop`, `export`, `delete`, `renew` and `resource-create` action, the broker rechecks the attempt ID, ownership epoch, authenticated caller, lease state and local deadline. Losing ownership prevents subsequent mutations and publication. Broker restart requires journal replay and host/VMM inventory reconciliation before any new execution is authorized. If a disconnected broker or worker could still control an old VMM, increasing the database epoch is insufficient. Replacement must remain blocked until physical termination is proved or an independently enforceable external fencing mechanism is verified. Unsupported cloud fencing semantics are BLOCKED, never presumed atomic. Local monotonic deadlines remain enforceable without successful database renewal. On broker loss, an independent watchdog must be able to stop or quarantine the VM. A stopped control-plane heartbeat is not evidence that the guest has stopped. ## 6. Eight bounded acceptance groups Status of every test: NOT RUN. These are proposed synthetic fixtures for disposable staging, with no uncontrolled exhaustion or destructive host operations. The authoritative suite contains 24 named subcases, 32 resource-owning attempts and 3,960 seconds of serial row deadlines. The overall hard suite deadline is 4,500 seconds, including a 540-second setup/recovery margin. At most 120 seconds of that margin is for preparing the independent positive-control network environment. Each resource-owning attempt has an outer deadline of at most 120 seconds. ### Authoritative attempt/deadline ledger | Subcase | Attempts | Hard deadline (s) | | ------------------ | -------- | ----------------- | | T01.python.success | 1 | 120 | | T01.python.nonzero | 1 | 120 | | T01.python.wall | 1 | 120 | | T01.node.success | 1 | 120 | | T01.node.nonzero | 1 | 120 | | T01.node.wall | 1 | 120 | | T02.api | 0 | 60 | | T03.identity | 1 | 120 | | T03.fs_secret | 1 | 120 | | T03.channel | 1 | 120 | | T04.deny | 1 | 120 | | T04.exception | 1 | 120 | | T05.cpu | 2 | 240 | | T05.memory | 2 | 240 | | T05.pid_fd | 2 | 240 | | T05.storage | 2 | 240 | | T05.output | 1 | 120 | | T05.admission | 4 | 480 | | T06.export | 1 | 120 | | T06.parser | 1 | 120 | | T07.races | 2 | 240 | | T07.fencing | 2 | 240 | | T08.recovery | 2 | 240 | | T08.supply_audit | 0 | 60 | | TOTAL | 32 | 3,960 | The eight acceptance groups below specify the actual operations within those limits. Every subcase is release-blocking when it exposes an intended security-boundary failure. An inadequate or unsupported fixture is `BLOCKED` or `INCONCLUSIVE`, not `PASS`. ### T01 — Runtime behavior and outcomes Coverage: G10, G16. - `T01.python.success`: One Python attempt writes `results/report.json` and exits zero. Assert verified cleanup and gated delivery; capture the exact exported digest. - `T01.python.nonzero`: One Python attempt writes an allowed diagnostic JSON file at the same path, then exits code 7. Assert `NONZERO_EXIT`, with independently evaluated artifact and cleanup outcomes. - `T01.python.wall`: One Python attempt performs a finite, low-CPU 40-second wait. The normal workload wall limit is 30 seconds. Assert `TIMEOUT` and physical stop, without aggregate CPU exhaustion. - `T01.node.success`: One Node.js attempt writes the same allowed JSON path and exits zero. - `T01.node.nonzero`: One Node.js attempt writes its permitted diagnostic artifact and exits code 7. - `T01.node.wall`: One Node.js attempt performs a finite, low-CPU 40-second timer wait, testing the same 30-second workload deadline. Each subcase: exactly one workload attempt, at most 120 seconds including lifecycle cleanup, with no additional VM launch. Expected evidence: Broker timestamps, exit observations, wall-clock enforcement, immutable manifest, resource inventory and outcome state. Incorrect status, early artifact delivery or incomplete termination is a failure. Passing shows the finite fixtures behaved as intended, not that arbitrary code is safe or all runtime failure modes are covered. ### T02 — Cross-tenant authorization and idempotency Coverage: G01, G16. `T02.api` uses zero execution attempts and a 60-second hard deadline. Fixture: Two synthetic tenants, one owned job record and a server-authorized profile. Perform 12 bounded API requests covering submission, read, log retrieval, cancellation, listing, download, unauthorized ownership, unknown policy fields, a caller-supplied tenant field, and reuse of an idempotency key with matching and conflicting payloads. Expected: Unauthorized requests are denied; policy injection is rejected; identical idempotent submission returns the original record; a conflicting payload returns `409`. Evidence is the HTTP response set, canonical hashes and audit events. Any ownership bypass is release-blocking. Passing does not establish resistance to every application authentication vulnerability. ### T03 — Privileges, filesystem, secrets and transport Coverage: G02, G03, G04, G05, G06. - `T03.identity`: One attempt, 120 seconds. Inspect five bounded privilege checks: UID, GID, supplementary groups, effective capabilities and `no_new_privs`; make one harmless attempted setuid-style privilege escalation. Expect UID/GID `10001`, no capabilities and rejected elevation. - `T03.fs_secret`: One attempt, 120 seconds. Probe six authorized/unauthorized paths or device classes and four known synthetic secret names. Confirm authorized runtime reads succeed, while inaccessible mounts, host devices, cross-tenant data and secret variables remain unavailable. - `T03.channel`: One attempt, 120 seconds. Make eight bounded probes covering `AF_VSOCK`, inherited descriptors, `AF_INET`, `AF_INET6`, malformed frames, oversized frames, forbidden commands and guest-to-host initiation. Assert deny/reject and no privileged mutation. Evidence includes compiled security-policy identifiers, syscall-denial observations, bounded guest logs, broker traces and configuration read-back. A security bypass fails the group; missing compiled-policy verification blocks it. Passing does not guarantee containment after guest-kernel compromise. ### T04 — Network isolation and controlled exceptions Coverage: G06. - `T04.deny`: One attempt, 120 seconds; eight bounded probes target synthetic IPv4, IPv6, DNS, metadata, private, link-local, host and inbound endpoints. - `T04.exception`: One attempt, 120 seconds; test four authorized/unauthorized exception cases and verify that the production deny profile cannot be bypassed using a proxy, forwarding channel or alternative socket. A separate disposable positive-control environment is prepared before counted attempts, proving the synthetic endpoints are reachable under an authorized test network policy. It is not the reference runtime and must not provide production egress. Expected: Deny profile blocks connections, name resolution and prohibited forwarding; any exception requires ownership, expiry and data-release controls. Evidence includes positive-control readiness, enforcement logs, denied operations and absence of accepted bypasses. Missing positive-control DNS is `TEST_SETUP_FAILURE`, not proof of isolation. A successful connection denial is not proof that permitted exceptions cannot exfiltrate data; content inspection and its limitations require separate review. ### T05 — Resource accounting and admission Coverage: G07, G08, G09. Use separately reset authorized test profiles so testing one limit does not get masked by another. - `T05.cpu`: Two attempts, 240 seconds total. First tests guest aggregate cumulative CPU using two bounded child computations (at most 200 million iterations per child), with supplementary per-process `RLIMIT_CPU` raised to 45 seconds and test aggregate cutoff 10 CPU-seconds. Second tests outer host VMM aggregate accounting with a separately authorized 12 CPU-second host cutoff. Each computation has a 30-second work window and the attempt a 120-second lifecycle ceiling. Finite work that does not reach the intended cutoff is `INCONCLUSIVE`. - `T05.memory`: Two attempts, 240 seconds. Guest case attempts 16 allocations of 40 MiB each (640 MiB total) against a 512 MiB workload cap, limited to the permitted staging host. Host case uses a separately authorized 768 MiB guest configuration with a provisional 896 MiB host envelope; attempts 16 allocations of 52 MiB (832 MiB total) to exercise the outer enforcement, subject to baseline and overhead read-back. If the fixture cannot safely cross the intended host limit, mark `BLOCKED`, not `PASS`. - `T05.pid_fd`: Two attempts, 240 seconds. PID case attempts at most 20 child processes against guest `pids.max=16`, reading back the host VMM task limit of 32. FD case attempts at most 80 guest opens against `RLIMIT_NOFILE=64` and verifies host VMM `RLIMIT_NOFILE=128`. No uncontrolled process spawning. - `T05.storage`: Two attempts, 240 seconds. Byte case writes at most 72 MiB in 4 MiB chunks against a 64 MiB writable-work cap. Inode case creates at most 80 small files against an authorized 64-inode test quota. Both verify no host spillover. - `T05.output`: One attempt, 120 seconds. Emit at most 9 MiB stdout, 9 MiB stderr, 5 MiB console and 3 MiB synthetic VMM-log events, plus a 24 MiB valid artifact. Assert the individual 8/8/4/2/28 MiB slices and aggregate 50 MiB gate. Collectors must drain/discard safely, bound dropped-byte counters and never hang the guest. - `T05.admission`: Four short attempts, 480 seconds. Submit the four jobs along with 24 bounded queued admission requests, using a test profile limited to two simultaneous slots and three pending requests. Check fairness, rejection/backpressure and preserved control-plane capacity; verify the production-configured global maximum is 20 without attempting uncontrolled saturation. Evidence: cgroup `cpu.stat`/memory/PID counters, host and guest rlimit read-back, watchdog triggers, disk/inode quotas, collector counters, admission events and resource inventories. Failures include unbounded resource use, collector deadlock, missing host headroom and admission bypass. Passing does not establish production throughput, acceptable latency, cost or the capacity to sustain 20 active microVMs. ### T06 — Artifact integrity and parser containment Coverage: G04, G12, G16. - `T06.export`: One attempt, 120 seconds. Produce no more than 12 candidate records inside one job, including a valid `results/report.json`, a file changed during runtime, an unallowlisted path, traversal, symlink, special-file indication, duplicate path, colliding path and unsupported archive type. Assert stop-before-seal, exact byte verification, immutable accepted export and no rejected-file exposure. - `T06.parser`: One isolated extractor invocation, 120 seconds. Feed a bounded 1 MiB synthetic hostile structured filesystem image or manifest fixture, exercising malformed length, count/depth violation and parser termination under the extractor's independent caps. It must not launch a second hidden workload VM. Evidence: source snapshot ID, parser-domain journal, validator decisions, file digests, extractor stop proof, immutable-store receipt and cleanup proof. Any privileged host parser exposure, unsafe path acceptance, delivery before cleanup or orphaned extractor is release-blocking. Passing does not establish absence of undiscovered filesystem-parser vulnerabilities. ### T07 — Cancellation races, duplicates and fencing Coverage: G10, G11. - `T07.races`: Two attempts, 240 seconds. In the first, submit one cancellation near a finite completion boundary and two duplicate cancellation notifications. In the second, issue two duplicate dispatch notifications and one simulated supervisor failure. Assert one authoritative attempt ownership, durable cancellation intent and no unauthorized rerun. - `T07.fencing`: Two attempts, 240 seconds. First simulates one stale-epoch mutation and one failed renewal. Second simulates one broker restart and reconciles the existing execution before any proposed replacement. No additional resource-owning replacement launches occur. Evidence: monotonic epochs, broker journal, exclusive-slot records, attempts inventory, rejected stale RPCs, local deadline and independent watchdog events. Any old worker able to create resources, publish data or renew ownership after fencing is release-blocking. Passing does not prove recovery against every provider partition; unresolved old execution must remain quarantined. ### T08 — Recovery, dependency supply and audit Coverage: G11, G13, G14, G15, G16. - `T08.recovery`: Two attempts, 240 seconds. First injects one bounded partial-provisioning fault and checks journaled rollback. Second injects a worker-loss/cleanup-failure scenario and checks bounded cleanup attempts, inventory reconciliation, quarantine and non-delivery. - `T08.supply_audit`: Zero attempts, 60 seconds. Use at most eight synthetic checks: digest mismatch, missing lockfile, revoked dependency, invalid provenance, rollback reference, inaccessible audit record, expired retention and incident alert routing. Evidence: resource creation/deletion receipts, dependency-policy decisions, signed or otherwise authenticated provenance records where required, bounded audit records and incident routing events. A digest match alone does not establish dependency safety. Passing establishes only policy behavior for supplied fixtures, not complete supply-chain trust, assured physical erasure or effective incident response. All 24 subcases remain NOT RUN. Evidence must be collected against the actual built deployment; descriptive test plans do not count as security test results. ## 7. Implementation handoff and remaining gaps ### 7.1 Dependency-ordered backlog | Priority | Deliverable | Acceptance evidence | Release gate | | -------- | -------------------------------------------------- | ---------------------------------------------------------------------------- | ------------------------------ | | P0 | Verify host/KVM/provider compatibility | Actual host capability, Firecracker/jailer version and permissions read-back | BLOCKED pending evidence | | P0 | Implement privileged broker and external fencing | Durable journal, exclusive slots, stale-epoch rejection, termination proof | BLOCKED pending implementation | | P0 | Implement guest init privilege transition | UID/capability proof and compiled MAC/seccomp verification | BLOCKED pending implementation | | P0 | Implement isolation/storage adapters | Actual immutable image, mount/device policies, quotas and VMM cgroups | BLOCKED pending verification | | P0 | Implement host-initiated control adapter | Working authenticated host-side transport, bounded parser and guest denial | BLOCKED pending verification | | P1 | Implement API and authoritative state machine | Schema tests, tenant-ownership tests, idempotency and outcome consistency | NOT RUN | | P1 | Implement isolated extraction and immutable export | Reproducible digests, rejection evidence, independent extractor cleanup | NOT RUN | | P1 | Implement reconciliation and quarantine | Worker-loss, supervisor-failure and incomplete-cleanup evidence | NOT RUN | | P1 | Implement dependency preparation and revocation | Signed/pinned bundles, traceable builds, update and rollback checks | NOT RUN | | P2 | Benchmark resource budgets and 20-job capacity | Load, latency, host overhead, fairness and budget measurements | NOT RUN | | P2 | Run the complete acceptance suite | All 24 subcases and 32 counted attempts with retained evidence | NOT RUN | ### 7.2 Exact unresolved blockers BLOCKED — Platform support. Linux/KVM access, virtualization permissions, Firecracker compatibility, storage primitives and provider fencing have not been verified. BLOCKED — Compiled enforcement. Actual guest setup capabilities, mount/cgroup delegation, seccomp compatibility-syscall coverage, MAC transitions, and host jailer policies are not installed or verified. BLOCKED — Ownership guarantees. An independently enforceable method for stopping old execution after broker/worker partition remains to be demonstrated. BLOCKED — Extraction adapter. The snapshot handoff, disposable parser domain, transport format, immutable export and extractor reconciliation are specifications, not completed implementations. BLOCKED — Production envelope. The host VMM 1,280 MiB memory target, 30-second workload limit and 20-job global concurrency target require measurement. NEEDS DECISION — Capacity economics. The reference assumes one disposable microVM per attempt. Cloud placement and per-tenant quotas should be finalized only after benchmarks and tenancy-policy approval. ### 7.3 Contract-level consistency findings The architecture is coherent at the reference level, but three fixture/example details require correction before turning it into a canonical implementation specification: 1. Synthetic artifact digest: The SHA-256 for the 12 bytes `{"ok": true}` is `6bc0da1f42f96fc37b8bd7ed20ba57606d2a0da5cda2b135c7854fbdc985b8a3`. This replaces the illustrative digest in the result JSON. The artifact path and byte length remain consistent with the submitted job. 2. T05.memory: Its host case must not be interpreted as proven independent host-memory enforcement. The current 768 MiB guest configuration can trigger guest memory enforcement before the intended outer host ceiling. The fixture must be calibrated against a measured host overhead baseline and separately authorized guest/host caps, or marked `INCONCLUSIVE`. No additional counted attempt is authorized. 3. T05.output: The described emission totals exactly 50 MiB before per-stream discards. A proper aggregate-overflow assertion must arrange a bounded attempted total above 50 MiB while remaining within its declared fixture cap—for example 54 MiB using the 28 MiB artifact slice. The collector and aggregate enforcement evidence must be recorded independently. These findings prevent a claim of complete contract reconciliation. ### 7.4 Protection reconciliation Design coverage versus implemented assurance | Baseline | Reference design | Adapter verification | Runtime tests | | -------- | ---------------------------------------------- | -------------------- | ------------- | | G01–G02 | Specified | Pending | NOT RUN | | G03–G04 | Specified | Pending | NOT RUN | | G05–G06 | Specified | Pending | NOT RUN | | G07–G09 | Specified; test fixture corrections needed | Pending | NOT RUN | | G10–G11 | Specified; external fencing unresolved | Pending | NOT RUN | | G12 | Specified; extractor implementation unresolved | Pending | NOT RUN | | G13–G14 | Specified | Pending | NOT RUN | | G15–G16 | Specified | Pending | NOT RUN | Final disposition `DESIGN_STATUS: NEEDS_DECISION` `RUNTIME_SECURITY_TESTS: NOT_RUN` The proposed microVM architecture is an appropriate conditional reference for potentially hostile multi-tenant Python/Node.js execution, but it is not production-approved, security-verified or implementation-ready. The critical next milestone is a disposable staging implementation proving host isolation, broker fencing, guest privilege transitions and safe artifact extraction—not expanding the architectural document. ### Process Improvement Notes - Keep the authoritative test ledger as machine-checked structured data, generating IDs, counts and deadline summaries rather than maintaining them independently in prose. - Validate JSON examples, exact byte digests, budget arithmetic and cross-section field consistency automatically before publication. - Separate reference-design preservation, adapter implementation and runtime evidence into three distinct acceptance gates; a preserved security control is not evidence of a working security boundary.