REA. La IA aprendió a desarmar software. Sus secretos no pueden estar ahí dentro.

Este mes, un proyecto open source llamado REA, Reverse Engineer Anything, llegó a lo más alto de las tendencias de GitHub. La propuesta cabe en una línea. Dar a los agentes de IA las herramientas de ingeniería inversa. Descompilar, entender, recrear. El agente abre el software, explica cómo funciona, muestra las evidencias y construye una versión para su proyecto.

Léalo de nuevo. Construye una versión.

Quiero hablar de esto sin alarmismo y sin ingenuidad. Porque la mayoría de las empresas todavía trata su propio código como una caja fuerte. Y el código nunca fue una caja fuerte. Ahora es una vitrina con un agente de IA afuera, leyéndolo todo.

Qué es REA, sin misterio

REA es un servidor MCP, el Model Context Protocol, y una línea de comandos, de código abierto, con licencia MIT. Conecta agentes de programación como Claude Code, Cursor, Codex y Gemini CLI a herramientas clásicas de ingeniería inversa. Ghidra, IDA y Hopper para binarios nativos. JADX para aplicaciones Android. Chrome DevTools para aplicaciones web y Electron.

El agente no necesita saber operar cada herramienta. Pide, y REA lo dirige a la herramienta correcta. El alcance es amplio. Binarios nativos, APKs, aplicaciones JavaScript con sus source maps, assemblies .NET, sitios, WASM, contratos EVM, binarios Go, firmware.

En la práctica, lo que antes exigía un especialista ahora exige una pregunta bien hecha. “¿Cómo hace esto esta app?” Y el agente va a buscar la respuesta dentro del software.

El proyecto deja claro que nació para uso lícito. Investigación, educación, interoperabilidad, preservación de software, análisis de lo que usted posee o está autorizado a examinar. Y es verdad. La ingeniería inversa es una disciplina legítima. Los investigadores la usan para encontrar fallas. Las empresas la usan para garantizar interoperabilidad. Yo mismo, como diseñador, pasé la vida desarmando productos para entender por qué funcionaban.

Pero una herramienta no elige quién la usa. Lo que el investigador hace en una tarde, el malintencionado también lo hace. Y ahora ambos lo hacen con un agente incansable trabajando para ellos.

La barrera cayó

Este es el punto que quiero fijar. La ingeniería inversa siempre fue posible. Lo que protegía era el costo. Tiempo, conocimiento, herramientas. Muchas empresas contaban, sin admitirlo, con ese costo como capa de seguridad.

REA, y todo lo que vendrá después, convierte ese costo en casi cero. Una aplicación Android, un front-end web, un instalador de escritorio, un firmware. Todo puede ser leído, explicado y reconstruido por un agente en una fracción del tiempo.

Y el problema empieza cuando el producto desarmado revela lo que nunca debería haber estado ahí. Una contraseña. Una clave de API. Un token de acceso a la nube. La lógica de licenciamiento completa. El endpoint interno que nadie documentó. Un agente no se cansa de buscar. Lo va a encontrar.

Los peligros reales

El primer peligro es el obvio. Clonación. Quien entiende cómo funciona su producto por dentro puede reproducirlo, modificarlo y redistribuirlo. Con un agente haciendo el trabajo pesado, años de construcción se convierten en una tarde de copia.

El segundo es más silencioso y más caro. Acceso. Una credencial olvidada dentro del código no expone solo la aplicación. Expone la base de datos, el storage, la cuenta de nube, los datos de sus clientes. El atacante no necesita invadir nada. Usa la llave que usted dejó en la puerta.

El tercero es el ataque a la confianza. Versiones modificadas de su app circulando con su nombre, su marca, su cara, pero con código malicioso por dentro. El usuario no nota la diferencia. Y quien paga la cuenta reputacional es usted.

Software que ya fue abierto, copiado y clonado

Esto no es teoría. La historia reciente es un catálogo de lecciones caras.

WhatsApp convive desde hace años con versiones modificadas como GB WhatsApp, construidas a partir de la ingeniería inversa de la aplicación original. Prometen funciones extra y entregan riesgos extra. El propio WhatsApp empezó a bloquear cuentas que usan estos clones, porque no hay forma de garantizar la seguridad de un código que nadie audita.

Snapchat aprendió en 2014. Investigadores hicieron la ingeniería inversa de la API privada de la aplicación, publicaron la documentación y alertaron sobre una falla. Poco después, millones de nombres de usuario y números de teléfono fueron extraídos y publicados. La API era privada solo de nombre.

Pokémon GO, en 2016, vio su comunicación desarmada en semanas. Surgieron mapas, bots y herramientas de terceros alimentados directamente por los servidores de Niantic, que tuvo que reaccionar endureciendo la protección de su API.

Y en 2026, el caso que más me hizo pensar. Anthropic publicó por error, en un paquete npm, un archivo de source map de Claude Code. Era el mapa para reconstruir el código fuente original. Cerca de 512 mil líneas quedaron expuestas, replicadas y estudiadas por el mundo entero en cuestión de horas. Una de las empresas más sofisticadas de IA del planeta, derribada por un archivo de configuración de empaquetado olvidado. Si pasó ahí, pasa en cualquier lugar.

El error más caro: secretos dentro del código

Ahora el punto central de este artículo. La mayor vulnerabilidad no es la ingeniería inversa. Es lo que ella encuentra.

En 2016, Uber sufrió una filtración que alcanzó datos de 57 millones de usuarios y conductores. El camino de los atacantes pasó por un repositorio de código donde estaban las credenciales de acceso a la nube de la empresa. La llave estaba en el código. Se accedió al código. El resto es historia.

Toyota reveló en 2022 que parte del código fuente de un servicio conectado estuvo público en GitHub durante cerca de cinco años. Dentro de él, una clave de acceso a un servidor de datos. Casi 300 mil direcciones de correo de clientes quedaron expuestas.

Ese mismo año, Symantec analizó aplicaciones móviles y encontró 1.859 apps con credenciales de AWS escritas directamente en el código. En uno de los casos, el acceso abría camino a las huellas digitales de cientos de miles de personas. La biometría no se cambia como una contraseña.

Y el problema solo crece. El informe State of Secrets Sprawl 2025, de GitGuardian, contó cerca de 23,8 millones de nuevos secretos expuestos en repositorios públicos de GitHub en un solo año. Y la mayor parte de los secretos filtrados sigue siendo válida mucho tiempo después. Nadie los rotó. Nadie se dio cuenta.

Observe el patrón. Ninguno de estos casos exigió un genio del crimen. Bastó con alguien mirando con atención algo que debía ser privado y no lo era.

La regla que no se negocia

Entonces voy a fijar la regla. Contraseña, clave de API, token, certificado, cadena de conexión, secreto de firma. Nada de eso vive en el código. Nunca. Ni en la app, ni en el front-end, ni en el repositorio privado, ni en el commit de prueba que usted iba a borrar después.

El secreto vive en el servidor. En una bóveda de secretos, un vault, un gestor de credenciales de la nube. Se inyecta en tiempo de ejecución, en el entorno que usted controla, con acceso restringido a quien lo necesita. El código pide. El servidor decide si lo entrega.

La aplicación que corre en manos del cliente debe tratarse como territorio público. No guarda secretos. No toma decisiones sensibles. No habla directo con la base de datos ni con la API paga. Habla con su back-end, y el back-end habla con el resto, autenticando, limitando, registrando. Si la regla de negocio importa, corre en el servidor. Si la validación importa, corre en el servidor. Lo que está en el cliente puede ser leído y lo será.

La seguridad es arquitectura, no un parche

Ofuscar el código ayuda. Retrasa al curioso. No detiene al decidido. La ofuscación es una cortina, no una pared.

La protección de verdad se diseña en capas. Secretos centralizados en una bóveda y nunca en el repositorio. Credenciales de corta duración, que expiran solas, en lugar de llaves eternas. Rotación periódica, para que una filtración antigua se vuelva una llave inútil. Privilegio mínimo, para que cada llave abra solo la puerta que necesita abrir. Escaneo automático de secretos antes de cada commit y en cada pipeline, porque el error humano va a ocurrir y la máquina necesita atraparlo antes que el mundo. Atestación de la aplicación, para que el servidor sepa si habla con la app legítima o con un clon. Monitoreo, para detectar el uso anómalo antes de que se vuelva titular.

Y un punto que veo poca gente discutir. La IA aprieta los dos lados de la ecuación al mismo tiempo. Por un lado, herramientas como REA hacen que leer su software sea barato para cualquiera. Por el otro, equipos enteros generan código con asistentes a una velocidad inédita. Los prototipos se vuelven producción en días. Y es justamente en esa prisa que la clave de API del modelo de lenguaje termina en el front-end, a la vista de cualquiera, generando una cuenta que nadie previó. Los agentes de IA, a su vez, operan con credenciales y acceden a sistemas reales. Un agente con una llave expuesta no es un asistente. Es una puerta abierta con autonomía.

Velocidad sin gobernanza es solo riesgo acelerado.

La mirada de quien construye

Vengo del diseño. Y aprendí temprano que una buena experiencia es la que esconde la complejidad del usuario sin esconder la responsabilidad de quien construye. La seguridad es lo mismo. No aparece en la pantalla. Nadie elogia el secreto que no se filtró. Pero es parte de la experiencia tanto como el botón bien diseñado.

En Mars tratamos esto como fundamento. La mayor barrera de la IA corporativa es la confianza, no la tecnología. Y la confianza no nace de promesas. Nace de arquitectura. De saber exactamente dónde vive cada secreto, quién accede, por cuánto tiempo y con qué rastro. La privacidad by design empieza ahí, mucho antes de que el primer dato personal entre al sistema.

La gobernanza no es burocracia. Es lo que permite crecer sin miedo a abrir el propio producto al mundo. Porque usted lo va a abrir. Cada vez que publique.

La invitación

Haga un ejercicio simple esta semana. Pida a su equipo que busque contraseñas, claves y tokens en el código, en el historial del repositorio y en las aplicaciones publicadas. No para encontrar culpables. Para encontrar puertas abiertas.

Si la respuesta es “no tenemos nada de eso”, desconfíe con cariño y pida un escaneo automático. Si la respuesta es “tenemos algunas”, felicitaciones. Usted acaba de descubrirlo antes que el atacante.

Asuma que su código será leído. No por una persona. Por un agente, con paciencia infinita. Construya como si ya lo hubiera sido. Y deje los secretos donde pertenecen. En el servidor. Bajo control. Jamás en el código.

La mejor forma de prever el futuro es crearlo. Y ningún futuro digital se sostiene sobre una llave olvidada. ¿Cuánto de su producto todavía trata como caja fuerte, cuando ya es vitrina?