Security

We can’t read your vault. We can’t open it for you either.

Encryption and decryption happen on your device. Our server stores and syncs ciphertext and checks signatures. It can’t read your vault, though it could withhold it, so keep an encrypted export.

Straight answers

What we protect against, and what we don’t.

Protects against

  • Passwords landing in chat history, logs or the command line during normal use
  • An assistant with an agent vault opening your personal vault: its key opens its own vault, not yours
  • The server, or anyone who breaks into it, reading your vault
  • A tampered vault: your devices check the signature on every download

Doesn’t protect against

  • An assistant you’ve connected that sets out to read or misuse what’s in the vault you gave it
  • Anything running as your user on your computer, including an assistant with shell access
  • A web page that tricks your assistant into typing a password into the wrong site
  • A weak master password, if someone captures your sign-in key
  • A brand-new device being shown an old copy of your vault
Why would I let an AI anywhere near my passwords?

You don’t have to: the vault works without one. If you do connect one, give it its own agent vault with only the logins it needs. Its key can’t open your personal vault, and you can revoke it at any time. Treat a connected assistant as able to see everything in the vault you give it.

Can my assistant read the passwords it uses?

In normal use it gets a single-use handle, a typed field or a short-lived private file, so the password stays out of the chat. That is not a promise against an assistant that sets out to dig for it.

Today a connected assistant can recover a password by chaining our own tools, and one with shell access can read the file we write for it. We’re closing the tool route before we invite testers. Until then, scope its vault to what you’d be fine with it seeing.

What if a web page tricks my assistant?

Today there’s no approval step when an assistant uses a login. Our browser typing tools don’t yet check that the page belongs to the site the login was saved for, and an assistant can change an item’s saved sites. So a hijacked assistant could type a password into the wrong site.

Before we invite testers, assistant fills will be limited to the sites a login was saved for, and changing those sites from an assistant will need your approval. Until then, don’t connect an assistant that browses untrusted pages to a vault holding anything important.

Is it safe to unlock the vault on a computer where AI agents run?

Not yet. On Linux, atlas-vault unlock leaves a key in a file in your home folder until you run atlas-vault lock. Anything running as your user can read it, including an assistant with shell access.

If you run our assistant server as an always-on local service, it accepts any connection from your computer without a token. We’re adding an expiry to that file and a required token before we invite testers. Until then, run assistants as a separate user or in a sandbox, and lock the vault when you’re done.

What does the company running my assistant learn?

To find the right login, an assistant sees item names, usernames, website addresses, identity details and notes that don’t look like secrets. So the company running your assistant learns which services you use.

Our note filter misses some secrets, such as PINs, seed phrases and backup codes, so keep those out of notes on items an assistant can reach. Some replies also include a short hash and the length of a value, which someone holding the chat could use to check guesses at a weak password. We’re hiding notes from assistants and switching to a keyed fingerprint before we invite testers.

Does my master password leave my device?

No. Your device stretches it with Argon2id, at least 256 MiB of memory and 3 passes, and refuses weaker settings even if a server asks for them. It then sends a separate sign-in key derived from it, which can’t decrypt anything. The server stores a hash of that key.

Someone who captured the sign-in key, including Cloudflare, which carries the connection, could try to guess a weak master password offline. Today they could also use it to change your account password or recovery key and lock you out of sync, though not to read your vault. Use a long master password that you use nowhere else.

Who runs the server, and what can it see?

We do, during the beta, on a machine we operate in Perth, behind a Cloudflare tunnel. It’s a separate service with its own data and keys, but not a dedicated host, and its backups are on the same machine for now.

It sees your email, your devices, how many items you have, their encrypted sizes, when they change and your IP address when you connect. It can’t decrypt your vault, but it could withhold or delete it, so keep an encrypted export.

Could the server roll my vault back to an old version?

Partly. On a normal sync, each device remembers the newest version it has seen and refuses an older copy, on Linux, iPhone and the browser extension. A new or reinstalled device has nothing to compare against, and our own review found one Linux sync path that could accept an older signed copy. We’re fixing that path before we invite testers.

Has anyone independent reviewed this? Who wrote it?

Not yet. Atlas Vault is about three months old, and much of it was written with AI coding tools. A change merges when the required automated checks pass, without a second person approving it. The encryption comes from libsodium and the Python cryptography library, not primitives of our own, and every change runs our leak test before it can merge. We’ll commission an independent security review before general availability.

What happens to the email I give the waitlist?

It’s stored in a Supabase database in Singapore with the use you picked, your consent and the time. Cloudflare Turnstile checks you’re a person once you start filling in the form (typing, clicking into the email field or choosing an option, not reading or scrolling past it), and we get a one-line Discord notice with a masked address. To be removed, email contact@atlas-ai.au and we’ll delete your entry by hand. The full list of services is on the Privacy page.

The crypto, plainly

Items

XChaCha20-Poly1305, with a new random nonce for every record. Each record is bound to its vault and ID. Account vaults are signed as a whole, and on a normal sync each device refuses a version older than the newest it has seen.

Master password

Stretched with Argon2id, at least 256 MiB of memory and 3 passes. Weaker settings are refused, including ones sent by a server.

Keys

Each vault has its own random key. It is wrapped by your account key, which is wrapped by a key derived from your master password with HKDF-SHA256.

Sign-in

Your device proves your password with a separate derived key that can’t decrypt anything. The server keeps an Argon2id hash of that proof, not the proof itself.

Sync

Each device signs what it uploads with Ed25519. The server checks every upload, and your devices check every download.

What we can see

It can’t read your vault, and your devices refuse a copy it has altered. Here is what it holds, and what it can’t see.

We can’t see

  • Your items, usernames and passwords
  • Notes, folder names, passkeys and two-factor seeds
  • Your master password, or any key that opens your vault

We can see

  • Your email address
  • Device names and types, and when each last connected
  • How many items you have, their sizes and when they change
  • Your IP address when a device connects

If you forget your password

When you create an account, you get a recovery key. It is shown once. Keep it somewhere safe, away from your devices.

  1. START
    Start a recovery from the command line on Linux, with your recovery key.
  2. WAIT 72 HOURS
    The iPhone app shows it in Settings, where you can cancel it. On Linux, atlas-vault account status shows it.
  3. THEN
    Set a new master password. Every device is signed out until you sign in with it.

A recovery waits 72 hours before it can complete. Until then, the command line on Linux can also cancel it.

If you lose both your master password and your recovery key, we can’t open your vault or reset it for you.

AI assistants

In normal use, assistants get single-use handles and private temporary files instead of the password. Each assistant can work from its own agent vault, whose key can’t open your personal vault.

Those safeguards keep a password out of the chat in normal use. They don’t stop an assistant that sets out to find one, so treat a connected assistant as able to see everything in the vault you give it. How it works for developers

Not done yet

It’s a beta. Here is what we haven’t built or proven yet.

  1. Two-step login for your Atlas Vault account.
  2. Email address verification.
  3. Signed sync catches changed data, and on a normal sync, data rolled back below what that device has seen. It can’t yet prove that the copy a brand-new device receives is the newest one.
  4. Account changes (password, recovery key, signing devices out) signed by one of your devices. Today the sign-in key alone is enough.
  5. An independent security review. We’ll commission one before general availability.
  6. Email or push alerts for a new sign-in or a pending recovery.
  7. An approval prompt on your phone when an assistant uses a login.
  8. Public source code.
  9. Re-encrypting your vault when you sign a device out. Signing out stops it syncing, but it keeps what it already had, so change the passwords a lost device could see.
  10. An expiry for the unlock key the Linux command line keeps. Today it lasts until you lock the vault.

How we build it

Atlas Vault is about three months old, and much of it was written with AI coding tools. No independent firm has reviewed it yet.

We don’t write our own cryptographic primitives. Encryption comes from libsodium (PyNaCl on Linux, and libsodium builds on iPhone and in the browser extension) and from the Python cryptography library. The iPhone app and the browser extension are tested against the same account test vectors as the Linux code.

Every change runs our tests, including the leak test, before it can merge, but no second person has to approve it yet. The leak test fails the build if a marker secret shows up in what any one of our tools, commands, logs or errors returns. It checks each tool on its own, not an assistant chaining tools together.

We’ll commission an independent security review before general availability.

Found a hole?

Email contact@atlas-ai.au with what you found and how to reproduce it. Give us a fair window to fix it before you share it, and don’t access or change other people’s data while testing.

Our details are also in /.well-known/security.txt.