SoloHum

Security and data handling

Last updated 7 October 2026. Draft: written from how the system works today, not yet reviewed by counsel.

What SoloHum reads

SoloHum connects to the tools your businesses run on with read-only keys, tokens or OAuth scopes. Each source states what it will read before you connect it, in the product, and that statement is the whole of it.

The first real sources (Stripe by restricted key, Mercury by read-only token) are being built; their access statements will appear here when they ship.

Built-in checks need no credential: a project with a domain is fetched over HTTPS, its certificate expiry read from the TLS handshake, and its registration expiry read from public RDAP.

What SoloHum stores

  • Your account: your email (from sign-in), time zone, brief times, quiet hours, currency and display preferences.
  • Your portfolio: the names of your businesses and projects, their stages, and their domains.
  • Resources: the things a source reports (a Stripe account, a site, a repository): the provider’s identifier, a name, a URL.
  • Events and metrics: the provider’s opaque identifier, a kind, a time, a title, an amount and currency where there is one, and a link back to the record in the source tool. No end-customer name, email address or payment instrument is ever written. A test runs on every build to confirm this.
  • Credentials: sealed with AES-256-GCM under a versioned key ring that lives outside the database, in a schema the API never exposes. The server opens a credential only to run a sync, and never logs it.
  • Items, baselines and checks: what the attention engine computed from the above.
  • An audit log of sensitive actions on your account: sources connected and disconnected, resources removed, heartbeats created.

Where

Data is stored in a Supabase Postgres database in AWS us-east-1 (N. Virginia), isolated per account by row-level security, so one account can never read another’s rows through any path. The application runs on Vercel in the same region. DNS is served by Cloudflare. The full sub-processor list is in the data-processing agreement.

How long

  • Built-in site checks: seven days.
  • Everything read from a source: until you disconnect it. Disconnecting deletes the credential first, then the connection and everything read through it, at once.
  • Your account: until you delete it. Deletion removes the account and everything under it within 30 days; the data-export and deletion flow is being built and this page will say when it has shipped.

Access

Sign-in is passwordless: a one-time link by email, or Google or GitHub. Links are redeemed by a click on a page SoloHum controls, so a mail scanner opening the link cannot sign in as you. Two-factor sign-in with an authenticator app is next in the plan. SoloHum’s own staff access is by the same accounts; there is no shared production password.

If something goes wrong

If SoloHum learns of a breach affecting your data, you will be told within 24 hours of confirmation, with what was affected, what was done, and what you should do. The incident runbook commits to that clock, which is the strictest among the platforms SoloHum connects to.

Reporting

Security reports go to security@solohum.com. Please do not test against other people’s accounts.