Library security settings
Security settings place library-wide controls around Production deployment, Builder access and live operational data. Open the library, select Library settings, then Security settings. Only an authorised administrator should change these controls.
Understand the controls
| Setting | What it controls | Operational consequence |
|---|---|---|
| Sandbox control | Whether services in the library can be deployed to Production. | Sandbox mode prevents every Production deployment from this library. |
| Enforce multifactor authentication | Whether Builder users in the library must set up a second sign-in factor. | Affected users cannot access the library until setup is complete. External QA testers are not Builder users and are unaffected. |
| Live data export | Whether library users can download submitted live data as CSV or JSON. | An exported file leaves platform access control and audit coverage once it is on a local device. |
| Disable User data view | Hides the live user-data view in analytics for every service in the library. | Users following an existing link see guidance to contact an administrator. |
| Disable Audit log view | Hides the audit-log view in analytics. | Operational investigation may need another approved route. |
| Allow Administrators to delete live records | Enables record deletion from the user-data view for administrators. | Deletion becomes available only to that high-privilege role and should follow an approved retention process. |
Use sandbox mode as a release guard
Choose Sandbox mode – prevent Production deployments for training, experimentation or a library that is not approved for live services. The control applies to the entire library, not just the current service.
Before allowing Production deployments, confirm that the library has named release owners, appropriate user roles, live integrations, data handling arrangements and a tested release process. Switching the guard off does not deploy anything by itself; it makes Production deployment possible for authorised users.
Enforce multifactor authentication deliberately
Enabling the requirement can immediately block a Builder user who has not completed setup. Before applying it:
- Tell library users when enforcement will begin.
- Confirm that administrators have completed setup and recovery arrangements exist.
- Review pending invitations and accounts that are no longer needed.
- Apply the setting and verify access with a non-administrator Builder account.
The user-management list shows whether multifactor authentication is enabled for each user. An administrator can also reset a user’s setup from that user’s record when a legitimate recovery need is confirmed.
Control live data access and export
The export control and the analytics-view controls solve different problems. Disabling export prevents supported CSV and JSON downloads; disabling the user-data view removes the interactive view. Consider them together with user roles, device controls, retention policy and external API access.
If export is allowed, define where files may be stored, how they are encrypted, how long they are retained and how an accidental disclosure is reported. Never use live exports in QA testing.
Allowing administrators to delete live records should be exceptional. Document who can authorise deletion, which evidence must be retained and whether another connected system also stores the record. Removing a record from one view may not remove copies held elsewhere.
Apply and verify
Select Apply after reviewing every control on the page. Then verify the outcome that matters: attempt the restricted deployment, sign in as an affected role, open the relevant analytics view or test the approved export process. A saved checkbox is not evidence that the wider operating process is safe.