
Por Thomas Cohen, fundador de Maestro
Claves API expuestas en una aplicación creada por IA: lo que ve un auditor
Una aplicación entregada en tres días recibe a sus primeros usuarios y todo parece funcionar. Un auditor que la abre mira tres lugares, siempre los mismos. Lo que encuentra, por qué la demo no lo muestra y lo que puede exigir un empresario sin leer una línea de código.
Un auditor que abre una aplicación creada por IA busca primero claves API expuestas. En Hacker News (febrero de 2026), un comentarista que dice auditar este tipo de sitios a diario escribe que ha encontrado «al menos 30». La medición apunta en la misma dirección: el código generado por grandes modelos supera las pruebas de seguridad en el 56 % de los casos, frente al 55 % un año antes (Veracode, 2026 GenAI Code Security Report, 28 de julio de 2026).
Los tres lugares que mira primero
El comentario de Hacker News nombra los tres seguidos: fundadores entregan aplicaciones construidas con Cursor, Lovable o Bolt, consiguen sus primeros usuarios, celebran y dejan en producción claves API expuestas, autenticaciones rotas y puntos de entrada que se pueden manipular. Traducido para un empresario: una contraseña técnica que viaja con la página al navegador del visitante, una puerta de entrada que no comprueba quién llama y formularios que confían en lo que les envían. Contamos los dos primeros en detalle, la prueba de la base de datos pública y nuestra propia clave que quedó visible; el tercero merece el mismo tratamiento, sin manual de instrucciones.
Por qué la demo no muestra nada
Veracode separa dos cosas en su informe del 28 de julio de 2026. La corrección del código, su capacidad de arrancar y hacer lo esperado, está resuelta: los modelos compilan, las pantallas aparecen. La seguridad no ha cambiado en un año, 56 % frente a 55 %, con un 44 % de tareas de generación que producen una vulnerabilidad. El detalle por tipo habla más que la media: 83 % de éxito en inyección SQL y 87 % en algoritmos de cifrado, pero 15 % en cross-site scripting y 12 % en inyección en registros. El mejor modelo probado se queda en el 68 %. Una aplicación puede, por tanto, superar tu demostración, atender a tus diez primeros clientes y seguir abierta donde nadie mira.
Nadie revisa
Un profesional francés describe el mismo movimiento en r/developpeurs (julio de 2026), y hay que precisar que vende ese servicio de auditoría: cada vez se desarrollan más sitios con ayuda de IA, a menudo por personas que no son desarrolladores, lo que democratiza la creación y multiplica las vulnerabilidades básicas porque nadie revisa el código. Su observación sobre sus clientes directivos de pymes es la parte más útil del mensaje: quieren un informe claro y comprensible, no un archivo ilegible lleno de jerga. La demanda es razonable y el mercado responde mal.
Lo que puede exigir un empresario sin leer el código
Cuatro peticiones caben en francés y se pueden verificar. La lista de claves y contraseñas técnicas utilizadas, con el lugar donde se guarda cada una, y confirmación escrita de que ninguna viaja con la página al navegador. La regla que dice, para cada tipo de dato, quién tiene derecho a leerlo y modificarlo. La prueba de que se escribió un test para esa regla y de que falla si se rompe. Y la fecha de la última verificación. En Maestro, esos elementos salen del método en lugar de la buena voluntad: las pruebas se escriben antes del código, el agente Félix las ejecuta en cada etapa y tus claves viven en el Llavero de macOS en lugar de pasearse por los archivos del proyecto. Nuestro defecto de agosto lo mostró en ambos sentidos: la clave visible venía de nosotros y fue un probador quien la vio.
Lo que eso no sustituye
Una auditoría humana sigue siendo superior y no vamos a afirmar lo contrario. Alguien cuyo oficio es intentar romper tu aplicación encontrará cosas que ninguna verificación automática busca, porque razona sobre tu actividad, el dinero que circula y las personas que usan la herramienta. Los escáneres especializados, como el del comentarista de Hacker News, también tienen su lugar antes de publicar. La verificación integrada sirve para que el informe de auditoría no tenga treinta páginas de errores evitables y para que su factura sea soportable, un tema vecino al de la aplicación que funciona sin ser segura.
Pedir la lista mañana por la mañana
Escribe a tu proveedor o abre tu herramienta y pide una sola cosa para empezar: la lista de claves y accesos técnicos de tu aplicación, con el lugar donde se guarda cada uno y la fecha de su última rotación. Una respuesta clara en una página dice que alguien se ocupa. Una respuesta incómoda te dice por dónde empezar y no habrás leído ninguna línea de código para saberlo.