Zero-knowledge vault design changes the password manager trust model

At a glance

What this is: This is a zero-knowledge architecture explainer showing how 1Password says it cannot read vault contents, and why that matters as password managers connect humans, NHIs, and AI agents.

Why it matters: It matters because IAM teams increasingly rely on password managers and secret stores as policy boundaries, so verifiable cryptographic limits are becoming as important as access policy and audit logging.

By the numbers:

• Only 44% of organisations are currently using a dedicated secrets management system.

👉 Read 1Password’s explanation of zero-knowledge vault architecture

Context

Zero-knowledge architecture is a design pattern where the service provider cannot decrypt customer data because the keys never leave the customer device. That distinction matters for password managers, secret stores, and any identity platform that handles sensitive credentials, because policy alone does not stop a compromised service from seeing plaintext if the architecture allows it. In IAM terms, this is a control boundary problem, not just a trust statement.

The article is really about what changes when a password manager becomes part of the broader identity and secrets plane for humans, NHIs, and AI agents. Once a service is expected to support search, reporting, or delegation workflows, the question is no longer whether the vendor promises restraint. The question is whether the system can technically avoid ever holding the readable data in the first place.

Key questions

Q: How should security teams evaluate zero-knowledge claims in password managers?

A: They should verify where encryption happens, who holds the keys, and whether the provider can ever access plaintext during normal operation or cloud processing. A true zero-knowledge design should make backend compromise far less useful because stored data is ciphertext only. The test is architectural, not contractual, and the strongest evidence is local encryption plus verifiable key custody.

Q: Why do zero-knowledge password managers matter for NHI and secrets governance?

A: They reduce the number of places where secrets can be exposed, which matters when service accounts, API keys, and human credentials are all managed through the same platform. If the provider cannot read vault contents, then a backend breach or internal access event is less likely to reveal usable secrets. That shifts governance toward endpoints, recovery flows, and delegated access paths.

Q: What breaks when a password manager offers cloud features that need plaintext access?

A: The zero-knowledge boundary breaks the moment the provider must see readable data to perform a feature. At that point, the product may still be secure, but it is no longer zero-knowledge for that workflow. Teams should assume that convenience features can quietly expand exposure unless the processing model is explicitly isolated and independently verifiable.

Q: How can organisations tell whether confidential computing is actually protecting sensitive identity data?

A: They should look for hardware-backed isolation, published enclave code, and cryptographic attestation that lets them verify what ran inside the protected environment. If those pieces are missing, the cloud feature is relying more on trust than on technical containment. That is a weak position for identity and secrets workflows that handle high-value credentials.

Technical breakdown

Device-side encryption and key custody

In a zero-knowledge design, encryption happens before data leaves the user device, and decryption keys never transit to the service provider. The provider stores only ciphertext, which is unreadable without the customer-held key material. In 1Password's model, the Secret Key and account password are combined locally, which means the server cannot recover the vault contents even if infrastructure is compromised. This is stronger than a policy promise because the provider cannot simply decide to inspect plaintext later. It is an architectural limit, not a procedural one.

Practical implication: treat key custody as a design control and verify where encryption and decryption actually occur.

Confidential computing and sealed cloud processing

Some enterprise features require server-side computation, which creates tension in any zero-knowledge system. Confidential computing resolves that by running code inside a hardware-enforced enclave that isolates processing from the rest of the cloud stack. The enclave uses verified code execution and cryptographic attestation so customers can check what is running inside it. That matters because it reduces the need to trust the cloud host or the service operator with readable data during processing. The architecture narrows the exposure window while still enabling cloud-scale functions.

Practical implication: require attestation evidence for any cloud-side feature that claims to process sensitive identity data securely.

Zero-knowledge tradeoffs in password managers and AI access

Zero-knowledge is not free. If the provider cannot see plaintext, it cannot offer server-side search, plaintext recovery, or broad cloud inspection features. The article also ties this to a wider identity pattern: password managers are becoming access layers for browsers, developer tools, workplace automation, and AI-powered agents. That means the trust model is expanding from human convenience to machine mediation. The technical question becomes whether access can be granted to the right tool at the right time without introducing a readable central point of failure.

Practical implication: evaluate whether any convenience feature quietly reintroduces plaintext exposure into the identity stack.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Zero-knowledge is a control boundary, not a branding claim. The article’s core point is that the service cannot read vault contents because the architecture makes that impossible, not because a policy says so. That distinction matters across human credentials, NHI secrets, and agent access because trust statements fail the moment a provider, host, or attacker can observe plaintext. Practitioners should treat this as an architectural constraint that changes what the platform can ever be asked to do.

Verifiable cryptography is now an IAM requirement, not a niche privacy feature. Password managers increasingly sit at the center of human sign-in, secrets distribution, and automation access. When a platform is part of the control plane for identities, the ability to prove what it cannot see becomes operationally relevant. This aligns with the NIST Cybersecurity Framework 2.0 emphasis on govern and protect functions, because the trust boundary itself must be demonstrable, not assumed.

Static trust assumptions break down as AI agents enter the credential path. The article points to AI-powered agents that can take actions on behalf of users, which pushes password managers beyond simple storage into delegated access. That creates a named concept worth tracking: plaintext exposure boundary, the point at which an identity system can no longer guarantee that sensitive data stays unreadable. Practitioners should recognise that once this boundary shifts into cloud processing, architecture rather than policy becomes the decisive control.

Zero-knowledge changes the failure mode from compromise of a service to compromise of endpoints. If the provider cannot decrypt data, attackers gain less from breaching the backend and more from targeting devices, recovery paths, or user authentication. That does not eliminate risk, but it reassigns where governance and detection effort should sit. For identity programmes, the implication is that backend resilience alone is insufficient when key custody is intentionally distributed.

Confidential computing validates a broader governance pattern for secrets processing. The article shows why certain enterprise functions need cloud computation without reverting to plain trust in servers. That same pattern will matter as organisations centralise secrets, automate credential checks, and extend identity workflows into machine and agent ecosystems. Practitioners should use this as a benchmark for whether a platform's cloud-side convenience features preserve the original security model.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
• That confidence gap is why practitioners should also review Ultimate Guide to NHIs , Static vs Dynamic Secrets when deciding how much plaintext exposure their workflows can tolerate.

What this signals

Plaintext exposure boundary: identity programmes should now map the exact point where readable credentials can exist, because that boundary determines whether a platform is truly zero-knowledge or merely policy-restricted. With 85% of organisations lacking full visibility into third-party vendors connected via OAuth apps, per The State of Non-Human Identity Security, the problem is no longer only storage. It is the entire chain from key custody to delegated access.

As password managers absorb more automation and AI-adjacent use cases, teams should assume that cloud-side convenience will keep pressuring the original trust model. The practical response is to verify attestation, recovery paths, and endpoint custody together, then align that design with NIST Cybersecurity Framework 2.0 govern and protect functions.

For practitioners

• Verify key custody boundaries Map exactly where encryption, decryption, and recovery occur in your password manager and secrets tooling. Require a clear answer on whether the provider ever receives plaintext or decryption material.
• Demand attestation for cloud-side processing For any feature that processes sensitive identity data in the cloud, require hardware-backed attestation, published execution code, and a documented trust model for the enclave or equivalent control.
• Reassess convenience features that imply server visibility Test whether search, reporting, breach checks, or analytics force plaintext exposure anywhere in the workflow, especially when the same platform also supports human logins and automated access paths.
• Separate backend compromise from endpoint compromise in tabletop exercises Run scenarios that assume the provider backend is unreadable but endpoints, recovery channels, or delegated access are targeted instead, then update monitoring and incident response assumptions accordingly.

Key takeaways

• The central risk is not just secret storage, but whether any part of the identity workflow can ever see plaintext.
• The evidence points to a market-wide confidence gap in NHI visibility, which makes architectural proof more valuable than policy language.
• Practitioners should audit key custody, cloud processing, and recovery paths together, because zero-knowledge fails when any one of them reintroduces readable data.

Key terms

• Zero-Knowledge Architecture: A design pattern in which the service provider cannot decrypt customer data because it never receives the keys needed to do so. The provider may store encrypted data and coordinate sync or processing, but it remains technically unable to read plaintext unless the architecture is broken.
• Confidential Computing: A method of processing sensitive data inside a protected hardware enclave so the cloud operator cannot inspect the data while it is in use. It combines isolation, attestation, and controlled execution to reduce exposure during cloud-side computation without forcing plaintext access.
• Plaintext Exposure Boundary: The point in a workflow where readable secrets can exist, whether on a device, in transit, or inside a processing environment. In identity and secrets governance, this boundary matters because every readable state expands the number of systems and actors that can leak or misuse credentials.

Deepen your knowledge

Zero-knowledge vault design and secret custody are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are evaluating password managers or secrets platforms with similar trust constraints, it is worth exploring.

This post draws on content published by 1Password: Zero-knowledge, not promises: How 1Password secures your data. Read the original.