machine-bridge-mcp 2.0.0 → 3.0.0-beta.102

package/docs/THREAT_MODEL.md

@@ -1,142 +1,239 @@
 # Threat model
 
-This document defines the security claims Machine Bridge is designed to make and the claims it explicitly does not make. It complements [SECURITY.md](../SECURITY.md) and the implementation detail in [ARCHITECTURE.md](ARCHITECTURE.md).
+This document defines the security claims Machine Bridge is designed to make and the claims it explicitly does not make. It complements [SECURITY.md](../SECURITY.md), [LOCAL_AUTHORIZATION.md](LOCAL_AUTHORIZATION.md), and [ARCHITECTURE.md](ARCHITECTURE.md).
 
 ## Scope
 
-Machine Bridge combines a remote OAuth relay, a high-authority local runtime, optional local stdio transport, persistent managed jobs, and a browser extension. The primary security objective is to ensure that only explicitly authorized, policy-permitted operations cross those boundaries, with bounded inputs, fail-closed state transitions, and minimal sensitive observability.
+Machine Bridge combines:
 
-The local runtime executes as the current OS user. Policy profiles restrict Machine Bridge behavior; they do not replace kernel, account, VM, container, browser-profile, or endpoint-security isolation.
+- a public OAuth and MCP endpoint on a Cloudflare Worker;
+- an authenticated relay to a high-authority local daemon;
+- optional local stdio transport;
+- filesystem, Git, process, browser, and application automation;
+- persistent managed jobs and registered local resources;
+- a browser extension operating in an existing user profile.
+
+The local runtime executes as the current OS user. Application policies restrict Machine Bridge behavior, but they do not replace kernel, account, VM, container, browser-profile, or endpoint-security isolation.
 
 ## Assets
 
-The main protected assets are:
+Protected assets include:
 
-- workspace and local-user-accessible files;
-- process execution authority and inherited environment values;
-- daemon device private key, account-administration HMAC key, account password verifiers, OAuth authorization codes, access tokens, refresh tokens, and local capability leases;
-- Worker and Durable Object routing state;
-- owner-only profile, lock, resource, service, and managed-job state;
-- registered local resource contents and paths;
-- browser pairing token, browser cookies, authenticated sessions, tabs, page content, and file-upload authority;
-- release candidate hashes, observed-verification acceptance records, package contents, and source-release integrity;
-- logs and diagnostics that could reveal paths, credentials, arguments, results, or user content.
+- workspace files and other files reachable by the local OS user;
+- process execution authority, process sessions, retained output, and inherited environment values;
+- the device root, root-certified ephemeral session keys, OAuth account password verifiers, authorization codes, access tokens, refresh-token families, DPoP bindings, and trusted-client records;
+- Machine Bridge state, locks, service metadata, native broker files, audit-chain state, registered-resource metadata, and managed-job plans/output;
+- browser pairing state, cookies, authenticated sessions, tabs, page content, form values, screenshots, and upload authority;
+- Worker and Durable Object routing, nonce, account, client, token, and pending-call state;
+- release candidate hashes, package contents, acceptance records, and source-release integrity;
+- logs and diagnostics that could reveal paths, credentials, arguments, output, or user content.
 
 ## Trust boundaries
 
 ### Hosted client to Worker
 
-The hosted client and its prompts, tools, extensions, and retrieved content are not automatically trusted. The Worker must validate OAuth state, PKCE, redirect and resource binding, account role/version, token expiry/rotation, MCP session state, request shape, body bounds, and allowed tool exposure.
+The hosted MCP client, its prompts, tools, extensions, and retrieved content are not automatically trusted. The Worker validates:
+
+- OAuth state, PKCE, redirect URI, resource binding, and request size;
+- account status, account version, account role, trusted client binding, token expiry, and refresh-family state;
+- DPoP proof method, target URL, timestamp, unique identifier, access-token hash, and key thumbprint when DPoP is used;
+- Native MCP `2026-07-28` per-request protocol metadata, valid positive `Accept` quality values, actual `/mcp` Origin, header/body consistency for version/method/name/declared primitive parameters, request IDs, role-visible tool exposure, raw argument schemas, and response-stream cancellation. Remote HTTP initialization compatibility is limited to the declared `2025-06-18`/`2025-11-25` dates and the bounded `initialize`/`notifications/initialized`/`ping`/`tools/list`/`tools/call` method set; it dispatches tools only through the current controller and cannot create `Mcp-Session-Id`, recovery/replay state, or a second authorization/session model. Other removed initialization/session requests receive bounded upgrade guidance only.
+- The daemon HTTPS fallback is a transport failover surface, not an MCP endpoint or alternate authority. Each POST is authenticated by the same root-certified ephemeral P-256 device session as the daemon, and its signature binds the fixed route, Worker origin, server/version, a 30-second nonce/timestamp window, and exact body SHA-256. Nonces are one-time and bounded; request/response bodies, queue count/bytes, request frequency, and liveness are bounded independently. The Worker admits the fallback only when no verified-ready WSS exists, preserves the same daemon-instance/pending-call ownership, and does not expose the fallback as ready until the daemon has acknowledged all probing controls and returned the sequenced `https_ready` proof. Bidirectional contiguous transport sequences reject gaps and suppress duplicate delivery before business side effects, so an HTTP response retry does not become a mutation retry.
+
+A client registration is not authority. Authority begins only after successful account authorization binds the client to one account and role version.
+
+Capability discovery is also an authorization boundary. Task routing and application/browser metadata are built from the effective account/daemon policy intersection, not from the daemon ceiling. Route scores and fallbacks are advisory and cannot manufacture authority; direct Bash remains available only when the effective policy already exposes it. A restricted account must not learn hidden local application inventory or receive names of unavailable execution tools through the resolver.
+
+Mirrored MCP headers are an intermediary-routing boundary. The Worker compares every required native current header with the JSON-RPC body before authorization-dependent dispatch; a mismatch fails with `-32020` before the daemon can observe the call. Stateless initialization-compatibility clients may omit the newer method/name/declared-parameter mirrors, but any such current mirror they do send is binding and must match the same JSON-RPC body before compatibility dispatch. The reserved mirror namespace is closed as well: an inapplicable `Mcp-Name` or a `Mcp-Param-*` header that is not declared by the selected tool schema is rejected rather than ignored. Tool schemas are compiled from a bounded JSON Schema 2020-12 subset at startup and runtime traversal charges every array item and own object property to a fixed work budget. Open request metadata/capability JSON also has a fixed structural-node/depth/key budget. This server advertises no change notifications, so `subscriptions/listen` validates and bounds the requested filter, acknowledges an empty supported notification subset, emits the correlated completion result, and closes immediately without retaining subscription state. Unsupported dialects or keywords fail closed, external network `$ref` values are not dereferenced, and validation diagnostics omit argument values and unbounded caller identifiers.
+
+Current response-stream cancellation deliberately crosses the OAuth boundary only through an unguessable internal stream capability. The public Worker strips caller-provided control headers before the service binding, the cancellation request contains no bearer token or DPoP proof, and the Durable Object consumes the capability before OAuth only to cancel a currently indexed call. Guessing remains bounded by 256-bit randomness; a compromised service binding or Worker runtime is already inside this trust boundary.
 
 ### Worker to local daemon
 
-The Worker is a relay and authorization layer, not a source of local authority. The daemon accepts only a version-compatible relay that proves possession of the enrolled P-256 device key in both a signed upgrade preflight and a Worker challenge. End-to-end readiness requires a local probe result through the active session. Every remote tool call carries bounded account and OAuth-client identity that is rechecked locally, followed by effect-level local transaction authorization.
+The Worker is a relay and authorization layer, not the source of local OS authority.
+
+The daemon connection requires:
+
+1. a root-signed ephemeral device-session certificate;
+2. a signed, nonce-bound WebSocket preflight using that session key;
+3. a fresh Worker challenge bound to the daemon instance;
+4. version compatibility;
+5. an end-to-end readiness probe delivered through the same result path as real calls.
+
+A replacement candidate does not displace a healthy daemon until those checks complete.
+
+Each remote tool call carries account ID, account version, OAuth client ID, refresh-family ID, and role. The local runtime recomputes effective authority and applies object ownership and operation classification before dispatch.
 
 ### MCP host to local stdio process
 
-A local MCP host can invoke every tool allowed by the selected daemon policy. The host, model output, repository instructions, and retrieved content may be malicious or prompt-injected. A permissive policy therefore grants meaningful local-user authority.
+Stdio is a local-owner transport. It does not use remote OAuth accounts or the relay device root. The local MCP host can invoke every tool allowed by the selected local policy.
+
+The host, model output, repository instructions, and retrieved content may be malicious or prompt-injected. A permissive local policy therefore grants meaningful local-user authority.
 
 ### Local runtime to operating system
 
-The runtime relies on the OS account, filesystem permissions, macOS TCC/SIP, Windows ACLs, container/VM boundaries, and endpoint controls. Canonical workspace checks prevent path escape only when unrestricted paths are disabled. They do not protect against a malicious process already running with the same OS-user authority.
+The runtime relies on OS-user identity, filesystem permissions, process controls, macOS TCC/SIP, Windows ACLs, endpoint controls, and any VM/container boundary.
+
+For delegated process execution, Machine Bridge requires a behaviorally verified OS sandbox. If the negative boundary cannot be demonstrated, delegated execution fails closed. Owner execution is not sandboxed by Machine Bridge. Fixed implementation-owned Git operations are not caller-selected process authority: they use code-constructed argv, no shell, literal pathspecs, an isolated minimal environment, bounded deadlines/output, and ordinary cancellation/process tracking. Fixed UI launch/JXA/native-input helpers likewise use code-constructed argv rather than caller-selected script source. For those mutation-capable helpers a failure before process start remains definite; once process start is established, timeout, cancellation, process error, or lost settlement is non-retryable unknown evidence because the UI mutation may already have happened. Before a restricted principal reaches Git, filesystem-first discovery checks metadata roots and recursive alternate stores and rejects symbolic-link/special-file descendants in the metadata trees; repository configuration that can execute helpers, redirect external files, or enable lazy object fetching is rejected. This protects the authenticated principal boundary but is not a hostile same-UID filesystem transaction: another local process with the owner's OS authority can still race metadata after inspection.
 
 ### Local runtime to browser extension
 
-The broker is loopback-only and pairing-token protected. The extension origin, protocol version, build version, capabilities, and handshake state are validated. The extension still runs inside a real browser profile and can reach the tabs, sessions, and origins granted by browser permissions.
+The broker is loopback-only, but loopback is not treated as a per-user authentication boundary. Long-lived extension/runtime tokens stay in owner-only state and serve only as HMAC keys: already-paired clients first prove possession of the role key with an init HMAC before the broker allocates challenge state, then verify a broker proof before WebSocket upgrade and present a five-second one-time role-bound proof. The fixed public pairing URL and HTTP document carry no credential. An explicit pair action first binds a one-shot OS-random loopback listener owned by the current process, then places a 30-second bootstrap only in that temporary URL fragment; the `document_start` content script strips it before page scripts, and the broker must prove knowledge derived from the owner-only extension token before the extension accepts that token. Successful bootstrap exchanges are consumed once. Extension origin, protocol/build version, capabilities, owner/client route, and handshake state are also validated. A same-OS-user malicious process remains outside the repository-only isolation guarantee, and process/URL UI visibility still relies on the operating system and browser boundary.
+
+The extension still operates inside a real browser profile. It can reach tabs, authenticated sessions, and origins granted by browser permissions. Only the `owner` role may use browser-session control or export local data into it. Computer Use does not increase that role ceiling: its browser observations bind semantic refs, document/frame epochs, optional screenshot evidence, and private backend-node identity to one bounded snapshot, then consume that snapshot as one-shot mutation authority. Transport loss after a browser mutation is attempted is explicitly unknown and never safe replay evidence. Screenshot-bound point actions additionally require exact current screenshot/viewport/document evidence; callers cannot submit raw CDP methods, backend-node IDs, or coordinates that are not bound to the referenced snapshot.
 
 ### Local runtime to persistent state
 
-State paths, locks, plans, resources, and service definitions are security-sensitive. Reads are bounded and symlink-aware; writes use owner-only modes where supported and atomic replacement; locks bind tokens to process identity and start time; destructive removal validates ownership and expected layout.
+State paths, roots, locks, plans, resources, native broker files, and service definitions are security-sensitive.
+
+Machine Bridge uses bounded reads, canonical path resolution, owner-only modes where supported, atomic replacement, process-identity locks, schema validation, and explicit lifecycle transitions. Security/destructive inventory treats only `ENOENT` as absence, refuses symbolic-link profile/job roots before traversal, and treats malformed/wrong-type entries inside reserved `profiles/`, public `job_...`, or retired cleanup namespaces as blockers rather than disposable unknown files. Whole-directory managed-job and state-root deletion is generation-bound: the exact inspected directory is moved to a reserved quarantine namespace, the moved filesystem identity and domain safety evidence are revalidated, and only that generation may be recursively deleted; crash residue is reclaimed only when the encoded generation still matches. Generic path-based tools cannot target Machine Bridge control-plane roots, even under `owner/full`. An authorized owner shell remains equivalent to same-user code execution and is outside that path boundary.
+
+### Device root to ephemeral session
+
+The default root is portable owner-only P-256 material, including on macOS, and is therefore readable by a determined same-user process. A non-exportable Secure Enclave root is available only through an explicitly configured app-like broker with provisioning-profile-validated Keychain access, a strict Apple code signature, stable Team ID, canonical non-symlink path with no group/other write access, and a successful real key probe. Either root signs one bounded ephemeral session certificate at daemon startup. WebSocket reconnect and account-administration requests use the in-memory session key, not the root.
+
+The portable provider stores an exportable private JWK in owner-only state and therefore provides weaker theft resistance. `server_info` reports the provider and exportability.
+
+Broker binding detects path, identifier, Team ID, signature, and capability drift. It does not protect against a malicious replacement signed by the same trusted Apple team and identifier. Production broker installations should therefore be root-owned or otherwise non-writable by the daemon user, with signing-key protection and update governance treated as external trust dependencies.
 
 ### Maintainer to release infrastructure
 
-Repository checks reduce accidental or malicious package drift, but source hosting, npm ownership, protected environments, maintainer accounts, and human review remain external trust dependencies. Repository automation cannot manufacture independent review or claim live candidate success without observing the explicitly owner-authorized candidate. It may record acceptance after that observed verification.
+Repository checks reduce package drift and accidental release mistakes. Source hosting, npm ownership, Apple signing identities, protected environments, maintainer accounts, and independent review remain external trust dependencies.
+
+The local signature binds the self-hosted broker bytes used by this installation. Public third-party binary distribution would be a separate trust model and is outside the current package workflow.
 
 ## Attacker models
 
-Machine Bridge considers the following attackers and failure sources:
+Machine Bridge considers:
 
-1. **Malicious or compromised hosted MCP client** attempting unauthorized tools, token replay, OAuth redirect abuse, request smuggling, duplicate IDs, cancellation races, or excessive resource use.
-2. **Malicious local MCP host or model output** attempting to use allowed tools for destructive actions, credential discovery, shell injection, or persistence.
-3. **Malicious repository content** including instructions, package scripts, Git configuration, paths, symlinks, generated metadata, or files designed to influence an agent or execution boundary.
-4. **Malicious webpage or browser content** attempting prompt injection, deceptive selectors, sensitive-field disclosure, unsafe navigation, replay after ambiguous input dispatch, or extension-protocol abuse.
-5. **Local same-user process** attempting to race locks, replace files, impersonate stale processes, read local state, or interfere with loopback services.
-6. **Network attacker or misconfigured proxy** attempting interception, redirect manipulation, credential disclosure, stale deployment evidence, or ambiguous timeout outcomes.
-7. **Compromised dependency or build input** attempting package substitution, mutable workflow execution, install-script abuse, release drift, or sensitive artifact inclusion.
-8. **Operational failure** such as abrupt termination, PID reuse, clock rollback, partial writes, disk/permission errors, service-manager races, stale browser builds, or daemon replacement during active calls.
+1. **A malicious or compromised hosted MCP client** attempting unauthorized tools, account switching, token theft/replay, OAuth redirect abuse, request duplication, cancellation races, or resource exhaustion.
+2. **A malicious local MCP host or model output** attempting destructive operations, credential access, shell injection, persistence, or data export through an allowed local-owner policy.
+3. **Malicious repository content** including instructions, package scripts, Git hooks/configuration, symlinks, generated metadata, or files designed to influence an agent or execution boundary.
+4. **Malicious web or browser content** attempting prompt injection, deceptive selectors, sensitive-field disclosure, unsafe navigation, ambiguous input dispatch, or extension-protocol abuse.
+5. **A local same-user process** attempting to read state, race locks, replace files, inspect memory, impersonate stale processes, or interfere with loopback services.
+6. **A network attacker or misconfigured proxy** attempting interception, redirect manipulation, stale deployment evidence, connection truncation, replay, or ambiguous timeout outcomes.
+7. **A compromised dependency or build input** attempting package substitution, install-script abuse, workflow mutation, release drift, or sensitive artifact inclusion.
+8. **Operational faults** including abrupt termination, PID reuse, clock anomalies, partial writes, permission errors, Keychain failures, service-manager races, stale extension builds, and daemon replacement during active calls.
 
 ## Security objectives
 
 The implementation aims to preserve these invariants:
 
-- deny unknown, malformed, stale, duplicated, unauthorized, or over-limit requests;
-- intersect remote account authority with the daemon capability ceiling in both Worker and local runtime;
-- permit authenticated owner automation directly within the daemon ceiling while binding delegated high-impact effects to local account/client-scoped, time-bounded capability leases;
-- keep transport authentication, account/tool authorization, transaction authorization, and OS authority separate;
-- use direct argv execution without shell interpretation unless the explicit shell tool is authorized;
-- canonicalize confined paths and reject symlink-based write escape;
-- bound request bodies, messages, files, output, logs, state, retained results, and concurrency;
-- ensure cancellation, timeout, disconnect, replacement, and shutdown have explicit process ownership and cleanup semantics;
-- prevent a candidate daemon or extension from displacing a healthy incumbent before compatibility/readiness validation;
-- avoid exposing secrets, arguments, results, resource contents, account credentials, or raw local paths in default logs and public metadata;
-- make multi-stage state and file mutations atomic or recoverable without silent partial success;
-- bind managed-job plans and release acceptance to cryptographic content hashes;
-- fail closed when state, ownership, permissions, process identity, or destructive cleanup cannot be verified;
-- keep supply-chain actions pinned, minimally permissioned, reviewed, and separately gated.
+- unknown, malformed, stale, replayed, duplicated, unauthorized, and over-limit input is rejected;
+- an intermediary cannot authorize or route one current method/name while the Worker executes another body; mirrored-header mismatch is rejected before dispatch;
+- JSON-RPC request IDs are not global identities across clients sharing one bearer token; response-stream cancellation instead uses a request-scoped unguessable internal capability that is never accepted from the public caller;
+- the stable account-role discovery catalog is not treated as execution authority; every call is intersected with the current end-to-end-ready daemon policy and fails closed when that authority is absent;
+- remote authority is the intersection of daemon policy and account role, never the union;
+- no approval record, token refresh, or local migration state can elevate a delegated role;
+- OAuth clients are bound to one account/version/role and can be revoked independently;
+- long-lived runtime objects are bound to account, account version, OAuth client, and refresh family;
+- generic path-based remote tools cannot target Machine Bridge control-plane state;
+- sensitive paths, persistence targets, browser/desktop control, data export, and persistent job creation are owner-only;
+- delegated process execution is accepted only when an OS sandbox is behaviorally verified;
+- direct argv execution is used unless the explicit shell tool is authorized;
+- confined paths are canonicalized and symbolic-link write escape is rejected;
+- request bodies, files, messages, output, logs, state, retained results, concurrency, and error-cause traversal are bounded; byte limits stop further source consumption rather than merely truncating retained data;
+- cancellation, timeout, disconnect, replacement, revocation, and shutdown have explicit process ownership and cleanup semantics; an asynchronous child `error` does not by itself release tracker/resource ownership before close/exit settlement, post-spawn start failures retain internal ownership until close, and a failed direct termination request cannot be reported as a successful forced kill or completed authority revocation; streamed calls persist ownership and deadlines across Durable Object hibernation, and per-WebSocket generations reject delayed results or close events from an obsolete connection;
+- candidate daemons and browser extensions cannot replace healthy incumbents before compatibility and readiness verification;
+- default logs, audit records, discovery warnings, browser responses, and administration errors omit secrets, arguments, contents, raw paths, form values, raw local exception text, and output;
+- multi-stage mutations are atomic or recoverable and do not silently claim partial success;
+- device-root rotation is two-phase and does not promote an undeployed key;
+- supply-chain actions are pinned, minimally permissioned, reviewed, and separately gated.
 
 ## Non-goals
 
-Machine Bridge does **not** claim to provide:
+Machine Bridge does not claim to provide:
 
-- kernel-enforced sandboxing, CPU/memory quotas, syscall filtering, or network isolation;
-- hard multi-tenant isolation between mutually untrusted users sharing one daemon and OS account;
+- kernel-enforced sandboxing for `owner`, universal syscall filtering, or universal network isolation;
+- OS CPU, memory, disk, or bandwidth quotas;
+- hard multi-tenant isolation between mutually untrusted humans sharing one daemon and OS account;
 - protection from root, an administrator, or a fully compromised same-user account;
-- complete prevention of prompt injection or malicious instructions when an authorized tool can perform the requested action;
+- complete prevention of prompt injection when an authorized tool can perform the requested action;
 - semantic detection of every secret, transformed credential, private document, or dangerous command;
-- proof that the browser extension is loaded in a safe or isolated profile;
-- rollback of a browser or external-system action after an ambiguous dispatch failure;
+- proof that the browser extension is loaded in an isolated profile;
+- rollback of a browser or external-system action after ambiguous dispatch;
+- an atomic rollback transaction spanning Cloudflare Worker deployment and every local service manager;
+- repair or node selection inside a third-party system VPN/TUN;
 - guaranteed cleanup after power loss, kernel failure, filesystem corruption, or an uncooperative external platform;
-- independent human code review while the project has only one active maintainer;
-- npm trusted publishing until the package owner configures external OIDC trust and a protected publication environment.
+- hardware-backed key storage on every operating system;
+- third-party public binary-store identity or independent distributor attestations;
+- independent human review while the project has only one active maintainer.
 
 ## Residual risks
 
-### Canonical `full` profile
+### Owner and canonical `full`
+
+`full` intentionally preserves the complete catalog, unrestricted local-user paths, shell execution, parent environment, browser/application authority, managed jobs, and absolute path output.
+
+A compromised active owner client can exercise the daemon ceiling without a second per-operation prompt. The design reduces prompt fatigue and avoids insecure copy-and-retry approval ceremonies, but it makes client trust, token protection, DPoP support, account revocation, and endpoint isolation critical.
 
-`full` intentionally preserves the complete catalog, unrestricted local-user paths, shell execution, parent environment, browser/application authority, and absolute path output. Version 2.0 treats the authenticated owner role as authorization to use that ceiling without a second terminal prompt. This prioritizes uninterrupted owner automation: compromise of an active owner OAuth client can exercise the complete daemon ceiling. Delegated accounts remain lease-bound for higher-impact effects. A malicious delegated client holding both valid OAuth credentials and an active matching lease can still act destructively within that lease. A temporary `full` lease is therefore an explicit automation window, not a sandbox or an endorsement of untrusted instructions. Use a narrower profile or a separate low-privilege OS boundary for mutually untrusted workloads.
+Use a narrower profile, separate OS account, container, or VM when prompts, repositories, clients, or workloads are mutually untrusted.
 
-### Application and browser automation
+### Public Worker endpoint and quota guards
 
-UI state can change between inspection and action. Pages can present deceptive content, and an authenticated browser profile may contain high-value sessions. Trusted input and replay controls reduce specific failure modes but do not make arbitrary web content trustworthy.
+The default public endpoint remains the automatically provisioned `workers.dev` origin so ordinary users need no DNS zone or custom domain. The in-Worker Rate Limiting bindings are deliberately Durable Object burst guards, not authentication boundaries or exact global quota accountants. They run after a Worker invocation begins and are scoped by Cloudflare location. A high-capacity route/Worker bucket bounds aggregate stateful pressure, while a lower route/subject bucket isolates a presented credential or an anonymous network identity through an internal truncated SHA-256 key. Raw credentials and addresses are not logged or returned by diagnostics; the network-address hash is a bucketing mechanism, not cryptographic anonymization of low-entropy IP space. Random invalid credentials cannot bypass the aggregate bucket. Distributed traffic can still consume the account-wide Workers request allowance, and a sufficiently concentrated source can exhaust its own local subject bucket. Binding failure is fail-open to avoid turning a quota helper into an account outage. Operators who already control an external edge may add pre-Worker filtering independently, but the public package does not require or assume a private domain.
 
-### Package scripts and registered commands
+### Bearer clients
 
-Automatic command discovery does not inject script bodies into prompts, but invoking a package script still executes repository-controlled code. The active policy and human approval remain decisive.
+DPoP is optional for interoperability. A Bearer token can be used by whoever possesses it until expiry or revocation. Short access-token lifetime, rotating refresh families, client binding, account versioning, a bounded identity-equivalent concurrency window, and post-window replay-family revocation reduce but do not eliminate token theft risk.
 
 ### Same-user interference
 
-Owner-only permissions and process-identity locks reduce accidental and cross-account interference. They cannot reliably defend against a determined process running as the same OS user with equivalent filesystem and process rights.
+Owner-only permissions, optional provisioned Secure Enclave roots, control-plane path denial, process-identity locks, and audit chains reduce several attacks. They cannot prevent a determined same-user process from reading portable credentials, inspecting process memory, changing source before execution, or interfering with local services.
+
+### Delegated sandbox availability
+
+Delegated execution is unavailable when the platform sandbox cannot pass the negative-boundary probe. This is an intentional availability trade-off. Replacing fail-closed behavior with an unverified path blacklist would create false isolation.
+
+### Browser and application automation
+
+UI state can change between inspection and action. Pages can present deceptive content, and authenticated profiles may contain high-value sessions. Protocol checks and trusted-input handling do not make arbitrary web content trustworthy. Computer Use narrows stale-target risk through one-shot snapshot authority, browser document/frame/semantic identity, and macOS PID-generation/owner-window revalidation, but it cannot make a multi-command visual/semantic observation atomic when the underlying OS/browser does not provide such a primitive.
+
+Screenshots are user data and may contain credentials, personal information, private documents, or transient notifications even when semantic value fields are redacted. They are returned only as requested tool results and are not operational log data. Computer Use shares the ordinary 7 MiB tool-result boundary; an image that would overflow the result is omitted before publishing the observation snapshot, and the resulting snapshot loses pixel-action authority. This avoids an inaccessible snapshot ID while not pretending that an omitted image was never captured in local memory during the bounded operation.
+
+The macOS experimental background visual backend uses fixed native code and exact process/window/screenshot bindings, but it depends on Accessibility/Automation/Screen Recording permissions and private WindowServer/SkyLight behavior that Apple does not guarantee as a stable public API. It is disabled unless explicitly configured and successfully probed. Probe failure must degrade to supported semantic/screenshot evidence rather than enabling pixel input. Same-UID local interference, OS compositor races, or a UI that changes after the last preflight remain residual risks; unknown outcomes require observation before any new mutation.
+
+### Managed jobs
+
+Synchronous identity and sandbox probes use `SIGKILL` when their declared deadline expires; a soft timeout signal is not treated as a bound because the caller can otherwise remain blocked. POSIX forced process-tree escalation requires a non-empty captured ownership set and exact PID/start-time continuity. If process inspection is unavailable or ambiguous, Machine Bridge may leave a resistant descendant for operator cleanup rather than risk signaling a reused process group.
+
+Managed jobs outlive MCP calls and daemon reconnects. Plans and resources are validated and ownership-bound, but an authorized owner plan can still consume resources or perform destructive work. Finally steps must be idempotent because recovery may retry them. Process-tree escalation revalidates captured PID, start-time, and process-group identity so PID reuse cannot redirect `SIGKILL` to an unrelated process. Full and targeted process snapshots share one monotonic budget per ownership decision, preventing descendant count or a stalled process-table query from expanding shutdown latency without bound. Darwin additionally queries only the target PGID, reducing the chance that unrelated process-table load erases all ownership evidence and forces fail-closed descendant retention. A missing ChildProcess `close` event after observed `exit` receives a bounded output-drain fallback and cannot leave a managed-job runner permanently unresolved.
 
 ### Availability and resource exhaustion
 
-Concurrency, message, output, and timeout limits bound many application-level resources. The daemon does not enforce OS CPU, memory, disk, or network quotas, so an authorized process can still consume host resources.
+Application-level limits bound many requests and outputs. An authorized owner process can still exhaust CPU, memory, disk, network, or external service quotas.
+
+Beta.61 retains cooperative admission to reduce accidental cross-agent resource storms, adds protected backfill and Linux PSI pressure evidence, and narrows project contention to provable shell working directories. None of these is a hostile-process containment boundary. A same-user process can ignore the coordinator, forge unrelated workload outside Machine Bridge, deliberately escape a process group, or consume more than its advisory reservation. The coordinator therefore protects cooperating Machine Bridge/workflow roots from accidental CPU/I/O/memory/disk oversubscription and starvation; account/container/VM/cgroup controls remain required against malicious or uncooperative local code. Persistent coordinator records contain no command text or raw project path, but their existence and coarse resource-family/timing metadata are local side channels to the same OS user. PSI reports system/cgroup stall history, not which particular cooperating process caused it.
+
+### System VPN/TUN and distributed activation
+
+A system VPN/TUN can remain administratively connected while its selected upstream route, synthetic DNS mapping, or transport path is temporarily unusable. Machine Bridge can detect missing inbound relay traffic, classify the socket close, bound retry delay, report outage history, and on macOS classify the default route as tunnel/VPN versus a coarse non-tunnel category. It cannot identify the failing upstream node or repair a third-party VPN. `system-network-stack` is therefore not a claim of direct routing. The route diagnostic deliberately omits interface identity, addresses, DNS answers, and endpoints. A Worker transport/liveness invalidation is treated as a retryable socket-generation failure; elevating it to a permanent protocol error would let an ordinary network fault restart the daemon and amplify the outage. Unknown protocol messages and authentication or version mismatch remain fail-closed.
+
+Candidate activation verifies the foreground candidate before service handoff and records exact package/deployment evidence. It does not provide an atomic transaction spanning Cloudflare deployment and every local service manager. The machine-global service definition therefore has an owner-only pending/committed ledger, all service writers share one fixed per-user lock, and any path that also acquires a workspace startup lock uses machine-service-first ordering. Provider-active state is not authenticity evidence: the exact owner-bound service daemon must publish a token-protected readiness checkpoint after device authentication, relay probe, and `ready_ack`. Missing, corrupt, pending, mismatched, or unready ownership fails closed.
+
+An explicit candidate device-authentication rejection permits one same-name redeployment with the unchanged selected identity; ambiguous network or health failure does not. After remote preparation, local compensation installs and starts the compatible candidate service rather than reviving a known-incompatible old daemon. Before remote preparation, restoration of an older service requires the same version and entrypoint to reappear as a verified service-mode daemon. The wrapper intentionally has no transaction-wide hard kill, because killing the parent could bypass cleanup and leave detached deployment helpers; each internal stage has its own deadline instead. Persistent Cloudflare, service-manager, filesystem, or process-inspection failure can still require operator diagnosis. Local cleanup errors are aggregated rather than hidden, and remote rollback is not fabricated.
 
 ### External governance and publication
 
-Code cannot create a second independent reviewer, npm OIDC trust relationship, protected environment, or OpenSSF Best Practices registration. Those controls remain explicit external work rather than simulated repository compliance.
+GitHub tag/Release publication requires an explicit confirmation flag, TTY-backed stdin/stdout/stderr, and one process-identity lock shared through the common Git directory. This blocks the supported MCP, managed-job, CI, redirected, and ordinary background paths and prevents concurrent publication from separate linked worktrees. It is a workflow and accountability boundary, not cryptographic user-presence authentication: arbitrary code already executing as the same OS user can allocate a pseudo-terminal and invoke the same command. A protected release environment, hardware-backed user presence, or a separately isolated principal is required when adversarial same-user separation is part of the threat model.
+
+Code cannot create a second independent reviewer, npm OIDC trust relationship, protected publication environment, Apple Developer identity, or external certification. These remain explicit operational requirements.
 
 ## Validation map
 
-The main regression suites cover:
+Regression suites cover:
 
-- OAuth, refresh-family replay revocation, signed administration requests, account, policy, device-authenticated daemon readiness, relay replacement, and local capability leases;
-- path confinement, atomic writes, state locks, service lifecycle, managed-job recovery, and destructive cleanup;
-- direct process boundaries, shell separation, process-tree termination, timeout, cancellation, and disconnect;
-- browser pairing, version/capability handshake, owner/client broker routing, sensitive-field handling, trusted input, and CSP navigation;
-- privacy redaction, package contents, release impact, interactive candidate acceptance, dependency integrity, CodeQL, and Scorecard findings;
+- account roles, trusted clients, account-version revocation, refresh-family rotation/replay, DPoP proofs, and non-escalatable effective authority; request-scoped stream cancellation does not weaken that boundary because the outer Worker strips caller-supplied internal control headers, mints a random capability itself, sends no bearer token or DPoP proof on the private cancellation request, and binds the capability only to the currently indexed in-memory call.
+- root-certified ephemeral sessions, preflight nonce replay, daemon challenge binding, readiness, reconnect, and candidate replacement;
+- signed account administration, client revocation, bounded strict-JSON administration responses, and removal of the long-lived administration secret;
+- control-plane path denial, path canonicalization, symlink handling, sensitive/persistence targets, and object ownership;
+- delegated sandbox behavior and fail-closed platform detection;
+- process/session cleanup, generated-key rollback including cleanup failure, managed-job lifecycle and recovery, state locks, atomic persistence, and destructive removal;
+- browser pairing, version/capability handshake, broker routing, independent concurrency limits, public-error redaction, sensitive input, and navigation controls;
+- audit-chain integrity, privacy redaction, package contents, installation, release impact, dependency integrity, CodeQL, Scorecard findings, and GitHub publication guard/lock behavior;
 - malformed, over-limit, concurrent, replayed, stale, and fault-injected inputs.
 
-See [TESTING.md](TESTING.md) for the complete test inventory and [AUDIT.md](AUDIT.md) for reviewed failures and residual limitations.
+See [TESTING.md](TESTING.md) for the test inventory and [AUDIT.md](AUDIT.md) for historical findings and residual limitations.
 
 ## Reporting