Rodrigo Jorge · Preparado em 23 de outubro de 2026, às 09:51 (horário de Brasília, UTC-3). Horário de publicação a confirmar.
Uma pessoa pergunta ao assistente interno por que um cliente encerrou o contrato. A busca encontra um relatório restrito à diretoria. O assistente responde com um resumo, sem link para o arquivo.
Nesse cenário hipotético, ocultar a referência não impede a exposição. O conteúdo já atravessou a fronteira de acesso.
Como CISO, eu começaria pela consulta que alimentou a resposta: ela foi executada com a autorização de quem? A conta que pode indexar todos os documentos não define o que cada usuário pode receber. Se a integração usa essa conta para recuperar qualquer trecho e pede ao modelo para esconder os proibidos, a seleção de conteúdo já depende de uma instrução ao modelo.
RAG, a geração apoiada em conteúdo recuperado, precisa carregar as permissões junto com o conteúdo. A relevância de um trecho responde se ele ajuda na pergunta. Não responde se aquela pessoa tem direito a recebê-lo.
O filtro não autentica ninguém
A documentação do Azure AI Search descreve um padrão de security filters que inclui ou exclui documentos comparando identificadores de usuários ou grupos. A própria Microsoft ressalta: nesse padrão, o identificador é uma string usada no filtro, não uma autenticação ou autorização feita por ele. O filtro precisa ser aplicado em cada consulta.
Para uma integração que adote esse padrão, minha proposta é derivar a identidade e os grupos de um contexto autenticado, montar a restrição no serviço e impedir que o usuário ou o modelo a substituam por parâmetros livres. O conteúdo não autorizado deve ficar fora do contexto enviado ao modelo. Isso é uma proposta de arquitetura a verificar, não uma garantia dada pelo nome do produto.
Há ainda a cópia das permissões. A Microsoft documenta, em seu recurso de controle de acesso na consulta atualmente marcado como preview, que a atualização das ACLs depende do método de ingestão. Alterar a permissão na origem não implica que todo índice já reflita a mudança. Essa observação não é uma recomendação de adoção do recurso em preview.
Uma equipe precisa saber o que acontece com trechos já indexados, caches e histórico da conversa quando o acesso muda. Um novo filtro na busca não apaga uma resposta entregue anteriormente.
Ver o diagrama: autorização antes do contexto do modelo. Fluxo proposto, sem métricas ou dados de incidente.
Eu avaliaria essa integração com dois usuários de laboratório e documentos sintéticos. Um pode ler o documento; o outro, não. A pergunta é a mesma. A evidência deve mostrar quais trechos foram recuperados para cada identidade, além da resposta final. Depois, retirar o acesso do primeiro usuário e repetir o teste pelo caminho de atualização previsto.
A ausência do segredo no texto final não basta se o trecho proibido entrou no contexto. Também não basta testar apenas a consulta principal: se há atalhos por título, citações ou export, eles precisam respeitar a mesma autorização.
O critério para liberar esse fluxo é demonstrar que a busca preserva a fronteira de leitura para cada identidade e que existe um tratamento definido para mudanças de permissão. Se a integração não sabe de quem é o acesso, ainda não sabe quais documentos pode entregar.
Referências
- Microsoft: Security filters for trimming results in Azure AI Search, consultado em 23 de outubro de 2026.
- Microsoft: Query-time ACL and RBAC enforcement in Azure AI Search (preview), consultado em 23 de outubro de 2026. Limites e atualização de permissões conforme a ingestão.