Security Policy

Security approach

Twenty4 uses layered controls appropriate to SaysMee's current architecture. No internet service is perfectly secure, and this page does not claim certifications, audits, response times, or controls that have not been independently verified.

Controls implemented in the application

• Supabase authentication and row-level database policies isolate user-owned records where migrations are applied.
• Privileged database credentials remain in server-only environment variables and are not intended for browser bundles.
• API routes re-check authentication and resource ownership for protected operations.
• Layered local and shared database rate limits reduce automated abuse across server instances.
• Same-origin mutation checks, content-type enforcement, bounded request bodies, and server-side authorization reduce CSRF, parser, and resource-exhaustion risk.
• Private signed uploads bypass application request-size bottlenecks; server finalization verifies ownership, declared size, extension, and magic bytes before indexing.
• A Content Security Policy and related headers limit script sources, framing, MIME sniffing, referrer leakage, and unnecessary browser capabilities.
• Readiness checks, sanitized structured errors, CSP reports, and private security events support production detection without recording request bodies or credentials.
• Account deletion removes active user records and stored conversation files through a server-authorized workflow.
• Safety-event records contain no second raw prompt and are unavailable through normal client policies.

Provider and transport security

SaysMee relies on its hosting, database, storage, model, search, and email providers for parts of transport security, encryption, availability, and backup handling. Exact cryptographic versions and retention behavior depend on the deployed provider configuration. Twenty4 should verify those settings and provider agreements before launch rather than publish unsupported guarantees.

Operational requirements before launch

• Rotate any credential that has appeared in source, logs, screenshots, shell history, or shared files.
• Apply every production database migration and verify row-level policies with separate user accounts.
• Enable multi-factor authentication for hosting, Supabase, domain, email, and model-provider administrators.
• Connect the implemented sanitized error webhook to an owned alert channel, and test the incident-response runbook.
• Enable host-level WAF, bot, and volumetric DDoS controls; these cannot be supplied by application code alone.
• Run dependency, secret, authorization, upload, and abuse tests before each release and after material infrastructure changes.

Incident response

Suspected incidents should be triaged, contained, investigated, documented, and remediated. Credentials should be rotated when exposure is possible, and affected users or regulators should be notified when and within the period required by applicable law. Twenty4 does not promise a universal fixed notification deadline because legal duties vary by incident and jurisdiction.

Responsible vulnerability disclosure

Report a suspected vulnerability privately to support@saysmee.com with the subject "Security report". Include the affected URL, impact, reproducible steps, and a safe proof of concept.

• Do not access data that is not yours, degrade availability, use social engineering, or test third-party infrastructure without permission.
• Stop testing and report immediately if personal data or secrets become visible.
• Give us reasonable time to investigate before public disclosure.
• This policy does not create a bug bounty, payment promise, immunity, or authorization to violate law.

User security

• Use a unique password and secure the email account connected to SaysMee.
• Never paste passwords, recovery codes, private keys, or financial credentials into a chat.
• Review share links and uploaded files before sending them to others.
• Sign out on shared devices and report unexpected account activity promptly.