Quando um agente de IA passa a executar tarefas de verdade, e não apenas responder perguntas, aparece uma decisão que costuma ser tomada às pressas: o que ele pode fazer?
A resposta prática, na maioria dos projetos, é alguma variação de tudo. Dá-se ao agente uma credencial ampla, acesso ao servidor, permissão de escrita no banco, e confia-se que ele fará apenas o que foi pedido. Funciona quase sempre. O problema é o quase.
Por que a tentação é forte
Vale reconhecer o motivo, porque ele é legítimo: delimitar permissão dá trabalho e atrasa o resultado. Você quer que o agente leia um arquivo, consulte um registro e atualize um status. Dar acesso amplo faz isso funcionar em cinco minutos. Mapear exatamente cada operação necessária leva uma tarde.
E há um segundo motivo, mais sutil: no começo, ninguém sabe do que o agente vai precisar. O escopo é descoberto enquanto se constrói. Acesso amplo parece a escolha pragmática para não travar a cada passo.
A armadilha é que essa configuração temporária nunca é revisitada. O que foi aberto para destravar o desenvolvimento continua aberto em produção, com dado real.
O risco que não é o que parece
Quando se fala em risco de agente com acesso amplo, a imagem que vem é a de um ataque: alguém manipula o agente por uma instrução maliciosa e faz com que ele apague o banco. Isso é real e tem nome, mas não é o caso mais comum.
O caso mais comum é bem mais banal: o agente faz exatamente o que entendeu, e entendeu errado. Recebe a tarefa de limpar registros antigos e tem uma noção de antigo diferente da sua. Recebe a tarefa de padronizar um campo e padroniza em todos os registros, inclusive nos que não deveriam mudar.
Não há malícia nenhuma nisso. Há uma instrução ambígua encontrando uma permissão ampla, que é a combinação que produz a maior parte dos acidentes.
Três camadas que resolvem quase tudo
1. Expor funções, não credenciais
Essa é a mudança mais importante e a mais fácil de aplicar. Em vez de dar ao agente uma chave de banco e deixá-lo escrever consultas livremente, exponha funções específicas: buscar_pedido, atualizar_status, listar_pendentes.
Cada função faz uma coisa, valida a entrada e não aceita ser usada de outro jeito. O agente escolhe qual chamar, mas não escolhe o que a função permite. A diferença é enorme: o espaço de ações possíveis deixa de ser infinito e passa a ser uma lista que você escreveu.
2. Separar leitura de escrita
A maioria das tarefas de agente é de leitura: consultar, resumir, comparar, responder. Escrita costuma ser a minoria, e é onde mora o risco.
Separar as duas, com credenciais diferentes, permite ser generoso onde é barato e rigoroso onde importa. E revela uma coisa útil: ao mapear as operações, muitos times descobrem que o agente nem precisava de escrita, bastava sugerir a ação para alguém aprovar.
3. Confirmação para o que não tem volta
Nem toda operação merece o mesmo tratamento. Atualizar um campo é reversível. Apagar registros, enviar mensagem para cliente, mover dinheiro e alterar configuração de produção não são.
Para essas, o agente prepara e alguém confirma. Isso não torna o fluxo manual, porque noventa e cinco por cento continua automático. Torna o fluxo supervisionado exatamente onde a supervisão vale a pena.
O caso específico do acesso ao servidor
Quando o agente ganha acesso a terminal, vale um cuidado extra, porque terminal é a permissão que contém todas as outras.
Três práticas reduzem bastante o risco: rodar o agente com um usuário próprio, sem privilégios administrativos, em vez do usuário root; restringir o acesso a um diretório específico, de modo que o resto do sistema não esteja ao alcance; e manter um registro do que foi executado, porque sem log não há como reconstruir o que aconteceu depois de um incidente.
Como descobrir o mínimo de verdade
Existe um método simples e que funciona: comece negando tudo e vá liberando conforme quebrar.
Rode o agente com permissão mínima e observe onde ele falha. Cada falha revela uma necessidade real. Ao final de alguns ciclos, você tem uma lista exata do que é necessário, obtida por evidência em vez de suposição. O caminho contrário, começar aberto e tentar fechar depois, quase nunca acontece, porque fechar significa arriscar quebrar algo que já funciona.
O princípio, em uma frase
A pergunta certa não é o que o agente precisa para funcionar. É o que ele precisaria para causar um estrago que você não consegue desfazer. Se a resposta for uma permissão que ele tem e não usa, esse é o item a remover primeiro.
Um agente bem delimitado não é menos útil. É apenas um agente cujo pior dia possível continua sendo um dia administrável.
Para montar esse tipo de ambiente com isolamento desde o começo, veja as opções de infraestrutura da StayCloud.
