Security at Felarity.

A summary of the controls that protect every audio chunk, transcript, and report inside Felarity. This page describes the controls as deployed today; where a control is on a roadmap, we say so plainly.

Last updated: June 7, 2026

1. Encryption

All data at rest in Felarity — meeting transcripts, audio chunks, session reports, contradiction records, speaker samples, and database rows containing identifiers — is encrypted using Fernet (AES-128 in CBC mode with HMAC-SHA256 authentication). Keys are held in a runtime secret store and rotated on a documented schedule; ciphertext at rest is bound to a key version so rotated keys can be retired without re-encrypting historical data in bulk.

All data in transit is protected with TLS 1.3. Public endpoints terminate at Cloudflare's edge, then re-encrypt to nginx on the application host. We disable legacy protocols (TLS 1.0, 1.1) and weak ciphers; HSTS is enforced with a 12-month max-age and includeSubDomains.

Customer-managed encryption keys (BYOK), where the customer's KMS holds the data-encryption-key wrapping key, are on the roadmap for Enterprise customers and are available Q4 2026. Customers who require BYOK before that date should contact us — we will document the operational constraints honestly rather than promise a date we cannot meet.

2. Access control

Authenticated sessions are bearer tokens stored in Redis with a 30-day TTL and a sliding refresh on each authenticated request. Tokens are bound at issuance time to a single user identity and workspace; the binding is the authoritative source of truth.

Workspace isolation is enforced server-side on every request. Any workspace ID supplied by the client is checked against the authenticated user's binding and overridden if it does not match. There is no path by which a client can request data outside the workspace it is authenticated into.

Database roles follow least privilege. The application connects with a role that has no DDL rights and no access to schemas outside its own. The audit ledger writer holds an INSERT-only role on its target table (see section 4). Backup processes use a separate read-only role.

Engineering access to production is mediated by a single jump host. Operators authenticate with a hardware security key (FIDO2/WebAuthn) plus a second factor. Full session recording is enabled on the jump host; recordings are retained for one year.

3. Authentication and MFA

End-user authentication today is via Google OAuth. For paid tiers we offer TOTP-based MFA, with recovery codes generated at enrollment and a documented recovery path that does not weaken the second factor.

For Enterprise customers we support SAML 2.0 single sign-on against Okta, Microsoft Entra (formerly Azure AD), and Google Workspace. Just-in-time provisioning and SCIM 2.0 lifecycle (create, update, deprovision) are available on request. SSO and SCIM are configured per workspace; trial and personal accounts are not affected.

4. Audit logging

Security-relevant events are written to a hash-chained WORM ledger. Each entry contains the event type, actor, target, timestamp, and a SHA-256 hash of the previous entry; tampering with any historical entry invalidates every entry after it. Logged event types include sign-in and sign-out, role and permission changes, report export, report deletion, refund issuance, and billing plan changes.

The ledger writer holds an INSERT-only database role; no application code path can update or delete past entries. A public endpoint, /admin/audit/verify, recomputes the hash chain end-to-end and reports the first break, if any. Workspace administrators see verification status in the trust panel of their workspace.

5. Cryptographic attestation

Every Felarity report — the artifact produced by the 11-stage post-session pipeline — is accompanied by an 8-node SHA-256 Merkle chain covering the audio manifest, transcript, diarization, contradictions, NLI scores, topology, council synthesis, and report body. The chain root is signed with an Ed25519 private key held in a runtime secret store.

The corresponding public key is published at /.well-known/felarity-signing-key.pem. A standalone verifier is exposed at /api/verify: any party in possession of a report (including parties outside your organization, such as opposing counsel or a regulator) can confirm that the report is unmodified and was produced by Felarity. Key rotation is documented in our cryptographic key registry; rotated public keys remain published indefinitely so historical reports remain verifiable.

6. Network and infrastructure

Public traffic enters through Cloudflare, which provides WAF rules tuned for our endpoints and DDoS protection at L3, L4, and L7. The origin is nginx, which terminates the Cloudflare tunnel and proxies to Flask running on gevent workers. Internal services — Postgres, Redis, the inference gateway, the forensic pipeline, the speaker-diarization service — live on LAN-only network segments with no public ingress; access is via the application host only.

Secrets (database passwords, signing keys, API tokens, third-party credentials) live in a runtime secret store. They are not committed to source control, not present in environment files in production images, and not readable from application logs.

7. Data loss prevention

For workspaces in regulated industries (healthcare, legal, finance, government) we run Presidio-based PHI and PII detection on both inbound and outbound traffic. Matches — names, MRNs, account numbers, SSNs, addresses, phone numbers, custom patterns — are redacted before the text reaches the model and before any response is shown to the user. For environments where Presidio is not installed we fall back to a regex pattern library covering the same categories with reduced recall.

The DLP layer is configurable per workspace. Administrators can add custom patterns, allowlist specific terms, and review redaction events in the audit ledger.

8. Vulnerability management

Application and infrastructure dependencies are pinned in requirements.txt and equivalents. We run pip-audit weekly against the pinned set; high and critical CVEs are remediated on a documented timeline (24 hours for critical with known exploitation, 7 days for high, 30 days for medium).

A third-party penetration test against the application and its public surface is scheduled annually; the next test is scheduled for Q3 2026. Summary findings and remediation status are available under NDA to Enterprise customers on request.

Coordinated disclosure of vulnerabilities by external researchers is handled through /trust/responsible-disclosure/. We commit to acknowledging reports within two business days and to crediting reporters in our changelog when they so wish.

9. Backups and disaster recovery

Postgres is backed up nightly via pg_dump in custom format, plus continuous WAL archiving for point-in-time recovery. Encrypted session storage (audio chunks, transcripts, reports) is rsync'd nightly to a peer host on a separate physical machine. Both targets receive the data; neither is the single point of failure.

Retention is 30 daily snapshots plus 12 monthly snapshots. Snapshots are encrypted before they leave the primary host. Backup integrity is verified by a nightly hash manifest; a quarterly restore drill exercises the recovery path end to end.

On the standard tier we target an RPO of 24 hours and an RTO of 4 hours. Enterprise customers can contract tighter objectives — typically RPO 1 hour and RTO 1 hour — backed by warm standby and PG streaming replication.

10. Incident response

We operate a 24/7 on-call rotation. A first responder triages within one hour of detection, classifies severity, and engages the incident commander if the event is material. Affected customers are notified within 72 hours of confirmation of a material incident, with subsequent updates as the investigation progresses and a written post-incident report once the matter is closed.

Our incident-response runbook covers detection, containment, eradication, recovery, customer communication, regulator notification where applicable, and post-mortem. Runbooks are reviewed and exercised on a tabletop basis twice a year.

11. Personnel

All engineers undergo background checks at hire, commensurate with applicable law. Security training is delivered on hire and refreshed quarterly, with topics drawn from the OWASP top ten, secure-by-default patterns specific to our stack, and incident-response drills.

Access to production systems is granted on the principle of least privilege and reviewed quarterly. Joiners receive only the access required for their role; movers have their access re-baselined; leavers have all access revoked within one business day of separation.