Estamos en la era de los agentes; nadie puede dudarlo. Para que los agentes sean más potentes y útiles, les estamos dando acceso a nuestras herramientas online: Google Drive, correo electrónico, calendario, navegador, Slack, GitHub… La lista es interminable.

Una de las herramientas a las que me he mostrado reacio a dar acceso a los agentes es el correo electrónico.

¿Por qué dar acceso a tu bandeja de entrada a un agente es una idea muy mala

El correo electrónico no es solo una herramienta de comunicación para enviar texto y archivos; también es la forma en que la mayoría de los servicios identifican a sus usuarios. Cuando te registras en un servicio online, necesitas una cuenta de correo (o, cada vez más y afortunadamente, puedes usar OAuth a través de otro servicio).

Solo piensa en lo que una persona (o agente) malintencionado puede hacer si tiene acceso a tu bandeja de entrada:

• Obtener códigos de recuperación o de inicio de sesión.
• Usar «recuperar mi contraseña» para obtener un enlace para crear una nueva contraseña para cualquier cuenta asociada a tu dirección de correo electrónico.
• Suplantar tu identidad creando cuentas en servicios.
• Suplantar tu identidad ante amigos, compañeros de equipo o clientes.
• Acceder a información confidencial o personal.

El riesgo es muy alto.

Dar credenciales a un agente para que acceda a tu bandeja de entrada abre un nuevo vector de ataque y crea nuevos riesgos.

• El agente podría filtrar las credenciales (este riesgo puede mitigarse con herramientas como Himalaya CLI, que evitan que el agente acceda a las credenciales directamente, pero el agente seguiría teniendo acceso al buzón completo).
• Una inyección de prompt puede engañar al agente para:
  • revelar información privada (información confidencial, códigos de recuperación de cuenta, etc.).
  • enviar un correo electrónico en tu nombre.
• El agente podría cometer un error y enviar un correo electrónico al destinatario equivocado.

Buscando una solución

Entiendo el valor de dar acceso a un agente a algunos correos electrónicos, pero no a todos, así que empecé a pensar en una posible solución:

Cuenta de correo dedicada

Una forma posible de mitigar los riesgos es crear una cuenta de correo solo para el bot y reenviar los correos que consideres seguros desde tu cuenta personal a esa cuenta.

Esto puede funcionar para casos específicos y sencillos, pero necesitas reconfigurar los reenvíos cada vez que algo cambia. El filtrado de correo también depende de tu proveedor, y no todos los proveedores ofrecen las mismas capacidades de filtrado.

Si tienes varios agentes y quieres darles acceso a diferentes correos, necesitas crear varias cuentas (una por agente), lo que añade complejidad.

Es difícil (y a menudo imposible) limitar los destinatarios o archivos adjuntos permitidos.

SirenoRelay: Da acceso a la bandeja de entrada a través de un relay mcp

Por eso nació SirenoRelay.

SirenoRelay es una herramienta para Linux y macOS que proporciona un servidor MCP. Puedes ejecutarlo a través de la CLI, como un servicio o en un contenedor (recomendado). Actúa como un relay entre tu agente y tu cuenta de correo, controlando el acceso a tu bandeja de entrada y al correo saliente.

Utiliza Himalaya CLI internamente como su proveedor de correo electrónico (tengo previsto añadir más proveedores en el futuro). Puedes definir perfiles de acceso, que especifican lo que cada usuario o agente puede y no puede ver. Los usuarios de SirenoRelay son independientes de los usuarios de tu cuenta de correo: asignas un perfil a cada usuario de SirenoRelay y esas reglas se aplican a ese usuario.

Veamos un ejemplo

Imagina que quieres dar acceso a tu agente a los recibos del supermercado. Puedes configurar SirenoRelay para permitir correos de tickets@supermarket.com y, por organización, limitar el acceso a los mensajes en la carpeta Invoices.

profiles:
    ticketprofile:
        folders:
            allow:
                - ro:Invoices
        inbound:
            addresses:
                allow:
                    - 'tickets@supermarket.com'
            attachments:
                allow: ["application/pdf"]
        outbound:
users:
    Agent:
        provider: default
        profile: ticketprofile
        token_hash: 6bbad1ac753370e6e4da2345aa5716d371adcd9af81b2b56d12f6f0eda5f38bb

Con esta configuración, el agente debe usar un token. Tú estableces la contraseña o el token del usuario, y la herramienta almacena su token_hash para mayor seguridad. Cada token está asociado a un usuario y a un perfil.

Es importante tener en cuenta que el relay bloquea cualquier cosa que no esté explícitamente permitida. Por ejemplo, como la sección outbound está vacía, el agente no puede enviar correos electrónicos a nadie.

La configuración de la carpeta otorga acceso de solo lectura (ro) a la carpeta Invoices. El agente ni siquiera sabe que existen otras carpetas; solo puede ver aquellas a las que tiene permiso para acceder.

Incluso si esa carpeta contiene correos de otros remitentes, el agente solo puede ver (listar o leer) los mensajes de tickets@supermarket.com, nada más.

En cuanto a los archivos adjuntos, el agente solo recibe los que están permitidos. Hay dos modos de ocultación: en uno, el agente sabe que un correo tiene un adjunto pero no puede acceder a él; en el otro, no se le informa en absoluto de la existencia del adjunto.

También puedes establecer reglas para otras cosas, como el asunto y el contenido del cuerpo. Por ejemplo, un correo no se listará si su cuerpo contiene ciertas palabras.

Puedes eliminar enlaces de los correos electrónicos y usar un escáner externo, como gitleaks, para comprobar si un correo contiene un secreto.

La herramienta incluye un comprobador de ejecución en seco (dry-run) para ver si un hipotético correo con ciertas características sería permitido o denegado: sirenorelay policy-check --user finance-agent --folder INBOX/Invoices.

Cómo instalarlo

Puedes usar Homebrew o pedirle a tu agente que lo instale automáticamente:

También proporciona una skill para instalar y configurar la herramienta, lo que facilita la configuración.

Complemento (add-on) para Home Assistant

Mi principal caso de uso es dar acceso a mi correo electrónico a los agentes Hermes que se ejecutan en mi HAOS (a través de un add-on que creé). Esto me permite preguntar cosas como cuándo compré arena para gatos por última vez: el agente puede leer mis recibos del supermercado y encontrar la respuesta.

Ejecutar este servicio en HAOS parecía un paso lógico, así que empaqueté la herramienta como un add-on de Home Assistant y proporcioné una interfaz de usuario para simplificar la configuración:

Próximos pasos

Tengo previsto permitir que un usuario utilice varios perfiles (aplicándose la regla más restrictiva en caso de conflicto). También planeo seguir mejorando la documentación y añadir soporte para más proveedores en Himalaya, incluidos aquellos que utilizan OAuth.