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.
Documentation
What we collect, what we never store, how tenant isolation works, and how to run the demo stack locally.
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.
Production, beta, demo, and fixture labels match backend proof tests. Website and product use the same labels.
Each connector ships with minimum-permission manifests, data-collected and data-not-collected lists, and maturity labels that match backend proof tests.
Docker Compose for local demo. Private connector runner design for VPC metadata-only egress. Full deployment runbook in the product docs.
Permission artifacts per connector for security review calls. Available through the trust center in the product.
Request trust packs during a security review or design-partner onboarding call.
Exports are tenant-scoped, redacted, and append-only audit events accompany sensitive actions. No raw secret values in reports or CSV downloads.
We walk through the security model, trust packs, and what Sentyn never stores with your identity and GRC teams.