Controle Remoto do Codex, Fortalecimento de RCE do Agente, Ganchos de Sessão do Copilot e Microsoft Agent Framework 1.5

[00:00] O Codex 0.130.0 oferece aos operadores de coding-agent um plano de controle mais limpo. O recurso principal é codex remote-control, um ponto de entrada mais simples para iniciar um app-server headless que pode ser controlado remotamente. Isso é importante porque coding agents não são mais apenas ferramentas de terminal. Eles são sessões de app-server com threads, snapshots de configuração, superfícies de plugins, eventos de review, visualizações de arquivos e clientes remotos que podem precisar inspecionar ou continuar o trabalho sem estar dentro do terminal original. Esta versão também adiciona visualizações de threads paginadas, metadados de hooks de plugins, atualização de configuração live melhorada, diffs de turns mais precisos após falhas parciais de patch, resolução de imagens multi-ambiente e telemetria mais rica para depuração de fluxos de review.

[02:00] HISTÓRIA 1 — OpenAI Codex 0.130.0 Adiciona App Servers Remote-Control, Visualizações de Threads Paginas, Visibilidade de Hooks de Plugins e Reparo de Estado Melhorado Comece pelo ponto de entrada remote-control. Um app-server headless é um objeto operacional diferente de uma execução de CLI única. O servidor controla sessões, threads, configuração, seleção de ambiente, execução de ferramentas e conexões de clientes. Adicionar um comando codex remote-control de alto nível reduz o atrito para iniciar esse plano de controle diretamente. Para desenvolvedores que integram coding agents em dashboards, IDEs, clientes de navegador ou máquinas de desenvolvimento remoto, essa é a superfície que transforma um assistente local em um endpoint de serviço.

O mecanismo importante é a separação de controle e trabalho. O app-server pode manter uma sessão de codificação ativa enquanto um cliente se reconecta, navega por uma thread grande, abre uma visualização de resumo ou solicita uma visualização de item completo apenas quando necessário. O Codex 0.130.0 adiciona paginação de threads grandes onde os clientes podem solicitar visualizações de itens de turn não carregados, resumidos ou completos. Isso não é apenas polish de UI. Threads de agentes podem se tornar enormes porque incluem turns de usuário, turns de modelo, chamadas de ferramentas, diffs, referências de arquivos, aprovações, imagens e resumos compactados. Carregar tudo em todos os clientes desperdiça memória, aumenta latência e torna clientes remotos frágeis.

Uma API de thread paginada dá ao app-server espaço para tratar a materialização de thread como um contrato. Um item não carregado pode preservar ordenação e identidade sem transferir payload. Um item de resumo pode fornecer contexto suficiente para navegação. Um item de turn completo pode ser buscado quando o usuário abre o detalhe. Esse padrão é familiar em logs, traces e linhas do tempo de issues, e coding agents agora precisam dele porque suas transcrições são registros operacionais, não apenas texto de chat.

Detalhes de plugins agora mostram hooks bundled, e o compartilhamento de plugins expõe metadados de link além de controles de discoverability. Hooks são parte do comportamento real de runtime de um plugin. Se um plugin pode modificar startup, observar uma chamada de ferramenta, fornecer um comando ou participar de review, os operadores precisam ver isso antes de instalá-lo ou compartilhá-lo. Esconder hooks dentro de um pacote transforma review de plugin em adivinhação. Mostrá-los nos detalhes do plugin torna a superfície de execução auditável.

A versão também repara o comportamento de configuração do app-server live. Threads de app-server live agora capturam mudanças de configuração sem exigir restart. Em um runtime de agente, a configuração pode incluir escolhas de modelo, políticas de aprovação, configurações de provider, disponibilidade de ferramentas, estado de plugin, seleção de ambiente e opções de telemetria. Se uma thread de longa execução continua usando configuração obsoleta, operadores podem acreditar que mudaram a política enquanto um agente ativo continua com configurações antigas. Atualizar threads live do snapshot de configuração mais recente faz as mudanças de política entrarem em vigor onde o trabalho está acontecendo.

Diffs de turns ganham um conserto particularmente prático. O Codex agora mantém diffs precisos nas operações de apply_patch, incluindo falhas parciais que ainda mutaram arquivos. Esse modo de falha é importante. Um patch pode falhar no meio mas ainda assim alterar parte de um arquivo. Se o runtime reportar o diff errado depois, o usuário não pode confiar na visualização de review, lógica de rollback ou trilha de auditoria. Rastreamento de diff baseado em operações é a direção certa: registre o que a operação realmente mudou, não o que o patch ideal deveria ter mudado.

Consertos no ThreadStore melhoram resumos, renames, resume e caminhos de fork, incluindo threads sem caminhos de rollout local. Isso significa que a camada de armazenamento de thread está se tornando a fonte de verdade para mais operações de lifecycle. Resume e fork são especialmente importantes para coding agents porque um usuário pode querer ramificar uma investigação, continuar uma execução falhada ou abrir uma thread de um cliente remoto que não tem o caminho de rollout local original. Se a identidade da thread depender demais do estado do filesystem local, fluxos de trabalho remotos e headless quebram.

Compactação remota também recebe consertos de contrato de stream. O Codex agora emite response.processed para streams v2 e evita enviar service_tier em requisições de compact com API key. Compactação é como sessões longas permanecem utilizáveis, mas compactação remota precisa falar a mesma linguagem de eventos do resto do app-server. Um evento processed faltando pode deixar clientes esperando por um estado terminal. Enviar campos não suportados em uma requisição de compact pode quebrar apenas o caminho de compactação enquanto turns normais ainda funcionam, o que é difícil de diagnosticar.

Suporte multi-ambiente aparece em view_image, que agora pode resolver arquivos através do ambiente selecionado. Coding agents frequentemente operam através de host, container, sandbox, workspace remoto ou projeto montado. Um caminho de imagem não é significativo a menos que o runtime saiba qual ambiente o possui. Resolver através do ambiente selecionado impede um cliente de acidentalmente olhar para o filesystem errado ou falhar em exibir um artefato que existe dentro do sandbox ativo.

Suporte a autenticação Bedrock agora aceita credenciais de console-login da AWS dos perfis de aws login. Isso é uma conveniência para operadores com impacto real de deployment. Muitas equipes já gerenciam acesso AWS através de fluxos baseados em perfil. Permitir que o Codex use esses perfis reduz caminhos de credenciais duplicados e faz a autenticação de model-provider se alinhar com controles de acesso cloud existentes.

As mudanças de telemetria são úteis para depuração em produção. O Codex adiciona metadados de trace OpenTelemetry configuráveis e analytics de review e feedback mais ricos. Eventos de review são uma parte central da segurança de coding-agent. Se um comando foi aprovado, negado, retentado ou escalado, operadores precisam de contexto de trace suficiente para entender por quê. Boa telemetria deve conectar sessão, turn, chamada de ferramenta, decisão de aprovação, requisição de modelo e resultado visível ao usuário sem vazar segredos.

A recomendação prática é tratar deployments de app-server do Codex como deployments de serviço. Fixe a versão, inicie remote-control deliberadamente, documente quais clientes podem se conectar, audite hooks de plugins antes de compartilhar, mantenha o comportamento de atualização de configuração em mente e teste casos de falha de patch. A versão não é apenas sobre novos comandos; é sobre tornar um coding agent controlável, inspecionável e recuperável quando sessões crescem grandes e rodam remotamente.

[16:00] HISTÓRIA 2 — A Pesquisa de RCE do Semantic Kernel da Microsoft Transforma Prompt Injection em uma Lição de Limite de Execução de Ferramentas O post de segurança da Microsoft é um lembrete direto de que prompt injection se torna mais perigoso quando linguagem é conectada a ferramentas. O modelo não é o componente vulnerável no estudo de caso. O modelo recebe texto, decide chamar uma ferramenta e preenche argumentos de ferramentas. O limite vulnerável é o código do framework e plugin que confia nesses argumentos e os transforma em comportamento host executável.

O primeiro problema disclosure centra-se no caminho de busca do Vector Store In-Memory do Semantic Kernel. O exemplo de agente expõe uma função de busca de hotel. Um usuário pede hotéis em uma cidade. O modelo chama o plugin de busca com um argumento city. O plugin constrói um filtro determinístico para refinar o dataset antes da similaridade vetorial. O passo arriscado é que um argumento controlado pelo modelo é interpolado em uma expressão lambda Python e então executado com eval().

Esse é o limite de execução. Um valor normal de cidade se torna uma expressão de filtro. Um valor malicioso pode fechar uma aspa e adicionar lógica Python. O prompt injection não precisa de exploit de navegador, anexo malicioso ou corrupção de memória. Ele precisa que o framework do agente pegue um parâmetro derivado de linguagem e o coloque em uma expressão executável. Uma vez que isso acontece, prompt injection se tornou injeção de código.

A mitigação tentada usou validação AST e um ambiente de builtins restrito. Em alto nível, o validador permitia expressões lambda, escaneava nomes e atributos em busca de identificadores perigosos e executava com __builtins__ removido. Isso soa razoável, mas linguagens dinâmicas tornam blocklists frágeis. Os pesquisadores da Microsoft contornaram o filtro sem usar os nomes bloqueados óbvios diretamente. O payload atravessava estruturas de objetos Python para localizar machinery de import e alcançar execução de comandos de sistema através de atributos alternativos.

A lição não é simplesmente "não use eval." A lição mais ampla é que argumentos de chamada de ferramenta são input não confiável mesmo quando vieram de um modelo, mesmo quando o usuário não digitou código diretamente e mesmo quando o schema diz que o campo é um nome de cidade. Um modelo pode ser induzido a colocar strings controladas por atacante em qualquer argumento que ele tem permissão para preencher. Se a ferramenta então interpreta essa string como código, uma linguagem de query, um comando shell, um caminho de arquivo ou um template, o framework criou um sink de injeção.

Busca vetorial torna isso fácil de subestimar porque parece infraestrutura de recuperação em vez de execução de código. Mas stores vetoriais frequentemente suportam filtros de metadados, linguagens de expressão, predicados customizados, prefilters de embedding, rerankers e strings de query específicas de connectors. Cada um desses pode se tornar um limite de injeção se valores controlados por usuário ou modelo forem concatenados em uma expressão interpretada. Design seguro geralmente significa filtros parametrizados, DSLs tipadas, operadores em allowlist e validação que rejeita estrutura inesperada antes da execução.

Um reparo robusto deve remover a construção de código de string do caminho padrão. Ao invés de gerar uma string lambda, um framework pode construir um predicado a partir de campos tipados e operadores. Por exemplo, campo equals valor deve ser dado, não código fonte. Se uma linguagem de filtro for inevitável, o runtime deve parsear em um AST restrito e avaliar com um interpretador que só entende as operações permitidas. Ele não deve chamar o avaliador da linguagem host e tentar bloquear comportamento perigoso depois.

O princípio do privilégio mínimo também é importante. Plugins de busca não devem executar com os mesmos privilégios de sistema de arquivos, processo e rede do aplicativo host se não precisarem deles. Um predicado de busca de hotéis não precisa de acesso ao shell. Se um bug no framework transformar um filtro em execução de código, o sandbox e os privilégios do processo determinam o raio de impacto. Frameworks de agentes devem isolar a execução de plugins, limitar variáveis de ambiente, evitar passar credenciais para processos genéricos de ferramentas e registrar parâmetros de ferramentas com cuidado suficiente para resposta a incidentes.

Detecção é prático. Equipes que usam frameworks de agentes devem inventariar ferramentas que executam templates, filtros, comandos shell, células de notebooks, snippets Python, snippets JavaScript, SQL ou operações de arquivo. Elas devem procurar por valores controlados pelo modelo passados para esses interpretadores. Devem corrigir o Semantic Kernel e pacotes relacionados, mas também revisar plugins personalizados porque o mesmo padrão aparece no código da aplicação. Segurança de injeção de prompt não é apenas um problema de avaliação de modelo; é validação de entrada e isolamento de execução para runtimes de ferramentas.

A conclusão para operadores é direta: cada ferramenta de agente é um endpoint de API cujo chamador é parcialmente controlado pelo modelo. Trate schemas de ferramentas como contratos de API externos. Valide entradas no limite da ferramenta. Prefira estruturas de dados tipadas em vez de strings interpretadas. Mantenha as permissões de plugins restritas. Registre o suficiente para reconstruir qual prompt causou quais argumentos de ferramenta. E teste injeção de prompt tentando forçar o agente a passar parâmetros hostis para ferramentas, não apenas verificando se o modelo diz palavras unsafe.

[28:00] HISTÓRIA 3 — GitHub Copilot SDK Adiciona Ganchos de Aprovação de Plano e Modo de Limite de Taxa, além de Diagnósticos Cross-SDK A pré-release do Copilot SDK de 8 de maio é sobre incorporar sessões de agentes em produtos com controle de runtime mais explícito. Aplicações podem agora registrar callbacks para exitPlanMode.request e autoModeSwitch.request. Esses eventos são importantes porque o modo plano e a troca automática de modelo são decisões de produto, não apenas decisões de modelo.

O modo plano é uma fronteira entre propor trabalho e fazer trabalho. Em um agente de codificação embutido, a aplicação pode querer que um humano aprove o plano, que um motor de políticas o verifique, ou que uma regra específica do projeto bloqueie certas mudanças. Os novos handlers permitem que aplicações decidam se uma solicitação de saída do modo plano é aprovada. Isso dá ao produto host um ponto claro de interceptação antes que o runtime passe do planejamento para a execução.

A troca automática de modelo após limites de taxa é um tipo diferente de fronteira. Um runtime pode querer se recuperar de eventos de limite de taxa mudando para outro modelo ou modo. Isso pode preservar a continuidade, mas também pode mudar comportamento, custo, latência ou capacidade. O handler autoModeSwitch.request permite que a aplicação decida se aceita essa troca. Para produtos enterprise, isso é importante porque a escolha do modelo pode estar vinculada a política de dados, conformidade, linhas de base de avaliação ou controles de orçamento.

A release também adiciona diagnósticos estruturados em .NET, Python e Rust. Os logs cobrem início da CLI, conexão TCP, tempo das requisições JSON-RPC, ciclo de vida da sessão e caminhos de erro. Essa é exatamente a visibilidade que um SDK de agente embutido precisa. Quando uma sessão falha, a causa pode ser início do processo, transporte, autenticação, enquadramento JSON-RPC, tratamento de eventos do runtime, resposta do modelo, execução de ferramentas ou comportamento de callback do host. Sem logs estruturados de tempo e ciclo de vida, toda falha parece "o agente travou".

O detalhe do JSON-RPC vale destaque. Muitos SDKs de agentes de codificação envolvem um processo de runtime local e se comunicam via JSON-RPC. Isso significa que existe um objeto cliente na aplicação, um processo de runtime, uma conexão de transporte, IDs de requisição, streams de eventos e operações de longa duração. Diagnósticos precisam mostrar quando o runtime iniciou, quando a conexão TCP abriu, quais requisições JSON-RPC foram enviadas, quanto tempo levaram e onde erros surgiram. Caso contrário, desenvolvedores de aplicações não conseguem distinguir uso incorreto do SDK de falha do runtime.

A opção enableSessionTelemetry torna a telemetria uma escolha explícita de sessão. Esse é o formato certo para privacidade e operações. Algumas implantações querem telemetria de sessão interna para debugar problemas e melhorar qualidade do produto. Outras precisam que esteja desabilitada por política. Colocar o controle na configuração de sessão e configuração de resume torna a decisão auditável e repetível em vez de depender de padrões ocultos.

Existem correções menores de compatibilidade que importam para usuários de SDK de longa duração. Enums de eventos de sessão C# agora são structs readonly com backing de string para que a desserialização não falhe quando o runtime adiciona novos valores de enum. Isso é compatibilidade direta para streams de eventos. Blobs de recursos de resultados de ferramentas binárias Rust agora padrão para application/octet-stream quando mimeType está ausente. Isso é uma correção de resiliência de formato de wire. Ambas as mudanças reduzem quebra quando runtimes e SDKs evoluem em velocidades diferentes.

A implicação prática para construtores é que sessões do Copilot SDK estão se tornando objetos de runtime controlados pelo host. Se você os incorpora, implemente os callbacks de modo plano e troca de modo deliberadamente. Decida quais trocas podem acontecer automaticamente e quais precisam de revisão. Ative diagnósticos em desenvolvimento e staging. Capture tempo de JSON-RPC ao redor de sessões lentas ou instáveis. Trate telemetria como uma decisão de política. E teste clientes mais antigos contra eventos de runtime mais novos para que compatibilidade direta de enum e eventos não o surpreenda.

[38:00] HISTÓRIA 4 — Microsoft Agent Framework 1.5 Avança em Orquestração, Observabilidade, Política de Ferramenta de Navegação e Semântica de Wire A release de 8 de maio do Microsoft Agent Framework é ampla, mas várias mudanças são diretamente relevantes para construtores de agentes em produção. A linha .NET adiciona Magentic Orchestration, allowlisting de WebBrowsingTool, samples de observabilidade de agente hospedado, eventos de raciocínio em AGUI, melhorias de multithreading de todo e headers de cliente por chamada do Foundry. A linha Python próxima adiciona skills baseadas em classes e providers de contexto de harness experimental. A release também corrige formato de wire de output de ferramenta, loops de workflow, parsing de YAML, serialização multipartidária e numeração de sequência.

Magentic Orchestration é a manchete porque sistemas multiagente precisam de mais do que uma lista de agentes. Eles precisam de agendamento, delegação, propriedade de turno, estado compartilhado, condições de término e uma forma de decidir qual agente deve agir a seguir. Uma camada de orquestração formaliza esses mecanismos. Marcá-la como experimental é apropriado porque semântica de orquestração se torna arquitetura de aplicação: um agendador ruim pode fazer loop, duplicar trabalho, esconder falhas ou deixar um agente dominar a conversa.

O allowlisting de WebBrowsingTool é um controle importante de uso de navegador/computador. Ferramentas de navegação conectam um agente a conteúdo externo que pode ser malicioso, não confiável ou simplesmente distrativo. Um allowlist dá à aplicação host uma superfície de política para quais destinos de navegação ou comportamentos de navegador são permitidos. Em sistemas de agentes, navegação não é apenas ler. O navegador pode buscar conteúdo de injeção de prompt, enviar formulários, seguir redirects, expor cookies e recuperar arquivos. A política precisa existir antes da ferramenta rodar.

Samples de observabilidade de agente hospedado também são valiosos porque implantação é onde abstrações de framework encontram realidade de produção. Um agente hospedado precisa de logs, traces, correlação de requisição, visibilidade de chamada de modelo, tempo de chamada de ferramenta e estado de falha. Samples de observabilidade podem se tornar o padrão de referência para equipes que de outra forma enviariam agentes apenas com logs de console. A pergunta útil para qualquer agente hospedado é: podemos reconstruir uma execução falha desde a requisição externa através da decisão de orquestração, chamada de modelo, chamada de ferramenta e resposta final?

Eventos de raciocínio em AGUI expõem outro problema de transporte. Interfaces de usuário precisam renderizar progresso do agente sem misturar chain-of-thought privado, justificativa de ferramenta e resumos de raciocínio visíveis ao usuário incorretamente. Um canal de eventos de raciocínio permite que o framework represente progresso ou estado relacionado a raciocínio como eventos estruturados. A aplicação ainda precisa decidir o que é seguro mostrar, armazenar e transmitir, mas eventos estruturados são melhores que scraping de texto de um stream.

Multithreading de todo e injeção de todo na lista de mensagens mostram como gerenciamento de estado se torna uma funcionalidade de runtime. Agentes usam listas de todo para planejar, rastrear progresso e se recuperar após interrupções. Se o estado de todo não for thread-safe, atualizações concorrentes podem corromper o plano. Se o estado de todo não for visível no contexto da mensagem, o modelo pode perder o rastreamento de compromissos. Injetar todoss na lista de mensagens torna o estado de tarefa parte do contexto do modelo, enquanto melhorias de multithreading reduzem condições de corrida em torno de atualizações.

A correção de formato de wire de function_call_output.output é pequena mas crítica. A release corrige para ser uma string JSON no wire. Formatos de output de ferramenta são contratos entre runtime, SDKs, modelos e clientes. Se um lado espera uma string e outro envia JSON estruturado diretamente, desserialização ou replay pode falhar. Frameworks de agentes devem ser estritos sobre esses contratos de wire porque outputs de ferramentas são frequentemente armazenados, streamados, compactados e resumidos depois.

Geração de número de sequência recebe uma correção para IDs duplicados ou fora de ordem. Ordenação de eventos é fundamental para UIs e logs de agentes. Se dois eventos compartilharem um número de sequência ou chegarem com ordenação inconsistente, clientes podem renderizar estado obsoleto, descartar atualizações ou associar incorretamente resultados de ferramentas. Em uma conversa multiagente ou multipartidária, bugs de ordenação são especialmente dolorosos porque o usuário não consegue dizer qual agente disse ou fez algo primeiro.

Correções de reentrada de workflow e parsing de YAML falam sobre confiabilidade de agente declarativo. Um loop de QuestionExecutor após reentrada de GotoAction é o tipo de bug que transforma conveniência de workflow declarativo em comportamento descontrolado. Parsing de block scalar YAML para skills de arquivo importa porque definições de skills baseadas em arquivo frequentemente contêm prompts, instruções, exemplos ou scripts. Se block scalars forem parseados incorretamente, a skill que o agente vê não é a skill que o desenvolvedor escreveu.

A recomendação prática é avaliar esta versão através de superfícies de produção. Se você usa o Microsoft Agent Framework, inspecione como a orquestração escolhe o próximo ator, defina listas de permissão de browser-ferramenta antes de conectar sites externos, configure observabilidade antes do lançamento, trate eventos de raciocínio como um canal de IU governado, teste estado de tarefas sob concorrência e valide compatibilidade de protocolo para saídas de ferramentas. Lançamentos de frameworks não são apenas novas abstrações; são mudanças nos contratos de runtime dos quais sua aplicação depende.

[50:00] Encerramento A recomendação prática do EP048 é operacional. O Codex 0.130.0 torna as sessões de agente de codificação mais semelhantes a serviços com servidores de aplicativo de controle remoto, visualizações de thread paginadas, visibilidade de hook de plugin, atualização de configuração e melhor recuperação em torno de patches e compactação. A pesquisa do Semantic Kernel da Microsoft mostra como argumentos de ferramenta controlados por modelo podem se tornar execução de código se os frameworks os transformarem em expressões de linguagem host interpretadas. O GitHub Copilot SDK oferece aos produtos embarcados hooks de aprovação e recuperação além de diagnósticos. O Microsoft Agent Framework 1.5 avança a orquestração, política de navegador, observabilidade, transporte de eventos, estado de tarefas e correção de formato de conexão. Para construtores, o trabalho é tornar cada limite de runtime de agente explícito: plano de controle, entrada de ferramenta, evento de aprovação, política de navegador, telemetria e estado de thread armazenado.