Deixar uma IA Escrever Código que Pode Apagar Coisas, em Segurança

Pedi ao meu sistema de IA uma coisa pequena e maçadora: limpar os processos deixados a correr na máquina depois de um dia de trabalho. A forma óbvia de fazer essa tarefa teria sido um desastre silencioso.

Um dia a construir deixa lixo digital: um servidor de desenvolvimento ainda agarrado a uma porta, um navegador em segundo plano que nunca fechou, um script que sobreviveu ao seu propósito. Limpar esse lixo é precisamente o tipo de tarefa que se quer automatizar. Mas "terminar os processos deixados a correr" é uma armadilha, porque o lixo e aquilo que nunca se pode terminar parecem quase iguais visto de fora.

Tudo parece lixo

Na minha máquina, uma limpeza ingénua do género "encontra os processos node, python e do navegador perdidos e termina-os" teria eliminado, sem ordem particular:

• os processos auxiliares de uma sessão de trabalho ativa que eu ainda tinha aberta noutra janela, e
• o meu navegador de facto.

Nenhum destes é lixo. E uma limpeza mais abrangente, corrida com mais privilégios, teria ido mais longe, até um contentor que fazia trabalho real e que só escapou por correr sob um utilizador de sistema diferente. Cada um apresenta-se ao sistema operativo como um processo node, python ou chrome genérico, com a mesma forma do lixo que eu queria eliminar. As duas coisas que eu realmente queria terminar (um servidor de desenvolvimento perdido, um daemon de navegador abandonado) eram um conjunto pequeno e nomeável. Tudo o resto era uma dependência viva com o mesmo disfarce.

Esta é a forma geral de qualquer operação destrutiva que uma IA possa escrever por si: o raio de destruição é definido por aquilo que o código decide poupar, e "o que poupar" é fácil de errar de forma catastrófica.

Regra 1: crie uma barreira determinística, não confie no juízo do modelo

A tentação é tornar a IA mais esperta a distinguir um processo perdido de um processo vivo. É o instinto errado. "Mais esperto" significa que o modelo volta a fazer um juízo difuso de cada vez que corre, e uma decisão má é irreversível.

Por isso a limpeza não deixa o modelo decidir o que terminar. Está construída à volta de uma barreira explícita e mecânica:

• uma denylist com o que nunca pode tocar: sessões ativas, as próprias ferramentas que orquestram o trabalho, a sincronização de ficheiros em segundo plano, serviços do sistema, tudo o que esteja dentro de um contentor;
• uma allowlist curta com o que pode terminar: os servidores e daemons específicos que são genuinamente descartáveis;
• e para todo o resto: não fazer nada.

Um processo desconhecido não é candidato a ser terminado. É poupado por omissão. É preciso merecer a eliminação, estando na allowlist e ausente da denylist. A segurança vive nas listas, que eu escrevi e consigo ler, e não no quão afiado o modelo está numa dada tarde.

O teste de saber se construiu isto bem: um modelo mais fraco e mais barato conseguiria correr isto em segurança? Se a resposta for não, a segurança nunca esteve no código, esteve na esperança de o modelo se manter esperto. Com o juízo movido para uma barreira explícita, o modelo em tempo de execução limita-se a aplicar uma verificação determinística.

Regra 2: dê ao caminho automático um raio de destruição menor

Esta limpeza corre de duas maneiras: quando eu a peço explicitamente, e automaticamente quando uma sessão termina. Não têm o mesmo risco.

Quando a peço, estou a ver. Quando dispara por sua conta (incluindo quando eu apenas reinicio o meu espaço de trabalho a meio de uma tarefa, ainda a trabalhar), não está ninguém. Por isso o caminho automático é deliberadamente mais tímido: só elimina processos genuinamente abandonados (cujo processo-pai já desapareceu) e recusa-se a correr nos eventos com maior probabilidade de dispararem enquanto ainda estou a trabalhar. A mesma ferramenta, dois níveis de segurança, ajustados à presença ou ausência de uma pessoa.

Uma operação que corre sem supervisão nunca deve ter o mesmo alcance de uma que aciona pessoalmente. Não é paranoia; é ajustar o raio de destruição à quantidade de supervisão.

Regra 3: ponha um adversário a tentar parti-lo antes de correr

Esta é a parte que realmente me salvou.

O agente que escreveu o script de limpeza também escreveu um conjunto completo de testes, correu-os e reportou sucesso: tudo o que era protegido continuava vivo, tudo o que era descartável tinha desaparecido. Tudo verde.

Depois fiz algo diferente. Dei o script terminado a um segundo agente independente com uma única instrução: não confirmes que funciona, tenta fazê-lo terminar o processo errado.

Encontrou três falhas reais, nenhuma delas apanhada pelos testes que passaram:

1. Um caminho de eliminação ignorava a lista de segurança por completo. Um caso especial para limpar processos do navegador correspondia a um padrão de texto em bruto, contornando a denylist, o que significava que, nas condições certas, poderia ter correspondido e terminado o meu navegador de facto, e não o descartável.
2. Uma definição partilhada podia terminar uma sessão viva. Com duas sessões de automação de navegador a correr, uma abandonada e uma viva, uma única definição partilhada marcaria também a viva para eliminação. Exatamente a sessão que era suposto proteger.
3. Um padrão era demasiado ganancioso. A regra pensada para apanhar um servidor de ficheiros descartável correspondia também a ollama serve, o comando que corre um modelo de IA local. Limpar "lixo" teria desligado um servidor de modelo a correr.

Cada uma destas é a diferença entre uma ferramenta útil e um incidente. E cada uma passou pelos testes verdes de quem a implementou, porque um teste escrito pelo autor verifica os casos em que o autor pensou. Um adversário verifica os casos em que ele não pensou.

Isto não é exótico. É o mesmo princípio de pedir a alguém para provar que uma afirmação é falsa em vez de confirmar que é verdadeira: obtêm-se respostas completamente diferentes, e muito mais úteis, do mesmo modelo, sobre o mesmo código, só por apontá-lo na direção contrária.

O que "possuir a sua IA" significa de facto

Fala-se muito sobre se se deve confiar à IA acesso real aos nossos sistemas. Acho que esse enquadramento falha o essencial. A questão não é confiança, é estrutura.

A produtividade vem de deixar a IA escrever o código operacional, maçador e propenso a erros que preferia não escrever à mão. A segurança vem de recusar que o resultado corra na base da confiança: limita as partes destrutivas atrás de regras que controla, dá aos caminhos automáticos menos alcance do que aos supervisionados, e envia tudo o que é irreversível por uma revisão adversarial antes de sequer executar.

É isto que possuir um agente de IA parece na prática: não alugar uma caixa preta e cruzar os dedos, mas correr uma que se consegue inspecionar, limitar e supervisionar. O agente faz o trabalho. As chaves ficam consigo.

Este artigo é sobre prática de engenharia, não um argumento de venda, mas é também exatamente como construímos a automação que entregamos a clientes: a IA faz o trabalho, barreiras determinísticas e revisão humana seguram a linha. Se é este o tipo de IA que quer no seu negócio, uma que possui e supervisiona em vez de alugar e confiar, é essa a conversa que temos.