Você não precisa acreditar só na minha palavra

1. A versão curta

Se você não ler mais nada nesta página:

• O seu e-mail é buscado em tempo real a cada solicitação e descartado no momento em que a resposta é enviada. Não guardamos nenhuma cópia dos e-mails que o seu agente lê.
• Por caixa de entrada, armazenamos um token de acesso ou uma senha de app, criptografado com AES-256-GCM, para podermos fazer a próxima chamada que você pedir. Alguns recursos guardam uma pequena parte de uma mensagem enquanto você os usa: envios agendados e retidos, lembretes de acompanhamento e adiamentos, e o histórico de execuções das automações. A Seção 2 lista cada um deles.
• Nunca treinamos nenhum modelo de IA com o seu e-mail e nunca enviamos o seu e-mail a um modelo escolhido por nós. O seu agente é o único que o lê, sob o seu controle.
• O acesso é limitado pela credencial que você configura: as chaves de API podem ser restritas a caixas de entrada selecionadas ou ter permissão para acessar todas as caixas de entrada do espaço de trabalho. Você pode revogar o acesso do provedor a qualquer momento nas configurações do Google, da Microsoft ou do seu provedor.
• O código que executa o serviço é público. Você pode lê-lo, auditá-lo ou hospedar tudo por conta própria.

2. O que acessamos e o que armazenamos

A diferença entre acesso e armazenamento é todo o design. No momento da solicitação, o agente pode ler muita coisa, em tempo real. Quase nada disso é registrado.

As exceções deliberadas são recursos que precisam lembrar parte de uma mensagem: um envio agendado ou retido, um lembrete de acompanhamento ou um adiamento, e o histórico de execuções das automações. Cada um guarda apenas o que precisa, pelo tempo indicado na tabela acima.

3. Você não precisa confiar em mim, pode verificar

“Uma pessoa qualquer fez isso no vibe coding” é uma preocupação legítima para qualquer ferramenta hospedada que acessa o seu e-mail. A resposta certa não é uma promessa maior. É eliminar a necessidade de você acreditar na minha palavra.

• Leia o código. O servidor que executa o MCPEmails é público no GitHub. Você pode ver exatamente o que ele guarda (um token criptografado, mais os registros de recursos listados acima) e o que não guarda (os e-mails que o seu agente lê).
• Hospede você mesmo. Se preferir não usar o serviço hospedado, você pode executar o mesmo código na sua própria infraestrutura, com as suas próprias chaves: uma stack Docker de um único comando está em self-host/.
• Use uma conexão restrita e revogável. Você se conecta com OAuth ou com uma senha de app que concede apenas acesso aos e-mails, e pode revogá-la com um clique no seu provedor, sem nenhuma participação minha.
• Acompanhe o que ele faz. Cada chamada de ferramenta do seu agente é registrada em um log de atividade que você pode ler, para ver exatamente o que foi acessado e quando.

github.com/Albretsen/MCPEmails

E se um conector nativo já atende o seu provedor e faz o que você precisa, use-o. O MCPEmails existe para os provedores e as combinações de várias caixas de entrada que esses conectores não atendem.

Execute você mesmo, sem confiar em ninguém (nem em nós)

O MCPEmails é código aberto sob a licença AGPL-3.0, e o serviço hospedado executa exatamente o mesmo servidor MCP que você pode hospedar por conta própria. Isso significa que “o e-mail é buscado em tempo real e nunca é armazenado” é algo que você pode verificar executando o código e observando a rede, não algo em que precisa acreditar.

A hospedagem própria prioriza IMAP/SMTP: conecte qualquer caixa de correio com uma senha de app, e as suas credenciais são criptografadas com uma chave que só você tem. Um único comando sobe a stack inteira na sua própria máquina.

Ler o guia de hospedagem própria · AGPL-3.0

4. O risco real: prompt injection

A ameaça real aqui não sou eu lendo os seus e-mails. É um e-mail hostil tentando sequestrar o agente: instruções escondidas dentro de uma mensagem que tentam fazer a sua IA encaminhar, excluir ou vazar algo. Esse é um problema real e ainda sem solução para todo agente de e-mail. Não vou dizer que está resolvido. Posso mostrar como ele é contido:

• O acesso às caixas de entrada é configurável. As chaves de API podem ser restritas a caixas de entrada selecionadas ou receber, de forma deliberada, permissão para acessar todas as caixas de entrada de um espaço de trabalho. Uma chave restrita não consegue acessar uma caixa de entrada que não lhe foi concedida.
• Ações destrutivas são separadas e sinalizadas. Enviar e excluir são ferramentas próprias, com escopos separados; a exclusão exige confirm: true. Se um cliente mostra ou não uma confirmação ao usuário depende da política desse cliente.
• Só e-mail. As conexões pedem acesso aos e-mails, nunca à sua conta inteira: nada de agenda, arquivos ou contatos. Dentro dos e-mails o acesso é amplo, porque as ferramentas precisam dele: ler, organizar, excluir e enviar. Com o login do Google, o Gmail também nos deixa ler os seus endereços de “Enviar e-mail como”. O que o seu agente pode fazer com esse acesso é limitado pelas permissões que você concede a cada app de IA ou chave de API e pelas restrições da caixa de entrada.
• Limite de taxa. Toda chave tem limite de taxa, então um agente descontrolado ou sequestrado não consegue disparar milhares de ações sem que ninguém perceba.

Não está resolvido. Está contido: ações irreversíveis têm uma barreira, e os escopos das chaves de API e as restrições de caixa de entrada podem reduzir o raio de impacto.

5. Como as suas credenciais são protegidas

Os tokens e as senhas das suas caixas de entrada são o dado mais sensível que guardamos, então recebem a proteção mais forte que podemos oferecer:

• Todos os dados em trânsito são criptografados com TLS 1.2 ou superior. Conexões que não suportam TLS são recusadas.
• Os tokens OAuth e as credenciais IMAP são criptografados em repouso com AES-256-GCM. A chave de criptografia é mantida como um segredo de servidor, separada do banco de dados, e nunca é armazenada junto com os dados criptografados.
• As chaves de API passam por hash SHA-256 antes de serem armazenadas. A chave bruta não pode ser recuperada a partir do hash.
• O acesso ao banco de dados é protegido por políticas de Row-Level Security que impedem que um espaço de trabalho acesse os dados de outro, mesmo que uma consulta seja escrita de forma errada.
• O acesso administrativo à infraestrutura de produção exige autenticação multifator e é registrado em log.

6. Verificação do Google, da Microsoft e dos provedores

O acesso ao Gmail usa os escopos restritos do Google, a categoria que o Google examina com mais rigor.

O uso e a transferência, pelo MCPEmails, de informações recebidas das APIs do Google para qualquer outro app seguem a Política de Dados do Usuário dos Serviços de API do Google, incluindo os requisitos de Uso Limitado.

O acesso ao Outlook e ao Microsoft 365 passa pelo Microsoft Graph, a partir de um app cujo editor é verificado pela Microsoft, e solicita apenas um conjunto nomeado de permissões mostrado na tela de consentimento da Microsoft: Mail.ReadWrite, Mail.Send, offline_access, openid, profile e email. Para Fastmail, iCloud, Yahoo, Zoho, Yandex e outros provedores IMAP, você se conecta com uma senha de app emitida pelo provedor, que pode revogar a qualquer momento, sem escopos OAuth amplos que pudéssemos solicitar em excesso.

7. Suboperadores

Mantemos curta a lista de empresas que têm contato com algum dado. Cada uma trata dados apenas conforme as nossas instruções, com base em um acordo de processamento de dados ou nos termos padrão de processamento de dados do provedor, e o nosso Acordo de Processamento de Dados está disponível para clientes que precisarem dele. Repare no que não está na lista: nenhum provedor de IA. O MCPEmails não envia o seu e-mail a nenhum modelo próprio. Quem faz isso é o seu agente, sob o seu controle e de acordo com a política de dados do provedor dele.

8. Como relatar uma vulnerabilidade

Se você encontrar um problema de segurança, por favor relate. Prefiro muito mais ouvir de você do que ler sobre isso depois.

• Envie um e-mail para security@mcpemails.com com os detalhes e os passos para reproduzir o problema.
• Um contato legível por máquina está publicado em /.well-known/security.txt.
• O meu objetivo é confirmar o recebimento dos relatos em até 24 horas e corrigir problemas críticos confirmados em até 72 horas.

Porto seguro. Se você se esforçar de boa-fé para seguir esta política, não acessar nem modificar dados de outros usuários e me der uma oportunidade razoável de corrigir o problema antes de divulgá-lo, eu não vou mover nem apoiar nenhuma ação judicial contra você pela sua pesquisa.

Quem está por trás

Uma pessoa: eu. Sou Asgeir Albretsen e opero o MCPEmails por meio da Albretsen AS, uma sociedade de responsabilidade limitada de direito norueguês (aksjeselskap) da qual sou proprietário, número de organização 938 702 373, sediada em Bergen, na Noruega. Os commits também são meus, em github.com/Albretsen, então o nome nesta página e o nome no código são o mesmo. Há mais detalhes na página Sobre, e a identificação jurídica completa está nos termos.

Tudo depender de uma única pessoa é um risco real, e a resposta não é prometer que eu sempre estarei aqui. O MCPEmails é público sob a AGPL-3.0 e o serviço hospedado executa esse mesmo código, então, se eu parar, ou se você simplesmente deixar de confiar em mim, você pode clonar o repositório e executá-lo na sua própria infraestrutura, com as suas próprias chaves. O guia de hospedagem própria descreve o procedimento completo. Prefiro ser uma pessoa com nome, que você pode contatar e deixar, a ser um fornecedor anônimo em quem você só pode confiar.

Os e-mails de suporte e de segurança não passam por uma fila. Eles chegam a mim, e eu respondo pessoalmente a todas as mensagens.