Use case:
When running a public survey that collects sensitive data (in my case, autism research), I want anyone with the participant link to be able to submit, but I want to guarantee that only specific accounts can ever edit the form or read responses — even if an author or auditor link leaks.
Current behavior
Today the privileged roles are gated only by possession of the key embedded in the link. The Access list can restrict a Form, but it gates the whole document at the retrieval layer, so enabling it also blocks anonymous participants (they have no account to check against the list). The result is an all-or-nothing choice: either fully open participation with author/auditor access resting entirely on link secrecy, or an authenticated allow-list that also locks out anonymous respondents.
Why this is hard
I understand the access list operates on server-side retrieval of a single encrypted blob, and that participants must retrieve that same blob to render the form, so a single document-level gate can't distinguish roles. This request is therefore explicitly for decoupling "who may retrieve the form definition to fill it in" from "who may retrieve responses / edit," which I recognize is an architectural change rather than a config toggle.
Proposed behavior
Allow an Access list to be scoped to the author and auditor roles only, while participant submission remains open to unauthenticated link-holders. The goal is leak resistance for the privileged roles: a leaked author/auditor link should be useless to an account not on the list.
Impact
For research and other regulated-data use cases, standing auditor links across a team are a real exposure with no rotation path today (a leaked key currently forces rebuilding the form under new keys). Server-enforced, account-based gating for the privileged roles would remove that single point of failure.
Related: #2231 (documentation of Access list × Forms interaction).
