Features / Platform
Security and audit
Separated at the database, not by hopeful code
Each organization's data is isolated by the database itself rather than by application logic remembering to filter. Everything consequential is recorded.
What it does
- Isolation enforced below the application, not inside it
- Audit log of who did what, and when
- Retention rules you set, and deletion that actually deletes
- Single sign-on and extended audit history on Enterprise
Without it
A support tool holds more of your customers than your app does
One missing WHERE clause
Every multi-tenant leak looks the same in the diff: a query that forgot the org filter. It ships on a Wednesday afternoon, passes review because it reads fine, and the first person to notice is a customer looking at somebody else's conversation.
Nobody can say who changed that
A rule that used to escalate refunds is not escalating refunds. Three people had access, none of them remember touching it, and there is no record to check. You end up guessing from Slack scrollback.
You promised deletion and flipped a flag
A customer asked you to erase their data and you said yes. What actually happened was a status column changed and the rows stayed, along with the attachments in object storage that nobody thought about.
How it works
The database refuses, not the application
Every tenant-scoped read and write opens a transaction, sets the tenant for that transaction only, and lets Postgres row-level security do the filtering. A query that forgets its filter comes back empty instead of coming back with someone else's rows.
The workers connect as different roles
The audit purge, the daily seal, the credential mailer and the erasure runner each connect as their own database role with their own permissions, and each checks at startup that it is the role it thinks it is. A bug in one of them cannot do another one's job.
What that includes
- The audit purge
- the daily seal
- the credential mailer
The audit log can be added to and nothing else
Update and delete are revoked on the audit table at the database level, so no code path can rewrite history, including ours. Each day is sealed with a digest that chains to the previous day, which is how a removed row becomes visible rather than invisible.
Six risk classes are locked everywhere
Authentication and access, billing and payments, database migrations, personal data and deletion, tenant isolation, and secrets. A locked class resolves to human review when it is read, so a per-area setting can only be more restrictive, never less.
Deletion runs, then gets counted
A deletion request waits out a grace window, then walks every table and every blob store. A separate verification pass counts what is left behind, and the request is not marked verified until that count is zero.
What it means for you
The security questionnaire has real answers
When a prospect asks how their data is kept apart from another customer's, you can describe a mechanism they can check rather than a policy they have to trust.
New code inherits the isolation
Someone joining next month does not need to know the tenancy rules to be safe. They cannot write the query that leaks, because the connection they get is already scoped.
You can reconstruct the bad afternoon
Who changed the setting, when, from which address, and what it was before. Not so you can blame someone, but so the conversation about what happened takes ten minutes instead of a day.
The honest limit: Tore is pre-launch and has no third-party audit or SOC 2 report yet; what is described here is the mechanism, and you are welcome to check it. Single sign-on is planned for Enterprise and is not built.