Core commitment: Construction procurement documents contain commercially sensitive bid data, contract terms, and vendor pricing. We designed Levlr's architecture specifically so that documents are never written to persistent storage — not to a database, not to a file system, not to a log. They exist only in server memory for the duration of the analysis request.
This page describes the technical and organisational security measures we have in place across Levlr's infrastructure, application layer, and third-party integrations. We update it as our controls evolve.
All communication between your browser and Levlr's servers is encrypted using TLS 1.3. Older TLS versions (1.0, 1.1) and weak cipher suites are disabled. HTTP requests are automatically redirected to HTTPS. Our TLS configuration targets an A+ rating on SSL Labs.
Communication between Levlr's serverless functions and third-party APIs (Gemini, Supabase) is also over TLS 1.3 on dedicated HTTPS connections. No document data is transmitted over unencrypted channels at any point.
Account data, saved analysis sessions, vendor records, and project metadata are stored in Supabase (PostgreSQL), which encrypts all data at rest using AES-256. Database backups are also encrypted.
Supabase enforces Row Level Security (RLS) policies on every table. All queries are scoped to the authenticated user's ID — it is not possible for a query to return another user's data, even with a valid session token.
We do not store documents, bid files, contracts, invoices, or any uploaded content. These are processed entirely in server memory and never written to disk or database.
Documents are processed in memory only. The lifecycle of an uploaded document is: receive over TLS → load into RAM → extract text → send to Gemini API over TLS → discard. No file write operations occur at any point in this pipeline.
Specifically:
The only external service that receives document content is the Google Gemini API, which processes the text under Google's API data processing terms. Those terms prohibit Google from using API-submitted content to train models. See Google's policy at ai.google.dev/gemini-api/terms.
After the Gemini response is returned, the analysis result is either displayed in your browser session or saved to your account (if you choose to save it). The original document is never retained.
Levlr's Gemini API key is stored exclusively as a server-side environment variable in Vercel. It is never exposed to the browser, never included in client-side JavaScript, and never logged.
All AI analysis requests from the browser are routed through /api/gemini — a server-side proxy function that authenticates the request against Supabase, then forwards it to the Gemini API using the server-stored key. The raw API key is unreachable from the client under any circumstances.
Supabase credentials used server-side follow the same pattern: environment variables only, never bundled into client code.
Authentication is handled by Supabase Auth, which uses industry-standard JWT (JSON Web Token) sessions. Passwords are hashed using bcrypt and never stored in plaintext. We do not have access to your raw password at any time.
Session tokens are short-lived and are validated server-side on every API request. Expired or invalid tokens are rejected with a 401 response — no document processing occurs without a valid authenticated session for paid features.
We plan to add support for SAML SSO and hardware security key (WebAuthn/FIDO2) authentication for Team and Enterprise accounts in a future release.
Levlr is deployed on Vercel's edge infrastructure, with compute distributed across Vercel's global edge network. Static assets are served from Vercel's CDN. Serverless functions run in isolated V8 isolates with no persistent state between requests.
Our database runs on Supabase, hosted on AWS US-East-1. Supabase provides automated daily backups with point-in-time recovery, and maintains its own SOC 2 Type II certification.
Infrastructure dependencies:
Levlr is currently undergoing a SOC 2 Type II audit covering the Trust Services Criteria for Security, Availability, and Confidentiality. We expect to complete the audit and publish the report in Q3 2026.
In the meantime, our current controls are designed to meet SOC 2 requirements:
Enterprise customers who require a current third-party attestation should contact us at security@levlr.io to discuss our interim security documentation.
The following third-party services process data on Levlr's behalf:
We review sub-processors annually and will update this list when sub-processors change. Material changes are communicated to registered users by email with 30 days' notice.
We maintain a documented incident response plan covering detection, containment, eradication, recovery, and post-incident review. Key commitments:
Because documents are never stored, a database breach would not expose document content — only account metadata (email addresses, analysis result text, and project names).
We conduct annual penetration tests of Levlr's application and infrastructure. Tests cover OWASP Top 10 vulnerabilities, API authentication bypasses, injection attacks, and privilege escalation paths.
The most recent test was conducted in February 2026. No critical or high-severity findings were identified. Medium-severity findings were remediated within 14 days. Enterprise customers may request a summary of findings under NDA by contacting security@levlr.io.
We welcome reports from security researchers. If you discover a vulnerability in Levlr's application or infrastructure, please report it to security@levlr.io.
Our disclosure policy:
Please do not access, modify, or exfiltrate user data during testing. Test against your own account only.
For security reports, vulnerability disclosures, enterprise security questionnaires, or to request our penetration test summary or SOC 2 documentation:
For general privacy questions, see our Privacy Policy. For terms of use, see our Terms of Service.
Levlr · levlr.io · Security · Last updated March 13, 2026