SEC-WF-001 — Block multi-project rollout until runtime authorization is active

Field	Value
Status	Open rollout blocker; source-verified, cross-role live evidence pending
Architecture state	Deployed single-project legacy access; workflow-scoped OpenFGA checks implemented but inactive
Severity	Critical
Affected surface	Runtime reads, trigger, clear, mark state, source, logs, XCom, and UI action visibility
Components	sparqd/oqullus, sparqd/bff-api, sparqd/workflow-backend, OpenFGA, Airflow
Associated issue	Not opened

Where the problem appears

Inventory current runtime access with two authenticated roles, then reserve cross-project denial testing for an environment where OpenFGA is activated.

Concrete observed case

The deployed frontend uses the backward-compatible single-project model and calls the generic Airflow BFF facade for most runtime operations. That path is protected by its legacy token/audience and Airflow-role contract, not by workflow-scoped OpenFGA decisions. Workflow-backend source contains operation-specific OpenFGA checks, but OpenFGA is inactive and the browser does not use those routes.

This assessment therefore does not claim that deployed per-workflow grants are being bypassed; those grants are not rolled out. It identifies a hard security precondition for exposing multi-project selection or per-workflow sharing.

Expected condition

Keep current support explicitly single-project while the legacy path remains. Before multi-project rollout, activate OpenFGA and migrate every read and mutation to a route that resolves the workflow UUID and checks the specific relation before contacting Airflow. UI actions reflect capabilities but never replace server enforcement.

Cause and evidence

• Direct Airflow routes are used for runs, tasks, logs, XCom, clear, mark state, source, graph, and grid.
• Workflow-backend runtime routes implement view, trigger, pause, clear, and mark-state relations in source; they are not active protection in the assessed deployment.
• BFF Workflow facade does not currently proxy that runtime surface.

Why it matters

If multi-project or workflow-level access is presented before this migration, a user with generic Airflow access could read or mutate another workflow, including sensitive logs and XCom. The current risk is architectural rollout drift, plus any excessive access in the legacy Airflow role model; the latter still requires live role evidence.

Existing controls and workarounds

Document and restrict the current single-project Airflow roles. Do not expose multi-project selection, sharing, or workflow-level permission claims until the new enforcement path is active.

Alternatives considered

1. Recommended: migrate to explicit workflow-backend runtime routes, activate OpenFGA, verify the role matrix, and then disable generic browser access.
2. Retain single-project legacy access indefinitely — viable only if the product explicitly rejects multi-project and per-workflow isolation.
3. Implement DAG-level Airflow permissions synchronized from OpenFGA — possible defense in depth, but still keep the product boundary.
4. Trust UI filtering — rejected because direct requests bypass it.

Component involvement

• sparqd/workflow-backend contains the future canonical permission checks; they become enforcement only after OpenFGA activation.
• sparqd/bff-api exposes only explicit runtime routes.
• sparqd/oqullus keeps current controls consistent with the legacy access contract; after rollout it gates presentation from returned capabilities. Airflow remains defense in depth.

Reproduction and verification

Follow WF-S006.

Resolution conditions

Close only after OpenFGA is active and cross-project/workflow denial tests prove no Airflow call occurs. Until then, keep this as a rollout blocker rather than reporting the source checks as deployed protection.

Validation and blockers

Security, workflow-backend, BFF, Oqullus, OpenFGA, and Airflow owners must validate before runtime access is considered safe.