Tenant isolation
PostgreSQL row-level security on every tenant table. API never trusts tenant IDs from request bodies. Cross-tenant negative tests required for new features.
Security & trust
Learn what Sentyn reads, what it never stores, how customer data stays separated, and which features are still in beta.
How Sentyn handles tenancy, credentials, secrets, audit, and connector trust.
PostgreSQL row-level security on every tenant table. API never trusts tenant IDs from request bodies. Cross-tenant negative tests required for new features.
Connector credentials encrypted through a KMS abstraction. API returns status only. Logs and responses never echo credential payloads.
Secrets stripped before persistence, API responses, reports, logs, and webhooks. Tests use fake secrets and assert full values never appear.
Sensitive writes fail closed if audit append fails. Tenant-scoped events for connector setup, owner assignment, and export actions.
Discovery connectors require least-privilege read scopes only. Permission manifests must exist before any real credential is accepted.
Beta, demo, fixture, and future production labels come from backend maturity evidence. No connector is presented as live-proven until a successful real-source sync records that proof.
The product shows whether a connector is beta or demo-only. Permission guides and collected-data details are reviewed separately for each connected system and are not yet complete for every connector.
The demo can run locally with Docker. A beta private runner can read approved system details inside your cloud network and send only safe identity data to Sentyn.
Review connector permissions, security controls, deployment notes, and proof of what each feature has passed.
Ask for the current security material before connecting a system.
Reports include only your organization’s data, remove secret values, and keep a permanent record of important actions.
We walk through the security model, trust packs, and what Sentyn never stores with your identity and GRC teams.