How Tidehawk protects your data

This page describes the controls that are actually implemented, so you can answer a client’s due-diligence questionnaire from it.

Tenant separation

Every table that holds customer data carries a workspace identifier, and PostgreSQL Row-Level Security policies are attached to those tables. Separation is enforced by the database on every query, not by application code remembering to add a filter. A bug or an injection flaw in an application code path cannot read another workspace’s rows, because the database refuses them.

The application connects as a role that has Row-Level Security enforced and holds only the specific privileges it needs, table by table. Administrative tables are not reachable from that role at all.

The row-level separation rules are covered by an automated test suite that must pass before any change ships.

Encryption

In transit. TLS 1.2 or higher on all connections.
At rest, application layer. Two-factor authentication secrets and PSA integration credentials are encrypted with AES-256-GCM before they are written, using a key held separately from the database. Someone holding a copy of the database cannot read them without that key.
Passwords. Stored as Argon2id hashes, never as recoverable text.
Recovery codes. Stored as keyed hashes, so a database copy alone cannot be used to derive them.

None of these secrets appear in a data export. Exports declare what was withheld and why. See Export your data.

Your audit trail

Actions in your workspace are written to an audit log that owners and admins can read and export. Entries are chained together with a hash, so a row altered after the fact no longer matches the chain. The evidence report re-verifies the chain when you generate it. See Audit log.

Support access to your workspace

Tidehawk support engineers can open a session inside your workspace to investigate a problem. That access is constrained.

Every access is logged. Support tooling reaches customer data only through a wrapper that writes a record first: who accessed which workspace, for what action, and when. Those records are themselves chained with a hash so an entry cannot be altered silently, and a daily job re-checks the chain.
A support session needs a ticket. The database requires a reference to a real, open support ticket in your workspace. There is no way to create a session without one.
A written reason is required, of at least 20 characters.
The engineer re-authenticates with their own authenticator code at the moment they start the session, so a hijacked staff session is not enough on its own.
A signed Data Processing Agreement is required. Without it, the session is refused.
Sessions expire after one hour, and a background job closes any that are left open.
You are emailed as soon as a session starts, to every owner. This notice cannot be switched off.

While a session is open, your workspace shows a banner saying so.

What a support engineer cannot do

Certain actions are blocked outright during a support session, even for an operator who would otherwise have the rights: inviting team members, opening your Stripe billing portal, removing a passkey, and deleting your workspace.

Seeing the history yourself

Open Settings → Operator access. It lists every support session ever opened in your workspace, with the engineer, the ticket reference, the reason, and the start and end times. If a session is active you can end it immediately from that page.

Sensitive changes made by Tidehawk staff to a customer account, such as executing an erasure or changing billing, require approval by a second administrator before they run.

Reporting a vulnerability

Email security@tidehawk.co with a description of the issue.