Three things we do not do
Nothing leaves your network
Models, documents, prompts, embeddings and logs stay where you install them. None of it is sent to an outside provider.
Nobody gets in without a role
Every request is refused unless a role allows it. Roles also decide which individual records a person can open.
We do not train on your data
Your prompts and the answers to them are never used to train or test a model that anyone else uses.
Where your data sits
Everything the system needs runs inside the environment you pick. Nothing calls out to an outside provider, so there is no traffic to inspect and no copy to worry about.
A data centre in your country answers the residency question. It does not answer the jurisdiction question, which depends on who controls the machines. On-premise and private cloud answer both.
How someone gets in
Three gates, in this order. A request that fails any of them is written to the log and goes no further.
Your own login
People sign in through the identity provider you already use — ADFS, Google, Okta, or any OAuth2 provider.
A second factor
A one-time code by SMS or email, or a fingerprint.
Their role decides the rest
What someone can open, edit or export is set by role, department and function. Personal data is hidden from roles that do not need it.
How the data is protected
On the way in and out
Once it is stored
What each deployment gives you
Pick the row that matches what your security team needs to be able to say.
Check it yourself
Every certificate on this page carries its number, and every issuer runs a public register you can search.
You also get a staging environment to test the access rules before go-live, and the audit trail is yours to export whenever you want it.
Our certificates
Certificates confirm the system above. They do not replace it. Each one can be checked with its issuer.