Permissions, audit and controlled AI
An architecture that works within your access permissions, writes every action to an audit record and sends no personal data to AI. This page describes behaviour, not promises.
Like a bank vault: whoever holds the key opens it, every opening goes in the ledger, and critical safes need two signatures.
The parts that build trust
Permissions and tenant separation
Every screen is tied to a permission and every module to a feature switch; each company’s data is kept separate.
Password Vault
Secrets are stored with envelope encryption; viewing requires person- or role-based permission and recent verification.
One-time links
Invitation, approval and password reset links come from a single service; expiry and usage limits are enforced on the server.
Controlled AI
The assistant connects to permitted tools, not to the database. Each tool carries a risk class; risky actions require approval.
Data protection
Personal and financial data is not sent to the model; the real record is shown only on an authorised screen.
Audit chain
Password Vault access and assistant actions are written to a hash-chained record that cannot be altered; the chain is verified from the admin screen.
About trust
Does the AI see our data?
No. The model receives only data references and masked summaries; the real record is rendered on an authorised Portal screen. Requests and responses go through leak checks.
Where are secrets stored?
In the Password Vault, encrypted and versioned. Modules receive secrets only through a defined usage binding.
Which standards do you comply with?
This page makes no certification claims. We share the details of our permission, audit and data protection behaviour in a technical call.
Let’s talk about a technical evaluation.
We’ll answer your IT and security team’s questions together.