# Agentes de IA enviando e-mails por uma API: controles seguros

Um agente que pode chamar uma API de e-mail consegue entrar em contato com clientes, fornecedores e parceiros na velocidade de uma máquina. Esse recurso é útil para avisos de rotina e acompanhamentos operacionais. Também transforma um pequeno erro no prompt, um registro desatualizado ou uma sessão comprometida do agente em um problema de comunicação externa antes que alguém leia um rascunho.

Um projeto seguro não começa com um prompt melhor. Ele começa fazendo o caminho de envio recusar destinatários inseguros, exigir aprovação quando uma mensagem ultrapassar um limite de risco definido e preservar evidências suficientes para reconstruir cada decisão. Se sua resposta para «Quem poderia receber um e-mail deste agente?» for «qualquer pessoa no CRM», você não criou um limite. Apenas entregou a ele um catálogo de endereços.

## A credencial de e-mail nunca deve definir a autoridade do agente

A credencial que chama a API do provedor prova que um serviço pode enviar e-mails. Ela não prova que determinado processo de agente deve entrar em contato com determinada pessoa para determinada finalidade. As equipes costumam misturar essas perguntas porque é fácil emitir tokens de provedor e difícil descobrir o que aconteceu depois que eles vazam.

Mantenha o token do provedor em um componente que execute o envio. O agente deve enviar uma intenção, não manter um token bearer reutilizável. Esse componente pode identificar a execução do agente, resolver os IDs dos destinatários, inspecionar a mensagem, exigir uma decisão quando necessário e chamar o provedor somente depois que essas verificações forem aprovadas.

Essa distinção importa durante uma falha. Imagine que um agente receba de um chamado a instrução: «Envie o contrato atualizado para meu novo endereço». Se o agente possuir a credencial de e-mail, poderá enviar imediatamente para qualquer endereço que apareça no texto. Se enviar uma solicitação a um remetente controlado, esse remetente poderá rejeitar o endereço não reconhecido, pedir aprovação ou exigir que uma pessoa atualize o registro do contato.

Um token de API bruto também dificulta a revogação. Você pode revogar o token, mas isso talvez interrompa todos os workers legítimos que o compartilham. Dê a cada processo de agente uma identidade de sessão. Encerre a sessão quando o processo terminar. Se o processo se comportar mal, revogue essa sessão e mantenha os outros trabalhos em execução.

Não coloque um token de API de e-mail nas variáveis de ambiente do agente, nos arquivos do projeto, no histórico do shell, na configuração de ferramentas ou no prompt. A ofuscação não corrige esse projeto. Depois que um modelo ou processo de ferramenta leu um segredo, você não consegue provar com segurança por onde ele passou.

Para equipes que usam agentes autônomos de programação em um Mac, o Sallyport pode executar uma chamada HTTP à API de e-mail sem expor a credencial ao agente. Isso resolve a custódia da credencial, mas não substitui as regras de destinatário e conteúdo descritas abaixo.

## Os limites de destinatários precisam de registros, não de comparação de strings

Um limite de destinatário deve responder se este endereço específico pode receber esta classe de mensagem deste remetente. Uma lista de domínios permitidos, sozinha, não responde a isso. Um fornecedor pode usar uma caixa de e-mail pessoal, um cliente pode ter vários contatos e um erro de digitação ainda pode apontar para um endereço real em um domínio permitido.

Faça do cadastro de destinatários a fonte de verdade. Cada destinatário externo recebe um ID estável e um endereço, além das informações necessárias para que o serviço de envio avalie uma solicitação: relacionamento, responsável, finalidades de mensagem permitidas, status de consentimento quando relevante e indicação de que uma pessoa precisa revisar cada envio. O agente solicita `contact_4821`, não `ap@northwind.example`.

O remetente resolve o ID somente depois de verificar o registro. A solicitação pode levar um nome de exibição para renderização, mas não deve substituir o endereço armazenado no cadastro. Isso evita uma falha sutil que aparece com frequência em integrações de agentes: os desenvolvedores validam um ID de contato e depois confiam em um campo `to` livre da mesma solicitação.

Use listas separadas para estes casos:

- clientes que aceitaram uma classe definida de avisos
- contatos operacionais ativos de fornecedores, sob responsabilidade de uma pessoa nomeada
- destinatários internos de teste usados durante a implantação
- destinatários excepcionais que sempre exigem uma decisão humana

Não aceite `to`, `cc`, `bcc` ou reply-to como strings sem restrições na interface voltada ao agente. Bcc exige atenção especial. Ele é útil em alguns fluxos restritos de conformidade ou gerenciamento de casos, mas também cria um caminho oculto para divulgação. Desative-o por padrão. Exija uma justificativa documentada e uma aprovação explícita para cada destinatário em Bcc permitido.

Reply-to pode causar tantos problemas quanto a lista de destinatários. Um agente pode enviar um aviso inofensivo com um endereço reply-to que encaminhe informações de clientes para uma caixa de entrada sem monitoramento. Resolva os valores de reply-to a partir de uma lista curta de perfis de remetente, em vez de aceitá-los do agente.

Trate os dados de contato como mutáveis. Um contato de fornecedor pode sair da empresa, uma conta pode ser encerrada, o consentimento pode mudar e um cliente pode pedir que as mensagens parem. O caminho de envio deve verificar o status atual no momento do envio, não apenas quando o agente planejou a mensagem. Endereços armazenados em cache são convenientes até se tornarem o motivo pelo qual um ex-funcionário recebe uma atualização de contrato.

## As identidades do remetente devem deixar clara a finalidade da mensagem

Um agente deve enviar mensagens a partir de uma identidade organizacional dedicada, nunca de uma caixa de e-mail de funcionário e jamais de um endereço executivo. Os destinatários precisam saber claramente que tipo de caixa entrou em contato e para onde uma resposta será enviada.

Configure perfis de remetente como `billing-notices`, `service-status` ou `vendor-operations`. Cada perfil deve especificar um endereço From, um destino de resposta, as classes de mensagem permitidas e os modelos que pode usar. O agente escolhe entre IDs de perfil. Ele não escreve cabeçalhos From ou reply-to arbitrários.

Essa separação limita tanto os danos quanto a confusão. Se um agente que lida com atualizações de chamados de suporte também puder usar `accounts-payable`, ele poderá fazer uma solicitação de pagamento parecer legítima. Se todas as mensagens operacionais usarem um único endereço amplo, a equipe não saberá se uma mensagem inesperada veio de um processo monitorado ou de uma pessoa.

Autentique cada identidade de envio. SPF informa aos sistemas receptores qual infraestrutura pode enviar e-mails por um domínio. DKIM anexa uma assinatura do domínio à mensagem. DMARC publica como o domínio deseja que mensagens sejam tratadas quando SPF e DKIM falham no alinhamento. Nenhum desses registros decide se o agente escolheu o destinatário correto. Eles protegem a reputação do domínio e ajudam os receptores a avaliar a autenticidade.

A RFC 5322 define o formato de mensagens da Internet e separa campos como From, Sender, Reply-To, To, Cc e Bcc. O padrão permite muitas formas que um cliente de e-mail pode exibir corretamente. A interface do agente deve ser muito mais restrita do que o formato permite. A flexibilidade do formato de e-mail não autoriza agentes a criar caixas de e-mail, cabeçalhos ou listas de destinatários.

Mantenha os nomes de exibição conservadores. Uma mensagem de `"Accounts Payable" <billing-notices@...>` pode enganar um fornecedor quando pede alterações bancárias sensíveis. Reserve os nomes para a função operacional real e proíba linguagem que afirme que uma pessoa nomeada enviou ou revisou a mensagem quando isso não aconteceu.

## A aprovação deve inspecionar a mensagem final, não o resumo do agente

Uma aprovação humana só funciona quando a pessoa revisora vê exatamente a decisão que o sistema executará. «O agente quer avisar o cliente sobre uma fatura» não é um objeto de aprovação. Essa descrição omite o cliente, o valor, o remetente, o texto, o caminho de resposta e os anexos.

Monte primeiro a mensagem, resolva todos os destinatários, renderize cada variável do modelo e crie um registro imutável de envio proposto. Depois, apresente esse registro para revisão. A chamada final de envio deve referir-se ao registro aprovado pelo ID e rejeitar qualquer alteração feita depois da aprovação.

Um registro proposto deve ter, no mínimo, este formato:

```json
{
  "request_id": "req_01J...",
  "agent_session": "sess_01J...",
  "purpose": "vendor_invoice_query",
  "sender_profile": "vendor-operations",
  "to": [{"contact_id": "vendor_4821", "address": "ap@example.test"}],
  "cc": [],
  "bcc": [],
  "subject": "Question about invoice INV-1048",
  "body_sha256": "6af1...",
  "attachment_sha256": [],
  "approval_required": true
}
```

Armazene o conteúdo renderizado em armazenamento protegido ou guarde um resumo criptográfico junto a uma cópia durável, conforme suas regras de retenção. Um resumo sozinho prova que os bytes não mudaram apenas se você ainda puder recuperar os bytes que alguém afirma ter enviado. Para mensagens sensíveis, preserve tanto a mensagem MIME renderizada quanto seu resumo.

Os gatilhos de aprovação devem refletir o dano, não uma pontuação vaga de confiança. Pontuações de confiança parecem atraentes porque soam adaptáveis, mas deixam as pessoas revisoras tentando entender por que uma mensagem com pontuação 0,74 foi enviada e outra com 0,71 foi interrompida. Use condições claras que uma pessoa operadora possa inspecionar.

Exija aprovação quando uma solicitação:

- incluir um destinatário que ainda não foi aprovado para aquela finalidade
- for enviada a uma parte externa fora de uma classe de avisos de rotina
- alterar pagamento, acesso à conta, contrato, preço, entrega ou termos jurídicos
- incluir um anexo ou um destinatário em Bcc
- exceder a quantidade conhecida de destinatários daquela classe de mensagem

Exija aprovação também quando o agente criar o corpo a partir de instruções abertas, em vez de um modelo restrito. Um lembrete que diz «Sua manutenção programada começa amanhã» tem uma finalidade delimitada. Uma mensagem redigida a partir de uma longa conversa de suporte pode conter alegações, promessas ou dados pessoais que o agente retirou do caso errado.

Não aprove uma sessão de agente por um dia e chame isso de revisão. Isso concede uma capacidade ampla enquanto oculta cada consequência. A aprovação de sessão pode autorizar o agente a preparar solicitações. A aprovação por mensagem deve decidir sobre a comunicação externa quando a mensagem estiver fora de uma classe de baixo risco previamente aprovada.

## Os modelos reduzem a variação, mas não concedem permissão

Os modelos são úteis porque limitam o texto e facilitam a inspeção. Eles não tornam uma mensagem segura se o agente puder escolher qualquer destinatário, preencher campos com dados não verificados ou selecionar um modelo cuja finalidade não corresponda ao evento.

Cada modelo precisa de uma classe de mensagem definida, perfis de remetente permitidos, relacionamento de destinatário autorizado, campos de dados obrigatórios e um número máximo de destinatários. O renderizador deve rejeitar variáveis desconhecidas, em vez de deixar marcadores silenciosamente ou aceitar HTML arbitrário.

Considere um aviso de manutenção do serviço. O agente pode preencher o nome do cliente, a janela de manutenção e um canal de suporte a partir de registros associados a uma conta ativa. Ele não deve preencher uma explicação livre retirada de um chamado, incluir o identificador de outro cliente ou adicionar um anexo porque considera isso útil.

Uma pequena representação de política pode tornar essas verificações auditáveis sem fingir que um mecanismo de regras resolve questões de julgamento:

```yaml
message_class: scheduled_maintenance
sender_profile: service-status
recipient_relationship: active_customer
max_recipients: 1
allowed_template: maintenance_notice_v3
approval:
  required_if:
    - attachment_present
    - recipient_status_not_active
    - maintenance_window_changed_after_render
```

A falha evitada aqui não é teórica. Um fluxo comum renderiza um modelo, armazena um rascunho e depois permite que o agente altere a janela de manutenção imediatamente antes do envio. A tela de aprovação ainda mostra a janela antiga. Vincule a aprovação ao resumo do conteúdo renderizado e invalide-a quando qualquer destinatário, cabeçalho, variável ou anexo mudar.

Mantenha os modelos fora do limite de autoridade do agente. Um agente pode solicitar um ID de modelo e valores estruturados. O serviço de envio deve carregar o modelo e escapar os valores de acordo com o contexto de saída. Se o agente enviar HTML completo, poderá esconder texto extra com marcação, incluir material de rastreamento não aprovado ou alterar o significado visual da mensagem.

Não use modelos para disfarçar prospecção. Avisos transacionais e mensagens de marketing têm expectativas diferentes de consentimento, frequência e cancelamento de assinatura. Se não conseguir classificar a mensagem com clareza, encaminhe-a para uma pessoa em vez de forçá-la a passar por um modelo conveniente.

## Anexos e conversas citadas carregam os dados que você esquece de revisar

Anexos transformam um envio de texto controlado em um fluxo de divulgação de arquivos. O agente pode encontrar uma proposta antiga, exportar um chamado ou gerar uma planilha com colunas que ninguém pretendia compartilhar. Uma pessoa revisora que leia apenas o corpo do e-mail deixará de ver a parte mais prejudicial do envio.

Exija que os anexos entrem em uma área de preparação controlada pelo serviço de envio. Faça a verificação do arquivo conforme o processo de segurança da organização, calcule um resumo, identifique sua origem e vincule o arquivo exato ao envio proposto. A pessoa revisora deve poder abrir a cópia preparada ou ver uma prévia confiável antes de decidir.

Nunca permita uma solicitação como `attach: "/Users/shared/contracts/latest.pdf"` vinda de um agente. «Mais recente» não é um registro, e um caminho do sistema de arquivos não prova quem deve receber o documento. Uma pessoa ou um fluxo de documentos aprovado deve criar um registro de anexo com classificação, responsável, nome do arquivo, resumo e validade.

Conversas de e-mail citadas exigem a mesma cautela. Encaminhar uma conversa pode revelar notas internas, destinatários anteriores, cabeçalhos copiados e detalhes de casos não relacionados. Se o agente precisar de contexto, forneça os fatos estruturados relevantes. Se precisar enviar uma mensagem anterior, trate o conteúdo encaminhado como um artefato semelhante a um anexo que exige revisão.

Imagens e PDFs gerados merecem uma verificação direta. A extração de texto pode ajudar as pessoas revisoras a procurar números de conta ou dados pessoais, mas não detecta tudo de forma confiável em um layout visual. Uma prévia preparada é mais lenta do que a automação às cegas. É muito mais rápida do que explicar por que um fornecedor recebeu a fatura de outro fornecedor.

## Eventos de entrega são evidências, não permissão para tentar novamente sem limite

A resposta da API de e-mail geralmente significa que o provedor aceitou sua solicitação. Ela não significa que a caixa de entrada do destinatário aceitou a mensagem, que uma pessoa a leu ou que uma resposta chegará a uma fila monitorada. Preserve o ID da mensagem do provedor e associe eventos posteriores ao ID interno da solicitação.

A RFC 5321 descreve o comportamento de transferência do SMTP, incluindo a diferença entre a aceitação por um servidor e os resultados posteriores da entrega. Os provedores de API envolvem esse transporte em uma resposta mais simples, mas não podem eliminar essa diferença. Trate uma resposta de API bem-sucedida como evidência de envio ao provedor.

Registre eventos de entrega, devolução permanente, devolução temporária, reclamação, cancelamento de assinatura e rejeição do provedor quando ele oferecer esses dados. Use esses eventos para atualizar a elegibilidade do destinatário. Um contato que sofre uma devolução permanente deve deixar de receber e-mails operacionais automatizados até que uma pessoa responsável corrija o registro. Uma reclamação deve remover imediatamente o endereço da classe relevante, não apenas na próxima execução semelhante a uma campanha.

A lógica de novas tentativas precisa de um limite e de uma pessoa responsável. Falhas temporárias podem justificar uma nova tentativa limitada usando o mesmo registro de mensagem aprovado. Não peça ao agente para reescrever e reenviar uma mensagem rejeitada por conta própria. Uma nova tentativa reescrita pode contornar proteções contra duplicação e transformar uma notificação malsucedida em vários e-mails inconsistentes.

Elimine duplicidades antes da chamada ao provedor. Derive o valor de idempotência do ID do envio aprovado, não do assunto mutável nem da tarefa atual do agente. Se ocorrer um timeout de rede depois do envio, o agente deve consultar o registro de envio, em vez de presumir uma falha e enviar outra solicitação.

Um webhook do provedor pode chegar atrasado, duas vezes ou fora de ordem. Armazene-o como um evento com o ID do provedor e processe-o de forma idempotente. Não permita que um evento de entrega duplicado acione um segundo fluxo interno ou convença um agente de que deve enviar uma mensagem de acompanhamento.

## Um registro de auditoria deve responder às perguntas desconfortáveis

Quando um cliente perguntar «Por que você me enviou isso?», você precisará de mais do que uma linha no painel dizendo `sent`. Será necessário descobrir qual execução do agente solicitou o envio, qual conta ou fluxo o iniciou, qual registro de destinatário foi resolvido para aquele endereço, qual conteúdo exato foi enviado, quem o aprovou e o que o provedor aceitou.

Mantenha duas trilhas relacionadas. Um diário de execuções acompanha a identidade e a duração do processo do agente, sua autorização e sua revogação. Um diário de chamadas acompanha cada envio proposto, decisão de validação, aprovação, envio ao provedor e evento de entrega. A associação entre os dois deve exigir um identificador, não uma investigação em vários logs da aplicação.

Torne os eventos de auditoria somente de acréscimo e proteja-os do componente que realiza o envio. Se um worker puder apagar ou reescrever seu próprio registro, a trilha de auditoria falhará justamente quando você mais precisar dela. O encadeamento de hashes oferece uma verificação prática contra adulteração: cada evento inclui o resumo do evento anterior e seus próprios dados serializados. Verifique a cadeia de forma independente.

Uma sequência mínima de eventos pode ser assim:

```text
2025-04-03T09:12:04Z proposed  req_01J... sess_01J... digest=6af1...
2025-04-03T09:12:10Z approved  req_01J... reviewer=user_17 digest=6af1...
2025-04-03T09:12:11Z submitted req_01J... provider_id=msg_92...
2025-04-03T09:12:14Z delivered req_01J... provider_event=evt_44...
```

Os registros não se tornam confiáveis apenas por terem timestamps. Proteja o armazenamento de eventos, registre o ator de cada transição de estado e verifique a integridade separadamente do serviço que grava os eventos. A retenção também importa. Decida por quanto tempo precisa manter conteúdo de mensagens, metadados e anexos antes que um incidente force uma resposta que você já não possa dar.

O Sallyport mantém visões separadas de sessões e atividades em um único log de auditoria criptografado e encadeado por hashes, e `sp audit verify` verifica a cadeia offline sem uma chave do cofre. Esse tipo de verificação independente é útil quando uma equipe precisa investigar se um registro mudou depois de uma execução do agente.

## Uma implantação controlada revela premissas erradas antes dos clientes

Não comece permitindo que um agente envie e-mails para todos os contatos ativos. Comece com um cadastro interno de destinatários e uma única classe de mensagem sem consequências financeiras, contratuais, de controle de acesso ou jurídicas. O objetivo é encontrar divergências entre os registros que você acredita ter e os registros usados de fato pelo caminho de envio.

Faça um piloto interno com pessoas que tenham concordado em receber mensagens de teste. Tente deliberadamente as falhas que sua interface precisa rejeitar: um endereço desconhecido, um destinatário extra em Cc, uma solicitação de Bcc, uma variável de modelo alterada depois da aprovação, um anexo vindo de um caminho não preparado e um novo envio depois de um timeout simulado. Registre se o sistema rejeitou cada solicitação e se a trilha de auditoria explica a rejeição.

Depois, acrescente um caso de uso externo com um conjunto pequeno e administrado de destinatários. Mantenha as aprovações ativadas para todos os envios até revisar registros reais suficientes para compreender os padrões de exceção. Não remova aprovações porque as mensagens parecem repetitivas. Remova-as apenas quando a origem dos destinatários, o modelo, o perfil do remetente, os campos de dados e o comportamento de novas tentativas estiverem restritos e monitorados.

Alguém deve ser responsável pelo cadastro de destinatários e pelas classes de mensagem. A automação costuma falhar nas fronteiras entre equipes: vendas acha que suporte é responsável pelo endereço, suporte acha que finanças é responsável pelo texto e o agente vê apenas uma linha de contato. Uma pessoa nomeada pode corrigir um registro desatualizado e decidir se uma nova finalidade pertence ao caminho automático.

Dê às pessoas um controle de parada imediato que bloqueie futuros envios de uma sessão e impeça que propostas em fila passem pela verificação final de envio. Depois, teste-o enquanto houver solicitações pendentes na fila. Um botão de revogação que funciona apenas antes do início do trabalho é um enfeite tranquilizador.

A primeira ação útil é simples: liste todos os e-mails externos que um agente poderia enviar hoje e identifique, para cada um, o registro exato do destinatário, o perfil do remetente, a regra de aprovação, o artefato de conteúdo e o evento de auditoria. Qualquer linha sem uma resposta ainda é uma chamada de API sem limites, por mais sofisticado que pareça o fluxo do agente.