La aplicación nunca se abrió
Los agentic harness cambian lo que un LLM puede hacer en las pruebas de seguridad de aplicaciones móviles. Por sí solo, un modelo puede nombrar riesgos probables como almacenamiento inseguro, secretos expuestos, permisos de riesgo, SDK vulnerables, problemas de backend y exposición de la privacidad, pero la aplicación puede quedar sin tocar. Con las herramientas, el contexto, la memoria, los prompts, los bucles de ejecución y la retroalimentación en tiempo de ejecución adecuados a su alrededor, el modelo puede inspeccionar el paquete de la aplicación, observar su comportamiento, seguir el tráfico, conectar señales y dejar evidencias que un equipo de seguridad pueda revisar. Del análisis de permisos a la explotación nativa con GEF, la diferencia se ve en la traza: evidencias de la aplicación, salida de las herramientas, pruebas en tiempo de ejecución y pasos reproducibles en lugar de texto con forma de informe.
Por qué los agentic harness son cada vez más críticos para las pruebas reales de seguridad móvil
Entregue una aplicación móvil a un modelo de lenguaje y pídale que pruebe su seguridad.
La respuesta puede resultar familiar: almacenamiento inseguro, criptografía débil, secretos expuestos, permisos excesivos, SDK vulnerables, problemas de backend, fallos de autenticación, riesgos de privacidad.
Puede estar estructurada como un informe. Puede citar las categorías correctas. Puede leerse como algo que un equipo de seguridad podría hacer circular.
La aplicación sigue sin haberse abierto.
No se inspeccionó ningún paquete. No se comprobó ningún permiso frente al comportamiento en tiempo de ejecución. No se observó ningún tráfico de SDK. No se revisó ninguna ubicación de almacenamiento. No se siguió ninguna llamada al backend. No se capturó ningún estado de fallo. No se entregó ninguna evidencia.
El informe existía. El objetivo no había cambiado de estado.
Un motor de razonamiento sin manos
La mayoría de las conversaciones sobre IA en seguridad siguen empezando por el modelo: cuál es más inteligente, cuál razona mejor, cuál tiene la ventana de contexto más larga, cuál obtiene mejores resultados en los benchmarks.
En un flujo de trabajo de seguridad real, el modelo es solo una parte del sistema.
Un modelo en bruto puede entender instrucciones, generar hipótesis, describir rutas de ataque y decidir qué debe ocurrir a continuación. Pero probar un objetivo exige entrar en contacto con él. Hay que desempaquetar la aplicación. Hay que revisar los permisos. Hay que identificar los SDK. Hay que inspeccionar el almacenamiento. Hay que observar el tráfico. Hay que probar los flujos de autenticación. Hay que seguir las llamadas al backend. Hay que descartar las pistas ruidosas. Los hallazgos que sobreviven deben estar respaldados por algo más duradero que un párrafo.
Alrededor del modelo están las herramientas, el contexto, los prompts, las skills, la memoria, los bucles de ejecución y la retroalimentación que permiten que esos pasos ocurran.
Cuando el modelo puede tocar la aplicación
Un modelo ve «almacenamiento de datos sensibles» y puede describir qué hay que comprobar: shared preferences, bases de datos locales, archivos de caché, uso del keychain, cifrado, logs. Las palabras son correctas. La aplicación sigue siendo una caja negra.
En un flujo de trabajo con harness, la aplicación se desempaqueta. Se inspeccionan las ubicaciones de almacenamiento. Se abren los archivos de configuración. Se observa el comportamiento en tiempo de ejecución. Un valor aparece en disco o no aparece. Una sospecha recoge evidencias o se desvanece.
Lo mismo ocurre con los SDK.
Un modelo puede advertir de que los SDK de terceros pueden introducir exposición de la privacidad. La advertencia es lo bastante conocida como para sonar útil. Pero el SDK no se ha identificado. No se han observado sus destinos de red. No se han comparado sus permisos con el tráfico real. No se ha inspeccionado ningún payload.
Entonces la pregunta cambia. Ya no es «¿podría esto ser un riesgo?». Pasa a ser: qué hay presente, qué se ejecuta, qué sale de la aplicación y qué evidencia lo respalda.
Anthropic ha mostrado el mismo patrón en trabajos de agentes de larga duración: el modelo no mejoró de forma aislada. También cambió el flujo de trabajo que lo rodeaba: prompts, herramientas, gestión del contexto, bucles de retroalimentación. Los textos de OpenAI sobre harness engineering apuntan al mismo tipo de trabajo alrededor de los agentes: criterios de aceptación, validación, herramientas que faltan, salvaguardas, documentación.
Esos ejemplos tratan de ingeniería de software. En la seguridad móvil, el mismo patrón aparece alrededor del artefacto, el tiempo de ejecución, la salida de las herramientas y la siguiente prueba que el modelo es capaz de ejecutar.
Una respuesta pulida puede dejar la aplicación sin tocar.
Una caja de herramientas no es un harness
Existe una versión perezosa de la seguridad agéntica: darle al modelo un montón de herramientas y llamarlo agente.
Entra demasiada salida en bruto en el contexto. Hay demasiadas herramientas disponibles demasiado pronto. Los resultados del escáner llegan sin suficiente interpretación. Las señales débiles se convierten en hallazgos con aire de seguridad. Una cadena sospechosa se convierte en un secreto. Un permiso se convierte en una violación de la privacidad. Un endpoint inusual se convierte en un problema de backend explotable.
Un harness útil es más discreto. Decide qué ve primero el modelo, qué herramientas corresponden al siguiente paso, qué debe recordarse y qué nivel de evidencia se exige para que algo se convierta en hallazgo.
En la seguridad móvil, casi toda señal necesita ese contexto. Un permiso no es automáticamente un problema de privacidad. Un SDK de terceros no es automáticamente malicioso. Un valor almacenado no es automáticamente sensible. Una solicitud sospechosa no es automáticamente explotable.
Un permiso no es un hallazgo
Tomemos el acceso a la ubicación.
Un modelo puede explicar por qué el acceso a la ubicación puede crear un riesgo de privacidad. Es un contexto útil. No es un hallazgo.
Hay que comprobar el permiso en tiempo de ejecución. Hay que identificar los SDK. Hay que observar el tráfico. Hay que revisar los dominios de destino. Hay que inspeccionar los payloads. Hay que comparar la finalidad declarada de la aplicación con lo que la aplicación realmente envía.
Solo entonces la pregunta resulta útil.
¿Cuándo se recopila la ubicación? ¿Qué componente la recopila? ¿Adónde va? ¿Se envía junto con identificadores? ¿Está vinculada a un SDK de analítica, a un SDK publicitario, a un endpoint del backend o a una funcionalidad que el usuario realmente activó?
Desde fuera, la aplicación parecía una sola cosa. Bajo inspección, se convierte en capas: código, permisos, SDK, almacenamiento, tráfico, llamadas al backend y comportamiento de la plataforma.
La categoría era visible desde el principio. El hallazgo solo aparece cuando la evidencia se mueve.
GEF hace tangible el harness
El mismo patrón se ve con más facilidad en la explotación nativa.
Un LLM de propósito general puede describir los pasos: aplicar ingeniería inversa a la biblioteca nativa, inspeccionar la aritmética insegura, construir un disparador del fallo, observar los registros, refinar una primitiva. La metodología puede ser correcta mientras el objetivo permanece intacto.
En un caso de JNI en Android, el modelo estaba conectado a GEF, una herramienta de explotación construida sobre GDB.
El agente aplicó ingeniería inversa a la biblioteca nativa y encontró un truncamiento de entero de 64 a 32 bits en un cálculo del tamaño de una imagen. El valor truncado controlaba el tamaño de la asignación de memoria en el heap. El valor original de 64 bits controlaba la longitud de la copia.
La asignación era menor que la copia.
Se elaboró una entrada. El fallo se reprodujo. Un puntero a función indirecto se sobrescribió con un marcador reconocible de 64 bits. El marcador apareció en el estado del fallo.
La primitiva se refinó hasta convertirla en una llamada controlada a una función nativa con un primer argumento controlado por el atacante. La ejecución se redirigió al cargador de bibliotecas nativas de Android. Una biblioteca compartida creada a propósito se ejecutó dentro del proceso de la aplicación.
Los logs mostraron la ejecución. La rutina de inicialización de la biblioteca creó artefactos de prueba.
La ruta no se detuvo en «posible desbordamiento de heap». Avanzó a través del objetivo: cálculo, asignación, fallo, control, primitiva de llamada, cargador, ejecución, prueba.
El modelo aportó el razonamiento. GEF mantuvo ese razonamiento unido al proceso en ejecución.
El trabajo tiene que poder revisarse
En cuanto un agente puede actuar, aparece otra pregunta.
¿Qué inspeccionó? ¿Qué salida de herramienta cambió la conclusión? ¿Qué evidencia se recopiló? ¿Qué suposiciones se hicieron? ¿Dónde se detuvo la investigación?
En la seguridad ofensiva y en las pruebas móviles, un hallazgo solo es útil si alguien puede entender cómo llegó el sistema a él. Si un agente informa de una exposición de datos sensibles, el revisor necesita la ruta: el comportamiento de la aplicación, la ubicación de almacenamiento o la solicitud, el payload, los datos afectados y el razonamiento que conecta la evidencia con el hallazgo.
Si el agente decide no informar de algo, esa decisión también necesita una ruta. Quizá el permiso estaba declarado pero nunca se usó. Quizá el SDK estaba presente pero inactivo. Quizá el endpoint parecía inusual pero no exponía ningún comportamiento sensible.
Lo mismo se aplica a la explotación. Si el agente afirma que hay ejecución de código, el revisor no debería quedarse con una frase que dice «la explotación tuvo éxito». La cadena de evidencias debería ser visible, desde el cálculo vulnerable hasta la prueba en tiempo de ejecución.
Sin esa visibilidad, el resultado resulta difícil de defender. Puede ser correcto, pero el equipo no tiene rastro. Puede ser erróneo, pero aun así puede llegar con suficiente fluidez como para parecer convincente.
Un harness registra lo que ocurrió: permisos, límites de las herramientas, puntos de aprobación, logs de evidencias, pasos reproducibles y condiciones de parada.
El agente investiga. El equipo sigue necesitando ver la investigación.
De texto con forma de informe a pruebas defendibles
El modelo ya no se limita a enumerar lo que debería comprobarse. Trabaja con evidencias de la aplicación, salidas de herramientas, comportamiento en tiempo de ejecución, tráfico, señales de dependencias, trazas de explotación y pasos reproducibles. El resultado de un paso cambia el siguiente.
El resultado también cambia de forma. En lugar de una lista de comprobación más pulida, hay un recorrido por el objetivo. En lugar de un párrafo plausible, hay artefactos que un revisor puede inspeccionar. En lugar de «esto puede ser un riesgo», hay una cadena que puede cuestionarse.
Un equipo de seguridad puede abrir el artefacto. Seguir la traza. Reproducir los pasos. Inspeccionar la prueba en tiempo de ejecución.
No un modelo que suena como un pentester.
Una traza que puede sobrevivir a uno.