Dual loyalty, by design.

Rep-private data the manager can never reach

Coaching observations, follow-up draft text, and the voice samples a rep opts in to share are rep-private. They are isolated at the database layer the same way: rep-self RLS policies only, no manager or aggregate policy, and no grant to the manager-aggregate database role. There is no join, view, or RPC that lets a manager read them — the data is simply not reachable by that identity.

• The rep's review-and-send page loads drafts with a user-context client, so RLS confines each draft to its owning rep.
• The manager dashboard runs entirely through the same user-context client — never the service role — so a manager only ever sees what RLS already permits.
• The manager-aggregate role holds SELECT on an enumerated list of team-visible tables only, and is explicitly withheld from rep-private columns and tables.

Encryption in transit and at rest

• All traffic is served over TLS (HTTPS) end to end.
• The managed Postgres database and its backups are encrypted at rest by the platform.
• HubSpot OAuth tokens are encrypted at rest with an application key before they are stored — the raw token is never persisted in plaintext.
• Rep phone numbers are encrypted at rest, with a separate keyed HMAC used only for inbound WhatsApp lookup so we can match a sender without storing a reversible index.

Least privilege and tenant isolation

• Every team's data is isolated by row-level security keyed to team membership; cross-tenant reads are denied by default.
• Privileged database functions are SECURITY DEFINER with a pinned search_path, gated by an active-membership check, and have EXECUTE revoked from anonymous and public roles — granted only to authenticated and service identities.
• Service-role write paths (CRM sync, ingest, delivery) validate team membership before any write.
• Sign-in uses Google, Microsoft, and email magic link via Supabase Auth; we never store passwords.
• Production data access is limited to personnel who need it for support, security, or engineering.

Your data stays in your systems

• CRM data lives in your HubSpot tenant, in native fields. We read what you authorize and write back deals and notes — we do not require mailbox access.
• Inbound webhooks are verified per provider: HubSpot request signatures and Twilio request signatures are checked before any handler runs.
• Internal cron and ingest endpoints require a bearer secret, compared in constant time.
• WhatsApp briefs are delivered only after explicit rep opt-in, and a STOP reply halts delivery.

How we build and operate

• All changes go through pull request review and a CI pipeline (type-check, lint, build, tests) before they ship.
• Database row-level-security behavior is covered by automated policy tests.
• Dependencies are kept current and patched on a regular cadence.
• Errors and delivery failures are monitored, with operational health checks and alerting on background jobs.
• Secrets live in the platform's encrypted environment store, never in source control.

We follow common SOC 2 / ISO 27001-aligned practices. We are not yet formally certified; Charter customers can request our current posture summary and security questionnaire.

Sub-processors

We use a small set of vetted sub-processors to operate the service. The authoritative list lives in our Data Processing Agreement.

• Vercel — Application hosting + workflow runtime
• Supabase — Postgres database + authentication
• HubSpot — CRM integration (your own tenant)
• Twilio — WhatsApp brief delivery
• OpenAI — Speech + language models (via our LLM layer)
• Resend — Transactional + digest email delivery
• Sentry — Error monitoring (optional, when enabled)
• Upstash — Distributed rate limiting (optional, when enabled)

Data retention and deletion

• Reps can export and delete their own account data from in-product tools.
• Withdrawing voice-drafting consent clears the stored reference messages.
• On account or team termination we delete or return customer personal data within a reasonable period, except where retention is required by law or for backup cycles (typically up to 30 days). Aggregated, anonymized metrics may be retained.

See our Privacy Policy for the full detail on what we collect and why.

Reporting a vulnerability

If you believe you have found a security issue, please email security@briefton.com with steps to reproduce. We will acknowledge your report, investigate, and keep you updated through to resolution. Please give us a reasonable time to remediate before any public disclosure, and avoid accessing or modifying other users' data while testing. We do not pursue good-faith researchers who follow this policy.