Loka Note handles confidential conversations, and we treat the security of that data as a first-class product feature. The summary below outlines the controls we have in place today — encryption in transit and at rest, per-tenant database isolation, audited admin operations, and a published disclosure channel. For our full Data Processing Agreement, see the DPA page.
Loka Note runs on enterprise cloud infrastructure operated by Vercel (application hosting and edge network) and Supabase (Postgres database, authentication, and storage). Both providers maintain SOC 2 Type II attestations, ISO 27001 certifications, and 24/7 monitoring of the underlying platform. We deploy from a single source-controlled trunk gated by automated CI checks, and every production deploy is traceable to a specific commit and author through our version control and deployment logs.
Every connection between your browser, our application, and our backend uses TLS 1.2 or higher with modern cipher suites. The marketing site enforces HTTP Strict Transport Security with a two-year max-age and HSTS preloading, so browsers refuse plaintext connections to lokanote.com even before they reach us.
All meeting recordings, transcripts, summaries, and account data are encrypted at rest by the underlying cloud platforms. On top of that platform layer, we apply application-level envelope encryption to your most sensitive meeting content: transcripts, AI summaries, action items, key topics, your notes, and the search embeddings derived from them are encrypted with AES-256-GCM under a unique data-encryption key per user. Each user's key is itself wrapped by a key-encryption key held in Google Cloud KMS — the key material never leaves the KMS boundary, and every wrap and unwrap is recorded in Cloud Audit Logs. The practical effect is that a stolen database dump yields only ciphertext; decrypting any account's content requires a separate, audited call to KMS that we control. Sensitive third-party credentials such as Google OAuth refresh tokens are likewise encrypted at the application layer with AES-256-GCM using a key that lives outside the database, so they cannot be replayed without the application key. This is defense-in-depth for stored data, not end-to-end encryption: transcription and AI features still process your content in plaintext in memory, so the risk we close is the theft of data at rest rather than the processing itself.
Loka Note is multi-tenant, and isolation is enforced at the database level by Postgres row-level security. Every tenant-scoped table carries policies that pin reads and writes to the authenticated user. Service-role keys that bypass RLS stay server-side and are never exposed to browser code, and elevated SECURITY DEFINER routines are revoked from anonymous and authenticated roles so they can only be invoked from server helpers we control.
We authenticate users through Supabase Auth, which validates session JWTs server-side via getUser() on every protected request rather than trusting cookies alone. Sign-in supports email/password and Google single sign-on, with optional two-factor authentication (TOTP) that is mandatory for administrators. Repeated failed sign-ins trigger a temporary account lockout enforced inside Supabase Auth, so it cannot be bypassed by calling the auth API directly. Admin operations are gated by an explicit ADMIN_USER_ID pin, and admin actions write to admin_audit_log with the actor, the affected user, and the action payload.
We track the OWASP Top 10:2025 as our baseline control map. Mutating API requests enforce same-origin checks, request bodies are validated with Zod, and webhook payloads are verified with constant-time signature comparison. The authenticated application enforces a nonce-based content security policy with no inline scripts; static marketing pages use a hardened CSP without per-request nonces, since they render no user-controlled content. CSP violations are reported to a dedicated endpoint so we see drift before users do. Authenticated mutation and AI endpoints are protected by per-user rate limiting, and a weekly automated dynamic-analysis (DAST) scan runs in CI against our preview environment.
Security-relevant events are written to a dedicated security_events table — forbidden-access attempts, webhook signature failures, cron bearer-token mismatches, rate-limit denials, and CSP violations. CSRF and same-origin blocks are recorded in our edge request logs. Administrative actions are written to admin_audit_log. Both tables are append-only from the application side and are reviewable by authorised staff. Application errors are captured by Sentry with PII scrubbed, and a component health-probe feeds our public status page at status.lokanote.com.
We use a small, carefully-vetted set of sub-processors: Vercel (hosting and edge network), Supabase (database, authentication, file storage), Google Cloud (audio transcription via Speech-to-Text, LLM summarisation and chat via Vertex AI Gemini, and encryption-key management via Cloud KMS), Polar (billing), our transactional email provider (account and notification email), PostHog (in-app product analytics — manual events only, never transcript or chat content), and Sentry (error monitoring with PII scrubbed). Customer audio is processed for transcription and summarisation only; we do not use customer data to train models.
You control how long Loka Note retains your meetings. Plan-based retention windows are enforced by scheduled cleanup jobs that purge expired recordings, and you can delete any meeting, recording, transcript, or your entire account from the dashboard at any time. Deletion requests propagate to storage within minutes. When you delete your account, we also destroy your per-user encryption key, which crypto-shreds your encrypted content — any residual ciphertext becomes permanently unrecoverable, even by us. Data exports are available on demand for portability.
We maintain an internal incident response runbook covering detection, containment, eradication, and customer notification. Material incidents that affect customer data are communicated to impacted customers without undue delay. Our responsible-disclosure contact is published at /.well-known/security.txt; we credit researchers who report verified findings.
If you believe you have found a security vulnerability in Loka Note, please email support@lokanote.com or use the disclosure contact at /.well-known/security.txt. Please give us a reasonable window to investigate and remediate before any public disclosure. We acknowledge reports within one business day and provide a status update within five business days.