La investigación de Wake Forest revela filtraciones generalizadas de credenciales en agentes de IA y apps para iOS

Dos investigaciones de la Universidad Wake Forest señalan una debilidad compartida por dos ecosistemas de IA que crecen con rapidez: las credenciales suelen quedar en lugares desde los que pueden recuperarlas un agente, una aplicación o un atacante. Un estudio examinó 17.022 habilidades de terceros para agentes y encontró 520 afectadas, con un total de 1.708 problemas de seguridad. Otro, centrado en 444 apps de iOS con funciones de modelos de lenguaje, detectó que 282 exponían credenciales o mecanismos de acceso a sus backends durante las pruebas. 124

El riesgo práctico va mucho más allá de que aparezca una cadena de texto en el código. Una clave o un token expuesto puede abrir el acceso a datos privados, capacidades de un agente o inferencias de modelos pagadas con la cuenta del desarrollador.

Qué encontró el estudio sobre las habilidades de agentes

Los investigadores seleccionaron 17.022 habilidades a partir de 170.226 artefactos disponibles en SkillsMP, un mercado abierto de habilidades para agentes. Combinaron detección estática de secretos, pruebas dinámicas en un entorno aislado con credenciales simuladas y comprobaciones para comparar el propósito declarado de cada habilidad con su comportamiento durante la ejecución. 34

El análisis identificó lo siguiente:

• 520 habilidades afectadas, con 1.708 problemas de seguridad agrupados en 10 patrones de filtración de credenciales. 416
• 466 de las 520 habilidades afectadas exponían credenciales utilizables sin privilegios elevados, lo que equivale a una tasa reportada de explotabilidad inmediata del 89,6 %. 14
• Un problema que cruza distintos formatos: en el 76,3 % de los casos de filtración fue necesario analizar tanto las instrucciones en lenguaje natural como el código.
• El 3,1 % de los casos se debió a inyección de instrucciones en lenguaje natural sin código ejecutable. 4

La conclusión es relevante: una revisión centrada únicamente en el código puede pasar por alto riesgos importantes. Una habilidad puede describir una tarea aparentemente legítima, mientras sus instrucciones o scripts de apoyo exponen secretos durante el uso normal.

Los registros de depuración pueden convertir secretos en datos legibles para el modelo

Los registros de depuración destacaron como una vía especialmente importante de filtración. En los marcos de trabajo para agentes que incorporan la salida estándar al contexto del modelo, una credencial mostrada mediante funciones como print o console.log puede quedar disponible ante una petición normal en lenguaje natural. El resumen del estudio identifica los registros de depuración como el principal vector y atribuye a la exposición de la salida ante los modelos de lenguaje el 73,5 % de las filtraciones. 4

El problema no se limita a las claves de API escritas de forma evidente en el código. Las credenciales también pueden filtrarse a través de scripts, variables de entorno, registros, instrucciones de los prompts o combinaciones de código y lenguaje que solo resultan peligrosas durante la ejecución habitual.

Tanto el desarrollo malicioso como la negligencia influyen

La investigación describe dos grandes causas de las filtraciones:

• Desarrollo malicioso: una habilidad incluye deliberadamente instrucciones o cargas diseñadas para recopilar credenciales o datos privados y, potencialmente, enviarlos a un servidor remoto.
• Desarrollo negligente: el desarrollador no aplica prácticas seguras y deja sin querer credenciales o rutas de acceso disponibles para los atacantes. 1

La diferencia importa a la hora de corregir el problema. El contenido malicioso exige detección, retirada y controles antes de su distribución; la exposición accidental requiere una gestión más segura de secretos, registros protegidos, controles de autenticación y pruebas previas a la publicación.

Después de que los investigadores avisaran a SkillsMP, Wake Forest informó de que se retiraron todas las habilidades identificadas como maliciosas y se corrigió la mayoría de las vulnerables. Sin embargo, el estudio advierte de que limpiar el repositorio original puede no ser suficiente: las copias derivadas —o forks— pueden conservar las credenciales expuestas incluso después de reparar la fuente. 14

El estudio de iOS encontró otra vía para secuestrar cuentas de modelos de lenguaje

La investigación relacionada sobre iOS examinó 444 aplicaciones con funciones de modelos de lenguaje y descubrió que 282 —aproximadamente el 64 %— exponían credenciales explotables de servicios de IA o mecanismos de acceso a sus backends en el tráfico de red. 25

Los patrones de exposición reportados fueron:

• Tokens basados en JWT que podían reutilizarse: 48 %
• Proxies backend sin autenticación: 33 %
• Transmisión de claves de API en texto plano: 19 % 3

Estas debilidades pueden observarse durante el uso normal de una app. Un atacante que capture una clave, reutilice un token o encuentre un proxy abierto podría enviar solicitudes a través de la cuenta de modelos de lenguaje del desarrollador. Eso puede consumir inferencia de pago, abusar de recursos asociados en la nube o generar cargos no autorizados. 25

Las pruebas respaldan la posibilidad de una exposición financiera grave o potencialmente ilimitada, según los límites de la cuenta y el tiempo que se prolongue la intrusión. No obstante, no demuestran por sí solas una cifra concreta de pérdidas, como “cientos de miles de dólares”.

La respuesta de los desarrolladores también fue lenta. Tres meses después de la divulgación responsable, solo el 28 % de las apps de iOS afectadas había corregido la vulnerabilidad comunicada; el 72 % seguía siendo explotable en el seguimiento del estudio. 311

Por qué importa en el desarrollo asistido por IA

En conjunto, los estudios muestran que añadir una función de IA o instalar una habilidad reutilizable para agentes puede ampliar la superficie de ataque de una aplicación. Entre los nuevos riesgos se encuentran:

• Claves de proveedores integradas en aplicaciones cliente o expuestas dentro del contexto de un agente.
• Herramientas con privilegios capaces de acceder a archivos, servicios o datos privados.
• Registros que, sin intención, pasan a formar parte del contexto que el modelo puede leer.
• Endpoints backend que aceptan solicitudes sin una autenticación adecuada.
• Tokens que los atacantes pueden reutilizar.
• Cargos por uso de modelos de lenguaje generados contra la cuenta del desarrollador.

La preocupación aumenta con el auge del llamado vibe coding, una forma de desarrollo asistido por IA en la que se genera y ensambla software con gran rapidez. La velocidad no sustituye al análisis de amenazas: la autenticación, la gestión de secretos, la autorización, los registros y la revisión de dependencias siguen requiriendo decisiones de ingeniería deliberadas.

El estudio sobre las habilidades de agentes también detectó indicios de desarrollo asistido por IA en el 72 % de los casos con credenciales codificadas de forma fija, lo que sugiere que ciertos patrones inseguros pueden propagarse mediante código generado o ensamblado con rapidez. 4

Prácticas de seguridad desde el diseño

Los resultados apuntan a una base defensiva para los equipos que desarrollan productos de IA o distribuyen habilidades para agentes:

1. Mantener las claves de proveedores de larga duración fuera de los dispositivos cliente y del contexto de los modelos. Las solicitudes sensibles a los modelos deben pasar por un servidor autenticado.
2. Utilizar credenciales de corta duración y alcance limitado. Aplicar el principio de mínimo privilegio y validar los tokens, en lugar de considerar que poseer uno basta para autorizar una operación.
3. Ocultar los secretos en los registros y en la salida estándar. Todo lo que se incorpore al contexto de un agente debe tratarse como potencialmente recuperable por el modelo o por un usuario.
4. Analizar el código, la configuración, los prompts y las dependencias en busca de secretos. Los resultados sobre agentes muestran por qué las instrucciones en lenguaje natural y el código ejecutable deben revisarse conjuntamente.
5. Probar el tráfico de red y la autorización del backend. Hay que comprobar que una solicitud interceptada no pueda reutilizarse ni redirigirse a través de un proxy sin autenticación.
6. Rotar las credenciales expuestas y revisar los forks y las copias. Eliminar un secreto del repositorio original no garantiza que todas las versiones distribuidas hayan sido limpiadas.
7. Incorporar revisiones de plataforma antes de la distribución. La evaluación de los mercados, las guías para desarrolladores, la divulgación responsable y los controles automatizados pueden complementar la atención individual de los equipos. 34

La lección central es sencilla: la seguridad de la IA no puede añadirse únicamente después del lanzamiento. Las credenciales, los permisos de los agentes, el contexto de los modelos y los controles de facturación deben considerarse elementos esenciales de la seguridad del producto desde el primer momento.