Resumo Técnico: Segurança do Agente em Ambientes Empresariais Multilocatários

1. Declaração do Problema

O artigo aborda uma lacuna fundamental de segurança na implantação de sistemas de Geração Aumentada por Recuperação (RAG) e de IA agencial em ambientes empresariais. Enquanto tratamentos acadêmicos e APIs voltadas ao consumidor frequentemente assumem acesso a dados de um único locatário e homogêneo, implantações empresariais do mundo real envolvem múltiplos locatários compartilhando infraestrutura com dados heterogêneos, conformidade regulatória rigorosa e requisitos de controle de acesso granular.

O problema central identificado é a lacuna entre relevância e autorização. Sistemas de recuperação existentes (vetoriais, baseados em palavras-chave ou híbridos) otimizam para relevância semântica ou correspondência de palavras-chave, mas carecem de mecanismos nativos para impor políticas de autorização. Consequentemente, uma consulta de um locatário pode recuperar e expor dados confidenciais pertencentes a outro locatário se esses dados obtiverem as maiores pontuações nas métricas de relevância. Essa lacuna é exacerbada em sistemas agentes onde:

• Divulgação mediada por ferramentas ocorre quando agentes invocam ferramentas com credenciais amplas em vez de autorização do usuário final.
• Acúmulo de contexto permite que conversas de múltiplas voltas vazem dados entre locatários sem revalidação de política por volta.
• Orquestração no lado do cliente distribui lógica crítica de segurança para clientes potencialmente não confiáveis, permitindo a burla de verificações de autorização.

Abordagens padrão para isolamento, como replicar toda a pilha agencial (armazenamentos vetoriais, pontos de extremidade de inferência) por locatário, são consideradas proibitivas em termos de custo e operacionalmente fragmentadas.

2. Metodologia e Arquitetura

Os autores propõem uma arquitetura de isolamento em camadas imposta por meio de orquestração no lado do servidor para proteger os caminhos de dados e controle da IA agencial. Essa abordagem é implementada no OGX (Open GenAI Stack), um framework de código aberto e neutro em relação a fornecedores que oferece APIs compatíveis com a OpenAI.

2.1 Isolamento em Camadas (Caminho de Dados)

A arquitetura protege o fluxo de dados através de três camadas distintas dentro do limite de confiança do servidor:

1. Ingestão Consciente de Política: Metadados do locatário (propriedade, atributos) são anexados aos documentos no momento da ingestão. Isso garante que cada fragmento de documento herde atributos de locatário consistentes, prevenindo acoplamento acidental entre locatários.
2. Filtragem na Recuperação: Um mecanismo de imposição de dois níveis é aplicado:
   • Pré-busca: A autorização baseada em atributos (ABAC) é avaliada antes do início da busca.
   • Pós-recuperação: Filtragem ao nível de fragmento é aplicada após a recuperação.
   • O sistema suporta empurrão de predicado (onde o backend vetorial aplica filtros nativamente durante a busca) para manter o recall perfeito em escala. Se o empurrão não estiver disponível, a filtragem pós-recuperação garante segurança (zero vazamento), mas pode degradar o recall em grandes corpora.
3. Inferência Compartilhada: A camada de inferência do Modelo de Linguagem de Grande Escala (LLM) é compartilhada entre todos os locatários. Como as Camadas 1 e 2 garantem que apenas documentos autorizados entrem no contexto do prompt, o próprio modelo não requer isolamento por locatário, reduzindo os custos de infraestrutura de $O(N \cdot M)$ para $O(M)$.

2.2 Orquestração no Lado do Servidor (Caminho de Controle)

Para abordar os riscos de burla no lado do cliente, os autores defendem a orquestração no lado do servidor do loop de inferência $\to$ ferramenta $\to$ inferência.

• Limite de Confiança: Todas as operações críticas de segurança (autorização de execução de ferramenta, isolamento de estado, imposição de política) são centralizadas dentro do processo do servidor.
• Compensações: Embora isso introduza latência para chamadas de ferramentas em comparação com a execução local, impede que clientes comprometidos pulem filtros ou manipulem invocações de ferramentas.
• Abordagem Híbrida: A arquitetura permite que frameworks no lado do cliente mantenham o controle sobre a composição do agente e operações sensíveis à latência, enquanto o servidor impõe invariantes de segurança.

3. Contribuições Principais

O artigo faz quatro contribuições principais:

1. Formalização da Lacuna entre Relevância e Autorização: Os autores definem matematicamente por que a classificação por relevância sozinha é insuficiente para isolamento e fornecem evidências empíricas de que a recuperação sem filtragem vaza dados entre locatários em 98–100% das sondagens.
2. Arquitetura de Isolamento em Camadas: Um design proposto que combina ingestão consciente de política, filtragem no momento da recuperação e inferência compartilhada, com orquestração no lado do servidor como camada de imposição.
3. Validação Empírica: Uma avaliação de seis experimentos medindo segurança (vazamento, resiliência a injeção de prompt), desempenho de sistemas (latência, vazão) e qualidade de recuperação em uma matriz $2 \times 2$ de modos de orquestração (cliente vs. servidor) e filtragem de recuperação (sem filtragem vs. filtragem ABAC).
4. Implementação de Código Aberto: A arquitetura é implementada no OGX, um framework neutro em relação a fornecedores que oferece APIs compatíveis com a OpenAI (incluindo uma API de Respostas para orquestração de múltiplas voltas) e um Operador Kubernetes para implantação.

4. Resultados Experimentais

A avaliação utilizou um ambiente de teste sintético com três locatários (finanças, engenharia, jurídico) e 300 documentos.

• Segurança (Vazamento entre Locatários):

  • Configurações Sem Filtragem: Independentemente do modo de orquestração, a recuperação sem filtragem resultou em 98–100% de vazamento de dados entre locatários.
  • Configurações com Filtragem: A filtragem ABAC eliminou completamente o vazamento entre locatários (0% de vazamento), alcançando o objetivo de segurança (G1).
  • Injeção de Prompt: Sob configurações com filtragem, todas as 90 sondagens de injeção de prompt foram bloqueadas (0% de vazamento). Em configurações sem filtragem, 62–80% das sondagens recuperaram com sucesso dados não autorizados.
  • Imposição: O estudo destaca que, embora a filtragem no lado do cliente (Configuração B) possa alcançar 0% de vazamento, ela depende da integridade do cliente. A orquestração no lado do servidor (Configuração D) fornece a garantia de imposição necessária (G2) ao mover a lógica para dentro do limite de confiança.

• Desempenho:

  • Latência: A filtragem de recuperação adicionou aproximadamente 19ms ao caminho de busca (ida e volta de autenticação + avaliação de política + consulta), o que é negligenciável em comparação com os tempos de inferência (segundos). A orquestração no lado do servidor adicionou ~3s de latência total devido às idas e voltas, mas suporta streaming para reduzir o tempo até o primeiro token.
  • Vazão: A filtragem não degradou a vazão. A vazão escalou linearmente com a concorrência. A orquestração no lado do cliente alcançou ~2x a QPS da orquestração no lado do servidor em alta concorrência devido a caminhos de solicitação mais curtos.

• Qualidade de Recuperação:

  • A filtragem ao nível de fragmento melhorou a Precisão@5 em 2,2x (de 0,200 para 0,433) ao filtrar ruído entre locatários.
  • Empurrão de Predicado: Backends que suportam empurrão de predicado mantiveram Recall@5 = 1,0 em todos os tamanhos de corpus. Backends sem empurrão (usando filtragem pós-recuperação) viram o recall degradar significativamente (de 1,0 para 0,002) à medida que o tamanho do corpus aumentava para 50 mil fragmentos, embora as garantias de segurança permanecessem intactas.

5. Significância e Escopo

O artigo afirma que este trabalho é o primeiro a abordar a interseção entre design padronizado de API agencial, orquestração no lado do servidor e isolamento multilocatário em infraestrutura compartilhada.

• Significância: A arquitetura demonstra que multilocatário seguro, APIs neutras em relação a fornecedores compatíveis com a OpenAI e capacidades de agentes autônomos podem ser alcançadas simultaneamente sem duplicação de infraestrutura por locatário. Ela desloca o paradigma de segurança de recuperação "baseada em relevância" para "baseada em política".
• Escopo e Limitações:
  • A solução é projetada para ambientes empresariais multilocatários; é desnecessária para implantações de locatário único ou dados públicos.
  • A arquitetura protege a construção de contexto, mas não a memória paramétrica; os modelos ainda podem gerar informações absorvidas durante o pré-treinamento.
  • O limite de confiança é o processo do servidor; a arquitetura não protege contra processos de servidor comprometidos, operadores internos ou ataques de canal lateral.
  • Ferramentas de função no lado do cliente permanecem fora do limite de confiança do servidor, embora o OGX mitigue isso por meio de classificação explícita de ferramentas.

Os autores concluem que, embora a orquestração no lado do cliente ofereça menor latência para ambientes confiáveis, a orquestração no lado do servidor com filtragem ABAC é essencial para cenários empresariais que exigem isolamento rigoroso e conformidade.