Authorization em aplicações com LLM

• Modelos de linguagem de grande porte (LLMs) são sistemas imprevisíveis porque processam entradas incertas de usuários humanos, portanto a aplicação do princípio do menor privilégio (least privilege) é essencial
• À medida que os LLMs passam a ser usados na prática em várias tarefas, como busca interna e automação, é necessário que operem apenas com “permissões efetivas (effective permissions)” mínimas para evitar incidentes de segurança e uso indevido
• Em uma arquitetura RAG (Retrieval-Augmented Generation), embeddings de dados e verificações de permissão devem ser separados das fontes de dados, exigindo controle de autorização granular no nível de recurso
• Quanto mais aumentam os usos complexos com dados externos (3rd party)/RAG, Agents, MCP etc., mais o local e a forma reais de aplicação das permissões emergem como questão central de segurança
• Autenticação baseada em tokens, como OAuth, tem limitações para controle fino de permissões por recurso, então a lógica real de autorização precisa ser implementada diretamente na camada da aplicação

---

Termos e conceitos básicos

• Prompt: solicitação do usuário enviada ao LLM (comando, pergunta etc.)
• RAG (Retrieval-Augmented Generation): workflow que anexa dados adicionais ao prompt para aumentar a precisão da resposta do LLM (ex.: anexar automaticamente a lista de férias da empresa)
• Context: dados auxiliares anexados ao prompt (materiais relacionados recuperados etc.)
• Embedding: representação vetorial numérica de texto, usada para busca/correspondência de dados
• Agent: motor de execução baseado em LLM que realiza ações de acordo com o prompt (como chamada automática de ferramentas)
• Tool: funcionalidade externa, como API/aplicação, que o LLM pode chamar diretamente
• Model Context Protocol (MCP): protocolo padrão proposto pela Anthropic para acesso de LLMs a ferramentas

Princípio central do modelo de autorização para LLMs

• Golden Rule:
  > O LLM deve operar apenas com os privilégios mínimos estritamente necessários para processar a solicitação do usuário
• Para usuários humanos, um certo “excesso de privilégios por convenção” pode ser tolerado, mas LLMs são imprevisíveis, rápidos e podem causar danos em larga escala quando erram.
  → As “permissões efetivas” do LLM devem ficar limitadas à interseção entre as permissões do usuário, do LLM e da tarefa

Cálculo das permissões efetivas

• Permissões efetivas de uma aplicação com LLM =
  1. permissões que o LLM possui
  2. permissões que o usuário possui
  3. permissões necessárias para a tarefa solicitada
     A interseção desses três elementos
• O usuário “delega (impersonation)” seu papel ao LLM (como um chatbot),
  mas ele não deve ultrapassar nem o escopo de permissões do LLM nem o do próprio usuário
• Explicação intuitiva com um diagrama de Venn de permissões
  • A execução só é permitida quando as permissões da tarefa estão totalmente contidas na interseção

RAG (Retrieval-Augmented Generation) e tratamento de permissões

1. RAG com dados 1st Party (próprios)

• Exemplo: um chatbot interno que encontra, no código-fonte da empresa, “arquivos que contêm chaves secretas”
• Embedding: todos os arquivos são convertidos em vetores e armazenados em um banco de dados; o prompt também é convertido em vetor para matching por similaridade
• Onde aplicar as permissões:
  • Verificar imediatamente a organização proprietária real, o tipo, o repositório e as permissões do usuário para o “arquivo” retornado no resultado da busca
  • Verificar se o usuário pode acessar esse arquivo (permissões no nível de recurso)
  • Fazer a verificação de autorização na camada da aplicação no processo de ligação entre embedding e dados de origem
• Colocar a lógica de autorização dentro do próprio LLM é instável (não há garantia devido à sua natureza probabilística)
• Resumo:
  • O ponto central do RAG é aplicar fortemente permissões por usuário e por recurso após conectar embeddings e dados originais

2. RAG com dados 3rd Party (externos)

• Uso de embeddings de dados de APIs/sistemas externos (ex.: wiki, sistema de tickets etc.)
• Problema: embeddings e dados originais ficam em sistemas diferentes → o local de aplicação das permissões se torna ambíguo
• Três formas de tratar permissões
  1. Delegar a autorização ao sistema externo (verificar a permissão real a cada chamada de API, com problemas de resposta lenta e rate limit)
  2. Sincronizar a ACL (lista de controle de acesso) na aplicação (alta precisão/confiabilidade, mas maior custo de gestão/sincronização da ACL)
  3. Reimplementar internamente a própria lógica de autorização externa (maior carga de gestão/sincronização e maior complexidade lógica)
• Conclusão: dependendo da situação real, o trade-off entre “onde aplicar a autorização” e como fazê-lo é importante
  (é preciso escolher entre desempenho e simplicidade, custo de gestão e precisão etc.)

LLMs baseados em agentes (AI Agent) e permissões

• Exemplo: chatbot realizando tarefas automáticas de manutenção, como excluir branches de repositório ou fechar issues
• Com MCP (Model Context Protocol), tools (funções/APIs) são expostas ao LLM de forma padronizada
• Em cada requisição do MCP, é preciso aplicar o modelo de permissões efetivas
  (interseção entre permissões do usuário, do agent e da tarefa)
• Limitações da autenticação baseada em tokens, como OAuth
  • As informações de permissão ficam incluídas no token, mas não cobrem permissões em tempo real no nível de ativo/recurso
  • Na prática, apenas parte das informações vai no token, e o restante exige implementação separada de lógica de autorização na camada da aplicação

Conclusão e resumo prático

• Em ambientes de LLM/RAG/Agent, o ponto central da gestão de autorizações é definir onde e como as permissões serão aplicadas

• Por meio do modelo de permissões efetivas, o LLM deve ser restringido a operar apenas dentro da interseção entre “usuário + LLM + tarefa”

• Tokens de autenticação, como OAuth, devem ser usados apenas para identificar “quem fez a solicitação”,
  e a verificação real de permissões por recurso deve obrigatoriamente ser feita na aplicação

• Ao integrar sistemas externos,
  é necessário projetar considerando vários trade-offs, como 1) delegar a autorização (queda de desempenho), 2) sincronizar ACL (complexidade operacional), 3) reimplementar a lógica de autorização (alta manutenção)

• Resumo final:
  > O LLM deve operar apenas dentro dos privilégios mínimos estritamente necessários para processar a solicitação do usuário,
  > e as permissões efetivas (effective permissions) são definidas como a interseção entre as permissões do LLM, do usuário e da tarefa
  > A verificação real de permissões deve obrigatoriamente ser realizada por recurso, na camada da aplicação