¿Es seguro dejar que la IA ejecute comandos de terminal? Sí, en tu propia máquina, en un repositorio que puedes revertir, y solo después de leer lo que está a punto de ejecutarse. No, en el momento en que una herramienta envía la salida del modelo directo a un shell sin paso de confirmación. Lo que sigue es el modelo de amenazas detrás de esa respuesta.
1. Qué es exactamente lo que entregas
Un agente con acceso al shell puede hacer todo lo que puede hacer tu usuario: leer variables de entorno —y los tokens que contienen—; leer ~/.ssh y ~/.aws/credentials; reescribir configuraciones; instalar servicios que sobreviven a un reinicio. No es una hipótesis sobre una IA maliciosa. Basta un solo error.
2. La diferencia entre «sugerir» y «ejecutar»
$ clai elimina todos los contenedores parados y las imágenes sin usar→ docker system prune -a⚠ CAUTION — elimina toda imagen que no use un contenedor en ejecución¿Ejecutar? escribe yes para confirmar:Generar y ejecutar son dos pasos distintos. Una herramienta que envía la salida del modelo directo al shell ha eliminado la única barrera entre un error tipográfico del modelo y tu disco.
3. Tres niveles de riesgo que conviene distinguir
SAFE — comandos de solo lectura: ls, ps, df, git log. Un error cuesta tiempo.
CAUTION — comandos que cambian el estado: docker prune, git reset, systemctl restart, chmod -R. Un error cuesta trabajo.
DANGER — irreversibles: rm -rf, dd, mkfs, DROP TABLE, force push. Un error cuesta datos.
Lo útil no es la etiqueta en sí, sino que obliga a detenerse justo donde el costo de un error se multiplica por diez.
4. Pide una prueba en seco
$ clai sincroniza esta carpeta a producción, pero antes muéstrame qué haría→ rsync -av --dry-run ./build/ deploy@prod:/var/www/Casi toda operación destructiva tiene un modo «solo mostrar»: rsync --dry-run, git clean -n, find sin -delete. Pídelo primero siempre que esté en juego producción.
5. Limita el radio de impacto, no la confianza
Un usuario aparte para las tareas del agente. Tokens con permisos mínimos y vida corta. Producción, solo a través de un canal aparte con revisión. Son las mismas reglas que le darías a alguien nuevo el primer día, y funcionan por la misma razón: no dependen de lo buena que sea la IA.
6. Verifica qué se ejecutó realmente
$ clai muéstrame los últimos 20 comandos que ejecuté con clai→ cliai log --tail 20Un registro local de peticiones te da un análisis posterior. Si algo sale mal, puedes ver exactamente qué frase produjo qué comando.
Trampas
- Lo peligroso no es solo el comando destructivo, también la fuga. Un agente que imprime variables de entorno mientras depura acaba de poner tus tokens en un log, y ese log puede salir de la máquina.
- «Ya lo reviso después» no funciona. Lees el comando antes de Enter. Después de Enter, lees las consecuencias.
- El modo autónomo en tu máquina y en producción son decisiones distintas. En un sandbox descartable o un repositorio git, la ejecución automática es razonable. En un servidor con datos reales, no.
Preguntas relacionadas
¿Está bien dar acceso al terminal a la IA? Para trabajo reversible —un repositorio git, un sandbox, tu propia máquina— sí, siempre que confirme antes de ejecutar. En producción, solo el modo «muéstrame, yo decido».
¿En qué se diferencia de copiar y pegar de Stack Overflow? En principio, en nada, y ese es el argumento clave. Un comando de internet también lo lees antes de ejecutarlo. La única diferencia es que este se generó para tu sistema.
¿Qué hago si de todos modos se ejecuta el comando equivocado? Detén el proceso, revisa el registro local de peticiones, evalúa el daño. Por eso las operaciones irreversibles piden confirmación escrita, no una sola tecla.
Ver también
- SAFE, CAUTION, DANGER: cómo clasifica CliAI lo que va a ejecutarse
- Por qué una CLI y no un chat: la filosofía de CliAI
- De lenguaje natural a comando de shell: cómo funciona
CliAI te muestra el comando y espera tu confirmación antes de ejecutar algo destructivo — empieza aquí.