Para el socio director de Dragonfly, Haseeb Qureshi, el aspecto más sorprendente del experimento de GLM 5.2 fue su costo: "GLM 5.2 ejecutándose durante 20 minutos cuesta aproximadamente $2. ¿Qué significa eso? Significa que estamos en un nuevo mundo."

Dragonfly es una firma de capital de riesgo enfocada en criptomonedas, y las observaciones de Qureshi tienen peso en una industria donde las fallas de software han permitido algunos de los robos más grandes de los que se tenga registro. Según se informa, el modelo redescubrió la vulnerabilidad vinculada al reciente robo de ColdCard después de que los investigadores lo dirigieron hacia el software afectado. ColdCard, fabricada por Coinkite, es una billetera hardware popular entre los usuarios de autocustodia de Bitcoin. No hay evidencia de que los ladrones usaran IA. La prueba demuestra, en cambio, lo económicamente que tanto atacantes como desarrolladores pueden ahora examinar el código que protege grandes cantidades de criptomonedas.

Por qué el costo de $2 importa

La investigación seria de vulnerabilidades ha requerido tradicionalmente conocimiento especializado y muchas horas de esfuerzo manual. Incluso un investigador experimentado puede inspeccionar solo un número limitado de versiones de firmware, contratos inteligentes y bibliotecas criptográficas.

La IA permite que una cantidad mucho mayor de código reciba una revisión inicial. Los investigadores pueden asignar varios modelos al mismo código base, pedirles que investiguen diferentes rutas de falla y repetir el proceso siempre que esté disponible un modelo más potente.

La mayoría de las búsquedas pueden no producir nada útil. Eso pierde importancia cuando un intento individual cuesta solo unos pocos dólares. Quien busque debilidades puede examinar muchos objetivos sin necesitar que cada ejecución tenga éxito. Una sola falla válida en un software que protege millones de dólares podría justificar el costo de miles de intentos fallidos.

La IA no ha eliminado la necesidad de experiencia en seguridad. Ha reducido el costo de generar pistas, probar teorías y cubrir más código del que un investigador humano podría inspeccionar por sí solo.

Lo que realmente demuestra la prueba de GLM 5.2

Qureshi dijo que los investigadores pidieron a varios modelos que examinaran el software después de que el incidente de ColdCard ya hubiera centrado la atención en él. Según él, a los modelos no se les dijo dónde se ubicaba la vulnerabilidad, y GLM 5.2 la encontró en aproximadamente 20 minutos.

El contexto es importante. Los investigadores ya sabían que el software relevante contenía un problema serio. El modelo no estaba buscando a ciegas en todas las billeteras hardware ni descubriendo un ataque sin un punto de partida.

Identificar un error también es diferente de explotarlo a gran escala. Un atacante todavía podría necesitar:

• Determinar qué dispositivos o billeteras están afectados.
• Reconstruir claves privadas utilizables.
• Identificar billeteras que contengan saldos valiosos.
• Mover los fondos antes de que los usuarios o los fabricantes puedan responder.

Los comentarios de Qureshi no muestran que GLM 5.2 haya realizado esos pasos ni que un sistema de IA haya participado en el robo original. Lo que el experimento establece es más limitado pero aún importante: un modelo de propósito general, según se informa, redescubrió la debilidad técnica subyacente rápidamente y a un costo insignificante.

La IA ya está aquí, antes que la amenaza cuántica

Gran parte del debate sobre la seguridad a largo plazo de Bitcoin se ha centrado en la computación cuántica. Una máquina cuántica suficientemente capaz podría eventualmente amenazar los esquemas de firma que protegen las monedas, obligando a las redes y a los usuarios a migrar a una nueva criptografía. Ese riesgo requiere preparación anticipada.

El análisis de código asistido por IA presenta un problema diferente porque las herramientas ya pueden utilizarse contra el software que funciona hoy. La IA no necesita derrotar la matemática subyacente de Bitcoin. Puede buscar en el código circundante errores como la generación débil de números aleatorios, secretos expuestos, implementaciones criptográficas defectuosas y funciones de recuperación inseguras.

Un análisis previo de las amenazas de IA y cuánticas que enfrenta el cripto examinó la misma distinción. La computación cuántica podría eventualmente crear un problema criptográfico en toda la red. La IA ya puede dirigirse a billeteras, puentes, bibliotecas y aplicaciones que actualmente protegen los fondos de los usuarios.

La preocupación inmediata es, por lo tanto, un error humano en el software alrededor de Bitcoin en lugar de que la IA rompa al propio Bitcoin.

Atacantes y desarrolladores tienen acceso a la misma herramienta

La IA no tiene preferencia por una seguridad más fuerte ni por un ataque exitoso. Su efecto depende de la tarea que le asignen las personas.

Un atacante puede usar un modelo para escanear firmware antiguo, automatizar análisis repetitivo y probar posibles debilidades. Un fabricante de billeteras puede usar el mismo modelo antes del lanzamiento, dirigiéndolo hacia la generación de claves, la firma de transacciones y los procedimientos de recuperación.

Los desarrolladores también pueden revisar productos lanzados antes de que existieran los agentes de programación modernos. El software auditado hace cinco años puede ahora examinarse con herramientas que no estaban disponibles cuando llegó a los clientes. Varias empresas de seguridad de blockchain ya han comenzado a incorporar análisis asistido por IA en sus flujos de trabajo de auditoría, aunque la tecnología sigue siendo un complemento de la revisión humana en lugar de un reemplazo.

Sin embargo, las dos partes no operan bajo condiciones iguales. Un atacante puede actuar tan pronto como se confirma una vulnerabilidad útil. Un desarrollador debe reproducir el hallazgo, entender qué usuarios están afectados, preparar una corrección segura y distribuirla sin revelar suficiente información que acelere la explotación.

Los modelos también pueden malinterpretar el código, producir falsos positivos o describir ataques que fallan en la práctica. Los investigadores humanos siguen siendo responsables de verificar el resultado y decidir con qué urgencia necesita responder el proyecto.

La IA amplía la cantidad de código que puede examinarse. No reemplaza la experiencia ni la respuesta a incidentes requerida después de encontrar una debilidad grave.

La autocustodia sigue dependiendo de la billetera

Qureshi describió a los usuarios afectados como personas que habían seguido los consejos de seguridad habituales: "Personas que están haciendo todo correctamente."

Habían trasladado su Bitcoin fuera de los exchanges y lo habían almacenado en billeteras hardware dedicadas. Sin embargo, la autocustodia sigue dependiendo de que el dispositivo cree y proteja sus claves correctamente.

Qureshi dijo que el firmware afectado utilizaba una fuente de aleatoriedad más débil de lo previsto. Si una clave privada se genera a partir de datos predecibles, mantener el dispositivo sin conexión no puede fortalecer la clave con posterioridad. Una separación de red (air gap) puede reducir la exposición a ataques remotos contra un secreto generado correctamente. No puede reparar un secreto que fue débil desde el momento en que se creó.

Los usuarios de billeteras hardware dependen, por lo tanto, de más que su propio manejo de una frase de recuperación. También confían en el firmware del fabricante, el diseño del hardware, las bibliotecas criptográficas y el generador de números aleatorios. Años sin un exploit conocido pueden demostrar que el software ha sobrevivido al uso ordinario. No prueban que cada debilidad grave ya haya sido identificada.

El código antiguo de las billeteras necesita ser revisado nuevamente

El análisis de IA más económico facilita la revisión del código antiguo. El software que antes atraía poca atención puede ahora examinarse repetidamente y a escala.

Los fabricantes de billeteras y los protocolos cripto deberían volver a escanear versiones anteriores cuando los modelos principales mejoren, especialmente cuando el código crea claves privadas, firma transacciones o controla la recuperación de billeteras.

Una actualización de firmware no resolverá todos los problemas. Cuando una falla afecta cómo se crearon las claves existentes, corregir el software puede proteger las billeteras nuevas mientras deja las más antiguas expuestas. Los usuarios pueden necesitar generar nuevas claves bajo el sistema reparado y transferir sus fondos. Los proveedores deberían, por lo tanto, poder identificar las versiones afectadas, contactar rápidamente a los clientes y explicar cómo migrar de forma segura.

Ese proceso también crea oportunidades para estafadores. Los incidentes de seguridad suelen generar cuentas de soporte falsas, sitios web de migración maliciosos y mensajes que piden a los usuarios que verifiquen sus billeteras. Los usuarios nunca deben proporcionar una frase semilla o clave privada a un representante de soporte, sitio web, cuenta de redes sociales o chatbot de IA. Un proceso de recuperación legítimo no requiere que otra persona o servicio reciba esos secretos.

La revisión de seguridad ya no puede ser un evento único

El análisis asistido por IA debería convertirse en parte del desarrollo normal en lugar de una herramienta que se usa solo después de que se hayan robado fondos. Las empresas cripto deberían considerar:

• Escanear código nuevo antes del lanzamiento.
• Reexaminar firmware y bibliotecas antiguos a medida que los modelos mejoran.
• Usar varios modelos para abordar el mismo código desde diferentes direcciones.
• Hacer que investigadores experimentados reproduzcan hallazgos graves.
• Preparar procedimientos de comunicación de emergencia y migración de billeteras.
• Mantener programas de divulgación responsable y recompensas por errores.

Los modelos proporcionan una cobertura más amplia y rápida. Los equipos de seguridad aún necesitan separar las vulnerabilidades genuinas de los informes incorrectos, desarrollar una corrección y gestionar las consecuencias para los usuarios.

La carrera de seguridad se está volviendo más económica

El ejemplo de Qureshi no muestra que la IA pueda romper a Bitcoin. Muestra que el software que protege a Bitcoin puede ahora someterse a pruebas de vulnerabilidades a un costo que rápidamente se está volviendo insignificante.

Ese desarrollo puede producir mejor seguridad o ataques más económicos. Los desarrolladores pueden usar la IA para desafiar sus propios productos y detectar errores antes del lanzamiento. Los atacantes pueden dirigirla hacia código olvidado, repetir búsquedas en muchos objetivos y actuar según el primer resultado útil.

La tecnología está disponible para ambos. El resultado depende de quién la use, con qué precisión se verifiquen los hallazgos y qué tan rápido puedan responder los defensores. Los proyectos que reevalúan continuamente su software pueden beneficiarse de las mismas herramientas que facilitan los ataques. Quienes dependen de auditorías antiguas o asumen que un error oculto durante mucho tiempo ya habría sido encontrado dejan esa oportunidad a otra persona.

Aviso legal: Este artículo es solo para fines informativos y no constituye asesoramiento en materia de seguridad, finanzas ni inversión. El experimento reportado no establece que se haya usado IA en el robo de ColdCard ni que GLM 5.2 pueda identificar de manera confiable cada vulnerabilidad de software.

Metodología: Este análisis utiliza comentarios públicos del socio director de Dragonfly, Haseeb Qureshi, sobre el incidente de ColdCard y la prueba reportada de GLM 5.2. La comparación entre el riesgo de IA y el cuántico distingue las herramientas de investigación de vulnerabilidades actualmente disponibles de las amenazas a largo plazo que requieren hardware cuántico con capacidad criptográfica.