What we can and cannot see

Your credentials stay in your vault

Hearth stores a reference — op://Hearth/ynab/credential — not the secret. It's fetched at the moment a tool runs and forgotten immediately. You rotate and revoke in 1Password, without asking us, and 1Password's own access log is a record of what we did that we do not control. If our log says we read your token twice this week and theirs says nine, we're caught.

Half of the key is never on our disk

For anything sealed here, the key is split. We hold one half; the other half lives in your MCP client and arrives only on a request you initiated. A copy of our database — a backup, a snapshot, a stolen disk — is noise on its own.

What this does not mean

We will not tell you "not even we can read it", because that sentence isn't true and you'd be right not to believe it.

• We serve this page. The code that handles your password is delivered by the party it's meant to protect you from. No amount of published hashes fixes that, because we'd be serving those too.
• We generated your connector key. The honest claim is "we did not keep a copy", not "we could not have".
• While a tool runs, we see the data. Your transactions pass through this server in the clear on the way to your AI client. We don't store them and we don't log them — but encrypted credentials are not the same as private data, and anyone telling you otherwise is being imprecise on purpose.
• Whoever runs your AI client sees the results. That's inherent: the model has to read the data to answer you.

What we do about it

Every outbound request goes through one hardened HTTP client that cannot reach a private, loopback, link-local or Tailscale address — enforced on the resolved IP, re-checked on every redirect, with the destination pinned so DNS can't be swapped underneath it. That code has 255 recorded attacks against it and a test you can run.

Every action is written to an append-only, hash-chained log that you can read and verify. The database refuses updates and deletes on it.