Security
Argon2id hashing, authenticated field encryption, hardware passkeys, and audited access. The technical foundation behind your financial data.
Last reviewed · reviewed on material architecture changes and at minimum annually
From password storage to data at rest, Convexity uses modern cryptographic primitives. No legacy algorithms, no compromises. The spec, by layer:
| Layer | Mechanism | Parameters |
|---|---|---|
| Password storage | Argon2id | time_cost=3 · memory_cost=64MB · OWASP-recommended, memory-hardened, GPU/ASIC-resistant |
| Sensitive DB fields | AES-256-GCM (authenticated encryption) | Per-deployment key derived from server-side secret. Legacy Fernet (AES-128) kept decrypt-only through the backup retention window |
| Transport | TLS + HSTS | All API + WebSocket, TLS 1.2 minimum (TLS 1.3 preferred). HTTP permanently redirected. HSTS on convexityos.com (includeSubDomains) and atava.ai |
| Access tokens | JWT, short-lived | 15-min expiry + DB-backed refresh tokens. Rotation on each refresh; replay revokes the whole family |
| Throttling | Tiered rate limits | Auth 5 / 5min · API 120 / min / IP · AI 30 / min |
| Legacy upgrade | Silent bcrypt → Argon2id | On next successful login. No user action required |
When we store your data, we scramble it. When it travels between your browser and our servers, we scramble it. Even our team can't read your password; we only check that yours matches. Six places it matters:
We never store your actual password. We store a one-way scrambled version that even we can't reverse, using a method specifically designed to be slow against attackers, even ones with fancy hardware.
Things like your authenticator-app secret and your linked-account access are scrambled with a key only our servers know. A stolen database without our servers would be unreadable for these fields.
Everything between your browser and our servers travels through an encrypted tunnel, the same kind your bank uses. We force this on every request. There's no insecure version to fall back to.
Sign-ins last 15 minutes and renew quietly in the background while you use the app. If somebody steals an active sign-in token, the renewal mechanism notices and revokes every related session.
We cap how many times anyone can try a sensitive action per minute. Brute-force attacks that would take seconds against an unprotected service take years against ours.
The next time you sign in, if your password is stored using an older scrambling method, we silently upgrade it to the latest. You don't have to do anything.
Three independent authentication factors plus Google SSO. Each layer adds protection without adding friction.
Memory-hardened hashing with OWASP parameters. Automatic upgrade from legacy bcrypt on login.
Time-based one-time passwords via pyotp. Works with Google Authenticator, Authy, 1Password, or any TOTP app.
Phishing-resistant FIDO2 authentication using hardware security keys or platform biometrics. Disclosed as a complete factor: a passkey login is sufficient on its own and does not require TOTP after enrollment.
CSRF-bound login flow. A signed state JWT is paired with an HttpOnly Secure SameSite=Lax nonce cookie; the callback rejects any state whose nonce does not match. Tokens never appear in the URL query string; they ride the URL fragment, which never reaches our access logs.
Database-backed sessions with automatic expiry. Revoke individual sessions or all active sessions from any device.
Append-only JSONL audit trail covering 30+ security event types: logins, MFA changes, password resets, session revocations, account modifications, and every require_admin action. Each entry carries prev_hash + entry_hash (SHA-256); any edit, deletion, or insertion breaks the next entry's chain on the next verify_chain walk. Concurrent writes serialize via threading.Lock + fcntl.flock so cross-process appends do not race.
Pick how you want to sign in. Each option is independent; using a stronger one doesn't mean giving up the others. The strongest options resist phishing entirely.
The basics. Stored using a method designed to be slow for attackers and is automatically upgraded over time.
Optional six-digit code from an authenticator app like Google Authenticator, Authy, or 1Password, the same kind your bank or email provider uses.
Optional. Use a YubiKey, Apple Touch ID, Windows Hello, or any modern device-built-in passkey. Resists phishing: you can't be tricked into entering it on a fake site. Once enrolled, signing in with a passkey is enough on its own; we don't also ask for your authenticator code, and we say so plainly.
One-click sign-in if you'd rather not manage another password. Your Google account does the verification on our behalf. We protect the round-trip with a one-time nonce so somebody can't trick your browser into signing you into a different account.
From any device, you can sign out one specific session, or sign out everywhere at once. Useful if you lose a phone or use a public computer and forget.
Every important account event (sign-ins, password resets, multi-factor changes, session sign-outs, every administrative action) is permanently recorded. Each row links to the previous one with a cryptographic fingerprint, so we'd be able to detect if anyone went back and edited or deleted history. Records are kept for 90 days at the system level.
Sensitive fields in our database are encrypted with AES-256-GCM using a per-deployment key. Encryption and decryption happen server-side. We never sell, share, or monetize your financial data.
We don't sell it, share it, or run an advertising business behind the scenes. You can take it with you. You can also delete it: fully, not "from view."
How we classify information, who is responsible for what, and which controls apply to which data. Effective 2026-04-17. Next review 2027-04.
| Domain | Control |
|---|---|
| Encryption | Argon2id for password hashing. AES-256-GCM for at-rest field encryption on restricted data. TLS 1.2 minimum (TLS 1.3 preferred) for all transport. Legacy Fernet (AES-128) kept decrypt-only through the backup retention window. |
| Access control | JWT-based session auth; tier-based RBAC enforced at middleware on every request. See access control policy below. |
| Authentication | Password + optional TOTP + optional WebAuthn for account holders. MFA available, not yet mandatory. |
| Logging & monitoring | Structured JSON logs with request-ID propagation. Sentry error tracking with PII scrubbed at the SDK layer. Hash-chained append-only audit log (SHA-256 prev_hash + entry_hash) covering 30+ security-sensitive event types plus every require_admin action; verify_chain(date) walks daily files for tamper evidence. |
| Webhook integrity | Plaid and Stripe webhooks signature-verified at the edge before any handler runs. Stripe events deduplicated via IntegrityError on BillingEvent.stripe_event_id; charge.refunded and charge.dispute.created handlers downgrade tier on chargeback. |
| Vulnerability management | Patching SLAs: Critical 72h, High 14d, Medium 30d, Low 90d. Continuous scanning via Dependabot, pip-audit, unattended-upgrades. Backend dependencies pinned to exact versions (122 packages locked via requirements.txt; direct deps with extras + floors live in requirements.in). Most recent internal review 2026-05-26: closed 22 findings (4 Criticals + 6 Highs + 12 Mediums) same day. Independent third-party penetration test scheduled before enterprise GA. |
| Data retention | Soft delete with 30-day recovery. Hard delete on request. Full policy: /privacy. |
| Third-party risk | Subprocessors disclosed publicly on this page. New subprocessors disclosed before data is shared. |
We have a written policy that says how we handle different types of information, who's responsible for what, and how often we review. Switch to Technical view above for the full policy text.
Every request is independently authenticated and authorized at middleware before any business logic runs. There is no "trusted internal network"; even our own services are verified the same way external ones are. Nine controls we actually enforce, then the ones we deliberately do not claim.
JWT access tokens expire in 15 minutes. No long-lived trust: if the token is stolen, the window for use is bounded by that ceiling.
tier_gate enforces RBAC on every protected route. Unauthorized requests receive 403 before the handler runs; no implicit privilege from session state alone.
Refresh tokens rotate on each use and carry an auth_chain_id. Replay of any token revokes the entire chain, past and future. A stolen refresh token does not survive the legitimate user's next refresh.
Logout writes the access JWT's jti to a Redis denylist for the remainder of its 15-minute lifetime. Closes the "active access token lingers after sign-out" gap.
Every audit row carries prev_hash + entry_hash (SHA-256). Any in-place edit, deletion, or insertion breaks the next entry's prev_hash check at verify_chain time. Cross-process appends serialize via threading.Lock + fcntl.flock.
Triggering a production deploy from the admin UI requires a fresh TOTP code beyond the active session. Session compromise alone is not sufficient to push code.
Login responses are timing-equalized: a dummy verify_password runs even when the user record does not exist, so response times cannot distinguish "no such email" from "wrong password." Waitlist signup returns the same generic response for new and duplicate emails.
Production secrets load from a root-owned env file at unit start. They never transit between processes in plaintext and are not readable from the application user account.
Application-layer rate limits on auth endpoints (5 / 5min). Host-layer fail2ban bans repeated SSH attempts with a journald-backed jail.
Many older systems had an "inside" and an "outside": the outside was checked carefully, but anything that got inside was trusted. We don't operate that way. Every action is checked, every time, regardless of where it came from. The big ideas, then a few smaller ones.
Each "I'm signed in" pass is good for 15 minutes. When your session renews, the renewal mechanism is designed to detect theft: if somebody steals your session and tries to keep it alive, the very next renewal trips an alarm that signs out every related session at once.
Every request is independently checked against your account permissions before it does anything. We don't assume you're allowed to do something just because you were a moment ago, and we don't carry "trusted" status anywhere on our side.
If the founder logs into the admin tool and asks to deploy new code, the active session isn't enough; the system asks for a fresh six-digit code from the authenticator app. We don't get a backdoor either.
Access to systems and data follows the principle of least privilege. Permissions are tier-based, enforced in application middleware, and granted only when required to deliver a specific feature. Scope covers user access to the application and operator access to the underlying infrastructure.
Single operator today (founder). Server access via SSH key-based authentication only; password logins disabled at the sshd level. Production secrets live in a root-owned env file loaded by systemd. MFA is enforced on all operator-facing third-party accounts (domain registrar, DNS, email, GitHub, VPS vendor, cloud console). Triggering a production deploy from the in-app admin tool requires a fresh TOTP step-up beyond the active session; session compromise alone is not sufficient. Every require_admin action is audit-logged into the hash-chained log.
backend/app/security/offboarding.py: revokes all tokens, disables MFA, deletes passkeys, disconnects Plaid, clears passwords.As a rule, you can see your stuff and only your stuff. The team can't see your portfolio holdings while wandering through the database. And our servers themselves are reachable only by one person, only with a hardware key.
Right now, "we" is one person: the founder. Our servers are reachable only by SSH and only with a hardware key. Password sign-in is permanently disabled at the server level. Outside services we use (domain, email, GitHub, server provider) all require multi-factor authentication. Even pushing new code to production from the admin tool requires a fresh authenticator code beyond the normal sign-in.
Two internal reviews complete in 2026. First-wave hardening shipped 2026-05-02 across the application + infrastructure layers. Second-wave deep-dive on the 10 highest-leverage threats closed 22 findings (4 Criticals + 6 Highs + 12 Mediums) on 2026-05-26, all in one calendar day. We don't claim a third-party penetration test; that's tracked separately and listed below.
| Layer | Reviewed | Status |
|---|---|---|
| Application (first wave) | Authentication coverage across every route, authorization on cross-resource queries, ownership scoping on portfolio-bearing endpoints, AI-tool surface, billing & subscription paths. | Shipped 2026-05: authentication required at the route layer for every account-bearing endpoint, resource ownership predicates enforced at database layer. |
| Application (second wave) | SSO + OAuth flow, webhook integrity (Plaid + Stripe), GDPR upstream-revocation completeness, refresh-token reuse, frontend HTML injection, admin action auditing. | Shipped 2026-05-26: SSO tokens moved out of URL query (now URL fragment), OAuth login flow CSRF-bound via signed state JWT + HttpOnly nonce cookie, Plaid webhook signature verification, Plaid token revocation on GDPR delete, refresh-token chain revocation, react-markdown sanitization for AI narrative, html.escape on EOD HTML, admin actions routed through require_admin audit hook. |
| Infrastructure | SSH configuration, secret storage, log retention, system account privileges, third-party agent configuration, reverse proxy, stale config drift. | Hardening runbook executed 2026-05-02. Brute-force ban at SSH layer, hardened sshd (key-only, restricted user list, low MaxAuthTries), secrets loaded by systemd. Idle-in-transaction PG sessions terminated at 60s by default. |
| Dependencies | Continuous software-composition analysis on backend (pip-audit) and frontend (Dependabot). Automatic OS package updates via unattended-upgrades. | Findings prioritized and remediated per the vulnerability-management patch SLA above. Backend now version-locked: 122 packages pinned to exact versions in requirements.txt. |
| Audit-log integrity | Whether an attacker (or an insider) could quietly edit, delete, or insert audit entries without leaving evidence. | Audit log now hash-chained (SHA-256 prev_hash + entry_hash). Tamper evidence verifiable via verify_chain(date). External mirror destination supported (env-gated) but intentionally unset until vendor selection. |
| External pen test | Independent third-party penetration test against the production application and infrastructure. | Scheduled before enterprise GA, per the vulnerability-management policy. Vendor selection in progress. |
We did two top-to-bottom security reviews in May 2026: the first covered every place an attacker could try to get in, the second focused on the 10 highest-risk threats. The second review closed 22 separate findings on a single calendar day. We've also lined up an outside expert to do the same, independently, before we sell to enterprise customers.
Honesty about gaps matters more than marketing claims. Here's what we're building toward.
Content-Security-Policy-Report-Only globally as of 2026-05-26 plus X-Frame-Options: DENY, and we're monitoring violation reports for ~1 week before flipping to enforce.Being honest about what we don't have is more useful than marketing claims about what we do. Here's what's missing, and what we're working toward.
Third-party services that process data on our behalf.
Every modern app uses some outside services. These are ours: what they do for us, and what they see.
| Service | Purpose | Data processed |
|---|---|---|
| Anthropic | AI analysis (primary) | Prompts containing market data, portfolio contextWhat you ask the AI, plus the relevant market and portfolio context |
| OpenAI | AI analysis (fallback) | Prompts containing market data, portfolio contextSame as above, only used when Anthropic is unavailable |
| Voyage AI | Embeddings for semantic search | Text sent for embedding: filings, transcripts, news, your search queries and research content you write or upload (no account identifiers)The text we turn into search indexes, including what you search for and research you write, with nothing attached that identifies your account |
| Perplexity | Web search with citations | Search query text (no account identifiers)Just the words you search for, with nothing attached that identifies your account |
| Plaid | Brokerage account linking | OAuth tokens, account balances, positionsAn access token (not your password) plus your balances and holdings |
| Stripe | Payments and subscription billing | Email, account ID and username, subscription and purchase records. Card data is collected on Stripe-hosted checkout and portal pages and never transits our servers.Your email and which plan you bought. Your card details go straight to Stripe and never touch our servers. |
| Sign in with Google (OAuth) | OAuth authentication requests; only for accounts that use Google sign-inThe sign-in handshake, and only if you choose to sign in with Google | |
| E2B | Sandboxed compute for assistant-written analysis | Rows from the datasets an analysis reads, which can include holdings and tax-lot cost basis (no account identifiers). The sandbox has no network access and is destroyed when the run finishes.Just the numbers a custom analysis needs, which can include your holdings, with nothing attached that identifies your account. The sandbox cannot reach the internet and is thrown away afterwards. |
| Financial Modeling Prep | Market data feed (quotes, fundamentals, WebSocket) | Ticker symbols (no user data) |
| CoinGecko | Crypto market data (quotes, market charts) | Coin identifiers (no user data) |
| Sentry | Error monitoring | Error stack traces, performance metrics (PII excluded)Technical details about errors and performance; your personal info is stripped before it's sent |
| Mixpanel | Product analytics | Page views, feature events, account id, email, display name, username, plan tier, device metadata, masked session replays (text redacted, media blocked)Which pages and features you use, your email and name, your account id and plan, basic device details, and screen recordings with every piece of text blanked out |
| Intercom | Support messaging | Conversation content, email address if you provide one, IP address, browser metadataWhatever you write to us in the support chat, your email if you give it, and basic technical details about your browser |
| OVH | Infrastructure (VPS, US region) | All application data (sensitive fields encrypted at the application layer) |
| Cloudflare | DNS, CDN | HTTP requests, IP addresses |
| Let's Encrypt | TLS certificates | Domain names only |
We publish our security incident count, third-party audit cadence, and bug-bounty status publicly because they are the simplest trust signals a prospect can verify.
Three things we keep public so you can verify them yourself: incidents we have had to report, when an outside firm last audited us, and where our paid bug-bounty program stands.
Where Convexity stands against the SOC 2 Trust Services Criteria: a dated, self-assessed readiness board with receipts. Not certified, not claiming to be.
A self-assessment is not an audit. SOC 2 reports are issued by independent, licensed CPA firms after examining evidence; nothing on this page substitutes for that, and we will not pretend otherwise.
Single-operator pre-launch SOC 2 is theater. We will publish the audit report when it is real, not a logo.
the house rule, stated under Incidents too
A licensed CPA firm examines whether the controls are designed correctly at a point in time.
No auditor engaged. Planned concurrent with multi-seat launch; this board is the preparation.
The same controls, observed operating effectively over a 3 to 12 month window.
Follows Type I. Nothing is in progress, and no page of ours should tell you otherwise.
The security attestation required by our brokerage-data aggregator for production access.
Program underway against all ten requirements; targeted completion Q4 2026.
Independent offensive testing of the web app and API by an outside firm.
Scheduled before enterprise GA, after the current hardening pass lands.
The controls behind the counts: the mechanism, not adjectives. The full checklist with evidence paths lives in the repo's compliance program; this is the public cut.
Open: MFA enforcement for credential-linked accounts (built, staged behind a flag) · HSTS preload.
Open: content-security-policy moves from report-only to enforcing (disclosed under Gaps above).
Open: external audit-log mirror (env-gated, destination pending) · on-call escalation formalization.
Open: hosted CI enforcement · restore drills on a logged cadence · documented RTO and RPO.
Open: outside-counsel review of the privacy policy · retention automation completion.
Open: formal risk-assessment cadence · vendor data-processing agreements · evidence automation.
Counted, not vibes. The numbers come from the criteria-by-criteria checklist in the repo's compliance program. Every "in place" cites its mechanism; two people re-counting would land on the same board.
Dated, then replaced. The board carries its assessment date. When an auditor is engaged, the engagement is disclosed here, and the eventual report replaces the self-assessment entirely.
Gaps, curated. Process gaps are named in the open. Anything security-sensitive is tracked internally and disclosed after the fix ships, the same policy this page applies to incidents.
Send the questionnaire. We will walk it through this board line by line and show the receipts behind any row, including the ones we marked against ourselves.
48-hour acknowledgement. 72-hour status updates until resolution. Safe-harbor terms for good-faith research; a paid bounty is coming soon.
If you spot something that looks like a security problem (a strange error, a way to see information you shouldn't, anything that worries you), please email us. We'll respond within 48 hours, no matter who you are.
$ mail[email protected]