Security & threat model

The short version. The complete, authoritative threat model lives in docs/security.md; the security policy and per-defect fix log are in SECURITY.md. Read those before pointing proto-mcp at a live mailbox.

proto-mcp exists to make one bet safe: that letting an LLM read, organize, and send your Proton Mail can be a convenience rather than a liability. The design below is what makes that bet defensible — and the last section is the honest list of what it does not protect against.

The guarantees

Your fingerprint on every send

Each write fires a native macOS prompt showing the literal recipients and subject. mail_send has a TTL of zero, so it re-prompts every single time — there are no blanket approvals for sends. The fingerprint tap on that specific prompt is the line between “Claude drafted it” and “Claude sent it.”

Default-deny by construction

Unknown tools don’t run. A tool with no entry in the policy table fails to register at startup — you cannot accidentally ship an unguarded write. Every state-changing tool is deny-by-default and must be explicitly granted a decision (allow, prompt, or deny).

Signed, notarized, and self-checking

Binaries are hardened-runtime, Developer-ID-signed, and Apple-notarized — no Gatekeeper warning on install. At startup the daemon runs a SHA-256 integrity check and refuses to run a swapped or tampered binary.

Locks when you walk away

Screen lock, sleep, or an idle timer zero the in-memory session. Resuming takes Touch ID. The unlocked session lives in one daemon shared by every client, so locking once locks everywhere.

Honest, redacted audit log

Every tool call is logged. Secrets are scrubbed, message bodies are reduced to {sha256, bytes}, and recipients are kept literal — so the verification chain stays truthful and you can always reconstruct exactly what went where.

Local-only

The daemon listens on a 0600 Unix socket, never a network port. Claude Desktop and Claude Code attach through a tiny forwarder. Mail content goes to Proton over TLS; nothing else leaves the machine. There is no cloud component, no telemetry, no external listener.

What a send prompt looks like

What proto-mcp does not defend against

Security that hides its gaps isn’t security. The honest caveats:

• Cached bodies are plaintext-in-SQLite. Decrypted message bodies are cached locally to keep reads fast and offline (TTL-bounded, with secure_delete on). On a stolen, imaged disk that is recoverable cleartext until purged. protonmcp purge --older-than 7d --vacuum shrinks the window now; envelope encryption (SQLCipher) is a post-1.0 item.
• A compromised Mac is game over. proto-mcp defends the boundary between Claude and your mailbox. It does not defend against malware already running as your user, a physical attacker at an unlocked machine, or a kernel-level compromise.
• Prompt injection can still propose actions. A malicious email could try to get Claude to move, label, or send mail. The Touch-ID gate on sends and the default-deny policy are the backstop: the injection can ask, but it cannot make a send happen without your fingerprint on a prompt that names the real recipient.
• Not a multi-account or fleet tool. It is built for one person and one mailbox on their Mac. Don’t rate-abuse, scrape, or run multi-account automation through it — that violates Proton’s Terms.

Reporting a vulnerability

Security-load-bearing paths (internal/redact/, internal/keystore/, internal/policy/, internal/approval/, helpers/touchid/, helpers/lockwatch/) have required reviewers defined in .github/CODEOWNERS. To report a defect, follow the process in SECURITY.md rather than opening a public issue for anything sensitive.

← Back to the homepage