OpenAI DevDay 2026: todas as novidades do stack de agentes

O OpenAI DevDay 2026, realizado em 29 de setembro, apresentou os agentes Dots sempre ativos, o modelo GPT-6.1 Sol, o Codex Cloud, o suporte a MCP Events e uma plataforma de plugins mais ampla, entre mais de 20 anúncios. Juntos, eles transformam o ChatGPT e o Codex em um stack de agentes que atua em sistemas conectados, colocando permissões e entradas não confiáveis no centro da segurança de aplicações.

Os anúncios do OpenAI DevDay apontam para uma mudança no funcionamento do software de IA. Agora, um modelo pode fazer parte de um fluxo de trabalho mais longo: receber um objetivo, reunir contexto de aplicativos conectados, usar um navegador ou ambiente de programação e continuar quando novas tarefas chegarem. O resumo do DevDay abrange atualizações para consumidores, desenvolvedores e empresas, mas o fio condutor é um agente capaz de atuar em vários sistemas. Alguns anúncios são lançamentos novos, outros ampliam produtos existentes e vários ainda são prévias.

Isso viabiliza automações úteis. Também coloca permissões, entradas não confiáveis e evidências do que um agente realmente fez entre as principais questões de segurança de aplicações.

Ilustração original da Plexicus sobre o stack de agentes anunciado; não é uma captura de tela de um produto da OpenAI.

Agentes persistentes se conectam ao trabalho

Dots são os agentes sempre ativos da OpenAI. Cada dot tem um computador na nuvem, navegador, contexto persistente e acesso a aplicativos conectados, sujeito às permissões e aprovações configuradas. A OpenAI descreve a pesquisa proativa como trabalho de fundo somente para leitura; outras ações dependem das permissões mais amplas do dot. Essa diferença importa: observar um problema novo, preparar uma alteração e executar essa alteração não devem ser tratados como uma única permissão.

A OpenAI também descreveu dots especialistas, com identidades organizacionais e acesso dedicado. Essa é uma direção de piloto, não uma frota empresarial disponível para todos. Para equipes que avaliam agentes persistentes, cada identidade deve ter uma pessoa responsável, acesso restrito e um registro de suas ações. Um modelo de ameaças em camadas, como o OWASP MAESTRO para IA agêntica, ajuda a mapear onde cada controle deve ficar.

O GPT-6.1 Sol fornece outra parte do stack. A OpenAI o posiciona para programação, uso do computador e fluxos de trabalho mais longos (documentação do modelo). O menor custo por tarefa pode tornar práticas as execuções repetidas de agentes, mas um modelo capaz não comprova que sua saída é segura nem que suas ações estão autorizadas.

Modelos mais rápidos e infraestrutura privada

A OpenAI também ampliou o Ultrafast, um nível premium de velocidade. No DevDay, informou até 300 tokens por segundo para o GPT-6 Astra Ultrafast, com o GPT-6.1 Sol Ultrafast previsto para depois (resumo do DevDay). Esses são dados de desempenho divulgados pela OpenAI, não uma previsão para toda carga de trabalho. A velocidade importa porque um agente pode realizar dezenas de etapas sequenciais de raciocínio e uso de ferramentas. Reduzir a latência de cada etapa pode mudar a sensação de interatividade do fluxo. Isso não elimina a necessidade de conferir o resultado.

Os anúncios de privacidade tratam de outra limitação. O Zero Data Retention with Private Safety Processing é descrito para clientes de API elegíveis que precisam de processamento automatizado de segurança sem que a OpenAI retenha prompts e respostas; a arquitetura pode usar armazenamento em nuvem gerenciado pelo cliente. O Private Inference foi apresentado como recurso futuro, com computação confidencial e controles verificáveis no projeto proposto. Antes de tratar uma prévia como uma garantia já vigente sobre o tratamento de dados, as equipes devem avaliar o serviço e o contrato que realmente têm à disposição. Isso é importante quando agentes conseguem ler código-fonte, mensagens internas e dados de clientes.

De sessões de programação ao trabalho contínuo com software

Codex Cloud oferece aos agentes de programação ambientes de nuvem reutilizáveis. Junto com a revisão de código e o Codex Security Cloud, isso aponta para um fluxo no qual agentes inspecionam um repositório, propõem alterações, executam verificações e analisam achados de segurança sem depender do notebook aberto de um desenvolvedor.

O limite de segurança abrange o repositório e os sistemas ao redor: código-fonte, dependências, segredos, CI, issues e pull requests. Um patch gerado por agente ainda exige revisão do comportamento afetado; nossa análise das vulnerabilidades em pull requests geradas por IA mostra por quê. Um teste aprovado diz algo sobre os casos testados; não prova que todos os caminhos de autorização ou endpoints expostos são seguros.

A Codex CLI atualizada adiciona comandos por voz, uma visualização /agents e melhorias para acompanhar e retomar várias tarefas de agentes (resumo do DevDay). A mudança operacional importante é que uma pessoa desenvolvedora pode supervisionar vários agentes em paralelo. Isso torna a responsabilidade pelas tarefas e a origem de cada alteração de código mais importantes do que a interface usada para iniciá-las.

A experiência de desktop do Code Review traz resumos, diffs, perguntas e revisão na nuvem para o fluxo de trabalho do desenvolvedor. A revisão automática na nuvem depende de conexão e configuração do repositório. O Codex Security Cloud pode analisar repositórios conectados sob demanda ou conforme um cronograma, investigar descobertas e preparar correções enquanto a máquina local está offline. Essas opções ajudam a encurtar o ciclo de feedback, mas as descobertas ainda precisam de evidências de alcançabilidade e impacto — a lacuna que o Deep Code Analysis foi criado para fechar. As correções propostas precisam de um novo teste do comportamento alterado, como descrevemos em nosso playbook de remediação autônoma.

O guia de uso do computador da Agents API acrescenta outra interface. Quando um agente consegue clicar em aplicativos, uma página visível se torna contexto da tarefa e também pode carregar instruções maliciosas. Mantenha as sessões do navegador restritas ao objetivo, limite aquilo a que elas podem acessar e exija revisão antes de alterações importantes.

A Agents API mais ampla reúne orquestração, uso de ferramentas, gerenciamento de contexto, conexões MCP e sandboxes em uma única superfície de desenvolvimento. A OpenAI hospeda o navegador para o uso do computador, enquanto o aplicativo do desenvolvedor continua controlando o acesso a sites e o fluxo de trabalho ao redor. A Decisions API, anunciada em prévia limitada, segue um caminho mais restrito: os desenvolvedores fornecem um conjunto finito de respostas permitidas, e o modelo escolhe entre elas (resumo do DevDay). Saídas limitadas podem ajudar no roteamento ou na classificação, mas uma resposta escolhida pelo modelo não deve, por si só, autorizar uma operação sensível.

O resumo do DevDay também destaca o Amazon Bedrock Managed Agents powered by OpenAI. Trata-se da ampliação de uma parceria anterior com a AWS, e não de uma tecnologia que surgiu no DevDay. A AWS descreve identidade, memória, capacidade computacional, controles de segurança e logs de auditoria dos agentes dentro de sua infraestrutura. Empresas que o adotarem ainda precisam mapear esses controles para as próprias permissões e processos de revisão.

MCP Events adiciona um caminho de entrada

A OpenAI está adicionando suporte à especificação proposta de MCP Events. Em vez de consultar um serviço periodicamente, o ChatGPT pode assinar eventos de um servidor MCP. A OpenAI documenta a entrega de webhooks assinados, IDs de eventos, filtros, verificações de autorização e proteções contra loops de feedback.

Um evento pode ser útil: um novo relatório de bug pode iniciar uma investigação e preparar uma correção preliminar. Mas o conteúdo do evento vem de fora do limite de instruções do agente. Um relatório falsificado ou escrito com intenção maliciosa precisa continuar sendo dado da tarefa, mesmo quando chega por um webhook válido. A autenticação identifica qual serviço enviou o evento; ela não torna seguro obedecer a cada frase do payload.

Ilustração original da Plexicus sobre um fluxo de MCP Events; não é uma captura de tela de um produto da OpenAI.

Plugins e suas extensões de interface ampliam esse caminho. Um plugin pode expor ferramentas, dados e interfaces interativas a um agente. Analise os escopos solicitados, o provedor, o tratamento de dados e as ações de escrita como faria com qualquer integração de software (guia de segurança de plugins da OpenAI).

A documentação de plugins da OpenAI agora descreve pacotes que combinam skills, um servidor MCP, uma interface e conexões externas. As Plugin Extensions podem fornecer barras laterais, painéis, editores, formulários e contexto compartilhado com uma conversa. O Plugin Creator e um processo de envio revisado pretendem facilitar a criação e publicação; a OpenAI descreve um diretório compartilhado entre ChatGPT e Codex. Um canal de distribuição maior também aumenta a importância de avaliar os softwares e escopos por trás de um botão de instalação conveniente.

O Sites pode hospedar plugins compatíveis, permitindo que uma página compartilhada com IA ofereça recursos conectados a várias pessoas. A página pode ser comum, mas os dados e as ações de cada usuário ainda precisam obedecer às permissões individuais. Para desenvolvedores, esse é um caminho de hospedagem de aplicações. Para as equipes de segurança, é mais um lugar para verificar o limite entre contexto compartilhado e autoridade individual (resumo do DevDay).

Space transforma o stack em trabalho compartilhado

ChatGPT Space é o espaço da OpenAI para páginas, arquivos, planilhas, apresentações e agentes. O Pages permite que pessoas e agentes editem um documento em conjunto, usando contexto conectado e atualizando-o ao longo do tempo. Apresentações colaborativas foram mostradas como novidade futura, com geração, edição, comentários e exportação. Uma página compartilhada que se atualiza a partir de ferramentas é útil, mas os responsáveis precisam saber quais são os dados de origem, a instrução de atualização e o público.

Teams e Team Tasks colocam o trabalho agendado ou acionado por eventos em um ambiente organizacional compartilhado. A OpenAI também planeja o @ChatGPT no Slack e no Microsoft Teams, onde um agente poderá participar de um canal ou thread usando ferramentas aprovadas e as permissões pertinentes dos usuários (resumo do DevDay). Isso reduz a distância entre discussão e ação. Também traz uma pergunta direta: de quem é a autoridade de uma solicitação feita em uma conversa em grupo?

O plugin Meetings pode transformar uma conversa gravada em notas e itens de ação no aplicativo para macOS e alimentar tarefas de acompanhamento. A OpenAI diz que o áudio da reunião é apagado quando as notas ficam prontas. Mesmo assim, as equipes devem considerar o consentimento, a retenção das notas resultantes e se uma sugestão falada deve se tornar uma tarefa executável. Os perfis compartilháveis facilitam encontrar determinados trabalhos; os controles de compartilhamento do workspace continuam definindo quem pode acessá-los.

Identidade, planos e distribuição

O Sign in with ChatGPT permite que usuários elegíveis usem o consumo de seus planos em aplicativos de terceiros participantes, com controles da franquia de cada aplicativo (ajuda da OpenAI). Assim, o ChatGPT se torna tanto uma opção de login quanto uma fonte portátil de uso. A análise de segurança é familiar: identifique o terceiro, verifique os acessos concedidos e saiba como revogá-los.

O Pro 500 é o novo plano individual de alto uso, com acesso ao Astra Ultrafast quando disponível. O OpenAI Marketplace permite que empresas elegíveis direcionem parte de seu compromisso comercial para softwares de parceiros aprovados. Ambos foram anunciados no resumo do DevDay. Eles mudam como a capacidade de agentes e as integrações podem ser compradas, mas não eliminam a necessidade de avaliar as ferramentas que recebem dados organizacionais.

O que as equipes de AppSec devem verificar após o OpenAI DevDay

O principal risco é uma cadeia de recursos razoáveis quando vistos isoladamente: um agente lê uma mensagem, consulta um repositório, usa um navegador e depois altera um ticket ou abre uma pull request. O dano depende de onde o conteúdo não confiável passa a ser tratado como autoridade e do que o agente pode fazer em seguida.

Ilustração original da Plexicus sobre a superfície de ataque de um agente; não é uma captura de tela de um produto da OpenAI.

Para cada fluxo de trabalho, as equipes de segurança devem verificar:

• Identidade e escopo: quais credenciais cada agente possui, o que pode ler ou alterar e quando o acesso expira.
• Limites de entrada: páginas recuperadas, mensagens, payloads de eventos e resultados de ferramentas continuam sendo dados não confiáveis? (Prompt injection é a primeira categoria do OWASP Top 10 para Aplicações LLM).
• Controles de ação: quais gravações exigem aprovação humana e a aprovação se aplica à ação e ao destino exatos?
• Rastreabilidade: os logs conectam um evento à decisão do agente, às chamadas de ferramentas, à alteração resultante e ao revisor?
• Validação: uma descoberta é alcançável e explorável dentro do escopo autorizado — por exemplo, em um AI Swarm Pentest — e a correção foi testada novamente?

O adendo de segurança do GPT-6.1 Sol da OpenAI apresenta resultados de avaliações de cibersegurança e descreve salvaguardas de implantação. São resultados de benchmark divulgados pelo fornecedor sob condições específicas de avaliação, não uma medida da segurança de toda implantação de agentes. O aplicativo, as permissões, as integrações e os controles humanos continuam determinando a exposição real.

A questão permanente de AppSec do DevDay é prática: conforme os agentes operam por mais tempo e em mais sistemas, as equipes conseguem demonstrar quais ações foram permitidas, quais evidências as embasaram e se o software resultante é seguro? A verificação orientada por provas precisa acompanhar todo o fluxo, do evento recebido até a alteração final.

Perguntas frequentes