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.

Every app can also re-lock itself after a stretch of inactivity, and every one of them lets you choose how long: Never, 1, 5, 15, 30 minutes or 1 hour. It’s fifteen minutes unless you change it. Look in that app’s encryption settings — Settings → Security in a browser, Settings → Encryption on a Mac or PC, More → Encryption on Android, and Settings → Security → Encryption on an iPhone or iPad, which an iPhone also puts straight on the More tab.

The choice belongs to the device rather than the account, on purpose. The thing it defends against is someone walking up to this machine, so a work laptop and a home desktop can sensibly differ, and setting it on one doesn’t change the others.

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

On a Mac and in a browser that also switches the idle re-lock off, and the timer disappears from the screen: your notes stay open there until you lock them yourself or sign out. Everywhere else the timer keeps running — on Windows, iPhone, iPad and Android you get both, no passphrase to retype and a re-lock if you leave it alone. Worth knowing which of the two you’re picking. (Windows takes the timer off the screen while stay unlocked is on, but it’s still running.)

A browser catches people out three ways. Closing the tab locks it, whatever your timer says — the key only ever lives in that tab’s memory, so it goes when the tab does. Time with the tab hidden is idle time: switching to another tab doesn’t buy your session more, and it locks as soon as you come back if the window ran out while you were away. And navigating away locks it on the spot, so pressing Back later brings the page back locked rather than as you left it. Those last two need a timer to be running. Let the browser stay unlocked and none of it applies, which is the whole point of it.

What stay unlocked leaves behind stays on that one device and never syncs: on Apple devices, Windows and Android 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, iPad or Android device the operating system itself won’t hand the item over until you’ve passed its own check — Touch ID, Face ID, a fingerprint or your passcode — 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.