A runner group permits execution but does not isolate code

A fictional organization limits a self-hosted runner group to two repositories. A proposed workflow from one allowed repository can still execute code from an untrusted contribution, and the host retains sensitive network reachability and state between jobs. A colleague declares the setup safe because no third repository can select the runner. Another separates runner eligibility from code trust, job permissions, secrets and host isolation. This written exercise registers no runner, starts no workflow and reads no credentials. It asks what the access policy actually establishes and why a qualified authorized workflow design must address the consequences of untrusted execution rather than rely on one eligibility control.