security --model --verbose
ऐसी सुरक्षा जिसका आप हिसाब रख सकें।
एक security product को अपने model के बारे में स्पष्ट होना चाहिए। यहां ठीक वही है कि Kutrion आपके credentials और sessions की सुरक्षा कैसे करता है — और क्या दावा करता है, क्या नहीं।
broker --explain
Broker आपका access कैसे संभालता है
Authorized session के लिए memory में decrypt करें, policy और JIT लागू करें, host तक broker करें, और हर step रिकॉर्ड करें।
Envelope encryption for credentials at rest
Every credential in the vault is encrypted with a per-record data key, which is itself wrapped by a key-encryption key. Keys are rotated and never stored beside the data they protect. Outside the vault, two places are not sealed yet: values in synced API environments, and a password an AI agent types into a command, which that command's audit record masks in the common forms but not every form. Terminal recordings, their summaries and command history are stored unsealed.
Post-quantum ready
Key exchange uses a hybrid ML-KEM construction and license signatures use composite ML-DSA, so a captured session can't be unlocked by a future quantum adversary — alongside AES-256 and SHA-256, which are already quantum-resistant.
Audited access broker
The server decrypts a credential in memory only for an authorized, audited session — then discards it. We do not claim zero-knowledge; we claim a broker you can actually account for.
Phishing-resistant sign-in
Sign in and step up with passkeys and security keys (WebAuthn) across the web app, mobile and the admin plane — phishing-resistant by design, with TOTP and backup codes as fallbacks.
Hash-chained audit log
Credential reads, sessions, grants and revocations are written to a hash-chained audit log, where tampering is detectable, and attributed to a person. It does not record everything yet: some refusals, transfers that fail before the first byte, and connection deletes are missing, and whether a privileged database role can alter an audit row has not been tested. Session recordings are kept under your retention policy and are not part of the chain.
Privacy-first AI
AI assistance defaults to a self-hosted model rather than a cloud one. An organization can opt in to a cloud fallback, which also needs a configured key and the cloud_ai entitlement. Terminal output and credentials do not reach a cloud model unless an organization admin opts one in — that opt-in, not the redaction step, is the control. Which network the model runs on is a separate question: self-hosted installs run it on yours, and on the hosted service it is the deployment's own until you point us at an endpoint you operate. When cloud assist is on, credentials, keys and PII are removed from the payload and every send is audited, but the command text and output around them still reach the model. The AI privacy model doc sets out both deployment cases and exactly what is removed and what is sent.
Least privilege & JIT
Role-based access to shared vaults plus just-in-time elevation that expires on its own. No standing credentials scattered across laptops.
Built on a modular monolith
A single hardened backend with clear module boundaries — auth, vault, ssh, terminal, audit — rather than a sprawling attack surface to secure.
HSM-backed master key, yours on self-hosted
Kutrion wraps every data key with one envelope-encryption master key per deployment. Self-hosted, the deployment is yours: seal that master under your own HashiCorp Vault Transit key — itself HSM- or auto-unseal-backed — so it is unsealed only in memory at boot and never sits at rest. On the hosted service the master belongs to the deployment we operate; it is not issued per customer.
Streams to your security stack
Forward security events in real time to Splunk and Microsoft Sentinel, sync credentials with your own HashiCorp Vault (KV v2), and provision via SCIM — Kutrion fits the SIEM and secrets-manager stack you already run.
अक्सर पूछे जाने वाले सवाल
Is Kutrion zero-knowledge?
No — and we won't pretend otherwise. Kutrion is an audited access broker: the server decrypts in memory for authorized, audited sessions so it can broker SSH access and enforce policy. There is no plaintext credential material at rest in the vault; synced API environment values are not sealed yet, and a password an AI agent types into a command is masked in that command's audit record in the common forms but not every form. Access is written to a hash-chained audit log, which does not cover every event yet.
Where does my data live?
Credentials are envelope-encrypted at rest. Enterprise plans support data-residency controls, and AI can be pointed at a model you operate so sensitive output stays on your own network — the AI privacy model doc explains what that takes on the hosted service and on a self-hosted install.
What is your compliance posture?
Kutrion is built toward SOC 2, with audit logging, access controls, and tamper-evident records as first-class features. A DPA and subprocessor list are available for enterprise customers.
How do you handle AI and my terminal output?
AI defaults to a self-hosted model rather than a cloud one, so nothing reaches a cloud model unless an organization admin opts one in — that opt-in, not the redaction step, is the control. That default says which kind of model answers, not whose network it runs on: on a self-hosted install it is yours, and on the hosted service it is the deployment's own until you point it at an endpoint you operate. When cloud assist is on, secrets and PII are stripped from the payload and every send is audited, but the operational content around them still reaches the model. See the AI privacy model doc for the measured figure and both deployment cases.
Can we manage our own encryption keys?
On a self-hosted install, yes. Kutrion has one envelope-encryption master key per deployment, and every data key in that deployment is wrapped by it — so the answer turns on who runs the deployment, not on which plan you are on. Self-hosted, you do: point KEY_PROVIDER at your own HashiCorp Vault Transit key — which can itself be HSM- or auto-unseal-backed — and the master is sealed under a key you hold and unsealed only in memory at boot. On the hosted service that master is the deployment's own, so an Enterprise plan there does not give your organization a separate key that no other tenant's data sits under; per-organization keying is not something we offer today. Per-record data-key wrapping stays local in both cases, so there is no hot-path cost and no plaintext credential material at rest.
Can Kutrion plug into our SIEM and secrets manager?
Yes. Security events stream in real time to Splunk and Microsoft Sentinel (plus Slack, PagerDuty and webhooks), a pull Events API covers full-stream export, and Enterprise can sync credentials with your own HashiCorp Vault (KV v2) — push, pull or bidirectional with conflict detection.