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)