Policies

A policy describes who can do what to which data. You write it once in Trinitis; when you activate it, Trinitis writes it into each platform's own native controls.

Anatomy of a policy

A policy is a set of rules. Each rule has:

  • Actor — a user, a group or role, a platform principal, or a registered AI agent
  • Resource — the database, schema, table or columns it covers
  • Effect — Allow or Deny
  • Action — Read, Write or Admin

Policies are built in the Trinitis web app. There is no separate policy language or CLI to learn.

Draft, then activate

  1. Open Policies → New Policy and add your rules.
  2. Save as Draft. Nothing changes on your platforms yet.
  3. Activate. Trinitis applies the policy using native commands — grants, revokes and, where supported, masking policies — and records the result in the audit log.

Start from the grants you already have

On Snowflake, Databricks and Redshift, migration import reads your existing roles and grants and turns them into draft policies grouped by role. You approve or reject each draft before anything is applied. Migration import is not available on BigQuery or PostgreSQL.

Column-level controls

  • Snowflake — column masking via Dynamic Data Masking
  • Databricks — column masking via Unity Catalog column masks
  • Redshift — column masking via native dynamic data masking
  • PostgreSQL — native column masking on Amazon Aurora (pg_columnmask); column restriction via native REVOKE SELECT on community and RDS PostgreSQL
  • BigQuery — column masking is on the roadmap; enforcement today is at the dataset and table level
  • S3 / Iceberg — discovery and visibility only today

Your controls keep working without us

Because policies live in your platforms' native controls, they keep working if Trinitis is switched off. You lose the management plane, not the controls.

The Platforms page has the full capability matrix.