Security

1.Tenant isolation

• Separate database projects. Provisioned workspaces are assigned their own managed Postgres project rather than sharing tables with other customers. A workspace’s credentials open its own database, not the platform’s.
• Row-level security. Platform tables enforce row-level security policies keyed to the authenticated tenant, so a query cannot reach another tenant’s rows even if it tries.
• Scoped credentials. Sites and resources provisioned for a workspace are issued that workspace’s credentials. Failures on this path fail closed — an unconfigured site rather than one wired to the wrong database.

2.Secrets

• Credentials live in a dedicated secrets service, not in application configuration or source control.
• The vault does not mutate values unattended — there is no automatic rotation or sync without an explicit, deliberate action.
• Changes to the vault and the secrets service require human approval through a gated release process, separate from ordinary code review.
• Rotation is documented and runbook-driven, including coordinated rotation across dependent services.

3.Encryption

Data is encrypted in transit using TLS, including on every call to a model provider. Data at rest is encrypted by our managed database and object-storage providers using their platform encryption.

4.Provenance and audit trail

Every finished output carries a receipt: which models ran, which quality checks passed, what it cost, and every edit since. This is a genuine audit record rather than a summary — it is generated by the pipeline that did the work, and it is verifiable at a public link when you choose to share one.

Workspace activity — who produced what, when, and against which budget — is visible to workspace administrators.

5.Access control

• Role-based permissions within a workspace.
• SSO via SAML 2.0 and user provisioning via SCIM 2.0 are available on Enterprise.
• Internal access to production systems is limited to what operating the service requires.

6.What we have not done

About the governance profiles

Accentor offers compliance profiles — including HIPAA-adjacent, COPPA, SOC 2 and EU profiles. These are product features: they apply the corresponding controls and checks to the work you produce, and they record that they did. They are not a third-party attestation about Accentoritself, and selecting one does not make your use of Accentor compliant with that framework. Read them as tooling that helps you meet an obligation you hold.

Health, payment and regulated data

Do not put protected health information or cardholder data into Accentor without an executed agreement covering it. We will sign a BAA or DPA on request — talk to us before you upload, not after. Payment card details are handled by Stripe and never reach our systems.

7.Reporting a vulnerability

Email [email protected] with enough detail to reproduce the issue. We will acknowledge your report, keep you informed while we investigate, and credit you if you would like us to.

Please give us a reasonable opportunity to fix an issue before disclosing it publicly, and do not access, modify or delete data belonging to anyone else while testing. Good-faith research reported this way is welcome, and we will not pursue action over it.

We do not currently run a paid bug bounty.

8.Incidents

If a security incident affects your data we will notify you without undue delay, with what we know, what we have done and what we recommend. For customers with a DPA, the notification terms in that agreement apply.