Security

The Security tab turns the roles defined in Domain into a role-based access-control (RBAC) matrix across every surface the plan contains — the pages, layouts, and components drawn in Structure, the entities modelled in Data, and the endpoints defined in Backend. One grid answers the question every stakeholder eventually asks: who can reach what?

Define the axes first

Roles come from Domain → Roles, and they are the matrix's columns; the plan's pages, entities, and API endpoints form the rows automatically, so a route added on Structure or an endpoint added on Backend appears in the matrix without any bookkeeping. If no roles exist yet, the tab's empty state takes you straight to the Domain tab's Roles panel rather than leaving you to find it.

Baseline plus exceptions

The matrix is a default policy with recorded deviations, not a cell-by-cell checklist:

• Choose the baseline — permissive (allow, the default) or locked down (deny).
• Toggle exceptions — click a cell to flip that one role-and-surface pair away from the baseline.

Only the exceptions are stored, so surfaces added later inherit the baseline automatically instead of arriving half-configured. Switching the baseline preserves who can currently reach what — the exception set is re-expressed against the new default, so the grid looks identical after the switch and only pairs added later pick up the new policy.

Generate a starting policy

The Generate button asks the AI for a least-privilege starting policy, grounded in the Domain description, the project's target, and the actual roles and surfaces on the grid. A generated fill replaces the whole exception set, so it is a starting point to refine, not a merge into hand-set cells — run it before detailed tuning, not after. The button's chat half opens the assistant sidebar instead, when you would rather reason about the policy than generate it.

Derived denials from route guards

Role guards placed in Structure's Nav view appear in the matrix as derived denials — locked cells the grid cannot toggle, because they are decided on the page itself. They are computed live rather than stored, so removing a guard lifts its derived restriction the moment it is gone. This keeps the matrix honest: it never appears to grant access the generated guards would refuse.

Where the policy goes

The matrix is saved with the project and enforced in the generated code: guarded pages emit a real role check that redirects, and guarded route handlers answer with 403 — the behaviour described in security concepts. The policy also appears in the project report and the generated README, and Traceability sits beside it for the feature-coverage half of the same review.