DEV Community: Passwork Team

Why your password manager shouldn't have a "god mode"

Passwork Team — Mon, 24 Aug 2026 23:53:17 +0000

Your lead DevOps engineer quits on a Friday, no notice, master password included. Or maybe it's simpler: your company's sole founder comes back from a two-week trip and just... can't remember it.

Either way, someone in the room asks the question we hear on almost every technical call about Passwork: "Is there a backdoor for this? A way to just unlock everything?"

The honest answer is no, and that's on purpose. Any "restore everything" button that can instantly decrypt all data in a password manager is a massive single point of failure (SPOF). If you build a backdoor for emergencies, you've also built a front door for attackers. Compromise one account, get everything. That's not a feature, that's the whole system's threat model collapsing into a single credential.

This post is about how we designed access recovery for a zero-knowledge password manager without that button. Instead of one god-mode admin, we split recovery into three isolated layers, each with a narrow job and a hard boundary on what it can't do. We think the pattern generalizes past our own product, so we're sharing the reasoning, not just the feature list.

The zero-knowledge dilemma

Zero-knowledge architecture means the server only ever sees ciphertext. Encryption and decryption happen client-side; the server stores encrypted blobs and has no way to read them without a cryptographic grant, a wrapped key handed to a specific user for a specific vault.

This is great for security and terrible for anyone who assumes recovery works "somehow." If nobody sets up a recovery path before an incident, the math is unambiguous: the data is gone. Not "hard to get," not "requires a support ticket." Gone, because the server never had the key in the first place.

We treat this as the correct trade-off, not a bug to work around. The alternative, a server that can always decrypt on demand, means every password in the vault is one server compromise away from a breach. But it does mean recovery can't be an afterthought. It has to be architecture, decided and configured before anyone needs it, not improvised during an incident at 2 a.m.

So the design question becomes: how do you let an organization recover from losing an account, a device, or an employee, without ever creating a single credential that can decrypt the whole system?

Deconstructing "god mode": our three-tier recovery model

We ended up splitting recovery into three tiers, each solving one narrow problem. None of them, alone or combined, produces a master key to everything. That's the point.

Tier 1: Infrastructure level, the emergency console

The first tier answers a login problem, not a data problem: what if the Owner (the top-level system administrator) can't get into their own account and normal recovery, like an email link, isn't available?

For this we built an emergency console: a set of CLI commands that run on the server itself, not through the web UI. An admin with server access can use it to reset the Owner's password or two-factor authentication when the normal recovery path isn't available.

Two things gate this deliberately:

It requires server-level access, via SSH or console, rather than a button in the interface.
The emergency commands are locked behind a state flag that the server admin has to explicitly enable before they can run.

The emergency commands stay disabled by default and become available only after a server administrator explicitly enables the required state flag. Deliberate activation protects the recovery path from accidental use and keeps it beyond the reach of someone with web application access alone.

The key boundary is that the emergency console restores login access while preserving the existing cryptographic access model. Resetting the Owner's password lets them sign in again with exactly the vault permissions they had before the incident.

Vault decryption still depends on cryptographic grants issued in advance. In other words, the emergency console solves the account-access problem, while access to vault data remains governed by the existing grants.

Every use of it gets logged as a distinct event: password reset, 2FA reset, whatever ran. It's traceable, not a quiet backdoor.

Tier 2: Data level, the offline recovery account

Fixing login solves half the problem. The other half: what if the person who actually had the cryptographic grant to a vault is the one who's gone?

Our approach relies on pre-shared cryptographic grants, set up before anything goes wrong rather than improvised during the incident.

In practice: create a standard user account (not an Owner, not a service account), assign it as administrator for the specific vault types your team cares about, then print the master password and put it in a physical safe, a bank deposit box, or another team's offline vault.

The classic break-glass pattern works because the cryptographic access is already in place before the emergency. There's no way to retroactively grant access to a vault after the fact if nobody set up the grant beforehand. If your recovery account only has access to two vault types today, that's exactly what it'll be able to recover next year, no more.

The scope is deliberately narrow. This account isn't root. It's a targeted key to a defined set of vaults that someone consciously decided were worth this level of insurance. Wider coverage means assigning more vault types to it, and thinking harder about how you're storing that offline password.

Tier 3: Automation level, service accounts aren't a backdoor

The third tier is less about recovery and more about closing a mistake we've seen teams make: treating a service account as an emergency login.

A service account exists for automation, onboarding scripts, CI/CD pipelines, identity provider sync, anything that needs programmatic access to the API without a human typing a password. It authenticates with API tokens.

Critically, a service account is designed exclusively for programmatic access through API tokens. Interactive login remains unavailable. That separation is a deliberate design decision: allowing interactive access would turn a narrowly scoped automation credential into a quiet backdoor, potentially sitting in a CI secret store with privileges beyond its intended purpose.

If a token leaks, the blast radius is whatever that integration was explicitly granted, and nothing else. It's still bound by the same access-grant rules as any other account. It doesn't become a master key just because it's automated.

The architecture at a glance

The three recovery tiers solve different problems and deliberately stop at different boundaries.

The emergency console restores access to the Owner account when normal login recovery is unavailable. It requires server-level access and explicit activation, and it cannot decrypt vaults the Owner was never granted access to.

The offline recovery account restores access to selected vault types through cryptographic grants created in advance. Its reach is limited to those pre-assigned vaults: it cannot gain new access retroactively during an incident.

The service account handles programmatic access for integrations and automation. Its API token is limited to explicitly granted resources and cannot be turned into an interactive web login.

This separation is the important part. Recovery does not depend on one privileged credential with access to everything. Each mechanism has its own trigger, scope, and boundary, so compromising one recovery path does not automatically compromise the entire system.

Together, the three tiers provide different paths for account recovery, data recovery, and automation without creating a universal master key.

Security is about distributing trust, not concentrating it

The engineering takeaway is simple, even if implementing it took real work: a password manager with a god-mode admin isn't actually zero-knowledge, whatever the marketing says. If one account, one password, or one command can unlock every secret in the system, you've built a single point of failure with extra steps.

The harder, more useful design goal is recovery without concentration: multiple isolated mechanisms, each auditable, each scoped to a narrow job, none of them capable of becoming a universal key on its own.

We're curious how other teams solve this. How does your org handle the bus factor for critical infrastructure secrets? Physical safe, Shamir's Secret Sharing, something homegrown with HashiCorp Vault, or are you still crossing your fingers? Drop it in the comments, we'd like to compare notes.

IBM’s 2026 breach report: 5 security controls engineering teams should review

Passwork Team — Mon, 24 Aug 2026 23:08:08 +0000

IBM’s 2026 Cost of a Data Breach Report (wich was published in July'26) contains a number that caught the Passwork team’s attention: AI-enabled attacks now account for more than one in four malicious breaches, up 56% year over year.

The average cost of those incidents reached $6.04 million, about $1 million above the global average.

At Passwork, we build a self-hosted password and secrets management platform, so we looked at IBM’s findings from a specific engineering perspective: what they mean for software delivery, AI identities, secrets, and access management.

A $6 million average breach does not mean a vulnerable dependency, exposed API, or leaked token in your repository is a "$6 million bug." IBM studied 602 organizations that had already experienced breaches, so its numbers are better treated as directional benchmarks than as a risk calculator for an individual application.

The more useful question for developers is what happens to the time between vulnerability discovery and exploitation as AI capabilities improve.

Research into frontier models suggests that AI can accelerate vulnerability discovery and validation. If attackers can move through that part of the process faster, security teams cannot leave triage and remediation on the same schedule they used a few years ago.

For us, that changes the engineering question from:

How much could a breach cost?
to:

What controls need to become continuous parts of software delivery?

Here are five areas we think are worth reviewing.

1. AI changes the remediation clock

Vulnerability management has always involved a race between discovery and remediation. AI potentially changes the speed of one side of that race.

That makes a quarterly vulnerability review increasingly difficult to justify for internet-facing systems.

The answer is not necessarily to put an AI agent into every CI/CD pipeline. Automation can help with classification, enrichment, or even suggesting a patch, but it does not solve the harder engineering questions: Who owns the vulnerable component? How urgent is the finding? What happens if the fix cannot be deployed immediately? And how do we know the fix actually reached production?

A practical workflow needs to answer those questions before the vulnerability appears.

For internet-facing services, we think that means at least:

maintaining an inventory with a clear owner for every exposed service;
creating a separate path for known-exploited and actively exploited vulnerabilities;
defining remediation SLAs based on exploitability and exposure, not severity alone;
having compensating controls when an immediate patch is impossible;
verifying that the fix reached production rather than treating a merged PR as remediation.

The compensating control matters. Sometimes upgrading a dependency immediately is not realistic. But reducing exposure may be: disable the vulnerable feature, add a WAF rule, restrict a network path, introduce a feature flag, or temporarily remove the service from the public surface.

The objective is not "patch everything immediately." It is to make sure a critical finding never enters a backlog with no owner and no next action.

2. The 18% gap: detection is not secure delivery

One of the most interesting findings in IBM’s report is where organizations are actually deploying AI agents.

Among breached organizations, about half reported using AI agents in their SOCs. Their most common uses were threat hunting (56%) and response and containment (54%).

Only 18% used them for vulnerability scanning and management.

That gap matters more to us than the question of whether a team uses AI security tooling at all.

Detection and response happen after something suspicious has occurred. Vulnerability management sits closer to the software delivery process, where engineering teams can remove or reduce exposure before exploitation.

The practical lesson from the 18% figure is not "put an AI agent everywhere." It is to make vulnerability work part of delivery.

For example, we would review four places.

PR and CI. Which security findings actually block a merge, and which simply disappear into the backlog? Define clear CI gate rules that combine severity with exploitability instead of treating every finding the same way.

Dependencies. Which critical direct and transitive dependencies have no clear owner? Assign ownership and maintain an up-to-date SBOM so that a vulnerability can be mapped to the team responsible for fixing it.

External surface. Who owns staging environments, demo instances, and services that were deployed and then forgotten? Connect the asset inventory to owners and use expiry or tagging policies for temporary services.

Remediation. What happens when a patch cannot ship today? Define compensating controls in advance: restrict network exposure, disable the affected feature, introduce a WAF rule or feature flag, or temporarily remove the vulnerable service from the public surface.

AI may make parts of this workflow faster. It can enrich an alert, correlate it with asset exposure, summarize a CVE, or propose a patch.

But ownership, review and safe rollout remain engineering responsibilities.

3. AI security is mostly systems security

IBM also found that more than 20% of organizations reported an incident targeting an AI model or application. Among organizations experiencing AI-related breaches, 92% lacked proper AI access controls.

The obvious reaction is to focus on the model.

We think the more useful place to look is everything around it.

A production AI feature rarely consists of a model call in isolation. It may connect to APIs, vector stores, queues, databases, internal tools, SaaS applications, cloud infrastructure and CI/CD systems.

An agent may also be allowed to perform actions rather than simply generate text.

That turns familiar software architecture decisions into AI security decisions.

When reviewing an AI workflow, we would ask:

Which tools can the agent call by default?
Which data sources can it query?
What data is used for retrieval, generation, evaluation and telemetry?
Can its account read data unrelated to its current task?
Can it modify production state?
Where are credentials for model providers, databases, queues and cloud services stored?
Are development, staging and production using separate identities?
Can an action be traced back to a specific user, service or agent?

Prompt injection and model inversion introduce new attack patterns, but many of the controls around them are not new.

API boundaries still matter. Least privilege still matters. Secret handling still matters. Logging still matters. Safe defaults still matter.

In other words:

AI security is largely systems security applied to a new type of application.

4. Treat an AI agent as a production identity

IBM reports that fewer than half of organizations actively secure non-human identities such as API keys, service accounts and machine credentials in their AI workflows.

As agentic systems expand, that becomes difficult to treat as an IAM detail.

An AI agent is not only a model call. In production, it is an identity with tools, data paths, permissions and secrets.

We think it should be managed accordingly.

A basic review can start with five questions:

Does every agent or service account have an owner and defined purpose? "AI-agent-prod" is not enough documentation if nobody knows which application owns it or why it has access.
Where do its secrets live? They should not be embedded in source code, prompt templates, configuration copied into chat, or shared documents.
Are permissions scoped to the task? A workflow that needs read access to one data source should not inherit a credential that can administer the entire environment.
Can access expire or be revoked? Long-lived credentials with no rotation or lifecycle owner increase blast radius when something goes wrong.
Are environments separated? An experimental agent running in development should not quietly inherit production credentials because using the same service account was easier.

As AI creates more machine identities, existing weaknesses in secret management and access governance become easier to multiply.

5. Shadow AI is an enablement problem before it becomes an enforcement problem

IBM reports that Shadow AI was associated with 43% of AI-related incidents in its 2026 study, while only about a third of organizations enforced strict approval processes for internal AI tools.

The simplest response is to ban unapproved LLMs. But a clear policy alone doesn’t solve the engineering problem.

If the approved workflow is too slow or too restrictive for actual development work, people will find alternatives. A better starting point is to give teams a secure path that is easy enough to use.

That might include:

approved models and providers;
corporate accounts and SSO;
clear rules for code, logs and customer data;
secret redaction before prompts are sent;
a lightweight approval path for new AI tools;
a test environment for agent experiments.

The data policy should also be concrete.

"Do not send sensitive data to AI" leaves developers to decide what "sensitive" means in the middle of a task.

A more useful policy explicitly covers things such as production database dumps, API tokens, private keys, customer or personal data, credentials and unredacted production logs.

And it should provide alternatives: masked logs, synthetic datasets, least-privilege test environments, approved enterprise workspaces or local/offline workflows where appropriate.

For us, Shadow AI is an enablement problem before it becomes an enforcement problem.

Automation matters when it closes a queue

There is one more IBM result worth putting into engineering context.

Organizations reporting extensive use of security AI and automation had average breach costs $1.93 million lower and breach lifecycles 65 days shorter than organizations using no AI or automation.

That is an association in IBM’s sample, not proof that adding AI automatically produces those savings.

But the mechanism behind useful automation is familiar to engineering teams: reduce the time between a signal and a safe action.

That can be much less glamorous than deploying an autonomous security agent.

It could mean:

dependency update PRs that automatically run the relevant test suite;
vulnerability alerts enriched with service ownership and exposure data;
secret scanning before credentials reach the repository;
infrastructure-as-code checks in CI;
deterministic rollback for risky deployments;
security alerts automatically routed to the team that owns the affected service.

Each removes queue time or manual context switching.

That logic applies even to small engineering teams with no dedicated SOC and no budget for security AI agents.

Three controls to inspect this sprint

IBM’s 2026 report is framed around breach economics. For engineering teams, we think its more useful message is about asymmetric speed.

AI can accelerate vulnerability discovery and attack workflows. At the same time, AI adoption is creating more applications, integrations, service accounts, tokens and machine identities that need to be governed.

Adding another detection tool does not close that gap by itself.

If we had to turn the report into three tickets for the next sprint, they would be:

1. Create a fast path for actively exploited vulnerabilities.
Identify internet-facing assets, assign owners, define escalation rules and document what to do when immediate patching is impossible.

2. Inventory AI-agent identities and secrets.
For each agent or AI-enabled service, record its owner, purpose, permissions, credentials, environment, rotation policy and revocation path.

3. Give developers an approved way to use AI.
Define allowed providers, accounts and data types, plus a practical process for testing or requesting new tools.

None of these controls depends on predicting exactly how capable the next frontier model will be.

They address a simpler problem: when discovery and exploitation get faster, the gap between finding, prioritizing and fixing a weakness becomes more important.

Security controls have to move closer to where software is built and shipped.

Read the full IBM’s 2026 Cost of a Data Breach Report analysis on our blog.