OpenAI detalha as proteções do Codex: sandboxes, aprovações e auditoria das ações do agente

Em 8 de maio de 2026, a OpenAI explicou como restringe o Codex dentro de seus fluxos de trabalho. A ideia é simples: um agente de código deve acelerar o desenvolvimento, mas não ganhar acesso descontrolado a arquivos, redes e infraestrutura.

Limites para o Codex

A primeira camada de proteção é a sandbox. Ela estabelece limites técnicos: onde o Codex pode escrever, quais diretórios estão abertos para escrita, se o acesso à rede é permitido e quais caminhos permanecem protegidos. No topo disso, uma política de aprovação opera. Se um agente precisa fazer algo fora do ambiente permitido, ele deve solicitar confirmação. Um usuário pode aprovar uma ação específica única ou conceder permissão para esse tipo de ação pelo resto da sessão. Isso reduz o risco de operações acidentais e opacas.

Separadamente, a OpenAI usa um modo Auto-review. Quando o Codex está prestes a cruzar um limite de sandbox, ele passa o plano de ação e contexto recente para um subagende de auto-aprovação separado. Esse agente pode automaticamente permitir solicitações de baixo risco e, em alguns casos, até mesmo as mais sensíveis, se o usuário já tiver nível de autorização suficiente. Como resultado, tarefas rotineiras não desaceleram o trabalho, enquanto ações potencialmente perigosas ainda são interrompidas no estágio de revisão.

"Manter um agente dentro de limites técnicos claros, acelerar ações de baixo risco e destacar explicitamente as de risco" — assim a

OpenAI descreve o objetivo deste esquema.

Rede, Acesso e Regras

A segunda camada é o gerenciamento de acesso. A OpenAI não oferece ao Codex acesso livre à internet de saída: a política de rede permite destinos esperados, bloqueia indesejados e exige aprovação para domínios desconhecidos. Até mesmo busca e web fetch podem ser restritos a respostas em cache. Credenciais de CLI e MCP OAuth são armazenadas no keyring do sistema, o login é obrigatório através do ChatGPT, e o acesso está vinculado a um workspace corporativo específico. Isso garante que a atividade do agente permaneça dentro dos limites de controle corporativo.

• Modos de sandbox permitidos — apenas read-only e workspace-write
• A escrita é automaticamente habilitada apenas para diretórios de trabalho pré-conhecidos
• Para rede, você pode ativar um proxy, permitir localhost e bloquear domínios específicos
• Endereços conhecidos como *.openai.com podem passar sem aprovação manual
• Requisitos administrativos não podem ser desabilitados do lado do usuário

Também existem regras separadas para comandos shell. O Codex não considera todos os comandos igualmente seguros: operações padrão apenas-leitura podem ser ignoradas sem confirmação até fora da sandbox, enquanto padrões perigosos são bloqueados ou enviados para revisão. No exemplo da OpenAI, eles permitem sem questões extras ler pull requests através de gh pr view e list, bem como diagnósticos de Kubernetes através de kubectl get, describe e logs. A empresa implementa a política de base através de configs gerenciados e requisitos, então o mesmo framework de controle opera no app desktop, CLI e extensão IDE.

Logs com Explicação

A OpenAI enfatiza separadamente que restrições sozinhas são insuficientes. Logs de segurança padrão mostram bem o que aconteceu: um processo iniciou, um arquivo mudou, houve uma tentativa de conexão de rede. Mas deles é difícil reconstruir a intenção do agente e do usuário. Portanto, o Codex pode exportar logs OpenTelemetry com contexto de agente mais rico: solicitações originais do usuário, decisões de aprovação, resultados de chamadas de ferramentas, uso de servidores MCP e eventos de proxy de rede — o que foi permitido e o que foi bloqueado. Para clientes Enterprise e Edu, essa atividade também está disponível através da Plataforma de Logs de Conformidade, e os logs podem ser centralizados em SIEM e sistemas de compliance.

Dentro da OpenAI, esses dados são usados por um agente IA para triagem de segurança. Quando a proteção de endpoint relata comportamento estranho do Codex, a equipe de segurança não apenas olha para o alerta em si, mas para logs acompanhantes: qual foi a solicitação original, quais ferramentas foram iniciadas, o que o agente tentou fazer, que decisões a rede tomou e onde aprovação foi necessária. Isso ajuda a distinguir mais rapidamente comportamento esperado de um erro inofensivo e de um caso que realmente exige escalação. Os mesmos logs também são usados operacionalmente — para entender como o uso interno do Codex está crescendo, quais ferramentas estão em demanda e onde a política ainda precisa de ajustes.

O Que Isso Significa

A OpenAI está essencialmente demonstrando um modelo corporativo para agentes de código: não um modelo inteligente em vez de controles, mas um modelo dentro de um ambiente rigidamente configurado com auditoria e regras. Para empresas que desejam implantar tais assistentes, este é um sinal de que a principal questão de produto agora não é apenas sobre a qualidade do modelo, mas também sobre quão bem ele se encaixa na segurança, conformidade e processos internos.