Security
Assume the workflow is hostile.
The execution boundary is disposable. The control plane, credentials and evidence path stay outside it.
Controls
The boundary, by design.
One job per execution
Each job gets one Firecracker microVM behind jailer, with its own copy-on-write disk, cgroup and network namespace. No slot is reused.
Trusted repositories first
Fork pull-request workloads and unknown repositories are rejected by policy.
Scoped credentials
Only short-lived, job-scoped material enters the guest. One-time runner configuration is erased after cleanup.
No public ingress
Jobs receive public egress only. Private ranges, metadata endpoints and SMTP ports are in the required deny set.
Provenanced evidence
Authoritative lifecycle and cleanup events are kept apart from untrusted, guest-produced diagnostics.
Explicit uncertainty
A stale heartbeat or uncertain cleanup quarantines the node. Evidence gaps are visible states, never silent success.
Signed runner images
Runner images are pinned by digest and released with an SBOM, provenance and a signature that admission verifies.
Nothing from the host
No host Docker socket, host filesystem, host network, tailnet, cloud metadata, provider or control-plane credentials in the guest.
Honest limits
Bounded verification, not absolute safety.
A workflow can gain root inside its isolated execution and can tamper with guest-produced diagnostics. OpenRunners treats those diagnostics as untrusted while separately recording authoritative lifecycle and cleanup state. A passing workflow does not prove software is safe.
These controls are release gates. Customer admission stays closed until each has a current, observed receipt from the production runtime. Report vulnerabilities privately to the security contact listed in the project's security policy.
Run your next job on a runner that shows its work.
Admission is manual for trusted GitHub repositories while the release gates close. Sign in with GitHub to request access and we will review your organization when a slot opens.