A Protected Runner Is Not Approval: Pressure-Testing Ota's First Signed Authority Carrier

A runner label identifies a machine but does not grant permission to execute a repository action. GitHub Actions can direct a job to a self-hosted runner, but the label only answers, "Which machine can handle this job?" It does not address the critical question of whether the specific task, such as publishing, migrating, or deploying, is authorized to run.

A workflow cannot generate its own approval by requesting a more privileged runner. Ota's first signed carrier is built around this separation. The repository determines the governed lane, while the workflow requests a protected runner from GitHub. A separate authority source then decides if the exact lane can cross its boundary.

Ota confirms this decision before any actions begin and logs a new transaction afterward. This model was rigorously tested on a pre-provisioned Linux/x64 VPS runner. One authorized task succeeded, producing a retained archive, while three attempts with invalid authority were blocked before the task executed. The result is not a general approval system but a concrete demonstration of a deliberately bounded carrier.

The pressure test showed that the flow works under stress. The repository contract selects the governed lane, and the workflow asks for a protected runner label. The protected runner then triggers `ota run ... --grant id`, and Ota verifies the fixed authority state and the exact semantic scope. A new crossing transaction begins, the task runs, and the receipt and archive confirm admission to the outcome.

Each layer maintains its own job: the repository contract defines the governed lane, GitHub's workflow handles scheduling, checkout, credentials, and provider policies, authority issuance and provisioner manage the signed bundle, revocation, sequence state, and signing key, and Ota on the runner handles admission, scope verification, transaction, receipt, and archive.

This separation is the core value proposition. While GitHub remains responsible for scheduling and platform controls, Ota introduces repository-specific governance, allowing independently issued authority to be bound to the complete action the repository is about to execute. The pressure test verified that the correct administrator-installed Ota binary matched a root-owned full-commit and SHA-256 manifest before checking authority.

The workflow then ran Ota's read-only hardening diagnostic as an unprivileged job user. Various scenarios were tested, including live grants, expired grants, revoked grants, and out-of-scope grants. Each refusal case was documented with typed JSON refusal records, human-readable messages, and complete checkout manifests before and after the dry-run and real refusal.

The selected scaffold task never started, ensuring the boundary was clearly demonstrated. Ota verified several factors before running the live task: the repository contract names only an authority identifier without signing keys, bundle locations, trust-store paths, or revocation states. These details are stored in fixed protected system paths.

Before admitting the selected lane, Ota verifies the fixed authority binding and the signed bundle, 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 task name but an identity that changes if dependencies, hooks, task effects, target platform, or execution selection change.

A grant for yesterday's publish lane cannot silently authorize a modified closure with the same label. The archive created by a successful run is more than a log line. It includes a fresh crossing transaction, verification of the selected scope, and retention of the receipt archive in the hosted artifact. This provides a verifiable chain: governed lane - verified signed authority and semantic scope - fresh crossing transaction - selected task outcome - archive that can re-derive the recorded scope.

This closes a critical gap. A provider can confirm a workflow ran, but Ota preserves the specific repository action that crossed the declared boundary, the authority that admitted it, and what happened afterward. However, this proof is intentionally narrow: it confirms that the authority files were protected within the current Ota process and verified the selected crossing against those files before work began.

It does not prove provider-attested isolation between the job and an administrator, absence of every possible escalation path, metadata credentials, or host-control endpoints, nor does it guarantee a verifiable absence of all possible vulnerabilities.