Connect AI to Your Encrypted Files Without Handing Over the Keys

AI assistants are getting good at working with files. You can point one at a folder of notes and ask it to summarize a month of meetings, refactor a pile of documents, or pull every invoice that mentions a vendor. The catch is how you connect the assistant to your files in the first place.

For most cloud storage, the answer is an OAuth grant. You click "Allow," and a third party receives a token that lets it read your storage through the provider's API — broadly, server-side, and usually until you remember to revoke it. The provider already holds your plaintext, so handing an integration the same view is just one more party with a copy of everything.

Hoodik takes the opposite approach. The bridge between an AI agent and your files runs inside the Mac app, on your machine. The agent gets decrypted results locally, your encryption keys never leave the device, and the Hoodik server keeps doing the only thing it has ever done: store ciphertext it cannot read.

The Usual Model: Broad, Permanent, Server-Side Access

When you connect a typical cloud account to an external tool, the tool talks to the provider's servers on your behalf. That arrangement has three properties worth naming:

• It's broad. The token usually covers your whole account, not the one folder you cared about.
• It's permanent. Access persists until explicitly revoked, long after the task that needed it is finished.
• It's server-side. The decryption happens on infrastructure you don't control, because the provider holds the keys anyway.

None of this is malicious. It's just the shape of an architecture where the server can already read your data. Once that's true, an integration reading your data too is not a meaningful escalation. The privacy was already gone.

Hoodik's architecture never gave the server that ability in the first place — so the integration has to be built differently.

The Inverted Model: The Bridge Lives on Your Mac

Hoodik's Mac app speaks the Model Context Protocol (MCP), the open standard that AI clients like Claude Desktop and Cursor use to discover and call tools. Instead of registering a hosted service that an AI vendor connects to over the internet, the app starts a small MCP server locally, and your AI client connects to that.

This relocation is the whole point. The Hoodik server in your data center or on your NAS is untouched — it still only ever receives encrypted bytes. The component that decrypts files for the agent is the same client that decrypts them for you when you open the app, running on the same machine, under the same unlocked key. The agent never gets your keys; it gets the output of operations the app performs with them.

The feature is macOS-only. The app compiles for iOS and Android too, but a desktop where AI clients like Claude Desktop and Cursor live is the only place this makes sense, so it's gated to the Mac.

How It Works, End to End

Transport: a loopback HTTP server

When you enable AI Access, the app binds an HTTP server to 127.0.0.1 — the loopback address, reachable only from your own Mac, not from your network or the internet. It listens on port 19548 by default (configurable), and speaks JSON-RPC 2.0 over POST /mcp using MCP's Streamable HTTP transport.

Because it's bound to loopback, there is no network surface to attack from another machine. A request has to originate on the Mac itself.

Authentication: a bearer token that lives encrypted

Loopback-only is necessary but not sufficient — other processes on the same Mac could still reach 127.0.0.1. So every request must carry an Authorization: Bearer <token> header, and the server rejects anything without the exact token.

The token is a random UUID. What matters is how it's stored: it is encrypted with your account's RSA public key and written to the app's local database as ciphertext. It can only be turned back into a usable token by decrypting it with your private key — which exists in memory only while you're signed in and the app is unlocked. If someone copied the app's database off your disk, the token would be as opaque to them as your files are to the server. Regenerating the token from settings rotates it and clears any active sessions, so a leaked snippet stops working the moment you replace it.

The tools: thirteen operations, all returning plaintext locally

Once connected, the agent can discover and call thirteen tools that map onto the things you'd do in the app:

• Browsing and reading: list_files, read_file (capped at 50 MB), search_files, storage_stats
• Writing and organizing: write_file, create_directory, rename_file, move_files, delete_file
• Notes: list_notes, read_note, create_note, update_note for Hoodik's editable markdown documents

Every read tool returns decrypted content to the agent. When you ask it to read a file, the app downloads the ciphertext, decrypts the per-file key with your private key, decrypts the file with that key, and hands the plaintext to the agent — all locally. When the agent writes a file or a note, the reverse happens: the content is encrypted on the Mac before a single byte goes to the server.

search_files deserves a specific note, because it's where the privacy model could have leaked and doesn't. It uses the same privacy-preserving search the rest of Hoodik uses: the query is tokenized and hashed on-device, and only hashes go to the server. The agent gets useful results; the server never learns what was searched for. (For the full picture of how that works, see our write-up on what end-to-end encryption actually means.)

The safety layers: every call passes four gates

A tool call doesn't go straight to the file operation. It travels through a short pipeline, in this order:

1. Rate limiting. A token-bucket limiter allows about 5 requests per second with a burst of 20. An interactive agent never notices; a runaway loop hits the wall fast. This runs first so a rejected flood doesn't even cost an audit write.
2. Lock gating. When the app is PIN-locked, tool calls are denied outright. The decrypted private key may technically still be in memory, but the app treats a locked screen as "keys unavailable" so an agent can't quietly drain plaintext past a lock you thought protected you. You can optionally opt a small read-only set — listing, search, and storage stats, none of which touch a file body — into working while locked. The default is deny-everything.
3. Auditing. Every call is recorded to a local log: which tool, when, how long it took, and whether it succeeded. The parameters are SHA-256-hashed before they're stored, and the bearer token is never written in plaintext — only a short hash so the log can group calls by agent. You get an accountable trail without the log itself becoming a place your file names leak.
4. The real handler. Only after those gates does the file operation run.

Idle sessions expire after about 30 minutes, so a connection left open doesn't stay live indefinitely.

The reason the agent sees plaintext while the server sees only ciphertext comes down to where each gate runs: the entire pipeline, decryption included, executes on your Mac. The server's role is unchanged from any other Hoodik client — it stores and returns encrypted blobs. The MCP server is just another local client that happens to expose its operations to an AI agent instead of to a human tapping a screen.

Setting It Up

Enable AI Access in the Mac app's account settings. The app generates a token, starts the local server, and shows you a ready-to-paste configuration block. For Claude Desktop, it looks like this:

{
  "mcpServers": {
    "hoodik": {
      "url": "http://localhost:19548/mcp",
      "headers": {
        "Authorization": "Bearer <your-token>"
      }
    }
  }
}

Paste that into Claude Desktop's config (Settings → Developer → Edit Config), under mcpServers. The app shows the exact file path for your machine, and offers the same snippet shaped for Cursor or for any generic MCP client that speaks Streamable HTTP. A guided connect wizard walks through the steps, and a built-in test-connection probe runs the MCP handshake against the local server so you can confirm it's reachable before switching to your AI client.

The token shown in the snippet is the same secret stored encrypted on disk — it's only ever in plaintext in your AI client's config and in the app's memory while it's running. If you ever want to invalidate it, regenerate it from the same settings screen and update your client's config with the new value.

What It Can and Can't Reach — Honestly

A few limits are worth stating plainly:

• macOS only. There is no iOS or Android equivalent, by design. On those platforms you use the app directly.
• One account at a time. The server serves the account that's currently active and unlocked in the app. Sign out, and the agent's access goes with it.
• Nothing while locked, unless you've explicitly opted the read-only tools into the locked state.
• No keys, ever. The agent can ask for decrypted content, but it never receives your private key or any file's encryption key. It can act through the app; it can't walk away with the ability to decrypt your storage on its own.

One clarification, because the words overlap: this is not the same as Hoodik's public-link sharing. Public links involve a deliberate, scoped server-side decryption to protect a file's key from being exposed in a shared URL — a tradeoff we document openly. The MCP server is the opposite situation: decryption happens entirely on your own machine, and the server's job stays exactly what it has always been — storing ciphertext it cannot read.

The Point

Connecting AI to your files normally means trusting another party with broad, lasting, server-side access to data they can already read. Hoodik's design removed the server's ability to read your data years ago, so the integration had to follow suit: the bridge runs on your Mac, scoped to your unlocked session, gated and logged locally, with your keys never leaving the device.

If you want to try it, the Mac app is on the App Store, and it connects to any Hoodik server — including one you deploy yourself. Like the rest of Hoodik, the server is fully open source, so the claims here are yours to verify rather than ours to assert.