Can an app or AI read my encrypted notes?

No — and not because we’ve told them not to. There’s nothing readable for us to hand over.

When you encrypt a note, your own device scrambles it before it’s sent. Harbor’s servers store only the scrambled version, and they hold nothing that can unscramble it. So when you approve an app, create a Personal Access Token, or connect an AI assistant, your encrypted notes simply aren’t available to it. That’s a property of how Harbor is built, not a rule we’re promising to follow.

Here’s exactly what that looks like in practice.

What a connected app actually receives

An app you authorize — a browser extension, a third-party client, anything using a token — gets the note’s record with the title and the body as unreadable ciphertext: strings of scrambled characters, not your words. Files attached to an encrypted note come back the same way, as encrypted bytes it has no way to open.

An AI assistant connected over MCP gets less than that. Instead of the note, it receives a short marker — the note’s ID, which notebook it’s in, and a line explaining that the note is encrypted and can’t be shown. It never sees even the scrambled text. On top of that:

• Encrypted notes never appear in its search results. They’re never added to the search index, and files inside them are never scanned for text, so there’s nothing to match on.
• It can’t edit an encrypted note or add to one. It gets a plain refusal.
• It can see that an encrypted note has an attachment, but it can’t download it.

What’s encrypted, and what isn’t

This is the part worth reading slowly.

Encrypted — unreadable to Harbor and to anything you connect:

• The note’s title
• The note’s body
• The files attached to the note — with one exception, below

Not encrypted — visible to Harbor’s servers, and to an app you’ve given the matching permission:

• Notebook names
• Tag names, including the tags on an encrypted note
• Attachment filenames, file types, and sizes
• When a note was created and last changed, and which notebook it’s in

That’s a deliberate trade. If notebook names were encrypted too, your sidebar couldn’t load until you’d typed your passphrase. So we encrypt the contents — where the meaning lives — and accept that the labels around them stay visible. If a filename or a notebook name would itself give something away, give it a duller name.

What encryption doesn’t cover

Everything above describes a note that is encrypted. It doesn’t describe what happened before it was — and that distinction matters, because a note can become encrypted after the fact: you can encrypt an existing note yourself, and moving a note into an encrypted notebook encrypts it on the way in.

One limit applies to any note that became encrypted rather than starting that way:

• Attached files may not be re-sealed, and how much gets covered depends on which app you use. The title and body are always sealed. The files are a different matter: the harbor command-line tool doesn’t rewrite attachment bytes at all, so they stay downloadable and readable exactly as they were. In the apps, files embedded in the note’s body are re-encrypted, but files that arrived through an Evernote import are attached a different way and are missed — the file, and the small preview image our servers generated from it, stay readable even though the note itself is locked. You can see that one in a note list: a locked note showing a legible photo.

That’s a known gap, it’s on our list, and we’d rather say so than let you assume otherwise. The safe assumption meanwhile is that anything which sat on our servers unencrypted was stored unencrypted, and encrypting the note afterwards doesn’t un-store it. Files you add to a note that is already encrypted are encrypted with it, as you’d expect — it’s the conversion of an existing note that leaves this edge.

Changing a note’s encryption deletes its history

This one isn’t a gap we’re closing. It’s deliberate, it’s permanent, and it’s worth knowing before you act rather than after.

When you encrypt a note that already existed, Harbor deletes that note’s version history. The earlier, readable versions aren’t carried across and they aren’t sealed — they’re removed from our servers, and neither you nor we can bring them back. There’s no Trash for them and no support override.

Removing encryption does the same thing in reverse. The encrypted versions go, and the note starts a fresh history from that moment. It’s easy to think of this as an encrypting-only consequence; it isn’t. Either direction costs you the history.

Everything else comes through untouched — the note’s current title and body, its notebook, its tags, its attachments, its reminders. It’s only the record of what the note used to say that goes.

We do it this way because the alternative is worse. Encryption happens on your device, so our servers can’t seal old versions themselves — every app would have to re-encrypt every snapshot, and the promise would only ever be as strong as whichever app did it worst. A half-sealed history, with readable old versions sitting behind a padlock, is exactly the failure worth avoiding. So the mismatched versions are deleted once, on our side, and every app inherits the same behaviour.

Don’t count on being asked first. The deletion happens on our servers, but the warning is each app’s own job, and they haven’t all caught up. The web app tells you before it encrypts and before it decrypts. The other apps and the harbor command-line tool may not — harbor notes encrypt goes ahead with no prompt at all. If the earlier versions of a note matter to you, open its history and save what you need before you change its encryption.

Who holds the key

You do. Your passphrase never leaves your devices. It isn’t sent to Harbor, our servers never check it, and they can’t work anything out from it.

What Harbor does store is your encryption key in a locked form — sealed with your passphrase — so a new device can pick it up and open it once you type the passphrase in. Without the passphrase it’s just more unreadable data, and there’s no version of it we can open.

Which is also why support can’t rescue you. There’s no master key, no spare copy, no override: if you lose your passphrase, the notes encrypted with it stay sealed permanently — to you and to us. Put it in a password manager the day you set it.

Where you can open them

An encrypted note opens on any device where you can type your passphrase in — the Mac app, the iPhone and iPad apps, the Windows app, the Android app, and the web app. Set encryption up on any one of them and the rest unlock with the same passphrase. You can also turn encryption on for the first time from any of them, including your phone.

Unlocking only ever puts the key in that app’s memory — it’s never written down in the open. Lock it and your encrypted notes go straight back behind their placeholder. The Mac, iPhone, iPad, Windows and Android apps also re-lock themselves after a stretch of inactivity; the first four let you set how long, and Android uses a fixed fifteen minutes. The web app has no such timer, so close the tab when you’re done on a machine you share.

You can also let a device stay unlocked, so you’re not retyping a long passphrase every time — on the Mac, iPhone, iPad and Windows apps, and in the web app. It’s off unless you switch it on.

What that leaves behind stays on that one device and never syncs: on Apple devices and Windows it goes into the system’s own credential store, and in a browser it stays inside that browser’s storage. The exact thing kept differs by platform, and each app’s Encryption screen says which. One difference is worth naming, because it’s about who does the checking: on a Mac, iPhone or iPad the operating system itself won’t hand the item over until Touch ID, Face ID or your passcode passes, while on Windows the credential is protected by Windows for your account and never leaves the PC, but the Windows Hello prompt is Harbor’s own check rather than a lock Windows puts on the credential.

Either way it’s the same trade, and it’s a real one: it’s far more convenient, and anyone who can get past that device’s sign-in can then open your encrypted notes. On a shared or borrowed device, leave it off.

Two things stay the same everywhere. A device that doesn’t have your key shows the note as locked rather than showing you scrambled text. And if a note was encrypted with a different passphrase — one you’ve since replaced, say — the app tells you so plainly instead of showing you an empty note.

One case that works differently: the CLI

Everything above is about apps talking to Harbor’s servers. The harbor command-line tool is a different situation, because it runs on your computer rather than ours.

Give the CLI your passphrase — it reads one from the HARBOR_PASSPHRASE environment variable — and it decrypts notes locally, the same way the Harbor app does once you unlock it. So an AI agent working in a terminal where you’ve set that passphrase can read your encrypted notes. Nothing has leaked; you handed over the key yourself. It’s just worth knowing before you set that variable somewhere an agent can reach.

Your unencrypted notes are a different question

Encryption protects the notes you encrypted. It doesn’t cover the rest of your library.

The notes you left unencrypted are readable by an app you authorize — limited to the permissions listed on the approval screen, and nothing beyond them. If it asked to read your notes, it can read your unencrypted notes. If it asked for your files, it can download your unencrypted attachments. That’s the whole point of connecting it, and it’s why the approval screen spells out each permission before you agree.

So the shape most people settle on: encrypt the genuinely sensitive slice — IDs, financial records, medical documents — and leave the rest working normally, where search, OCR, and your AI can actually help. There’s more on that in What’s the trade-off when I encrypt a note?

You can see every app and AI assistant you’ve connected — and cut any of them off immediately — in Harbor under Settings → Developer → Connected apps.