OpenAI revela como protege o Codex: sandboxes, aprovações e auditoria das ações do agente

Em 8 de maio de 2026, a OpenAI explicou como limita o Codex em seus fluxos de trabalho internos. A ideia é simples: o agente de código deve acelerar o desenvolvimento, mas sem ganhar acesso irrestrito a arquivos, rede e infraestrutura.

Limites para o Codex

A primeira camada de proteção é a sandbox. Ela define os limites técnicos: onde o Codex pode gravar, quais diretórios aceitam escrita, se o acesso à rede é permitido e quais caminhos continuam protegidos.

Sobre essa base funciona uma política de aprovações. Se o agente precisar fazer algo fora do ambiente permitido, ele é obrigado a pedir confirmação. O usuário pode aprovar uma ação específica ou liberar aquele tipo de ação até o fim da sessão. Isso reduz o risco de operações acidentais e pouco transparentes.

A OpenAI também usa o modo Auto-review. Quando o Codex está prestes a ultrapassar os limites da sandbox, ele envia o plano da ação e o contexto recente para um subagente de aprovação automática. Esse subagente pode liberar automaticamente solicitações de baixo risco e, em alguns casos, também as mais sensíveis, se o usuário já tiver nível de autorização suficiente. Assim, tarefas rotineiras não travam o trabalho, e ações potencialmente perigosas continuam passando por verificação.

«Manter o agente dentro de limites técnicos claros, acelerar ações de baixo risco e destacar explicitamente as arriscadas» — é assim que a

OpenAI descreve o objetivo desse esquema.

Rede, acessos e regras

A segunda camada é o controle de acessos. A OpenAI não dá ao Codex acesso livre de saída à internet: a política de rede permite destinos esperados, bloqueia os indesejados e exige aprovação para domínios desconhecidos. Até a busca e o web fetch podem ser restritos a respostas em cache.

As credenciais da CLI e do MCP OAuth ficam no keyring do sistema, o login é obrigatoriamente feito via ChatGPT e o acesso é vinculado a um workspace enterprise específico. O objetivo é manter a atividade do agente dentro dos perímetros de controle corporativos.

• Os modos de sandbox permitidos são apenas read-only e workspace-write
• Somente diretórios de trabalho conhecidos de antemão são liberados automaticamente para escrita
• Na rede, é possível ativar um proxy, permitir localhost e bloquear domínios específicos
• Endereços conhecidos, como *.openai.com, podem passar sem aprovação manual
• Os requisitos administrativos não podem ser desativados pelo usuário

Há também regras específicas para comandos de shell. O Codex não trata todos os comandos como igualmente seguros: operações comuns de read-only podem passar sem confirmação mesmo fora da sandbox, enquanto padrões perigosos podem ser bloqueados ou enviados para revisão.

No exemplo da OpenAI, a leitura de pull requests via gh pr view e list é liberada sem perguntas extras, assim como o diagnóstico de Kubernetes via kubectl get, describe e logs. A empresa distribui a política base por meio de managed configs e requirements, de modo que o mesmo perímetro vale no desktop app, na CLI e na IDE extension.

Logs com contexto

A OpenAI ressalta que restrições, sozinhas, não bastam. Os logs de segurança comuns mostram bem o que aconteceu: um processo foi iniciado, um arquivo foi alterado, houve uma tentativa de conexão de rede. Mas, com eles, é difícil reconstruir a intenção do agente e do usuário.

Por isso, o Codex consegue exportar logs OpenTelemetry com um contexto mais voltado ao agente: as solicitações originais do usuário, as decisões de approvals, os resultados das chamadas de ferramentas, o uso de servidores MCP e os eventos do proxy de rede — o que foi permitido e o que foi bloqueado. Para clientes Enterprise e Edu, essa atividade também fica disponível na Compliance Logs Platform, e os registros podem ser centralizados em sistemas de SIEM e compliance.

Internamente, a OpenAI usa esses dados em um agente de AI para security triage. Se a proteção de endpoint sinaliza uma ação estranha do Codex, a equipe de segurança analisa não só o alerta, mas também os logs associados: qual foi a solicitação original, quais ferramentas foram executadas, o que o agente tentou fazer, quais decisões a rede tomou e onde foi exigida aprovação.

Isso ajuda a separar mais rápido o comportamento esperado de um erro inofensivo e de um caso que realmente exige escalação. Os mesmos logs também têm uso operacional: entender como cresce o uso interno do Codex, quais ferramentas são mais procuradas e onde a política ainda precisa de ajustes.

O que isso significa

Na prática, a OpenAI apresenta um modelo corporativo para agentes de código: em vez de trocar controle por um modelo inteligente, o modelo opera dentro de um ambiente rigidamente configurado, com auditoria e regras. Para empresas que querem adotar esse tipo de assistente, é um sinal de que a principal questão de produto agora envolve não só a qualidade do modelo, mas também o quanto ele se encaixa em segurança, compliance e processos internos.