Artefactos de skills de agentes: revisar el archivo que una skill entrega a la siguiente

Las salidas de las skills se convierten en entradas de trabajo posterior¶

Las skills de agentes empaquetan instrucciones, scripts y recursos para reutilizarlos. Sus salidas pueden convertirse en entradas de trabajo posterior. Un resumen, una hoja de cálculo o una base de datos local pueden trasladar un error anterior a una decisión posterior, incluso después de que haya terminado la conversación que los produjo. Nuestra nota anterior sobre políticas en la memoria del agente examinó resúmenes de políticas almacenados. Esta nota examina productos de trabajo generados que un paso posterior trata como evidencia.

SkillRelay, un preprint de Liao et al. enviado el 9 de octubre de 2026, estudia esa persistencia entre sesiones separadas. En su modelo de amenazas, el atacante controla varias skills antes de la ejecución; las tareas de los usuarios y las políticas de proyecto de confianza quedan fuera de su control. Los autores distinguen un resultado dañino de una cadena de ataque completa a través del traspaso previsto. Leer el artículo (v1).

La defensa del artículo combina la procedencia con la revisión de las operaciones propuestas. La revisión es obligatoria y consultiva: tras una recomendación desfavorable, el agente puede confirmar igualmente la solicitud revisada. Son resultados de un benchmark controlado, y el artículo no estima con qué frecuencia se enfrentan las organizaciones a esta amenaza. No hemos reproducido sus resultados. Este artículo omite sus tasas de ataque y de defensa; quien las utilice debe comprobar cada denominador en el artículo.

La declaración de cobertura indica lo que la revisión deja fuera¶

El detalle de implementación más útil está en el código publicado. En el commit fijado, las líneas 57 a 66 del archivo run.py del componente de protección (guard) construyen una declaración de cobertura que enumera las operaciones que revisa el prototipo y los efectos que deja fuera de esa revisión. Un archivo coverage.json registra ese límite para cada ejecución protegida. Declaración de cobertura fijada.

La implementación declara otros límites: la procedencia se registra por etapa, la mediación de red es incompleta y un hash calculado después de una lectura no puede mostrar qué bytes se leyeron mientras otro proceso escribía. Son límites del prototipo que los autores declaran abiertamente. Leímos el código fuente como texto y no pusimos a prueba la cobertura en tiempo de ejecución.

Una declaración así merece atención porque un mismo flujo de trabajo puede llegar al mismo resultado con consecuencias por varias vías. Un paquete de evidencia puede publicarse mediante una API, exportarse a un directorio compartido o componerse a partir de una base de datos que lee otro servicio. Revisar la solicitud a la API cubre una vía. Una revisión de arquitectura tiene que rastrear las demás antes de describir el flujo de trabajo completo como revisado.

• Revisado: el envío a través del adaptador del prototipo, con una comprobación de respaldo en el servicio receptor.
• Fuera de la revisión de operaciones: cambios arbitrarios en archivos locales.
• Fuera de la revisión de operaciones: publicación en una base de datos SQLite local.
• Fuera de la revisión de operaciones: tráfico hacia la pasarela del modelo.

Lo que comprobamos en el artefacto publicado¶

Inspeccionamos el repositorio en el commit f7fa742 (8 de octubre de 2026) como datos. Analizamos el catálogo del benchmark completo y el árbol de Git sin truncar mediante dos solicitudes de solo lectura a la API de GitHub, y cotejamos con el árbol cada ruta de configuración que referencia el catálogo.

Esto confirma una propiedad estructural limitada de la versión publicada: el catálogo es coherente internamente y los archivos que referencia están presentes. No ejecutamos el benchmark, no instalamos sus skills en ningún contexto de agente ni reprodujimos sus resultados de seguridad. La presencia de una ruta no dice nada sobre el contenido del archivo, de modo que no demuestra que las entradas benignas lo sean. Los recuentos describen el diseño del benchmark y no tienen ningún significado en términos de rendimiento.

Mantenga separados la producción, el respaldo y la autorización¶

Volvamos al ejemplo del proveedor y demos al traspaso dos registros. El primero describe la producción: la tarea que generó el archivo, la versión del productor, el digest del artefacto y las referencias de origen. El segundo describe la decisión de recepción: la tarea actual, el destinatario previsto, el contenido saliente exacto, las afirmaciones que deben verificarse y la persona o regla responsable de la autorización.

Estos registros responden a preguntas distintas. Un digest intacto vincula una revisión a unos bytes concretos. Una referencia de origen apunta hacia el material de respaldo. Una declaración de que un revisor aprobó algo necesita su propio registro de decisión y su propio alcance. Ninguno de esos campos debe sustituir a otro de forma implícita. Un manifiesto de apariencia completa puede describir aun así una conclusión sin respaldo.

Un revisor también debe poder ver tanto el archivo como la operación a la que dio lugar. Registre qué fuentes originales se comprobaron, qué solicitud concreta se revisó, si la solicitud cambió después y qué interfaz produjo realmente el efecto. Una persona que revisa una decisión sobre un proveedor debe poder seguir esa cadena sin reconstruirla a partir de un resumen bien presentado.

Un registro de revisión para el traspaso¶

El registro de revisión del traspaso entre skills (en inglés) convierte esas preguntas en campos. Es una hoja de trabajo ilustrativa para un flujo de trabajo sintético y no se ha evaluado como control de seguridad. Adáptelo al sistema que es responsable de la decisión y que realiza la acción.

Mantenga los registros de revisión y de autorización fuera del control del productor cuando el modelo de confianza del sistema lo exija. Un campo rellenado por el productor que afirme una aprobación debe contrastarse con la autoridad responsable de esa decisión. Para cada efecto, identifique todas las vías que puede usar el flujo de trabajo: llamadas a API, exportaciones a directorios compartidos y cambios en bases de datos que lee otro proceso. Registre el límite de revisión real y la evidencia de que se aplicó a esa solicitud. Marque como no verificadas las vías que carezcan de esa evidencia.

Tres casos sintéticos para probar un traspaso¶

Una primera investigación puede ser pequeña. Elija un traspaso recurrente y una acción con consecuencias, identifique todas las vías que van del archivo a ese efecto y ejecute tres casos sintéticos con registros de origen fijos y un receptor local. Conserve los materiales originales, el archivo generado, la solicitud saliente exacta, el resultado de la revisión y el efecto observado.

Cuente por separado las finalizaciones legítimas, las afirmaciones sin respaldo aceptadas, los intentos de divulgación fuera del alcance, los efectos que eludieron la revisión y los errores de ejecución. Registre los errores como errores. El comportamiento esperado de la tabla es un criterio de evaluación propuesto. No hemos realizado este ejercicio, por lo que no respalda ninguna tasa de protección.

Investigación relacionada sobre skills¶

Varios artículos recientes examinan las skills desde otros ángulos. Cada uno estudia una unidad de revisión distinta: un paquete, una cadena de paquetes o un uso posterior de su salida.

• SkillCascade (Zhu et al., v1, 24 de septiembre de 2026) examina interacciones dañinas entre skills instaladas conjuntamente, incluidos casos que superan los análisis de cada skill por separado. Estudia la composición dentro de un flujo de trabajo; SkillRelay estudia artefactos conservados entre sesiones. Los autores reconocen que los entornos aislados controlados no pueden establecer la incidencia real, y analizan los límites de usar un modelo para juzgar los resultados. SkillCascade v1.
• Counterfactual Trace Auditing (Zhou et al., v2 revisada el 28 de mayo de 2026, publicada por primera vez el 12 de mayo) compara tareas emparejadas con y sin una skill y registra las diferencias de comportamiento. Cada condición se ejecuta una vez, con un modelo y un benchmark, por lo que los autores limitan su lectura causal. La idea trasladable a una prueba de traspaso es comparar lecturas, escrituras y operaciones además de la finalización. Counterfactual Trace Auditing v2.
• Security skills for Linux vulnerability detection (Xue et al., v1, 19 de octubre de 2026) evalúa skills de seguridad seleccionadas en el análisis del kernel de Linux guiado por archivos. No estudia traspasos maliciosos, y sus tasas de detección no son trasladables a traspasos de documentos. Artículo v1.
• ACES (Kevin et al., v1, 20 de agosto de 2026) propone una evaluación en vivo emparejada con y sin una skill, y SkillEval (Han et al., v2 revisada el 12 de octubre de 2026, publicada por primera vez el 7 de agosto) puntúa propiedades de los documentos de skills. Solo leímos sus resúmenes e introducciones. ACES v1, SkillEval v2.

Dónde vuelve a comprobar KLA una acción aprobada¶

Para los agentes que actúan a través de la entrada de acciones de agente de KLA (agent action ingress), el KLA Policy Engine evalúa cada acción propuesta, y un resultado require_approval crea una Decision Request. Cuando la acción aprobada se reanuda, KLA compara sus argumentos con el hash sellado en el momento de solicitar la aprobación. Si los argumentos han cambiado, la acción se bloquea con el código de motivo tool_args_mismatch y no se ejecuta. Para las acciones enviadas a través de esa entrada, la comprobación responde a la pregunta del registro sobre «si la solicitud cambió después». Un archivo que un agente escribe directamente en un directorio compartido es una vía distinta y necesita su propia fila en el registro.

La investigación de este artículo no evaluó KLA. La guía de supervisión humana explica cuándo una acción debe requerir aprobación y cómo la registra el flujo de trabajo creador-verificador.