Por qué tu asistente de IA para programar es un riesgo de seguridad (y cómo solucionarlo)

La semana pasada me di cuenta de algo alarmante. Llevaba meses permitiendo que un asistente de IA ejecutara comandos libremente en mi máquina. Tenía acceso a credenciales de AWS, claves SSH, repos privados de GitHub y todo lo que guardaba en mi directorio home. Lo peor: ni lo había considerado porque era práctico y no había pasado nada grave.

Ese es el error que borra bases de datos en producción.

La comodidad engaña y expone

La realidad duele: los agentes de IA para código manejan permisos como si fueran ingenieros senior desde el primer día. No le darías a un contratista nuevo acceso SSH total a todos los servidores. Pero a un LLM sí, sin pensarlo dos veces.

No se trata de intenciones malas. Es descuido puro. Son tan útiles que olvidamos su poder real. Un prompt malicioso en un repo clonado, un objetivo desalineado o un comando inocente podrían enviar tus credenciales a un servidor enemigo. Y ni te enterarías.

Lo positivo: herramientas como Claude Code ofrecen controles sólidos. Solo hay que activarlos.

Los peligros del modo por defecto

Muchos agentes de IA corren en "auto" por defecto. Ejecutan comandos sin preguntar, salvo bloqueos explícitos. Parece eficiente, ¿verdad? Mira lo que permite en la práctica:

Si no bloqueas nada y usas auto, tu IA puede:

• Hacer curl a cualquier sitio.
• Descargar con wget.
• Conectar vía ssh a servidores remotos.
• Abrir conexiones con nc.
• Leer todos los .env del proyecto.
• Acceder a ~/.aws/credentials, ~/.ssh, ~/.gnupg.
• Subir código a repos directamente.

Todo en silencio. Sin avisos. Sin pausas.

Un modelo de seguridad en tres capas

Necesitas control preciso. No todo requiere tu OK, pero acciones clave sí. Así lo estructuro:

Capa 1: Bloqueo total

Prohíbe acceso a credenciales desde el principio:

{
  "deny": [
    "Read(~/.ssh/**)",
    "Read(~/.aws/**)",
    "Read(~/.gnupg/**)",
    "Read(~/.azure/**)",
    "Read(~/.kube/**)",
    "Read(~/.npmrc)",
    "Read(~/.git-credentials)",
    "Read(*.env)",
    "Read(.env.*)",
    "Bash(curl *)",
    "Bash(wget *)",
    "Bash(nc *)",
    "Bash(ssh *)"
  ]
}

Es tu firewall. Nada pasa, pase lo que pase.

Capa 2: Pide confirmación

Para acciones reversibles pero riesgosas:

{
  "ask": [
    "Bash(git push *)",
    "Bash(git commit *)",
    "Bash(git merge *)",
    "Bash(git reset *)",
    "Bash(npm publish *)",
    "Bash(docker push *)"
  ]
}

La IA las necesita a veces. Pero tú revisas antes. Eficiencia sin locuras.

Capa 3: Permite lo seguro

Da luz verde a lo inofensivo:

{
  "allow": [
    "Bash(npm run *)",
    "Bash(git status *)",
    "Bash(git diff *)",
    "Bash(git log *)",
    "Bash(ls *)",
    "Read(src/**)",
    "Read(tests/**)"
  ]
}

Corre libre. No cambian nada crítico.

Elige bien el modo base

Con listas listas, define el default para lo demás. Opciones:

1. auto: Ejecuta lo no bloqueado sin avisar. Rápido, pero confía en tu lista deny.

2. acceptEdits: Lee y edita libre, pero pregunta por comandos bash fuera de allow. Equilibrado.

3. ask: Consulta todo riesgoso. Lento, pero ultra seguro.

acceptEdits funciona genial para la mayoría. Mantiene el ritmo sin riesgos tontos.

Configuración lista para usar

Así queda una setup de verdad:

{
  "permissions": {
    "deny": [
      "Read(~/.ssh/**)",
      "Read(~/.aws/**)",
      "Read(~/.gnupg/**)",
      "Read(~/.azure/**)",
      "Read(~/.kube/**)",
      "Read(~/.npmrc)",
      "Read(~/.git-credentials)",
      "Read(~/.config/gh/**)",
      "Read(*.env)",
      "Read(.env.*)",
      "Bash(curl *)",
      "Bash(wget *)",
      "Bash(nc *)",
      "Bash(ssh *)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(git commit *)",
      "Bash(npm publish *)",
      "Bash(docker push *)"
    ],
    "allow": [
      "Bash(npm run *)",
      "Bash(npm install *)",
      "Bash(npm test *)",
      "Bash(git status *)",
      "Bash(git diff *)",
      "Bash(git log *)"
    ],
    "defaultMode": "acceptEdits"
  }
}

Tu IA ayuda con tests, código y análisis. Pero no roba datos ni sube sin permiso.

Dos enfoques según el caso

Uso alias en shell:

# Normal: seguridad equilibrada
alias cc="claude --permission-mode auto"

# Emergencia: full trust (poco)
alias ccd="claude --permission-mode dangerously-skip-permissions"

cc para el día a día. ccd solo en crisis, con decisión consciente.

El problema afecta a todos

No es solo Claude Code. Copilot, Devin, Cursor, ChatGPT con ejecución: todos exponen lo mismo. Conveniencia vs. seguridad.

Claude destaca por sus controles finos. Otros te obligan a todo o nada.

Implicaciones para equipos

En empresas, es vital. No confíes en que cada dev lo configure bien.

Haz:

• Listas deny obligatorias en configs compartidas.
• Bloquea archivos de credenciales en filesystem.
• Usa tokens temporales, no claves eternas.
• Controles de red contra fugas.
• Capacita en productividad vs. riesgos.

En resumen

Los asistentes de IA para código valen oro. Pero exigen configuración.

Dedica 15 minutos hoy. Bloquea credenciales. Pide OK para deploys. Elige default sensato. Así usas IA productiva y segura.

"No ha pasado nada" no es plan de seguridad.