Security posture
Encrypted credentials
Keys are sealed with AES-256-GCM before they reach the database, tagged with your workspace and connection ID so the ciphertext can't be replayed anywhere else. Decryption happens server-side only. What comes back to your browser is a masked hint.
Isolation the app can't forget
Every row carries a workspace ID and Postgres row-level security enforces it, keyed off the signed token in your session. A query that tried to read another tenant's data would return nothing.
Sign-in we own end to end
Passwords are hashed with argon2id. Two-factor is TOTP, and its secret is sealed with the same envelope as your provider keys. Sessions rotate on refresh, and resetting your password invalidates every one of them at once.
Fail-safe ingestion
A failed provider read is recorded against that connection and left alone. We would rather show you a gap than a confident wrong number, and a month still in progress is flagged partial until it closes.
Least privilege, by design
Every connector asks for read-only cost and usage access. There is no code path in EvenHelm that could change a resource or spend money in your account, because we never ask for the permission to.
Straight answers about deletion
Deleting a connection disables it and stops every read we make against your provider. The sealed credential is retained rather than shredded, so rotate the key at the provider if you want it dead on both sides. Session IPs, audit entries and expired sign-in tokens are pruned nightly on fixed windows; invoices stay, because accounting law says they must.
Responsible disclosure
If you have found something that looks wrong, we want the report more than we want the quiet. A person reads every one of these. Email hello@evenhelm.app.