Security claims should be specific, qualified, and tied to evidence.

Security approach

Vocalis uses layered product, application, workspace, provider, and operational controls where they are implemented and evidenced. Controls continue to evolve with the service.

This overview is intentionally high level. It does not disclose sensitive defensive architecture or promise that any system is risk-free.

Authentication and account access

Authentication is handled through the configured Supabase authentication service. Product routes require authenticated sessions where appropriate, and backend APIs verify the authenticated user before protected actions.

Users are responsible for protecting their sign-in methods and promptly removing workspace or integration access that is no longer authorized.

Workspace isolation and authorization

Product services apply workspace-scoped authorization and role checks for protected operations. Database policies and application checks are used where implemented to limit access to authorized workspace data.

The presence of RBAC or row-level policies in one area is not presented as proof that every historical or administrative path has identical controls.

Provider credentials and OAuth

OAuth access and refresh credentials are encrypted before persistence using an environment-specific encryption key. Public account projections remove known secret-bearing metadata.

OAuth authorization state is signed, short-lived, and replay-controlled in the audited publishing flow. X and YouTube include governed refresh/rotation handling.

Development, testing, and operational evidence

Software changes are subject to automated unit, integration, browser, type, lint, build, and evidence checks across product areas. Billing and publishing release checks preserve environment boundaries and secret-safe results.

Internal development evidence is not the same as an independent security certification, penetration-test result, availability commitment, or Production assurance.

Security questions and vulnerability reporting

Send suspected vulnerabilities or security concerns to [email protected]. We aim to acknowledge normal enquiries within 2 business days, but this is not a contractual response or resolution SLA.

Describe the affected surface and potential impact without disrupting the service or accessing another customer’s data. Do not include passwords, access credentials, exploit payloads, or unnecessary personal data in the first report.

Claims we do not make

• No unsupported security or privacy certification.
• No guarantee of uninterrupted availability or absolute security.
• No public bug bounty or contractual vulnerability-response SLA.
• No blanket claim that every category of data is encrypted in every context.
• No claim that Development evidence is equivalent to Production certification.