El artículo nada sexy. El que decide si Claude Code se convierte en infraestructura o en la historia que cuentas en un postmortem.

Esta es la regla en torno a la cual construyes todo lo demás:

Esa única regla aclara el 90 % de las decisiones de permisos. Todo lo demás es operativizarla.

Reversibilidad, no "miedo"

La mayoría de equipos configuran allowlists por instinto. "Los tests parecen seguros; los deletes dan miedo." Está mal.

Reformula alrededor del blast radius:

• Reversible: editar un archivo en tu working tree, correr tests, hacer pnpm install, crear una feature branch. Si algo se rompe, git checkout/git stash te salva.
• Irreversible: git push, npm publish, migraciones de DB en prod, terraform apply, enviar correos, cobrar tarjetas, borrar recursos cloud.

La primera lista debería estar en la allowlist del agente. La segunda debería exigir una pulsación humana cada vez, sin excepciones.

El .claude/settings.json mínimo para un repo de producción

{
  "tools": {
    "shell": {
      "allow": [
        "pnpm test",
        "pnpm test:watch",
        "pnpm lint",
        "pnpm build",
        "pnpm db:migrate:dev",
        "pnpm db:reset:dev",
        "pnpm install",
        "git status",
        "git diff *",
        "git log *",
        "git stash *",
        "git checkout *",
        "git branch",
        "git add *",
        "git commit *",
        "ls *",
        "rg *",
        "cat *"
      ],
      "deny": [
        "git push *",
        "git rebase *",
        "git reset --hard *",
        "rm -rf *",
        "npm publish *",
        "pnpm publish *",
        "docker push *",
        "kubectl apply *",
        "terraform apply *",
        "aws *",
        "gcloud *",
        "psql -h prod*"
      ]
    }
  }
}

Algunas cosas a fijarse:

• git commit está permitido; git push no. El agente puede preparar un cambio local; tú lo publicas.
• pnpm db:migrate:dev está permitido; la variante prod no — y las migraciones de prod no deberían ejecutarse desde una máquina de dev.
• aws * y gcloud * se deniegan en bloque. Si necesitas un sub-agente que llame APIs cloud, dale un comando específico, no la CLI entera.

La lista "archivos que el agente no debe tocar nunca"

Aunque confíes en el agente, ciertos archivos deben requerir edición humana. Bloquéalos en CLAUDE.md:

# Nunca modificar
- /infra/terraform/   (solo humanos)
- /.github/workflows/release.yml
- El campo "version" de /package.json
- Cualquier archivo en /db/migrations/ ya aplicado
- /SECURITY.md

Claude Code respeta con fuerza las instrucciones de CLAUDE.md. Combinado con la revisión del git diff, basta para el 99 % de los equipos.

Separación de roles de sub-agentes = defensa en profundidad real

Cubrimos los 11 sub-agentes en el artículo 5. Por qué importa la separación de roles para la seguridad:

• code-reviewer no puede editar. Aunque "decida" que algo está bien, no puede enviarlo.
• test-writer no puede tocar código de producción. Un test fallido es evidencia real, no salida flaky.
• migration-runner solo puede correr pnpm db:migrate. Aun comprometido, el blast radius es un comando.

Esa es defensa en profundidad real — construida con archivos de restricciones, no con teatro de seguridad.

Cosas que no deberías automatizar

Una lista corta de "no, aunque funcione":

• Publicar en canales públicos (Slack, Discord, Twitter). La latencia da igual; un mensaje con tono fuera de lugar en #engineering, no.
• Correos a clientes. Contenido generado, vale en borradores. El envío es humano.
• Dinero. Cargos, reembolsos, payouts. No automatizar. Nunca.
• Auth e identidad. Añadir usuario, conceder admin, rotación de claves.
• Force pushes. Incluso en feature branches. El coste de un force-push accidental es demasiado alto.

Regla práctica: si el peor coste es un postmortem, un correo de disculpa o una carta del regulador, mantén una pulsación humana entre intención y ejecución.

Trazabilidad — la feature infravalorada

Cada sesión de Claude Code escribe un transcript en ~/.claude/sessions/. En equipo, manda esos transcripts a algo durable:

• Un bucket S3 privado.
• Un stream de logs en Datadog.
• Un simple git log de .claude/transcripts/ commiteado en el repo.

No los leerás a menudo. Pero el día que sí — cuando algo raro pase en la base y necesites saber quién/qué la cambió — son oro.

Checklist práctica de seguridad

Antes de dejar correr Claude Code sobre una base real:

• .claude/settings.json con allow y deny explícitos.
• CLAUDE.md con sección "Nunca modificar".
• .claude/agents/ incluye al menos code-reviewer y test-writer.
• git push no está en ninguna allowlist.
• Un compañero ha revisado la allowlist.
• Probaste primero claude --dry-run (o el equivalente en tu versión) en una feature branch.

Seis ítems. Veinte minutos de trabajo. La mayoría de incidentes de prod vienen de saltarte al menos tres.

---

Próximo artículo: Pipelines multi-agente — encadenar sub-agentes, ejecutarlos en paralelo y los patrones para "revisión-mientras-codeo" sin perder la cabeza.