A platform that governs other systems’ identities and credentials has to hold itself to a higher standard than the systems it reads. This page describes how the Trustivan platform is built and isolated, in enough detail to be useful to a security reviewer and with the same honesty labels we use everywhere else. It is deliberately conservative: where a control depends on your configuration or your deployment plan, we say so.
Principles
Four commitments the architecture is built around
Least privilege by default
Connectors read, never write; roles grant the minimum; sessions are short and revocable
Isolation at every layer
Tenant scoping in storage, query, job execution and connector credentials — no cross-tenant path
Evidence before claims
Every record carries its source and observation time; missing evidence is shown as unknown
Honest labels
Available, future capability, not built — in the product and on this page
Tenant isolation
Trustivan is multi-tenant. Isolation is enforced in several independent layers so that no single defect can expose one customer’s data to another:
- Storage. Every node, edge, evidence envelope, finding and audit event carries a tenant key. There are no shared, tenant-less tables for customer data.
- Query. Tenant scope is enforced by PostgreSQL row-level security beneath the API layer, before any filter a caller supplies. There is no cross-tenant query path in the product, including for Trustivan staff.
- Execution. Connector sync jobs run per tenant with that tenant’s credentials and cannot address another tenant’s store.
- Secrets. Connector credentials are envelope-encrypted under a per-tenant wrapping key and are released only to that tenant’s jobs.
Isolation is part of the platform foundation and is covered by automated tests that attempt cross-tenant access and must fail.
The evidence model
Every record the platform shows can be walked back to its source. Each assertion in the identity graph carries evidence: the connector that observed it, the source object identifier, the observation time, a statement of what was seen and the raw provider payload, redacted of credential material. Inferred relationships are marked as inference and rendered distinctly from observed ones.
When a factor has no evidence, the platform shows unknown. This applies to risk context, lifecycle states, ownership and classification alike. The model is described in detail in Inside the identity graph.
Read-only, least-privilege connectors
Connectors are how Trustivan reads your environment, and they are built to be easy to review:
- Read-only by contract. The connector contract defines no write operations. Remediation actions you take from a finding are recorded as tasks and evidence; they are not executed against your systems by the connector.
- Permissions documented up front. Each connector’s required read-only permissions are documented, with the reason for each.
- Partial failure is visible. If a sync reaches only part of the estate, the run is recorded as partially failed, rather than silently producing an incomplete inventory.
- Metadata, not secret values. Where a connector reports credentials, it reads that a credential exists, its type, age and attachments. Where a source API would return secret material, the connector does not request it.
The connector list with per-connector status is on the integrations page.
Credential handling
Two kinds of credential matter here: the ones Trustivan needs to read your environment, and the ones that belong to the identities it discovers.
Connector credentials — the tokens, keys or federated identities you grant to a connector — are stored encrypted in a per-tenant secret store, released only to that tenant’s sync jobs, and never written to logs, exports or the identity graph.
Discovered credentials — the keys, tokens and certificates held by your identities — are represented by metadata only: type, age, last rotation, where they are attached, and where copies have been reported through the exposure ingestion API. The platform does not store customer secret values. This is a deliberate narrowing of scope: Trustivan needs to know that a key exists and what it unlocks, not what the key is.
Audit logging, RBAC and sessions
The identity governance foundation of the platform applies the same discipline to Trustivan’s own users that the product applies to yours.
- Audit trail
- Authentication events, role and membership changes, connector configuration, ownership changes, remediation and access-grant decisions and data exports are recorded with actor, time and tenant. Audit events are append-only and hash-chained per tenant, so an alteration is detectable rather than impossible.
- RBAC
- Six roles are scoped to organizations and teams. Administering the organization is separated from operating security, and an analyst can propose a remediation but not approve it.
- Sessions
- Email and password sign-in, bounded session lifetimes, revocation on demand and invitation-based onboarding. There is no SSO and no MFA. Role grants and revocations are recorded in the audit trail.
Data residency
Trustivan runs as a single-host deployment: the console, the API and PostgreSQL on one host, with connector syncs running on that same host. Tenant data therefore resides wherever that host is provisioned. There is no multi-region option and no high-availability configuration today, and we do not describe residency as anything broader than the location of that host.
Build, test and security gates
The version-controlled pre-commit hook runs a secret scan, lint and type checks on every commit it is enabled for. The unit and integration suites — including the cross-tenant tests described above — and the dependency audit run through make verify, by hand, before a change is committed. CI workflows that would run the same gates on every change are defined but have not yet run: the repository has no remote. The datedproduct updates describe what changed using the same availability labels as the product.
Controls at a glance
| Area | What is in place | Status |
|---|---|---|
| Tenant isolation | Tenant key on every record; PostgreSQL row-level security enabled and forced below the API; secrets wrapped under a per-tenant key | Available |
| Evidence model | Connector, source identifier, observation time and redacted raw payload behind every assertion; inferred edges marked apart from observed ones | Available |
| Connectors | Five read-only connectors with documented permissions; partially failed syncs recorded as such; no write operations in the contract | Available |
| Customer credential handling | Connector credentials envelope-encrypted per tenant; used only by that tenant’s sync jobs; no retrieval of customer secret values | Available |
| Authentication & sessions | Email and password sign-in with bounded session lifetimes, revocation on demand and invitation-based onboarding; no MFA | Available |
| SSO, SAML and SCIM | Not built, by design: no sign-in through your own identity provider and no directory-driven provisioning | Not built |
| RBAC | Six roles with organization and team scope; organization administration separated from security operations; analysts propose and cannot approve | Available |
| Audit trail | Authentication, role and membership changes, connector configuration, ownership and remediation decisions, exports; append-only and hash-chained per tenant | Available |
| Second-person approval | Remediation, policy exceptions and agent access grants approved by someone other than the requester | Available |
| Build, test and security gates | Secret scan, lint and type checks in the pre-commit hook; test suites and dependency audit through make verify; CI workflows defined and not yet run | Available |
| Behavioural anomaly detection | Not built, by design: no behavioural baselines over the identities Trustivan governs | Not built |
| SIEM export & webhooks | Forwarding findings and audit events to your SIEM or a webhook | Future capability |
Responsible disclosure and compliance posture
If you find a vulnerability in the platform or this site, we want to hear about it. The Security & Trust page describes how to report it and what to expect from us; please use it rather than public channels so that we can fix the issue before it is disclosed.
On compliance: the platform is designed to support customers’ SOC 2 and ISO 27001 programs — through the audit trail, RBAC, evidence model and isolation described above — and we will share our current security documentation under NDA on request. We do not list certifications on this page; if and when we hold one, it will be stated plainly with its scope and date, and not before.