Proteger tu SaaS con agentes de IA (lecciones de un pentest salvaje)

Un desarrollador decidió "pentestear" el SaaS de un colega. Sin avisar. Una tarjeta de prueba de Stripe, un fallo en el flujo de pago, y una suscripción de pago obtenida gratis. Lo pillaron los logs: su email en texto plano, visible del lado de la víctima.

La víctima es Benjamin (BenjaminCode), un amigo. No nombraré al autor: es justo la atención que busca. Pero el incidente es solo un pretexto. El verdadero tema es este: la IA vuelve trivial el pentesting. Cualquiera puede lanzar hoy un agente que sondea tu SaaS en producción. La única respuesta sostenible es una defensa agéntica que funcione en continuo.

Por qué importa ahora

Antes, sondear una aplicación exigía tiempo y habilidad. Hoy, un agente de IA genera emails desechables, prueba endpoints, intenta pagos con tarjetas de prueba y lo documenta todo, en minutos. El coste de un ataque oportunista ha caído casi a cero.

La conclusión: si tienes un SaaS en producción con usuarios reales, te van a sondear. No es cuestión de "si" sino de "cuándo". La buena noticia: los mismos agentes que facilitan el ataque hacen la defensa automatizable.

Los 3 agentes que protegen mi SaaS

Me apoyo en un tríptico: prevenir, corregir, vigilar. Tres agentes, tres roles.

1. Prevenir — el agente de auditoría

Un agente que escanea el código en continuo y busca fallos antes de que lleguen a producción: secretos expuestos, dependencias vulnerables, rutas sin proteger, validación ausente. Lo ejecuto cada semana (repo-security-audit) y me da un informe priorizado.

2. Corregir — el agente de dependencias

Un agente que vigila las CVE de las dependencias, prioriza por criticidad y abre las pull requests de actualización por su cuenta. No un Dependabot en bruto: un agente que clasifica, explica el riesgo y propone la corrección.

3. Vigilar — el agente de análisis de logs

Es el que detectó al atacante. Un agente que lee los logs de producción en continuo y detecta patrones anómalos:

• una tarjeta de prueba que aparece en un pago real,
• accesos repetidos a endpoints de administración,
• intentos de explotar el flujo de pago.

Alertas en tiempo real. Es exactamente este tipo de agente el que "quemó" al atacante en el caso: los logs lo registraron todo.

Lecciones del fallo (hardening de la aplicación)

Más allá de los agentes, el incidente recuerda unas reglas básicas que demasiados SaaS descuidan:

• Separar estrictamente test y producción. Una tarjeta de prueba NUNCA debe validar un pago en producción.
• Validar el precio en el servidor. Nunca confíes en el front para un "gratis" o un descuento.
• Firmar y verificar los webhooks de Stripe (signing secret obligatorio).
• Limitar el ritmo (rate limiting) en los endpoints sensibles.
• Enmascarar los datos sensibles en los logs. La ironía del caso: el atacante no enmascaró su email. Tú tampoco loguees nada en claro.

¿Y en el plano legal?

Entrar en el sistema de un tercero sin autorización no es una "jugada astuta", es un delito. En Francia, el acceso y el mantenimiento fraudulento en un sistema de tratamiento automatizado de datos se castigan en los artículos 323-1 y siguientes del Código Penal. Un vídeo "discreto" que deja adivinar el objetivo, sin avisar a la víctima, no protege a la víctima: protege al autor.

Lo que hay que recordar

La IA hizo el ataque gratis. La defensa debe volverse automática. Tres agentes (prevenir, corregir, vigilar) más unas reglas de hardening, y pasas de una postura reactiva a una continua.

Muestro el montaje completo en vídeo, con la demo del agente de análisis de logs: ver en YouTube.

Para profundizar en dev agéntico y seguridad, únete a mi newsletter The Agentic Dev.