Security and access
Permissions the database enforces, not the screen.
An ERP holds payroll, bank details, tax certificates and the ethics channel. Who may see what is the whole product, not a settings page — so it is decided by a role, enforced in the database, and written down when it happens.
The role system
Powerful enough to describe your org chart. Small enough to read.
Most permission systems fail one of two ways: too coarse to express a real company, or so granular nobody ever audits them. 87 areas, four levels each, nineteen ready-made roles and your own on top.
Watched by
Compliance
The roles that ship
- Admin
- Controller
- Accountant
- Finance
- Account Payables
- Account Receivables
- Compliance
- HR Manager
- HR
- Operations Manager
- Operations
- Inventory
- Sales
- IT
- Employee
Four levels, cumulative
Viewer
Can see it. Cannot change it.
User
Does the day-to-day work of that area.
Supervisor
Approves, corrects and sees what others did.
Full access
Configures the area, including who else gets in.
Each area is set to one of these for a given role. Higher levels include everything below them, so a supervisor never needs the levels underneath granted separately.
Per area, not per screen
Access is granted over 87 functional areas — invoicing, payroll, treasury, stock, the ethics channel — each set to one of four cumulative levels. That is a grid somebody can actually read and defend in an audit, rather than the hundreds of individual switches nobody will ever review.
Nineteen roles, or your own
Nineteen roles ship ready to use, from Admin down to Employee. When none of them is the shape of the job, an organisation defines its own — a real role, not a copy of another one with exceptions bolted on.
Integrations get roles too
An API key is not a master key. It is assigned roles through exactly the same chain a person is, so an integration sees precisely what its role sees — and revoking it is the same act as revoking a leaver.
It cannot grant what you did not buy
Entitlement is checked after the role, not before it. A role that names payroll grants nothing to an organisation without payroll — so a role cannot quietly become a way into a module that was never paid for.
You are only offered what fits
A company that bought time tracking is not shown Controller, Accountant and Finance — three roles that would resolve to the same empty set. The catalogue narrows to the roles that mean something for what you actually run.
Where it is enforced
Hiding a field is not security.
Anyone can call an API directly. A permission that only removes a button is a permission that does not exist — so every one of these is decided below the interface, where a request cannot get past it.
The database decides, not the screen
Hundreds of row-level policies live in the database itself. Hiding a field in an interface is not security — anyone can call the API directly — so the row is not returned to someone whose role does not reach it, whatever they call it with.
One operation, one permission
Privileged operations run as guarded procedures, each gated on a single dedicated permission rather than a chain of loosely related ones. A permission means one thing, so widening it cannot quietly widen something else.
The AI runs under a real role
Every AI employee, and every agent step inside a workflow, runs as a principal with ordinary permissions — never as an administrator. What it can see is what a person with that role would see, decided by the same policies.
Refusals are recorded
The audit trail records who acted, on which record, and when — and a refused attempt is written down rather than dropped in silence. An access control you cannot review afterwards is a control you are trusting rather than checking.
Secrets, sign-in and lifetime
The parts that would hurt if they were wrong.
Secrets are not stored beside ordinary data
Your tax certificate and its password are encrypted with AES-256-GCM before they are written, and kept in their own table behind a narrower permission than the one that lets somebody see the company at all. They are never decrypted inside the database. Putting them next to the company record would have let anyone who can read a company read the certificate straight out of the API.
Passkeys, and MFA you can require
Members can sign in with a passkey instead of a password. An organisation can require a second factor of everyone, and the application enforces enrolment before granting access rather than asking nicely.
One-time links are never stored
Signing links and the codes that go with them are kept only as fingerprints. The link is shown once and never written down, so nobody — including us — can re-issue it out of the database.
Data has a lifetime you set
Retention windows are yours to choose per company — how long conversations, messages and attachments are kept — and a scheduled job actually deletes what has aged out. Zero means keep it forever, and that has to be a choice somebody made.
Sensitive data · GDPR article 9
Health data gets a store of its own.
Clients’ special-category data never sits in a CRM field. It is encrypted per value with a key held outside the database, visible only to the roles you give it to, signed for by the client, and logged on every read.
What we claim
Mechanisms, not badges.
This page describes mechanisms rather than badges, on purpose. We do not hold a SOC 2 report, and we would rather tell you that than imply otherwise — what we can do is show you exactly how access is decided, where it is enforced, and what is written down when it is. For how personal data is handled, the privacy policy is the document that governs, not a marketing page.
Bring your reviewer.
The fastest way through a security review is a call where we open the role editor, show you a permission being refused, and let you read the trail it left.