Permisos y límites

El llavero del portero

Un portero tiene llaves de todo el edificio, pero no abre cualquier puerta a cualquiera. Las zonas delicadas (la sala de contadores, el cuarto de máquinas) exigen permiso aunque quien pregunte parezca de fiar.

Con un agente pasa lo mismo: dar acceso a herramientas lo hace productivo, pero un acceso sin límites trae tres riesgos que cita la fuente: operaciones destructivas (como rm -rf o DROP TABLE), condiciones de carrera por llamadas simultáneas y violaciones silenciosas de política por permisos mal configurados.

Regla 1: «fail-closed» por defecto

Fail-closed significa que, si no sabes, se cierra. Una herramienta nueva se trata como no de solo lectura y no apta para ejecución simultánea, salvo que alguien la marque explícitamente como segura. Así se evita corrupción de datos por escrituras concurrentes.

Regla 2: la seguridad depende de la llamada, no solo de la herramienta

La misma herramienta puede ser segura con unas entradas y peligrosa con otras. Por ejemplo, con una shell:

Seguras (pueden ir a la vez):   cat archivo.txt   |  grep "patrón" src/  |  ls -la
Inseguras (una a una):          rm -rf build/     |  npm install         |  sed -i ... *.ts

El motor agrupa las llamadas: las seguras corren en paralelo; cualquier insegura abre un tramo en serie.

Regla 3: una cadena de permisos con orden estricto

Cuando hay varias fuentes de reglas, el orden de prioridad de la fuente es:

Política (organización) -> Ajustes de usuario -> Reglas de proyecto -> Overrides locales -> Permisos de sesión

Cada capa puede permitir, denegar o «aplazar» a la siguiente. Ojo: evaluar permisos tiene efectos laterales (registrar denegaciones, cambiar de modo tras un rechazo), así que no cachees resultados entre llamadas.

Regla 4: zonas que nunca se aprueban solas

Hay rutas y comandos que deberían preguntar siempre, incluso en modo automático. Ejemplo de la fuente:

protected_paths: [/etc/**, /usr/**, node_modules/**, .git/**]
protected_commands: ["rm -rf*", "DROP TABLE*", "DELETE FROM*", "mkfs*"]

Checklist antes de activar una herramienta

- [ ] ¿Es de solo lectura? (sí / no / depende de los argumentos)
- [ ] ¿Es segura en paralelo?
- [ ] Modo por defecto: preguntar o denegar
- [ ] Rutas y comandos protegidos definidos
- [ ] Probada con entradas seguras (se aprueban) e inseguras (preguntan)
- [ ] Fallos registrados sin dejar estado a medias

Las reglas del proyecto viven en archivos como los que veremos en AGENTS.md corto.