A worker is a trust decision.

The client portal is separate from the fellow portal.

Actions uses the existing Tbench identity service, but establishes its own host-only, HTTP-only session cookie. The server checks that an account is active, approved, assigned to a client organization, and has the client role before rendering the workspace.

Fellow, reviewer, and administrator roles do not become client accounts because they visit a different hostname. Account applications are reviewed. Approval permits client sign-in; it does not activate workers or grant production deployment authority.

State-changing portal requests require an allowed origin. Browser code receives no bearer token from the login response. Identity is rechecked on workspace access; service failure does not grant access.

Disposable environments are a design requirement.

The proposed Linux worker runs each CI runner and its workload inside a disposable VM. It should not mount the developer’s home directory or share the host’s privileged Docker socket. CPU, memory, disk, and network limits need enforcement and validation on each backend.

Rootless containers reduce privileges but do not provide the same boundary as a separate guest kernel. Firecracker requires Linux/KVM; Windows, macOS, GPU passthrough, and nested virtualization need separate compatibility work.

Protecting the host is not protecting secrets from the host.

A machine’s administrator can influence execution and access data on that machine. A sandbox does not make a personal machine an independently trusted verifier. Short-lived tokens reduce exposure time but do not remove that trust relationship.

• Default to minimal repository permissions and task-specific credentials.
• Keep production signing and deployment jobs on explicitly trusted infrastructure.
• Block public, untrusted jobs from personal workers by default.
• Restrict network access according to workload policy and protect cloud metadata endpoints.

Cache writes cross time as well as process boundaries.

A clean VM can still consume a poisoned cache. The proposed cache policy separates trust classes, restricts who can publish reusable state, and never intentionally snapshots credentials. Lower-trust jobs should receive disposable writes rather than permission to alter a future privileged job’s inputs.

Current qualification boundary.