Security at VivList

    Last updated August 9, 2026

    VivList holds your team's projects, tasks, documents, and the work context around them. That makes us a target and makes your trust conditional. This page describes how the product is actually built and what is in place today. It deliberately does not list controls we have not implemented, and it does not claim certifications we do not hold.

    VivList is an early-stage product built and operated by a small team. If you are running a security review and need something this page does not cover, write to security@vivlist.com and you will get a specific answer rather than marketing copy.

    Architecture and tenant isolation

    • VivList is a multi-tenant application on managed PostgreSQL. Tenancy is enforced in a single shared schema using row-level security, not separate schemas or databases per tenant.
    • Row-level security is enabled on every application table, and every policy scopes rows to the authenticated user's identity (auth.uid()) through workspace ownership. Isolation is enforced by the database on every query, not by application code remembering to filter.
    • Client-side route guards only control what the interface renders. They are not the security boundary and we do not treat them as one — an API request with someone else's session returns only that session's rows.
    • Server-side code paths that need elevated privileges are limited and explicit: a small number of database functions run with elevated rights for administrative metrics, the public-form endpoint, and internal email queue processing. Each one checks the caller's role or scopes its own result set before returning data; privileged credentials are never available to browser code.
    • Today a workspace's data is reachable only by the account that owns it. Multi-user shared workspace access, and the role model that goes with it, is in development — the team directory in the product does not yet grant data access to other accounts.

    Encryption

    • In transit: all connections to vivlist.com and to our backend APIs are served over HTTPS with TLS 1.2 or higher. Plain HTTP is redirected.
    • At rest: the database, backups, and object storage are encrypted at rest with AES-256 by our managed infrastructure provider (Lovable Cloud, which runs the managed Postgres and object storage behind VivList on AWS infrastructure).
    • Key management: encryption keys for data at rest are generated, stored, and rotated entirely by that infrastructure provider. We do not hold or manage at-rest encryption keys ourselves.
    • Files and attachments: uploads go to a private object storage bucket that is not publicly readable. Downloads are served through signed URLs generated per request with a 60-second expiry. There are no permanent public links to customer files.
    • Application secrets and API keys are held in the platform's encrypted secret store and are read only by server-side code. No provider credential or AI API key is shipped to the browser.

    Authentication and sessions

    • Email and password sign-in plus Google sign-in, handled by a managed authentication service. Passwords are salted and hashed with bcrypt by that service; we never store, log, or have access to plaintext passwords.
    • Email addresses are verified before an account becomes usable, and password reset uses single-use, time-limited links.
    • Sessions use short-lived JWT access tokens (one hour) with refresh-token rotation. Tokens are held in browser storage rather than httpOnly cookies, and every API request is authorised server-side against the token's identity. Signing out revokes the refresh token.
    • Multi-factor authentication is not available today. It is on our roadmap; we would rather tell you that plainly than let its absence go unmentioned. Google sign-in lets you inherit MFA enforced on your Google account, which is currently the strongest option.
    • Leaked-password screening is applied at signup and password change, so credentials found in known public breach corpora are rejected.

    AI processing

    • AI features (writing assistance, chat, insights) are opt-in per action. Nothing is sent to a model provider unless you invoke one of those features.
    • Every AI call runs server-side through the Lovable AI Gateway, which routes to third-party foundation models (currently OpenAI and Google models). The API credential lives only on the server; the browser never talks to a model provider directly.
    • AI endpoints require an authenticated session. Unauthenticated requests are rejected with a 401, so nobody outside your account can drive inference on our behalf.
    • We do not train any model on your content, and we do not use it for any purpose beyond returning your result. Only the content needed for the request you invoked is sent — we do not ship whole workspaces to the model.
    • Model providers' own retention and training terms apply to the request they receive. We are documenting those terms per provider and will publish them here rather than paraphrase them; ask us at security@vivlist.com and we will send the current position for the exact feature you care about.

    Activity records

    The product records an activity history for tasks — creation, status, priority, assignee, due date, and title changes, with actor and timestamp — visible to the workspace owner. Authentication events are captured in our authentication provider's logs and are available to us for investigation.

    We do not yet offer a customer-facing audit log covering permission changes, membership changes, exports, and deletions, and we do not offer log streaming to a customer SIEM. Both are planned, and we are happy to discuss requirements if this is a gating item for you.

    Application security

    • Server-side input validation on API endpoints, with authorisation checked on the server for every data access rather than in the client.
    • Automated dependency vulnerability scanning runs against our lockfile, and an automated security scanner reviews database access policies for tables exposed without appropriate row-level security.
    • No third-party penetration test has been performed yet. We would rather say that than stay silent about it. If you need one to complete a review, tell us and we will discuss timing.

    Compliance status

    SOC 2 Type II is in progress. We do not hold a SOC 2 report today and will not imply otherwise; when a report exists it will be available under NDA and this page will say so with the report date.

    We are not currently able to publish a completed subprocessor list, ISO certification, or HIPAA/PCI attestation, so we are not claiming any. For a written answer on data processing agreements, data residency, or the third parties involved in delivering VivList, contact security@vivlist.com and we will respond with specifics.

    Data retention and deletion

    Customer data is retained for the life of the account. Deleting a project, document, task, or file removes it from production immediately; encrypted backups age out on our infrastructure provider's schedule. If you want your account and its data deleted, email security@vivlist.com or privacy@vivlist.com and we will confirm when it is done. Cancelling a subscription does not by itself delete your data — you keep access to your content under the free tier until you ask for deletion.

    Reporting a vulnerability

    We welcome reports from security researchers and will not pursue legal action against anyone who reports in good faith, tests only against their own account or data, avoids privacy violations and service disruption, and gives us reasonable time to remediate before disclosure.

    Send reports to security@vivlist.com. Our machine-readable policy lives at /.well-known/security.txt. We acknowledge reports within two business days and will keep you updated through remediation.

    Incident response

    We are a small team: a named engineer is reachable at all times and personally owns triage, containment, and communication for any security incident. If we confirm an incident affecting your data, we will notify affected customers by email within 72 hours of confirmation, with what we know, what we have done, and what you should do.

    Questions

    Security questionnaires, data processing agreements, and architecture calls: security@vivlist.com or book a call.