Una skill es código, y el código necesita un punto de control

Una skill es código, y el código necesita un punto de control

NVIDIA publicó esta semana como código abierto una herramienta llamada SkillSpector. Su tarea es acotada y llevaba tiempo pendiente: analizar skills de agentes de IA en busca de problemas de seguridad antes de que un agente las cargue. El proyecto incluye la detección de 64 patrones de vulnerabilidad, una cifra ante la que vale la pena detenerse, porque implica que alguien se sentó a enumerar las formas en que una skill puede salir mal.

En paralelo, Cloudflare publicó una skill de auditoría de seguridad que ejecuta auditorías en varias fases sobre una base de código y emite hallazgos legibles por máquina, y GitHub detalló un clasificador de detección de secretos sensible al contexto que elevó un 11,5 % la aceptación ponderada de hallazgos reales y redujo un 86 % el tiempo medio de análisis. Tres equipos distintos, tres ángulos distintos, la misma conclusión: la capa donde los agentes reciben sus instrucciones se ha vuelto infraestructura, y la infraestructura se audita.

Qué es realmente una skill

La palabra "skill" hace que todo parezca más blando de lo que es. Una skill no es una opción de configuración. Es un conjunto de instrucciones y, muy a menudo, de scripts, plantillas y definiciones de herramientas que un agente leerá y seguirá con los permisos que se le hayan concedido.

Esa última frase resume el modelo de seguridad en una oración. Una skill no necesita un exploit, porque no está entrando a la fuerza. Se la invita a entrar, se le entregan las llaves y se le pide ayuda. Si sus instrucciones son maliciosas o simplemente descuidadas, el agente actuará según ellas como si fueran tu propia intención, porque hasta donde puede distinguir, lo son.

Es el mismo problema que los gestores de paquetes enfrentaron hace décadas, y se resolvió de la misma manera: dando por supuesto que la cadena de suministro es hostil y colocando puntos de control en ella. El ecosistema de agentes está al principio de ese proceso, y por eso un proyecto como SkillSpector importa mucho más de lo que sugiere su número de estrellas.

Por qué 64 patrones es la cifra interesante

Una lista de 64 patrones de vulnerabilidad es una taxonomía, y las taxonomías son la forma en que madura un campo. Antes de tener una, cada incidente es una sorpresa. Después de tenerla, los incidentes se vuelven instancias de clases conocidas, lo que significa que se pueden probar, seguir y, con el tiempo, eliminar por diseño.

Algunas de esas clases resultan familiares en el software común: comandos de shell inseguros, entradas sin validar, credenciales escritas en archivos que nunca deberían contenerlas. Otras son propias de esta nueva capa. Instrucciones que amplían el alcance del agente sin decirlo. Prompts que atraen contenido no confiable y lo tratan como un comando. Descripciones de herramientas que tergiversan lo que hace una herramienta, de modo que el agente la llama por el motivo equivocado. Skills que encadenan otras skills en un camino que nadie pretendía.

En esa última categoría está la dificultad. Una skill es peligrosa exactamente en proporción a cuánto puede alcanzar, y los agentes modernos pueden alcanzar mucho: el sistema de archivos, la red, otros agentes, las herramientas que registró otra skill. El radio de impacto de una skill mala no es la skill. Es todo lo que el agente puede tocar, un blanco móvil que depende de qué otras skills se cargaron primero.

El problema del contexto envenenado

Lo incómodo de la seguridad de agentes es que la frontera entre datos e instrucciones no la impone nada. Un modelo lee texto. No sabe por naturaleza qué frases son hechos a considerar y cuáles son órdenes a obedecer.

Así que una skill que descarga una página web, lee un gestor de incidencias o resume un correo está exponiendo al agente a texto que puede contener instrucciones. Si el modelo las sigue, no hay exploit en ningún sentido tradicional. Solo hay un sistema que hizo lo que le dijo algo en lo que no debería haber confiado.

Por eso el análisis debe ocurrir en el momento de la carga y no en el del incidente. Una vez que una skill se ejecuta dentro de un agente con permisos amplios, la pregunta interesante ya ha recibido una mala respuesta. El punto de control debe ir primero, y debe ser automático, porque la revisión humana de cada skill de un registro no escala y nunca lo hará.

La auditoría se está volviendo un producto

El lanzamiento de Cloudflare apunta a una segunda tendencia. Su skill de auditoría produce hallazgos legibles por máquina en lugar de una lista que alguien tiene que leer. Esa frase hace un trabajo real. Los hallazgos que un humano debe leer son hallazgos que un humano ojeará. Los hallazgos que una canalización puede consumir pueden convertirse en tickets, fusiones bloqueadas o despliegues rechazados sin que nadie tenga que acordarse de mirar.

El trabajo de GitHub sobre detección de secretos encaja en el mismo patrón. La filtración de secretos escala con cuánto código se produce, y la producción de código ha subido con fuerza. La respuesta no fue "contratar más revisores". Fue un clasificador sensible al contexto que recorta el ruido, para que las alertas que la gente sí ve tengan más probabilidades de ser reales. La precisión, en las herramientas de seguridad, determina si alguien sigue leyendo las alertas después del tercer mes.

Ambas son el mismo movimiento hecho en capas distintas. En lugar de pedir a los humanos más vigilancia, se hace que la comprobación automática sea lo bastante buena para que la atención humana solo se gaste donde puede importar. Es la única estrategia que sobrevive al contacto con el volumen.

La cuestión de gobernanza de fondo

Hay aquí una capa de políticas que avanza más rápido de lo que la mayoría de los equipos cree. Los sistemas de control de versiones empiezan a llevar metadatos de procedencia. Los registros de paquetes añaden atestación. Los organismos de normalización trabajan en cómo etiquetar contenido sintético y cómo identificar a un agente. La dirección del viaje apunta a un mundo donde el origen y la integridad de un artefacto deben ser demostrables, no supuestos.

Las skills ocupan un lugar incómodo en ese mundo, porque la misma skill puede ser útil y peligrosa según el contexto. Una skill capaz de modificar archivos es esencial para un agente de programación y catastrófica para un agente que además lee correos no confiables. La decisión de confianza no es una propiedad de la skill por sí sola. Es una propiedad de la skill más el entorno más las otras skills que puede alcanzar.

Lo que sugiere que los analizadores acabarán necesitando hacer más que coincidencia de patrones. La versión realmente difícil de esta herramienta comprueba si una combinación propuesta de skills concede una capacidad que nadie pidió, y avisa antes de publicarla y no después.

Qué deberían hacer los equipos ahora, sin reaccionar de más

El pánico no es la respuesta correcta, y tratarlo como problema de otro tampoco.

Los movimientos prácticos son poco glamurosos. Trata las skills de terceros como dependencias no confiables, porque eso son exactamente. Fija las versiones y revisa los diffs cuando cambien. Ejecuta agentes en entornos donde el radio de impacto esté acotado, para que una skill mala no pueda alcanzar la red o la base de datos de producción solo porque el agente resultaba cómodo. Registra qué skills se cargaron y qué hicieron, porque la primera pregunta difícil tras cualquier incidente es qué se permitió ejecutar.

La industria ya recorrió este camino. Los ecosistemas de paquetes eran inseguros, luego se volvieron tediosos de atacar, y lo tedioso es justo el punto. Las skills de agentes van hacia el mismo equilibrio, y los proyectos publicados esta semana son el primer intento serio de construir el punto de control. Llegar antes del incidente es más barato que llegar después, y lo único necesario para llegar pronto es la disposición a ser aburrido al respecto.