Para ser lo más productivos posible al programar y en otras tareas, los agentes necesitan un grado saludable de autonomía. Eso significa que deberían poder actuar de forma independiente, ser creativos y completar el trabajo sin detenerse con demasiada frecuencia para pedir permiso.

Sin embargo, una mayor autonomía introduce riesgos de seguridad si los agentes realizan acciones no deseadas. Esto es especialmente cierto en el caso de los agentes locales, que a menudo se ejecutan cerca de archivos, credenciales, variables de entorno y herramientas MCP, y tienen acceso a sistemas de producción.

La respuesta fácil es pedirle confirmación al usuario antes de cualquier acción, pero pedir permiso con demasiada frecuencia crea su propio problema de seguridad operativa. Después de suficientes avisos repetidos, la gente deja de leer con atención y el flujo de aprobación pierde valor.

Esta semana lanzamos Auto-review, que hace que las decisiones sobre la autonomía del agente funcionen más como un regulador que como un interruptor. La idea central es que un agente debería poder moverse libremente cuando hay poco en juego, pero frenar cuando su siguiente acción cruza un límite importante.

Determinamos dónde se sitúa una acción dentro de ese continuo con un agente clasificador especializado que revisa las acciones en contexto antes de que se ejecuten. Crearlo implicó convertir nuestra intuición sobre cómo debería regularse la autonomía del agente en un modelo funcional de consecuencias, intención y retroalimentación que pudiéramos poner a prueba frente al comportamiento real de los agentes.

#Evaluar el riesgo en contexto

Que una acción de un agente implique un riesgo depende de la situación. El mismo comando puede ser inofensivo en un flujo de trabajo e inaceptable en otro. Lo que importa es la relación entre la acción, la solicitud del usuario y las consecuencias de equivocarse.

Ese reconocimiento nos llevó a desarrollar un agente "clasificador" que regulara la autonomía general del agente. Queríamos que fuera un modelo pequeño, para que siguiera siendo rápido y barato de ejecutar, y que al mismo tiempo pudiera emitir un juicio matizado sobre si la siguiente acción se ajustaba a la intención del usuario.

La regla principal que le dimos al clasificador fue que debía ser más permisivo cuando los riesgos de seguridad fueran menores y más cauteloso cuando fueran mayores. Con esa idea general clara, empezamos a crear el clasificador como un revisor contextual y rápido que pudiera situarse directamente en la ruta de ejecución del agente.

#Desarrollo del clasificador

La primera decisión técnica fue la elección del modelo. El clasificador se ejecuta antes de que se ejecute una llamada a herramienta, así que se sitúa directamente en el bucle del agente y necesita ser rápido además de preciso. El hecho de ser una compañía con múltiples modelos ayudó aquí, porque pudimos probar una amplia gama de modelos y modos de razonamiento, y luego elegir el que ofrecía el equilibrio adecuado entre velocidad y criterio.

Una sorpresa inicial fue que los modelos con menos razonamiento no siempre eran más rápidos. Cuando un modelo tenía dificultades para entender la política o la llamada a herramienta, podía dedicar más tiempo y tokens a buscar una respuesta que al final resultaba peor. El mejor equilibrio fue un modelo pequeño con suficiente razonamiento para tomar la decisión con claridad.

También hicimos que el clasificador usara agentes, porque algunas acciones no pueden juzgarse solo a partir del comando. Un comando como python script.py puede ser seguro o inseguro según lo que haya dentro del archivo, así que el clasificador puede inspeccionar el espacio de trabajo con herramientas como ReadFile, Grep, Glob y ListDir antes de decidir.

Evitamos usar un endpoint de clasificación independiente, porque una ida y vuelta adicional añadiría latencia justo antes de cada llamada a herramienta revisada. En su lugar, el clasificador se ejecuta en el mismo flujo RPC que el agente padre, con una arquitectura similar a la de los subagentes.

#Diseñando el ciclo de retroalimentación

La siguiente decisión fue qué debía hacer un bloqueo. No queríamos que el clasificador se convirtiera en otro generador de solicitudes de aprobación. Cuando bloquea una acción, devuelve una explicación al agente principal, y ese agente a menudo puede usar esa retroalimentación para elegir un camino más seguro sin interrumpir al usuario.

La intención del usuario es lo que hace útil esa retroalimentación. La cuestión no es si una acción parece riesgosa de forma aislada. La cuestión es si la acción está justificada por lo que el usuario le pidió al agente que hiciera. Eso es lo que permite que el trabajo normal de desarrollo siga avanzando, mientras que las acciones con mayores consecuencias requieren una señal más clara del usuario.

Ese diseño solo funciona si el clasificador está calibrado con respecto a las acciones que debería dejar pasar y las que debería detener, así que necesitábamos evals que cubrieran ambas.

#Pruebas del clasificador

Nuestro primer conjunto de evals provino de datos internos de uso para entender cómo suele trabajar el agente. El clasificador tenía que detectar acciones arriesgadas sin bloquear el trabajo rutinario de desarrollo, y las sesiones internas eran la mejor forma de ver esa referencia. Empezamos con aproximadamente 12 horas de sesiones internas de desarrolladores, y luego las recortamos y deduplicamos las acciones comunes hasta obtener 6,122 filas etiquetadas.

También necesitábamos datos sintéticos, porque los peores casos no aparecen con suficiente frecuencia en el uso normal. Generamos casos en los que el agente podía leer secretos, modificar datos de producción, seguir instrucciones no fiables o realizar acciones con efectos secundarios importantes. Esos ejemplos nos dieron cobertura para los fallos que más queríamos que el clasificador detectara.

La política fue cambiando a medida que aprendíamos, lo que hizo más complejo el trabajo con los datos. Cuando cambiamos las categorías de comportamiento que el clasificador debía reconocer, tuvimos que volver a etiquetar o rematerializar el conjunto de evals. De lo contrario, estaríamos probando el clasificador actual frente a una comprensión desactualizada del problema.

Ejecutamos las evals a través del mismo bucle del clasificador del backend que usamos en producción. Eso nos permitió probar el flujo completo, incluido el uso de herramientas, la clasificación final, las anulaciones del modelo y los fallos de análisis. Las evals comprobaron la decisión final de permitir o bloquear, junto con el contexto que el clasificador usó cuando necesitó inspeccionar el espacio de trabajo antes de decidir.

También buscamos inestabilidad. Si el mismo caso se permitía seis veces y se bloqueaba cuatro, eso normalmente significaba que la política o el prompt no estaban lo bastante especificados. Las ejecuciones repetidas nos dieron una forma de encontrar esos casos inestables y ajustar el clasificador hasta que su comportamiento fuera más consistente.

#Reducir al mínimo los bloqueos directos

En la práctica, solo una pequeña parte de las acciones del agente necesita ser revisada por el clasificador. Muchos comandos ya están cubiertos por listas de permitidos o por aislamiento, así que el clasificador se ejecuta sobre todo cuando la acción requiere juicio contextual.

Cuando el clasificador sí se ejecuta, actualmente bloquea alrededor del 4% de las acciones, aunque un bloqueo no se convierte de inmediato en una solicitud al usuario. El clasificador devuelve una explicación al agente principal, que a menudo puede acotar la acción, elegir otra herramienta o evitar por completo el paso riesgoso.

Algunos bloqueos del clasificador se convierten en interrupciones para el usuario, pero a nivel global estamos viendo que solo alrededor del 7% del total de chats en modo Auto-review llevan a al menos una interrupción. Para ponerlo en perspectiva, algunos clientes empresariales con los que trabajamos antes veían que aproximadamente el 40% de las acciones se bloqueaban dentro de su organización.

Estos primeros datos coinciden con el comportamiento principal del producto que buscábamos. El clasificador rara vez interrumpe directamente al usuario y, en la mayoría de los casos bloqueados, el agente principal puede usar esa retroalimentación para continuar de una forma más segura y más acotada.

#Refinando la autonomía del agente

Auto-review todavía está en una fase temprana, y nuestra comprensión del continuo de autonomía seguirá evolucionando a medida que los agentes sean cada vez más capaces. Hoy se centra en los agentes locales de la aplicación de escritorio, y esperamos que estas mismas ideas den forma con el tiempo a cómo gestionamos la autonomía de los agentes en más lugares.

Queremos que los agentes tengan una autonomía real, pero que la decisión de frenarlos dependa del contexto y no de una única configuración global de permisos. El clasificador nos permite mejorar la seguridad sin volver a convertir la autonomía en una sucesión de solicitudes de aprobación. Detecta acciones que requieren un mayor análisis, proporciona retroalimentación al agente principal y permite que el agente siga trabajando cuando hay una forma más segura de continuar.

Auto-review ahora viene activado de forma predeterminada para los nuevos usuarios. Los usuarios existentes pueden activarlo en Configuración > Agentes.