Courts IT must let clerks query docket summaries while blocking direct access to the underlying evidence metadata tables. What permission pattern should they use?

Granting SELECT on a curated docket view while denying direct table permissions on the underlying evidence metadata tables lets clerks query docket summaries without access to sensitive base tables. The view is a controlled presentation surface: least privilege comes from granting access to the needed view and withholding access to the underlying tables. Granting db_owner to every clerk login fails because ownership rights exceed the need; they can allow schema changes, data writes, and access far beyond docket summaries. Masking sensitive columns while granting unrestricted SELECT on every underlying evidence table also fails: masking may obscure displayed values, but it does not replace denying access to the tables. Publishing base tables anonymously through an unauthenticated REST endpoint removes identity and authorization, making it unsuitable for court evidence controls. Exam caveat: a view does not ensure separation if clerks also have base-table permissions or elevated ownership unintentionally widens access; omit those grants or explicitly deny them. Operational check: create the view with only summary columns, grant SELECT on it to the clerk role, and confirm that role has no SELECT, INSERT, UPDATE, or DELETE permissions on evidence metadata tables. Connect as a clerk and verify that summary queries succeed while SELECT against the base tables fails. Recheck permissions after schema deployments.