Both factors, or neither
A username, a password and a code from your authenticator tool. The session is issued after both factors and only after both.
Security and sovereignty
Your identity. Your keys. Your infrastructure.
A password and an authenticator code every time, plus your own identity provider if you have one.
Your data is the only thing the AI can reach.
Wherever you run it, leave AI off and nothing leaves your network at all.
The AI works inside a database engine started with external access switched off. It reads the data you gave it and nothing else on the machine. The boundary is the engine itself, not a list of words to watch for. How a question is phrased makes no difference to it.
Two factors, every time.
The second factor is built into the product.
Passwords are expensive to crack
Each one is hashed with scrypt at N=2^17, which is deliberately slow and memory-hungry, so a stolen file is worth very little to whoever took it.
The login page keeps your roster private
A wrong email and a wrong password take the same time, because both walk the same work. Timing tells an attacker nothing about who has an account here.
Guessing gets slower, quickly
Rate limiting and lockout run per account and per address, and they are checked before the expensive hashing, so they cap the machine cost as well as the guessing.
Bring your own identity provider.
You type your work email
Home-realm discovery reads the domain and sends you to the identity provider that owns it. Nothing else about you is needed to route the request.
Your own provider signs you in
Any SAML 2.0 identity provider, connected one per client email domain. Your people meet the sign-in screen they already know.
The assertion is checked against that tenant
It is validated against that connection’s own certificate, and the asserted email is anchored to that connection’s own domain.
One organisation’s provider mints one organisation’s session
Because the binding is to the domain, a signed assertion from one tenant resolves to that tenant and to that tenant alone.
A response has to answer a request we made
Sign-in starts here, and each request carries a single-use nonce that is spent the moment it comes back, so a replayed response has nothing left to spend.
Sessions end on a schedule you set.
Thirty minutes idle, twelve hours absolute, and an access change that lands on the next request.
- 01Thirty minutes idle
Step away and the session closes itself. Coming back costs you ten seconds, and it costs whoever finds your laptop rather more.
- 02Twelve hours, absolute
The long cap stands on its own. Activity slides the idle timer and leaves the twelve hours exactly where it was. A session has an end even on the busiest day.
- 03Access changes land on the next request
Disable someone, rotate a password or reset an authenticator, and every live session they hold is finished the next time it is used.
- 04Roles are read fresh, every request
No role ever travels inside a token. A change in the directory is in force immediately.
The console always has a way in.
An atomic guard keeps at least one active administrator at all times. It is a small rule, and it is the difference between a tidy afternoon of housekeeping and a support ticket nobody enjoys writing.
Nothing leaves your network unless you send it.
Every tool is complete without AI.
- 01No AI at all
Every tool produces its complete result on its own deterministic engine. Leave AI off and nothing reaches a model provider at all.
- 02Your key, your provider
Switch it on and it runs on the key you supplied, with the provider you chose, under the terms you negotiated with them. We supply no key and hold no shared pool.
- 03Your own endpoint
The OpenAI-compatible client accepts any endpoint you name. Point it at a proxy running inside your own network and nothing leaves it at all.
Evidence in the shape your framework asks for.
Every finding carries a CIS Controls v8.1 Safeguard ID and a NIST CSF 2.0 function.
Guard tags every finding it raises with a CIS Controls v8.1 Safeguard ID and a NIST CSF 2.0 function, deterministically, and that tag travels with the finding into its CSV, its SARIF, its PDF and the screen. Your auditor receives a finding with the control reference already attached, in a format their own tooling reads.
That is mapped audit evidence. It is not a certification, and this product does not issue one.
Your audit trail writes itself while you work.
Governed changes land in a hash-chained ledger using plain SHA-256 with no secret key, so your auditor can re-verify its integrity from the export with their own tools.
Hardened from the container up.
Built into the image. Gated in the pipeline that produced it.
| Layer | What is in place |
|---|---|
| The container | The application runs as an unprivileged user, uid 10001. Root is used once, to take ownership of the data volume, and dropped before anything starts. |
| Every response | Security headers on all of them, including a policy that keeps the tool out of anybody else’s frame. |
| Sign-in | Rate limiting and lockout, per account and per address. |
| Every change | A CSRF token on every mutation, bound to your own session. |
| Files on disk | Written atomically at 0600. A half-written secret is never a readable one. |
| Encryption | A separately derived key for each purpose. One secret never quietly does two jobs. |
| Dependencies | Every one pinned to an exact commit, the gateway included. |
| The shipped image | Carries no package installer inside it. |
| The pipeline | A vulnerability scan that fails the build, running against an ignore list that is empty. |
Take it to your security team.
Ask for the source behind any claim on this page.