Control what runs. Know where it runs.

Organization account access.

Actions uses the existing Tbench identity service with 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.

Company sign-in discovers only statically configured providers for exact operator-verified domains. It never looks up whether an individual has an account. Shared domains require an explicit workspace ID. Owners and admins can resolve an approved teammate by email only within their own organization.

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. Post-login destinations are restricted to local dashboard paths; external links and API targets are refused.

Disposable jobs. Bounded resources.

The device worker uses a disposable non-root Docker container, a 160-process limit, dropped capabilities and no-new-privileges. A runner class allocates its advertised CPU count and 1024 MiB per CPU; default device consent is two job CPUs within 4096 MiB including a separate 128 MiB proxy. The proxy also has a 0.25 CPU ceiling. No host directories, Docker socket or host ports are exposed. An isolated internal network permits outbound HTTPS through a domain allowlist; private and local DNS answers are rejected. Package registries require an explicit opt-in.

Use trusted private code on Ubuntu 24.04 x64. Docker shares the host kernel, and same-label repository jobs can be assigned before broker observation. Privileged builds and hostile/public code require stronger isolation and are not supported by this profile. Writable-layer disk quotas, ARM, macOS, GPU and Windows job images require separate qualification.

Keep signing keys on the broker.

GitHub App keys remain on the hosted broker; devices receive revocable scoped enrollment and short-lived runner configuration. A machine’s administrator can influence execution and access data on that machine, including workflow secrets GitHub grants to its jobs. Choose hosts appropriate to the sensitivity of each workload.

• 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.

Know where workflow data goes.

Execution occurs on the enrolled device. GitHub receives repository data, workflow logs and configured artifacts. Tbench’s hosted broker handles organization, repository, device and job metadata. Keep source and secrets out of published logs and artifacts.

Actions runs the checks your approved workflow defines; it does not add an automatic LLM judge. A model step sends only the inputs it is configured to send, and a remote provider receives those inputs. Review the provider, data terms and allowed network route before enabling that step.

For source-sensitive model checks, use an organization-controlled inference endpoint and explicitly approve its network path. The reviewed in-job local model inference profile remains pending qualification, and container isolation does not automatically expose a developer’s host model service to a job.

Your repository controls linting, tests, security checks and review rules. Choose which checks are required, and pair model-assisted review with branch protection and independent review before merging.

Cache writes cross time as well as process boundaries.

The current runner uses disposable job environments without a managed persistent build cache. Repository-configured external caches have their own data and trust boundaries. Before enabling shared build state, separate trust classes, restrict cache publishers and keep credentials out of reusable snapshots.

Controls across the job lifecycle.

Worker enrollment is single-use and expiring. Job claims use conditional durable writes and worker-bound leases. GitHub completion events require a valid HMAC signature and exact job/run/repository identity. Ambiguous dispatch and started jobs are not automatically retried. A definitely unstarted native job may return to the queue only after independent inspection and confirmed cleanup. The foreground worker serves a bounded session; stopping or sleeping the device removes its availability.

A separately signed execution policy.

The independent Tbench queue approves an immutable policy and signs each assignment with its own Ed25519 key. An enrolled device verifies the key, organization, commit, policy digest, device identity and fenced lease before executing. Source stays in your organization-controlled Git object cache rather than being uploaded to the queue.

• Non-root Linux containers, read-only root filesystem and disabled network.
• Named command steps with CPU, memory, timeout, log and writable-storage caps.
• No host Docker socket, arbitrary bind mounts, automatic image pulls or implicit architecture emulation.
• Heartbeat, cancellation and results bound to the same leased job.
• Ambiguous or expired active work requires operator review before another attempt.

The local application verifier adds a separate named required/advisory check policy. A device-reported pass is not remote attestation; high-trust merge enforcement and official certification require independent evidence. Organization trials preserve all these access and workload controls.