Un agente de IA que pueda enviar correo puede generar consecuencias comerciales incluso cuando se pasa cada mensaje SPF, DKIM y DMARC. La autenticación aborda aspectos de la identidad del dominio de envío; no establece que el mensaje haya sido autorizado, exacto o apropiado. Gobierna la acción de envío como una capacidad separada con un propósito definido y un alcance de destinatario.
Definir lo que el agente puede comunicar
Especifique los casos de uso aprobados, la cuenta de envío, las fuentes de los destinatarios, los límites de volumen, las reglas de archivos adjuntos y los requisitos de revisión. Los resúmenes de estado interno de rutina y los compromisos contractuales no deben compartir la misma ruta de aprobación autónoma. Restrinja los destinatarios externos y el contenido sensible de acuerdo con la política de la organización y establezca quién puede cambiar esa política.
Obtenga la identidad del destinatario de un directorio confiable o de una dirección aprobada explícitamente, no de una instrucción incorporada en un correo electrónico que se está analizando. Un mensaje que dice enviar el informe a esta nueva dirección es evidencia para evaluar, no autorización automática. Inyección rápida de OWASP explica por qué el texto externo puede manipular el comportamiento del agente si se lo trata como una instrucción.
Mantenga la autoridad de envío separada de la lectura
Utilice una identidad de envío con solo los permisos de API y buzón de correo necesarios. Una integración de lectura de informes no debe obtener silenciosamente la autoridad de enviar como o enviar en nombre. Mantenga la generación, aprobación y envío de borradores como eventos registrados separados. Antes de enviarlo, vuelva a verificar los destinatarios, el asunto, el cuerpo y los archivos adjuntos con la versión aprobada.
Agencia excesiva de OWASP recomienda limitar las funciones y permisos expuestos y hacer cumplir la autorización en sentido descendente. Aplique esos controles en la puerta de enlace de envío para que un modelo no pueda omitirlos con una herramienta HTTP genérica o una API de correo alternativa. Los límites de velocidad y un interruptor de apagado reducen el impacto, pero no sustituyen la autorización del destinatario y del contenido.
Pruebe un flujo de trabajo de envío limitado
Para el plan escrito SEND-01, suponga que el inquilino A/buzón de servicio, desde status@example.invalid , destinatario ops@example.invalid , asunto Estado de rutina, cuerpo Revisión completa; no se proponen cambios, no se adjuntan archivos adjuntos, el propósito es estado interno. Todas las identidades son ilustrativas y no se proporciona ninguna credencial ni aprobación real.
Según una regla de puerta de enlace propuesta, el objeto exacto con una aprobación protegida válida y un ID de operación no utilizado podría ser elegible para su envío. Un nuevo destinatario externo, un archivo adjunto, un propósito contractual, un cuerpo modificado, un origen cambiado, una cuenta diferente o una identificación de operación reutilizada deben detenerlo. Una ruta HTTP genérica no debe pasar por alto el mismo límite de autorización. Estas son decisiones esperadas, no pruebas ejecutadas.
En producción, distinga una solicitud aceptada por el proveedor de la entrega al destinatario. Si se pierde la respuesta de envío, inspeccione los identificadores de mensajes u operaciones disponibles antes de volver a intentarlo para evitar correo duplicado. El apoyo de idempotencia del proveedor varía; un guardia de repetición local por sí solo no puede probar la entrega exactamente una vez a través de una falla de red.
Mantenga una cadena de acción inspeccionable
La secuencia propuesta es la recuperación de informes aprobados, la creación de borradores, la decisión humana autorizada, la validación de la puerta de enlace de ejecución, el envío del proveedor y la observación de la entrega por separado. Registre a qué componente pertenece cada paso. El ID de solicitud del proveedor, el recibo de aprobación, la marca de tiempo de envío y el resultado de la entrega no están disponibles en este ejemplo. No se ejecutó ninguna prueba de adaptador de proveedor, guardia local o repetición y no se envió ningún mensaje.
Autenticar y auditar la ruta de correo real
Configure la autenticación documentada del servicio de envío para el dominio De origen elegido y verifique los mensajes de prueba autorizados en los receptores. RFC 9989 explica alineación, mientras DKIM separa la responsabilidad del firmante del supuesto autor. Ninguno de los protocolos certifica la veracidad de una declaración generada por IA.
Conservar la autorización del usuario o servicio, la versión del contenido aprobada, la resolución del destinatario, el resultado del envío y la evidencia de entrega posterior bajo los controles de retención adecuados. Proporcione una forma de suspender el envío inmediatamente sin deshabilitar el diagnóstico de solo lectura. Si se envía un mensaje no autorizado, trátelo como un incidente de comunicación; arreglar DNS no retraerá su contenido.