Book a walkthrough

Draft for counsel review. Not in force.

TrueSit security overview

Version 0.1, 2026-10-11. How TrueSit protects recordings and data, for buyers’ security reviews. Where a measure is planned rather than in place, it says so. Report a security issue to security@truesit.ai.

1. Recordings, from the phone to storage

  • The phone encrypts each piece of a recording (AES-GCM) as it is written, with a key held in the phone’s secure keystore (Android Keystore, iOS Keychain).
  • Pieces upload over TLS through short-lived signed links, with a checksum each, and are checked before processing.
  • Storage is private and encrypted at rest. Each file is readable only through the database rules for the sit it belongs to.
  • Recordings stay on the phone until they upload, so an outage on our side does not lose a sit.

2. Access control

  • Every database table has row-level rules. Each organization’s data is kept apart; a rep reads only their own sits; managers and admins read their organization’s.
  • The rules call helper functions the apps cannot call directly. Functions are closed to anonymous use and check the caller’s role inside.
  • Managers cannot delete, download or export. Downloads and exports are for org admins only, through short-lived links, and each is logged.
  • Rep private notes, Mentor memory and voiceprints are never readable by managers or admins. No app role can read a voiceprint.

3. Staff access

  • Only listed platform staff reach the console, with two-factor sign-in (an authenticator app) required before anything opens. Anyone else gets “not found”.
  • The console reads and writes only through server functions no client role can call.
  • Viewing as a user is read-only, lasts at most 30 minutes, needs a typed reason, and is logged; the organization’s admins can read that log. Recordings play there only with an org admin’s grant for that sit.
  • AI support tools propose; staff approve. Nothing is sent to a customer and no account is changed without approval, except an acknowledgement and a resolved mark the platform owner may allow.

4. Logging

  • An append-only audit log records sensitive actions: listens, exports, downloads, deletions, seat and role changes, settings changes, retention runs and voiceprint destruction. Org admins read it in Settings.
  • A separate log records every staff console action.

5. Application security

  • The web dashboard sends a content security policy with a fresh script nonce per request, HSTS, frame denial, and strict referrer and permissions policies.
  • Every public route is rate limited per client.
  • API tokens are shown once and stored only as hashes. Webhook secrets are kept out of reach of any app role. Outgoing webhooks are signed and never sent to private addresses.
  • Inbound CRM webhooks are signed per organization and refused outside a five-minute window.

6. AI providers

Speech and AI providers receive only what each step needs, under contracts that bar training their own models on customer data. The rep’s voiceprint is made and matched on our own servers with our own model; no outside provider receives it. The help assistant reads only public help articles.

7. Development practices

  • A pre-commit check refuses committed secrets, and the full history is scanned.
  • Dependencies are pinned and checked for known advisories; a high or critical advisory fails the check unless it has a written exception.
  • Database access rules are tested per role, and a mutation check breaks each rule in turn to prove a test catches it.
  • Production keys live only in the hosting providers’ secret stores.

8. Availability and backups

  • The processing queue retries failed jobs with backoff and keeps failures for review; a failed sit can be processed again.
  • A nightly copy of the recordings bucket goes to a separate provider (Cloudflare R2), and deletions reach it. This is configured in the keys round, before launch.
  • Database backups are taken by our database provider.

9. Incident response

We keep a written plan: detect, contain, assess, notify, fix, review. We notify affected organizations without undue delay and within 72 hours of confirming a breach of their data, and help them meet their own duties.

10. Data location and retention

Customer data is stored in the United States. Retention and deletion follow the public schedule (truesit.ai/legal/retention); deleted data leaves backups within 30 days.

11. Audits and testing

  • An outside penetration test before general availability: planned, not done.
  • An independent security audit (SOC 2): on the roadmap; no report exists yet.
  • Security questionnaires: answered on request, once a year per customer.

12. Reporting a vulnerability

Write to security@truesit.ai (security.txt at truesit.ai/.well-known/security.txt). We acknowledge within 3 business days, keep you informed, and do not pursue good-faith research that avoids privacy harm, data destruction and service disruption.