Security model

Kutrion is an audited access broker — not zero-knowledge. We state that plainly because it is the honest description of what the server does, and because the choice shapes everything else about the design. The server decrypts a secret in memory only for a specific authorized, audited action, and that act is always recorded.

The model, stated plainly

• Envelope encryption throughout. Every record is sealed with its own data key, which is itself wrapped by a master key. Keys are never stored beside the data they protect.
• No plaintext credential material at rest. Secrets are only ever decrypted in memory, for the duration of an authorized action, and then discarded.
• Decrypt only for an authorized action. There is no bulk decryption and no standing plaintext — decryption is tied to a specific, permitted operation.
• Access on a tamper-evident trail. Reads, brokered sessions, and security events are written to a hash-chained audit log in which tampering is detectable; a few event types are not recorded yet. See Audit logs.

A strict zero-knowledge design would make the server unable to do the things teams need — broker an SSH session, inject a credential just-in-time, scan command output for a leaked secret. Each of those requires the plaintext, in memory, at the moment of use. We chose the broker, and we made it accountable rather than pretending it is blind.

Multi-tenant isolation

Tenants are isolated at the database using Postgres row-level security. Every tenant table is scoped by org_id, derived from the authenticated context, and the policy is forced even for the table owner — there is no query path that quietly returns another tenant’s rows. See Tenant isolation.

Privacy-first AI

AI assistance defaults to a self-hosted model rather than a cloud one. There is no configuration in which a cloud model is the silent default. Where that self-hosted model runs, however, depends on the deployment, and the two cases are not the same:

• Self-hosted Kutrion. AI is off until an operator turns it on and points the server at an Ollama endpoint. That endpoint is one you run, so prompts and terminal output are answered on your own network.
• Hosted Kutrion. The default is the instance’s model — the Ollama endpoint the operator of the deployment has configured — which is Kutrion’s infrastructure, not yours. Putting inference on your own network is a configuration step, not the default: an organization admin points Kutrion at an Ollama endpoint you operate. That setting is available on every plan.

In both cases the cloud model is a separate path that stays shut unless three things line up together: a configured cloud key, a per-organization opt-in that is off until someone turns it on, and the cloud-AI plan entitlement. Anything that does go out has secrets and PII stripped first and is recorded on the audit trail, but that step is a filter rather than a gate: it removes shaped values, not the operational content around them — command text, terminal output, hostnames and file paths still reach the model. The privacy model, including the measured passthrough figure and what each deployment actually gives you, is in AI privacy model.

Product-protection layer

For self-hosted deployments, Kutrion adds protections that bind the software to where it is licensed to run:

• On-prem key binding. The master key’s unlock is derived from the host environment, a hardware root, and the license signature, so a licensed instance cannot simply be cloned to unlicensed hardware. See Cryptography.
• Honeytokens. Decoy credentials and tripwires detect tampering and unauthorized use; their state is surfaced to operators in the admin console. A decoy is a whole credential, never a key inside one — a decoy placed inside a multi-secret credential such as an environment-variable bundle has no record of its own and would never raise an alarm, so decoys are seeded as standalone credentials.

Related pages

• Cryptography — envelope encryption, key providers, and post-quantum posture.
• Tenant isolation — the row-level-security model.
• Architecture overview — how the system is put together.