Segurança do OpenAI Codex: riscos, controlos e boas práticas

O que é o OpenAI Codex e porque é que muda o modelo de segurança?

O OpenAI Codex é a ferramenta de código agêntica da OpenAI. Funciona onde quer que o programador já trabalhe: uma CLI Codex no terminal, uma extensão de IDE, um modo de cloud e multi-agente que corre tarefas de forma assíncrona, e um SDK para ligar o Codex à sua própria automação. Atua sobre instruções em linguagem natural: analisar uma base de código, gerar uma funcionalidade, correr os testes, corrigir as falhas, abrir um pull request. Liga-se ao GitHub, corre ao lado dos sistemas de build, e pode ser apontado a um repositório e deixado a trabalhar.

Primeiro uma clarificação de nomenclatura, porque tropeça quase toda a gente que procura este tema. "Codex" neste artigo significa o agente de código (CLI, extensão de IDE, cloud e SDK). Em separado, a OpenAI lançou uma funcionalidade literalmente chamada Codex Security: um agente que se liga a um repositório, constrói um modelo de ameaças específico da base de código, analisa o histórico de commits, valida vulnerabilidades candidatas num ambiente isolado, e propõe correções para revisão humana. Os dois são fáceis de confundir. Este guia é sobre proteger o agente de código Codex. O Codex Security, a própria capacidade de descoberta de vulnerabilidades da OpenAI, é coberto brevemente abaixo como um input assistivo, não um programa de segurança completo.

Essa propriedade agêntica é a que quebra o velho modelo de segurança. Um assistente de IDE tradicional sugere completações; um humano aceita ou rejeita cada uma. O raio de impacto de uma sugestão má é um bloco de código que um programador ainda tem de colar. O Codex executa ações em vez disso. Lê ficheiros que não nomeou, executa comandos que não escreveu, edita código por toda a árvore, e em modo de cloud pode correr durante muito tempo sem ninguém a observar. A superfície de ataque já não é "que código sugeriu o modelo". É "o que pode este agente fazer com o acesso que tem, e quem consegue influenciar as suas instruções".

“

Uma sugestão é um rascunho que um humano escolhe aceitar. Uma ação é algo que já aconteceu. O modelo de segurança tem de passar de rever rascunhos para restringir ações.

Há uma segunda mudança que importa ainda mais, e tem que ver com a velocidade. O pull request tornou-se a casa da segurança de aplicações porque assentava na cadência humana: uma pessoa abrandava, lia o diff e só depois fazia o merge. O Codex, sobretudo em modo de cloud e multi-agente, não corre à cadência humana. Uma única sessão pode entregar mais código numa tarde do que um revisor lê numa semana. Quando isso acontece, o diff deixa de ser um ponto de controlo e torna-se um registo de decisões já tomadas. Qualquer controlo que só atue no pull request está agora a rever o histórico, não a preveni-lo.

Para a maioria das equipas, a pergunta prática não é se o Codex tem proteções nativas. Tem-nas, e estão sensatamente concebidas. A pergunta é se essas proteções chegam para o uso do dia a dia. A resposta honesta é não. A própria orientação "Running Codex safely" da OpenAI enquadra o ambiente isolado (sandbox) e as aprovações como defesa em profundidade, não uma fronteira completa, e no momento em que muda para modo full-access ou ativa o acesso de rede no sandbox, essas barreiras de proteção saem por conceção. A adoção segura continua a depender de permissões, disciplina de sandbox, supervisão humana e validação independente em código, dependências e pipelines.

Como funciona o modelo de segurança do Codex

O modelo do Codex assenta em três ideias: correr o trabalho dentro de um ambiente isolado (sandbox), perguntar antes de fazer algo que escape dele, e manter a rede fechada a menos que a abra. Na prática, isso surge como um punhado de controlos.

É uma base genuinamente ponderada, e a maior parte desta lista não existia nos assistentes de IDE de uma geração atrás. A armadilha é lê-la como uma fronteira de segurança acabada. A OpenAI é explícita ao dizer que o modo auto é um meio-termo em vez de uma garantia, que full-access e a flag --dangerously-bypass-approvals-and-sandbox removem o sandbox de propósito, e que ativar o acesso de rede dentro do sandbox é uma troca deliberada de segurança por capacidade. Cada controlo desta lista tem uma forma documentada de o desligar, e a próxima secção é sobre o que acontece quando o faz, ou quando um atacante o faz por si.

Os 6 principais riscos de segurança no OpenAI Codex

Os riscos abaixo não são teóricos. Correspondem a vulnerabilidades documentadas, investigação publicada e ao OWASP Top 10 para Aplicações LLM. Os números que os enquadram são os mesmos que todas as equipas de AppSec citam agora.

40%

do código gerado por IA era vulnerável em cenários de segurança do MITRE Top-25 (NYU, Asleep at the Keyboard)

#1

injeção de prompt, o principal risco LLM pelo 3.º ano consecutivo (OWASP LLM01)

10,5%

das soluções de agentes de código de IA eram seguras, face a 61% funcionalmente corretas (Carnegie Mellon SusVibes)

1. Injeção de comandos e execução remota de código

O Codex escreve e corre código ao nível do sistema, por isso uma falha na forma como lida com os seus próprios inputs torna-se um caminho para a execução de código. Isto não é hipotético. A BeyondTrust Phantom Labs divulgou uma vulnerabilidade crítica de injeção de comandos no OpenAI Codex que permitia o roubo de GitHub User Access Tokens, com o payload contrabandeado através de um nome de branch do GitHub e escondido da interface usando caracteres Unicode invisíveis. Como vivia no pedido de criação de tarefa, afetava o site do ChatGPT, a CLI Codex, o SDK Codex e a extensão de IDE Codex ao mesmo tempo.

A OpenAI remediou-a (um hotfix inicial uma semana após o relatório de dezembro de 2025, proteções de shell mais fortes e âmbito de token reduzido até início de 2026, em última análise classificada como Critical Priority 1), por isso este bug específico está fechado. Continua a ser a ilustração mais clara da superfície: um agente que executa comandos de shell em seu nome transforma qualquer input não sanitizado que lê, um nome de branch, um nome de ficheiro, uma resposta de ferramenta, num potencial ponto de injeção. O perigo agrava-se quando o agente corre com acesso amplo à shell e um modo permissivo, porque uma cadeia de comandos individualmente inofensivos pode instalar uma dependência, alterar uma configuração de CI ou abrir um mecanismo de persistência.

2. Cadeia de suprimentos e dependências maliciosas

O Codex instala pacotes, clona repositórios e corre scripts de configuração como parte do trabalho normal, e a sua própria popularidade fez dele um alvo. O TechRadar e outros meios reportaram sobre um pacote npm, codexui-android, que se fazia passar por uma UI remota para o Codex, atraiu cerca de 29 000 downloads, e depois de um lançamento inicial limpo lançou uma atualização que exfiltrou silenciosamente os conteúdos do ficheiro de credenciais do Codex (~/.codex/auth.json), tokens de acesso, de refresh e de ID, para um servidor controlado pelo atacante. Como o token de refresh não expira, uma única instalação comprometida pode conceder acesso persistente e silencioso.

Esse incidente insere-se num padrão mais amplo. Ao longo de 2025 e até 2026, campanhas de typosquatting e de imitação no npm visaram cada vez mais ferramentas de código de IA e os seus ecossistemas. O próprio fluxo de trabalho de desenvolvimento torna-se o vetor de ataque: um package.json envenenado, um hook malicioso de post-install ou um helper com typosquatting pode transformar um rotineiro prompt "configura este repositório" em roubo de credenciais. A alucinação de pacotes agrava-o, um agente que inventa com confiança um nome de pacote plausível mas inexistente entrega a um atacante uma vaga para registar e transformar em arma.

3. Injeção de prompt e escrita de exploits orientada

A injeção de prompt é o risco que define as ferramentas de código agênticas, e é o risco LLM número um da OWASP pelo terceiro ano consecutivo (LLM01). Um atacante esconde instruções em algo que o agente lê, um ficheiro, uma página web, uma issue, o README de uma dependência, a saída de uma ferramenta, e o agente segue-as, anulando o comportamento previsto.

O cenário agêntico piora o desfecho, porque o Codex não se limita a responder; age e escreve código ao nível do sistema. Um agente orientado pode ser empurrado a escrever um exploit, enfraquecer uma verificação de autorização, adicionar um caminho de desserialização insegura ou ligar uma backdoor que lê como correta para um revisor cansado. A forma perigosa é indireta: não precisa de colar um prompt malicioso, basta apontar o Codex a um repositório envenenado ou deixá-lo consumir saída hostil de ferramentas. Como um modelo de linguagem não consegue separar de forma fiável uma instrução de confiança de uma maliciosa embutida em dados, a injeção pode levar a execução de comandos, exfiltração de dados ou manipulação silenciosa de código.

4. Modos de sandbox e de aprovação demasiado permissivos

A segurança do Codex assenta no seu sandbox e nos seus prompts de aprovação, e ambos podem ser baixados com uma única flag. Escolher full-access (danger-full-access), ou ativar o acesso de rede de saída dentro do sandbox workspace-write, troca a barreira de proteção por capacidade, e a OpenAI di-lo claramente. Com o sandbox aberto e a rede acessível, o mesmo agente que estava contido há um momento pode agora escrever fora do workspace e enviar dados para qualquer lado.

O mecanismo que corrói isto na prática é a fadiga de aprovações. Quando o agente pausa repetidamente, as pessoas recorrem a --ask-for-approval never, ou ao preset full-auto, para fazer os prompts desaparecer. Numa semana, o cuidadoso valor por omissão tornou-se, em silêncio, uma autorização geral, e ninguém decidiu que assim fosse. A versão ao nível da equipa é pior: um programador corre read-only, outro corre full-access porque era mais rápido numa sexta-feira, e no momento em que partilham um repositório ou um fluxo de trabalho automatizado, a configuração mais fraca define a verdadeira postura de todos.

5. Retenção de dados e privacidade

O Codex é útil porque tem contexto, e esse contexto inclui rotineiramente mais do que o ficheiro à sua frente: código adjacente, configuração, variáveis de ambiente e por vezes credenciais. Os agentes geram e transmitem grandes quantidades de código privado em série, prompt após prompt, tarefa após tarefa. Para bases de código sensíveis ou reguladas, a pergunta certa não é apenas "a ligação está encriptada", mas "o que é armazenado, durante quanto tempo, onde, e quem lhe consegue chegar".

A exposição é muitas vezes indireta em vez de dramática. Ao resumir um repositório ou ao depurar um erro, o agente pode expor um token ou um endpoint interno numa saída que depois acaba num pull request, num ticket ou num chat, onde vive muito depois de a sessão terminar. As organizações que adotam o Codex em escala devem rever os termos de tratamento e retenção de dados da OpenAI para a superfície que usam (a API, os tiers Business e Enterprise diferem), manter segredos e dados regulados fora do alcance do agente, e tratar tudo o que o agente emite como potencialmente registado.

6. Autonomia em escala

A capacidade que torna o Codex apelativo, correr uma tarefa e voltar a um pull request acabado, é também a que alarga a lacuna de revisão. Em modo de cloud e multi-agente, o Codex pode fazer alterações grandes e abrangentes em muitos ficheiros com pouca atenção humana pelo meio. Quanto mais autónoma e mais demorada for a tarefa, maior o diff, e menor a fração dele que um humano lê de facto antes de aprovar.

Isso importa para a segurança porque a janela para uma alteração insegura ou maliciosa aterrar cresce com o tamanho do diff não lido. Uma regressão de autorização subtil, uma dependência injetada ou uma validação enfraquecida em silêncio são muito mais fáceis de passar despercebidas numa alteração autónoma de 2 000 linhas do que numa de 20 linhas que um programador escreveu deliberadamente. A autonomia não cria novas classes de vulnerabilidade tanto quanto remove a fricção natural que costumava apanhá-las, que é precisamente por que os controlos abaixo se apoiam tanto na revisão, na delimitação e na governação no momento do prompt.

O que a segurança nativa do Codex cobre, e o que não cobre

Os controlos nativos são reais, e ajuda ser preciso quanto à linha entre o que tratam e o que deixam para si.

Leia a coluna da direita como o verdadeiro trabalho. Os controlos nativos são o chão: o sandbox e o valor por omissão de rede impedem que um erro honesto, ou um único comando orientado, se torne um desastre à escala da máquina. Não foram concebidos para travar um adversário determinado que controla os inputs do agente, e a OpenAI não afirma que foram. Tudo o que transforma "o Codex está instalado" em "o Codex está governado" vive nas práticas que se seguem.

Boas práticas para proteger o OpenAI Codex

Estas nove práticas fecham a lacuna entre a base nativa e uma postura de segurança real. Nenhuma é exótica; a disciplina está em aplicá-las de forma consistente numa equipa que se move depressa.

1. Mantenha o sandbox ligado e o full-access desligado. Use por omissão read-only para exploração e auto (workspace-write) para trabalho real, e trate full-access (danger-full-access) e --dangerously-bypass-approvals-and-sandbox como exclusivos de contentores descartáveis. Confirme que o sandbox do SO está de facto ativado em cada plataforma em que corre, e nunca o desative numa máquina que consiga alcançar credenciais reais ou hosts de produção.

2. Deixe a rede fechada a menos que uma tarefa realmente precise. O valor por omissão da cloud de não haver acesso de saída é a barreira de proteção mais valiosa que o Codex inclui, porque a exfiltração precisa normalmente da rede. Ative o acesso de rede no sandbox workspace-write apenas para a tarefa específica que o exige, delimite-o a destinos conhecidos onde puder, e volte a desligá-lo depois em vez de o deixar aberto por hábito.

3. Aplique o privilégio mínimo a repositórios e tokens. Dê ao Codex acesso apenas aos repositórios de que uma tarefa precisa, prefira tokens GitHub efémeros e estreitamente delimitados a tokens amplos e persistentes, e rode-os com regularidade em vez de esperar por um incidente. A divulgação da BeyondTrust é um lembrete de que um único token GitHub vazado pode alcançar todos os repositórios a que lhe foi dado acesso, por isso o âmbito do token é o âmbito da brecha.

4. Governe dependências e pacotes. Restrinja as instalações a registos de confiança ou mirrors internos, exija aprovação para novos pacotes e analise tudo com análise de composição de software. Não deixe o agente instalar automaticamente pacotes obscuros ou não verificados por mais confiança com que os sugira, verifique que um pacote sugerido existe de facto antes de o adicionar, e seja especialmente desconfiado de ferramentas helper que envolvem o próprio Codex, que é exatamente onde vivia o ladrão de tokens codexui-android.

5. Mantenha um humano no circuito do código gerado. Trate a saída do Codex como um rascunho, não uma implementação final, e dimensione a revisão ao tamanho da alteração. Encaminhe o código gerado e modificado através de revisão de pull request e testes automatizados, com escrutínio extra na autenticação, validação de input e caminhos privilegiados. O objetivo não é desconfiar do modelo; é que um agente que produz milhares de linhas por dia, sobretudo em modo de cloud, produz falhas subtis mais depressa do que elas surgem por si próprias.

6. Corra trabalho não confiável em isolamento. Ao apontar o Codex a um repositório desconhecido, a uma issue de terceiros, ou a qualquer coisa que não escreveu, corra-o num contentor ou VM sem segredos do host montados e sem caminho para produção. A injeção de prompt indireta chega exatamente através deste tipo de conteúdo, por isso a defesa mais barata é garantir que um agente orientado não tem nada de valioso ao alcance.

7. Mantenha os segredos fora de alcance. Mantenha segredos em texto simples totalmente fora do contexto do agente: use um cofre e injete em tempo de execução, redija valores sensíveis nos logs, e não deixe o agente ler ficheiros de credenciais ou conteúdos .env de que não precisa. Proteja o próprio ficheiro de credenciais do Codex (~/.codex/auth.json) como o alvo de alto valor que é, e se um segredo alguma vez aparecer num registo ou numa saída, rode-o de imediato e investigue como lá chegou.

8. Restrinja a autonomia em modo de cloud e multi-agente. Delimite estreitamente as tarefas demoradas e assíncronas, prefira várias alterações revisíveis a uma única abrangente, e exija aprovação humana antes de uma branch autorada pelo Codex fazer merge para algo protegido. Quanto maior o diff autónomo, mais deliberada tem de ser a revisão, por isso defina expectativas (e regras de proteção de branches) que correspondam ao volume que o Codex consegue produzir.

9. Defina a política por repositório e sensibilidade do ambiente. Classifique os repositórios (público, interno, regulado, produção) e aplique controlos mais estritos aos sensíveis: modos read-only ou estreitamente delimitados, rede fechada, negar acesso a segredos, exigir revisão mais forte. Corra o Codex contra sistemas críticos apenas em ambientes sem caminho direto para credenciais de produção, e documente a política para que os programadores saibam onde a ajuda de IA é permitida e sob que restrições. Use o Codex Security e o SAST tradicional como inputs assistivos a essa revisão, não como um substituto dela.

Onde os controlos nativos param: proteger o agente no momento do prompt

Percorra de novo os riscos e surge um padrão. O sandbox, os modos de aprovação e o passo de revisão atuam todos sobre o que o agente já decidiu fazer, ou sobre código que já escreveu. Concentram-se em torno do pull request, porque é aí que a AppSec sempre viveu. Mas o PR só foi alguma vez um ponto de controlo porque um humano o lia, e à cadência do agente, sobretudo em modo de cloud, ninguém o lê de ponta a ponta.

O lugar para impor uma regra já não é o diff; é o prompt, antes de a linha insegura ser escrita. Qualquer regra que queira que o agente siga tem de estar nas suas mãos no momento em que escreve, não à espera num scanner que chega quando o código já está em disco e o agente já passou para a tarefa seguinte.

É essa a camada que o VibeDefend acrescenta. É uma CLI npm gratuita que instala em cerca de cinco segundos e liga o OpenAI Codex (mais o Claude Code, o Cursor, o Windsurf e o VS Code Copilot) a quatro camadas de governação que correm dentro do ciclo do agente.

npx -y @cybedefend/vibedefend@latest installEscolher EU ou US, confirmar OpenAI CodexColocar .cybedefend/config.json no repositórioO próximo prompt está governado

Regras de Negócio As convenções no seu repositório que nunca foram escritas (usar Decimal128 para dinheiro, a autorização passa por requireOwner). O VibeDefend extrai-as da forma como a sua equipa já programa e carrega-as no contexto do agente antes de cada edição. Regras de Segurança OWASP Top 10, SOC 2, RGPD e ISO 27001, carregadas no dia em que instala. O agente lê o lembrete aplicável antes de escrever, de modo que o requisito do framework se torna parte do código em vez de uma caixa a marcar no momento da auditoria. Action Guard Chamadas destrutivas (um sudo rm -rf, uma leitura crua de uma variável de ambiente com forma de segredo, um psql ad-hoc contra um host de produção) são intercetadas antes de dispararem. Avisar ou bloquear conforme a regra, com cada interceção no registo de auditoria. Live Findings Cada resultado dos seus scanners (SAST com alcançabilidade, SCA, segredos, IaC e CI/CD) está ao vivo no contexto do agente, de modo que ele não só escreve código seguro, como tria e corrige as vulnerabilidades que já tem.

Crucialmente, nada do seu código atravessa a rede. As decisões acontecem localmente, ao lado do agente; apenas metadados de governação estruturados (a regra que disparou, o caminho do ficheiro, a severidade, um timestamp) chegam ao backend. Os tenants da EU e dos US são fisicamente separados, e a região é escolhida no momento da instalação. É esse modelo de privacidade que permite a um controlo estar tão perto do código sem se tornar, ele próprio, um risco de exfiltração de dados, o que importa ainda mais para um agente cujo próprio ficheiro de credenciais já foi alvo de roubo.

Isto não é um substituto das práticas acima. É a camada em falta que elas assumem existir: a que coloca as suas regras nas mãos do agente no momento do prompt, de modo que a linha insegura seja reescrita antes de alguma vez ser sugerida, em vez de apanhada três fases depois por um scanner que lê um diff que ninguém teve tempo de ler. O sandbox impede o agente de fazer o que não pode fazer; o VibeDefend molda o que ele escreve, em primeiro lugar.

Perguntas frequentes

O OpenAI Codex é seguro?

O OpenAI Codex é seguro de usar quando está em sandbox e delimitado, e arriscado quando não está. O seu sandbox ao nível do SO, os modos de aprovação escalonados e o comportamento de rede desligada por omissão na cloud previnem uma grande classe de acidentes e contêm a maioria dos comandos perdidos. O risco residual vem da configuração (modo full-access, rede ativada, aprovações desativadas), dos inputs (injeção de prompt, repositórios e pacotes maliciosos) e da autonomia em escala (grandes alterações de cloud que passam sub-revistas). Trate-o como um agente poderoso que precisa de privilégio mínimo, isolamento e revisão humana, não como uma ferramenta que é segura logo à partida.

Qual é a diferença entre Codex e "Codex Security"?

São duas coisas diferentes da OpenAI que partilham um nome. O Codex é a ferramenta de código agêntica: a CLI, a extensão de IDE, o modo de cloud e o SDK que leem o seu repositório, editam ficheiros, correm comandos e abrem pull requests. O Codex Security é um agente separado de descoberta de vulnerabilidades que se liga a um repositório, constrói um modelo de ameaças, analisa o histórico de commits, valida questões candidatas em isolamento, e propõe correções para revisão humana. Este guia é sobre proteger o agente de código Codex. O Codex Security é um input assistivo à revisão de código, útil como um par de olhos extra, não um programa de segurança completo.

O Codex corre código num ambiente isolado (sandbox)?

Sim. O Codex executa comandos dentro de um sandbox do sistema operativo: Seatbelt no macOS, Landlock e seccomp no Linux, e um sandbox dedicado no Windows. Por omissão, as escritas estão limitadas ao workspace ativo e, no ambiente de cloud, o acesso de rede de saída está desativado. Esses valores por omissão são o núcleo do seu modelo de segurança. Podem ser baixados deliberadamente com full-access (danger-full-access) ou ativando o acesso de rede dentro do sandbox workspace-write, e a OpenAI é explícita ao dizer que fazê-lo remove a proteção de propósito.

O Codex pode vazar o meu token GitHub ou credenciais?

Pode, se não tiver cuidado, e há precedente. A BeyondTrust Phantom Labs divulgou uma vulnerabilidade de injeção de comandos que deixava os atacantes roubar GitHub User Access Tokens através de um nome de branch forjado no site do ChatGPT, na CLI Codex, no SDK e na extensão de IDE; a OpenAI já a remediou. Em separado, um pacote npm malicioso que se fazia passar por um helper do Codex exfiltrou o ficheiro de credenciais do Codex (~/.codex/auth.json) de cerca de 29 000 instalações. Defenda o token delimitando-o estreitamente, rodando-o, validando quaisquer ferramentas helper, e protegendo o ficheiro de credenciais como um segredo de alto valor.

O Codex envia o meu código para a OpenAI?

O Codex envia o contexto de que precisa para os modelos da OpenAI para gerar respostas, o que pode incluir código, conteúdos de ficheiros e o contexto envolvente da sua tarefa. O que é armazenado e durante quanto tempo depende da superfície que usa e do seu tier (os termos da API, Business e Enterprise diferem na retenção e no treino). Para código sensível, escolha um tier e uma configuração que correspondam aos seus requisitos de tratamento de dados, mantenha segredos e dados regulados fora do alcance do agente, e reveja as políticas de retenção. Os metadados de governação de uma camada adicional como o VibeDefend mantêm-se separados e não transmitem código-fonte.

Que modo de sandbox/aprovação do Codex devo usar?

Para a maioria do trabalho, read-only para explorar e auto (o sandbox workspace-write com aprovação a pedido) para fazer alterações, com a rede deixada fechada. Reserve full-access (danger-full-access) e --dangerously-bypass-approvals-and-sandbox para contentores descartáveis sem credenciais reais, e evite --ask-for-approval never em qualquer máquina que consiga alcançar produção ou segredos. Faça corresponder o modo à sensibilidade do repositório: quanto mais crítico o sistema, mais apertado o sandbox, mais aprovação, e menos rede o agente deve ter.

Em que é que a segurança do Codex difere da do Claude Code, Cursor ou GitHub Copilot?

Os fundamentos são partilhados (privilégio mínimo, gestão de segredos, revisão humana, análise de dependências), mas as superfícies diferem. As superfícies distintivas do Codex são o seu sandbox do SO mais a saída de emergência de full-access, os seus incidentes de injeção de comandos e de cadeia de suprimentos no npm, e a lacuna de revisão do modo de cloud autónomo. O Claude Code apoia-se na integração profunda com MCP e shell; o Cursor teve o Workspace Trust desativado por omissão; o GitHub Copilot combateu sugestões inseguras e fuga de segredos em escala. Cobrimos cada agente no seu próprio guia.