Hicimos Red Team a MVPs Construidos con IA. Esto Es Lo Que Se Rompió.
Seguridad
2026-06-19
Nos propusimos responder una pregunta: ¿qué tan mal está, en realidad?
Todos coinciden en que los productos construidos con IA "tienen problemas de seguridad". Vago. Así que corrimos un ejercicio de red team enfocado contra un conjunto de MVPs reales construidos con IA — productos entregados rápido, en su mayoría por piloto automático, del tipo que está levantando una ronda seed hoy. Los atacamos como lo haría un adversario real.
No damos nombres, y generalizamos los detalles. Pero los patrones valen tu tiempo, porque si entregaste con IA, casi seguro tienes al menos uno de estos.
El Método
Nada exótico. Hicimos lo que hace un atacante con una tarde libre y un navegador:
- Creamos una cuenta, y luego hurgamos en cada ID, cada endpoint, cada parámetro.
- Leímos el bundle del cliente y la pestaña de red.
- Apuntamos las features de IA hacia inputs que no esperaban.
- Y luego subimos la concurrencia y observamos qué se caía.
Sin zero-days. Sin presupuesto de estado-nación. Solo curiosidad y la disposición a enviar un request que la app no anticipó.
Esa es la amenaza. No hackers de película — una persona aburrida con las dev tools abiertas.
Qué Se Rompió
1. Bypass de autenticación / IDOR — lo encontramos en casi todos
El hallazgo principal. Cambia /api/invoice/1041 a /api/invoice/1040 y estás leyendo la factura de otro. La app verificaba que habías iniciado sesión; nunca verificaba que el registro era tuyo. En un producto recorrimos la tabla entera de usuarios de esta forma. Este es el bug serio más común en software construido con IA, punto.
2. Secretos a la vista de todos
API keys vivas en el bundle de JavaScript. Una key de almacenamiento en la nube con acceso de escritura enviada al navegador. Un .env con credenciales de base de datos de producción commiteado en la primera semana y nunca rotado. Cualquiera que abriera la pestaña de red tenía las llaves del reino.
3. SSRF — el servidor pidiendo lo que le digas
Una feature de "obtener preview desde URL" que felizmente solicitaba cualquier URL que le dieras — incluyendo endpoints internos de metadata de la nube. Eso es una línea recta para robar las credenciales de nube del servidor. La IA construyó la feature exactamente como se pidió. Nadie le dijo que la URL era hostil.
4. Prompt injection directo a agentes que llaman herramientas
El hallazgo más moderno y más subestimado. Un agente de soporte de IA que podía buscar pedidos y emitir reembolsos — y tomaba instrucciones del contenido de un ticket de soporte. Pega el texto correcto en el campo del mensaje y el agente se emite a sí mismo un reembolso, o vuelca el historial de pedidos de otro cliente. El input del usuario no era confiable; el agente lo trató como un comando.
5. Bugs de dinero bajo concurrencia
Dispara el endpoint de "canjear crédito" cien veces en paralelo y el balance se vuelve negativo. Dos requests leen el mismo valor, ambos pasan el check, ambos escriben. En una demo nunca lo verías. Con usuarios reales — o cualquiera que sepa sostener el botón — es una pérdida directa. Código de alto rendimiento que no fue diseñado para concurrencia es una vulnerabilidad, no solo un bug.
6. Sin rate limits — costo y caída como ataque
Endpoints sin medición llamando a APIs de pago (incluyendo LLMs). Un solo script podía acumular una factura de cuatro cifras de la noche a la mañana o simplemente tumbar el servicio. Los endpoints funcionaban hermosamente un request a la vez, que es la única forma en que jamás fueron probados.
El Hilo Común
Cada uno de estos tiene la misma causa raíz: la IA optimiza para el camino que le mostraste.
Pediste "deja que los usuarios vean sus facturas", así que construyó la lectura. No dijiste "y evita que vean las de todos los demás", así que no lo hizo. El camino feliz es impecable. El camino adversario nunca se consideró, porque considerar al adversario es un trabajo distinto — y es el trabajo que el piloto automático se salta.
Esto no es un argumento contra construir con IA. Construimos con IA todos los días. Es un argumento a favor de un humano que piense como atacante leyendo el resultado antes que tus usuarios.
El Playbook de Arreglos
Si no haces nada más, haz esto, más o menos en orden:
- Autorización en cada objeto. Cada lectura y escritura verifica "¿este usuario es dueño de esto?" — no solo "¿este usuario inició sesión?". Esto mata la clase IDOR.
- Saca los secretos del cliente y rótalos. Nada sensible en el bundle. Cualquier cosa que alguna vez se commiteó está quemada — rótala.
- Trata todo input de usuario como hostil — incluido el input a tu IA. Valida, sanitiza, y nunca dejes que texto no confiable se convierta en una instrucción o una acción sin una barrera.
- Allowlist para requests salientes. Si el servidor obtiene una URL, restringe a dónde puede ir. Bloquea rangos internos y endpoints de metadata.
- Haz atómicas las operaciones concurrentes. Cualquier cosa que toque dinero o contadores necesita locking correcto u operaciones atómicas de base de datos — diseñadas para el hot path, no atornilladas después.
- Pon rate-limit a todo, especialmente a lo que cuesta dinero. Por usuario y global. Este es tu circuit breaker contra el abuso y las facturas descontroladas.
- Re-testea bajo carga adversaria. Arreglarlo en el código no es terminar. Terminar es probar que aguanta cuando alguien lo ataca.
Este Es el Trabajo Que Hacemos
Leer el camino feliz es en lo que la IA es excelente. Leer el camino adversario — el IDOR, el agente inyectado, la carrera bajo carga — es en lo que nosotros somos excelentes, y se vuelve más valioso cada día a medida que más código se despliega en piloto automático.
Hacemos red team y endurecemos sistemas de alto rendimiento y construidos con IA: encontramos lo que un atacante encontraría, lo probamos, lo arreglamos, y verificamos que el arreglo aguante.
Reserva 20 minutos con nosotros. Cuéntanos qué entregaste. Te diremos, honestamente, por dónde empezaríamos.
Mejor nosotros que ellos.
Anteriormente: La Trampa del Piloto Automático — por qué el código generado por IA falla la revisión de seguridad.
Written by Dandelion Labs