--- title: "A busca não pode ampliar o acesso" slug: "a-busca-nao-pode-ampliar-o-acesso" date: "2026-10-23" publishedAt: "2026-10-23T09:51:00-03:00" author: "Rodrigo Jorge" summary: "Copiar um documento para o índice de um agente também exige preservar quem pode lê-lo. Relevância não substitui autorização, nem mesmo quando a resposta é só um resumo." origem: "Análise" status: "published" --- **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](/assets/artigos/a-busca-nao-pode-ampliar-o-acesso-pt.svg). 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](https://learn.microsoft.com/en-us/azure/search/search-security-trimming-for-azure-search), consultado em 23 de outubro de 2026. - [Microsoft: Query-time ACL and RBAC enforcement in Azure AI Search (preview)](https://learn.microsoft.com/en-us/azure/search/search-query-access-control-rbac-enforcement), consultado em 23 de outubro de 2026. Limites e atualização de permissões conforme a ingestão.