Trust & security
What we hold, and what we never see.
Trinitis stores metadata only, never your data values. Policies are enforced inside your own platforms by their native controls, and there is no proxy in your query path. This page sets out exactly what that means.
What Trinitis connects to
Outbound connections to each platform's native API. No proxy.
Trinitis initiates every connection outbound to each platform's native API; for Redshift and PostgreSQL that can run through an SSH tunnel via your bastion. Nothing sits in your query path.
| Platform | How Trinitis authenticates | Required privileges |
|---|---|---|
| Snowflake | Service-account user and password, or key-pair | Connector docs |
| Databricks | OAuth service principal (recommended), or personal access token | Connector docs |
| BigQuery | Service-account JSON key | Connector docs |
| Amazon Redshift | Service user and password; optional SSH tunnel | Connector docs |
| PostgreSQL | Service user and password; optional SSH tunnel | Connector docs |
| S3 / Iceberg | Static access key, or IAM role assumption with a per-connection external ID | Connector docs |
A note on SELECT
On Snowflake, Databricks, Redshift and PostgreSQL, reading column metadata requires the SELECT privilege; there is no metadata-only option. That means the credential you give Trinitis could read rows. BigQuery is the exception: the metadataViewer role grants metadata and denies data reads.
Trinitis reads only schema and column metadata and stores no row values. Even so, evaluate the credential as one capable of reading data.
What Trinitis stores
Metadata in. Data values never.
We store
- Schema, table and column names
- Tags
- Existing grants
- Drafted and approved policies
- Group and role membership
- Query history, with real data values stripped
We never store
- Customer data values
- Sampled column values. Trinitis does no column-value sampling today.
- Credentials
- Held in AWS Secrets Manager, encrypted with KMS, and used only by the application. Kept while a connection exists or is archived (for audit attribution); deleted at account offboarding.
- Audit
- Append-only. Access intelligence is ingested about every 5 minutes by default. Export as CSV or JSON. 12-month rolling retention from the event date.
- Hosting and encryption
- US, on AWS us-east-1. AES-256 at rest via KMS; TLS 1.2+ in transit. More regions are on the roadmap; no residency options today.
The honest answer
If we are compromised, what happens to you?
What is exposed
Metadata, and the least-privileged credentials held in Secrets Manager. No data values, because we never store them. You can revoke those credentials at the platform at any time.
Your policies keep working
Policies are enforced inside your own platforms by their native controls. With Trinitis switched off, enforced policies stay in force.
Nothing applies without you
Drafts land in PENDING and apply only after you approve them. Trinitis does not change access on its own.
Retention & deletion
How long we keep what we keep.
| What | Retention |
|---|---|
| Configuration and metadata | Life of the account; deleted within 30 days of termination. |
| Audit log | 12-month rolling retention from the event date. Not deleted at termination. |
| Connection credentials | Deleted at account offboarding, with a 7-day AWS recovery window. |
| Backups | About 7 days. Deleted data ages out as backups cycle. |
Security questionnaire, pre-answered
The questions your security team will ask first.
- Is data encrypted in transit?
- Yes. TLS 1.2 or higher.
- Is data encrypted at rest?
- Yes. AES-256, with keys managed in AWS KMS.
- Who are your subprocessors?
- AWS, Vercel, Auth0 and Google Workspace.
- Where is the service hosted?
- In the US, on AWS us-east-1. More regions are on the roadmap; there are no data-residency options today.
- Do you offer a DPA?
- Yes. A Data Processing Agreement is available (in final review).
- Do you have SOC 2?
- SOC 2 Type I is in progress.