Wallfacer: the reference architecture as a managed product, with no published scale

Wallfacer sponsors this guide, and is graded on the same rubric as the other seven case studies.

Wallfacer is a managed implementation of the reference architecture: per-task VMs, an external session record, and customer-authored workflows with enforced human gates. It sits in the least publicly proven category in this landscape, the managed substrate (model E in the five operating models). The design maps onto six of the seven compliance properties by construction. Stripe and Intercom publish throughput and revert rates; Wallfacer has published no customer-scale numbers.

Every session boots two VMs, so credentials and model output never share a machine

Each session provisions a paired set: a harness VM running the vendor agent CLI (Claude and Codex adapters today) and a sandbox VM holding the customer's code. This is Anthropic's brain/hands split enforced as two machines rather than two processes. The sandbox image does not even carry the agent CLI. The full turn-by-turn event stream is persisted outside both VMs, so the resume mechanism and the audit record are the same artifact, the pattern the session chapter argues for.

VMs are Firecracker on Linux and Tart on macOS, restored from versioned snapshots in roughly 2 seconds versus roughly 30 for a fresh build. One isolated VM pair per session, reproducible from a known-good image, is the unit of work. The harness side is more disposable still: a fresh harness VM boots for every turn and is destroyed when the turn's terminal event lands, so the machine the agent CLI runs on never outlives a single exchange.

Gates are workflow steps, not conventions

The Task Machine is the orchestration layer. An account authors a handbook: a collection of playbooks, each an ordered list of steps, every step an ai step, a human gate, or a wait check, plus triggers that spawn tasks from inbound events. The canonical shape is implement, AI review, human approval, merge. A review step that returns approved: false fails, and its failure route loops the task back to the implementer, bounded by a retry limit that defaults to five. Segregation of duties is control flow here, not policy text: the author step and the approver step are different actors by construction, and a task parks at a human gate until a real person resolves it.

Two details matter for auditability. Triggers are compiled at edit time from a plain-English sentence into a deterministic event filter or a cron schedule, so no LLM runs in the routing path. And scheduled runs fire by emitting a system event through the same routing path as external events, so a cron-spawned task is a recorded, queryable event rather than a side channel.

Takeover is a first-class API: a human posts a direction to a blocked or gated task, which records the intervention and feeds standing instructions into subsequent AI attempts. Tasks awaiting humans surface in an Inbox decision queue. Measured against the four-transfer standard, branch, environment, conversation, and process state all live server-side and transfer together.

Three audit streams, split-trust secrets, and a scrub gate before every snapshot

The audit plane is three streams: an execution stream (the account event log itself, every engine transition), a policy stream (playbook publish, archive, enable, disable), and an access stream (who viewed the audit timelines). Actor provenance, human, AI, integration, or system, is snapshotted at the moment of the act.

Secrets use split-trust envelope encryption: ciphertext lives in one system, the unwrap key in another (KMS-held), so neither alone can read a secret at rest. Plaintext is substituted into the environment manifest at provision time and stripped before delivery; every wrap and every provision-time decrypt is itself audited.

Before any environment snapshot is captured, a prepare-snapshot step strips per-identity credentials: the git token, the GitHub CLI login, the SSH key, the committer name and email. The scrub is a hard gate: if it fails, the snapshot is aborted rather than freezing one user's credentials into an image others will boot.

The gaps, on the same rubric

Property 7 is unmet. Wallfacer ships no dependency-install gating: nothing verifies a package an agent names against a trusted source before install, no deny-by-default registry, no release-age cooldown. The failure mode is proven, package hallucination ran at 19.7% in the USENIX study behind slopsquatting, and Nx s1ngularity turned an AI CLI's own supply chain into the weapon. No vendor in this handbook ships the control; the sponsor doesn't either. See dependency provenance for the prescription.

Per-agent AI identity. The bar is per-initiating-human. An account onboards named AI agents through role templates (software engineer, code reviewer, or a blank agent), each with its own environment, git identity, vendor and model, and an enabled flag. Every action and audit row carries the specific agent that performed it, resolved per step attempt: a step pinned to a reviewer wins over the agent the triggering event routed the task to (an assignee handle mapped to an agent), which wins over the account default. Tasks also record a responsible human (the owner, falling back to the creator), so the trace to a person exists at the task layer. But no agent identity is scoped to the human who initiated the work, and no shipping platform meets that bar yet.

Scale is unproven in public. The architecture maps cleanly onto six of the seven compliance properties. Whether it holds at Stripe-class volume is a claim the field cannot yet check: the numbers have not been published. The sponsor has not published them either.