Saltar para o conteúdo principal
OpenAI

8 de maio de 2026

GarantiaSegurança

Executar o Codex com segurança na OpenAI

Uma análise dos controlos, limites e telemetria que a OpenAI usa para gerir agentes de programação em fluxos de trabalho reais.

A carregar…

À medida que os sistemas de IA se tornam mais capazes, passam cada vez mais a agir em nome dos utilizadores. Os agentes de programação conseguem rever repositórios de forma autónoma, executar comandos e interagir com ferramentas de desenvolvimento. Estas são tarefas que antes exigiam execução humana direta.

Com o Codex, concebemos estas capacidades em conjunto com os controlos de que as organizações precisam para uma implementação segura. As equipas de segurança precisam de formas de governar como os agentes operam: a que podem aceder, quando é necessária aprovação humana, com que sistemas podem interagir e que telemetria existe para explicar o seu comportamento.

Na OpenAI, implementamos o Codex com alguns objetivos claros: manter o agente dentro de limites técnicos bem definidos, permitir que os programadores avancem rapidamente em ações de baixo risco e tornar explícitas as ações de maior risco. Também preservamos telemetria nativa do agente para podermos compreender e auditar o que o agente fez. Na prática, isto significa configuração gerida, execução restringida, políticas de rede e registos nativos do agente.

Controlar a forma como o Codex opera

Implementamos o Codex com um princípio simples: deve ser produtivo dentro de um ambiente delimitado, as ações quotidianas de baixo risco devem ser fluidas e as ações de maior risco devem parar para revisão.

Sandboxing e aprovações

As aprovações e o sandboxing funcionam em conjunto. A sandbox define o limite técnico de execução, incluindo onde o Codex pode escrever, se pode aceder à rede e que caminhos permanecem protegidos. A política de aprovação determina quando o Codex tem de pedir autorização para realizar uma ação, por exemplo, quando precisa de fazer algo fora da sandbox. Os utilizadores podem aprovar a ação uma vez ou aprovar esse tipo de ação para essa sessão.

Para pedidos que atravessam o limite da sandbox, estamos a usar o modo de revisão automática(abre numa nova janela), uma funcionalidade que, quando ativada, aprova automaticamente determinados tipos de pedidos para reduzir a frequência com que os utilizadores têm de parar e aprovar ações do Codex. O Codex envia a ação planeada e o contexto recente para o subagente de aprovação automática, que pode aprovar automaticamente ações de baixo risco — ou ações de alto risco com um nível suficiente de autorização do utilizador — em vez de interromper o utilizador. Isto mantém o Codex em movimento no trabalho de rotina, continuando a parar em ações de maior risco ou com consequências não intencionais.

TOML

1
# config.toml
2

3
# Turn on auto_review
4
approvals_reviewer = "auto_review"
5
# Add known development directories to the sandbox automatically
6
sandbox_workspace_write.writable_roots = ["~/development"]
7

8
# requirements.toml
9

10
# Require Codex to operate inside the sandbox
11
allowed_sandbox_modes = ["read-only", "workspace-write"]

Acesso à rede

Não executamos o Codex com acesso de saída sem limites. A nossa política de rede gerida permite destinos esperados, bloqueia destinos aos quais não queremos que o Codex aceda e exige aprovação para domínios desconhecidos. Isto permite que o Codex conclua fluxos de trabalho comuns e reconhecidamente seguros sem lhe dar acesso amplo à rede.

TOML

1
# requirements.toml
2

3
# Ensure web fetch only comes from OpenAI's cache
4
allowed_web_search_modes = ["cached"]
5

6
[experimental_network]
7
# Turn on Network Proxy
8
enabled = true
9
# Allow Codex to interact with localhost
10
allow_local_binding = true
11
# Block all requests to this domain
12
denied_domains = ["pastebin.com"]
13
# Auto-allow requests to these domains
14
allowed_domains = ["login.microsoftonline.com", "*.openai.com"]

Identidade e credenciais

Também gerimos a forma como o Codex se autentica. As credenciais OAuth da CLI e de MCP são armazenadas no porta-chaves seguro do sistema operativo, o início de sessão é forçado através do ChatGPT e o acesso é restringido ao nosso espaço de trabalho empresarial do ChatGPT. Isto mantém a utilização do Codex associada aos nossos controlos ao nível do espaço de trabalho e disponibiliza a atividade do Codex na ChatGPT Compliance Logs Platform para o nosso espaço de trabalho empresarial.

TOML

1
# config.toml
2

3
# Store CLI Auth Creds in OS Keychain
4
cli_auth_credentials_store = "keyring"
5
# Store MCP Creds in OS Keychain
6
mcp_oauth_credentials_store = "keyring"
7
# Require Auth via ChatGPT
8
forced_login_method = "chatgpt"
9
# Require Auth to Specific ChatGPT Workspace
10
forced_chatgpt_workspace_id = "<workspace-uuid>"

Regras

Usamos regras para que o Codex não trate todos os comandos shell como igualmente seguros. Comandos benignos comuns que os engenheiros usam no desenvolvimento diário são permitidos sem aprovação fora da sandbox, enquanto comandos perigosos específicos podem ser bloqueados ou exigir aprovação. Isto permite que o Codex avance rapidamente em tarefas comuns de engenharia, continuando a impor revisão ou a bloquear padrões que não queremos executar fora da sandbox.

Starlark

1
# default.rules
2

3
prefix_rule(
4
pattern = ["gh", "pr", ["view", "list"]],
5
decision = "allow",
6
justification = "Allows read-only GitHub PR inspection via gh CLI.",
7
)
8
prefix_rule(
9
pattern = ["kubectl", ["get", "describe", "logs"]],
10
decision = "allow",
11
justification = "Allows Kubernetes resource inspection for debugging.",
12
)

Configurações geridas

Aplicamos esta postura através de uma combinação de requisitos geridos na cloud, preferências geridas do macOS e ficheiros locais de requisitos. Os requisitos são controlos impostos por administradores que os utilizadores não podem substituir. As preferências geridas do macOS e os ficheiros locais de requisitos permitem-nos manter uma base consistente, continuando a testar diferentes configurações por equipa, grupo de utilizadores ou ambiente. Estas configurações aplicam-se às superfícies locais do Codex, incluindo a aplicação de desktop, a CLI e a extensão do IDE.

Telemetria nativa do agente e trilhos de auditoria

O controlo é apenas metade do trabalho. Depois de os agentes serem implementados, as equipas de segurança precisam de visibilidade sobre o que estes agentes estão a fazer e porquê. Os registos de segurança tradicionais continuam a ser úteis ao analisar ações realizadas pelo Codex, mas respondem sobretudo ao que aconteceu: um processo foi iniciado, um ficheiro foi alterado, foi tentada uma ligação de rede. Os defensores continuam a ter de perceber porque é que o Codex fez algo, ou qual era a intenção do utilizador.

O Codex pode dar às equipas de segurança uma visão mais consciente do agente. O Codex suporta a exportação de registos OpenTelemetry para vários eventos do Codex, como prompts dos utilizadores, decisões de aprovação de ferramentas, resultados de execução de ferramentas, utilização de servidores MCP e eventos de permissão ou recusa do proxy de rede. Os registos de atividade do Codex também estão disponíveis através da OpenAI Compliance Platform para clientes Enterprise e Edu.

TOML

1
# config.toml
2

3
[otel]
4
log_user_prompt = true
5
environment = "prod"
6

7
[otel.exporter.otlp-http]
8
endpoint = "http://localhost:14318/v1/logs"
9
protocol = "binary"

Na OpenAI, usamos os registos do Codex em conjunto com o nosso agente de triagem de segurança com tecnologia de IA. Quando um alerta de endpoint indica que o Codex fez algo invulgar, a ferramenta de segurança de endpoints diz-nos que ocorreu um evento suspeito. Os registos do Codex ajudam então a explicar a intenção envolvente do utilizador e do agente. O nosso agente de triagem de segurança com IA usa os registos do Codex para inspecionar o pedido original, a atividade das ferramentas, as decisões de aprovação, os resultados das ferramentas e qualquer decisão ou bloqueio relevante da política de rede. O agente de triagem de segurança com IA apresenta a sua análise à nossa equipa de segurança para revisão, de modo a distinguir entre comportamento esperado do agente, erros benignos e atividade que realmente justifica escalonamento.

Também usamos a mesma telemetria a nível operacional. Usamos estes registos para compreender como a adoção interna está a mudar, que ferramentas e servidores MCP estão a ser usados, com que frequência a sandbox de rede está a bloquear ou a solicitar aprovação, e onde a implementação ainda precisa de ajustes. Estes registos OpenTelemetry podem ser centralizados em sistemas SIEM e de registo de conformidade.

Olhar em frente

À medida que agentes de programação como o Codex se integram nos fluxos de trabalho de desenvolvimento, as equipas de segurança precisam de ferramentas especificamente concebidas para gerir esta mudança. O Codex disponibiliza as superfícies de controlo, a gestão de configuração, o sandboxing e a telemetria detalhada e consciente do agente necessários para garantir uma adoção segura. Com estas capacidades implementadas, as equipas de segurança podem ativar o Codex com maior confiança, equilibrando a produtividade dos programadores com a visibilidade e o controlo necessários para a segurança empresarial. Pode encontrar mais informações sobre a configuração do Codex aqui(abre numa nova janela), e sobre a Compliance API aqui(abre numa nova janela).

Autor

OpenAI