Two identities, two purposes
Umbraco backoffice users edit content and administer MegaForm. Umbraco members sign in to the public website. A visitor's member login does not make them a MegaForm administrator, and a backoffice login should not be used as the public member test.
Configure editorial access
Grant the relevant Umbraco user group access to the MegaForm section. Then review MegaForm permissions for viewing, editing forms and managing submissions. Use a restricted editor account to verify the result; an administrator account does not reveal missing permissions.
Server endpoints enforce permissions independently of the visible menu. A hidden button is not an access boundary. Private entries, attachments and script source require appropriate authorisation.
Require a member login
Use the form's Require Login setting for a member-only experience. Test the page signed out, as an eligible member and as an ineligible member. Check any member prefill against the actual member's profile and avoid trusting a hidden input as proof of identity.
Field visibility/read-only rules can use the roles available through the host. Review those rules with the intended account and inspect the delivered form as well as the screen.
Script authoring is more restricted
C# authoring requires a native backoffice administrator, an enabled server feature and the compiler. Ordinary form-edit access is insufficient. See C# scripting.
Submissions explains the entry workspace and private attachment flow.