Proton Bridge: local readonly MCP server OOTB (or at least a readonly user+password)
For local AI usage - e.g. using local LLM, I am practically limited in how to give them readonly access to my email. The best I can do is use a local MCP like https://github.com/nikolausm/imap-mcp-server which has a parameter for readonly, but the readonly is really just a value in a file and an AI that locally does BS can mess around or run the MCP itself. And I am still in a situation to have to trust that bridge, my installation, the package source etc.
a good first step for embracing local AI securely could be to have proton bridge expose a readonly user/password OOTB in addition to the regular one.
Even better would be if Proton Bridge rather embraced the direction the world is taking. It could provide a securely controllable local MCP protocol interface OOTB. Could be an OAuth flow with the online proton account, secure tool permissions, restrictions on incoming traffic types etc.
Conceptually, local MCP is not more or less secure than a local IMAP (since it's a more modern protocol with better security protocol definitions one could even make the point that it's easier to secure). It's "just" the intended use case that is likely triggering security analysis - but the fact that a simple local bridge can wrap it (and is popular and has proton as a preconfigured builtin) is a good proof that overall proton security would be better by not driving people into bridges like that that can be really easy to mess up. Embracing MCP through the bridge would pay into security much more than denying it and I think local is the right product strategy fit for Proton (vs. remote which would be the same question as why proton has no remote IMAP server)
you have an AI product but it's not really intended or set up to replace a local AI setup with powerful data access on the assumption that local is safe (which is an assumption that proton bridge makes implicitly, too because the data then lives in the mail program's local data)
Nikolaus Kühn
shared this idea
-
Joe
commented
I strongly support this, particularly as an **official local MCP server integrated into Proton Mail Bridge**.
For me the primary use case is allowing AI agents such as ChatGPT, Claude and Codex to securely **search and read my Proton Mail**, without giving a third-party cloud service permanent access to my mailbox.
Proton Bridge already solves the difficult architectural problem: it decrypts Proton Mail locally and exposes the mailbox to trusted local applications. MCP seems like a natural extension of that model.
An ideal implementation would:
- run only on localhost by default;
- expose MCP directly from Proton Bridge;
- support read-only access as the safest default;
- provide granular scopes such as:
- search mail;
- read messages/threads;
- list folders/labels;
- read attachments;
- draft messages;
- send messages;
- modify/delete messages;
- allow individual MCP clients to be authorized and revoked;
- provide an audit log showing which client accessed which capability;
- require explicit opt-in for destructive or outbound operations.This would preserve Proton's zero-access architecture because the plaintext processing would still happen locally after Bridge decrypts the mailbox.
It would also be significantly safer than pushing technically capable Proton users toward unofficial MCP wrappers around Bridge IMAP credentials.
I would personally start with a **read/search-only MCP profile**. Being able to ask an agent:
“Find my correspondence with company X about topic Y and summarize what was agreed”
would already make Proton Mail dramatically more useful in agent-based workflows.
Longer term, the same architecture could potentially expose Proton Calendar and other Proton services through scoped MCP capabilities.
Given Proton's investment in Lumo and privacy-preserving AI, an official privacy-first MCP implementation feels particularly well aligned with Proton's direction.