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.
• L'accès est limité par l'identifiant que vous configurez : les clés API peuvent être restreintes à certaines boîtes ou autorisées à atteindre toutes les boîtes de l'espace de travail. Vous pouvez révoquer l'accès du fournisseur à 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 :

• L'accès aux boîtes est configurable. Les clés API peuvent être restreintes à certaines boîtes ou délibérément autorisées à atteindre toutes les boîtes d'un espace de travail. Une clé restreinte ne peut pas atteindre une boîte qui ne lui a pas été accordée.
• Les actions destructrices sont séparées et signalées. L'envoi et la suppression sont des outils distincts avec des portées séparées ; la suppression exige confirm: true. La présentation d'une confirmation à l'utilisateur dépend de la politique du client.
• 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 protégées, et les portées des clés API ainsi que les restrictions de boîtes peuvent réduire le rayon d'impact.

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, Microsoft et fournisseurs

L'accès à Gmail utilise les portées restreintes de Google, le niveau que Google examine le plus minutieusement.

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.

L'accès à Outlook et Microsoft 365 passe par Microsoft Graph, depuis une application dont l'éditeur est vérifié par Microsoft, et ne demande qu'un ensemble nommé d'autorisations affiché sur l'écran de consentement de Microsoft : Mail.ReadWrite, Mail.Send, offline_access, openid, profile et email. 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.

Qui est aux commandes

Une seule personne : moi. Je suis Asgeir Albretsen et j'opère sous le nom d'Albretsen Consulting, une entreprise individuelle norvégienne (enkeltpersonforetak), numéro d'organisation 926 646 753, basée à Bergen, en Norvège. Les commits sont les miens eux aussi, sous github.com/Albretsen, si bien que le nom affiché sur cette page et le nom associé au code ne sont qu'un seul et même nom. Vous trouverez plus de détails sur la page « À propos », et l'identification juridique complète figure dans les conditions.

Que tout repose sur une seule personne est un risque réel, et la réponse n'est pas de promettre que je serai toujours là. MCPEmails est public sous AGPL-3.0 et le service hébergé exécute ce même code, donc si j'arrête, ou si vous cessez simplement de me faire confiance, vous pouvez cloner le dépôt et l'exécuter sur votre propre infrastructure avec vos propres clés. Le guide d'auto-hébergement décrit toute la procédure. Je préfère être une personne identifiée que vous pouvez joindre et que vous pouvez quitter, plutôt qu'un fournisseur anonyme à qui vous ne pouvez que faire confiance.

Les messages de support et de sécurité ne passent par aucune file d'attente. Ils arrivent chez moi, et je réponds moi-même à chaque message.