Fuga de credenciales en las skills de agentes LLM: un estudio sobre 17 000 skills

¿Qué es esto?

El 3 de abril de 2026, un equipo publicó en arXiv Credential Leakage in LLM Agent Skills: A Large-Scale Empirical Study, la primera medición a gran escala de cómo las «skills» de terceros filtran los secretos que se les confían. Una skill es un paquete de instrucciones en lenguaje natural junto con scripts que amplían las capacidades de un agente; suele ejecutarse en un entorno privilegiado, con acceso a claves de API, tokens y credenciales de bases de datos.

El estudio tomó una muestra de 17 022 skills (de 170 226 catalogadas en el mercado que los autores denominan SkillsMP, capturado a comienzos de 2026) combinando análisis estático, ejecución en sandbox e inspección manual. Identificó 520 skills vulnerables con 1 708 problemas distintos y derivó una taxonomía de 10 patrones de fuga: 4 accidentales y 6 adversarios. Es un trabajo de investigación defensivo, basado en la divulgación, no un kit de ataque: aquí no se reproduce ningún payload explotable.

Cómo funciona

El hallazgo central es que la fuga de credenciales en las skills es multimodal. Una skill es código y texto, y el 76,3 % de las fugas detectadas solo podía descubrirse analizando conjuntamente el script y sus instrucciones en lenguaje natural; una fracción menor, el 3,1 %, surgía únicamente de la inyección de prompt en el texto de instrucciones. Las herramientas que solo analizan el código fuente, o solo el prompt, pasan por alto la mayor parte de la superficie.

El vector más importante es trivial: el registro de depuración. Simples instrucciones print y console.log representan el 73,5 % de las fugas, porque la salida estándar de una skill se inyecta directamente en el contexto conversacional del agente. Un secreto escrito en stdout para depurar queda, de hecho, entregado al modelo, y a todo lo que, más adelante, pueda leer ese contexto.

Vía de fuga (conceptual)

  script de la skill  --imprime el secreto en stdout-->  contexto del modelo
                                                               |
                                          registros / memoria / transcripción
                                                               |
                                       legible por las herramientas posteriores

Las credenciales en juego cubren todo el espectro: claves de nube y de API (AWS, claves de cuenta de servicio de GCP en formato JSON, claves de terceros del tipo gsk-/AKIA), tokens OAuth y de plataforma, cadenas de conexión a bases de datos, contraseñas SMTP y de administración, material de claves privadas SSH/TLS, secretos de firma de webhooks e incluso claves de monederos de criptomonedas. Sobre todo, el 89,6 % de las credenciales filtradas era explotable sin ningún privilegio especial, y la exposición es persistente: secretos eliminados de un repositorio original sobrevivían en forks independientes que conservaban el material antiguo incluso tras corregir el original.

Por qué importa

Las skills se están convirtiendo en la forma predeterminada de ampliar los agentes, y un modelo de mercado implica que una persona desarrolladora instala código escrito por un desconocido, código que luego se ejecuta con sus propias credenciales. Este estudio convierte un riesgo largamente sospechado en una realidad medida, junto con trabajos paralelos de abril de 2026 sobre skills maliciosas en la naturaleza (revisado el 10 de junio de 2026) y sobre el envenenamiento de la cadena de suministro del ecosistema de skills.

Dos cifras deberían replantear los modelos de amenaza. Primero, el canal stdout-hacia-contexto es una vía de fuga de la que el escaneo de secretos clásico nunca tuvo que preocuparse: su escáner de secretos en CI no vigila lo que una herramienta imprime en tiempo de ejecución. Segundo, los forks conservan los secretos tras corregir el original, de modo que «rotamos y parcheamos el original» no es contención. La misma arquitectura que produce el fallo de seguridad funcional —una skill que imprime de más— es la que un atacante aprovecha como fallo de seguridad.

Defensas

Los autores proponen mitigaciones concretas y por capas. Para quienes operan agentes y escriben skills:

1. Trate stdout como salida no confiable, no como un registro privado. Todo lo que una skill imprime puede llegar al contexto del modelo. Filtre los patrones de credenciales reconocidos del flujo de stdout antes de que entre en la memoria conversacional, y nunca depure con secretos en claro.
2. Aplique el mínimo privilegio a nivel de arquitectura. Acote y minimice de antemano la exposición a credenciales de cada skill en lugar de sanear a posteriori. Una skill solo debe poseer el token más estrecho que necesite, durante el menor tiempo posible.
3. Aísle el motor de razonamiento del motor de ejecución. El artículo aboga por un aislamiento basado en capacidades —el LLM y la skill ejecutándose con memoria y acceso de red separados— para que una fuga en la ejecución no se convierta en una fuga en el contexto.
4. Haga del escaneo de secretos previo a la publicación una etapa obligatoria. Integre el escaneo de secretos en el ciclo de desarrollo de las skills como un paso requerido antes de publicar, no como un endurecimiento opcional. Tenga en cuenta que se necesita un escaneo conjunto de código y lenguaje para detectar la mayoría multimodal.
5. Rote las claves y considere los forks como comprometidos. Como los secretos persisten en los forks, rote cualquier credencial que alguna vez tocó una skill publicada y asuma que las copias en fork aún portan el valor antiguo. Retirarlo de main no basta.

Estado

Elemento	Referencia	Fecha	Notas
Estudio publicado	arXiv 2604.03070	2026-04-03	17 022 skills analizadas; 520 vulnerables; 1 708 problemas
Taxonomía de fugas	arXiv 2604.03070	2026-04-03	10 patrones (4 accidentales, 6 adversarios)
Vector dominante	arXiv 2604.03070	2026-04-03	Registro de depuración (print/console.log) = 73,5 % de las fugas
Explotabilidad	arXiv 2604.03070	2026-04-03	89,6 % explotable sin privilegios; persiste en los forks
Resultado de la divulgación	arXiv 2604.03070	2026-04	Skills maliciosas retiradas; 91,6 % de las credenciales en duro corregidas
Trabajo relacionado	arXiv 2602.06547	rev. 2026-06-10	Skills maliciosas medidas en dos registros

Para los equipos, la lección no es «las skills son inseguras», sino «las skills se ejecutan con sus credenciales, y sus supuestos actuales de gestión de secretos no las cubren». El canal de fuga es la propia ventana de contexto del modelo, la corrección debe residir en la arquitectura de las skills y en el pipeline de publicación, y es la rotación —no el borrado— lo que realmente contiene un secreto expuesto.