Privilégio mínimo para agentes de IA: a lição de 1975 que seu piloto está ignorando
O risco de um agente de IA não é uma questão de capacidade que depende do fornecedor. É uma questão de autoridade que você mesmo já respondeu, no dia em que entregou as credenciais.
A maioria dos pilotos de agentes de IA está travada na pergunta errada: o modelo já é bom o suficiente? O privilégio mínimo para agentes de IA resolve mais risco real em uma tarde do que um ano inteiro esperando a próxima versão do modelo. O estrago que um agente pode causar é definido por três coisas que já estão sob seu controle: as chaves de acesso que ele carrega, os caminhos de escrita que essas chaves abrem e se alguém realmente testou a restauração.
Acompanhe o mecanismo em um caso documentado. O próprio relato oficial da Replit confirma que o Agent da empresa apagou dados do banco de dados de um aplicativo de Jason Lemkin, cofundador da SaaStr, e afirma que o rollback restaurou tudo, sem perda final de dados. Note qual camada salvou essa história. Quem apagou foi o agente. Um snapshot transformou uma exclusão em um contratempo, e não em um evento fatal para a empresa; tire o snapshot e o mesmo comportamento escreve uma manchete bem diferente.
Snapshots são exatamente a camada que todo mundo presume existir e ninguém testa. Quando um engenheiro do GitLab removeu o diretório errado de um banco de dados em janeiro de 2017, o post-mortem publicado pela própria empresa registrou que, das cinco técnicas de backup e replicação nominalmente em vigor, nenhuma funcionava de forma confiável; a recuperação usou uma cópia de staging que por sorte existia com seis horas de defasagem, e esses dados foram perdidos. Nenhum agente, nenhuma tecnologia nova, apenas um comando destrutivo encontrando um caminho de recuperação nunca testado. É exatamente esse risco que o seu programa de agentes está bancando silenciosamente, só que agora com um operador mais rápido e menos cansado no teclado.
Por que não basta simplesmente instruir um agente de IA a não apagar nada?
Porque uma instrução é um conselho, e o agente já está de posse das suas credenciais no momento em que a lê. A segurança da informação tem um nome para essa estrutura, e ele é bem anterior à onda atual de IA. Norm Hardy descreveu o problema do “confused deputy” em 1988: um programa que age com a autoridade delegada por uma parte, seguindo instruções fornecidas por outra, sem nenhuma forma confiável de saber quais dos seus poderes a requisição atual deveria poder acionar. O “deputado” não é hostil. Está confuso, e essa confusão opera no nível de privilégio de quem entregou as chaves. Note do que o problema não depende: da competência do deputado, das suas intenções ou de quanto confiam nele.
É por isso que a resposta da disciplina nunca foi tentar melhorar o deputado. Saltzer e Schroeder formularam o princípio do privilégio mínimo em 1975, no clássico artigo sobre proteção em sistemas computacionais publicado nos Proceedings of the IEEE, e a jogada de design é tornar a intenção irrelevante. Dê a cada componente a autoridade mínima que a sua função exige, e um componente se comportando mal, seja qual for o motivo, inclusive motivos que ninguém previu, ainda assim só conseguirá alcançar um conjunto limitado de coisas. As permissões de sistema operacional, os papéis de banco de dados e o IAM de nuvem estão todos a jusante dessa ideia. Os programas de agentes estão reabrindo essa discussão, e o argumento para reabri-la é que esse deputado, dessa vez, parece esperto.
Então um arquivo dizendo “NÃO TOCAR EM PRODUÇÃO” não é um controle. É um bilhete deixado para um processo que já consegue alcançar a produção. Os controles de verdade são os que tornam o bilhete redundante: uma identidade sem permissão de exclusão, uma credencial que nunca esteve naquele arquivo, um backup ao qual o agente não consegue se autenticar. Se o modelo obedeceria ao bilhete numa terça-feira qualquer deixa de ser uma pergunta que você precisa fazer, e esse é justamente o valor da abordagem.
A documentação de segurança do fornecedor descreve o comportamento, não o limita
System cards e relatórios de avaliação valem a leitura, e o setor deveria publicar mais desse material. Ainda assim, leia-os pelo que são. Eles registram como um modelo se comportou no ambiente de teste do fornecedor, em tarefas escolhidas pelo fornecedor, num momento específico. Isso é uma descrição, e descrições não vinculam nada. Nenhum documento de segurança publicado entra na sua conta de nuvem e remove uma permissão de exclusão, e nenhum fornecedor está oferecendo indenizar você pelo que o modelo dele fizer com credenciais que você decidiu conceder. Um comprador que trata divulgação como garantia está lendo o documento ao contrário: o que ele cataloga é exatamente o que você vai acabar absorvendo.
As pontuações de benchmark caem na mesma categoria. Elas medem comportamento típico em tarefas selecionadas, enquanto a sua exposição real é o comportamento de pior caso na sua própria infraestrutura, e nenhuma posição em ranking limita isso. As perguntas de compra que realmente importam são mais mundanas. O que a ferramenta faz quando uma instrução não pode ser cumprida como foi escrita: para e pergunta, ou improvisa algo parecido? O que fica registrado em log quando isso acontece? Quais ações ela consegue tomar sem uma segunda confirmação? Essas respostas mudam como você delimita as permissões. Uma pontuação não muda nada.
É por isso que o ajuste precisa descer uma camada, para uma infraestrutura que não negocia.
Como fica o privilégio mínimo para agentes de IA na prática?
Pare de tratar agentes como funcionários de confiança e comece a tratá-los como terceirizados com crachá de acesso. A pergunta que orienta tudo: que ação irreversível esse agente poderia tomar hoje, se falhasse na próxima hora? Depois, feche esses caminhos: uma identidade por agente, em vez de uma conta de serviço compartilhada; leitura como padrão, com escrita liberada só para um schema ou caminho nomeado; nenhuma credencial de produção em qualquer arquivo de ambiente que o agente consiga ler; backups sob uma identidade que o agente não consegue assumir; e uma restauração ensaiada neste trimestre, não apenas presumida desde 2023. Nada disso é novidade. Toda área de TI faz isso com terceirizados, runners de CI e integrações de terceiros há vinte anos. Está sendo pulado agora porque os pilotos estão sendo conduzidos por times de produto, não de plataforma, na suposição de que um piloto é pequeno. O raio de impacto não liga para o rótulo que você deu ao projeto. Mais sobre como projetar sistemas agênticos que falham de forma segura.
Existe uma camada de responsabilidade civil que raramente chega ao business case, e ela já foi testada em tribunal. Em fevereiro de 2024, o Civil Resolution Tribunal da Colúmbia Britânica condenou a Air Canada a indenizar um passageiro que agiu com base em uma informação sobre tarifa de luto inventada pelo chatbot do site da companhia aérea. A defesa da Air Canada foi a de que o chatbot era uma entidade legal separada, responsável pelos próprios atos. O tribunal chamou essa alegação de “notável” e a rejeitou. O valor envolvido era irrisório. O princípio não é: seja lá o que o seu agente faça com a autoridade que você concedeu a ele, ele faz isso como se fosse você, e ninguém fora da sua empresa vai se interessar por qual camada da pilha tomou a decisão. Vale o mesmo raciocínio, guardadas as proporções, para quem opera sob a LGPD: a empresa continua sendo a controladora dos dados perante a ANPD, não importa qual camada do sistema apertou o botão. A OWASP classifica isso como agência excessiva, e as mitigações que ela lista são as mesmas coisas mundanas: escopos mínimos e um humano no caminho de qualquer ação com consequência real. As empresas que estão extraindo valor de verdade aqui projetaram esse ponto de checagem humana de propósito, em vez de descobri-lo no meio de um incidente.
Agora, o teste justo para o meu próprio argumento: isso não destrói o valor do agente, ao travar as permissões? Em parte, sim. Um agente sem caminho de escrita economiza menos tempo do que um com acesso à produção, e fingir o contrário é como esses programas são vendidos e depois discretamente engavetados. Coloque a ação irreversível de pior caso por unidade de autoridade concedida de um lado, o ganho de produtividade esperado do outro, e seja honesto: a maioria dos business cases hoje modela o benefício e nenhuma parte da cauda de risco. Onde o pior caso ultrapassa a sua capacidade demonstrada de recuperação, você não está com uma ferramenta de produtividade nas mãos. Está com um passivo não precificado com uma boa demonstração. Sequenciar isso direito é uma decisão de arquitetura antes de ser uma decisão de ferramenta.
Então pare de esperar pelas notas de lançamento do próximo modelo. Uma revisão de permissões e um teste cronometrado de restauração somam umas duas semanas de trabalho pouco glamoroso de plataforma, e nenhum roadmap trava por causa disso, mas elas limitam o seu prejuízo potencial seja lá o que for lançado depois. Reserve essas duas semanas antes de o piloto ganhar as credenciais, porque fazer isso depois costuma acontecer às três da manhã, com alguém do jurídico na chamada.
Perguntas frequentes
Instruções de prompt conseguem impedir um agente de IA de apagar dados?
Não de forma confiável. Instruções influenciam a probabilidade, não removem a capacidade, e o agente já está de posse das credenciais no momento em que as lê. Trate instruções escritas como preferência e as permissões como o controle de verdade: se a única coisa entre um agente e o seu banco de dados de produção é uma frase em português, o banco está, na prática, desprotegido.
Quais credenciais um agente de IA para código nunca deveria ter?
Qualquer coisa capaz de apagar ou sobrescrever um estado que você não consiga restaurar dentro da sua janela de recuperação. Na prática: credenciais de escrita no banco de dados de produção, papéis de console de nuvem com permissão de exclusão sobre armazenamento ou computação, administração de backups e snapshots, acesso de leitura ao gerenciador de segredos além do único segredo necessário para a tarefa, e qualquer conta de serviço compartilhada com outros sistemas. Se o agente precisa de dados de produção, entregue a ele uma cópia restaurada em um ambiente separado, não o acesso direto.
Como testar o raio de impacto de um agente de IA antes de colocá-lo em produção?
Liste as ações destrutivas alcançáveis com a identidade que você planeja conceder, depois tente executar cada uma delas a partir dessa identidade em um ambiente de staging. Tudo que funcionar é algo que o agente pode fazer num dia ruim. Termine cronometrando uma restauração completa a partir do backup com a identidade do agente revogada, porque a sua exposição real é a distância entre o que o agente pode destruir e o que você consegue efetivamente trazer de volta.
Relacionado
- O Oligopólio da Memória Que Está Encarecendo a Corrida da IA
- O Penhasco do Subsídio de IA: A Conta Real da Inferência Chegou
- Seu Ganho de Produtividade com IA Está Sendo Pago por uma Etapa que Ninguém Mede
- AI & Automation
Escrito por uma persona editorial de IA do sistema editorial proprietário da Abyshire e revisto pela nossa equipa.