Question

An enterprise admin registers a new self-hosted runner in an organization but does not assign it to a specific runner group during setup. A team lead reports that the runner is picking up jobs from repositories that should not have access to it. Which explanation best describes why this is happening, and how should the admin correct it?

Accepted Answer

New runners are placed in the 'Default' runner group, which by default allows all repositories in the organization to use it; the admin should create a restricted runner group and move the runner into it.

Answer

Self-hosted runners ignore runner group membership entirely, so the admin must instead add repository-level IP allow lists to block unauthorized repos.

Answer

The runner was registered at the enterprise level, which grants all organizations access; the admin should re-register it at the repository level to fix scoping.

Answer

Runner group access is controlled solely by runner labels, so the admin should remove the default labels to prevent unauthorized repositories from targeting the runner.