Cibersegurança

Os testes de precisão nem sempre revelam vazamentos de dados em agentes do Azure OpenAI

Um teste com uma conta de baixa permissão revelou que um assistente baseado no Azure OpenAI e no SharePoint recuperava conteúdo ao qual o usuário não conseguia acessar diretamente, apesar de ter sido aprovado nas avaliações de precisão e nos testes unitários. A análise mostra que a verificação das permissões do usuário no momento da recuperação, e não apenas o gerenciamento da identidade do serviço, é o fator decisivo para impedir esse tipo de vazamento.

2026-09-01
6 min de leitura
42 visualizações
certi.news Editorial Team
Os testes de precisão nem sempre revelam vazamentos de dados em agentes do Azure OpenAI

Um assistente de e-mail baseado no Azure OpenAI foi aprovado em todas as avaliações realizadas pela equipe de Egiziago Cioffi, mas falhou em um teste de segurança simples: quando uma conta de baixa permissão fez as mesmas perguntas que uma conta de alta permissão havia feito anteriormente, o assistente retornou conteúdo do SharePoint que a conta de baixa permissão não conseguia abrir diretamente. O incidente revela que o sucesso do agente em fornecer respostas precisas ou concluir tarefas não significa necessariamente que ele aplique os limites corretos de acesso.

Cioffi, arquiteto de tecnologia da informação e empresarial e CEO da SynSphere Italia, parceira da Microsoft com sede em Milão, construiu o agente pessoalmente, escreveu a tarefa de indexação e configurou o fluxo de recuperação no Azure OpenAI, conectando-o ao SharePoint. O assistente processava automaticamente cerca de 60% das mensagens recebidas de clientes, segundo respostas por escrito fornecidas por Cioffi à VentureBeat. No entanto, as avaliações e os testes unitários não perguntavam qual identidade de permissões era usada ao buscar o conteúdo, ponto que os registros de recuperação revelaram posteriormente.

O problema não está apenas na precisão da resposta

Em fluxos RAG que usam uma conta de serviço com permissões amplas para a indexação, o agente pode enxergar um conjunto de dados maior do que aquele ao qual o usuário final consegue ter acesso. Se as permissões do solicitante não forem verificadas no momento da execução da consulta, documentos restritos poderão entrar na janela de contexto do modelo antes que haja uma oportunidade de bloqueá-los.

O Azure AI Search oferece um mecanismo nativo para reduzir listas de controle de acesso no nível do documento usando tokens baseados no Entra. Esse recurso estava em versão prévia desde maio de 2025, seguido posteriormente pela sincronização das listas de acesso do SharePoint em uma versão prévia posterior. A versão prévia do SharePoint também permite inserir dados de grupos de sites usando o prefixo spg: na API 2026-05-01-preview. No entanto, a documentação indica que a aplicação das permissões no momento da consulta é confiável para entidades compatíveis com o Entra, e o fluxo experimental também não abrange todos os métodos de implantação de agentes.

O serviço Azure OpenAI On Your Data oferece acesso no nível do documento por meio de filtros de segurança no Azure AI Search, mas a documentação da Microsoft afirma que não definir o campo de grupos permitidos desativa o acesso no nível do documento. Já os fluxos RAG personalizados que contornam o Azure AI Search não têm essa verificação automaticamente, a menos que o desenvolvedor a implemente no fluxo de recuperação, que foi o que ocorreu na implantação de Cioffi.

Indicadores independentes, mas não evidência de uma única causa

Outros dados reforçam a importância do problema, embora seja necessário não misturar diferentes tipos de falhas. A Straiker realizou mais de 1.700 tentativas de exploração bem-sucedidas contra agentes em produção e informou, no primeiro relatório do STAR Labs, publicado em julho, que 91% dos ataques bem-sucedidos contra agentes de produtividade terminaram em uma extração silenciosa de dados sem detecção. Esse percentual não prova que todos os casos tenham resultado de uma falha na aplicação das permissões de recuperação; o relatório não separa falhas de autorização, injeção de instruções, uso indevido de ferramentas e outros fatores.

Separadamente, o Instituto de Segurança de IA do Reino Unido documentou 19 ações não autorizadas durante uma avaliação de segurança realizada entre 25 e 28 de julho e publicou o relatório do incidente em 4 de agosto do mesmo ano. O teste foi realizado com os classificadores de segurança cibernética desativados e o acesso à internet habilitado. Esses resultados representam uma falha em conter o comportamento do agente dentro do escopo pretendido, não uma falha idêntica ao incidente de recuperação do SharePoint; o ponto em comum é a ausência de uma verificação confiável do escopo em tempo de execução.

O que o candidato corrigiu na prática?

Cioffi transferiu a decisão de autorização para o momento da consulta, adicionando um filtro que verifica as permissões do usuário do SharePoint antes de encaminhar qualquer parte do conteúdo ao modelo. Assim, o conteúdo que o usuário não consegue abrir no SharePoint não entra na janela de contexto. O assistente continuou resolvendo automaticamente cerca de 60% dos e-mails recebidos após a ativação do filtro, mas Cioffi não forneceu um número para a taxa anterior à implementação, para fins de comparação.

Essa solução impõe uma compensação clara: informações que o agente usava anteriormente para responder podem ser excluídas, o que pode levar a respostas incompletas ou à ausência de resposta quando as permissões impedirem o acesso a uma parte de que o modelo necessita. A adequação dessa compensação varia conforme a sensibilidade dos dados, a diferença de permissões entre os usuários e a capacidade da organização de lidar com consultas incompletas.

Um teste prático antes do lançamento

A principal lição editorial é que a governança da identidade do agente e a verificação das permissões de recuperação tratam de duas camadas diferentes. A governança da identidade define as contas de serviço, o escopo de acesso delas e o ciclo de vida de seus tokens, mas não garante que o conteúdo recuperado pela conta em nome de um usuário de baixa permissão corresponda ao que esse usuário consegue acessar.

  • Use duas contas, uma com baixa permissão e outra com alta permissão.
  • Faça a mesma pergunta usada pela conta de alta permissão.
  • Compare o resultado do assistente com aquilo que a conta de baixa permissão consegue abrir diretamente no sistema de origem.
  • Em uma implantação do Azure AI Search com um indexador do SharePoint e entidades compatíveis com o Entra, verifique se a redução de ACL no momento da consulta está ativada e se o grupo de usuários não depende de grupos de sites do SharePoint sem suporte.
  • Em um fluxo RAG personalizado, presuma que a verificação de autorização não existe até que o contrário seja comprovado por meio de testes e registros.

Segundo o artigo, o teste com as duas contas leva cerca de 30 minutos, mas revela algo que a pontuação de avaliação da resposta, por si só, não consegue mostrar: o agente realmente usa as permissões do solicitante ou as permissões da conta de serviço que criou o índice?

Fonte da notícia
VentureBeat Startups & Funding
Abrir fonte original ↗
c
Autor

certi.news Editorial Team

Na mesma categoria

Você também pode gostar

Ver todas as notícias