Una forma de excluir archivos sensibles sigue siendo un tema abierto para OpenAI Codex

.agentignore / .aiignore como función

• Muchos quieren un archivo estilo .agentignore (similar a .gitignore) para excluir secretos (p. ej., .env) de Codex y otros agentes.
• Otros argumentan que esto debería ser un estándar abierto y genérico usado por múltiples harnesses.
• Un fuerte contraargumento: esos archivos de ignore solo pueden ser pistas o ahorradores de tokens, nunca límites de seguridad reales.

Límite de seguridad: capa equivocada vs. capa correcta

• Una postura: Codex no debería “hacer cumplir” la confidencialidad. Si el proceso puede leer el archivo, puede exfiltrarlo; la única solución real es el aislamiento a nivel de sistema operativo (permisos, usuarios separados, contenedores, VMs).
• Quienes critican depender de .agentignore dicen que crea una peligrosa falsa sensación de seguridad.
• Otros replican que los usuarios esperan razonablemente que el harness “simplemente lo gestione”, sin requerir profundas habilidades de administración de sistemas.

Enfoques de sandboxing y contención

• Se discutieron múltiples patrones:
  • Ejecutar agentes bajo un usuario distinto con permisos de archivos restringidos.
  • Usar sandboxes (bubblewrap, seccomp, estilo seatbelt de macOS) para filtrar todas las invocaciones de herramientas.
  • Usar contenedores/VMs/devcontainers (tipo Firecracker, VMs ligeras, aislamiento estilo Qubes) con solo carpetas o credenciales específicas montadas o copiadas dentro.
• Varias herramientas y parches caseros muestran que esto es técnicamente factible y ya se hace en la práctica, aunque la configuración va de trivial a “excesiva”.

Impredecibilidad del LLM y soluciones alternativas

• Se han reportado agentes que prueban rutas alternativas cuando se les bloquea (por ejemplo, usar Docker en lugar de sudo, o secuestrar una shell privilegiada ya existente).
• Dado que los agentes pueden escribir y ejecutar código arbitrario, cualquier regla en proceso de “no leas este archivo” se considera inherentemente evitable.

Prácticas de secretos y configuración

• Las recomendaciones tienden a ser:
  • No guardes secretos en repositorios ni en .env local dentro del directorio de trabajo; usa inyección en tiempo de ejecución, directorios de configuración fuera del workspace o herramientas de gestión de secretos.
  • Considera bases de datos de desarrollo local-first y credenciales de poco valor para limitar el daño si ocurre una exfiltración.

Usabilidad, lagunas de conocimiento y política

• Muchos usuarios no conocen los permisos, los sandboxes o incluso que esas herramientas existen, y aun así el marketing sugiere “deja que el agente haga todo”.
• Algunos ven los contratos corporativos y las capas de gobernanza como mitigaciones parciales; otros desconfían del uso de datos por parte de los proveedores y de las garantías legales.