Ferramentas com Privilégio Mínimo
Dê ao agente o conjunto de ferramentas mais estreito, e a cada ferramenta o escopo mais estreito, que a tarefa realmente exige. O padrão assume que a injeção de prompts às vezes terá êxito e limita o que um agente sequestrado pode fazer: você não consegue corrigir o modelo, mas consegue decidir o que ele é capaz de alcançar.
Definição
Ferramentas com privilégio mínimo são a prática de restringir o catálogo de ferramentas de um agente, e a credencial por trás de cada uma, ao mínimo que a tarefa exige — de modo que as consequências de um ataque bem-sucedido ou de um erro do modelo fiquem limitadas por design, e não pela obediência do modelo.
Problema
Um agente com ferramentas amplas e credenciais amplas transforma qualquer injeção, jailbreak ou alucinação bem-sucedida em uma ação real com todo o alcance da conta por trás dela.
Quando usar
Use onde um agente puder agir: chamar APIs, escrever arquivos, enviar mensagens, movimentar dinheiro. Quanto mais autonomia e menos revisão humana, mais o raio de impacto precisa ser definido na camada de permissões e não no prompt.
Solução
Parta da tarefa, não da plataforma. Liste as operações que o agente precisa executar e exponha exatamente essas. Um catálogo montado a partir de «o que a API oferece» é uma concessão de permissões que ninguém revisou.
Separe leitura de escrita: ferramentas distintas, credenciais distintas e nenhum caminho de escrita alcançável por um argumento de uma ferramenta de leitura. Endpoints de «consulta» que também mutam são a escalada silenciosa mais comum.
Restrinja a credencial, não apenas a ferramenta. Uma ferramenta somente leitura apoiada por um token de administrador está a um bug de virar ferramenta de escrita; emita credenciais por ferramenta com o escopo mais estreito que o sistema a montante suporte.
Limite os parâmetros. Coloque em lista de permitidos os caminhos, repositórios, tabelas, contas ou destinatários que uma ferramenta pode endereçar, para que um agente sequestrado não consiga reapontar uma ferramenta legítima para um alvo ilegítimo.
Faça as concessões expirarem e serem revisadas. Ferramentas se acumulam; remova o que ninguém invoca e trate adicionar uma ferramenta como a mudança de permissão que ela é.
Registre a concessão e a chamada separadamente. O que o agente podia fazer e o que ele fez são duas auditorias diferentes, e um incidente precisa das duas.
Componentes
Benefícios
- Limita o dano de uma injeção bem-sucedida sem depender de o modelo se comportar.
- Transforma «este agente é seguro?» em um artefato revisável: uma lista de ferramentas, escopos e responsáveis.
- Melhora de tabela a precisão na escolha de ferramenta: menos ferramentas e mais nítidas são mais fáceis de distinguir para um modelo.
- Torna incidentes investigáveis, porque o conjunto alcançável já era conhecido antes do incidente.
Riscos
- Ampliação por conveniência: um token amplo colado durante uma depuração e nunca estreitado depois.
- Fragmentação: dezenas de ferramentas finíssimas que o modelo não distingue, trocando um ganho de segurança por uma perda de confiabilidade.
- Falsa tranquilidade. O privilégio mínimo limita consequências; não evita o ataque, e nada diz sobre exfiltração por uma ferramenta de leitura legitimamente concedida.
- Atrito de processo: se emitir uma credencial restrita custa mais do que reutilizar uma ampla, o processo vira a vulnerabilidade.
Quando não usar
- Protótipos sobre dados sintéticos sem alcance à produção, onde a cerimônia custa mais do que o risco que elimina.
- Quando a plataforma a montante não sabe expressar escopos: aí o controle se muda para um proxy à frente, em vez de ser dado por satisfeito.
- Quando estreitar o agente empurraria o trabalho para uma via humana pior limitada e pior auditada.
Tecnologias
Exemplos
- Um agente de programação com um token de repositório restrito a um repositório e a um prefixo de branch, sem leitura no nível da organização. Uma injeção pelo README de uma dependência ainda pode abrir um branch; não alcança os outros quarenta repositórios.
- Um agente de suporte com as ferramentas de CRM separadas: read_customer com uma chave somente leitura e update_ticket restrita aos chamados já presentes na conversa. Uma sessão sequestrada pode incomodar um chamado, não exportar a base de clientes.
- Um servidor MCP público cujo catálogo inteiro são getters sobre conteúdo já publicado, apoiado por nenhuma credencial: não há o que revogar porque não há o que vazar.
Evidência de produção
- Contexto
- O endpoint MCP público desta base de conhecimento, acessível a qualquer agente na internet.
- Cenário
- O corpus é público e somente leitura, então o catálogo é inteiramente de getters. Não há ferramenta que escreva, nenhuma que alcance dados que o site já não publique e nenhuma credencial alcançável a partir de uma ferramenta.
- Tecnologia
- JSON-RPC sem estado sobre HTTP em um route handler do Next.js, lista de origens permitidas verificada antes de qualquer handler rodar, limite de taxa por chamador em Redis e log de auditoria estruturado por chamada.
- Carga
- Tráfego contínuo e não assistido de agentes desde o lançamento, mais rastreadores de registries e verificações de saúde de diretórios.
- Resultados
- Um cliente deste servidor sequestrado por injeção de prompts não obtém nada que não pudesse ter baixado do site público, porque o conjunto alcançável é exatamente o corpus publicado. Não há credencial a revogar nem caminho de escrita a abusar.
KPIs
- Ferramentas por agente
- O tamanho do catálogo. Crescer sem remover é o sinal de que as concessões se acumulam sem revisão.
- Percentual de ferramentas com escrita
- Quanto do catálogo pode alterar estado. O número que vale a pena levar ao mínimo que a tarefa permitir.
- Idade da ferramenta sem uso mais antiga
- Dias desde a última invocação de uma ferramenta concedida. Uma concessão antiga sem uso é alcance que ninguém precisa e que um atacante herda.
- Cobertura de escopo documentado
- Percentual de ferramentas com escopo escrito e responsável nomeado. Uma ferramenta sem documentação é uma ferramenta sem limite.
Modos de falha observados
- O token de administrador atrás da ferramenta somente leitura: escopo declarado na camada de ferramenta, ilimitado na camada de credencial.
- Reapontamento de parâmetros: a ferramenta é legítima e o alvo não é, porque nada restringiu o argumento.
- Deputado confuso: estreitar as ferramentas sem estreitar sob qual autoridade elas rodam não muda nada, porque quem chama continua herdando o alcance do agente.
- Deriva do catálogo: as ferramentas adicionadas para um experimento ficam, e o conjunto de permissões revisado já não é o implantado.
Lições aprendidas
- Escreva o raio de impacto antes de conceder a ferramenta, não depois do incidente.
- O nome de uma ferramenta não é o escopo dela. Só a credencial do lado servidor é.
- Remover uma ferramenta que ninguém chama é o trabalho de segurança mais barato que existe.
- O privilégio mínimo paga duas vezes: limita ataques e faz o agente escolher melhor as ferramentas.
FAQs
- O privilégio mínimo impede a injeção de prompts?
- Não, e não é essa a intenção. Ele assume que a injeção às vezes vai funcionar e decide de antemão o que um ataque bem-sucedido consegue realizar. Prevenir e conter são trabalhos diferentes, e só conter está sob o seu controle.
- Quão estreito é estreito demais?
- Quando o modelo já não distingue duas ferramentas, ou quando uma tarefa rotineira precisa de quatro chamadas que poderiam com segurança ter sido uma. Dividir melhora até começar a produzir escolhas erradas, e uma chamada errada é uma falha por si só.
- Usamos uma única conta de serviço para tudo. É tão ruim assim?
- Significa que cada agente, e cada atacante que alcançar um deles, tem o alcance da tarefa mais ampla que qualquer um deles executa. Uma única conta é a versão deste padrão em que o raio de impacto é «tudo».