Gate: block unattended scheduling until the concurrency and exfiltration canaries both certify #964

New Issue

2026-07-28T02:57:23-05:00

jcwalker3 commented

2026-07-28 02:57:23 -05:00

Parent: #955 (certification umbrella).
Cross-link: #797, #805, #887, #929.
Depends on: #962, #963, #899.

Goal supported: both — multi-LLM and secure isolation.

Problem

#899 makes administrative loop-disable enforceable, which answers "the operator turned it off." Nothing answers "it was never certified on." Once #899 lands, an operator can enable a scheduled worker at any time with no requirement that either canary has ever passed — and #887's and #929's completion gates are prose in epic bodies that no code consults.

Current evidence

#899's acceptance criteria are entirely about disable, bootout, respawn, and reboot persistence.
#797's acceptance criterion "worker schedules and responsibilities can be validated before activation" is a configuration check, not a certification check.
Both epic completion gates are unenforced prose.

Scope

A durable certification record naming each canary, the commit certified, the timestamp, and the evidence.
A fail-closed precondition on enabling or running any unattended scheduled worker.
Explicit expiry, so a certification does not outlive the code it certified.

Non-goals

Running the canaries — #962 and #963.
The administrative disable mechanism — #899.
The worker control surface — #805.

Security and concurrency boundaries

The certification record is authority state. It must live where an LLM client cannot write it, and it must bind to a specific commit.

Acceptance criteria

Enabling or running an unattended worker without both current certifications fails closed with a typed blocker, distinct from the #899 administrative-disable blocker, from an issue-first refusal, and from a wrong-role refusal.
A certification is bound to a commit and invalidated when the certified surface changes.
Certification state is queryable by workflow tooling.
A supervised, attended run remains possible, so the canaries themselves can execute.
The gate cannot be satisfied by editing a file an LLM client can write.

Required positive tests

Both canaries green permits scheduling.
A run after a certified commit is permitted.

Required negative and adversarial tests

Neither certification present is refused.
Only one certification present is refused.
A certification for a superseded commit is refused.
An expired certification is refused.
An LLM client attempting to write its own certification record is refused and audited.

Deployment and migration requirements

The certification store lives on the protected server once #961 completes.

Rollback and recovery requirements

Revoking a certification immediately re-blocks scheduling.

Observability and audit requirements

Every grant and refusal is audited with the deciding certification.

Definition of done

Unattended scheduling is impossible until both canaries certify.

Parent: #955 (certification umbrella). Cross-link: #797, #805, #887, #929. Depends on: #962, #963, #899. **Goal supported:** both — multi-LLM and secure isolation. ## Problem #899 makes administrative loop-disable enforceable, which answers "the operator turned it off." Nothing answers "it was never certified on." Once #899 lands, an operator can enable a scheduled worker at any time with no requirement that either canary has ever passed — and #887's and #929's completion gates are prose in epic bodies that no code consults. ## Current evidence - #899's acceptance criteria are entirely about disable, bootout, respawn, and reboot persistence. - #797's acceptance criterion "worker schedules and responsibilities can be validated before activation" is a configuration check, not a certification check. - Both epic completion gates are unenforced prose. ## Scope - A durable certification record naming each canary, the commit certified, the timestamp, and the evidence. - A fail-closed precondition on enabling or running any unattended scheduled worker. - Explicit expiry, so a certification does not outlive the code it certified. ## Non-goals - Running the canaries — #962 and #963. - The administrative disable mechanism — #899. - The worker control surface — #805. ## Security and concurrency boundaries The certification record is authority state. It must live where an LLM client cannot write it, and it must bind to a specific commit. ## Acceptance criteria - Enabling or running an unattended worker without both current certifications fails closed with a typed blocker, distinct from the #899 administrative-disable blocker, from an issue-first refusal, and from a wrong-role refusal. - A certification is bound to a commit and invalidated when the certified surface changes. - Certification state is queryable by workflow tooling. - A supervised, attended run remains possible, so the canaries themselves can execute. - The gate cannot be satisfied by editing a file an LLM client can write. ## Required positive tests - Both canaries green permits scheduling. - A run after a certified commit is permitted. ## Required negative and adversarial tests - Neither certification present is refused. - Only one certification present is refused. - A certification for a superseded commit is refused. - An expired certification is refused. - An LLM client attempting to write its own certification record is refused and audited. ## Deployment and migration requirements The certification store lives on the protected server once #961 completes. ## Rollback and recovery requirements Revoking a certification immediately re-blocks scheduling. ## Observability and audit requirements Every grant and refusal is audited with the deciding certification. ## Definition of done Unattended scheduling is impossible until both canaries certify.