Cuando las skills de IA se convierten en dependencias de la cadena de suministro

Escrito por: Nubank Editorial, Lucas Palma y Paulo Martins

El desarrollo asistido por IA está cambiando más rápido que los modelos de seguridad construidos a su alrededor. La primera ola fue relativamente sencilla: los desarrolladores usaban grandes modelos de lenguaje para generar código, explicar funciones desconocidas o sugerir pruebas. Pero el flujo de trabajo del desarrollador se está volviendo más combinable, ya que los modelos y agentes ahora pueden equiparse con skills reutilizables, plugins, servidores MCP, reglas de agentes, manifiestos de herramientas, instrucciones de prompt y scripts de automatización local.

Estos componentes pueden no parecerse a los paquetes de software tradicionales, pero pueden influir en lo que hace un sistema de IA, qué herramientas invoca y cómo modifica el entorno de un desarrollador. En otras palabras, la cadena de suministro de software se está expandiendo más allá del código.

Ese cambio estuvo en el centro de un proyecto liderado por Paulo Martins, Lead Security Engineer. La experiencia del equipo fue compartida por Lucas Palma, Product Security Manager en Nubank, en la AI Engineer World’s Fair en San Francisco. En lugar de centrarse únicamente en la seguridad del código generado por IA, el equipo empezó a plantearse una pregunta más amplia: ¿qué ocurre cuando las instrucciones y capacidades que se dan a la IA se convierten ellas mismas en dependencias?

La respuesta llevó a un sistema de seguridad que revisó más de 2.000 skills de IA antes de que pudieran llegar a los desarrolladores y a una lección más amplia sobre cómo los controles de seguridad deben evolucionar a medida que la IA pasa a formar parte del toolchain de desarrollo.

Cuando las instrucciones empiezan a comportarse como dependencias

Una skill de IA puede entenderse como una capacidad empaquetada para un modelo o agente. Puede agrupar instrucciones, contexto, flujos de trabajo y archivos de apoyo, y puede describir qué herramientas o comandos deben usarse o cómo un sistema de IA debe interactuar con otros sistemas.

Una vez instalada o disponible para una herramienta de programación con IA, una skill puede influir en cómo los desarrolladores escriben, revisan o modifican código. Eso hace que las skills sean útiles precisamente porque son reutilizables.

Un equipo puede capturar un flujo de desarrollo útil una sola vez y ponerlo a disposición de muchos ingenieros. En lugar de explicar repetidamente cómo realizar una tarea, la organización puede codificar ese conocimiento en algo que un asistente de IA pueda usar directamente.

Pero la reutilización también cambia la ecuación de riesgo, ya que una instrucción problemática escrita para un solo desarrollador tiene un alcance limitado. Una skill problemática publicada en un marketplace interno puede volverse descubrible en múltiples equipos y proyectos, y el mismo mecanismo de distribución que hace que las buenas prácticas se difundan más rápido también puede amplificar los errores.

La exposición crece aún más al considerar skills de terceros o compartidas por la comunidad. Esto no es solo una preocupación teórica: ya se ha observado a actores maliciosos aprovechando plugins y skills maliciosas en campañas reales para inyectar instrucciones y comprometer entornos de desarrollo.

Por eso el equipo empezó a tratar las skills de IA y componentes similares como parte de la cadena de suministro de software. Pueden parecer configuración o documentación, pero su efecto operativo puede estar mucho más cerca del de una dependencia.

La velocidad y la seguridad tienen que coexistir

El desafío se vuelve especialmente visible en un entorno regulado. El desarrollo asistido por IA puede dar a los ingenieros mayor velocidad al programar, mejor contexto, menos trabajo repetitivo y flujos reutilizables. Al mismo tiempo, el sistema que lo rodea todavía debe proteger a los clientes y las credenciales, preservar la auditabilidad, evitar cambios no intencionados en producción y dejar clara la responsabilidad.

Una respuesta posible sería crear otro proceso de aprobación en torno a la IA: los desarrolladores usan las herramientas y luego Seguridad revisa lo que ocurrió. Pero ese modelo introduce fricción después del hecho y deja el momento de mayor riesgo — la distribución — relativamente abierto.

En cambio, el objetivo fue hacer que los controles operaran dentro del flujo de trabajo que los ingenieros ya utilizan. La seguridad debe estar presente cuando una skill se crea y se comparte, en lugar de convertirse en un punto de control externo que los desarrolladores encuentran más tarde.

Esa distinción importa. La velocidad de desarrollo y la seguridad no tienen que convertirse en objetivos en competencia si los controles se colocan en el punto correcto del sistema.

Instrucciones aparentemente inofensivas pueden impactar la producción

Una de las razones por las que las skills de IA exigen una mentalidad de seguridad distinta es que el comportamiento riesgoso puede estar oculto dentro de instrucciones que parecen razonables a primera vista.

Piensa en las credenciales. Una skill podría instruir a un agente a recuperar un token local para acceder a un servicio. Técnicamente, la tarea puede funcionar como se espera, pero recuperar el token puede hacer que la credencial entre en el contexto del modelo, exponiéndola potencialmente a través de logs u otra infraestructura involucrada en el procesamiento de la solicitud.

Otra skill podría contener un comando de shell capaz de modificar datos relacionados con producción. Sus instrucciones podrían indicar que el agente debe preguntar al desarrollador antes de ejecutar el comando.

Eso suena como una salvaguarda, pero la aprobación existe únicamente dentro del prompt. El modelo puede interpretar el contexto anterior como consentimiento, omitir la pausa esperada o, en la práctica, aprobar su propia acción.

Los permisos crean otra clase de riesgo. Una skill capaz de manipular tablas, grants o entradas de registro puede tener razones legítimas para hacerlo. Pero un acceso demasiado amplio significa que algo tan simple como información desactualizada o un error de tipeo puede tener consecuencias reales.

En esos casos, los diseños más seguros colocan la operación sensible detrás de una herramienta controlada por el host o de un servidor MCP, en lugar de dar al modelo autoridad ilimitada.

Ninguno de estos ejemplos requiere un autor de skills malintencionado. Un componente puede generar exposición de seguridad mientras hace exactamente lo que su autor pretendía.

Revisión antes de la distribución

A medida que el marketplace interno de Nubank facilitó que los ingenieros descubrieran skills, el equipo identificó el propio marketplace como un punto de control crítico.

La descubribilidad genera escala. Y la escala significa que un pequeño error puede convertirse en un comportamiento repetido en toda la organización. En lugar de revisar las skills después de que los desarrolladores ya habían empezado a usarlas, la seguridad necesitaba moverse antes en el proceso. El flujo resultante es:

Creador de la skill → Pull request → Skill Vetter → Marketplace → Desarrolladores

El desarrollador que crea o modifica una skill la envía mediante el proceso normal de pull request. Antes de que el componente esté disponible en el marketplace, un sistema automatizado llamado Skill Vetter lo evalúa y clasifica los riesgos potenciales.

Solo después de ese gate la skill puede pasar al directorio descubrible que usan los desarrolladores. Arquitectónicamente, esto cambia el rol del marketplace, que empieza a funcionar como parte del modelo de seguridad.

Cómo funciona Skill Vetter

El sistema combina distintas formas de análisis porque ninguna técnica aislada es suficiente para este problema. Los ingenieros pueden ejecutar el escáner localmente mientras crean una skill, obteniendo retroalimentación antes de enviarla. Una vez que una skill se agrega o modifica, CI ejecuta las verificaciones automáticamente como parte del pull request.

La primera capa usa detección determinista para patrones que pueden identificarse con una confianza relativamente alta. Eso incluye señales como comandos de shell destructivos, solicitudes de credenciales, rutas de archivos sensibles, uso de CLI con impacto en producción y otras construcciones riesgosas conocidas.

Otros problemas son más difíciles de identificar sin contexto. Para esos, el sistema también usa análisis basado en LLM para evaluar el comportamiento de la skill de forma más holística.

Un escáner determinista es adecuado para identificar algo explícito: una ruta sensible conocida, por ejemplo, o una clase específica de comando peligroso. Pero puede tener dificultades para determinar si una secuencia de instrucciones aparentemente ordinaria se vuelve riesgosa por el sistema al que apunta o por los permisos que asume.

Un LLM puede ayudar con esa segunda categoría porque puede interpretar las relaciones entre instrucciones, herramientas y comportamiento pretendido.

Los resultados se muestran directamente en el pull request. Los hallazgos también se convierten a SARIF — el formato estandarizado que usan los sistemas de code scanning — para que los desarrolladores puedan ver la retroalimentación de seguridad a través de herramientas familiares. Según la severidad y la política, la skill puede requerir remediación o ser bloqueada antes de llegar al marketplace.

La idea es combinar reglas predecibles con análisis contextual y entregar ambos mediante un flujo de trabajo que los ingenieros ya comprenden.

Lo que revelaron más de 2.000 skills

Ejecutar el sistema a escala produjo una visión más clara de lo que era útil y de lo que aún necesitaba ajustes. Entre más de 2.000 skills analizadas, el proceso identificó aproximadamente 1.600 riesgos potenciales. Alrededor de 1.000 problemas fueron remediados, mientras que unos 90 casos se clasificaron como revisiones prioritarias.

Los números fueron solo parte del resultado, ya que la lección más útil vino de comparar las señales producidas por distintos enfoques.

Los escáneres deterministas funcionaron bien para patrones de riesgo conocidos, incluidos comandos destructivos, manejo de credenciales y rutas sensibles. La revisión basada en LLM aportó valor donde entender el comportamiento general de una skill requería más contexto. La integración con SARIF y los comentarios directamente en los pull requests ayudaron a convertir los hallazgos en retroalimentación sobre la que los ingenieros podían actuar.

Pero el ejercicio también expuso fuentes de ruido: tratar todos los comandos como igualmente peligrosos no era útil. Tampoco lo eran las advertencias que no distinguían entre operaciones locales inofensivas y acciones capaces de afectar la producción. Señales débiles sin suficiente contexto podían producir hallazgos sin ayudar a los desarrolladores a entender qué debía cambiar realmente.

Para que una herramienta de seguridad se convierta en parte de un flujo de trabajo de ingeniería, la detección por sí sola no es suficiente. El sistema también debe explicar las consecuencias y señalar el camino hacia la remediación.

Un prompt no es una capa de autorización

Un hallazgo fue lo bastante importante para convertirse en un principio de diseño más amplio: pedirle al modelo que obtenga permiso no es lo mismo que imponer el permiso técnicamente.

Supongamos que una skill contiene una instrucción como pregunta antes de ejecutar este comando. Si el mismo modelo es responsable de decidir si existe el permiso y luego de ejecutar la operación, es en la práctica actor y aprobador a la vez. Ese no es un límite de seguridad confiable.

Un diseño más robusto mueve la operación peligrosa fuera del bucle de razonamiento del modelo. El agente puede solicitar la acción, pero un gate de aprobación controlado por el host determina si la herramienta realmente puede ejecutarse.

La presentación apunta a patrones como MCP u otras herramientas controladas por el host, hooks del estilo PreToolUse y aprobación humana explícita para operaciones sensibles.

La diferencia es arquitectónica más que lingüística: un prompt puede sugerir un comportamiento, pero un control fuera del modelo puede imponerlo.

Haz que el camino seguro sea el camino más fácil

La lección más amplia de Skill Vetter no es que cada componente de IA necesite otra revisión manual de seguridad. Es casi lo contrario.

Los componentes de IA reutilizables deben tratarse como parte de la cadena de suministro. Los desarrolladores deben poder ejecutar verificaciones localmente. Los mismos controles deben aplicarse automáticamente en CI. El análisis determinista debe encargarse de los patrones bien comprendidos, mientras que la revisión contextual debe reservarse para comportamientos que realmente requieren interpretación. Y las operaciones con impacto relevante en producción deben protegerse con controles técnicos fuera del propio prompt. Los siguientes problemas se derivan naturalmente de esa base.

El equipo está mirando más allá de las skills, hacia la cadena de suministro de agentes en un sentido más amplio, incluidos plugins, servidores MCP, reglas, hooks, comandos, agentes y manifiestos. La hoja de ruta también apunta a gates más fuertes respaldados por políticas, mayor aplicación a nivel de herramientas mediante aprobaciones, permisos con alcance definido, gateways confiables y registros de auditoría, y marketplaces donde los componentes de IA compartidos tengan dueño, versionado y revisión antes de su consumo.

A medida que la IA se integra más profundamente en el desarrollo de software, proteger únicamente el código que produce una IA no será suficiente. Los flujos de trabajo, las herramientas, los permisos y los componentes reutilizables que rodean al modelo también importan. Eso cambia dónde necesita operar la seguridad.

En lugar de añadir otra capa de aprobación después de la adopción, el objetivo es colocar salvaguardas en los puntos donde las capacidades de IA se crean, se revisan y se distribuyen, y exponer esas salvaguardas a través de los mismos sistemas de ingeniería que los desarrolladores ya utilizan.

El principio es hacer que el camino seguro sea el camino más fácil. La adopción de IA puede escalar de forma más sostenible cuando la seguridad forma parte del flujo de trabajo del desarrollador desde el principio, en lugar de ser algo añadido a su alrededor después.