Security & Multi-tenancy

Isolated workspaces

Each customer is an isolated workspace — a tenant. Data is scoped per tenant using row-level security, so one workspace cannot see another's records. A single user can belong to more than one workspace and move between them with a workspace switcher, which keeps consultants and multi-site teams in one account without mixing data.

Roles and per-module permissions

Access is controlled by roles combined with per-user, per-module permissions. Beyond broad roles, you can grant an individual user specific access to individual modules — including a read-only "view" level for people who need to see a module but not change it.

These permissions are enforced by a permission gate that runs both in the UI and on the server. The interface hides what a user cannot access, and the server independently checks the same rules, so the boundary is not something a client can bypass.

The accounts layer

For organizations that run several workspaces, an accounts layer sits above them. This gives groups that operate multiple tenants — for example across sites or business units — a higher-level structure to organize the workspaces they own.

Audit log and single sign-on

Administrative actions and approvals are written to an audit log, creating a durable record of who did what. For Enterprise, single sign-on via SSO/SAML is available, so access can be managed through your identity provider.

A human-governs model

Kanso is built so that people stay in control of consequential decisions. Routine work is captured as it happens — the day-to-day records that make up your quality system. Sensitive actions, such as approvals and signatures, require the right permission before they can be taken.

That separation keeps the system efficient for ordinary work while ensuring the moments that matter — the ones that commit the organization — are governed by a person with the authority to make them, and recorded in the audit log when they do.