Trust · Security

Security-first. from day one.

Last updated: October 3, 2026

Overview

Trueleveler's security page is a description of the technical and organisational security measures in place across its infrastructure, application layer and third-party integrations.

Core commitment: Construction procurement documents contain commercially sensitive bid data, contract terms, and vendor pricing. We designed Trueleveler so that a document you submit only to run an analysis is not written to persistent storage — not to a database, not to a file system, not to a log. The file exists only in server memory for the duration of that request. (The structured result is a different thing, and we set out exactly what happens to it under Document Handling.) Files you deliberately save to your workspace (the Documents area, Drawings, or engine PDFs you save) are a separate, opt-in path: they are stored in private, organization-scoped object storage, encrypted at rest and protected by row-level access controls, so you can use them again.

This page describes the technical and organisational security measures we have in place across Trueleveler's infrastructure, application layer, and third-party integrations. We update it as our controls evolve.

Data In Transit

All communication between your browser and Trueleveler's servers is encrypted using TLS 1.2 or higher. 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 Trueleveler's serverless functions and third-party APIs (AI provider, Supabase) is also over TLS on dedicated HTTPS connections. No document data is transmitted over unencrypted channels at any point.

Data At Rest

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.

Tenant isolation is enforced in two layers. First, Supabase Row Level Security (RLS) policies are applied to the application tables, so a query issued with your browser session token is constrained by the database itself to rows your organization owns — a stolen or tampered session token cannot widen that scope. Second, our server-side functions run with a privileged service credential that is not subject to RLS: those endpoints resolve your organization membership first and scope every query to it in code. That second layer is application logic, so we treat it as something to be tested and audited rather than something to promise is infallible: the org-scoping helper and the endpoints that use it are exercised by automated tests on every build, and access-control paths are a standing item in our security reviews and in the responsible-disclosure programme below.

Documents you submit only to run an analysis are not retained — they are processed entirely in server memory and not written to disk or database. Files you choose to save to your workspace are stored in a shared Supabase Storage bucket under organization-scoped Row Level Security and encrypted at rest; only members of your organization can access them, and you can delete them at any time.

Public notices, permit records, bids and awards. The Opportunities list also holds public information that we bring in from government sources: federal construction notices, building permits, and public construction bids and awards. It is stored in tables that only our servers can read (a browser cannot), and it is the same for every customer. Each organization’s own leads, and the notes and activity on them, are kept in tables of the same kind: a browser cannot read them either, and our servers limit every read and write to your organization in code, as described above. We do not keep the contact fields that these sources publish.

Document Handling

There are two distinct paths, and they are handled differently.

1. One-off analysis: the file is processed in memory and discarded. When you submit a document just to run an analysis, its lifecycle is: receive over TLS → load into RAM → extract text → send to AI API over TLS → discard. Specifically, for this path:

What is written on this path, so you know the whole picture: a run receipt (which engine ran, when, by whom, how long it took, token counts — no document content) is recorded for your usage meter and audit log. And the model's structured result is held in a short-lived server-side response cache, keyed by a one-way hash of the exact request, for up to seven days — so re-running a byte-identical analysis returns instantly instead of costing you another run. That cache holds the analysis output, never the source file, and it expires on its own. Engine runs inside a project are saved in that project's Engine History, most of them with their results, until you delete the project. We would rather state this plainly than claim that nothing at all is written.

2. Files you save to your workspace are stored, by design. When you upload a file to the Documents area, add a drawing set, or save an engine PDF to a project, you are deliberately filing it for later use, so we keep it in private, organization-scoped object storage (Supabase Storage), encrypted at rest and scoped by Row Level Security so only your organization can reach it. You can delete these files at any time, and they are removed when you delete the project or close your account. Retaining document text for cross-document search is a further opt-in, off by default, controlled by an organization owner in Settings.

The external services that receive document content are our AI inference providers (Anthropic and Google), which process the text under their API data-processing terms. Those terms prohibit the providers from using API-submitted content to train models.

After the AI response is returned, the analysis result is displayed in your browser session, saved to your account if you choose to save it, and held in the short-lived response cache described above. Engine runs inside a project are saved in that project's Engine History, most of them with their results, until you delete the project. Documents submitted only for one-off analysis are not retained.

API Key Management

Trueleveler's AI 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 a server-side proxy function that authenticates the request against Supabase, then forwards it to the AI 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

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.

Single Sign-On (SSO) via Google Workspace is available today — sign in with your existing corporate identity provider without managing a separate Trueleveler password. Microsoft 365 SSO and SAML SSO (Okta, Azure AD, OneLogin, generic SAML 2.0 identity providers) are on the roadmap for Business and Enterprise plans. Hardware security key (WebAuthn/FIDO2) authentication is also planned for a future release.

Infrastructure

Trueleveler is hosted on Vercel. Our application servers — Vercel serverless functions — run in Frankfurt, Germany (European Union, Vercel region fra1) and keep no persistent state between requests. Static assets are served from Vercel's global CDN, and the sign-in check in front of the app runs at Vercel's edge, in the location nearest the visitor. Vercel Inc. is a United States company.

Our database runs on a managed PostgreSQL service hosted in the European Union (AWS eu-central-1, Frankfurt). Automated backups with point-in-time recovery are maintained by the provider, which holds its own SOC 2 Type II certification. Sub-processor identity and exact region are disclosed in our Data Processing Agreement as required by GDPR Article 28.

Infrastructure dependencies:

SOC 2 Compliance

SOC 2 is on our roadmap. A formal SOC 2 Type II audit has not yet been engaged — we plan to initiate the audit as we scale, and our controls are already designed to meet SOC 2 requirements. Enterprise customers needing a security questionnaire response or a current controls overview today may contact hello@trueleveler.com.

Our current controls are designed to meet SOC 2 requirements:

Sub-processors

The following third-party services process data on Trueleveler's behalf:

Public lookup services the app calls: ipapi.co (which country you are in, once, from your browser; Kloudend, Inc., USA), open.er-api.com (currency exchange rates, from your browser; ExchangeRate-API, South Africa) and Open-Meteo (weather and place lookups for a project’s location, from our servers; OpenMeteo GmbH, Switzerland). Our servers also read public government sources, once a night, for the Opportunities list: SAM.gov (the daily file of public federal construction notices; U.S. General Services Administration, USA) and the open-data portals of cities and counties (public building-permit records, and public construction bids and awards; today the City of Los Angeles, the County of Los Angeles, Beverly Hills, Pasadena, Nashville, Columbus, Detroit, Louisville and the City of New York; USA). None of them receives any customer data.

Integrations you connect with your own account: DocuSign (e-signature) and Microsoft Outlook (a read-only mailbox connection). Your own agreement with each provider covers the data that goes through them.

The full list, with the data each service receives, is in our Data Processing Agreement. 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.

Incident Response

We maintain a documented incident response plan covering detection, containment, eradication, recovery, and post-incident review. Key commitments:

Because documents submitted for one-off analysis are not retained, a database breach would not expose that content — only account metadata (email addresses, analysis result text, and project names). Files you save to your workspace live in object storage protected by encryption at rest and organization-scoped Row Level Security, separate from the application database.

Penetration Testing

A third-party penetration test has not yet been engaged. We plan to commission an annual external penetration test alongside our SOC 2 Type II audit as we scale, covering OWASP Top 10 vulnerabilities, API authentication bypasses, injection attacks, and privilege escalation paths.

In the meantime, we run continuous automated vulnerability scanning via our dependency tooling and CSP violation reporting, and we welcome reports from security researchers under the responsible-disclosure policy below. Enterprise customers may request our current controls overview or security questionnaire response by contacting hello@trueleveler.com.

Responsible Disclosure

We welcome reports from security researchers. If you discover a vulnerability in Trueleveler's application or infrastructure, please report it to security@trueleveler.com.

Our disclosure policy:

Please do not access, modify, or exfiltrate user data during testing. Test against your own account only.

Security Contact

For security reports, vulnerability disclosures, enterprise security questionnaires, or to request our current security questionnaire:

For general privacy questions, see our Privacy Policy. For terms of use, see our Terms of Service.

Trueleveler · trueleveler.com · Security · Last updated October 3, 2026