A self-hosted runner executes workflow instructions on infrastructure the organization manages. That machine may reach private repositories, package mirrors, internal services, and cloud endpoints. A job's effective authority includes those connections as well as the permissions visible in the workflow file.
This makes runner placement part of the security design. The question is what a job can reach and what state it can leave for the next job.
Persistent hosts can carry state between jobs
GitHub's security guidance warns that self-hosted runners can be persistently compromised by untrusted workflow code and are not inherently clean environments between jobs. It describes isolation considerations for organizations operating them. GitHub's secure-use reference covers these risks.
An illustrative test runner shares a host with a release runner. Even if their workflow tokens differ, a writable shared directory or host-level credential can connect the two contexts. Reviewing only the token permissions would leave that relationship unexamined.
Map network and host authority
Identify reachable internal services, metadata endpoints, mounted sockets, shared caches, and credentials available to the runner process. A containerized job is not automatically isolated from the host if privileged mounts or runtime controls expose host authority.
Separate job classes by the trust level of their inputs and the resources they need. A public contribution test and a production deployment have different requirements. Document which runner groups can accept each job and who can change those assignments.
Test cleanup with harmless persistent markers
In a dedicated environment, have one job create a benign marker in each agreed writable location. Run a subsequent job and check which markers remain accessible. The test can reveal persistent workspace, cache, or home-directory state without introducing malicious software.
Also test whether the less-trusted job can reach a controlled internal endpoint that should be unavailable. Record the network decision and runner identity. A host's network location can grant access even when a job has no explicit application credential.
Plan replacement and evidence retention
Ephemeral runners can reduce cross-job persistence when the underlying compute environment is actually discarded. Removing a runner's registration alone does not prove that the host, disk, or cached credentials were destroyed. Verify the lifecycle implemented by the infrastructure platform.
Preserve job and infrastructure logs outside the disposable environment so an investigation does not lose its evidence when the runner terminates. Record who can modify those logs and how they connect to the workflow revision.
A scoped review can then describe which jobs share a boundary, what each can access, and how the environment is reset. Those findings support a concrete runner architecture decision rather than a general conclusion based solely on whether a runner is hosted internally or by a provider.
Sources
GitHub: Self-Hosted Runners. The shared-host example is illustrative.
