Agentes LLM: simula login social sin falsos positivos

Cuando un agente LLM prueba un signup con login social, “el botón respondió” no significa que el flujo sea correcto. Puede haber usado una identidad vieja, seguir una sesión de navegador equivocada o confirmar una cuenta distinta de la que el test esperaba. El resultado parece verde, pero la evidencia es debil.

En workflows de desarrollo con agentes, trato la identidad de prueba como una dependencia explícita, no como un detalle del navegador. El agente puede elegir el siguiente paso y explicar un fallo, pero un contrato pequeño debe demostrar qué identidad se usó, qué estado cambió y qué señales fueron observadas.

El problema: un agente puede completar el flujo equivocado

Un login social tiene más estado que un formulario de email y contraseña. Hay una sesión del proveedor, cookies del navegador, consentimiento, redirecciones y, a veces, un email de confirmación. Si todo eso vive en el mismo perfil, un agente puede “pasar” porque heredó una sesión que ya estaba autenticada.

Los falsos positivos más comunes son estos:

• El navegador conserva cookies de una cuenta anterior.
• El proveedor redirige al entorno equivocado.
• El email asociado a la identidad no coincide con el usuario creado.
• El agente lee un mensaje antiguo y lo toma por la confirmación actual.
• Un reintento crea otra cuenta, aunque el resumen solo diga ok.

La solución no es pedirle al modelo que sea mas cuidadoso. Es dividir el flujo en hechos verificables. Como en otros sistemas con correo, conviene pensar los correos de prueba como una señal operativa, con una edad, un identificador y un contexto de ejecución.

Qué significa simular un login social

Simular no quiere decir falsificar una cuenta real ni probar contra producción. Quiere decir construir una identidad sintética controlada en staging, con permisos mínimos y un ciclo de vida corto. El agente debe recibir una referencia como identity-qa-17, no una contraseña pegada en el prompt.

El mapa mental es sencillo:

identidad sintética -> sesión aislada -> login social -> signup
          |                |                |             |
       contrato       cookies nuevas    redirect host   evento de dominio

Cada flecha tiene una comprobación. Si la sesión no es nueva, el test se detiene. Si el redirect_uri no apunta a staging, se marca como fallo de seguridad. Si el evento de dominio no contiene la misma referencia de identidad, no se afirma que el signup terminó.

El contrato de identidad sintética

Un fixture útil puede describirse con pocos campos:

{
  "identity_ref": "identity-qa-17",
  "provider_subject": "provider-subject-91",
  "email_ref": "inbox-qa-17",
  "environment": "staging",
  "session_started_at": "2026-09-30T06:00:00Z",
  "expires_at": "2026-09-30T06:15:00Z"
}

provider_subject es un identificador de prueba, no un dato personal. email_ref apunta al fixture de correo sin escribir el contenido completo en cada log. El contrato tambien necesita expiración: una identidad de staging que sobrevive semanas termina pareciéndose demasiado a una cuenta compartida.

Para flujos que envían un código o un enlace, el adaptador de correo debería devolver solo candidatos recientes, su message_id y metadatos sanitizados. La comparación del asunto, del host y de la antigüedad debe ser código determinista. Un LLM puede interpretar “el proveedor rechazó el consentimiento”, pero no debe inventar que una identidad fue verificada.

Cuando el signup necesita reenvíos, es útil diseñar reenvíos seguros en un signup con el mismo run_id. Así un reintento queda relacionado con el intento original y no se confunde con un nuevo usuario.

Implementación por checkpoints

Un workflow manejado por un agente puede tener cinco checkpoints:

1. Preparar: crear run_id, fixture de identidad, inbox lógico y expectativas.
2. Aislar: abrir un contexto de navegador limpio y comprobar que no hay cookies previas.
3. Actuar: ejecutar el login social y capturar el host de cada redirección.
4. Observar: consultar los eventos de autenticación y el mensaje de confirmación esperado.
5. Verificar: comparar referencias, timestamps y estado final antes de emitir el recibo.

El recibo debería decir verified, timeout, redirect_mismatch o ambiguous. “Ambiguous” es un resultado valido: obliga a investigar en vez de convertir señales incompletas en éxito. En CI, guardaría el recibo y un snapshot pequeño; guardar todo el cuerpo del email hace el debugging mas costoso y aumenta la retención de datos.

Tradeoffs y límites

La identidad sintética reduce contaminación entre tests, pero añade una fábrica de fixtures y una política de expiración. Un proveedor social real puede cambiar su pantalla o imponer límites, por lo que no conviene depender de una prueba end-to-end para cada commit.

Mi separación práctica es usar tres capas: pruebas de contrato para el adaptador, pruebas de integración con un proveedor controlado y pocas pruebas end-to-end nocturnas. El agente participa en la preparación y en el diagnóstico; las aserciones críticas permanecen en código. Es menos flexible, pero mucho mas fácil de auditar.

Checklist para el siguiente workflow

• ¿La identidad tiene identity_ref y fecha de expiración?
• ¿El navegador empieza sin cookies ni sesiones heredadas?
• ¿Cada redirección comprueba el host esperado?
• ¿El email se vincula por run_id, message_id y antigüedad?
• ¿Un reintento conserva la relación con el intento original?
• ¿Los logs evitan secretos, cuerpos completos y datos personales?
• ¿El resultado puede ser ambiguous sin forzar un falso éxito?

Un agente LLM es muy útil para coordinar pasos y resumir evidencia. El límite sano es que no sea la fuente de verdad sobre la identidad, el correo o el estado de autenticación. Si el sistema deja ese contrato claro, hasta una nota con temp mailid o dummy e mail se puede rastrear sin convertirla en una cuenta permanente. Y el resultado deja de ser “parece que funcionó” para convertirse en una señal que otro proceso puede revisar.