É seguro deixar a IA executar comandos de terminal?

É seguro deixar a IA executar comandos de terminal? Sim, na sua própria máquina, num repositório que dá para reverter, e só depois de ler o que está prestes a rodar. Não, no momento em que uma ferramenta joga a saída do modelo direto no shell sem passo de confirmação. O resto é o modelo de ameaças por trás dessa resposta.

1. O que exatamente você está entregando

Um agente com acesso ao shell pode fazer tudo o que seu usuário pode: ler variáveis de ambiente — e os tokens que estão nelas; ler ~/.ssh e ~/.aws/credentials; alterar configurações; instalar serviços que sobrevivem a um reboot. Isso não é uma hipótese sobre uma IA malévola. Um único erro basta.

2. A diferença entre «sugerir» e «executar»

$ clai remova todos os contêineres parados e imagens não utilizadas→ docker system prune -a⚠ CAUTION — remove toda imagem que não esteja em uso por um contêiner rodandoExecutar? digite yes para confirmar:

Gerar e executar são dois passos distintos. Uma ferramenta que joga a saída do modelo direto no shell removeu a única barreira entre um erro de digitação do modelo e o seu disco.

3. Três níveis de risco que vale a pena distinguir

SAFE — comandos de leitura: ls, ps, df, git log. Um erro custa tempo. CAUTION — comandos que mudam o estado: docker prune, git reset, systemctl restart, chmod -R. Um erro custa retrabalho. DANGER — irreversíveis: rm -rf, dd, mkfs, DROP TABLE, force push. Um erro custa dados.

O que ajuda não é o rótulo em si, mas o fato de ele forçar uma pausa exatamente onde o custo de um erro sobe uma ordem de grandeza.

4. Peça uma simulação antes

$ clai sincronize esta pasta com o prod, mas primeiro mostre o que vai acontecer→ rsync -av --dry-run ./build/ deploy@prod:/var/www/

Quase toda operação destrutiva tem um modo «só mostrar»: rsync --dry-run, git clean -n, find sem -delete. Peça esse modo primeiro sempre que produção estiver envolvida.

5. Limite o raio de impacto, não a confiança

Um usuário separado para tarefas do agente. Tokens com escopo mínimo e vida curta. Produção tocada apenas por um canal separado com revisão. São as mesmas regras que você daria a um estagiário no primeiro dia, e funcionam pelo mesmo motivo: não dependem de quão boa é a IA.

6. Confira o que realmente rodou

$ clai mostre os últimos 20 comandos que rodei pelo clai→ cliai log --tail 20

Um log local de pedidos dá uma análise posterior. Se algo der errado, você vê exatamente qual frase gerou qual comando.

Pegadinhas

• O perigoso não é só o comando destrutivo, é também o vazamento. Um agente que imprime variáveis de ambiente durante uma depuração acabou de colocar seus tokens num log, e esse log pode sair da máquina.
• «Eu confiro depois» não funciona. Você lê o comando antes do Enter. Depois do Enter, você já está lendo as consequências.
• Modo autônomo na sua máquina e em produção são decisões diferentes. Num sandbox descartável ou num repositório git, a execução automática é razoável. Num servidor com dados reais, não.

Perguntas relacionadas

Tudo bem dar acesso ao terminal para a IA? Para trabalho reversível — um repositório git, um sandbox, sua própria máquina — sim, desde que confirme antes de executar. Em produção, só o modo «me mostre, eu decido».

Qual a diferença para copiar e colar do Stack Overflow? Em princípio, nenhuma, e esse é o argumento central. Um comando da internet você também lê antes de rodar. A única diferença é que este foi gerado para o seu sistema.

E se mesmo assim rodar o comando errado? Pare o processo, olhe o log local de pedidos, avalie o estrago. É exatamente por isso que operações irreversíveis exigem confirmação digitada, não uma única tecla.

Veja também

• SAFE, CAUTION, DANGER: como o CliAI classifica o que vai rodar
• Por que uma CLI e não um chat: a filosofia do CliAI
• Linguagem natural para comando de shell: como funciona

O CliAI mostra o comando e espera sua confirmação antes de rodar qualquer coisa destrutiva — comece aqui.