Control Remoto de Codex, Endurecimiento de RCE de Agentes, Ganchos de Sesión de Copilot, y Microsoft Agent Framework 1.5

[00:00] Codex 0.130.0 les da a los operadores de coding-agents un plano de control más limpio. La funcionalidad principal es codex remote-control, un punto de entrada más simple para iniciar un servidor de aplicaciones headless que puede ser controlado de forma remota. Esto es importante porque los coding-agents ya no son solo herramientas de terminal. Son sesiones de servidores de aplicaciones con hilos, instantáneas de configuración, superficies de plugins, eventos de revisión, vistas de archivos y clientes remotos que pueden necesitar inspeccionar o continuar el trabajo sin estar dentro de la terminal original. Esta versión también añade vistas de hilos paginadas, metadatos de hooks de plugins, mejor actualización de configuración en vivo, diffs de turnos más precisos después de fallos parciales de parches, resolución de imágenes en múltiples entornos y telemetría más rica para depurar rutas de revisión.

[02:00] HISTORIA 1 — OpenAI Codex 0.130.0 Añade Servidores de Aplicaciones con Control Remoto, Vistas de Hilos Paginadas, Visibilidad de Hooks de Plugins y Mejor Reparación de Estado

Comencemos con el punto de entrada remote-control. Un servidor de aplicaciones headless es un objeto operativo diferente de una ejecución CLI de un solo uso. El servidor posee sesiones, hilos, configuración, selección de entorno, ejecución de herramientas y conexiones de clientes. Añadir un comando de nivel superior codex remote-control reduce la fricción para iniciar ese plano de control directamente. Para los constructores que integran coding-agents en dashboards, IDEs, clientes de navegador o máquinas de desarrollo remotas, esa es la superficie que convierte un asistente local en un endpoint de servicio.

El mecanismo importante es la separación entre control y trabajo. El servidor de aplicaciones puede mantener una sesión de codificación viva mientras un cliente se reconecta, navega por un hilo grande, abre una vista de resumen o solicita una vista de elemento completo solo cuando es necesario. Codex 0.130.0 añade paginación para hilos grandes donde los clientes pueden solicitar vistas de elementos de turno no cargados, de resumen o completos. Eso no es solo pulido de UI. Los hilos de agentes pueden volverse enormes porque incluyen turnos de usuario, turnos de modelo, llamadas a herramientas, diffs, referencias de archivos, aprobaciones, imágenes y resúmenes compactados. Cargar todo en cada cliente desperdicia memoria, aumenta la latencia y hace que los clientes remotos sean frágiles.

Una API de hilos paginados le da al servidor de aplicaciones espacio para tratar la materialización de hilos como un contrato. Un elemento no cargado puede preservar el orden y la identidad sin transferir la carga útil. Un elemento de resumen puede dar suficiente contexto para la navegación. Un elemento de turno completo puede obtenerse cuando el usuario abre el detalle. Ese patrón es familiar en logs, trazas y líneas de tiempo de issues, y los coding-agents ahora lo necesitan porque sus transcripciones son registros operativos, no solo texto de chat.

Los detalles de plugins ahora muestran los hooks incluidos, y compartir plugins expone metadatos de enlaces más controles de descubribilidad. Los hooks son parte del comportamiento real en tiempo de ejecución de un plugin. Si un plugin puede modificar el inicio, observar una llamada a herramienta, proporcionar un comando o participar en una revisión, los operadores necesitan ver eso antes de instalarlo o compartirlo. Ocultar los hooks dentro de un paquete convierte la revisión de plugins en trabajo de adivinación. Mostrarlos en los detalles del plugin hace que la superficie de ejecución sea auditable.

La versión también repara el comportamiento de configuración del servidor de aplicaciones en vivo. Los hilos del servidor de aplicaciones en vivo ahora captan los cambios de configuración sin requerir un reinicio. En un runtime de agentes, la configuración puede incluir opciones de modelo, políticas de aprobación, configuraciones de proveedor, disponibilidad de herramientas, estado de plugins, selección de entorno y opciones de telemetría. Si un hilo de larga ejecución sigue usando configuración obsoleta, los operadores pueden creer que cambiaron la política mientras un agente activo continúa con la configuración anterior. Actualizar los hilos en vivo desde la última instantánea de configuración hace que los cambios de política surtan efecto donde se está realizando el trabajo.

Los diffs de turnos reciben una corrección particularmente práctica. Codex ahora mantiene los diffs precisos a través de operaciones de apply_patch, incluyendo fallos parciales que aún mutaron archivos. Este modo de fallo importa. Un parche puede fallar a mitad de camino pero aún así cambiar parte de un archivo. Si el runtime reporta el diff incorrecto después, el usuario no puede confiar en la vista de revisión, la lógica de rollback o el rastro de auditoría. El seguimiento de diffs respaldado por operaciones es la dirección correcta: registrar lo que la operación realmente cambió, no lo que se suponía que debía cambiar el parche ideal.

Las correcciones de ThreadStore mejoran los resúmenes, renombrados, resume y rutas de fork, incluyendo hilos sin rutas de despliegue local. Eso significa que la capa de almacenamiento de hilos se está convirtiendo en la fuente de verdad para más operaciones del ciclo de vida. Resume y fork son especialmente importantes para los coding-agents porque un usuario puede querer ramificar una investigación, continuar una ejecución fallida o abrir un hilo desde un cliente remoto que carece de la ruta de despliegue local original. Si la identidad del hilo depende demasiado del estado del sistema de archivos local, los flujos de trabajo remotos y headless se rompen.

La compactación remota también obtiene correcciones de contrato de stream. Codex ahora emite response.processed para streams v2 y evita enviar service_tier en solicitudes de compactación con API-key. La compactación es cómo las sesiones largas permanecen utilizables, pero la compactación remota tiene que hablar el mismo lenguaje de eventos que el resto del servidor de aplicaciones. Un evento processed faltante puede dejar a los clientes esperando un estado terminal. Enviar campos no soportados en una solicitud de compactación puede romper solo la ruta de compactación mientras los turnos normales aún funcionan, lo cual es difícil de diagnosticar.

El soporte multi-entorno aparece en view_image, que ahora puede resolver archivos a través del entorno seleccionado. Los coding-agents a menudo operan a través de un host, contenedor, sandbox, espacio de trabajo remoto o proyecto montado. Una ruta de imagen no es significativa a menos que el runtime sepa qué entorno la posee. Resolver a través del entorno seleccionado evita que un cliente mire accidentalmente el sistema de archivos equivocado o falle al mostrar un artefacto que existe dentro del sandbox activo.

El soporte de autenticación Bedrock ahora acepta credenciales de console-login de AWS de los perfiles de aws login. Eso es una conveniencia para operadores con impacto real en el despliegue. Muchos equipos ya gestionan el acceso a AWS a través de flujos basados en perfiles. Permitir que Codex use esos perfiles reduce las rutas de credenciales duplicadas y hace que la autenticación del proveedor de modelos se alinee con los controles de acceso a la nube existentes.

Los cambios de telemetría son útiles para la depuración en producción. Codex añade metadatos de trazas OpenTelemetry configurables y análisis más ricos de revisión y feedback. Los eventos de revisión son una parte fundamental de la seguridad de los coding-agents. Si un comando fue aprobado, denegado, reintentado o escalado, los operadores necesitan suficiente contexto de traza para entender por qué. Una buena telemetría debería conectar una sesión, un turno, una llamada a herramienta, una decisión de aprobación, una solicitud al modelo y un resultado visible para el usuario sin filtrar secretos.

La recomendación práctica es tratar los despliegues del servidor de aplicaciones Codex como despliegues de servicios. Fijar la versión, iniciar remote-control deliberadamente, documentar qué clientes pueden conectarse, auditar los hooks de plugins antes de compartir, tener en mente el comportamiento de actualización de configuración y probar los casos de fallo de parches. La versión no se trata solo de nuevos comandos; se trata de hacer que un coding-agent sea controlable, inspeccionable y recuperable cuando las sesiones crecen y se ejecutan de forma remota.

[16:00] HISTORIA 2 — La Investigación de RCE del Semantic Kernel de Microsoft Convierte la Inyección de Prompts en una Lección sobre Límites de Ejecución de Herramientas

La publicación de seguridad de Microsoft es un recordatorio directo de que la inyección de prompts se vuelve más peligrosa cuando el lenguaje está conectado a herramientas. El modelo no es el componente vulnerable en el caso de estudio. El modelo recibe texto, decide llamar a una herramienta y llena los argumentos de la herramienta. El límite vulnerable es el código del framework y de plugins que confía en esos argumentos y los convierte en comportamiento ejecutable del host.

El primer problema divulgado se centra en la ruta de búsqueda del Vector Store en memoria de Semantic Kernel. El agente de ejemplo expone una función de búsqueda de hoteles. Un usuario pide hoteles en una ciudad. El modelo llama al plugin de búsqueda con un argumento de ciudad. El plugin construye un filtro determinista para reducir el conjunto de datos antes de la similitud vectorial. El paso arriesgado es que un argumento controlado por el modelo se interpola en una expresión lambda de Python y luego se ejecuta con eval().

Ese es el límite de ejecución. Un valor normal de ciudad se convierte en una expresión de filtro. Un valor malicioso puede cerrar una comilla y anexar lógica de Python. La inyección de prompts no necesita un exploit de navegador, un archivo adjunto malicioso o corrupción de memoria. Necesita que el framework del agente tome un parámetro derivado del lenguaje y lo coloque en una expresión ejecutable. Una vez que eso sucede, la inyección de prompts se ha convertido en inyección de código.

La mitigación intentada usó validación de AST y un entorno de builtins restringido. A alto nivel, el validador permitía expresiones lambda, escaneaba nombres y atributos en busca de identificadores peligrosos y ejecutaba con __builtins__ eliminado. Eso suena razonable, pero los lenguajes dinámicos hacen que las listas de bloqueo sean frágiles. Los investigadores de Microsoft evadieron el filtro sin usar directamente los nombres bloqueados obvios. La carga útil traversó estructuras de objetos de Python para localizar la maquinaria de import y alcanzar la ejecución de comandos del sistema a través de atributos alternativos.

La lección no es simplemente "no uses eval". La lección más amplia es que los argumentos de llamadas a herramientas son entrada no confiable incluso cuando vinieron de un modelo, incluso cuando el usuario no escribió código directamente, e incluso cuando el esquema dice que el campo es un nombre de ciudad. Un modelo puede ser inducido a colocar strings controlados por un atacante en cualquier argumento que se le permita llenar. Si la herramienta luego interpreta ese string como código, un lenguaje de consulta, un comando de shell, una ruta de archivo o una plantilla, el framework ha creado un sumidero de inyección.

La búsqueda vectorial hace que esto sea fácil de subestimar porque se siente como infraestructura de recuperación en lugar de ejecución de código. Pero los vector stores a menudo soportan filtros de metadatos, lenguajes de expresiones, predicados personalizados, prefiltros de embeddings, rerankers y strings de consulta específicos de conectores. Cada uno de esos puede convertirse en un límite de inyección si los valores controlados por el usuario o el modelo se concatenan en una expresión interpretada. El diseño seguro generalmente significa filtros parametrizados, DSLs tipados, operadores en listas de permitidos y validación que rechaza estructura inesperada antes de la ejecución.

Una corrección robusta debería eliminar la construcción de strings-código de la ruta por defecto. En lugar de generar un string lambda, un framework puede construir un predicado a partir de campos tipados y operadores. Por ejemplo, campo equals valor debería ser datos, no código fuente. Si un lenguaje de filtro es inevitable, el runtime debería parsear en un AST restringido y evaluar con un intérprete que solo entienda las operaciones permitidas. No debería llamar al evaluador del lenguaje host e intentar bloquear comportamiento peligroso después.

El principio de mínimo privilegio también es importante. Los plugins de búsqueda no deberían ejecutarse con los mismos privilegios de sistema de archivos, proceso y red que la aplicación host si no los necesitan. Un predicado de búsqueda de hoteles no necesita acceso al shell. Si un bug del framework convierte un filtro en ejecución de código, el sandbox y los privilegios del proceso determinan el radio de explosión. Los frameworks de agentes deberían aislar la ejecución de plugins, limitar las variables de entorno, evitar pasar credenciales a procesos genéricos de herramientas y registrar los parámetros de las herramientas con suficiente detalle para responder ante incidentes.

La detección es práctica. Los equipos que usan frameworks de agentes deberían inventariar las herramientas que ejecutan plantillas, filtros, comandos de shell, celdas de notebooks, fragmentos de Python, fragmentos de JavaScript, SQL u operaciones de archivos. Deberían buscar valores controlados por el modelo que se pasan a esos intérpretes. Deberían aplicar parches a Semantic Kernel y paquetes relacionados, pero también revisar plugins personalizados porque el mismo patrón aparece en el código de la aplicación. La seguridad contra inyección de prompts no es solo un problema de evaluación del modelo; es validación de entradas y aislamiento de ejecución para los tiempos de ejecución de herramientas.

La conclusión para los operadores es directa: cada herramienta de agente es un endpoint de API cuyo llamador está parcialmente controlado por el modelo. Tratar los esquemas de herramientas como contratos de API externos. Validar las entradas en el límite de la herramienta. Preferir estructuras de datos tipadas sobre cadenas interpretadas. Mantener los permisos de los plugins restringidos. Registrar lo suficiente para reconstruir qué prompt causó qué argumentos de herramienta. Y probar la inyección de prompts intentando forzar al agente a pasar parámetros hostiles a las herramientas, no solo verificando si el modelo dice palabras unsafe.

[28:00] HISTORIA 3 — GitHub Copilot SDK Agrega Ganchos de Modo de Aprobación de Plan y Límite de Velocidad Más Diagnósticos Cross-SDK La versión pre-lanzamiento del Copilot SDK del 8 de mayo se trata de incrustar sesiones de agentes en productos con control de tiempo de ejecución más explícito. Las aplicaciones ahora pueden registrar callbacks para exitPlanMode.request y autoModeSwitch.request. Esos eventos son importantes porque el modo plan y el cambio automático de modelo son decisiones de producto, no solo decisiones del modelo.

El modo plan es un límite entre proponer trabajo y hacer trabajo. En un agente de codificación incrustado, la aplicación puede querer que un humano apruebe el plan, que un motor de políticas lo verifique, o que una regla específica del proyecto bloquee ciertos cambios. Los nuevos handlers permiten que las aplicaciones decidan si una solicitud de salir del modo plan es aprobada. Eso le da al producto host un punto de intercepción claro antes de que el tiempo de ejecución pase de planificar a ejecutar.

El cambio automático de modelo después de límites de velocidad es un tipo diferente de límite. Un tiempo de ejecución puede querer recuperarse de eventos de límite de velocidad cambiando a otro modelo o modo. Eso puede preservar la continuidad, pero también puede cambiar el comportamiento, costo, latencia o capacidad. El handler autoModeSwitch.request permite que la aplicación decida si acepta ese cambio. Para productos empresariales, eso es importante porque la elección del modelo puede estar vinculada a políticas de datos, cumplimiento, líneas base de evaluación o controles de presupuesto.

El lanzamiento también agrega diagnósticos estructurados a través de .NET, Python y Rust. Los logs cubren el inicio del CLI, conexión TCP, tiempo de solicitudes JSON-RPC, ciclo de vida de sesiones y rutas de errores. Esta es exactamente la visibilidad que necesita un SDK de agente incrustado. Cuando una sesión falla, la causa puede ser inicio del proceso, transporte, auth, enmarcado JSON-RPC, manejo de eventos del tiempo de ejecución, respuesta del modelo, ejecución de herramientas o comportamiento de callback del host. Sin logs estructurados de tiempo y ciclo de vida, cada falla parece "el agente se colgó".

El detalle de JSON-RPC vale la pena destacar. Muchos SDKs de agentes de codificación envuelven un proceso de tiempo de ejecución local y se comunican sobre JSON-RPC. Eso significa que hay un objeto cliente en la aplicación, un proceso de tiempo de ejecución, una conexión de transporte, IDs de solicitud, flujos de eventos y operaciones de larga duración. Los diagnósticos necesitan mostrar cuándo comenzó el tiempo de ejecución, cuándo se abrió la conexión TCP, qué solicitudes JSON-RPC se enviaron, cuánto tiempo tomaron y dónde surgieron errores. De lo contrario, los desarrolladores de aplicaciones no pueden distinguir el mal uso del SDK del fallo del tiempo de ejecución.

La opción enableSessionTelemetry hace de la telemetría una elección explícita de sesión. Esa es la forma correcta para privacidad y operaciones. Algunos despliegues quieren telemetría de sesión interna para depurar problemas y mejorar la calidad del producto. Otros la necesitan deshabilitada por política. Poner el control en la configuración de sesión y configuración de reanudación hace que la decisión sea auditable y repetible en lugar de depender de valores predeterminados ocultos.

Hay correcciones de compatibilidad más pequeñas que importan para usuarios del SDK de larga duración. Los enums de eventos de sesión de C# ahora son structs readonly respaldados por strings para que la deserialización no falle cuando el tiempo de ejecución agrega nuevos valores de enum. Eso es compatibilidad hacia adelante para flujos de eventos. Los blobs de recursos de resultados de herramientas binarias de Rust ahora predeterminan a application/octet-stream cuando mimeType está ausente. Eso es una corrección de resiliencia del formato de cable. Ambos cambios reducen roturas cuando los tiempos de ejecución y los SDKs evolucionan a diferentes velocidades.

La implicación práctica para los constructores es que las sesiones del Copilot SDK se están convirtiendo en objetos de tiempo de ejecución controlados por el host. Si los incrustas, implementa los callbacks de modo plan y cambio de modo deliberadamente. Decide qué cambios pueden ocurrir automáticamente y cuáles necesitan revisión. Activa los diagnósticos en desarrollo y staging. Captura el tiempo de JSON-RPC alrededor de sesiones lentas o inestables. Trata la telemetría como una decisión de política. Y prueba clientes más antiguos contra eventos más nuevos del tiempo de ejecución para que la compatibilidad hacia adelante de enums y eventos no te sorprenda.

[38:00] HISTORIA 4 — Microsoft Agent Framework 1.5 Avanza en Orquestación, Observabilidad, Política de Herramientas de Navegador y Semántica de Cable El lanzamiento del 8 de mayo del Microsoft Agent Framework es amplio, pero varios cambios son directamente relevantes para constructores de agentes de producción. La línea .NET agrega Magentic Orchestration, allowlisting de WebBrowsingTool, muestras de observabilidad de agentes alojados, eventos de razonamiento en AGUI, mejoras de multithreading de todo y headers de cliente por llamada de Foundry. La línea Python cercana agrega skills basadas en clases y providers de contexto de harness experimentales. El lanzamiento también corrige el formato de cable de salida de herramientas, loops de workflows, parsing de YAML, serialización multipartita y numeración de secuencias.

Magentic Orchestration es el titular porque los sistemas multi-agente necesitan más que una lista de agentes. Necesitan scheduling, delegación, propiedad de turnos, estado compartido, condiciones de terminación y una forma de decidir qué agente debería actuar a continuación. Una capa de orquestación formaliza esos mecanismos. Marcarla como experimental es apropiado porque la semántica de orquestación se convierte en arquitectura de aplicación: un mal scheduler puede hacer loop, duplicar trabajo, ocultar fallos o dejar que un agente domine la conversación.

El allowlisting de WebBrowsingTool es un control importante de uso de navegador/computadora. Las herramientas de navegación conectan un agente a contenido externo que puede ser malicioso, no confiable o simplemente distractivo. Una allowlist le da a la aplicación host una superficie de política para cuáles destinos de navegación o comportamientos del navegador están permitidos. En sistemas de agentes, navegar no es solo leer. El navegador puede obtener contenido de inyección de prompts, enviar formularios, seguir redirecciones, exponer cookies y recuperar archivos. La política necesita existir antes de que la herramienta se ejecute.

Las muestras de observabilidad de agentes alojados también son valiosas porque el despliegue es donde las abstracciones del framework se encuentran con la realidad de producción. Un agente alojado necesita logs, traces, correlación de solicitudes, visibilidad de llamadas al modelo, tiempo de llamadas a herramientas y estado de fallo. Las muestras de observabilidad pueden convertirse en el patrón de referencia para equipos que de lo contrario enviarían agentes con solo logs de consola. La pregunta útil para cualquier agente alojado es: ¿podemos reconstruir una ejecución fallida desde la solicitud externa a través de la decisión de orquestación, llamada al modelo, llamada a herramienta y respuesta final?

Los eventos de razonamiento en AGUI exponen otro problema de transporte. Las interfaces de usuario necesitan renderizar el progreso del agente sin mezclar cadena de pensamiento privada, racionalización de herramientas y resúmenes de razonamiento visibles por el usuario incorrectamente. Un canal de eventos de razonamiento permite que el framework represente el progreso o estado relacionado con razonamiento como eventos estructurados. La aplicación todavía tiene que decidir qué es seguro mostrar, almacenar y transmitir, pero los eventos estructurados son mejores que hacer scraping de texto de un stream.

El multithreading de todo y la inyección de todo en la lista de mensajes muestran cómo el manejo de estado se convierte en una característica del tiempo de ejecución. Los agentes usan listas de todo para planificar, rastrear progreso y recuperarse después de interrupciones. Si el estado de todo no es thread-safe, las actualizaciones concurrentes pueden corromper el plan. Si el estado de todo no es visible en el contexto del mensaje, el modelo puede perder pista de compromisos. Inyectar todos en la lista de mensajes hace que el estado de tarea sea parte del contexto del modelo, mientras que las mejoras de multithreading reducen condiciones de carrera alrededor de actualizaciones.

La corrección del formato de cable de function_call_output.output es pequeña pero crítica. El lanzamiento lo corrige para que sea un string JSON en el cable. Los formatos de salida de herramientas son contratos entre tiempo de ejecución, SDKs, modelos y clientes. Si un lado espera un string y otro lado envía JSON estructurado directamente, la deserialización o reproducción puede fallar. Los frameworks de agentes deben ser estrictos con estos contratos de cable porque las salidas de herramientas a menudo se almacenan, transmiten, compactan y se reanudan más tarde.

La generación de números de secuencia obtiene una corrección para IDs duplicados o fuera de orden. El ordenamiento de eventos es fundamental para UIs y logs de agentes. Si dos eventos comparten un número de secuencia o llegan con ordenamiento inconsistente, los clientes pueden renderizar estado obsoleto, descartar actualizaciones o desasociar incorrectamente resultados de herramientas. En una conversación multi-agente o multipartita, los bugs de ordenamiento son especialmente dolorosos porque el usuario no puede decir qué agente dijo o hizo qué primero.

Las correcciones de re-ingreso de workflow y parsing de YAML hablan de la confiabilidad de agentes declarativos. Un loop de QuestionExecutor después de re-ingreso de GotoAction es el tipo de bug que convierte la conveniencia del workflow declarativo en comportamiento descontrolado. El parsing de block scalar de YAML para file skills importa porque las definiciones de skills basadas en archivos a menudo contienen prompts, instrucciones, ejemplos o scripts. Si los block scalars se parsean incorrectamente, la skill que el agente ve no es la skill que el desarrollador escribió.

La recomendación práctica es evaluar esta versión a través de las superficies de producción. Si usas Microsoft Agent Framework, inspecciona cómo la orquestación elige el siguiente actor, define listas de permitidos de herramientas de navegador antes de conectar sitios externos, conecta la observabilidad antes del despliegue, trata los eventos de razonamiento como un canal de IU gobernado, prueba el estado de tareas bajo concurrencia y valida la compatibilidad del cableado para las salidas de herramientas. Los lanzamientos de frameworks no son solo nuevas abstracciones; son cambios en los contratos de runtime de los que depende tu aplicación.

[50:00] Cierre

La conclusión práctica del EP048 es operativa. Codex 0.130.0 hace que las sesiones de agente de codificación sean más similares a servicios con servidores de aplicaciones de control remoto, vistas de hilos paginados, visibilidad de ganchos de plugins, actualización de configuración y mejor recuperación alrededor de parches y compactación. La investigación de Semantic Kernel de Microsoft muestra cómo los argumentos de herramientas controlados por modelos pueden convertirse en ejecución de código si los frameworks los transforman en expresiones de lenguaje host interpretadas. GitHub Copilot SDK proporciona a productos integrados ganchos de aprobación y recuperación más diagnósticos. Microsoft Agent Framework 1.5 impulsa la orquestación, la política de navegador, la observabilidad, el transporte de eventos, el estado de tareas y la corrección del formato de cableado. Para los constructores, el trabajo es hacer que cada límite de runtime del agente sea explícito: plano de control, entrada de herramientas, evento de aprobación, política de navegador, telemetría y estado de hilo almacenado.