Falha em retrieval do Azure OpenAI expõe conteúdo que usuário não podia abrir

O que aconteceu

Egiziago Cioffi, arquiteto de TI e CEO da SynSphere Italia, empresa de Milão parceira da Microsoft, construiu um agente de email com Azure OpenAI. O assistente resolve automaticamente cerca de 60% dos emails de clientes recebidos, disse Cioffi ao VentureBeat em respostas por escrito.

Antes de colocar em produção, a equipe rodou testes de unidade e avaliações de qualidade. Todos passaram. Nenhum dos testes fez a pergunta que importava: o que acontece quando um usuário com permissão baixa faz a mesma pergunta que um usuário com permissão alta?

Cioffi fez esse teste. Ele rodou uma conta de privilégio baixo com as mesmas perguntas que uma conta de privilégio alto já havia feito ao assistente. As respostas não bateram. O assistente retornou conteúdo do SharePoint que o usuário solicitante não poderia abrir diretamente no SharePoint. Os logs de retrieval mostraram uma história diferente dos resultados das avaliações.

Contexto

O problema não é isolado. A Azure AI Search tem recursos nativos para controlar acesso por documento, como o document-level ACL trimming com tokens do Entra, em preview desde maio de 2025, segundo a documentação da Microsoft. O sincronismo de ACLs do SharePoint veio depois, em uma preview seguinte. A capacidade existe, mas não cobre todos os caminhos de implantação de agentes.

O preview atual de ACL do SharePoint, via API 2026-05-01-preview, consegue ingerir metadados de grupos de site com o prefixo spg. Porém, só princípios baseados em Entra são documentados como confiavelmente aplicados no momento da consulta. O preview funciona por REST API e SDKs de preview, e não abrange todos os caminhos de deploy. O Azure OpenAI On Your Data, por exemplo, suporta acesso por documento via filtros de segurança da Azure AI Search, mas a documentação da própria Microsoft indica limitações.

Cioffi percebeu que a causa raiz estava no pipeline de indexação. O indexador, que conectava o SharePoint à Azure AI Search, usava credenciais com permissões amplas. Quando o agente fazia a consulta, a resposta era filtrada pelas permissões do índice, não pelas do usuário final. Por isso as avaliações passavam: os testes usavam contas com acesso total.

Por que importa

Essa falha de retrieval em sistemas de RAG (retrieval-augmented generation) tem implicação direta de segurança. Uma empresa que implementa um assistente de IA generativa ligado a SharePoint, OneDrive ou bancos internos pode, sem saber, expor informações restritas a funcionários sem permissão. O custo não é só reputacional. Pode ser uma violação de LGPD no Brasil ou de GDPR na Europa, com multas que chegam a 4% do faturamento global.

Para empresas brasileiras que adotam Azure OpenAI e serviços da Microsoft, o alerta é prático: testar com contas de privilégio baixo é obrigatório antes de colocar um agente em produção. As avaliações tradicionais, que medem acurácia da resposta, não capturam vazamento de permissões.

Impacto

Cioffi resolveu o problema sem trocar a plataforma de identidade. Ele aplicou um filtro adicional na camada de retrieval e tornou o assistente mais restrito, com um escopo menor de dados. A solução foi simples, segundo ele, mas exigiu entender onde o filtro de permissões deveria ser aplicado.

No curto prazo, outros desenvolvedores de agentes na plataforma Azure precisam revisar seus pipelines. A Microsoft já oferece ferramentas, mas elas não funcionam em todos os cenários de deploy. Quem usa On Your Data com Azure AI Search precisa verificar se os filtros de segurança estão ativos e se cobrem o path específico do agente.

No médio prazo, a discussão aponta para a necessidade de padronizar o controle de acesso em RAG. Os logs de retrieval são a fonte de verdade, não as avaliações de qualidade. A falha de Cioffi não é um caso raro. Dados independentes mostram que muitos deployments de RAG em produção respondem com as permissões do indexador, não as do solicitante.

O que muda

Para quem desenvolve agentes com Azure OpenAI, a mudança é imediata: adicionar um filtro de ACL por usuário no momento da consulta, mesmo que o índice tenha permissões amplas. Também é preciso reduzir o escopo do assistente, limitando quais documentos ele pode buscar.

A Microsoft deve ampliar a cobertura do preview de ACL do SharePoint para todos os caminhos de implantação. Até lá, fica sob responsabilidade do desenvolvedor garantir que o agente não vaze conteúdo.

O que vem agora

A Microsoft continua expandindo os recursos de document-level access na Azure AI Search. A expectativa é que o suporte a ACLs do SharePoint deixe o preview e cubra todas as formas de integração. Até lá, empresas como a SynSphere Italia adotam soluções próprias.

Cioffi não revelou se a Microsoft foi notificada do caso, mas o relato dele indica que o problema é conhecido na comunidade. Para quem usa Azure OpenAI On Your Data, a recomendação é testar com contas de baixo privilégio em todas as perguntas críticas antes de liberar o agente para o time.