Privacy Policy

Who this policy applies to

Kutrion is a credential vault and an audited access broker. Organisations use it to store secrets and to reach their own hosts, and every access is recorded against the person who made it.

For the data your organisation puts into Kutrion, your organisation is the controller and Kutrion is the processor: we handle it on your instructions to run the service. For your own account and billing records, and for this website, Kutrion is the controller. The Data Processing Agreement sets out the processor side in full.

If you run Kutrion yourself, the deployment is yours. The behaviour described here is the software's; the operator of that install decides where it runs, who administers it and how long they keep it, and they — not Kutrion — hold your data.

What the service stores

• Vault content — logins, SSH keys, API keys, environment files and secure notes. Credential material is sealed with a per-record data key, which is itself wrapped by the deployment's master key; the master key is held by the configured key provider and never stored beside the data. No plaintext credential material is written at rest.
• Connection and access records — the hosts, usernames, teams, roles, grants and just-in-time elevations that decide who may reach what.
• Activity records — every secret read, session, grant and revocation, written to a tamper-evident audit trail. Commands run through the broker are recorded as issued, and on plans that include session recording every brokered shell session is recorded in full — automatically, not per session. The envelope described above covers credential material; session recordings, their generated summaries and command history are stored as content rather than as sealed secrets, isolated per organisation and reachable only through the access controls on the deployment.
• Account and device records — your email address, username, a hash of your password (never the password), your multi-factor and passkey enrolments, and one record per signed-in device carrying its IP address and browser or client identification so a session can be reviewed and revoked.
• Billing records — your subscription, invoices, tax details and payment references. Card numbers are never stored by Kutrion: the card is submitted to our payment subprocessor and tokenised there, and Kutrion keeps only the token reference plus the last four digits and card network so you can recognise the card you saved.
• Website data — this site's analytics are first-party and cookieless. A page view or a click on a call to action records the page path, the referrer and any campaign labels in the link you arrived from. No cookie, no identifier, no IP address and no third-party analytics script is involved. If you submit the contact form, the name, email, company and message you entered are stored along with the IP address and browser identification of the submission, and emailed to our sales inbox.

How the service processes it

Kutrion is an audited access broker. When you or a policy-approved automation asks for a secret or a session, the server decrypts that secret in memory for that authorised action, injects it into the session, and discards it. The server is therefore able to read a secret it holds, and we say so plainly rather than implying otherwise: what the design gives you is not a server that cannot look, but a server that cannot look without leaving a record. Every read and every session lands on the audit trail, attributable to a person and a device. The security page states the model in full, including what it does not cover.

We do not sell your data, we do not share it with advertisers, and we do not use your secrets, your sessions or your terminal output to train models.

AI, and what leaves the deployment

AI assistance defaults to a self-hosted model (Ollama), never a cloud one. Whenever a self-hosted model is available, that is where a prompt goes.

A prompt reaches a cloud model only when all three of the following are true, and each is off until someone deliberately turns it on:

• a cloud provider key is configured on the deployment;
• an administrator of your organisation has switched cloud AI on for that organisation — the setting is off by default;
• your plan carries the cloud_ai entitlement, which the free tier never has.

If any one of them is missing there is no cloud path at all. When all three hold and a prompt does go out, it passes a secret-and-PII filter first — credentials, API keys, private keys, JWTs, email addresses, IP addresses (IPv4) and payment card numbers are removed — and the send is written to the audit trail with a preview of exactly what was sent. That filter is not a transcript filter: command text, output, SQL, hostnames, file paths and the names of people and customers are retained and do reach the model, measured at about 90 percent of a 40,000-character operations transcript. The AI privacy model doc sets out the measurement, both deployment cases, and the treatment of an endpoint you supply yourself.

Where it runs, and who else is involved

On the hosted service, the hosting region is configured per deployment, and enterprise customers can arrange data-residency requirements as part of their agreement. On a self-hosted install, it runs wherever you install it: the licence verifies locally, so an air-gapped deployment works with no call home.

Kutrion keeps its third-party footprint small. The subprocessors page lists every subprocessor with its purpose and location, and account contacts are notified of material changes before they take effect. The AI subprocessor listed there is engaged only for organisations that have opted a cloud model in, under the three conditions above.

How long it is kept

Audit records are kept, not pruned. The trail is sealed into a hash chain, so deleting entries would destroy the evidence the trail exists to provide. The retention figure attached to your plan is a guaranteed minimum of history — the period we commit to keeping queryable — and not a schedule on which records are deleted.

Session recordings and command history are kept until they are deleted. You can delete your own session recordings from the app at any time; there is no automatic expiry on them today.

Short-lived authentication artefacts are removed automatically once they can no longer be used: unredeemed sign-up, password-reset and email-change codes are deleted past their expiry, unconfirmed authenticator enrolments are deleted after thirty minutes, and expired or long-revoked invitations are swept out.

Not yet stated here: a published retention period for account, organisation and billing records after an account ends, for session recordings and command history, and for website analytics rows and contact-form submissions. We would rather leave this gap visible than publish a period we have not committed to. Where a specific period matters to your review, agree it in writing with us — contact us and we will state the current practice and the commitment we can make.

Getting your data out, and getting it deleted

Data export is per surface rather than one archive: vaults, members, connections and the audit trail each export from the app, and an organisation administrator can pull a live inventory of everything the organisation holds, generated from the tables rather than from a document that drifted. Session recordings are the exception: they download one session at a time, and a bulk take is an assisted request rather than a self-service one. The inventory says which is which.

Deleting individual items — a credential, a connection, a recording, a member — is self-service. Erasing an entire account or organisation is not: there is no self-service button for it today, and it is carried out by us on a verified request from an owner. When it runs, it is a hard delete of that tenant's records rather than a flag. Audit records are the exception and are retained as compliance records, carrying the historical identifiers of what was erased.

To make a request about your data, or to ask what we hold about you, contact us. If your data sits in an organisation's Kutrion account, we will route the request through that organisation, because they are the controller for it.

Security incidents

If we become aware of a personal-data breach affecting your data, we notify the account's designated contact without undue delay and share what you need to meet your own notification obligations. To report a vulnerability or an abuse issue, see the security page.

Changes to this policy

When this policy changes materially, we update the date at the top of the page and notify account contacts. The subprocessor list is maintained separately and carries its own change notice.

Contact

Questions about this policy or your data: our contact page.