Vous ne devriez pas avoir à me croire sur parole

1. La version courte

Si vous ne lisez rien d'autre sur cette page :

• Vos e-mails sont récupérés en direct à chaque requête et supprimés dès que la réponse est envoyée. Nous ne conservons aucune copie d'un quelconque corps de message, objet, pièce jointe ou contact.
• Nous stockons exactement une seule chose sensible par boîte de réception : un jeton d'accès ou un mot de passe d'application, chiffré avec AES-256-GCM, afin de pouvoir effectuer le prochain appel que vous demandez.
• Nous n'entraînons jamais aucun modèle d'IA sur vos e-mails, et nous n'envoyons jamais vos e-mails à un modèle de notre choix. Votre agent est la seule chose qui les lit, sous votre contrôle.
• Chaque connexion est limitée à la seule boîte de réception que vous avez connectée, et vous pouvez la révoquer à tout moment depuis les paramètres de Google, de Microsoft ou de votre fournisseur.
• Le code qui fait tourner le service est public. Vous pouvez le lire, l'auditer ou héberger l'ensemble vous-même.

2. Ce à quoi nous accédons vs. ce que nous stockons

L'écart entre l'accès et le stockage, c'est toute la conception. Sur l'instant, l'agent peut lire beaucoup de choses, en direct. Presque rien n'est jamais écrit.

La seule exception délibérée est un message que vous demandez à l'agent de programmer pour plus tard. Nous devons le conserver jusqu'à l'heure d'envoi, nous le stockons donc chiffré entre-temps, puis nous en gardons une trace ensuite pour votre historique.

3. Vous n'avez pas à me faire confiance, vous pouvez vérifier

« Une personne quelconque a bricolé ça » est une inquiétude légitime pour tout outil hébergé qui touche à vos e-mails. La bonne réponse n'est pas une promesse plus grande. C'est de supprimer le besoin de me croire sur parole.

• Lisez le code. Le serveur qui fait tourner MCPEmails est public sur GitHub. Vous pouvez voir exactement ce qu'il conserve (un jeton chiffré) et ce qu'il ne conserve pas (vos e-mails).
• Hébergez-le vous-même. Si vous préférez ne pas utiliser du tout le service hébergé, vous pouvez exécuter le même code sur votre propre infrastructure, avec vos propres clés : une pile Docker en une seule commande se trouve dans self-host/.
• Utilisez une connexion limitée et révocable. Vous vous connectez avec OAuth ou un mot de passe d'application qui n'accorde qu'un accès au courrier, et vous pouvez le révoquer en un clic depuis votre fournisseur, sans aucune intervention de ma part.
• Surveillez ce qu'il fait. Chaque appel d'outil effectué par votre agent est enregistré dans un journal d'activité que vous pouvez consulter, pour voir précisément ce qui a été consulté et quand.

github.com/Albretsen/MCPEmails

Et si un connecteur natif couvre déjà votre fournisseur et fait ce dont vous avez besoin, utilisez-le. Ceci existe pour les fournisseurs et les combinaisons multi-boîtes qu'ils ne couvrent pas.

Exécutez-le vous-même, ne faites confiance à personne (pas même à nous)

MCP Emails est open source sous AGPL-3.0, et le service hébergé exécute exactement le même serveur MCP que vous pouvez auto-héberger. Cela signifie que « les e-mails sont récupérés en direct et jamais stockés » est quelque chose que vous pouvez vérifier en l'exécutant et en observant le réseau, et non quelque chose que vous devez croire sur parole.

L'auto-hébergement privilégie IMAP/SMTP : connectez n'importe quelle boîte mail avec un mot de passe d'application, et vos identifiants sont chiffrés sous une clé que vous seul détenez. Une seule commande met en route toute la stack sur votre propre machine.

Lire le guide d'auto-hébergement · AGPL-3.0

4. Le vrai risque : l'injection de requête

La menace honnête ici, ce n'est pas que je lise vos e-mails. C'est un e-mail hostile qui tente de détourner l'agent : des instructions cachées dans un message qui essaient de faire transférer, supprimer ou divulguer quelque chose par votre IA. C'est un problème réel et non résolu pour tout agent de messagerie. Je ne prétendrai pas qu'il est résolu. Je peux montrer comment il est contenu :

• Une boîte de réception, un jeton. Une connexion ne peut jamais toucher que la seule boîte de réception à laquelle vous l'avez connectée. Un jeton limité ne peut pas atteindre vos autres boîtes de réception, ni celles de quiconque.
• Les actions destructrices sont séparées et signalées. L'envoi et la suppression sont leurs propres outils, marqués comme destructifs, de sorte que votre client IA demande une confirmation avant de les déclencher.
• Moindre privilège. Les connexions demandent un accès en lecture et en rédaction du courrier, pas un contrôle sur l'ensemble du compte. Même un jeton entièrement compromis est borné par la portée que vous avez accordée.
• Débit limité. Chaque clé a un débit limité, de sorte qu'un agent emballé ou détourné ne peut pas déclencher des milliers d'actions sans que cela se remarque.

Pas résolu. Contenu : les actions irréversibles sont verrouillées, et le rayon d'impact est limité à une seule boîte de réception.

5. Comment vos identifiants sont protégés

Vos jetons sont la seule chose sensible que nous détenons, ils bénéficient donc de la protection la plus forte que nous puissions leur offrir :

• Toutes les données en transit sont chiffrées avec TLS 1.2 ou supérieur. Les connexions qui ne prennent pas en charge TLS sont rejetées.
• Les jetons OAuth et les identifiants IMAP sont chiffrés au repos avec AES-256-GCM. La clé de chiffrement est conservée séparément des données chiffrées et n'est jamais située au même endroit qu'elles.
• Les clés d'API sont hachées avec SHA-256 avant le stockage. La clé brute ne peut pas être récupérée à partir du hachage.
• L'accès à la base de données est protégé par des politiques de Row-Level Security qui empêchent un espace de travail d'atteindre les données d'un autre, même si une requête est mal écrite.
• L'accès administratif à l'infrastructure de production nécessite une authentification multifacteur et est journalisé.

6. Vérification Google et fournisseurs

L'accès à Gmail utilise les portées restreintes de Google, le niveau que Google examine le plus minutieusement. Nous achevons la vérification OAuth à portées restreintes de Google ainsi que son évaluation de sécurité annuelle CASA, réalisée par un évaluateur indépendant agréé par Google. Une fois celle-ci terminée, vous ne verrez plus l'avertissement « application non vérifiée » de Google lorsque vous vous connectez.

L'utilisation et le transfert par MCPEmails des informations reçues des API de Google vers toute autre application respectent la Google API Services User Data Policy, y compris les exigences Limited Use.

Pour Fastmail, iCloud, Yahoo, Zoho, Yandex et les autres fournisseurs IMAP, vous vous connectez avec un mot de passe d'application délivré par le fournisseur, que vous pouvez révoquer à tout moment, sans aucune portée OAuth large que nous pourrions demander à l'excès.

7. Sous-traitants

Nous gardons courte la liste des entreprises qui touchent à des données, et chacune est liée par un accord de traitement des données. Notez ce qui est absent : aucun fournisseur d'IA ne figure sur cette liste. MCPEmails n'envoie vos e-mails à aucun modèle de son choix. C'est votre agent qui le fait, sous votre contrôle et selon la politique de données de son fournisseur.

8. Signaler une vulnérabilité

Si vous trouvez un problème de sécurité, signalez-le. Je préfère de loin l'apprendre de votre part plutôt que de le découvrir plus tard.

• Écrivez à security@mcpemails.com avec les détails et les étapes pour reproduire.
• Un contact lisible par machine est publié à l'adresse /.well-known/security.txt.
• Je m'efforce d'accuser réception des signalements sous 24 heures et de corriger les problèmes critiques confirmés sous 72 heures.

Sphère de sécurité. Si vous faites un effort de bonne foi pour respecter cette politique, n'accédez pas aux données d'autres utilisateurs et ne les modifiez pas, et me laissez une chance raisonnable de corriger le problème avant de le divulguer, je n'engagerai ni ne soutiendrai aucune action en justice contre vous pour vos recherches.