A password manager asks for more trust than almost anything else you install. You hand one application every credential you own. It is fair to ask what that application protects you from. It is fairer still to ask what it does not.
This page answers both questions. The second half is the longer one, and that is deliberate. A list of threats a product defeats tells you what we are proud of. The list it concedes is the one you need in order to decide whether Vauz fits your situation. Every security design draws a boundary somewhere, and a design that appears to have no boundary has only hidden it. Ours is written down here, so that you can see where it falls rather than discover it later.
Nothing on this page describes how Vauz is built. A threat model states what is defended and what is conceded; how those defences are constructed is a separate matter, and one we keep to ourselves. A detailed account of a defence tends to be worth more to the person trying to get past it than to the person relying on it.
The asset is your vault: the entries you keep in Vauz. Domains and addresses, usernames and email addresses, passwords, and any notes you attach to them. Your V-Key, if you set one, is part of the same asset.
Your vault lives on your own computer, in a form that is readable only on that computer. It is not stored on our servers, not synchronised between machines, and not backed up anywhere by us.
That is a statement about what Vauz does today, and it is unconditional today: there is no setting that sends a vault anywhere. Encrypted cloud backup, sync between machines and password sharing are planned. None of them exist yet, and this document will be revised before any of them ships — each would change the answers below, and saying so afterwards would be too late to be useful.
One consequence is worth stating at the outset. Vauz is one vault on one computer. Moving to a different machine is something you do deliberately, by exporting your vault and importing it on the other side. There is no copy of it elsewhere. That is the point of the design, and it also means there is no copy elsewhere to fall back on.
Who they are: anyone the file reaches by a route you did not intend. A cloud backup, a shared or synced folder, a second-hand drive, a copy taken off your machine.
What they can do: keep the file indefinitely, examine it at leisure, and try to open it on hardware of their own choosing.
What Vauz aims to deny: portability of the file. A vault is bound to the computer that created it, and the file on its own does not open on other hardware — time spent with it elsewhere does not change that.
What that binding is not: a substitute for your operating system's disk encryption. It denies the file, not the machine. An attacker who takes a full image of your drive has taken more than the file, and is covered by section 4 rather than here.
Who they are: an attacker with full access to our systems. Also us, if we were compelled to produce everything we hold.
What they can do: read every record we keep, and keep reading it.
What Vauz aims to deny: anything worth taking. We do not hold vaults, so there is no vault for a breach of Sealzi to reach. What we do hold is listed in section 5, and it is an account record rather than your passwords.
What that does not cover: our credentials for our payment processor are on our servers too. Someone holding them could change subscriptions, or start one against a card saved with the processor. Your card number itself is not there to take: it is held by the processor, not by us.
Who they are: whoever controls the code that draws the card form — our payment processor, or anyone who compromises the script it serves.
What they can do: run code in the page where you type your card number.
What Vauz aims to deny: your account. The card form runs only on a separate page of ours, pay.vauz.sealzi.com, which is a different website as far as your browser is concerned. Your sign-in never reaches it: all it holds is what a one-use ticket from your dashboard gives it, which is permission, for up to an hour, to save a card to the account that sent you there. It cannot read your account, and it cannot start a charge — every subscription is set up from your dashboard, after you have agreed to it there, and only then does the payment processor charge it. A ticket copied out of your browser does not work in anyone else's.
Who they are: a page that wants credentials it has no claim to. A lookalike domain, a compromised site, a page carrying login fields that belong to someone else's service.
What they can do: present login fields, claim to be a site it is not, and ask as often as it likes.
What Vauz aims to deny: credentials for any site other than the exact one you are on, and any release at all that you did not approve. A page cannot talk the browser extension into handing over logins you saved elsewhere, and cannot obtain anything by asking quietly in the background. How much an approval is worth depends on what you have set up, which is covered in section 4.
The site named in the approval prompt is the one your browser says you are on. The extension does not accept a page's own account of which site it is, so a page cannot arrange for the prompt to name a site you trust while the request comes from somewhere else. The same answer is checked again at the moment the login is filled in, because an approval can sit in front of you for long enough to leave the page.
This is also why autofill does not work inside embedded frames — a box on the page served by another site. Any site can embed any other, so an autofill prompt appearing inside an embedded frame would be one the surrounding page decided to put in front of you. Vauz fills logins on the page you actually navigated to.
Where that stops being enough: naming the site correctly does not help if the name itself is the trick. An address can be spelled with letters borrowed from another alphabet that are drawn identically to ordinary ones, so a site built to be taken for one you know can be named accurately and still deceive you. The extension reads the address the way your browser really sees it and says so. Where the characters spell out a well-known name without being it, autofill is refused outright rather than merely warned about, because there is no innocent reason for such an address to exist. Where the resemblance is weaker — a name one character different from the one you meant, or a familiar name used as part of a longer one — it warns and leaves the choice to you.
That check runs entirely inside the extension, against a list built into it. It never asks the Vauz app what you have saved: an answer that changed depending on your vault would tell any page that cared to ask whether you hold an account somewhere.
It is a check on the shape of a name, not a judgement about whether a site is honest. An address bearing no resemblance to anything well known passes it, and a site can be a fraud under a name entirely its own. Nothing here removes the need to look at the address bar.
Who they are: anyone positioned between your computer and the internet. A shared or hostile network, a proxy, an internet provider.
What they can do: observe traffic, record it, and alter it.
What Vauz aims to deny: something to observe. The Vauz application sends nothing to anyone. Not to us, and not to any third party: no vault contents, no entry counts, no list of the sites you saved, no usage reporting, no error reporting, no update check, no licence check, no check-in of any kind. It does not reach the network at all, which means there is nothing on the wire to show that you are running it, let alone what you keep in it. The one thing that does produce traffic is your own click: choosing Documentation or Contact Support from the menu hands off to your browser or your mail client, and the request after that is theirs. Your account pages on our website are separate, and are served only over an encrypted connection.
What that encryption is not: resistant to a future quantum computer. The connection between your browser and our website uses a classical key exchange: our host does not offer a post-quantum one, so a recording made today could in principle be read by someone who later has one. Our payment processor's servers do offer a post-quantum key exchange, and our server uses it when talking to them wherever our host's software supports it. Passkeys themselves use classical signatures, as every passkey does today.
Who they are: anyone able to substitute the file you receive. An attacker on the network between our site and you, an intermediate cache or mirror, or anyone who gained the ability to replace the file on our own server.
What they can do: serve you a Vauz that is not ours.
What Vauz aims to deny: an undetectable substitution. Every release is signed, and the key that checks the signature is published away from the download itself, so an altered installer can be identified as altered. One limit belongs with this: the check is one you run yourself, using the steps on the download page. Your operating system does not run it for you.
These are not gaps we overlooked. They are the boundary. Read them as the conditions under which Vauz stops helping you, because a password manager that claimed to cover them would be claiming to protect you from your own computer.
Malware, a malicious dependency inside another program, a remote-access tool, or a person sitting at your unlocked session. Code holding your privileges can read what you can read, watch what you type, and see what is on your screen. It does not need to defeat Vauz in order to do any of that.
This is also the honest limit on the V-Key. The V-Key controls access to the application. It is not what encrypts your vault. On your own computer it does not stop code that runs as you, and it does not make a powered-off machine resistant to someone who can log in to it. Protecting a device at rest is your operating system's work, through its account login and its disk encryption, and Vauz is not a substitute for either.
If the system underneath is backdoored, everything above applies without a ceiling. No application can outrank the system it runs on, and any claim to the contrary is a claim about something other than software.
Copying the vault file is one thing; copying the whole disk is another. An image taken from an unencrypted drive carries the machine's own state with it, which is what the vault is bound to — so the binding described in section 3 does not survive that, and on some platforms an image can be brought up elsewhere and the vault opened. Turn on your operating system's full-disk encryption: BitLocker, FileVault, LUKS. Vauz is not a replacement for it and does not try to be.
A hardware keylogger, a camera pointed at your screen, a machine administered by someone else. Vauz receives the keystrokes the operating system hands it and has no way to know they were captured on the way in.
An unlocked vault is an open vault, to whoever is in front of it. Vauz can lock itself when you step away, but those settings are yours to switch on and yours to set. Left off, or set generously, they do not help.
The V-Key is optional. A new installation does not have one until you choose to set one, and the locking behaviour that depends on it applies only once you have. Without a V-Key, anyone who reaches your desktop session reaches your vault, and an autofill request is confirmed by a simple prompt rather than by proving who you are. Some people want a vault with no second gate in front of it. That is a legitimate choice, and this is its cost.
Guessed, watched over your shoulder, reused from a service that later leaked, written on paper, or told to somebody. A V-Key that someone else holds is not a V-Key. The same is true of your hint, if the hint is enough to produce the V-Key.
Anyone who can compel you to unlock your vault, whether through legal process or through force or the threat of it, will get your vault. Vauz has no duress mode, no decoy vault, and no way to distinguish an unlock you wanted from one you were made to perform.
An export is a file you now hold and are responsible for. Where it travels, how long it survives, and whether you chose to encrypt it when you wrote it are all yours to manage. A copy sitting in a downloads folder or attached to an email is beyond anything Vauz can reach on your behalf.
Because your vault is on your computer and nowhere else, a machine that is lost, stolen, wiped or simply broken takes the vault with it. We cannot recover it for you. We hold no copy, and there is no reset we can perform on your side of the line. Keeping your own backup is your responsibility, and it is a real one rather than a formality.
Vauz is closed source, and no independent security audit has been carried out. We intend to commission one when we can fund it. Until that happens, what you have is our account of our own work. That is precisely why this page is specific about where the boundary falls, and why we would rather you knew the audit had not happened than assumed that it had.
If you create an account, we hold your name, your email address, the public half of each passkey you enrol, a reference that identifies your customer record with our payment processor, which subscription you have and the dates it runs between, and, if you joined a family, the fact that you are a member of it, when you joined, whether you hold a seat on its plan and whether you help run it.
If you pay for a plan we also hold each payment's amount, tax, date and outcome, and, for every charge you agreed to, the exact words you agreed to and when — with the IP address and browser, encrypted. We never hold your card: not its number, not its last four digits, not its expiry date, not its security code (CVV). When your dashboard shows your card, it asks the payment processor at that moment and keeps nothing.
Sign-in is ours, so nothing we hold identifies you to anybody else. A passkey's private half never leaves your device: what we store is a public key, the identifier the authenticator gave it, a counter that lets us notice a cloned device, and whatever name you gave it. None of it can be used to sign in as you.
Two more records exist because a sign-in page cannot work without them, and both are listed here. Which sessions you have open, so that signing out can end them everywhere — carrying no IP address and no browser details, because we keep no log of sign-ins. And, while someone is repeatedly failing to sign in, a short-lived counter that lets us slow them down, keyed by a one-way code rather than by the address being tried, and deleted once the attempts stop. Successful sign-ins are counted nowhere.
One timestamp is kept, and it is worth being exact about: each passkey records when it was added and when it was last used, both shown to you on your dashboard. That is what lets you look at a passkey you do not recognise and see that it signed in an hour ago. It is a single value overwritten on each use — not a list, carrying no IP address and no browser details — so it answers "when was this passkey last used" and cannot answer "where have you been signing in from".
That is the whole of it. The record exists to run your account: to let you sign in, to contact you, and to bill you correctly.
We cannot read your vault. Not the entries, not the passwords, not the notes, not the sites you saved, not your V-Key and not its hint. We also do not know how many entries you have, when you last unlocked, which features you use, or whether you have opened Vauz at all since installing it. We chose not to collect any of it, and Vauz is built so that the choice does not depend on your trusting us to keep it.
Two consequences follow, and both of them cut against us rather than for us:
— We cannot let you back into a vault you are locked out of. There is nothing on our side to reset.
— We cannot tell you whether your vault was ever accessed, or by whom. We hold no record of it.
This page carries a review date, and it describes the release named beside that date. Both are at the top.
We revise it whenever something we have shipped moves one of the lines above, in either direction: when a concession in section 4 becomes a defence in section 3, or when a defence turns out to be narrower than we described. The review date moves with the revision.
We do not describe work that has not shipped. If a protection is not on this page, treat it as absent, whatever you may have read elsewhere.
Write to security@vauz.sealzi.com.
Every report is read and answered by a person. We do not publish a target response time, because we would rather not advertise a number we cannot yet promise to meet. When we reply, we will tell you where the report stands.
What helps most in a report: what you did, what happened, what you expected instead, and the version you were running. Enough detail for us to reproduce the problem is worth more to us than a severity rating.
We ask two things in return. Test against your own installation and your own account rather than anyone else's, and do not send us other people's data.
We engage in good faith with anyone who comes to us in good faith. If you would like credit for a finding once it is fixed, say so and you will have it.
Last reviewed 5 October 2026, against Vauz 1.4.2.