SEC-WF-005 — Add Pin to workflow authorization before multi-project rollout

Field	Value
Status	Open rollout blocker; source-verified
Architecture state	Deployed single-project pin path; workflow-scoped OpenFGA checks inactive
Severity	High
Affected surface	Pin and unpin workflow operations
Components	sparqd/oqullus, sparqd/bff-api, sparqd/workflow-backend, OpenFGA
Associated issue	Not opened

Where the problem appears

Inspect Pin in current single-project mode. Perform denied-workflow UUID tests only after OpenFGA and multi-project access are activated.

Concrete observed case

The deployed Pin path loads a workflow by UUID, creates the caller's pin, and returns the full workflow response. That is consistent with the current single-project compatibility model, which has no rolled-out per-workflow grants. Workflow-backend source does not invoke its dormant view_workflow check on Pin or Unpin, so the path is not ready for a future multi-project or workflow-sharing rollout.

Expected condition

After the authorization plane is activated, Pin requires view_workflow and returns no resource fields on denial. Pin listings apply the same authorized discovery and pending-authorization rules as ordinary list/detail.

Cause and evidence

• Pin service checks existence but not workflow authorization.
• Its successful response includes workflow configuration and metadata.
• Canonical list/detail source paths contain separate visibility and pending authorization checks; those depend on an activated authorization plane.

Why it matters

There is no demonstrated violation of a deployed per-workflow policy because that policy is inactive. The same route becomes a disclosure and reference- creation gap as soon as workflows can have different viewers or projects.

Existing controls and workarounds

Keep Pin within the documented single-project role boundary. Do not enable multi-project selection or workflow sharing until Pin uses the activated resource capability; UUID unpredictability is not authorization.

Alternatives considered

1. Recommended: require view_workflow before pin/unpin and reuse canonical response assembly.
2. Accept blind pin with no response body — still creates references to unauthorized resources and complicates later disclosure.
3. Browser-only prevention — rejected because direct requests remain possible.

Component involvement

• sparqd/workflow-backend preserves current single-project visibility and adds Pin to active workflow authorization during OpenFGA rollout.
• sparqd/bff-api passes denial without fallback.
• sparqd/oqullus uses the legacy access contract now and offers Pin from the returned capability only after rollout.

Reproduction and verification

Follow WF-S011.

Resolution conditions

Close as a rollout blocker after OpenFGA activation and denied UUID tests return no data or side effect, pending workflows remain hidden, and allowed Pin behavior stays idempotent.

Validation and blockers

Security and workflow-backend owners must validate; BFF and Oqullus verify propagation and presentation.