Agentes de IA que envían correos mediante una API: controles seguros

Un agente que puede llamar a una API de correo puede contactar con tus clientes, proveedores y socios a velocidad de máquina. Esa capacidad resulta útil para avisos rutinarios y seguimientos operativos. También convierte un pequeño error en el prompt, un registro obsoleto o una sesión del agente comprometida en un problema de comunicación externa antes de que nadie lea un borrador.

Un diseño seguro no empieza con un prompt mejor. Empieza haciendo que el proceso de envío rechace destinatarios inseguros, exija aprobación cuando el mensaje supere un nivel de riesgo definido y conserve pruebas suficientes para reconstruir cada decisión. Si a la pregunta «¿A quién podría escribir este agente?» respondes «a cualquiera del CRM», no has creado un límite. Le has entregado una agenda de direcciones.

La credencial de correo nunca debe definir la autoridad del agente

La credencial que llama a la API del proveedor demuestra que un servicio puede enviar correo. No demuestra que un proceso concreto del agente deba contactar con una persona concreta para un propósito concreto. Los equipos suelen mezclar estas cuestiones porque los tokens de los proveedores son fáciles de emitir y difíciles de revisar después de una filtración.

Mantén el token del proveedor en el componente que ejecuta el envío. El agente debe enviar una intención, no conservar un token de portador reutilizable. Ese componente puede identificar la ejecución del agente, resolver los IDs de los destinatarios, inspeccionar el mensaje, exigir una decisión cuando sea necesario y llamar al proveedor solo después de superar esas comprobaciones.

Esta distinción importa cuando algo falla. Supón que un agente recibe una instrucción copiada de un ticket: «Envía el acuerdo actualizado a mi nueva dirección». Si el agente posee la credencial de correo, puede enviar el mensaje inmediatamente a cualquier dirección que aparezca en el texto. Si envía una solicitud a un componente de envío controlado, este puede rechazar la dirección no reconocida, pedir aprobación o exigir que una persona actualice el registro del contacto.

Un token de API sin controles también complica la revocación. Puedes revocar el token, pero eso podría interrumpir a todos los procesos legítimos que lo compartan. Asigna a cada proceso del agente una identidad de sesión. Termina la sesión cuando termine el proceso. Si el proceso se comporta mal, revoca esa sesión y mantén el resto del trabajo en marcha.

No pongas un token de API de correo en las variables de entorno del agente, los archivos del proyecto, el historial del shell, la configuración de herramientas ni el prompt. Ocultarlo después no arregla este diseño. Una vez que el modelo o un proceso de herramientas ha leído un secreto, ya no puedes demostrar de forma fiable por dónde pasó.

Para los equipos que usan agentes autónomos de programación en un Mac, Sallyport puede ejecutar una llamada HTTP a una API de correo sin exponer la credencial al agente. Eso resuelve la custodia de la credencial, pero no sustituye las reglas sobre destinatarios y contenido que se describen a continuación.

Los límites de destinatarios necesitan registros, no coincidencias de texto

Un límite de destinatarios debe responder si esa dirección concreta puede recibir esa clase de mensaje de ese remitente. Una lista de dominios permitidos no basta. Un proveedor puede usar un buzón personal, un cliente puede tener varios contactos y un error tipográfico puede apuntar a una dirección real de un dominio permitido.

Haz que un registro de destinatarios sea la fuente de verdad. Cada destinatario externo debe tener un ID estable y una dirección, además de la información que el servicio de envío necesita para evaluar una solicitud: relación, responsable, propósitos de mensaje permitidos, estado del consentimiento cuando corresponda y si una persona debe revisar cada envío. El agente solicita contact_4821, no [email protected].

El componente de envío resuelve el ID solo después de verificar el registro. La solicitud puede incluir un nombre visible para el renderizado, pero no debe sobrescribir la dirección guardada en el registro. Esto evita un fallo sutil que aparece a menudo en las integraciones con agentes: los desarrolladores validan un ID de contacto y después confían en un campo to escrito libremente en la misma solicitud.

Usa listas separadas para estos casos:

• clientes que aceptaron una clase definida de avisos
• contactos operativos activos de proveedores, bajo la responsabilidad de un empleado identificado
• destinatarios internos de prueba usados durante el despliegue
• destinatarios excepcionales que siempre requieren una decisión humana

No aceptes to, cc, bcc ni reply-to como cadenas sin restricciones en la interfaz que usa el agente. Bcc merece un tratamiento especial. Es útil en un conjunto limitado de procesos de cumplimiento o gestión de casos, pero también crea una vía de divulgación oculta. Desactívalo por defecto. Exige un motivo documentado y una aprobación explícita para cada destinatario Bcc que permitas.

Reply-to puede causar tantos problemas como la lista de destinatarios. Un agente puede enviar un aviso inofensivo con una dirección de respuesta que desvíe la información del cliente a un buzón sin supervisión. Resuelve los valores de reply-to desde una lista breve de perfiles de remitente en lugar de aceptarlos del agente.

Trata los datos de contacto como información mutable. Un contacto de un proveedor puede marcharse, una cuenta puede cerrarse, el consentimiento puede cambiar y un cliente puede pedir que cesen los mensajes. El proceso de envío debe comprobar el estado actual en el momento del envío, no solo cuando el agente planificó el mensaje por primera vez. Las direcciones almacenadas en caché resultan cómodas hasta que provocan que un antiguo empleado reciba una actualización contractual.

Las identidades del remitente deben dejar claro el propósito del mensaje

Un agente debe enviar desde una identidad organizativa exclusiva, no desde el buzón de un empleado y nunca desde la dirección de un ejecutivo. Los destinatarios necesitan una señal clara sobre el tipo de buzón que les ha contactado y sobre dónde llegará la respuesta.

Configura perfiles de remitente como billing-notices, service-status o vendor-operations. Cada perfil debe especificar una dirección From, un destino de respuesta, las clases de mensajes permitidas y las plantillas que puede usar. El agente elige entre IDs de perfil. No escribe encabezados From ni reply-to arbitrarios.

Esta separación limita tanto los daños como la confusión. Si un agente que gestiona actualizaciones de casos de soporte también puede usar accounts-payable, puede hacer que una solicitud de pago parezca legítima. Si todos los mensajes operativos usan una única dirección general, el personal no podrá distinguir si un mensaje inesperado procede de un proceso supervisado o de una persona.

Autentica cada identidad de envío. SPF indica a los sistemas receptores qué infraestructura puede enviar correo en nombre de un dominio. DKIM añade una firma del dominio al mensaje. DMARC publica cómo debe tratarse el mensaje cuando SPF y DKIM no están alineados. Ninguno de esos registros decide si el agente eligió al destinatario correcto. Protegen la reputación del dominio y ayudan a los receptores a evaluar la autenticidad.

RFC 5322 define el formato de los mensajes de Internet y separa campos como From, Sender, Reply-To, To, Cc y Bcc. El estándar permite muchas formas que un cliente de correo puede mostrar correctamente. La interfaz de tu agente debe ser mucho más limitada que lo que permite el formato. La flexibilidad del formato de correo no autoriza a los agentes a fabricar buzones, encabezados o listas de destinatarios.

Mantén los nombres visibles bajo control. Un mensaje de "Accounts Payable" <billing-notices@...> puede inducir a error a un proveedor cuando solicita cambios bancarios sensibles. Reserva los nombres para la función operativa real y prohíbe cualquier lenguaje que afirme que un empleado concreto envió o revisó el mensaje cuando no haya sido así.

La aprobación debe revisar el mensaje final, no el resumen del agente

Una aprobación humana solo funciona si la persona revisora ve exactamente la decisión que el sistema va a ejecutar. «El agente quiere avisar al cliente sobre una factura» no es un objeto de aprobación. Omite el cliente, el importe, el remitente, el texto, la vía de respuesta y el conjunto de archivos adjuntos.

Construye primero el mensaje, resuelve todos los destinatarios, renderiza cada variable de la plantilla y crea un registro inmutable del envío propuesto. Después presenta ese registro para su revisión. La llamada final de envío debe referirse al registro aprobado mediante su ID y rechazar cualquier cambio posterior a la aprobación.

Un registro propuesto debería incluir al menos esta estructura:

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

Guarda el contenido renderizado en un almacenamiento protegido o guarda una huella y una copia duradera conforme a tus normas de conservación. Una huella por sí sola demuestra que los bytes no cambiaron solo si aún puedes recuperar los bytes que alguien afirma haber enviado. Para los mensajes sensibles, conserva tanto el mensaje MIME renderizado como su huella.

Los criterios de aprobación deben reflejar el daño posible, no una puntuación de confianza vaga. Las puntuaciones de confianza resultan atractivas porque parecen adaptables, pero dejan a los revisores intentando entender por qué se envió un mensaje con 0,74 y se detuvo otro con 0,71. Usa condiciones claras que un operador pueda inspeccionar.

Exige aprobación cuando una solicitud haga cualquiera de estas cosas:

• introduzca un destinatario que no haya sido aprobado antes para ese propósito
• envíe un mensaje a una parte externa fuera de una clase de avisos rutinarios
• cambie datos de pago, acceso a la cuenta, contrato, precios, entrega o condiciones legales
• incluya un archivo adjunto o un destinatario Bcc
• supere el número habitual de destinatarios de esa clase de mensaje

Exige también aprobación cuando el agente cree el cuerpo a partir de instrucciones abiertas en lugar de una plantilla limitada. Un recordatorio que diga «El mantenimiento programado comienza mañana» tiene un propósito acotado. Un mensaje redactado a partir de una conversación extensa de soporte puede contener afirmaciones, promesas o datos personales que el agente haya extraído del caso equivocado.

No apruebes una sesión del agente para todo un día y lo llames revisión. Eso concede una capacidad amplia y oculta cada consecuencia. La aprobación de sesión puede autorizar al agente a preparar solicitudes. La aprobación por mensaje debe decidir la comunicación externa cuando el mensaje quede fuera de una clase de bajo riesgo previamente aprobada.

Las plantillas reducen la variación, pero no conceden permisos

Las plantillas son útiles porque limitan la redacción y facilitan la inspección. No hacen seguro un mensaje si el agente puede elegir cualquier destinatario, rellenar campos con datos sin verificar o seleccionar una plantilla cuyo propósito no coincida con el evento.

Cada plantilla necesita una clase de mensaje definida, perfiles de remitente permitidos, una relación de destinatario autorizada, campos de datos obligatorios y un número máximo de destinatarios. El renderizador debe rechazar las variables desconocidas en lugar de dejar marcadores sin completar o aceptar HTML arbitrario.

Piensa en un aviso de mantenimiento del servicio. El agente puede rellenar el nombre del cliente, una ventana de mantenimiento y una vía de soporte a partir de registros asociados a una cuenta activa. No debe rellenar una explicación de texto libre extraída de un ticket, incluir el identificador de otro cliente ni añadir un archivo adjunto porque considere que sería útil.

Una representación pequeña de la política puede hacer que estas comprobaciones sean auditables sin fingir que un motor de reglas resuelve el criterio humano:

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

El fallo que esto evita no es teórico. En un flujo habitual se renderiza una plantilla, se guarda un borrador y después se permite que el agente actualice la ventana de mantenimiento justo antes del envío. La pantalla de aprobación sigue mostrando la ventana antigua. Vincula la aprobación a la huella del contenido renderizado e invalídala cuando cambie cualquier destinatario, encabezado, variable o archivo adjunto.

Mantén las plantillas fuera del límite de autoridad del agente. El agente puede solicitar un ID de plantilla y valores estructurados. El servicio de envío debe cargar la plantilla y escapar los valores según el contexto de salida. Si el agente envía HTML completo, puede ocultar texto adicional con marcado, incluir elementos de seguimiento que no aprobaste o alterar el significado visual del mensaje.

No uses plantillas para disfrazar comunicaciones comerciales. Los avisos transaccionales y los mensajes de marketing tienen expectativas distintas en cuanto al consentimiento, la frecuencia y la cancelación de suscripción. Si no puedes clasificar claramente el mensaje, envíalo a una persona en lugar de forzarlo mediante una plantilla conveniente.

Los archivos adjuntos y los hilos citados contienen los datos que olvidas revisar

Los archivos adjuntos convierten un envío de texto controlado en un proceso de divulgación de archivos. El agente puede encontrar una propuesta antigua, exportar un ticket o generar una hoja de cálculo que incluya columnas que nadie pretendía compartir. Un revisor que solo lea el cuerpo del correo pasará por alto la parte más dañina del envío.

Exige que los archivos adjuntos entren en un área de preparación administrada por el servicio de envío. Analiza el archivo según el proceso de seguridad de tu organización, calcula una huella, etiqueta su origen y vincula ese archivo exacto al envío propuesto. La persona revisora debe poder abrir la copia preparada o ver una vista previa fiable antes de decidir.

Nunca permitas una solicitud como attach: "/Users/shared/contracts/latest.pdf" desde un agente. «Último» no es un registro, y una ruta del sistema de archivos no demuestra quién debe recibir el documento. Permite que una persona o un flujo documental aprobado cree un registro del archivo adjunto con clasificación, responsable, nombre, huella y fecha de caducidad.

Los hilos de correo citados requieren la misma cautela. Reenviar un hilo puede revelar notas internas, destinatarios anteriores, encabezados copiados y detalles de casos no relacionados. Si el agente necesita contexto, proporciónale los datos estructurados relevantes. Si debe enviar un mensaje anterior, trata el contenido reenviado como un artefacto similar a un archivo adjunto que requiere revisión.

Las imágenes y los PDF generados merecen una comprobación directa. La extracción de texto puede ayudar a los revisores a buscar números de cuenta o datos personales, pero no detectará de forma fiable todo lo que aparece en una composición visual. Una vista previa preparada es más lenta que la automatización a ciegas. Es mucho más rápida que explicar por qué un proveedor recibió la factura de otro.

Los eventos de entrega son pruebas, no permiso para reintentar indefinidamente

La respuesta de la API de correo suele significar que el proveedor aceptó tu solicitud. No significa que el buzón del destinatario haya aceptado el mensaje, que una persona lo haya leído ni que una respuesta llegue a una bandeja supervisada. Conserva el ID del mensaje del proveedor y conecta los eventos posteriores con tu ID interno de solicitud.

RFC 5321 describe el comportamiento de transferencia de SMTP, incluida la diferencia entre la aceptación por parte de un servidor y los resultados posteriores de entrega. Los proveedores de API envuelven ese transporte en una respuesta más sencilla, pero no pueden eliminar la diferencia. Trata una respuesta correcta de la API como prueba de envío al proveedor.

Registra los eventos de entrega, rebote permanente, rebote temporal, queja, cancelación de suscripción y rechazo del proveedor cuando este los proporcione. Usa esos eventos para actualizar la elegibilidad del destinatario. Un contacto con rebotes permanentes debe dejar de recibir correo operativo automatizado hasta que el responsable corrija el registro. Una queja debe retirar la dirección de la clase correspondiente de inmediato, no después de la siguiente ejecución del agente parecida a una campaña.

La lógica de reintento necesita un límite y un responsable. Los fallos temporales pueden justificar un número limitado de reintentos usando el mismo registro de mensaje aprobado. No pidas al agente que reescriba y reenvíe por su cuenta un mensaje rechazado. Un reintento reescrito puede eludir las protecciones contra duplicados y convertir una notificación fallida en varios correos incoherentes.

Elimina duplicados antes de llamar al proveedor. Deriva el valor de idempotencia del ID del envío aprobado, no del asunto mutable ni de la tarea actual del agente. Si se produce un tiempo de espera de red después del envío, el agente debe consultar el registro del envío en lugar de asumir que falló y enviar otra solicitud.

Un webhook del proveedor puede llegar tarde, dos veces o desordenado. Guárdalo como un evento con su ID del proveedor y procésalo de forma idempotente. No permitas que un evento de entrega duplicado active un segundo flujo interno ni convenza al agente de que debe enviar un seguimiento.

Un registro de auditoría debe responder a las preguntas incómodas

Cuando un cliente diga «¿Por qué me enviaste esto?», necesitarás algo más que una línea en un panel que diga sent. Debes saber qué ejecución del agente solicitó el envío, qué cuenta o flujo lo inició, qué registro de destinatario se resolvió en esa dirección, qué contenido exacto se envió, quién lo aprobó y qué aceptó el proveedor.

Conserva dos registros relacionados. Un diario de ejecuciones registra la identidad y la duración del proceso del agente, su autorización y su revocación. Un diario de llamadas registra cada envío propuesto, la decisión de validación, la aprobación, el envío al proveedor y el evento de entrega. Para unirlos debe bastar un identificador, no una investigación entre registros de aplicación.

Haz que los eventos de auditoría sean de solo adición y protégelos frente al componente que realiza el envío. Si un proceso puede borrar o reescribir su propio registro, el registro de auditoría fallará justo cuando más lo necesites. El encadenamiento de hashes ofrece una comprobación práctica contra manipulaciones: cada evento incluye la huella del evento anterior y la de sus propios datos serializados. Verifica la cadena de forma independiente.

Una secuencia mínima de eventos podría ser esta:

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...

Las marcas de tiempo por sí solas no hacen fiable un registro. Protege el almacén de eventos, registra el actor de cada transición de estado y verifica la integridad por separado del servicio que escribe los eventos. La conservación también importa. Decide durante cuánto tiempo necesitas guardar el contenido, los metadatos y los archivos adjuntos antes de que un incidente te obligue a dar una respuesta que ya no puedes respaldar.

Sallyport mantiene separadas las vistas de sesiones y actividad a partir de un único registro de auditoría cifrado y encadenado mediante hashes. Además, sp audit verify comprueba la cadena sin conexión y sin una clave del almacén. Este tipo de verificación independiente resulta útil cuando un equipo debe investigar si un registro cambió después de una ejecución del agente.

Un despliegue controlado revela las suposiciones erróneas antes que los clientes

No empieces permitiendo que un agente escriba a todos los contactos activos. Empieza con un registro interno de destinatarios y una única clase de mensajes sin consecuencias financieras, contractuales, de control de acceso ni legales. El objetivo es encontrar las diferencias entre los registros que crees tener y los que realmente usa el proceso de envío.

Realiza un piloto interno con personas que hayan aceptado recibir mensajes de prueba. Intenta deliberadamente los fallos que tu interfaz debe rechazar: una dirección desconocida, un destinatario Cc adicional, una solicitud Bcc, una variable de plantilla modificada después de la aprobación, un archivo adjunto procedente de una ruta no preparada y un reenvío después de un tiempo de espera simulado. Registra si el sistema rechazó cada solicitud y si el registro de auditoría explica el rechazo.

Después añade un caso de uso externo con un conjunto pequeño de destinatarios asignados a un responsable. Mantén activadas las aprobaciones para cada envío hasta que hayas revisado suficientes registros reales para entender los patrones de excepción. No elimines las aprobaciones porque los mensajes parezcan repetitivos. Hazlo solo cuando la fuente de destinatarios, la plantilla, el perfil de remitente, los campos de datos y el comportamiento de los reintentos estén limitados y supervisados.

Alguien debe ser responsable del registro de destinatarios y de las clases de mensajes. La automatización suele fallar en los límites entre equipos: ventas cree que soporte administra la dirección, soporte cree que finanzas administra el texto y el agente solo ve una fila de contacto. Una persona responsable puede corregir un registro obsoleto y decidir si un nuevo propósito pertenece al proceso automático.

Da a las personas un control de parada inmediato que bloquee los envíos futuros de una sesión y evite que las propuestas en cola superen la comprobación final de envío. Después pruébalo mientras haya solicitudes pendientes en la cola. Un botón de revocación que solo funciona antes de que empiece el trabajo es un adorno tranquilizador.

La primera medida útil es sencilla: enumera todos los correos externos que un agente podría enviar hoy e identifica para cada uno el registro exacto del destinatario, el perfil del remitente, la regla de aprobación, el artefacto de contenido y el evento de auditoría. Cualquier fila sin respuesta sigue siendo una llamada a una API sin límites, por muy pulido que parezca el flujo del agente.