What mykeep holds, what it cannot hold, and the small number of things that do reach our servers.
The short version. Your secrets, logins, passkeys, OTP seeds and memory are stored on your own devices, sealed with a key derived from your password. We do not run analytics, advertising, tracking, or third-party SDKs, and we do not sell or share your data. Three things do reach our servers, and we describe each one precisely below: a push routing token (which we store in readable form), encrypted sync data if you turn on multi-device sync (which we cannot read), and memory request frames in transit (which we relay but never store).
mykeep is operated by Domu Inc. ("we", "us"). This policy covers the mykeep mobile app, the
mykeep browser extension and desktop helper, and the gateway service at mykeep.ai.
Questions, requests, or complaints: hello@mykeep.ai.
The following never leaves your device in readable form, and we have no copy of it and no ability to recover it:
Your vault is encrypted as a whole with AES-256-GCM under a key derived from your password using argon2id, and on supported hardware that key is additionally wrapped by the device's secure enclave / hardware keystore and released only after a successful biometric check.
When an AI agent asks to use one of your secrets, the secret is used on your device: the outbound request is made from the phone with the credential injected there, the response is scanned to strip any echo of the secret, and the raw secret is never returned to our gateway or to the calling agent. Every such use requires your live approval on the device.
We would rather you read this from us than discover it yourself. There are exactly three categories.
So that we can wake your phone when an agent is waiting on your approval, your device registers a push routing token with us: an Apple (APNs) or Google (FCM) device token, plus which of the two platforms it is. This value is stored as-is and is not encrypted; we can read it, and we transmit it to Apple or Google in order to deliver the wake notification. It is held in the per-vault relay object for as long as your device stays paired.
The notification itself carries no content — it is a bare "an agent needs your approval" signal that prompts your app to reconnect. A push routing token is a pseudonymous device identifier; it does not contain your name, email, or the contents of your vault. It is the only readable, non-encrypted piece of user-linked data we retain.
Multi-device sync is optional and off until you enable it. If you turn it on, we store the following in our database so your devices can replicate:
| What | Form |
|---|---|
| Your vault records | AES-GCM ciphertext encrypted under your device key. We hold no key that opens it. |
| Device label (model / OS) | Encrypted under the same key. We store it verbatim and cannot read it. |
| Device public keys | Ed25519 public keys, used only to verify that a sync request really came from one of your devices. |
| Recovery blob | A doubly-encrypted blob, stored under an identifier derived from a recovery secret only you hold. We can open neither layer. |
| Sync bookkeeping | Sequence numbers, version vectors, deletion tombstones and a per-device sync cursor. Small technical metadata, not content. |
This is a deliberate, bounded exception to "we hold nothing": we hold ciphertext under a key we never see. We can observe that a given vault identifier is syncing, roughly how many records it has, and when. We cannot observe what any of it says.
When an agent calls your vault, the request and the response pass through our gateway on their way to and from your phone. We do not persist or cache them, and we return no stale or cached answer — if your phone is unreachable, the request fails rather than being served from our side.
An honest limitation, stated plainly: the browser-fill path is end-to-end encrypted, so we cannot read it. Memory retain/recall frames are not yet end-to-end encrypted, which means memory content passing through the gateway is technically readable in transit by the gateway while it is being relayed. We do not log, store, or inspect it, but "we do not keep it" is a weaker statement than "we could not read it", and we are not going to blur the difference. End-to-end sealing of memory frames is on our roadmap. Credentials are never affected by this: the raw secret is never placed on the wire at all.
We do not sell, rent, or share your data, and we do not use it for advertising or to train any model. We rely on a small number of infrastructure providers acting on our instructions:
We may disclose information if legally compelled. Because of the design described above, what we are able to produce is limited to the push routing token, ciphertext we cannot decrypt, and edge logs — never your secrets or your master password.
To exercise any of this, or any access, correction, portability, objection or erasure right you have under laws such as the GDPR or the CCPA/CPRA, contact hello@mykeep.ai. We do not sell or share personal information as those terms are defined under California law. Note that we cannot decrypt your vault on your behalf, so we cannot produce its contents in response to an access request — only you can.
mykeep is not directed to children under 13 (or the equivalent minimum age in your country), and we do not knowingly collect their data.
Our infrastructure is globally distributed, so the limited data described above may be processed in countries other than yours, under appropriate safeguards.
If we change this policy materially — in particular if the list in section 3 ever grows — we will update this page and note it in the app before the change takes effect.