Security

This page answers the questions that come up once a factoring company or a shipper starts running diligence on your operation: where your dispatch inbox goes, who can see it, what happens to it over time, and whether it trains AI models.

Every claim on this page is verified against our code and infrastructure. Where something does not exist yet, we say so instead of implying it. The Privacy Policy is the legal text; this page is the technical detail behind it.

Compliance posture

Freigent is not SOC 2 certified. SOC 2 Type II is on our roadmap. We will not mark a compliance box we cannot back with an actual audit report, and we will tell you where the audit trail stands when you ask.

What we can show in code today:

• Tenant isolation enforced by the database itself, not just by app logic. Every customer table is walled off with Postgres Row-Level Security keyed to your organization. See Tenant isolation below.
• The security boundary is version controlled and tested. The full RLS policy set is checked into git, scanned for over-broad policies, and exercised by an automated cross-tenant isolation test.
• AI and automation actions are audit logged to dedicated database tables, so there is a record of what the system did and why.
• Self-service deletion that scrubs personal data from the mobile app.

Items we handle individually rather than promise here: penetration test reports, cyber insurance certificates, backup and restore specifics, and SSO. Ask [email protected] and you will get a straight answer about what exists today and what does not.

Where your data lives

Traffic moves over TLS. Encryption at rest is handled by the managed storage providers above (Supabase on AWS, Backblaze).

Tenant isolation

Freigent is multi-tenant: carriers share the same platform, and isolation happens in the database. Every table that holds customer data carries an org_id, and Row-Level Security policies decide row by row who can read or write. Over 400 tables are RLS-enabled with over 800 policies, all resolving membership through a get_user_orgs(auth.uid()) lookup.

Here is the actual policy that governs who can read a dispatch email, from the version-controlled snapshot of our production policy set:

CREATE POLICY "View org emails" ON public."emails"
  FOR SELECT TO public
  USING ((org_id IN (SELECT organization_memberships.org_id
                     FROM organization_memberships
                     WHERE organization_memberships.auth_user_id = auth.uid())
          OR user_id = auth.uid())
         AND deleted_at IS NULL);

Rows you delete are hidden from the app immediately; physical removal from the database is the deferred purge job noted under Retention.

In practice: your people see your org's rows, and nobody else's. Even a bug in the web app cannot read another carrier's data, because the database itself refuses to return it.

The whole policy set is checked into git and guarded by two automated gates: a static scan for over-broad policies, and a dynamic test that signs in as a real user from one org and asserts they cannot read another org's rows.

Your dispatch inbox

What we request at connect time. OAuth with mail-specific scopes only. Gmail gets gmail.modify, gmail.send, and basic profile. Outlook gets Mail.Read, Mail.ReadWrite, Mail.Send, and User.Read. We never see your account password, and mail scopes do not grant access to your other Google or Microsoft services. You can revoke access from your Google or Microsoft account settings at any time, which invalidates our tokens immediately.

Where your email lands. New mail reaches us by push: Google Cloud Pub/Sub notifies us for Gmail, Microsoft Graph notifications for Outlook. Messages are parsed and stored in our emails table, scoped to your org by the RLS policy above. Attachments are stored in a dedicated Backblaze B2 bucket. When you first connect an inbox we also run a historical sync of up to 2,000 existing messages so the AI has context.

Who reads it.

• Members of your organization, through the RLS-scoped app.
• Freigent's server-side AI agents, which classify inbound mail, draft replies, and run rate negotiation and booking workflows against it. Attachment parsing (rate confirmations, carrier packets) only runs if you ticked the consent box at connect time; without it the parser skips your mail explicitly.
• The AI providers listed in the sub-processor table below process what those agents need at inference time.
• Freigent personnel can reach production data for support and operations. That access is not yet governed by formal role-based access control or SSO; it is on the same roadmap as SOC 2, and we state it plainly rather than imply a control we have not built.

What leaves your outbox. AI-drafted replies are sent from your connected mailbox, so threads stay in your email history, not ours. Mail sent from freigent.ai addresses goes through Freigent-managed delivery services listed below.

Retention and deletion

• We keep your data while your account is active. There is no automatic purge window today; formal retention windows with an automated purge job are on the roadmap, and we will confirm dates before promising them.
• Email bodies are tiered to control database size: after a hot window, a body is uploaded to Backblaze B2, read back and verified, and only then is the database copy cleared. A short snippet and a storage pointer remain so search still works.
• You can archive and delete email in the app; deletion goes through an RLS policy that only ever touches your own org's rows.
• Drivers can delete their own account from the mobile app. That flow nulls personal fields on the driver and user records (name, contact details), severs the app link, and removes the login, while keeping the historical rows your records depend on intact.
• A full-organization export or wipe is handled on request. Contact support and we will confirm scope and timeline with you directly.

AI processing and training use

Freigent does not train models on your data. There is no fine-tuning or training pipeline anywhere in our codebase. Your loads, emails, and documents are used at inference time only, to do the work you asked for.

• Text agents (workflow, rate negotiation, booking, compliance drafting) run on the OpenAI API. Under OpenAI's published API data usage terms, data submitted through the API is not used to train or improve their models.
• Voice calls: audio streams through the self-hosted LiveKit server we operate. Speech to text, the language model, and text to speech for voice run on Groq's API. Call recordings are stored in our Backblaze B2 account.
• We do not sell your data. See the Privacy Policy for the authoritative legal terms.

Sub-processors

The DAT and Truckstop Chrome extensions run in your browser against your own load board session. Load board credentials are yours, not ours.

Reporting a security issue

Email [email protected] with details. We will acknowledge the report and work a fix. We do not run a formal bug bounty program yet.