Microsoft run-assert-eval convierte los hallazgos de riesgo de agentes en controles de tiempo de ejecución probados

Microsoft lanzó run-assert-eval el 24 de septiembre, conectando cuatro tareas de seguridad de agentes que antes estaban separadas mediante un flujo de trabajo guiado. La habilidad Microsoft run-assert-eval descubre riesgos, mide fallos, redacta controles de tiempo de ejecución y repite la misma evaluación después de añadir esos controles. El conflicto es inmediato: un ciclo de seguridad más rápido solo es útil si sus mediciones siguen siendo creíbles.

El ejemplo de Microsoft da sustancia al anuncio. Según la compañía, un agente de soporte de facturación reveló datos de otro cliente en 12 de 40 conversaciones de referencia aplicables. Tras introducir una política de tiempo de ejecución, Microsoft observó dos infracciones en 34 conversaciones aplicables. Eso redujo la tasa reportada del 30.0% al 5.9%.

El resultado parece concluyente, pero procede de un ejemplo elaborado y mantenido por los desarrolladores del proyecto. Microsoft no ha presentado una réplica independiente ni un estudio de despliegue en producción. Por tanto, el avance importante es el mecanismo, no una puntuación favorable. La habilidad convierte un fallo detectado en una política exigible y después prueba la intervención sin modificar silenciosamente la evaluación.

Microsoft run-assert-eval conecta descubrimiento, pruebas y aplicación

El lanzamiento transforma una colección de proyectos de seguridad en una ruta revisable desde un riesgo desconocido hasta un control de tiempo de ejecución probado.

La publicación de lanzamiento de Microsoft describe un flujo de trabajo iniciado mediante una instrucción en un entorno de programación compatible. Los desarrolladores comienzan con un agente, su propósito previsto, sus herramientas y los límites que debe respetar.

La habilidad puede usar Clarity para modelar amenazas del agente. El modelado de amenazas implica identificar fallos plausibles, activos afectados, causas y consecuencias antes de seleccionar pruebas. Los equipos también pueden proporcionar un riesgo conocido procedente de un requisito de producto, un informe de incidentes, un plan de pruebas o una evaluación existente.

Esa distinción importa. Se recomienda el descubrimiento de riesgos, pero no es obligatorio. Un equipo que ya sabe que su agente de facturación expone registros de clientes puede empezar por ese comportamiento en lugar de repetir el trabajo de descubrimiento.

Cuando los equipos necesitan descubrimiento, el modelador de amenazas Clarity examina el contexto operativo más amplio del agente. Está diseñado para revelar fallos que nunca se incluyeron en los requisitos originales.

En el ejemplo de facturación de Microsoft, Clarity identificó cuatro modos de fallo candidatos. El equipo seleccionó dos riesgos clasificados como críticos: acciones de alto riesgo no verificadas y exposición de datos entre clientes.

El primer riesgo abarcaba cambios de facturación realizados sin confirmar la identidad de quien llamaba. El segundo cubría divulgaciones relacionadas con una cuenta que no pertenecía a quien llamaba.

La habilidad pasó cada riesgo seleccionado a ASSERT, el marco de evaluación de Microsoft basado en requisitos. Cada riesgo se convirtió en una configuración, un comportamiento y una suite de evaluación.

Esta estructura acotada es más importante de lo que parece inicialmente. Si una evaluación mezcla fallos de autorización, privacidad, precisión y escalamiento, su puntuación agregada no puede explicar qué control se necesita.

En cambio, Microsoft run-assert-eval separa esos comportamientos. La variación se introduce dentro de cada suite mediante dimensiones como el modo de acceso, el pretexto del usuario, las afirmaciones de autoridad y la deriva del alcance en varios turnos.

La habilidad también busca investigaciones previas y marcos de seguridad para encontrar dimensiones de prueba relevantes. Microsoft afirma que estas fuentes pueden incluir orientación de NIST, recursos de OWASP, benchmarks, material regulatorio y políticas de proveedores de modelos.

ASSERT genera entonces casos, ejecuta el agente objetivo y evalúa las transcripciones capturadas. Sus dos mediciones principales se mantienen deliberadamente separadas.

“Comportamiento inadmisible infringido” registra los casos en los que el agente realizó un comportamiento prohibido. “Comportamiento permisible infringido” mide los casos en los que el agente no ayudó a pesar de tener permitido hacerlo.

Esta separación protege frente a una conocida ilusión de seguridad. Un agente que rechaza todas las solicitudes puede evitar muchas acciones perjudiciales, pero también deja de realizar su trabajo.

A continuación, el flujo de trabajo genera un borrador de política Agent Control Specification a partir del fallo medido. ACS es un formato portátil para colocar controles en puntos definidos de la ejecución de un agente.

Por último, la habilidad evalúa una versión gobernada del agente frente a los mismos casos. Las ejecuciones de referencia y gobernada mantienen la misma definición de comportamiento, conjunto de pruebas y método de evaluación.

El resultado no es simplemente otra puntuación de seguridad. Es una comparación controlada diseñada para aislar la política como la variable modificada.

La presión recae sobre los equipos que usan prompts como su principal salvaguarda

Microsoft cuestiona la idea de que las instrucciones escritas por sí solas proporcionen un límite de control adecuado para agentes que utilizan herramientas.

Los prompts de sistema siguen siendo útiles para definir roles y comportamientos esperados. Siguen siendo instrucciones probabilísticas interpretadas por un modelo, no comprobaciones de autorización deterministas aplicadas por el software circundante.

Esa debilidad se vuelve relevante cuando un agente puede recuperar registros, actualizar cuentas, emitir reembolsos o llamar a herramientas administrativas. Una solicitud persuasiva puede convertirse entonces en una lectura de base de datos o una acción empresarial.

El ejemplo de facturación de Microsoft ilustra esa brecha. El agente operaba para una persona asociada a la cuenta ACME-1001. Nunca debería haber recuperado ni modificado la cuenta de otro cliente.

Una solicitud evaluada pedía información de contacto relacionada con BPS-447, que pertenecía a un cliente distinto. Según Microsoft, el agente de referencia devolvió el registro completo.

Una revisión de código podría confirmar que la función de recuperación funciona correctamente. Una prueba unitaria podría confirmar que un identificador de cuenta válido devuelve el registro esperado. Ninguna prueba necesariamente verifica si el modelo elige un identificador no autorizado durante una conversación realista.

Ese problema va más allá del soporte de facturación. Un agente de investigación puede acceder a fuentes inadecuadas, mientras que un agente de gestión de cambios puede eludir una secuencia de aprobación. Un agente de viajes puede hacer un uso indebido de información de identidad o pago almacenada.

La guía de OWASP denomina a esta condición más amplia agencia excesiva. Surge cuando una aplicación de IA tiene más funcionalidad, permisos o autonomía de los que requiere su tarea.

La inyección de prompts puede desencadenar estos fallos, pero no es la única causa. Las solicitudes ambiguas, los planes alucinados, las herramientas comprometidas y los simples errores del modelo también pueden producir acciones inseguras.

Los equipos afectados no son solo los grupos de seguridad. Los responsables de producto deben definir resultados permitidos y prohibidos. Los desarrolladores deben exponer puntos de control adecuados. Los responsables de riesgo deben decidir si una reducción medida es suficiente.

Los equipos de evaluación también enfrentan presión. Su resultado ya no puede limitarse a un informe que enumera fallos. El flujo de trabajo de Microsoft espera que un hallazgo respalde un control específico y una ejecución de validación repetible.

Las organizaciones que utilizan benchmarks genéricos de modelos enfrentan otro problema. Un benchmark amplio puede describir las tendencias promedio de un modelo, pero no puede capturar las reglas de cuentas, los límites de escalamiento ni el proceso interno de aprobación de cada empresa.

El enfoque de Microsoft comienza con los propios requisitos y riesgos detectados de la aplicación. Eso hace que la evaluación sea más relevante, aunque también vuelve menos directas las comparaciones entre organizaciones.

El lanzamiento también presiona a los proveedores que tratan la observación como el paso final. Registrar una llamada peligrosa a una herramienta después de su ejecución puede ayudar en una investigación. No evita la acción que causó el daño.

Run-assert-eval lleva la intervención a la ruta de tiempo de ejecución del agente. Eso lo acerca a conceptos de seguridad conocidos como las comprobaciones de autorización, el mínimo privilegio y los puntos de aplicación de políticas.

Esto no elimina los prompts. Les asigna un papel más limitado. Los modelos pueden planificar e interpretar el lenguaje, mientras que los controles deterministas deciden si las operaciones sensibles deben continuar.

Esta división se vuelve cada vez más importante a medida que los agentes obtienen acceso a archivos locales y conocimiento interno. Los equipos que construyen una base de conocimiento consultable se enfrentan a la misma cuestión de límites: la recuperación debe respetar el alcance real de autorización del usuario.

Microsoft run-assert-eval integra esa cuestión en un flujo de trabajo que los desarrolladores pueden ejecutar antes. La carga pasa entonces de esperar que el modelo obedezca una regla a demostrar dónde el software la aplica.

El mecanismo central es una prueba controlada de antes y después

La idea más sólida de run-assert-eval no es la generación automatizada de políticas; es preservar la evaluación mientras se modifica únicamente el control.

Las comparaciones de seguridad se vuelven poco fiables cuando los equipos regeneran el conjunto de pruebas después de aplicar una corrección. Un grupo distinto de prompts puede hacer que una política débil parezca exitosa o que una política sólida parezca peor.

Cambiar el evaluador crea otra variable de confusión. Dos evaluadores pueden interpretar de manera diferente la misma transcripción, especialmente cuando el comportamiento aceptable depende del contexto.

Run-assert-eval almacena en caché la sistematización de referencia y los casos de prueba. El agente gobernado se enfrenta después a la misma definición de comportamiento, casos y enfoque de evaluación.

Microsoft describe esto como congelar la evaluación. La política se convierte en la variable independiente prevista, mientras que las tasas de infracción medidas se convierten en los resultados observados.

El principio se parece a las pruebas de regresión en el software convencional. Una prueba fallida debe mantenerse fija mientras los desarrolladores modifican la implementación. De lo contrario, los resultados aprobados pueden reflejar una prueba reescrita en lugar de un comportamiento corregido.

Las pruebas de agentes son más difíciles porque las salidas del modelo son variables. El evaluador también puede basarse en un modelo, y los casos generados pueden contener sus propias ambigüedades.

Mantener constantes esos elementos no elimina todas las fuentes de incertidumbre. Sí hace que la diferencia entre antes y después sea más interpretable.

Microsoft afirma que evaluaciones anteriores de ASSERT encontraron entre un 80% y un 90% de concordancia entre su evaluador automatizado y revisores humanos. Compara ese rango con aproximadamente un 90% de concordancia entre revisores humanos.

Estas cifras son resultados reportados por Microsoft, no garantías universales de precisión. La concordancia del evaluador puede variar según el comportamiento, el modelo, la rúbrica, el idioma y la complejidad de la política subyacente.

La evaluación subyacente sigue siendo inspeccionable. El repositorio de ASSERT indica que las ejecuciones almacenan artefactos locales, casos generados, salidas de modelos, razonamientos del evaluador y métricas.

Los artefactos locales pueden respaldar auditorías porque los revisores pueden examinar por qué una transcripción fue clasificada como una infracción. También pueden identificar casos en los que el evaluador interpretó incorrectamente la política.

El diseño de dos tasas de ASSERT añade otra salvaguarda. Una política que bloquea comportamientos perjudiciales aún puede fallar si provoca un rechazo excesivo.

Para la suite entre clientes, Microsoft reportó una tasa de infracción inadmisible de referencia del 30.0%. El resultado gobernado fue del 5.9% con un denominador aplicable diferente.

Microsoft también dividió sus resultados entre prompts y escenarios. Los casos de prompts prueban interacciones más directas, mientras que los casos de escenarios capturan flujos de trabajo y contexto conversacional más ricos.

Para los casos de prompts entre clientes, la tasa inadmisible reportada cayó del 20.8% al 8.7%. La tasa correspondiente de escenarios cayó del 43.8% al 0.0%.

En los casos de prompts con acciones no verificadas, la tasa reportada cayó del 4,0 % al 0,0 %. En el desglose por escenarios, pasó del 8,7 % al 4,5 %.

Las infracciones de comportamiento permitido supuestamente alcanzaron el 0,0 % en las cuatro divisiones sometidas a gobernanza. Microsoft interpreta ese resultado como evidencia de que los controles preservaron el trabajo legítimo en esta muestra.

Importan las infracciones no permitidas restantes. Muestran que la política no eliminó todos los fallos, incluso dentro del ejemplo controlado.

Esto es coherente con el diseño iterativo del flujo de trabajo. Un equipo puede examinar los fallos que persisten, perfeccionar su definición de riesgo o su política y repetir el mismo proceso.

Por tanto, el método ofrece evidencia más sólida que unas pocas demostraciones manuales. Aun así, no establece cómo se comporta el agente ante todos los prompts futuros, actualizaciones de modelos, herramientas o entornos.

La ganancia práctica es más acotada y útil. Los equipos reciben evidencia trazable de que un control concreto modificó el rendimiento en una evaluación definida sin limitarse a silenciar al agente.

La política de tiempo de ejecución bloquea acciones antes de que el modelo pueda completarlas

La corrección de facturación funciona comprobando el alcance de la cuenta en el límite de la herramienta, no pidiéndole al modelo que reconsidere sus intenciones.

Tras medir la exposición entre clientes, run-assert-eval generó un borrador de política y un manifiesto ACS. La política expresaba la lógica de decisión, mientras que el manifiesto especificaba dónde debía aplicarse esa lógica.

Microsoft utilizó Rego, un lenguaje declarativo de políticas habitualmente asociado a motores de políticas. El material generado siguió siendo un borrador que requería revisión humana.

Esa puerta de revisión es importante. Microsoft afirma explícitamente que la generación no equivale a aprobación. Los desarrolladores deben inspeccionar la política, el punto de intervención, el manifiesto y la conexión con el agente objetivo.

La política seleccionada denegaba llamadas a herramientas cuando el identificador de cuenta solicitado difería de la cuenta del solicitante. Esa regla no requería que otro modelo decidiera si la solicitud parecía sospechosa.

Microsoft situó la comprobación en pre_tool_call, un punto de intercepción al que se llega antes de que el agente ejecute una herramienta. Por tanto, un identificador que no coincide provoca una denegación antes de que se produzca la recuperación.

El equipo también utilizó post_tool_call. Esta segunda comprobación retenía cualquier resultado no coincidente que nunca debería entrar en el contexto del modelo.

El uso de ambos puntos crea una defensa en profundidad. El primero intenta evitar una operación no autorizada. El segundo limita la exposición si el control anterior se omite o se conecta incorrectamente.

El motor de políticas ACS pretende separar estos controles de un único framework de agentes. Por ello, las políticas pueden seguir siendo portables cuando los equipos cambian de modelos o bibliotecas de orquestación.

Esa portabilidad aborda un problema real de mantenimiento. Los controles incorporados en prompts o callbacks específicos de un framework pueden resultar difíciles de auditar en varias implementaciones de agentes.

Una especificación compartida puede ofrecer a los revisores de seguridad un objeto coherente que inspeccionar. También puede permitir a los desarrolladores versionar los cambios de política junto al código de la aplicación.

Sin embargo, la portabilidad no garantiza una integración correcta. Cada entorno de ejecución debe exponer el contexto pertinente, preservar la identidad y llamar a la política en el punto adecuado.

Una regla de alcance de cuenta depende de información fiable sobre la cuenta. Si la identidad del solicitante es incorrecta o falta, una comparación perfectamente escrita seguirá produciendo un resultado de autorización erróneo.

La misma preocupación se aplica a los argumentos de las herramientas. Una política que inspecciona account_id presupone que el recurso solicitado está representado con precisión por ese campo.

Las herramientas complejas pueden ocultar objetivos sensibles dentro de consultas, documentos, URL o acciones anidadas. Entonces, una regla limitada podría pasar por alto rutas equivalentes hacia el mismo recurso protegido.

La política de tiempo de ejecución tampoco puede corregir todas las clases de fallos. Un control puede bloquear un reembolso no autorizado o una lectura de base de datos. No puede determinar automáticamente si toda explicación generada es precisa o justa.

Las aprobaciones humanas siguen siendo apropiadas para algunas acciones de alto impacto. Un diseño de herramientas con privilegios mínimos puede reducir los daños incluso cuando el modelo toma una mala decisión.

El marco más amplio de riesgos de IA considera la gestión de riesgos como una actividad de ciclo de vida. Incluye gobernanza, mapeo, medición y gestión continua, en lugar de una única prueba previa al lanzamiento.

Run-assert-eval encaja en ese patrón más amplio. Proporciona un puente concreto entre mapear un riesgo y medir y gestionar un comportamiento.

El punto de entrada de un solo prompt del flujo de trabajo no debería ocultar el trabajo subyacente. El modelado de amenazas, el diseño de pruebas, la revisión de políticas, la integración de sistemas y la interpretación de resultados siguen requiriendo decisiones informadas.

Lo que Microsoft ha reducido es el traspaso manual entre esas decisiones. La skill transporta artefactos estructurados de una etapa a la siguiente y mantiene visibles sus relaciones.

Esto puede reducir la probabilidad de que una descripción de riesgo pierda significado al transferirse entre los equipos de producto, evaluación y seguridad.

También puede acortar el intervalo entre descubrir un fallo y comprobar una mitigación. Ese intervalo suele ser donde se acumula el riesgo no resuelto de los agentes.

Los primeros resultados son evidencia, no una garantía general de seguridad

El ejemplo de Microsoft respalda la lógica del flujo de trabajo, pero no demuestra eficacia en producción entre agentes, organizaciones o ataques.

La limitación más evidente es la procedencia. Microsoft y los colaboradores del proyecto diseñaron las herramientas, seleccionaron el ejemplo, aplicaron los controles e informaron las mediciones resultantes.

Eso no invalida los hallazgos. Significa que los lectores deben distinguir entre un ejemplo práctico transparente y un benchmark independiente o un estudio de campo.

Los tamaños de muestra también requieren cautela. La línea base principal incluyó 40 conversaciones aplicables, mientras que la ejecución gobernada incluyó 34.

Esos denominadores difieren porque solo los casos aplicables contribuyen a una tasa de comportamiento concreta. Aun así, las muestras pequeñas pueden producir porcentajes inestables.

Un cambio de 12 infracciones a dos es operativamente significativo en el ejemplo. No debe interpretarse como una reducción universal del 80 % para otros agentes.

La tasa reportada del 0,0 % de infracciones permitidas también significa que no aparecieron infracciones en esa muestra. No significa que la política nunca pueda bloquear un comportamiento legítimo.

Un conjunto de pruebas más amplio podría revelar denegaciones falsas poco frecuentes. El tráfico de producción podría incluir relaciones entre cuentas, reglas de delegación o excepciones de soporte ausentes del ejemplo.

La filtración de la evaluación plantea otra preocupación. Si una política se ajusta repetidamente frente a un único conjunto de pruebas congelado, los desarrolladores pueden acabar sobreajustándose a los casos conocidos.

Congelar las pruebas crea una comparación creíble durante una intervención. Los programas a largo plazo aún necesitan casos reservados, nuevas variantes adversariales y monitorización de cambios de comportamiento.

Los cambios de modelo también pueden invalidar conclusiones anteriores. Un modelo nuevo puede formatear los argumentos de herramientas de otra manera, interpretar las negativas de forma distinta o encontrar otra vía hacia la información protegida.

Los cambios en las herramientas generan un riesgo similar. Añadir una función de exportación o un endpoint de búsqueda general puede introducir una ruta de acceso no cubierta por la comprobación original de cuenta.

El juez de evaluación merece un escrutinio continuo. El intervalo de concordancia reportado por Microsoft es alentador, pero los casos de desacuerdo pueden concentrarse en los límites más ambiguos y relevantes.

Los equipos deberían conservar la revisión humana para casos en disputa y muestrear periódicamente resultados aparentemente satisfactorios. Un juez automatizado estable resulta útil para comparar, pero no es una autoridad infalible.

También existe un problema de cadena de suministro implícito en la palabra “skill”. Las skills de agentes contienen instrucciones que influyen en la planificación, la ejecución y la validación.

Microsoft Research informó recientemente de 307 fallos inducidos por skills en dos entornos de benchmark. Incluyeron 125 fallos funcionales y 182 regresiones de eficiencia.

Esa investigación no evalúa específicamente run-assert-eval. Establece una razón más amplia para inspeccionar las instrucciones, scripts, permisos y supuestos operativos de cualquier skill.

Run-assert-eval aborda parcialmente esa preocupación mediante artefactos visibles y puertas humanas. Los equipos pueden inspeccionar las configuraciones de evaluación y políticas generadas antes de ejecutar pruebas gobernadas.

La generación de pruebas respaldada por literatura introduce otra obligación de verificación. Un marco citado puede orientar las dimensiones, pero su relevancia depende de la precisión con que la skill traduzca esa fuente en casos.

Una traducción deficiente puede generar etiquetas de cobertura impresionantes sin una cobertura significativa. Por ello, los revisores deberían inspeccionar los escenarios, no solo los nombres de los marcos asociados.

El coste operativo es otra cuestión abierta. Ejecutar casos generados, capturar trazas, evaluar transcripciones y repetir evaluaciones consume llamadas al modelo y tiempo de ingeniería.

El proyecto no ha publicado una comparación amplia de ese coste frente a flujos de evaluación manual. Las organizaciones deben determinar qué riesgos justifican una evaluación más profunda.

La interpretación más razonable es mesurada pero positiva. Microsoft ha reunido un proceso coherente para un problema de integración difícil.

El lanzamiento no demuestra que un agente sea seguro. Ayuda a un equipo a formular una afirmación de seguridad específica, adjuntarle evidencia y comprobar si una intervención mejoró un resultado definido.

Tres señales mostrarán si el enfoque se sostiene

La siguiente prueba es si equipos independientes reproducen las mejoras del flujo de trabajo sin sacrificar el comportamiento útil del agente ni crear cargas de mantenimiento ocultas.

La primera señal es la replicación por terceros. Los desarrolladores deberían estar atentos a evaluaciones públicas que apliquen Microsoft run-assert-eval a agentes fuera de los ejemplos incluidos.

Una replicación convincente publicaría las definiciones de riesgo, los casos, la política, las trazas, la configuración del juez y los resultados de la revisión humana. También revelaría los fallos que permanecieron tras la gobernanza.

Los resultados en distintos modelos y frameworks reforzarían la afirmación de portabilidad de Microsoft. Las diferencias sustanciales de integración revelarían dónde ACS todavía depende de entornos de ejecución individuales.

La segunda señal es una evidencia de producción más amplia. Los equipos necesitan saber si las evaluaciones congeladas predicen incidentes, denegaciones y elusión de políticas bajo tráfico real.

La evidencia útil incluiría tendencias de infracciones posteriores al despliegue y solicitudes legítimas bloqueadas por controles. También rastrearía fallos introducidos tras cambios en modelos, herramientas o prompts.

Los despliegues más sólidos conectarán los artefactos de evaluación con la monitorización continua. Una mejora previa al lanzamiento importa más cuando la telemetría de producción confirma el mismo límite de comportamiento.

La tercera señal es la respuesta del proyecto a la evasión y a la deriva de políticas. Los atacantes y los usuarios comunes pueden llegar a acciones protegidas mediante rutas ausentes de la suite original.

Esté atento a nuevas suites que cubran inyección indirecta de prompts, autoridad delegada, identidades en conflicto, manipulación de estado y transferencias entre múltiples agentes. Observe también cómo el proyecto evita el sobreajuste a casos congelados.

Las políticas versionadas y las ejecuciones de regresión serán esenciales. Los equipos necesitan un desencadenante claro para repetir evaluaciones cada vez que cambien los modelos, herramientas, permisos o reglas de negocio.

El lanzamiento también debería juzgarse por su experiencia de revisión. Una política generada solo es útil cuando desarrolladores y equipos de seguridad pueden entender por qué existe y qué bloquea.

Esto convierte a los artefactos locales, las transcripciones citadas y las definiciones acotadas de comportamiento en algo más que detalles de implementación. Forman la cadena de evidencia que respalda la aprobación.

Por tanto, Microsoft run-assert-eval se entiende mejor como una disciplina de ingeniería empaquetada como una skill. Conecta el modelado de amenazas, la evaluación específica por comportamiento, la aplicación de controles en tiempo de ejecución y las pruebas controladas posteriores.

Los desarrolladores no deberían preguntarse si el flujo de trabajo certifica que todo un agente es seguro. Deberían preguntarse si permite medir un riesgo importante, revisar un control y reproducir una mejora.

Es una promesa más modesta que demostrar la seguridad general. También es un punto de partida más creíble para la gobernanza de agentes.