Privacy Policy

Who this policy applies to

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

For the data your organization puts into Kutrion, your organization 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 behavior 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 credential 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 and are not sealed like credentials, isolated per organization 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 enrollments, 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 tokenized there, and Kutrion keeps only the token reference plus the last four digits and card network so you can recognize 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 credential or a session, the server decrypts that credential in memory for that authorized action, injects it into the session, and discards it. The server is therefore able to read a credential 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 credentials, your sessions or your terminal output to train models.

AI, and what leaves the deployment

AI assistance defaults to a self-hosted model (Ollama) rather than a cloud one. Once an organization has turned cloud AI on, a prompt can go to a cloud model instead, when a member asks for cloud on that request or when an administrator makes cloud the organization's AI provider. If the self-hosted model is unavailable, a prompt is not sent to a cloud model in its place.

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 organization has switched cloud AI on for that organization — 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 SHA-256 hash and the character count of what was sent. The filtered text itself (its first 2,000 characters) is kept on that record only if an administrator of your organization turns that setting on; it is off by default. 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 license 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 organizations 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 artifacts 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 enrollments are deleted after thirty minutes, and expired or long-revoked invitations are swept out.

Not yet stated here: a published retention period for account, organization 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 organization administrator can pull a live inventory of everything the organization 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 your own account is now self-service: delete it from the app or the web app, or see the account deletion page. Erasing an entire organization, with everyone in it, is not, and is carried out by us on a verified request from an owner. A request is verified when an owner of that organization confirms it to us from the email address registered to their Kutrion account; a request from any other address is answered, but nothing is erased on it. Either way it is a hard delete of those records rather than a flag. Audit records and entitlement and subscription history (7 years) 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, use the data request form. We respond within one month of receiving it. If your data sits in an organization's Kutrion account, we will route the request through that organization, 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.