Security

1. Account protection

Existing — authenticated accounts are implemented, with role-based account metadata and server-side session validation.

Planned — full account-recovery policy, user-facing security event history and expanded abuse controls.

2. Passwords and authentication

Existing — email/password authentication with minimum password length enforcement, plus optional configured social login providers.

Planned — production recovery guarantees and final incident-response SLAs.

3. OAuth connection safety

Planned — live OAuth connections and secure token storage. The Drive scaffold includes state/PKCE handling interfaces, but no identity or token-store adapter is active and callbacks fail closed. The UI must not claim a connected Google account.

4. API-key protection

Planned — personal/service key issuance, rotation, revocation and audited access. No user API keys can be created today. Provider mappings are server-owned; they are not exposed as public model names or browser configuration.

5. HTTPS/TLS in transit

Production deployment should use HTTPS/TLS with secure transport settings. Local development or LAN environments may run HTTP and should not be treated as production-grade transport security.

6. Server-side secret storage

Existing — private provider environment mappings are read by server-only modules and are not intentionally returned in public model responses. This does not itself establish managed key-vault operations, rotation timelines or encrypted token-database guarantees.

7. Access control

Existing — server-side model validation, authentication checks for account routes, upload ownership validation, and origin checks on mutation routes.

Planned — finalized subscription entitlement enforcement for paid checkout flows and expanded account-resource authorization review.

8. Upload and file handling

Existing — file-size/type checks, attachment-count limits, owner-bound retrieval, and no direct serving of active HTML/SVG as attachments.

Planned — malware scanning, advanced file sandboxing and additional storage-hardening controls.

9. Sessions and devices

Existing — authenticated sessions are active for signed-in accounts. The attachment-owner cookie is not a login session.

Device inventory, remote sign-out controls and account-recovery guarantees require additional product work.

10. Monitoring and audit logs

Existing — operational logs are generated for request outcomes and selected provider usage metrics with safety-oriented sanitization.

Planned — formalized security-audit log policy, retention schedule and role-based log-access review.

11. Backup and recovery

Existing — users can export local chat history as JSON. Browser clearing and server restarts can remove some locally stored or temporary data.

Formal backup retention, restoration objectives and disaster-recovery commitments require BUSINESS INPUT REQUIRED and operational rollout.

12. Incident response

Planned — designated responders, response-timeline commitments and external incident-notification procedures. No guaranteed response-time SLA is claimed in this policy.

13. Responsible vulnerability reporting

Security contact: [email protected]. Do not probe other people’s data, disrupt service, or run unauthorized testing. No bounty, penetration-test authorization, immunity or response deadline is promised by this page.

14. User security recommendations

Keep your browser and device updated, use a trusted network, review files before uploading and avoid sharing passwords, API secrets or payment data in chat. Anyone with a shared conversation snapshot link may read its contents. Verify consequential AI advice independently and export important work.