/ Trust — Security
Security and data handling.
How Helix isolates your data, what goes to the AI provider, and what does not. Every claim below maps to a real artifact in the codebase.
/ Isolation — Multi-tenant
Your data stays in your tenant.
Every table that holds customer data carries an org_id column and has PostgreSQL Row-Level Security (RLS) enabled. The RLS predicate is a membership lookup against the users table — not a JWT claim — so the isolation enforcement lives inside the database, not in application code.
Isolation is not asserted — it is tested. An adversarial two-org isolation proof attempts every read and write breach pattern across two fully provisioned orgs; any successful cross-tenant read raises an exception rather than returning data. The proof runs before every migration that touches a multi-tenant table.
/ Ingestion — Post-call only
Post-call. No real-time. No recording infrastructure.
Helix ingests completed call transcripts — it does not join calls in progress, does not operate recording infrastructure, and does not stream or buffer live audio. Transcripts arrive after the call ends, via a webhook from your recording provider. There is no real-time or live-call surface anywhere in the platform.
This is an architectural fact, not a policy: the ingestion adapter layer is transcript-in only. The codebase contains no real-time or streaming code path.
/ Demo — Pseudonymized
Demo data is pseudonymized. Real data is never mutated.
Prospect demos show no real third-party PII. Demo data is a pseudonymized clone in a dedicated demo org — the source is never rewritten in place. A pseudonymization runner mints a fresh identifier for every cloned row and remaps all foreign keys, then replaces names and entities with a strictly 1:1 fictional substitution.
Source immutability is a tested invariant: the test suite asserts that source rows are byte-identical before and after a pseudonymization run. The demo org and the real org are kept strictly separate by the same RLS isolation described above.
/ CRM — Read-only
No CRM write-back.
Helix maintains its own local system of record and does not write back to any third-party CRM (Salesforce, HubSpot, or otherwise). There is no CRM write path in the codebase — this is a hard product guardrail, not a configuration option.
/ AI — Data handling
What goes to the AI provider.
Analysis is performed by calling Anthropic's API with the call's transcript and derived context. Anthropic is the model sub-processor.
Under Anthropic's Commercial Terms of Service (§B Customer Content), Anthropic may not train models on customer content from the commercial API. Customers retain rights to their inputs, and Anthropic assigns its interest in outputs to the customer. The authoritative statement is the linked Anthropic terms document; Helix does not independently guarantee Anthropic's commitments.
Transcript data is routed to the AI provider only for post-call analysis. It is not stored by Anthropic beyond what their commercial terms describe.
/ Auth — Identity
Identity and access.
Authentication in v1 is Google OAuth only — there is no password sign-in and no self-service sign-up. Team members join by invite only. Invite tokens are server-generated, 256-bit, and unguessable; only their SHA-256 hash is stored in the database.
A user's role (AE, Manager, CRO, Admin) is derived from a single cached authority per request. It is never read from a request body or client-supplied parameter — it always comes from the authenticated session.
/ Contact — Security questions
Questions about security?
Reach out directly. We will respond to every security question with a specific answer, not a generic policy statement.
chris@fdelabsai.com