A runner label chooses a machine.
It does not authorize a repository action.
GitHub Actions can route a job to a self-hosted runner.
A label answers one useful question: Which machine is eligible to receive this job?
It does not answer the question that matters for a heavier repository action: Is this exact publish, migration, deployment, or other non-routine task authorized to run now?
Those are different boundaries.
A workflow must not be able to create its own approval merely by asking for a more privileged runner.
Ota's first signed crossing-authority carrier is designed around that separation.
The repository declares the governed lane.
The workflow asks GitHub to schedule a protected runner.
A separately managed authority source decides whether the exact lane may cross its boundary.
Ota verifies that decision immediately before effects start and emits a fresh transaction record after it does.
We pressure-tested that model on a pre-provisioned Linux/x64 VPS runner.
One live authorization executed and produced a retained archive.
Three invalid-authority cases refused before the task ran.
The result is not a general approval system.
It is concrete evidence for a deliberately bounded carrier.
The flow under pressure Each layer retains its own job: Layer Owns Does not own Repository contract Which lane requires a crossing Trust keys, grants, bundle paths, or revocations GitHub workflow Scheduling, checkout, credentials, and provider policy Authority issuance Authority provisioner Signed bundle, revocation, sequence state, and signing key Repository task selection Ota on the runner Admission, scope verification, transaction, receipt, and archive Issuing its own authority That separation is the product value.
GitHub still owns scheduling and platform controls.
Ota adds repository-specific governance: a way to bind independently issued authority to the complete action the repository is about to execute.
What we tested The pressure workflow verified the exact administrator-installed Ota binary against a root-owned full-commit and SHA-256 manifest before it checked authority.
It then ran Ota's read-only hardening diagnostic as the unprivileged job user.
Required observations had to pass: Linux/x64, non-root execution, no declared Docker host or common Docker socket, and valid fixed trust, bundle, and sequence records.
The four hosted scenarios ran against the same merged workflow revision: Scenario Result What the evidence proves Live grant Passed Exact-scope admission created a completed crossing transaction; the retained artifact contains the verified receipt archive and valid receipt history.
Expired grant Passed Dry-run and real execution refused with ; before/after checkout manifests matched.
Revoked grant Passed Dry-run and real execution refused with ; before/after checkout manifests matched.
Out-of-scope grant Passed Dry-run and real execution refused with ; before/after checkout manifests matched.
The refusal cases are important.
A green result or a rejected command alone would not establish the boundary.
The pressure workflow retained typed refusal JSON, the human refusal output, and complete checkout manifests before and after both dry-run and real refusal.
The selected scaffold task never started.
What Ota verified before the live task ran The repository contract names only an authority identifier: It does not contain the signing key, bundle location, trust-store path, or revocation state.
Those live outside the checkout at fixed protected system paths: Before Ota admits the selected lane, the first carrier verifies the fixed authority binding and the signed bundle, then checks the grant's exact contract identity, complete selected execution scope, crossing family, classification, actor posture, expiry, revocation, and sequence/high-water state.
The scope is not a friendly task name.
Changing dependencies, hooks, task effects, target platform, or execution selection changes the semantic scope identity.
A standing grant