La IA para el soporte de recuperación de cuentas es segura cuando cada acción que puede realizar sigue ayudando al verdadero propietario, aunque la persona que pide sea un impostor. Enviar tu correo habitual de restablecimiento a la dirección que ya está en la cuenta pasa esa prueba: un atacante puede pedirlo todo el día y el enlace sigue llegando a la bandeja del propietario. Cambiar el correo, restablecer el 2FA o "simplemente desactivarlo" no la pasa. Así que deja que la IA resuelva contraseñas olvidadas y bloqueos, clasifique y redacte los casos de 2FA y cambio de correo, y envíe directamente a una persona todo lo que huela a toma de cuenta.
La división importa porque los servicios de soporte son una vía de entrada conocida. El aviso sobre Scattered Spider de la agencia estadounidense de ciberseguridad CISA describe a atacantes que llaman a los servicios de ayuda para restablecer contraseñas y trasladar el MFA a sus propios dispositivos. Una IA a la que se pueda convencer de lo mismo es una versión más rápida de ese agujero.
eesel funciona así dentro de Zendesk, Freshdesk, HubSpot y otros helpdesks: solo llama al punto de restablecimiento que permites, retiene las acciones arriesgadas para su aprobación y nunca ve tus claves de API. XAP, que gestiona portales de estudiantes para estados y universidades de EE. UU., deja que su agente de eesel se encargue de los restablecimientos de contraseña del portal en Freshdesk mientras las eliminaciones de cuentas siguen con el equipo, y una persona envía cada respuesta.
¿Por qué son tan difíciles de automatizar los tickets de recuperación de cuentas?
Porque son el único tipo de ticket en el que ser útil y ser seguro tiran en direcciones opuestas. El cliente está bloqueado, a menudo estresado, y quiere su cuenta de vuelta ya. El atacante escribe exactamente el mismo mensaje.
También son mucho volumen. Bron Gondwana, del proveedor de correo Fastmail, puso una cifra en Hacker News:
"In 2016 before we had automated account recovery, lost password was in the top 3 categories of ticket every single week! Every member of the support team dealt with multiple account-loss tickets per day, both forgotten password or stolen account."
Esa pareja, contraseña olvidada y cuenta robada en la misma cola, es todo el problema. Trabajo la cola de soporte de eesel a diario, y "no puedo iniciar sesión" es uno de esos mensajes en los que la respuesta que parece más amable es a veces la que no debes enviar. Una persona siente la duda. Un chatbot hecho para resolver tickets cerrará encantado el asunto para quien esté al otro lado.
El otro lado es lo cansados que están los clientes de los malos flujos de recuperación. Un usuario de Hacker News resumió la frustración con las copias de seguridad de MFA y los servicios de soporte de una sola vez:
"Plus a ton of vendors allow customer support to trivially turn off MFA via social-engineering, so what is the point?"
Así que la tarea no es "automatizar la recuperación de cuentas". Es automatizar las partes donde una suposición errónea no cuesta nada y frenar las partes donde una suposición errónea le entrega la cuenta a alguien. La buena noticia es que la mayor parte del volumen está en el primer grupo. Si solo gestionas restablecimientos de contraseña, mi artículo sobre IA para solicitudes de restablecimiento de contraseña cubre ese tipo de ticket con más detalle. Esta guía cubre toda la cola de recuperación.
¿Cuál es la prueba que debe pasar una acción de recuperación de la IA?
Pregunta: si la persona de este chat fuera un atacante, ¿esta acción seguiría ayudando solo al verdadero propietario? Si es así, la IA puede ejecutarla. Si no, decide una persona.
La prueba parece simple y ordena casi todas las acciones de recuperación con claridad:
| Acción que pide el cliente | ¿Sigue ayudando solo al verdadero propietario? | Quién la ejecuta |
|---|---|---|
| Enviar el enlace de restablecimiento estándar | Sí, va a la dirección registrada | La IA, por sí sola |
| Explicar por qué la cuenta está bloqueada y cuándo se desbloquea | Sí, es información, no acceso | La IA, por sí sola |
| Guiar en el uso de un código de recuperación guardado | Sí, solo el propietario tiene el código | La IA, por sí sola |
| Reenviar un código a una dirección de recuperación ya registrada | Sí | La IA, por sí sola |
| Cambiar el correo o el número de teléfono de la cuenta | No, la nueva dirección podría ser de cualquiera | Una persona, tras verificaciones |
| Restablecer o quitar el 2FA | No, elimina el segundo cerrojo | Una persona, tras verificaciones |
| Decirle al cliente si un correo tiene cuenta | No, revela quiénes son tus clientes | Nadie, nunca |
| Pegar un enlace de restablecimiento o un código en el chat | No, el chat es el canal no confiable | Nadie, nunca |
Las dos últimas filas vienen directamente de la OWASP Forgot Password Cheat Sheet, la referencia de la comunidad de seguridad para los flujos de restablecimiento. Dice que se debe devolver un mensaje coherente tanto para cuentas existentes como inexistentes, así que una respuesta como "si ese correo tiene una cuenta, un enlace de restablecimiento va en camino" es la correcta incluso cuando la IA puede ver que la cuenta existe.
La tabla también te dice qué conectar. Un agente de IA que solo tiene un botón de "enviar correo de restablecimiento" no puede ser convencido de ejecutar las filas peligrosas, porque no tiene botón para ellas. Es una garantía mucho más fuerte que una instrucción que le diga que tenga cuidado. Las instrucciones se pueden discutir. Un permiso ausente no. Vuelvo sobre esto en la sección de configuración.
¿Qué solicitudes de recuperación de cuentas puede gestionar la IA?
Ordénalas según lo que sale mal si se engaña a la IA. Empezaría con tres carriles en cualquier equipo:
Carril 1: la IA lo resuelve. Contraseñas olvidadas, bloqueos tras intentos fallidos y clientes que aún tienen un código de recuperación o un segundo dispositivo. La solución viaja por algo que el propietario ya controla. La IA activa el restablecimiento, explica el bloqueo o guía en el uso del código, y luego cierra el ticket. Aquí está la mayor parte de tu volumen y es donde una IA recupera más horas. También es el carril para operar 24/7, porque nadie bloqueado un sábado quiere esperar al lunes.
Carril 2: la IA prepara, una persona decide. Un teléfono 2FA perdido sin códigos de recuperación, sin acceso al correo registrado o un nuevo número de teléfono. Ya no queda ningún canal que demuestre la propiedad, así que alguien tiene que comprobarlo. La IA sigue haciendo la mayor parte del trabajo: lee la cuenta, enumera qué opciones de recuperación existen, abre el caso, redacta la solicitud de identificación y escribe una nota interna para que el agente que lo recoja empiece con los hechos. Tiene la misma forma que un traspaso a una persona en los reembolsos, solo que con una regla más estricta sobre quién pulsa el botón.
Carril 3: solo el equipo de seguridad. "Alguien cambió mi contraseña", una solicitud para quitar el 2FA o cualquier petición sobre un inicio de sesión de administrador o propietario de la cuenta. El trabajo de la IA aquí es rapidez y silencio: etiquetarlo como urgente, enrutarlo, decirle al cliente qué pasará a continuación y no enviar nada a ninguna dirección que haya cambiado recientemente.
Un caso de cliente muestra por qué el carril 1 necesita contexto y no solo una palabra clave. MentorShow, una empresa francesa de formación en línea, hace que eesel lea cada ticket de HubSpot junto con el registro del miembro, incluidos el estado de la suscripción y la fecha de renovación. Sus instrucciones llevan una línea que copiaría en cualquier configuración: un problema de inicio de sesión de alguien sin suscripción activa no es un problema de inicio de sesión. Ese ticket necesita una respuesta de facturación, y un enlace de restablecimiento solo haría dar vueltas al miembro.
¿Qué dicen los estándares de seguridad sobre la recuperación de cuentas?
Las dos referencias a las que recurren la mayoría de los equipos de seguridad para esta cuestión son la NIST SP 800-63B-4, las directrices de identidad digital del gobierno de EE. UU., y OWASP. Se escribieron para ingenieros que construyen sistemas de inicio de sesión, pero la mayoría de las reglas se traducen directamente a lo que un agente de soporte, humano o IA, debe y no debe hacer.
| Qué dice el estándar | Qué significa en un ticket de soporte |
|---|---|
| NIST enumera cuatro métodos de recuperación: códigos de recuperación guardados, códigos emitidos enviados a una dirección de recuperación, contactos de recuperación y repetición de la prueba de identidad | Tu agente debe comprobar cuáles tiene la cuenta antes de prometer nada |
| Recuperar una cuenta con 2FA requiere dos códigos de recuperación de métodos distintos, un código más otro factor que funcione, o prueba de identidad repetida (NIST) | "Dime tu fecha de nacimiento" no es una de las opciones. Un caso de teléfono perdido sin nada registrado pasa a una persona |
Un código de recuperación emitido dura como máximo 10 minutos por SMS o voz y 24 horas por correo (NIST) | Dile a los clientes cuánto tiempo es válido el enlace y que pidan uno nuevo en lugar de responder a un correo antiguo |
| Una nueva dirección de recuperación debe confirmarse con un código antes de usarse (NIST) | Nunca trates como suyo un correo que el cliente escribe en el chat |
| Cada recuperación de cuenta envía una notificación a las direcciones registradas, con una forma de decir "no fui yo" (NIST) | La dirección antigua se entera de cada recuperación, así que el verdadero propietario puede detener una falsa |
Los intentos fallidos en un autenticador se limitan a 100 antes de desactivarlo (NIST) | Los bloqueos son a propósito. Explícalos; no busques una forma de saltarlos |
| Devolver el mismo mensaje exista o no la cuenta (OWASP) | La IA nunca confirma "sí, ese correo es de un cliente" |
| No iniciar sesión automáticamente al usuario tras un restablecimiento y ofrecer cerrar otras sesiones (OWASP) | Tras una toma de cuenta, una nueva contraseña por sí sola puede no dejar fuera al atacante |
| Las preguntas de seguridad no deben ser la única comprobación de restablecimiento (OWASP) | Respuestas como un cumpleaños o el nombre de una mascota suelen encontrarse en línea |
Esa regla de notificación es la que más olvidan los equipos de soporte, y es la protección más barata que tienes. NIST dice que las notificaciones de recuperación van a todas las direcciones de notificación de la cuenta, y que el aviso debe incluir instrucciones claras y datos de contacto por si el destinatario no lo pidió. Si tu IA activa una recuperación, asegúrate de que tu sistema envíe ese aviso también a la dirección antigua. Si alguien está secuestrando la cuenta, el propietario se entera en minutos, no cuando intente iniciar sesión.
OWASP también señala algo que cambia cómo tratas los tickets de "creo que me han hackeado". Dice que un restablecimiento de contraseña por sí solo puede no devolver el control de una cuenta comprometida, porque el atacante puede seguir teniendo una sesión activa o haber cambiado los datos de recuperación. Por eso los casos de toma de cuenta están en el carril 3, donde alguien puede cerrar todas las sesiones y comprobar qué cambió, y no en el carril 1 con un alegre enlace de restablecimiento.
¿Por qué la IA no debería cambiar correos ni restablecer el 2FA por su cuenta?
Porque esas son exactamente las solicitudes que los atacantes llevan a los servicios de soporte, y un modelo que lee un solo chat no puede distinguirlas de las de un cliente real.
El aviso de la CISA sobre Scattered Spider, un grupo detrás de varias grandes brechas, enumera los movimientos. El grupo se hacía pasar por empleados "to convince IT and/or helpdesk staff to provide sensitive information, reset the employee's password, and transfer the employee's MFA to a device they control". El aviso añade que estas llamadas suelen llegar en varias conversaciones: primero averiguan qué pregunta el servicio de ayuda y luego vuelven con las respuestas. Sus deberes los sacan de redes sociales, filtraciones de datos y fuentes abiertas, que es justo por lo que "confirma tu dirección y fecha de nacimiento" es una comprobación débil.
Okta vio el mismo patrón. En su informe de seguridad de 2023, Okta dijo que varios clientes de EE. UU. informaron de llamadas que intentaban convencer al personal del servicio de asistencia de restablecer todos los factores de MFA de sus cuentas de administrador más poderosas. Los consejos de Okta incluyen comprobaciones de identidad más fuertes en el servicio de ayuda, limitar los roles del servicio de ayuda para que no puedan tocar cuentas de administrador y alertar siempre que se restablezcan todos los factores de MFA de un usuario.
Ahora imagina el mismo ataque contra un agente de IA. No se cansa, responde al instante y un atacante puede probar cincuenta formulaciones en una hora. Si el agente tiene activada una acción de "quitar MFA", una de esas formulaciones podría funcionar. Si no tiene esa acción en absoluto, ninguna lo hará. Esa es la regla que escribiría en la configuración de cualquier agente: la IA puede iniciar una recuperación, pero no puede terminar una arriesgada.
Los cambios de correo merecen su propio aviso. Un comentarista de Hacker News que ha gestionado un sitio de mucho tráfico enumeró lo que te ahorras al no permitir cambios de correo:
"Email change is one of the most abused recovery vectors in account takeover (ATO)."
Probablemente no puedas prohibir los cambios de correo, pero sí puedes asegurarte de que una IA nunca realice uno a partir de una solicitud de chat. Si tus preocupaciones por la alucinación de la IA tienen que ver con respuestas erróneas, esta es la mayor preocupación: una acción que suena correcta realizada para la persona equivocada.
¿Cómo debería hablar la IA con tu sistema de inicio de sesión?
A través de un único punto de conexión estrecho que sea seguro por diseño, no mediante acceso de administrador a tu base de datos de usuarios.
La mayoría de los proveedores de identidad ya tienen la llamada que necesitas, y es la aburrida: enviar el correo estándar de restablecimiento a la dirección registrada. Revisé la documentación de cuatro habituales:
| Sistema de inicio de sesión | La llamada segura para darle a una IA | La llamada arriesgada que hay que mantener lejos |
|---|---|---|
| Amazon Cognito | AdminResetUserPassword, que envía un código de restablecimiento igual que el "olvidé mi contraseña" del propio usuario | AdminSetUserPassword, que establece una contraseña directamente |
| Firebase Authentication | Generar un enlace de restablecimiento de contraseña y enviarlo por correo a la dirección existente del usuario | Establecer el correo o la contraseña desde el SDK de administrador a petición |
| Auth0 | Activar el correo estándar de cambio de contraseña | Eliminar la inscripción MFA de un usuario mediante la Management API, que Auth0 describe como lo mismo que quitar su registro de MFA |
| Okta | Recuperación de autoservicio iniciada por el usuario | Restablecer todos los factores, la petición exacta del informe del incidente de Okta de 2023 |
Un detalle que conviene saber sobre Cognito: su documentación dice que los mensajes de recuperación solo van a usuarios con correo o teléfono verificado. Si ninguno está confirmado, debe intervenir un administrador. Es un caso natural del carril 2, y tu IA debería decirlo claramente en lugar de reintentarlo.
Si tu propia aplicación tiene un botón de "olvidé mi contraseña", la opción más limpia suele ser exponer lo mismo como un pequeño punto de conexión interno: recibe un correo, envía el correo normal de restablecimiento si la cuenta existe y siempre devuelve la misma respuesta. Tu IA llama a ese. No puede hacer nada que tu página pública de inicio de sesión no permita ya a cualquiera.
Cómo configurar la IA para la recuperación de cuentas en tu helpdesk
Este es el orden en que lo haría. Los pasos 1 a 3 merecen la pena aunque nunca dejes que la IA realice una acción.
Paso 1: cuenta lo que realmente recibes
Antes de escribir una regla, etiqueta un mes de tickets por tipo de recuperación: contraseña olvidada, bloqueado, 2FA perdido, correo perdido, teléfono nuevo, sospecha de toma de cuenta y "en realidad no es un problema de inicio de sesión". El etiquetado de tickets con IA puede hacerlo hacia atrás sobre tickets pasados. La mezcla lo decide todo lo demás. Una cola con un 90 % de contraseñas olvidadas necesita un punto de conexión y una buena respuesta. Una cola llena de 2FA perdido necesita primero un mejor proceso de verificación de identidad.
Paso 2: escribe los carriles en las instrucciones
Pon los tres carriles en las instrucciones del agente con palabras sencillas, con ejemplos de lo que los clientes escriben de verdad: "no puedo entrar", "teléfono nuevo, autenticador perdido", "ya no uso ese correo", "alguien cambió mi contraseña". Añade también las reglas duras: nunca confirmar si una cuenta existe, nunca pegar un enlace o código en el chat, nunca cambiar datos de contacto a petición. En eesel, las instrucciones son texto sin formato que editas, y el agente puede endurecerlas cuando lo corriges en el chat, como explican los documentos de instrucciones.
Paso 3: dale el contexto de la cuenta
Conecta lo que le diga a la IA quién es esta persona: tu sistema de suscripciones o facturación, tu CRM, el registro de cliente de tu helpdesk. Esta es la lección de MentorShow. La mitad de los tickets de "no puedo iniciar sesión" son planes caducados, un producto equivocado o un portal que ni siquiera gestionas. XAP encontró lo mismo: algunos estudiantes que no pueden iniciar sesión están en el portal propio de una universidad, que XAP no gestiona, así que la respuesta correcta es una derivación, no un restablecimiento.
Paso 4: conecta un punto de conexión seguro
Dale al agente la única llamada de restablecimiento de la sección anterior, y nada más que toque el inicio de sesión. En eesel esto es Network Access: permites un dominio, añades la cabecera de autenticación en los ajustes y el agente puede llamarlo. Las solicitudes a cualquier otro dominio se rechazan.
Lo que importa para la recuperación es la línea de arriba de esa pantalla: las credenciales se almacenan como cabeceras y no se muestran a la IA. La clave que puede activar restablecimientos nunca está en un prompt, así que no se le puede sonsacar al agente. Tus desarrolladores también pueden configurarlo desde una terminal. La CLI de eesel ejecuta el mismo agente y espacio de trabajo que el panel, así que un ingeniero, un script o un agente de código como Claude Code o Cursor puede conectar el punto de conexión, editar las instrucciones de recuperación y probar el agente sin abrir el navegador.
Paso 5: haz que toda acción del helpdesk que toque la identidad requiera aprobación
Cada acción que puede realizar un agente de eesel se configura por agente para ejecutarse sola, preguntar primero o quedar desactivada. Los documentos de acciones y aprobaciones recomiendan empezar supervisado, con las respuestas y todo lo irreversible bajo aprobación.
Para la recuperación, dejaría el etiquetado y las notas internas funcionando solos desde el primer día, y pondría las respuestas públicas bajo aprobación durante la primera o segunda semana. También puedes retener un tipo de caso aunque las respuestas estén activadas: una instrucción como "pregunta antes de responder a cualquier cosa sobre 2FA o cambio de correo" hace que el agente se detenga solo en esos casos.
Paso 6: enruta los carriles 2 y 3 a personas concretas
El carril 2 va a quien pueda ejecutar tu verificación de identidad, normalmente un agente sénior o el nivel 2. El carril 3 va a seguridad, por nombre, con una etiqueta de urgente y un SLA corto. Una IA puede enrutar por etiqueta al instante; no puede arreglar una regla de enrutamiento que apunta a una bandeja compartida que nadie vigila los fines de semana. Si tu equipo de nivel 2 es pequeño, haz que la IA escriba la nota interna para que empiece con los datos de la cuenta.
Paso 7: pruébalo con tus tickets de inicio de sesión pasados
Ejecuta el agente sobre los tickets de recuperación que ya gestionaste antes de que toque uno en vivo. ¿Envió enlaces de restablecimiento solo en el carril 1? ¿Confirmó alguna vez que un correo tenía cuenta? ¿Detectó la toma de cuenta escondida dentro de una queja de facturación furiosa? Una simulación sobre tickets pasados lo responde en una tarde, y es el paso que nunca me saltaría con este tipo de ticket.
¿En qué carril va este ticket?
Elige un tipo de solicitud para ver quién la gestiona, qué hace la IA y la regla que hay detrás.
¿Cómo mides si está funcionando?
Sigue la rapidez y la seguridad a la vez. Una configuración de recuperación rápida pero que de vez en cuando entrega una cuenta es peor que no tener IA.
- Porcentaje de tickets de recuperación cerrados por la IA. Debería ser aproximadamente tu porcentaje del carril 1 del paso 1. Si es mucho mayor, la IA está cerrando tickets que no debería.
- Tiempo hasta la primera respuesta en el carril 1. Los clientes bloqueados sienten cada minuto. Es la cifra que más debería bajar.
- Tiempo de respuesta del carril 3. Una toma de cuenta parada seis horas en una cola es el fallo que acaba en un titular. Vigílalo en tus informes de SLA.
- Respuestas de "no fui yo" a las notificaciones de recuperación. Cada una es una recuperación que alguien no pidió. Lee todas y cada una.
- Contactos repetidos en 7 días. Si el mismo cliente vuelve, el enlace de restablecimiento no le llegó o la respuesta no atendió el problema real.
La guía de informes de soporte con IA muestra cómo construirlos a partir de tickets etiquetados.
Errores comunes con la IA y la recuperación de cuentas
Estos son los que vigilaría durante el primer mes:
- Dejar que la IA confirme que la cuenta existe. "Encontré tu cuenta, te envío un enlace ahora" parece útil y le dice a un atacante qué correos son clientes. Usa la misma respuesta en ambos casos.
- Tratar los datos del chat como prueba. Nombre, dirección, últimos cuatro dígitos, fecha de nacimiento: todo está en la filtración de datos de alguien. La CISA señala que los atacantes reúnen justo esto antes de llamar.
- Pegar un enlace o código en la conversación. El chat es el único canal en el que no puedes confiar en un caso de recuperación. Los códigos van a la dirección registrada.
- Dar a la IA claves de API de administrador "por si acaso más adelante". Si la clave puede quitar el MFA, da por hecho que algún día alguien convencerá al agente de intentarlo. Dale la única llamada que necesita.
- Saltarse la notificación. Toda recuperación debería avisar a la dirección antigua. Es la alarma de toma de cuenta más barata que configurarás jamás.
- Olvidar el otro inicio de sesión. La cola de XAP lo mostró: a veces el portal al que el estudiante no puede acceder no es tuyo. Una derivación vale más que un enlace de restablecimiento.
Si quieres ver el panorama general de cómo un despliegue así pasa de supervisado a autónomo, el artículo sobre el calendario de implementación explica el mando.
Prueba eesel para tickets de recuperación de cuentas
eesel se incorpora a tu helpdesk como un compañero de IA para el soporte. En los tickets de inicio de sesión, lee cada uno con el contexto de cuenta del cliente, activa solo la llamada de restablecimiento que permites, responde igual exista o no la cuenta y retiene los cambios de 2FA, los cambios de correo y todo lo que parezca una toma de cuenta para tu equipo. Funciona en Zendesk, HubSpot y los demás helpdesks principales, y en Freshdesk mediante la integración con Freshdesk.
Las aprobaciones llegan donde tu equipo ya trabaja: el panel, un hilo de Slack o un enlace en la nota del helpdesk, y cada aprobación registra quién decidió y cuándo. Tus claves de API se quedan en los ajustes, nunca a la vista de la IA, y eesel nunca usa tus datos para entrenar los modelos subyacentes, según su Trust Center. Una carencia honesta: la auditoría SOC 2 Type II de eesel sigue en curso, así que si tu equipo de seguridad necesita el informe en mano hoy, pregunta primero por el estado actual; mi lista de comprobación de seguridad de proveedores explica qué pedir en su lugar.
XAP es un buen modelo para empezar poco a poco. Un filtro delante de su agente de eesel deja pasar solo los casos de derivación y los restablecimientos de contraseña del portal, nada llega a un estudiante sin que una persona lo envíe, y las eliminaciones de cuentas siguen con el equipo. Empieza ahí, mide durante un mes y luego abre el carril 1. Puedes probar eesel gratis durante 7 días con 100 créditos.