Security Overview
Placeholder draft · Last updated 21 August 2026
Placeholder draft — this document has not yet completed legal review and is not legal advice. Final text must be reviewed before client contracting.
1. Sign-in
Authentication is handled by Supabase Auth. Sign-in methods are password and — where configured for the deployment — magic link and Microsoft single sign-on. Optional multi-factor authentication (TOTP) is available for user accounts and is applied at the application level; it is not yet a condition of database-level access. Session tokens are held in browser memory only and are not persisted to local storage or cookies.
2. Tenant isolation
PostgreSQL Row-Level Security (RLS) is designed to act as the tenant-isolation boundary, with database policies intended to scope customer records to the signed-in user's tenant. Application records carry per-tenant scoping, and access within a tenant is further narrowed by roles and permissions. An internal tenant-isolation verification suite runs in continuous integration on every change, and verification suites have been run against the live database as schema changes land, with the tenant-isolation and permission checks passing at the time they were run. Verification is repeated per environment, and formal evidence accompanies customer contracting rather than this page.
3. Auditability
The product maintains a structured audit-support trail of who did what, when, across escalation records; in the hosted deployment, audit events are recorded server-side in an append-only operational store, with actor identity and timestamps bound at the server. Data exports are permission-gated and audited.
4. Application hardening
The application is served with a Content Security Policy and related security headers (frame denial, content-type protection, referrer policy). Uploaded attachment files are stored as file content in object storage that is designed to be private, with uploads and downloads mediated by the application through short-lived signed access rather than public URLs, and download access following record read access. Uploads are limited by size and file-type restrictions and are not currently scanned for malware.
5. AI and customer data
OgmaQ's customer-facing product currently has no AI functionality. OgmaQ does not process customer tenant data through AI providers, no AI vendor is currently a subprocessor of customer tenant data, and customer workspace content is not used to train AI models. Any future customer-facing AI-assisted functionality would require separate documentation, configuration, customer-facing disclosure and review before being enabled. Internal company tooling used outside the customer-facing product is separately scoped and controlled, and does not involve customer tenant data.
6. Program status
OgmaQ's security program is under active development toward first-client readiness. We do not currently hold, and do not claim, third-party attestations such as SOC 2 or ISO 27001. This page describes the design honestly rather than making assurance claims.
7. Reporting a vulnerability
If you believe you have found a security issue, please tell us — see the responsible disclosure policy. Security reports: security@ogmaq.com (hello@ogmaq.com also reaches the same team). Machine-readable details are published at /.well-known/security.txt.