Permisos de los agentes de programación con IA y modo YOLO: una configuración más segura

Modos de permisos en tres herramientas

Todo agente de programación con IA equilibra dos cosas: con qué frecuencia te interrumpe y cuánto puede hacer sin preguntar. Los ajustes se llaman de forma distinta en cada herramienta, pero tienen la misma estructura: un modo que pregunta, un modo que deja decidir a un revisor automático y un modo que se lo salta todo, conocido informalmente como modo YOLO.

Qué omiten de verdad los modos sin confirmaciones

Los modos que lo omiten todo eliminan algo más que las confirmaciones. En Codex, el flag elimina tanto las aprobaciones como el sandbox. Cursor describe Run Everything como ejecutar automáticamente cada llamada a herramientas sin sandbox y sin revisor. El modo bypass de Claude Code también omite las confirmaciones para escrituras en su propio directorio .claude y en .git.

Los fabricantes coinciden en dónde deben usarse estos modos: Claude Code indica que el modo bypass solo debe usarse en entornos aislados, como contenedores o máquinas virtuales, y Codex marca su flag como de riesgo elevado y no recomendado. Incluso dentro de un contenedor, todo lo que esté montado en él, como una credencial de la nube o un agente SSH, queda a su alcance. La guía sobre a qué pueden acceder los agentes enumera lo que eso suele incluir.

Qué puede cambiar un repositorio

La configuración de los agentes vive cada vez más en el repositorio, junto al código: ajustes en .claude/, .codex/config.toml, .cursor/mcp.json, definiciones de hooks y archivos de instrucciones como AGENTS.md y CLAUDE.md. Es cómodo para los equipos, y significa que un git clone puede cambiar el comportamiento de un agente.

• Los controles de confianza ayudan. Codex carga la capa .codex/ de un proyecto solo después de que confíes en él. Claude Code aplica las reglas allow de un repositorio solo después de que cada miembro del equipo confíe en la carpeta, e ignora bypassPermissions como modo por defecto en los ajustes del proyecto.
• No todo pasa por el mismo control. Los hooks, las definiciones de servidores MCP y los archivos de instrucciones siguen llegando con el repositorio; los servidores MCP tienen su propia solicitud de aprobación, y la confianza en el espacio de trabajo de Cursor está desactivada salvo que la actives.
• Las versiones antiguas se comportan de otra forma. Un ajuste que las versiones actuales ignoran puede seguir siendo respetado por un cliente antiguo en la máquina de alguien, y su mera presencia te indica que el proyecto espera que los agentes funcionen sin supervisión.

Ajustes del agente que no conviene commitear

Estos son los patrones que vale la pena detectar en la revisión antes de que lleguen a la rama principal:

• Aprobaciones desactivadas: bypassPermissions como modo por defecto, un subagente con permissionMode: bypassPermissions o un script del paquete que inicia un agente con --dangerously-skip-permissions o --dangerously-bypass-approvals-and-sandbox.
• Reglas allow que lo aprueban todo de antemano: Bash(*), o comodines sobre shells, intérpretes, ejecutores de paquetes y herramientas de red como Bash(curl:*) o Bash(npx:*).
• Hooks que descargan y ejecutan un script, por ejemplo, redirigir la salida de curl a una shell.
• Servidores MCP sin versión fijada, lanzados desde un script remoto, accesibles por HTTP sin cifrar o configurados con una credencial escrita en el código.
• Texto oculto en archivos de instrucciones: comentarios HTML o Unicode invisible en AGENTS.md o CLAUDE.md que un revisor no puede ver pero que el agente sí lee.

{  "permissions": {    "defaultMode": "bypassPermissions",    "allow": ["Bash(*)", "Bash(curl:*)", "Bash(npx:*)"]  }}

Una base más segura

1. Mantén el modo por defecto o el modo auto en los portátiles; reserva los modos que lo omiten todo para entornos desechables.
2. Commitea reglas allow acotadas a los comandos exactos que ejecuta tu proyecto y deniega la lectura de secretos.
3. Fija las versiones de los servidores MCP y guarda sus credenciales en variables de entorno, no en el archivo.
4. Activa el sandbox donde sea opcional y limita el acceso a la red a una allowlist.
5. Trata en la revisión los cambios en la configuración del agente y en los archivos de instrucciones como relevantes para la seguridad.

{  "permissions": {    "allow": ["Bash(npm run test:*)", "Bash(npm run lint)"],    "deny": ["Read(./.env)", "Read(./secrets/**)"]  }}

Una regla allow que termina en comodín es tan segura como el comando que la precede: una regla para npm run test es acotada; una regla para node o curl, no.

Dónde encaja vetkit

La auditoría de repositorios de vetkit revisa la configuración de agentes commiteada como parte de su suite de riesgos del código generado por IA: ajustes y flags que omiten las aprobaciones, reglas allow que aprueban de antemano comandos arbitrarios de shell o de red, hooks que ejecutan scripts remotos, servidores MCP sin versión fijada o lanzados de forma remota, servidores MCP sobre HTTP sin cifrar o con credenciales escritas en el código, y comentarios o Unicode ocultos en los archivos de instrucciones de los agentes. Las mismas reglas se comparten con el servidor @vetkit/mcp y con Agent Watch, que informa de lo que los agentes hacen realmente en las máquinas del equipo; la guía de monitorización cubre esa parte.

Fuentes

Leímos las afirmaciones sobre cada herramienta en su propia documentación el 10 de noviembre de 2026:

• Claude Code: permisos, ajustes y seguridad
• OpenAI Codex: aprobaciones y seguridad del agente y conceptos básicos de configuración
• Cursor: modos de ejecución y seguridad del agente

Los nombres de productos son marcas comerciales de sus respectivos propietarios. vetkit no está afiliado a ellos ni cuenta con su respaldo o patrocinio. ¿Has visto algo desactualizado? Escribe a contact@vetkit.dev y lo corregiremos.