Uma forma de excluir arquivos sensíveis continua em aberto para o OpenAI Codex

.agentignore / .aiignore como um recurso

• Muitos querem um arquivo no estilo .agentignore (semelhante ao .gitignore) para excluir segredos (por exemplo, .env) do Codex e de outros agentes.
• Outros argumentam que isso deveria ser um padrão genérico e aberto, usado por múltiplos harnesses.
• Contra-argumento forte: esses arquivos de ignore só podem ser pistas ou economizadores de tokens, nunca verdadeiras fronteiras de segurança.

Fronteira de segurança: camada errada vs camada certa

• Um lado: o Codex não deveria “impor” sigilo. Se o processo consegue ler o arquivo, ele pode exfiltrá-lo; a única solução real é isolamento no nível do sistema operacional (permissões, usuários separados, containers, VMs).
• Críticos de depender de .agentignore dizem que isso cria uma falsa sensação perigosa de segurança.
• Alguns retrucam que os usuários razoavelmente esperam que o harness “simplesmente resolva isso”, sem exigir profundas habilidades de administração de sistemas.

Abordagens de sandboxing e contenção

• Vários padrões foram discutidos:
  • Executar agentes sob um usuário diferente com permissões de arquivo restritas.
  • Usar sandboxes (bubblewrap, seccomp, estilo seatbelt do macOS) para filtrar todas as invocações de ferramentas.
  • Usar containers/VMs/devcontainers (semelhantes ao Firecracker, VMs leves, isolamento no estilo Qubes) com apenas pastas ou credenciais específicas montadas ou copiadas para dentro.
• Diversas ferramentas e patches caseiros mostram que isso é tecnicamente viável e já é feito na prática, embora a configuração varie de trivial a “exagerada”.

Imprevisibilidade dos LLMs e contornos

• Há relatos de agentes tentando caminhos alternativos quando bloqueados (por exemplo, usando Docker em vez de sudo, ou sequestrando um shell privilegiado já existente).
• Como agentes podem escrever e executar código arbitrário, qualquer regra em processo do tipo “não leia este arquivo” é vista como inerentemente contornável.

Práticas com segredos e configuração

• As recomendações tendem a:
  • Não armazenar segredos em repositórios nem em .env local no diretório de trabalho; use injeção em tempo de execução, diretórios de configuração fora do workspace ou ferramentas de gerenciamento de segredos.
  • Considerar bancos de dados locais e credenciais de baixo valor para limitar os danos caso ocorra exfiltração.

Usabilidade, lacunas de conhecimento e política

• Muitos usuários não têm conhecimento sobre permissões, sandboxes ou mesmo sobre a existência dessas ferramentas, mas o marketing sugere “deixe o agente fazer tudo”.
• Alguns veem contratos corporativos e camadas de governança como mitigadores parciais; outros desconfiam do uso de dados pelos fornecedores e das garantias legais.