# Security white paper You can read a document and fill a form before you create an account. A password or a sign-in is how the same vault reaches your other devices. ## The vault key The first time you save something, Vowkey makes a vault key on that device. Logins, cards, profiles, API keys, and document scans are encrypted with it before they are written down. A per-item key wraps each saved item, so changing how you unlock the vault does not re-encrypt every file. When you add a password, that password stretches with PBKDF2-HMAC-SHA256, 600,000 times, using a salt made on the device, and the result wraps the vault key. An account uses the same stretch with your email as the salt. The server stores the wrapped key. It does not store the password or the vault key, and it cannot open the vault. - On a Mac, the key sits in Keychain under Vowkey. Touch ID can ask before the app reads it. The prompt does not wrap the key. ## Where the key lives if you have not made an account Each app keeps its own vault until you sign in and choose to move it. Closing the app does not delete what you saved. Losing the only key does: there is no recovery file and no copy on the server until an account exists. - Mac, Windows, and Linux keep the key in the signed-in user's credential store: Keychain, Credential Manager, or the Secret Service. On Linux, other programs you run can read that store. - iPhone keeps it in the Keychain for this device only, available while the phone is unlocked. It does not come along in a phone backup. - Android wraps it with a key in Android Keystore and keeps the wrap in the app's private storage. Vowkey does not claim that key is in a separate hardware chip. - The browser extension wraps the key with an AES-256-GCM key that WebCrypto will not export, and stores that wrap in IndexedDB so the vault is still there after you quit the browser. A copied browser profile includes that wrap. - The web app keeps the key in the page only. Closing the tab drops it unless you have set a password. ## What the server stores A synced account stores your email, a password verifier, the wrapped vault key, and the public half of a device key. Each saved item is a row the server cannot read: the name, notes, fields, and the item body are the encrypted strings your device sent. Attachment files are encrypted the same way and stored beside the item. The server can see that an item exists, when it changed, which account it belongs to, and its type number. It does not see the passport number, the card, or the API key inside. ## What leaves the device when a form is hard to read Reading a passport, an ID, a PDF, or a spreadsheet happens on the device. You can turn the network off and still fill a form from what is already saved. If a form's labels need a reading service, the request is a signed login or a one-hour guest token. The relay checks the signature and forwards only the fields it allows. A form match sends labels, sections, and the names of saved details, not the saved values. Reading printed text sends that text. A photo you explicitly choose to send goes to a separate reader as a JPEG, PNG, or WebP. The relay does not write the request into its log. The service that answers still receives what was forwarded. Guest use is counted on the server so a new install does not reset the limit. ## What an AI agent can ask Claude, Codex, or another agent talks to Vowkey through a local MCP server started with the app. It is not a service on the internet. The agent sends a field and an @vk: handle. Vowkey fills the value on your device. A saved detail is Fill without asking, Ask first, or Don't fill. Ask first waits for Allow once, Always allow on this site, or Don't allow. Don't fill is not overridden by a site you already allowed. The tool result says what was filled. It does not include the saved value. ## Checking this yourself The apps, the server, and the relay are published source. Desktop and CLI downloads are listed with SHA-256 checksums. This page describes the current code. It is not an audit report: no independent audit has been commissioned, and there is no paid bounty program yet. If you find a problem, write to security@vowkey.com. The report page says when you will hear back. - [Security white paper](../../security/whitepaper/) ## Threat model Who can read what, and what they cannot. The server sees that an item exists, when it changed and its type number, but not its contents. The reading service sees the forwarded fields, labels or text, or a photo you chose to send, but not the vault. Malware running as you can read what the app shows you and the credential store on the device, and a lost unlocked device can show the vault; the key in the credential store does not travel to another device. A copy of the browser profile includes the wrapped key, so treat the profile as the vault. Signing in alone does not open the vault: the vault key is still needed. ## AES-256-CBC ยท HMAC-SHA256 Saved item fields use EncString type 2: AES-256-CBC with a fresh IV and HMAC-SHA256. The 64-byte user key contains the encryption and authentication keys. Each item key is encrypted under the user key; encrypted attachment bytes and their encrypted keys are stored separately. PBKDF2-HMAC-SHA256 with 600,000 iterations is the registration default; existing accounts retain their configured PBKDF2 or Argon2id parameters. Authentication and unlocking are separate: a signed login does not itself decrypt the vault.