Security
Enforced in the planner, not an application tier
Three-state privileges, row-level security, column masking, ABAC, and mandatory access control are evaluated inside query planning. The policy is part of the plan itself, so there is no application tier to bypass.
Access control
Layered rules, resolved in one place
The planner resolves privileges, row filters, masks, and labels while it builds the plan. What reaches the executor is already the governed query.
Three-state privileges
Every privilege is GRANT, DENY, or unset. DENY always wins, and a column-level rule overrides the table-level rule.
Temporal grants
Grants carry validity windows, including recurring time windows, so access expires on its own schedule.
Row-level security
Policies filter tables row by row, and row ownership binds each row to an owning principal.
Attribute-based access control
ABAC rules weigh attributes of the user, the session, and the data, not just role membership.
Mandatory access control
Security labels set an access ceiling that object owners cannot waive, enforced by the engine on every access.
Data classification
Data carries classification levels, and clearance enforcement keeps under-cleared sessions away from it.
How the three states resolve
Explicitly allowed at this scope.
Explicitly blocked. DENY beats GRANT wherever the two collide.
No rule at this scope. A column without its own rule keeps the table-level outcome.
DENY always wins over GRANT, and a column-level rule overrides the table-level rule for that column. A column with no rule of its own keeps the table-level outcome.
Access control lives in the zyron-auth crate and is applied by the same planner that orders joins on the database page. There is no policy proxy in front of the engine and nothing left for a client library to enforce.
Masking
Masking that lives on the column
Column data masking controls what a query returns from a sensitive column. Seven mask types cover the usual shapes of sensitive data, from partial reveals to full hashes, and custom masks handle the rest.
Grants get the same DDL treatment. A GRANT can carry a validity window, so access to a revenue table lapses on schedule instead of waiting for a cleanup ticket.
-- Column masking as a policy
ALTER TABLE patients ADD MASKING POLICY ssn USING mask_ssn();
-- A grant with a validity window
GRANT SELECT ON revenue TO analyst
VALID FROM '2026-01-01' UNTIL '2026-12-31';Both statements run over an unchanged PostgreSQL connection.
Authentication
Identity for people, services, and platforms
Interactive logins, machine credentials, and cloud platform identities authenticate natively against the server, with throttling and session binding behind all of them.
Passwords
Stored behind a memory-hard key derivation function.
API keys
Key-based authentication for services and automation.
JWT
Signed JSON Web Tokens for token-based sessions.
TOTP
Time-based one-time passcodes as a second factor.
WebAuthn
Passkeys and hardware security keys.
OAuth2
Delegated sign-in through an identity provider.
AWS STS / Secrets Manager
Short-lived AWS credentials and managed secret retrieval.
Kubernetes
Service account identity for workloads in a cluster.
Brute-force throttling
Repeated failed attempts are slowed down, so guessing credentials at scale stops paying.
Session binding
A session can be locked to its source IP and capped with query limits.
Operational safety
Admin power, held accountable
The riskiest identity in any database is the administrator. These controls make emergency access auditable, sensitive DDL deliberate, and privilege sprawl visible.
Break-glass access
Emergency access for real incidents, with every use recorded in the audit trail.
Two-person rule
Sensitive DDL waits for a second person to approve before it takes effect.
Privilege analytics
Visibility into who holds which privileges across the whole system.
Delegation lineage
Every privilege traces back through the chain of grants that produced it.
Cascade revoke
Revoking a grant also revokes everything that was granted onward from it.
Lifecycle governance
Governed to the end of the data's life
Retention, tiering, deletion, and compliance are engine statements with the same authority as the access rules above, not cron jobs scheduled around the database.
Aging and tiering
- Retention and TTL declared on the table itself
- Tiered storage and archival to object storage
- Data-residency enforcement on tier moves
- DRY RUN previews for archive, erasure, and retention
Immutable records
- WORM and time-bounded retention locks, immutable even to admins
- Legal hold that suspends deletion while it stands
- Tamper-evident audit chain
Deletion and recovery
- Soft delete with a recycle bin and UNDROP
- GDPR erasure and DSAR export
- Crypto-shred when deletion has to be final
Compliance presets
A single compliance_profile setting applies a preset for the regulation a deployment answers to.
-- Retention on the table itself
ALTER TABLE events SET TTL '90 days';
-- Tier cold data out to object storage
ARCHIVE TABLE old_events
WHERE created < '2024-01-01' TO 's3://archive/events';Retention and archival, straight from the SQL surface.
Lifecycle enforcement ships in the zyron-lifecycle crate, one layer of the crate stack shown on the database page. Key management lands with the distribution milestone now in progress on the roadmap.
Running in the next five minutes
Prebuilt binaries for Linux and Windows, no external dependencies, one command to a running server.