Security & Data Practices

• Invite-only accounts; there is no public sign-up.
• Roles are stored separately from profiles and cannot be changed from the browser.
• Every table enforces row-level security, so a provider can reach only their own records and administrator-only data is refused at the database, not merely hidden in the interface.
• Administrator-only reports and confidential assumptions are re-checked server-side on every request.

• Passwords are stored only as salted hashes by the authentication provider.
• Sign-in and password-reset messages are deliberately generic so accounts cannot be enumerated.
• Repeated failed sign-ins for the same address are throttled.
• Sessions expire and refresh automatically; signing out clears cached data.

All traffic is served over HTTPS with HSTS. The application sets a Content Security Policy, frame protection, a strict referrer policy, MIME-type sniffing protection, and a restrictive permissions policy. Sensitive values are never placed in URL parameters.

No file uploads and no storage buckets exist, so there are no publicly reachable user files. The application processes no payment data and no artificial-intelligence services are used.

Sign-ins, administrative changes, deletions, and privacy-request activity are recorded in an audit log readable only by administrators. Logs never contain passwords, tokens, or payment data.

Please report suspected vulnerabilities to tyler@trinitymsg.com. Include the steps to reproduce and do not access or modify data that is not yours. We ask that you give us a reasonable opportunity to remediate before public disclosure.