Security at runnerhut

Isolation

• One job, one microVM, with its own kernel — never a container on a shared kernel
• The VM is destroyed at job end; disks are cryptographically wiped, not reused
• Cache objects are encrypted and scoped per repository
• No operator shell access to running job VMs

Compliance

• SOC 2 Type 2, audited annually, report available under NDA
• Annual third-party penetration test
• GDPR DPA with published sub-processors and 30 days' notice of change
• EU and US data residency for compute, cache, logs and metrics

Access and identity

• Integrates as a GitHub App with scoped installation tokens — never a personal access token
• SAML and OIDC SSO with SCIM provisioning
• Append-only audit log with SIEM export
• Default-deny egress policy available per runner group

What a compromised job could and could not reach

Worth stating plainly, because it is the question a reviewer is actually asking. A job runs in its own microVM with its own kernel, so escaping to the host is the hard boundary rather than a container namespace. It can reach the network unless an egress policy restricts it, which is why default-deny egress matters more than most controls. It cannot read another tenant's cache, because cache objects are encrypted per repository. It cannot persist, because the VM and its disk are destroyed at job end.

Where the residual risk actually sits

• Your workflow: over-permissioned GITHUB_TOKEN, unpinned third-party actions, pull_request_target with a checkout of the PR head
• Your dependencies: a compromised postinstall script runs with whatever network access the runner has
• Your secrets: anything decrypted into a job is visible to code running in that job, including code a dependency pulled in

We can constrain the second and third with egress policy and short-lived credentials. The first is yours, and the GitHub Actions security checklist covers it in five changes.