How Passwords keeps your data safe

This page explains how Passwords protects what you store in it. It is the public description of the design. We say what it does first, in plain words, then add the detail. We also say where it stops protecting you.

The short version

• Your items are encrypted in your browser before they are sent to 3mote. In Private and shared vaults we store encrypted data we cannot open. Automation vaults are the exception, described below.
• A Private or shared vault is opened by keys held on your trusted devices. 3mote does not hold them.
• Who holds each vault’s key is kept in a signed record. Your browser checks it, and refuses one that was changed, cut short or forked.
• Your workspace can name a Recovery Group that can restore a locked-out teammate. Every vault shows who can open it, and owners and admins can see that list for every vault in the workspace.
• An AI agent can use a login, token or key without ever seeing it.
• One kind of vault, an Automation vault, is opened by a key that 3mote holds. It says so on the vault, and it is never called zero-knowledge.

The keys

Three layers of keys protect an item.

1. Item keys. Every item is stored as two encrypted pieces: the secret (password, token, key, notes) and the details (title, username, websites). Each piece has its own key. Every edit makes new item keys, so a key handed out earlier opens only the version that existed then.
2. The vault key. Each vault has one key that locks all of its item keys.
3. The people and groups who can open the vault. The vault key is locked once for each of them, using their public key. Only the matching private key can unlock it. Each locked copy is signed by whoever made it and is tied to the key it carries, so a copy cannot be swapped for another key without the person who opens it noticing.

Your own private keys are kept in your browser. They are protected by an account key, and a copy of that account key is locked to each of your trusted devices. There is no vault password to remember or to steal.

Who can open a vault

A vault can be opened by:

• The people you add, and the members of teams and roles you add. Someone who joins through a team or role is waiting for access until a vault manager opens the vault and confirms them. You see everyone under Who can open this vault.
• The Recovery Group, so a locked-out person can be restored. It shows as its own row. Owners can turn this off for Private vaults.
• An agent’s workstation, for one session, and only for items a person chose to grant. This never changes who the vault is locked for.
• A key that 3mote holds in AWS KMS, only on an Automation vault, so agents can use items without anyone present.

The Zero-knowledge badge means 3mote cannot open the vault. It is shown on every Private and shared vault whose record your browser has verified. When a key 3mote holds can also open a vault, the badge changes to Agents can use anytime · key held by 3mote. We never use the word zero-knowledge for that vault.

Vault names, and who can open each vault, are visible to workspace admins, so they can audit a vault they cannot open. Item titles are not, though an agent’s own written reason for a request may name items.

A signed record of who holds the key

The list of people a vault is locked for is not taken on 3mote’s word. Each vault keeps a signed record, one entry for each change: the vault was created, someone was added or removed, a permission changed, the keys were replaced, Automation was turned on or off. Each entry is signed by someone who already had the right to make that change, and it lists exactly who holds the key afterwards. Your browser checks the record from its saved checkpoint (from the first entry, the first time) and remembers the latest entry it has seen. It opens a vault only if the record lists you under your current keys. If 3mote shows a shorter record, or a different one, your browser refuses it and leaves the vault closed.

Adding people is a click, on purpose. The screen lists each person by name before anything is shared. A person your browser has not seen before is marked New to this browser. To add someone as a manager, who can change who has access, you must also compare their account words with them first.

The Checking… and Not verified labels in place of the vault badge mean this record has not been checked yet, or could not be. We do not claim what kind of vault it is until the check works.

Trusted devices and the eight words

A trusted device is a browser profile that can open your vaults. Its private key is created in your browser and stored there. 3mote cannot read it.

To add a new device, you approve it from a device you already trust, and the approving device must have Passwords open, because it needs your keys to show you the words. The new device shows two lines of eight words. The first line stands for the device. The second stands for your account. Together the two devices check both lines, and each time the person picks the matching set of eight words from three. If the account words do not match, select They don’t match on the new device. That withdraws it and nothing is shared. A server in the middle that tried to put in its own key would produce different words.

The same words check is used where a person could be tricked into trusting the wrong key: when a Recovery Group member restores you, when you confirm the Recovery Group, when a member is added to it, and when you add a manager to a vault.

Your browser also keeps what it has verified: the people’s keys it has seen, how far each vault’s record and the Recovery Group’s record have got. That is your trust state. It is signed with your keys, encrypted so 3mote cannot read it, and kept in sync across your devices, so a second device or a restored kit can start from what you already checked. A restored or newly approved device takes whatever genuine copy the server serves, which can be an older one. A browser that is already set up warns you if its saved checks go missing or move backwards. Start fresh in this browser is the way past it, after a confirmation that says what you give up: the browser will trust whatever it is shown next.

When you remove a device that was lost or stolen, your keys are replaced, every vault you can open is re-locked to the new keys, and you are signed out everywhere. Because a stolen key can act as you until it is replaced, a review then lists the changes made with the old key that this browser did not make, such as people it added to a vault. For each you choose I made this change, or Remove them and re-key.

The Recovery Kit

Your Recovery Kit is a PDF made in your browser. It holds your Recovery Code, which can restore your access on a new device in a supported browser. 3mote never sees the code. Anyone holding the kit can open everything you can, so keep it where you keep your passport. Making a new kit replaces your account key, so the old one stops working.

The Recovery Group and its signed record

The Recovery Group is an explicit list of people, never “everyone who is an owner”. A member can restore a locked-out person (with a 24-hour wait if that person still has a trusted device) and can take over a departed person’s Private vault after a 24-hour wait that an owner can cancel. Members can open every vault that has a recovery path for the group, by design, so choose them with care. Vaults the group can open list it, and a member is shown which vaults a restore covers.

The list is kept as a signed record. Every change adds one entry (set up the group, add a member, remove a member, a member replacing their keys, a restore). Each entry is signed by a member who was already in the group. Your browser checks the whole record, from the first entry, before it trusts the group, and it remembers the latest entry it saw. If 3mote shows a different list, a shorter record or a changed one, your browser refuses it.

Your browser does not use the group until you confirm it. You compare one member’s account words with them, and that member must have signed an entry in the record under exactly those keys. Until you do, nothing is locked for the group, adding or removing members and changing the Private vault setting wait, and some vaults show a prompt to confirm your Recovery Group, with a button. A vault made in that time has no recovery path for the group until a later record in the vault adds one.

Adding a member is done in the foreground by an existing member, who compares the new member’s eight words with them in person or by phone. A member is removed by another member, never by themselves.

How an agent uses an item, with your permission

An agent that is working on a workstation asks to use an item, with a short reason that is clearly marked as written by the agent. The request names items by id, so 3mote does not store the titles of the items it asks for. Your own browser decrypts the titles it shows you next to the ids. The reason is the agent’s own free text: it is stored readable, and it may name items. The person it works for is notified. They open the request, which shows the workstation, the agent, the person it works for and a link to the card. Their device checks that the request comes from the agent’s real workstation session, then they pick the items and select Grant for this session.

Their device locks the item keys to that one session, and 3mote carries the locked keys to the workstation. 3mote cannot open them. On the workstation, a program that is not the agent applies the value for it: it adds a header to a web request to an address the item allows, loads an SSH key into a key agent that can only reach the hosts the item names, or fills a sign-in form in one step. The agent gets the outcome, never the value. The runner checks text output for granted values, and one that carries a value is withheld and replaced with a notice. Screenshots and some short fragments are not covered, as the limits below say. After three withheld outputs in one session, the workstation stops that session. If the same item is caught three times in a week, across all agents, it is paused for every agent until a manager of the vault clears it. The vault’s managers are notified when that happens, and the clearing screen tells them to change the value at its service first.

A grant ends when the session ends, when you revoke it, when anything that gave the agent its access changes, or at the expiry of the workstation’s session certificate, even if the session was extended. After a revoke, the workstation drops its keys within about a minute.

How an agent uses an Automation vault

An Automation vault works without a person in the loop. When an agent uses an item, 3mote checks the agent, the vault and the person the agent is working for, and writes the record of the use first. Then 3mote asks AWS KMS to open the vault key with the key it holds, and hands the workstation the item’s key, locked to that session. It lasts up to an hour.

3mote does not read values. But it holds a key that could open the vault, and a compromised 3mote could use it. That is the reason for the badge, the record of every use, and the advice to rotate a value that an agent could use before you turn Automation off. Holding the key yourself is coming, on Enterprise.

What 3mote stores and what it never sees

3mote stores encrypted items and keys, the public keys of people and groups, vault names, who can open each vault and with what permission, rough item sizes and types, the labels of your devices and the activity log. From that it can tell who shares a vault with whom, how often items are opened and how big they are. For Private and shared vaults, it cannot tell what is in them. Automation vaults are the exception.

It never sees item titles, usernames, websites, notes, passwords, tokens, 2FA setup keys, SSH keys, your Recovery Code or your device keys. The activity log records that something was revealed or copied, never what. Titles and types of items an agent lists reach the AI provider your workspace chose for that agent. The agent is not given the values, but the safeguards cannot prevent every possible leak, as the limits below say.

The limits, honestly

No design removes every risk. These are the ones you should know about. They come in two groups: what an attacker could do once they have something of yours, and what we ask you to trust.

Attacks that need something of yours, or of ours

• 3mote serves the code your browser runs. Passwords is a web app. A malicious or compromised build of that code could read your keys while you use it. The same is true of 1Password’s and Bitwarden’s web vaults. We restrict what that code can load with an enforced content security policy, and more controls are planned. This is the ceiling for protection against 3mote itself.
• A value an agent has used may have been copied. An agent that can use a value to sign in or call an API can do things with it. Allowed hosts on each item, the activity log and your review of an agent’s work limit the harm. A revoke removes the grant. It cannot take back a value already used, end sign-ins and tokens already created, or reliably stop a compromised workstation. Rotate the password, key or token at its service if you need to be sure.
• A site can show a value back. If an agent sends a token to a website that echoes it in a reply, the value is in that reply. 3mote withholds output it recognises, but cannot catch every way a site might show it. Screenshots are not scanned. A password made only of letters can leave in pieces of up to 15 characters before the check reacts.
• Withholding an output answers a yes or no. An agent can learn a little about a value from which outputs get withheld. We stop the session after three, and pause the item after three in a week, so only a few characters can leak between clearings. That is why the clearing screen tells a manager to change the value at its service first.
• Sign-ins and tokens made during a grant can outlast it. Signing in can start a web session, and an API can issue a new token. A revoke does not end those. End them at the service.
• A compromised workstation holds what it was given. If someone takes over a workstation, it holds the granted keys, and up to an hour of released Automation keys, until the session ends.
• The Recovery Group can open every vault it covers. A member acting in bad faith could read every vault they can restore. Choose members you would trust with the keys, and keep the list short.
• A lost or stolen Recovery Kit gives access. It is the same exposure as any recovery key. Keep it safe, and make a new one if it may have been seen.
• A key that 3mote holds can open an Automation vault. We say so on the vault.
• Metadata is visible to 3mote. See the section above.
• Reveal and copy are reported by your browser. A modified browser could leave them out of the activity log.

What you have to trust, even with the signed records

The signed records and your saved checks make it much harder for 3mote to quietly change who can open a vault. These are the limits that remain. None is closed without a new mechanism, and each is trust that any end-to-end encrypted password manager with a server-held directory places in its server.

• The first time you meet a key, you trust the one 3mote shows you, unless you checked it with words. A person your browser has never seen is whoever the directory says. The first share to them is marked New to this browser, adding a manager needs a words comparison, and your saved checks mean you rarely start from nothing. Rarely is not never.
• 3mote could show two people different views. There is no public log of everyone’s keys. A hostile server could withhold a key change from someone who has not seen it yet and keep serving the old key, including serving only a thief’s change. Your browser’s checks only ever move forward, so it will not let its own view go backwards, but they do not make two people’s views agree. The Recovery Kit and removing a device bound the damage.
• A first answer can be old but genuine. A device restored with a kit, or approved from another device, takes the saved checks 3mote serves. That could be an older copy, or none. A missing copy raises a warning that clears only when an approval brings your own, or when you choose Start fresh. The first time you confirm the Recovery Group by words, you could land on an old list whose key a since-removed member still has. That needs that member to cooperate with a hostile server. A group that nothing but 3mote vouches for is never used to judge a vault or a key change: you confirm it with words first.
• What a stolen key signed before you replaced it counts as your own act. A thief and a hostile server could add people to a vault in that window, and your key change then commits to it. After you remove a device as lost or stolen, a review lists changes made with the old key that this browser did not make, and offers to remove the people they added and re-key. It is a convenience, not a guarantee: the date on a change is whatever its signer wrote, so a thief could backdate one and leave it out of the list.
• Some trust is held by the server and shown to you. Which agents are members of a vault, the key 3mote holds on Automation vaults, and the names shown in confirmation dialogs all come from 3mote. A confirmation from a person who is not a manager binds to the keys a manager listed, not to a name.
• 3mote can always make a vault or the group unverifiable. That is a denial of service. It cannot make your browser lock a key to a key it invented: nothing is shared for a vault or group whose record does not check out. Some honest situations can also leave a vault or the Recovery Group unverifiable. When a vault cannot be verified, the way out is to move its items to a new vault.
• A hostile server that also holds a key you have retired is the open threat. The rules that decide which keys are yours are the part still under review. They hold for a browser that has saved a checkpoint and the record of the key replacement. For any other, such a server can still cause an unverifiable vault or group, or a wrong first impression, as in the points above. Do not treat this threat model as closed until the external review is done.

This design is specified in detail and has been reviewed internally. It has not yet had an independent external review. One is planned before customer launch, and these key-trust rules are the part it will examine.