Security
How QSentia handles your data
This page documents our current security controls, what is in progress, and what we have not yet built. We do not overclaim. Every status below reflects the actual state of the platform.
Encryption
How data is protected in transit and at rest.
TLS 1.2 / 1.3 in transit
All traffic between clients and QSentia is encrypted via HTTPS. Enforced at the Vercel edge — no plain-HTTP fallback.
AES-256 encryption at rest
All production data persisted in Supabase (PostgreSQL) is encrypted at rest by default using AES-256. This is a platform-level guarantee from Supabase/AWS.
Secure cookie flags
Session cookies are set with HttpOnly and Secure flags. SameSite policy is enforced to mitigate CSRF exposure.
Authentication and access
How users and services are verified and what they can reach.
Supabase Auth (OAuth + email)
Authentication is handled by Supabase Auth. Passwords are never stored in plaintext — Supabase uses bcrypt hashing internally.
Protected route middleware
Next.js middleware enforces session validation on all authenticated routes. Unauthenticated requests are redirected before page content is served.
API key hashing
Platform API keys are stored as hashed values. The raw key is shown once at issuance and never retrievable again.
API key rotation and revocation
Key rotation and instant revocation endpoints are in active development. Admins can currently revoke keys via the back-office panel.
Role-based access control (RBAC)
Distinct access tiers (admin, platform user, read-only investor) are in design. Supabase Row Level Security policies are being mapped to these roles.
Row Level Security (RLS) on all tables
Supabase RLS is enabled on production tables. Full policy coverage across all data models is being completed.
MFA / 2FA
Multi-factor authentication support is on the roadmap. Planned via Supabase Auth MFA (TOTP).
Data handling and residency
Where data lives, how long it's kept, and who it's shared with.
Data residency
QSentia's Supabase project is hosted in the AWS ap-south-1 (Mumbai) region. All user and platform data resides within India.
DPDP Act (India) baseline
Data handling practices are aligned with India's Digital Personal Data Protection Act 2023. See the DPDP readiness page for detail.
Data retention policy
User account data is retained for the duration of the active relationship. On account deletion, personal data is purged within 30 days. Model telemetry logs follow a 90-day rolling retention.
Third-party data sharing
QSentia does not sell or rent user data. Data is shared only with infrastructure providers (Supabase, Vercel) under contractual data processing agreements.
API key lifecycle
How platform keys are issued, scoped, stored, and revoked.
Key issuance
API keys are admin-issued and scoped by entitlement tier. Each key maps to a specific set of endpoint permissions.
Key storage
Keys are stored as hashed values only. QSentia staff cannot retrieve a key after issuance.
Rate limiting
Preview and demo endpoints are rate-limited per client session. Production endpoint rate limits are being formalised.
No client-side key exposure
Private tokens are never included in browser-side code. All sensitive API calls are proxied server-side via Next.js API routes.
Webhook signing
HMAC-signed webhook payloads are on the developer roadmap.
Operational security
Incident response, audit logs, vulnerability management, and certification roadmap.
Incident response policy
A documented incident response process is in place. Affected users are notified within 72 hours of a confirmed breach, consistent with DPDP obligations.
Audit log exports
Structured execution and access audit logs are available in the dashboard. Downloadable export as CSV is in active development.
Dependency vulnerability scanning
GitHub Dependabot alerts are enabled on the production repository. Critical CVEs are reviewed within 5 business days.
CI/CD pipeline security
GitHub Actions CI runs on pull requests. Secrets are stored as encrypted GitHub Actions secrets — never hardcoded in source.
SOC 2 Type I audit
QSentia does not currently hold SOC 2 certification. We are building toward a Type I audit. Target scope: Q4 2026.
Penetration testing
Third-party penetration testing is planned prior to institutional launch.
Responsible disclosure
If you discover a security vulnerability in QSentia, please report it to us before disclosing publicly. We will acknowledge receipt within 2 business days and aim to resolve confirmed issues within 14 days.
admin@qsentia.comLast reviewed: June 2026 · This page is updated when control status changes. For compliance documentation, see the compliance centre. For data privacy, see the privacy policy.