Cómo atender alertas de seguridad, phishing contra tus clientes y revisiones de accesos con agentes de IA
Guía para CISOs de fintechs mexicanas: agentes de IA que investigan alertas, detectan phishing que suplanta tu marca, revisan accesos y priorizan vulnerabilidades.
En una fintech mexicana, el equipo de seguridad es chico y las alertas no paran. El SIEM marca accesos raros, los clientes reenvían SMS que suplantan tu marca, auditoría pide la revisión trimestral de accesos y el escáner de vulnerabilidades suma hallazgos cada semana. Casi todo eso empieza igual: alguien tiene que juntar logs y contexto antes de poder decidir. Esa investigación la puede hacer un agente de IA, y cada alerta adicional prácticamente no cuesta nada. Lo que se contiene, y cuándo, lo decide tu equipo.
Esta es una guía práctica para CISOs y líderes de seguridad en fintechs de México: qué trabajo de seguridad darle primero a un agente, cómo correrlo sin abrir un riesgo nuevo y cómo medir si de verdad le quita carga a tu equipo.
Qué hace. El agente investiga cada alerta con logs y contexto, revisa accesos, ordena vulnerabilidades y arma líneas de tiempo, siempre explicando qué encontró y con qué evidencia.
Qué no es. Un SIEM nuevo ni un sistema que bloquea por su cuenta. Tus reglas y tus herramientas siguen detectando; el agente investiga lo que ellas no pueden decidir.
Dónde se le va el tiempo a tu equipo
| Proceso | Lo que hace hoy una persona | Lo que hace el agente | Lo que decide una persona |
|---|---|---|---|
| Triage de alertas | Abre la alerta, busca logs en tres herramientas, decide si es real | Junta logs, compara con el comportamiento normal y explica si es real | Contener, escalar o cerrar |
| Phishing contra clientes | Revisa reportes y dominios parecidos uno por uno | Confirma la suplantación, junta evidencia y prepara la solicitud de baja | Enviar la solicitud y avisar a clientes |
| Revisión de accesos | Exporta usuarios de cada sistema y los cruza con nómina en Excel | Cruza accesos contra el puesto y las bajas, y marca lo que sobra | Quitar o mantener accesos |
| Vulnerabilidades | Ordena hallazgos por severidad del escáner | Prioriza según exposición real y propone el arreglo | Qué se corrige primero |
| Línea de tiempo de un incidente | Reconstruye a mano qué pasó y cuándo | Arma la línea de tiempo con cada evento y su fuente | El informe final |
Arranca con el triage de alertas o con el phishing contra tus clientes, el que hoy tenga más pendientes. Los dos tienen mucho volumen y muy poca decisión real por caso.
Cómo trabaja un agente de seguridad
- Recibe la alerta de tu SIEM, tu monitoreo o un reporte de cliente, o corre en un horario fijo.
- Investiga en modo lectura: logs de aplicación y de nube, accesos, cambios recientes, historial del usuario.
- Explica lo que encontró: qué pasó, qué tan seguro está, qué otra explicación podría haber.
- Propone una acción y la deja en Slack para tu equipo.
- Tu equipo decide y el agente registra la decisión. Si es un incidente, sigue armando la línea de tiempo.
Las herramientas
| Para qué | Lo que ya usas |
|---|---|
| Logs y monitoreo | Datadog, Splunk, Elastic, Microsoft Sentinel |
| Logs de nube | Google Cloud, AWS CloudTrail, Azure |
| Identidad y accesos | Okta, Google Workspace, Microsoft Entra ID |
| Endpoints | CrowdStrike, SentinelOne, Microsoft Defender |
| Código y vulnerabilidades | GitHub, GitLab, tu escáner de vulnerabilidades |
| Alertas y tickets | PagerDuty, Jira, Slack |
| Infraestructura para agentes | Runtime |
Con agentes de código como Claude Code o Codex, conectar una fuente nueva es cuestión de pedirlo: el agente escribe la consulta o la integración, la prueba y la guarda.
Runtime es el sistema operativo para agentes de IA. Cada agente corre en su propia computadora aislada, que se borra al terminar la sesión, con sus propias credenciales y acceso de red limitado a lo que necesita. Las acciones sensibles esperan el visto bueno de una persona responsable y todo queda en una bitácora.
Paso 1: escribe el patrón y lo que el agente nunca hace
Este paso lo hace tu equipo. Escoge un tipo de alerta y escribe cómo la investiga tu mejor analista: qué logs revisa, qué considera normal y qué lo hace escalar. Agrega la lista de lo que el agente nunca hace: bloquear usuarios, rotar llaves, cambiar reglas, borrar nada.
- Explícale el porqué. "Revisa si el acceso viene de una IP nueva y fuera de horario, porque así se ven los robos de sesión que hemos tenido" funciona mejor que "revisa la IP".
- Dile qué error no puede cometer. "Nunca cierres una alerta como falso positivo sin decir qué evidencia la descarta."
Paso 2: dale credenciales propias de solo lectura
El agente tiene su propio usuario en cada sistema, no el de una persona, con permisos de lectura. Las credenciales se cargan desde el dashboard de Runtime, nunca se pegan en un chat. Así puedes revocarlas cuando quieras y sabes exactamente qué consultó.
Investiga esta alerta de inicio de sesión sospechoso en la consola de administración. Trae los accesos de este usuario de los últimos 30 días en Okta y los logs de Google Cloud de la sesión. Dime si la IP, el dispositivo y el horario son normales para este usuario, qué hizo durante la sesión y si cambió permisos o descargó datos. Recomienda una acción y explícala. No bloquees al usuario.
Paso 3: ponlo en paralelo con tu equipo
Durante una o dos semanas el agente investiga las mismas alertas que tu equipo, sin tocar nada. Comparan conclusiones y cada diferencia se vuelve una instrucción. Revisa sobre todo las alertas que el agente cerró como falsos positivos.
Paso 4: hazlo proactivo
Una vez que confías en sus investigaciones, prográmalo: que revise alertas cada pocos minutos, que busque cada mañana dominios nuevos parecidos al tuyo y que corra la revisión de accesos cada trimestre sin que nadie se lo pida.
Cada mañana busca dominios registrados en las últimas 24 horas que se parezcan al nuestro. Para cada uno, revisa si tiene un sitio activo que copie nuestro logo, nuestra página de inicio de sesión o pida datos de tarjeta. Si confirmas suplantación, junta capturas y datos del registrador y prepara la solicitud de baja y un aviso para clientes. Déjalo en el canal de seguridad. No envíes nada.
Paso 5: úsalo cuando hay un incidente
Cuando tu equipo declare un incidente, el agente arma la línea de tiempo en paralelo: cada evento, su hora y su fuente. Eso le ahorra horas a tu equipo en el peor momento y deja listo el material para el informe interno y, si aplica, para el aviso a la autoridad.
Lo que se queda con tu equipo
| Qué | Por qué |
|---|---|
| Contener: bloquear, aislar, rotar llaves | Puede tirar un servicio o afectar a un cliente |
| Declarar un incidente | Activa tu plan de respuesta y posibles avisos a la autoridad |
| Avisar a clientes, al banco socio o a la CNBV | Es tu responsabilidad y tu reputación |
| Quitar accesos | Afecta el trabajo de una persona |
| Cambiar reglas de detección | Es tu modelo de amenazas |
Lo que hemos aprendido
- Empieza con un tipo de alerta. Uno bien investigado convence más que todo el SIEM a medias.
- El agente también es un usuario. Dale su propia identidad, permisos mínimos y revisa su bitácora como revisarías la de cualquiera.
- Las alternativas importan. Pídele siempre otra explicación posible; reduce los escalamientos de más.
- Lo recurrente es donde más se nota. Revisiones de accesos y dominios parecidos son trabajo que nadie quiere hacer y que el agente hace igual de bien cada vez.
Lo que te va a pedir cumplimiento
Si eres banco o institución de tecnología financiera, las disposiciones de la CNBV ya te piden gestionar la seguridad de la información, tener un responsable y avisar a la autoridad de ciertos incidentes. Si participas en SPEI, Banxico también te exige controles de seguridad. Un agente no cambia esas obligaciones, pero tu auditor va a preguntar por él:
- Qué accesos tiene. Credenciales propias, acotadas y revocables por agente.
- Qué puede hacer solo. Nada que contenga o cambie sistemas sin autorización.
- Qué datos ve. Los datos de clientes se enmascaran antes de llegar al modelo, y Runtime nunca entrena con tus datos.
- Qué hizo. Una bitácora de cada ejecución que puedes exportar. Runtime está auditado en SOC 2 y puede correr en tu propia nube o self-hosted.
Cómo medir resultados
| Indicador | Qué te dice |
|---|---|
| Tiempo desde la alerta hasta la decisión | Qué tan rápido respondes |
| Alertas pendientes al inicio del turno | Si ya no se te acumulan |
| Investigaciones aceptadas sin cambios | Qué tan bien trabaja el agente |
| Tiempo para dar de baja un sitio de phishing | Cuánto tiempo están expuestos tus clientes |
| Accesos sobrantes por revisión | La higiene de tus permisos |
Un calendario realista
| Etapa | Tiempo |
|---|---|
| Infraestructura para agentes | Minutos con Runtime; semanas si la construyes tú |
| Documentar un tipo de alerta y dar credenciales | 1 semana |
| Investigación en paralelo | 1 a 2 semanas |
| Triage con autorizaciones | Semana 3 o 4 |
| Phishing, accesos y vulnerabilidades | Mes 2 |
Rain, emisor de tarjetas con presencia en más de 150 países, usa Runtime para soporte técnico, monitoreo de fraude y riesgo, cumplimiento, ciberseguridad, investigaciones de ingeniería, revisión de PRs, QA y reportes, y se ha ahorrado $750k en proveedores y nómina.
En resumen
Tu equipo de seguridad no va a crecer al ritmo de las alertas. Deja que el agente investigue, cruce logs y prepare cada caso, y que tu equipo decida qué se contiene. Empieza con un tipo de alerta y hazlo proactivo cuando confíes en él. Para el lado de fraude, revisa la guía de prevención de fraude.
Ahora sí, a cuidar la casa.
Preguntas frecuentes
¿Para qué sirve un agente de IA en un equipo de ciberseguridad?
Para la investigación que viene después de cada alerta: juntar logs, revisar quién hizo qué, comparar con el comportamiento normal y explicar si es un incidente real. También sirve para trabajo recurrente como revisiones de accesos, priorizar vulnerabilidades y armar la línea de tiempo de un incidente. Tu equipo decide qué se contiene y cómo.
¿El agente puede bloquear usuarios o aislar equipos?
Solo si tú lo configuras así, y siempre con la autorización de una persona. Lo recomendable es que el agente trabaje con accesos de solo lectura y que bloquear una cuenta, rotar una llave o aislar un equipo espere el visto bueno de tu equipo en Slack o en el dashboard.
¿Cómo ayuda contra el phishing que suplanta a mi fintech?
El agente revisa los reportes de clientes, los dominios parecidos al tuyo y los mensajes que te reenvían, confirma si el sitio suplanta tu marca, junta la evidencia y prepara la solicitud de baja para el registrador o el proveedor de hosting. También redacta el aviso para tus clientes. Tu equipo decide qué se envía.
¿No es riesgoso darle acceso a un agente a mis logs y sistemas?
Por eso importa dónde corre. En Runtime cada agente tiene su propia computadora aislada que se borra al terminar, credenciales propias de solo lectura, acceso de red limitado a lo que necesita y una bitácora de todo lo que hace. Además puede correr en tu propia nube.
¿Qué pide la regulación mexicana en seguridad de la información?
Si eres banco o institución de tecnología financiera, las disposiciones de la CNBV ya te piden gestionar la seguridad de la información, tener un responsable y avisar a la autoridad de ciertos incidentes. Si participas en SPEI, Banxico también exige controles de seguridad. Confirma con tu área legal los plazos y formatos que te aplican.
¿Qué es Runtime?
Runtime es el sistema operativo para agentes de IA en equipos de pagos y fintech. Cada agente corre en una computadora aislada con sus propias credenciales, espera autorización antes de cualquier acción sensible, enmascara datos de clientes antes de que lleguen al modelo y deja una bitácora exportable. Está auditado en SOC 2.
Pon a tu primer agente a investigar alertas de seguridad
Trae tu tipo de alerta más ruidoso. Un ingeniero de IA de Runtime configura el agente, las credenciales y las autorizaciones con tu equipo.