Question 41 on the questionnaire reads: “Is customer data encrypted with keys held only by the customer (zero-knowledge)?” The MSP’s technical lead has two vendors’ answers open on a Tuesday afternoon. One says yes. Ours says no, and then spends a paragraph explaining why a vault that can inject a credential into a session must be able to decrypt it. She has until the end of the day to decide which answer her auditor will accept, and which one is describing the product she is actually buying. They are not the same question, and this post is about why.
Zero-knowledge means the operator of a system cannot read your data even if they want to, because only you hold the key. It is the right design for a password manager on your phone: you type the master password, your device decrypts, and the vendor never could. It is the wrong design for a credential vault that has to open a server for a technician without showing them the password, and we would rather explain that than let a questionnaire assume otherwise.
Because injection happens on the server. When a technician connects to a host through Guardian Vault, the credential is resolved server-side and injected into the session; the plaintext never reaches their browser. For the platform to inject it, the platform must decrypt it. Break-glass access with a reason and a second approver needs the same thing. So does recovery when someone leaves and their credentials must outlive them. All three require that shared credentials be decryptable by the platform. That is a design choice, and it is the one that makes “never shown” possible.
AES-256-GCM at rest, with a fresh initialisation vector per record. Authenticated encryption means a tampered record fails to decrypt rather than returning garbage. It covers credentials, documents, ticket contents and integration secrets.
A key per scope: derived from the master per company, and per person for private vaults, so one company’s key can never open another’s data. Keys are not shared across the platform.
Refuses to start blind: on boot the service proves it can decrypt with the key it was handed. If it cannot, it exits rather than run half-blind.
Every reveal is an event: who, when, from where, and which permission allowed it, including administrator overrides, recorded before the secret is returned.
What is inside that envelope is everything secret: vault credentials (passwords, secrets, SSH keys, one-time-password seeds and custom fields), integration secrets such as vendor API keys and directory bind passwords, and the agent keys, which live in each agent’s config file with owner-only permissions. Encryption happens before any of it reaches the database.
Everyone gets personal space alongside the shared company vaults. Personal items are encrypted with a key derived for that person, and the owner-only rule is checked before any administrator override, including a super admin; an attempt is refused and recorded as its own event. This is enforced by policy and audit rather than by cryptography. An operator holding the master key and the database could still decrypt, and we say so, because the alternative is a questionnaire answer that is true in the demo and false in the incident.
Every credential reveal records who, when, from where, and which permission allowed it. Every sign-in and every failure goes to an authentication log that cannot be edited or deleted through any interface. The audit trail is append-only. It is not hash-chained, and we will not call it tamper-proof. A questionnaire that asks for “immutable audit logs” gets that sentence, not a yes. The one-audit-trail argument, and why it is one trail across every module, is in one audit trail; break-glass itself is in break-glass with a reason.
Shared credentials are decryptable server-side by design, because injection, break-glass and recovery depend on it. Private items are protected by policy and audit, not by cryptography. Terminal and desktop sessions are relayed through the platform: TLS-protected end to end, not end-to-end encrypted in the cryptographic sense.
Vague answers cost everybody a week. These three are precise enough to rule us in or out, and they are the same three we give in every evaluation. Put them in the answer to question 41 and the auditor has what they need to verify rather than a claim to chase.
The zero-knowledge yes has a hidden price. If the browser decrypts, the technician sees the password, and a technician who has seen a password is a rotation waiting to happen: every credential they ever saw, on the day they leave, which is the reconciliation that eats a week per departure. With server-side injection there is nothing to rotate on that day, because nothing was shown. Deactivate the person once and every product session ends immediately. The cost of our design is a sentence on a questionnaire. The cost of the other is a weekend.
Hosting, encryption, access control, audit, the AI, the agent, and what we do not do, in the order a questionnaire asks.