Sie sollten mir nicht einfach glauben müssen

1. Die Kurzfassung

Falls Sie sonst nichts auf dieser Seite lesen:

• Ihre E-Mails werden bei jeder Anfrage live abgerufen und verworfen, sobald die Antwort gesendet ist. Wir behalten keine Kopie von Nachrichtentext, Betreff, Anhang oder Kontakt.
• Pro Postfach speichern wir genau eine sensible Sache: ein Zugriffstoken oder App-Passwort, verschlüsselt mit AES-256-GCM, damit wir Ihren nächsten Aufruf ausführen können.
• Wir trainieren nie ein KI-Modell mit Ihren E-Mails und senden sie nie an ein Modell unserer Wahl. Nur Ihr Agent liest sie, unter Ihrer Kontrolle.
• Der Zugriff hängt von den Zugangsdaten ab, die Sie einrichten: API-Schlüssel lassen sich auf ausgewählte Postfächer beschränken oder für alle Postfächer im Workspace freigeben. Den Anbieterzugriff können Sie jederzeit in den Einstellungen von Google, Microsoft oder Ihrem Anbieter widerrufen.
• Der Code, auf dem der Dienst läuft, ist öffentlich. Sie können ihn lesen, prüfen oder alles selbst hosten.

2. Was wir abrufen und was wir speichern

Der Unterschied zwischen Abruf und Speicherung ist das ganze Konzept. Im Moment der Anfrage kann der Agent vieles live lesen. Fast nichts davon wird je gespeichert.

Die bewussten Ausnahmen sind ausgehende Nachrichten, die warten müssen: eine Nachricht, die der Agent später senden soll, und eine Sendung, die auf Ihre Freigabe wartet. Wir müssen sie vorhalten, bis sie rausgehen, speichern sie so lange verschlüsselt und behalten danach einen Eintrag für Ihren Verlauf.

3. Sie müssen mir nicht vertrauen, Sie können es prüfen

„Das hat irgendwer schnell zusammengecodet“ ist eine berechtigte Sorge bei jedem gehosteten Tool, das auf Ihre E-Mails zugreift. Die richtige Antwort ist kein größeres Versprechen, sondern dass Sie mir gar nicht aufs Wort glauben müssen.

• Lesen Sie den Code. Der Server hinter MCPEmails ist öffentlich auf GitHub. Sie sehen genau, was er speichert (ein verschlüsseltes Token) und was nicht (Ihre E-Mails).
• Hosten Sie es selbst. Wenn Sie den gehosteten Dienst gar nicht nutzen möchten, betreiben Sie denselben Code auf Ihrer eigenen Infrastruktur mit Ihren eigenen Schlüsseln: Ein Docker-Stack mit einem einzigen Befehl liegt in self-host/.
• Nutzen Sie eine begrenzte, widerrufbare Verbindung. Sie verbinden sich per OAuth oder App-Passwort, das nur E-Mail-Zugriff gewährt, und können es bei Ihrem Anbieter mit einem Klick widerrufen, ganz ohne mich.
• Sehen Sie, was passiert. Jeder Tool-Aufruf Ihres Agenten landet in einem Aktivitätsprotokoll, das Sie lesen können. So sehen Sie genau, worauf wann zugegriffen wurde.

github.com/Albretsen/MCPEmails

Und wenn ein nativer Konnektor Ihren Anbieter schon abdeckt und alles kann, was Sie brauchen, nutzen Sie ihn. MCPEmails gibt es für die Anbieter und Kombinationen mehrerer Postfächer, die diese nicht abdecken.

Selbst betreiben, niemandem vertrauen (auch uns nicht)

MCPEmails ist Open Source unter AGPL-3.0, und der gehostete Dienst läuft auf genau demselben MCP-Server, den Sie selbst hosten können. „E-Mails werden live abgerufen und nie gespeichert“ können Sie also prüfen, indem Sie ihn betreiben und den Netzwerkverkehr beobachten. Sie müssen es nicht einfach glauben.

Self-Hosting setzt auf IMAP/SMTP: Verbinden Sie jedes Postfach mit einem App-Passwort. Ihre Zugangsdaten werden mit einem Schlüssel verschlüsselt, den nur Sie besitzen. Ein einziger Befehl startet den ganzen Stack auf Ihrem eigenen Rechner.

Zur Self-Hosting-Anleitung · AGPL-3.0

4. Das eigentliche Risiko: Prompt-Injection

Die echte Gefahr ist nicht, dass ich Ihre E-Mails lese. Es ist eine feindselige E-Mail, die den Agenten kapern will: versteckte Anweisungen in einer Nachricht, die Ihre KI dazu bringen sollen, etwas weiterzuleiten, zu löschen oder preiszugeben. Das ist ein reales, ungelöstes Problem für jeden E-Mail-Agenten. Ich behaupte nicht, es sei gelöst. Ich kann zeigen, wie es eingedämmt wird:

• Der Postfachzugriff ist konfigurierbar. API-Schlüssel lassen sich auf ausgewählte Postfächer beschränken oder bewusst für alle Postfächer eines Workspace freigeben. Ein beschränkter Schlüssel erreicht kein Postfach, für das er nicht freigegeben wurde.
• Destruktive Aktionen sind getrennt und gekennzeichnet. Senden und Löschen sind eigene Tools mit eigenen Berechtigungen; Löschen erfordert confirm: true. Ob ein Client eine Bestätigung beim Nutzer einholt, bestimmt die Richtlinie dieses Clients.
• Minimale Rechte. Verbindungen fordern Lese- und Schreibzugriff auf E-Mails an, keine Kontrolle über das ganze Konto. Selbst ein vollständig kompromittiertes Token ist auf die von Ihnen erteilten Rechte begrenzt.
• Ratenlimits. Jeder Schlüssel hat ein Ratenlimit. Ein außer Kontrolle geratener oder gekaperter Agent kann also nicht unbemerkt Tausende Aktionen auslösen.

Nicht gelöst, aber eingedämmt: Unumkehrbare Aktionen sind abgesichert, und die Berechtigungen von API-Schlüsseln sowie Postfachbeschränkungen können den möglichen Schaden begrenzen.

5. So werden Ihre Zugangsdaten geschützt

Ihre Tokens sind das einzig Sensible, das wir aufbewahren. Deshalb bekommen sie den stärksten Schutz, den wir bieten können:

• Alle Daten werden bei der Übertragung mit TLS 1.2 oder höher verschlüsselt. Verbindungen ohne TLS werden abgelehnt.
• OAuth-Tokens und IMAP-Zugangsdaten werden im Ruhezustand mit AES-256-GCM verschlüsselt. Der Schlüssel liegt als Server-Secret getrennt von der Datenbank und wird nie zusammen mit den verschlüsselten Daten gespeichert.
• API-Schlüssel werden vor dem Speichern mit SHA-256 gehasht. Der Schlüssel selbst lässt sich aus dem Hash nicht wiederherstellen.
• Der Datenbankzugriff ist durch Row-Level-Security-Richtlinien geschützt. Sie verhindern, dass ein Workspace auf die Daten eines anderen zugreift, selbst wenn eine Abfrage fehlerhaft geschrieben ist.
• Administrativer Zugriff auf die Produktionsinfrastruktur erfordert Multi-Faktor-Authentifizierung und wird protokolliert.

6. Prüfung durch Google, Microsoft und Anbieter

Der Gmail-Zugriff nutzt die eingeschränkten Scopes von Google, also die Stufe, die Google am genauesten prüft.

Die Nutzung und Weitergabe von Informationen, die MCPEmails über Google-APIs erhält, an andere Apps entspricht der Google API Services User Data Policy, einschließlich der Anforderungen zur eingeschränkten Nutzung (Limited Use).

Der Zugriff auf Outlook und Microsoft 365 läuft über Microsoft Graph, über eine App mit von Microsoft verifiziertem Herausgeber, und fordert nur die benannten Berechtigungen an, die auf dem Zustimmungsbildschirm von Microsoft stehen: Mail.ReadWrite, Mail.Send, offline_access, openid, profile und email. Bei Fastmail, iCloud, Yahoo, Zoho, Yandex und anderen IMAP-Anbietern verbinden Sie sich mit einem App-Passwort Ihres Anbieters, das Sie jederzeit widerrufen können. Es gibt keine weitreichenden OAuth-Scopes, die wir zu großzügig anfordern könnten.

7. Unterauftragsverarbeiter

Die Liste der Unternehmen, die überhaupt mit Daten in Berührung kommen, halten wir kurz, und jedes ist an einen Auftragsverarbeitungsvertrag gebunden. Beachten Sie, was fehlt: Kein KI-Anbieter steht auf dieser Liste. MCPEmails sendet Ihre E-Mails an kein eigenes Modell. Das tut Ihr Agent, unter Ihrer Kontrolle und nach den Datenrichtlinien seines Anbieters.

8. Eine Sicherheitslücke melden

Wenn Sie ein Sicherheitsproblem finden, melden Sie es bitte. Ich höre es viel lieber von Ihnen, als später darüber zu lesen.

• Schreiben Sie an security@mcpemails.com, mit Details und Schritten zur Reproduktion.
• Ein maschinenlesbarer Kontakt ist unter /.well-known/security.txt veröffentlicht.
• Ich bestätige Meldungen möglichst innerhalb von 24 Stunden und behebe bestätigte kritische Probleme möglichst innerhalb von 72 Stunden.

Safe Harbor. Wenn Sie sich in gutem Glauben an diese Richtlinie halten, nicht auf Daten anderer Nutzer zugreifen oder sie verändern und mir angemessen Zeit zur Behebung geben, bevor Sie das Problem offenlegen, werde ich keine rechtlichen Schritte gegen Sie wegen Ihrer Forschung einleiten oder unterstützen.

Wer dahintersteht

Eine Person: ich. Ich bin Asgeir Albretsen und betreibe den Dienst über die Albretsen AS, eine norwegische Gesellschaft mit beschränkter Haftung (aksjeselskap), die mir gehört, Organisationsnummer 938 702 373, mit Sitz in Bergen, Norwegen. Die Commits sind auch von mir, unter github.com/Albretsen. Der Name auf dieser Seite und der Name am Code sind also derselbe. Mehr steht auf der Über-uns-Seite, die vollständigen rechtlichen Angaben finden Sie in den Nutzungsbedingungen.

Dass alles an einer Person hängt, ist ein echtes Risiko, und die Antwort darauf ist nicht das Versprechen, dass ich immer da sein werde. MCPEmails ist unter AGPL-3.0 öffentlich, und der gehostete Dienst läuft auf genau diesem Code. Wenn ich aufhöre oder Sie mir einfach nicht mehr vertrauen, können Sie das Repository klonen und auf Ihrer eigenen Infrastruktur mit Ihren eigenen Schlüsseln betreiben. Die Self-Hosting-Anleitung beschreibt das komplette Vorgehen. Ich bin lieber eine namentlich bekannte Person, die Sie erreichen und verlassen können, als ein anonymer Anbieter, dem Sie nur vertrauen können.

Support- und Sicherheitsmails landen in keiner Warteschlange. Sie kommen bei mir an, und ich beantworte jede Nachricht selbst.