Security

Architecture

Tenant isolation is database-authoritative

Auth0 verifies the human; Postgres authorizes the tenant. A row in the membership table couples a platform user to a tenant; removing that row immediately and unambiguously revokes access — there is no token-expiry wait. Every query carries a tenant identifier extracted from the verified Auth0 token, never trusted from the request body.

Source credentials never enter the integrated graph

When you connect a bank (Plaid), an accounting system, or a payments processor, the access token that provider issues is encrypted at rest using a Fernet symmetric key wrapped by a separate key-encryption key (KEK). The TallyUp integrated graph stores only an opaque handle ID; the credential itself is never copied into business records and never logged. Code paths that handle credentials use typed secret wrappers so a stray str(token) renders as SecretStr('***') rather than the cleartext value.

One human, one identity

A platform user is globally unique by lower-cased email address. Tenant access is layered on top through membership rows, which means offboarding is a single revocation across every tenant a user could reach — there is no parallel per-tenant identity model to keep in sync.

Data protection

Encryption in transit

TLS 1.2 or higher is required for every customer-facing endpoint. HSTS is enabled on the public site. Internal traffic between application services runs over Fly.io's private network with mTLS-equivalent isolation.

Encryption at rest

Source credentials are encrypted with Fernet (AES-128-CBC + HMAC). The wrapping KEK is held outside the application database as a deployment secret. The operational database (Neon-managed Postgres) provides storage-layer encryption for all rows.

Access control

Authentication uses Auth0 with RS256-signed access tokens. Our API independently verifies every request: the token signature is checked against Auth0's published keys, and the user and tenant identifiers are read from token claims rather than trusted from the request body.

Machine-to-machine tokens (server-to-server integrations) live on a separate lane. They cannot perform operations that must be attributed to a human — those requests are refused at the policy layer, not just at the UI layer.

Every capability invocation is recorded in an audit log with the acting principal, the tenant, the resolved permission, and a redacted payload. Credentials are stripped from audit records the same way they are stripped from application logs.

Operational practices

Production deploys ship through CI. There is no direct production database access for engineers; schema changes flow through reviewed migrations. Secrets are managed as deployment-platform secrets (Fly.io) and rotated on a best-effort basis today.

Compliance

TallyUp does not currently hold a SOC 2 attestation. Our controls are designed against the SOC 2 Trust Services Criteria and we are working toward a Type I audit. We will publish the report when we have one. Until then, we are happy to walk through our security architecture with prospective customers — write to security@tallyupnow.com.

Reporting a vulnerability

If you believe you have found a security vulnerability in TallyUp, please email security@tallyupnow.com. We will acknowledge your report and work with you in good faith to investigate. Please give us a reasonable window to fix the issue before public disclosure.