Threat model

Status: updated 1 October 2026 for release 1 (issue #11): after the review of main at 26ce0d4 and its fixes (#78, #79), for the vendor terms of subscription logins (D40, T17), on 3 October for signed releases (D24, T19, #180), for the refused IPv6 prefixes (T5, #124, #194), and on 4 October for the trusted computing base (#248). It refines design §7, which stays the list of security rules; this page says what those rules defend against, where each is enforced and tested, and which risks are accepted. A control is measured when a spike or test showed it working, planned when an issue implements it, and open when nothing covers it yet.

Scope and assumptions

workharbor runs on one developer’s Apple-silicon Mac. It drives coding agents (Claude Code first; Codex CLI second, a target not yet built, #35) in Apple Container environments and talks to one forge, GitHub (D15). The developer reaches it from a laptop or phone over a VPN.

• One trusted human. The developer and the Mac’s macOS account are trusted. Protecting the developer from themselves is out of scope.
• The agent is not trusted. Its model output follows whatever text reaches it, including issue text written by strangers, so every agent and everything it writes is treated as potentially hostile.
• The VM boundary holds. Apple Container runs each container in its own lightweight VM (§5.1). A hypervisor escape is out of scope; what the supervisor deliberately exposes to a guest is in scope.
• Vendors are trusted for what they host. The LLM vendors and GitHub see the code they are sent. Choosing to send it is the developer’s decision, not a threat this page addresses.

Assets

Trust boundaries

phone / laptop ──VPN──▶ supervisor (host, trusted) ──▶ GitHub API, ntfy
                          │ exec, mounts
                          ▼
          ┌──── environment (guest VM, untrusted) ─────┐
          │ agent process, agent home volume,          │
          │ bind-mounted per-task checkout (writable)  │
          └───────────────┬────────────────────────────┘
                          │ --internal network only
                          ▼
              proxy sidecar (trusted, full egress) ──▶ LLM API, allowlisted hosts

1. Guest to host. Mounts, the exec channel, and files the host later reads from an agent-writable checkout.
2. Guest to network. Only through the proxy sidecar on a per-environment --internal network (§7.2).
3. Supervisor to clients. The JSON API and web UI, reachable only on loopback or the VPN (§7.5).
4. Supervisor to the forge. API calls and pushes with the App’s tokens; webhooks coming back.
5. Untrusted text into the agent. Issue and PR text, comments, CI logs and anything fetched while working.

Trusted computing base

The trusted computing base is what must be right for a boundary above to hold: trusted means that a flaw in it breaks a boundary, not that it is safe. Each component names the boundaries it guards, the control that checks them and where that control is built and tested (issue #248; drawn from main at 1835ca0, nothing newly measured).

The console has no threat ID of its own: T16 covers access into it and the accepted risks cover what runs and is shown there.

Threat sources

Threats and controls

Accepted risks

These are accepted for a single-developer, watched personal tool. Each has a limit, and each is revisited if the tool gets more users.

• A preview can still leak by navigation (D33, issue #72). The proxy’s CSP stops a preview’s script from fetching or loading images from another site, but a link, a top-level navigation or a DNS prefetch hint (which not every browser’s CSP controls) can still carry data out past the egress allowlist. Limit: only the human opens a preview, it closes with its environment, its session and its device, and the human sees where it navigates.

• A preview shares the UI’s cookies (D33, issue #72). Browsers do not isolate cookies by port, so a web app the agent runs, previewed on another port of the same host name, can set or overwrite cookies the UI also sees. Limit: the UI’s session and CSRF state are issued and kept on the server and its cookies carry the __Host- prefix, so a tossed cookie can sign the human out but cannot fix a session, forge a request or read one; only the human opens a preview, and it closes with its environment. A separate host name for previews would remove this (open).

• An image build has the builder’s own network (D38, issue #76). Building an environment from a repository’s Dockerfile runs its RUN steps in Apple Container’s builder VM, which the egress allowlist does not cover; container build 1.5.0 has DNS options but no network option (unverified: from its --help), so it cannot be put behind the sidecar. Devcontainer features add third-party install.sh scripts that run as root in the same builder (D38, #108, #127): only from ghcr.io/devcontainers/features/ or a source the human allowed per repository, each pinned by its manifest digest. Limit: only the default branch’s committed Dockerfile and context, and those pinned features, are built (never a topic or a working tree), no --ssh, --secret or credentials reach the build, its arguments pass the reserved-name check, and its only output is an image tag.

• The agents of one workspace are one trust domain (D42). They share one environment, its agent home (the login and every agent’s sessions) and the agent clone’s .git, and can change each other’s worktrees, branches, hooks and config; the isolation boundary is the workspace’s environment, not the agent. Limit: a workspace never contains the human’s own repository, the host never runs git in it, and nothing leaves it except a verified bundle whose commits are approved per SHA. Agents that must not touch each other belong in separate workspaces.

• The console’s terminal stream reaches the human’s terminal as it is (open: accepted or filtered is Werner’s decision, issue #223; D43). whr console and SSH into the console environment are interactive terminals, and today whr passes the guest’s bytes through unchanged (§7.1). The human’s terminal emulator parses them, and it is a host process with the human’s rights, so an agent-written file the human displays (cat, less, git log in the console: routine, not rare) can drive it: set the title, write the host clipboard with OSC 52, read the host clipboard with OSC 52 where the terminal allows it and so move a password or token into a guest that has egress, make the terminal answer with reports (device attributes, a status string) that arrive as typed input, or reach an emulator bug, which is code execution on the host outside every guest. Which terminals allow OSC 52 reads, and which ask first, is unverified. What limits it today: only in a session the human opens, and the console holds no credentials. The cheap mitigation is for whr console to drop OSC 52 and the other OSC, DCS, APC, PM and SOS sequences from the stream, as terminal multiplexers such as tmux can (unverified); plain SSH to the console would stay unfiltered, since the human’s own ssh client carries it.

• A development installation can be replaced by its own account (D24, D46, issue #261). make install puts whr in $HOME/.local (or a --prefix of the developer’s), and whr setup --dev and whr doctor --dev accept it and install the LaunchAgent with that binary, so anything that runs as the account, an agent’s escape from its VM or a process of the developer’s included, can replace the supervisor’s binary, which the managed prefix of D24 prevents. Limit: only by the explicit --dev flag on each call, or by the development_prefix key in the supervisor’s configuration, which whr writes only on an explicit whr setup --dev and which anything running as the account can write too, but which a managed installation refuses (D24, #276, to be built), never an environment variable or a default; setup and doctor warn that the installation lacks the replacement protection, doctor on every run while the key is set; the binary, the prefix and every directory above it must belong to the running account or root and be closed to group and other writers, the prefix is neither / nor the home directory nor a directory above it (6665a62, e664c8a: the home from $HOME and from the directory service; dscl by its absolute path and a comparison by identity rather than spelling, #278, to be built), and a binary in a git working tree or run as root is refused as in managed mode; no agent authority changes. These checks guard against a mistake, not against the account, which sets its own $HOME and PATH. It is for a developer’s machine: the dogfood host and the reference host keep the managed release installation (D24, D34).

• The console runs agent-written repository config (D43) when the human runs git or tools there. Limit: it is a VM with no host home, secrets, credentials or runtime socket; workspaces are read-only by default; hooks and fsmonitor are off. Spike #89 measured that hooks and fsmonitor stop through GIT_CONFIG_COUNT, while filter drivers, textconv and aliases set in a workspace’s config run unless overridden by name; the console’s git wrapper overrides each one it finds, and a setting it misses runs inside the console VM only.

• Data can leave through an allowed host. The sidecar matches on the hostname in CONNECT, so api.anthropic.com can carry data out, and domain fronting is not stopped. Limit: the allowlist is minimal, every request is logged, and the logs are reviewable.

• The sidecar is trusted and has full egress. Limit: it runs only whr-proxy, mounted read-only into the configured or built-in base image (never a repository’s devcontainer image), with no access to secrets.

• A subscription login sits inside the environment. Any process in the guest can read it while a run is active. Limit: the human signs in there through the vendor’s own flow and whr never sees the credential (D40), one dedicated auth directory per environment, never the host’s, and revocation at the vendor when the environment is deleted. That vendor revocation works as expected is unverified.

• Host git reads agent work only as a bundle. Since D42 the host runs no git in a workspace: an agent’s commits arrive as a bundle and are fetched into the supervisor’s repository with object checks (§4.5). What remains is git’s own handling of a crafted bundle and of the commits and trees in it, limited by fsckObjects, git’s path protections, a size cap and a scratch repository that holds nothing else.

• The agent sees what it is given. Repository contents go to the LLM vendor. That is the developer’s choice per repository.

Open items

• Guests reach the host’s LAN address and every service on all interfaces (#69): the pf rule blocking container subnets and the hardening of macOS’s own services are not yet measured. T1 is partly implemented: issues from untrusted authors are held for a Decision before any run (#53); T15’s front ends come with #24 and #30. T7’s transport is verified by spike #7, including the crash and deadline cases.
• Links inside a secrets directory are followed one level and the locations found in review are rejected (#58). Mounts can also be limited to the workspace roots workharbor owns, as a second layer behind the deny-list (CheckMountsWithin). Accepted: a hard link to a secret inside a project, and links more than one level deep inside a secrets directory.
• Webhook signature verification and the author association used for trust tiers are part of the forge adapter, #27.
• Whether an image build can be confined to an allowlist, for example through a proxy reachable from the builder VM or a later container build network option (open).
• This page is reviewed whenever a D-row changes a boundary, and before release 1.