Security model

Encryption and the link#

Your device      encrypts plaintext with a fresh key
PrivateNote      stores ciphertext and access metadata
Recipient        decrypts using the key in the #fragment

A link has the form https://privatenote.ai/note/{id}#{key}. Browsers do not send URL fragments in HTTP requests. The full link is still sensitive: a person or application that receives it also receives the decryption capability.

Content and metadata#

Encrypted#

Note body, title prepended to the body, attachment contents, and encrypted attachment metadata.

Visible to the service#

Access settings, note identifiers, timestamps, account association when signed in, and network metadata needed to operate the service.

Activity labels#

MCP label is stored on the sent-note row and is not encrypted note content. Avoid secrets in labels.

Sharing link#

Contains the key. The recipient, clipboard, delivery service, and an MCP host receiving secureUrl can observe the full link.

Working with AI agents#

Use contentFilePath for a text body, filePath or filePaths for attachments, and passwordFilePath for a reveal passphrase. Ask the agent to pass paths without opening or reading those files first.

The local MCP process inspects and encrypts the bytes. The preview identifies the file and options without disclosing its contents. The model can still observe the returned secureUrl; encryption does not hide a link from the host that receives it.

Limits of protection#

• A compromised device can read plaintext before encryption or after decryption.
• A recipient can save, copy, or photograph content after reveal. Burn after reading limits future access; it cannot erase their copy.
• A password adds a reveal requirement. Send the password separately from the link.
• PrivateNote cannot recover a missing URL-fragment key from server-stored ciphertext.

Report a vulnerability#

Follow SECURITY.md in the public repository for the vulnerability-reporting process.