Access by project
Access is based on an active project membership and a verified session with a second factor. Database policies and server commands enforce the role boundary. Administrative changes are audited; access to another project is not inherited.
The web application is separated from the simulation worker and its signing keys. Browser code must not contain service-role credentials or private signing keys. A test environment must not be used for real funds or personal investor data.
Research data and messages
Only approved research snapshots are intended for public release. Private working data and research labels do not become public merely because a related snapshot is published. A download is checked against the current publication status.
The prepared message module requires authenticated project access. Its transport and storage protections must be verified in the hosting environment before activation. They are not end-to-end encrypted. Do not use them to share secrets or highly sensitive personal information.
Verification before service activation
Local automated checks are part of development, not a certificate of security or evidence that hosted services are live. Activation requires hosted access-control tests, authentication and recovery checks, delivery verification, backup and restoration evidence, and the relevant operational approvals.
No claim of an independent penetration test, formal security certification or uninterrupted availability is made here. If you discover a suspected issue in a private workspace, notify your project owner without publishing credentials or exploit details in a public channel.