Access controls need to hold at the data boundary, not just in the interface.
A page can hide a button while the underlying API still allows the action. Likewise, filtering a list in the browser is not proof that another user’s data is protected.
Start with the expected rule
Write down who should be able to read or change each kind of record. For example, a workspace member might read that workspace’s projects while a visitor should have no access.
Test both sides of the boundary
In a verified test environment, synthetic accounts and records can help test allowed and denied access. Use accounts with different roles and workspace membership. A successful authorized request is only half of the question.
If database policies are configured outside the repository, source access alone may not establish what is deployed. A useful report should identify the evidence it has and the policy details it still needs.