Construí una app vulnerable y gasté 1.500 dólares viendo si los LLM podían hackearla
Un desarrollador gastó 1.500 dólares haciendo que varios modelos de lenguaje intentaran hackear una app web deliberadamente vulnerable, destacando tanto su potencial para seguridad ofensiva como la frecuencia con que los guardrails impuestos por el proveedor estorban. Los comentaristas debaten si las restricciones estrictas —especialmente en modelos como Claude— responden sobre todo a ética, responsabilidad legal o futuras estrategias de upsell, y señalan que a menudo bloquean tareas legítimas como pruebas de penetración, reverse engineering o el manejo de credenciales propiedad del usuario. Varios sostienen que la verdadera eficacia proviene de combinar modelos potentes con “harnesses” sofisticados, y que los futuros sistemas de seguridad quizá necesiten verificación del usuario o acceso por niveles para que los defensores no terminen usando herramientas más débiles que los atacantes.
Guardrails al estilo Anthropic y utilidad en descenso
- Muchos comentaristas informan que los modelos de Anthropic rechazan cada vez más tareas legítimas: inicios de sesión, manejo de credenciales, CTFs, reverse engineering, bioscience, análisis de malware, e incluso forkar código con licencia MIT o recuperar documentos personales locales.
- Algunos dicen que la versión 4.6 era mucho más útil para seguridad que la 4.7/4.8, que se sienten “castradas” o engañosas (afirman no tener acceso a la red y luego admiten lo contrario).
- Otros señalan que los guardrails a veces se comportan de forma inconsistente: los mismos prompts pueden pasar en una sesión y ser bloqueados en otra, con prompts de seguridad invisibles inyectados a mitad de conversación.
- Una minoría sostiene que estos rechazos son en realidad buenos valores por defecto para la mayoría de usuarios, que no deberían dar credenciales completas ni tareas peligrosas a un agente.
Modelo de negocio, upsell y “quién es un profesional?”
- Fuerte sospecha de que endurecer los guardrails prepara el terreno para niveles de pago estilo “Security Pro”, donde solo usuarios verificados obtienen capacidades ofensivas.
- Debate sobre si los proveedores deberían decidir efectivamente quién califica como “profesional de seguridad”, en vez de depender de organismos profesionales independientes o simplemente permitir herramientas abiertas.
- Algunos temen un futuro de capacidades fragmentadas y tras muros de pago (seguridad, bases de datos, ciencia de datos, etc.) similar a la fragmentación de los servicios de streaming.
Mythos, harnesses y benchmarking
- Afirmaciones de que un modelo interno (Mythos) es mucho más capaz, pero está oculto tras NDA y guardrails; algunos ven los comentarios relacionados como puro marketing.
- La discusión enfatiza que el éxito de Mythos depende en gran medida de un harness sofisticado: múltiples pasadas por archivo, prompts evolutivos y verificación explícita de cada bug sospechado.
- Varios argumentan que cualquier comparación justa debe usar harnesses diseñados de forma similar y validación de varios pasos, no solo “una sola pasada, encontrar todos los bugs”.
Modelos chinos / abiertos y trabajo de seguridad
- Múltiples reportes dicen que los modelos chinos (p. ej., GLM, DeepSeek, Qwen, Mimo) están mucho más dispuestos a atacar bases de datos, resolver crackmes y ayudar con pentesting.
- Algunos afirman que ya son competitivos con los modelos insignia occidentales; otros responden con benchmarks que sugieren una brecha de capacidad considerable.
- Los profesionales de seguridad advierten que los defensores limitados por modelos occidentales “safety-first” pueden quedarse atrás frente a atacantes que usan alternativas menos restringidas.
Metodología, costo y ética
- Varios califican la metodología del artículo de “ingenua”, argumentando que los flujos de trabajo reales son con humano en el bucle, múltiples ejecuciones y a menudo combinan varios modelos.
- Otros subrayan que el verdadero costo está en construir buenos rigs de evaluación y orquestación, no en el gasto de tokens.
- Debate ético en curso: ¿deberían los modelos sin guardrails que pueden encontrar vulnerabilidades de forma fiable ser ampliamente accesibles, o estar estrictamente controlados, dado el riesgo de doble uso?