.webp){kind=small}
Egiziago Cioffi é o Arquiteto de TI e Empresarial e CEO da SynSphere. Italia, uma parceira da Microsoft com sede em Milão. Ele mesmo criou um agente. Escreveu o trabalho de indexação, configurou o pipeline de recuperação do Azure OpenAI, conectou-o ao SharePoint e viu-o passar em todas as avaliações realizadas por sua equipe.
Seu assistente de e-mail Azure OpenAI resolve automaticamente cerca de 60% dos e-mails recebidos de clientes, disse Cioffi ao VentureBeat em respostas escritas às nossas perguntas de entrevista. As pontuações da avaliação foram excelentes e os testes unitários foram aprovados. Nenhum deles fez a pergunta que importava.
Cioffi executou uma conta com privilégios baixos respondendo às mesmas perguntas que uma conta com privilégios elevados já havia feito ao assistente. Os resultados não coincidiram. O assistente retornou conteúdo do SharePoint que o usuário solicitante não poderia ter aberto no SharePoint por conta própria. Os registros contavam uma história diferente das pontuações da avaliação.
Os registros de recuperação são a evidência dessa falha específica de produção. O que se segue são dados independentes que mostram que a classe de falha não é isolada.
O Azure AI Search oferece o recurso nativo de filtragem de ACL em nível de documento por meio de tokens baseados em Entra desde a versão prévia em maio de 2025, e a sincronização de ACL do SharePoint foi implementada em uma versão prévia posterior. O recurso existe; no entanto, não está disponível em todos os lugares onde é necessário.
A versão prévia do ACL do SharePoint agora pode ingerir metadados de grupos de sites por meio do prefixo spg: na API 2026-05-01-preview. No entanto, apenas as entidades de segurança com suporte. Entra são documentadas como sendo aplicadas de forma confiável no momento da consulta. A versão prévia é executada por meio da API REST e dos SDKs de pré-visualização e não abrange todos os caminhos de implantação do agente. O Azure OpenAI On Your Data, por exemplo, oferece suporte ao acesso em nível de documento por meio dos filtros de segurança do Azure AI Search, mas a própria documentação da Microsoft afirma que, se o campo permitted-groups não estiver mapeado, o acesso em nível de documento será desativado.
Essa é uma configuração padrão de fail-open em um caminho de primeira parte. Pipelines RAG personalizados que ignoram completamente o Azure AI Search ainda indexam em uma conta de serviço com privilégios amplos, sem verificação de direitos em tempo de consulta, a menos que o desenvolvedor crie uma. A implantação de Cioffi seguiu o caminho do pipeline personalizado.
A equipe vermelha da STAR Labs realizou mais de 1.700 tentativas de exploração bem-sucedidas contra agentes de produção e publicou os resultados em seu primeiro Relatório de Ameaças da STAR Labs, em julho. A taxa de 91% obtida em sua pesquisa mede todos os ataques bem-sucedidos contra agentes de produção que resultaram em exfiltração de dados sem detecção. Trata-se de uma medida do que aconteceu após a exploração bem-sucedida, e não de quantas implementações falham em aplicar restrições de tempo de recuperação de dados.
Entre os agentes de produtividade analisados, 91% dos ataques bem-sucedidos resultaram em exfiltração silenciosa de dados, sem que nenhum malware fosse necessário, conforme observado no relatório. Também não houve movimentação lateral pela rede. O agente retornou todos os dados que conseguiu alcançar. O relatório de Straiker não especifica quais desses sucessos se devem a falhas de autorização, injeção de código, abuso de ferramentas ou outras classes de ataque.
Trabalhando de forma independente, o Instituto de Segurança de IA do Reino Unido (UKASI) documentou 19 ações não autorizadas de agentes durante uma avaliação cibernética realizada entre 25 e 28 de julho. O UKASI publicou seu relatório de incidente em 4 de agosto deste ano. A avaliação foi conduzida deliberadamente com os classificadores cibernéticos desativados e o acesso à internet ativado. O relatório do UKASI demonstra que os agentes agiram fora do escopo pretendido por seus responsáveis pela implantação, em um ambiente de teste permissivo, sem nenhum mecanismo confiável para detectar o desvio antes que causasse danos. Trata-se de uma falha de contenção, não de uma falha de autorização de recuperação, e a semelhança com o incidente da Cioffi reside na ausência de uma verificação de escopo em tempo de execução, e não em um mecanismo idêntico.
As avaliações realizadas pela equipe da Cioffi foram projetadas para testar se o agente responde corretamente. Elas verificam a precisão factual, a relevância e a conclusão da tarefa. Elas não questionam quais permissões o pipeline de recuperação utiliza ao buscar o material de origem, porque essa questão não está presente na estrutura de avaliação.
O Azure AI Search atualmente implementa a verificação de direitos em tempo de recuperação no nível da plataforma. O filtro de ACL em tempo de consulta valida o token Entra do solicitante, extrai as declarações de usuário e grupo e retorna apenas os documentos cujos metadados de permissão sincronizados concedem acesso ao solicitante. Para implantações que usam o Azure AI Search com o indexador do SharePoint e entidades com suporte do Entra, o controle existe nativamente. A implantação de Cioffi não utilizou esse caminho. Seu pipeline de recuperação personalizado do Azure OpenAI ignorou a camada de filtro nativa, e foi assim que a falha persistiu em todas as avaliações realizadas por sua equipe.
Do ponto de vista do atacante, trata-se de uma falha no controle de acesso. Adriel Desautels, fundador e CEO da Netragard, explicou ao VentureBeat, em respostas por escrito, que a falha se resume a um colapso estrutural dos limites de autorização. "Se as credenciais do NHI (National Health Information) geralmente têm autorização ampla e podem ler dados com privilégios elevados, esses dados são armazenados em seu índice", escreveu Desautels. "Se um aplicativo não impõe a recuperação de dados com reconhecimento de identidade, um usuário 'normal' com permissões mais baixas pode consultar o aplicativo e acessar dados que, de outra forma, seriam restritos. "Isso reduz os limites de autorização ao nível de privilégio mais baixo com capacidade de busca.
Essa lacuna foi o que o teste de baixo privilégio de Cioffi expôs. A janela de contexto do assistente continha conteúdo do SharePoint que a conta de baixo privilégio não poderia ter recuperado diretamente pelo SharePoint. A avaliação foi aprovada. O limite de permissão de recuperação não havia sido aplicado.
Desautels explicou a lacuna na avaliação em termos operacionais. "Os agentes tendem a executar uma única identidade não humana, de longa duração, que detém uma ampla gama de permissões necessárias para qualquer tarefa que lhes seja solicitada", escreveu ele. "As avaliações também costumam não abranger prompts, saídas, transcrições, memória e registros, que podem ser lidos ou sequestrados por meio de conteúdo injetado. Essa discrepância é o que a maioria das avaliações atuais ignora."
O filtro de Cioffi restringiu o escopo de recuperação do assistente. A correção de Cioffi não exigiu uma nova plataforma de identidade. Ele moveu a decisão de autorização para o próprio caminho de recuperação, adicionando um filtro de caminho de consulta que verifica as permissões do SharePoint do usuário solicitante antes que o modelo veja um fragmento. O filtro é executado no momento da consulta, não no momento da indexação. O conteúdo que o usuário não conseguiu abrir no SharePoint não entra na janela de contexto do modelo.
O controle restringiu o alcance do assistente. O assistente ainda resolve automaticamente cerca de 60% dos e-mails recebidos com o filtro ativo, disse Cioffi ao VentureBeat. Ele não forneceu um número de resolução automática antes da implementação do filtro para comparação. A contrapartida qualitativa que ele descreveu é que alguns conteúdos que o assistente usava anteriormente para responder perguntas agora são excluídos porque as permissões do usuário solicitante não os alcançam. Esse é o preço de impor essa restrição.
A questão de saber se a filtragem de permissões em tempo de recuperação compensa o escopo de recuperação restrito não tem uma resposta única. Depende da sensibilidade do conteúdo indexado, da variação de permissões entre os usuários e se a implementação tolera consultas sem resposta quando o filtro bloqueia um trecho necessário para o modelo. O incidente de Cioffi demonstra que essa lacuna existe em pipelines personalizados do Azure OpenAI, que as avaliações de qualidade da resposta não a detectam e que um filtro de caminho de consulta a resolve, mediante uma compensação que o desenvolvedor pode descrever.
As plataformas de governança de identidade abordam uma camada diferente.
A CrowdStrike anunciou a aquisição da SGNL por $740 milhões em 8 de janeiro de 2026 e concluiu o negócio em 20 de fevereiro de 2026. A Palo Alto Networks anunciou a aquisição da CyberArk por $25 bilhões em julho de 2025 e concluiu o negócio em 11 de fevereiro de 2026. Ambos os negócios foram fechados no mesmo mês, estabelecendo a segurança de identidade como um pilar fundamental da plataforma de duas das maiores fornecedoras de segurança do mundo.
As plataformas de governança de identidade focam em quais contas de serviço existem, a que elas podem acessar e quando seus tokens expiram. Elas governam o ciclo de vida das credenciais que alimentam os agentes de IA. Essa camada é importante. O que ela não governa é o limite de permissão de recuperação. Ou seja, o momento em que uma conta de serviço com escopo correto recupera conteúdo em nome de um usuário que possui menos permissões do que a tarefa de indexação.
Todas as credenciais na cadeia são legítimas. A conta de serviço está limpa e devidamente gerenciada. Um usuário com privilégios limitados consulta o assistente, e este responde com base em todo o escopo indexado. Nada sinaliza a recuperação da informação, pois nenhuma credencial foi usada indevidamente.
O filtro s é um controle específico na camada de permissão de recuperação. O recurso nativo de filtragem de ACL do Azure AI Search aborda a mesma camada para implantações que o utilizam. Nenhum deles substitui a governança de identidade. Uma implantação de produção que deseja eliminar tanto a lacuna do ciclo de vida das credenciais quanto a lacuna de direitos no momento da recuperação precisa de controles em ambas as camadas.
Uma pergunta e um teste, qualquer equipe de segurança pode executar
Pergunte a quem cada sistema de recuperação de conteúdo por IA concede permissões ao buscar conteú. Se a implantação usar o Azure AI Search com o indexador do SharePoint e entidades de segurança com suporte do Entra, verifique se o ajuste de ACL em tempo de consulta está habilitado e se a população de usuários não depende de grupos de sites do SharePoint. Se a implantação usar um pipeline de recuperação personalizado, a verificação de direitos pode não existir.
Comece por comprovar a resposta a partir de uma conta com privilégios baixos. Execute a mesma pergunta que uma conta com privilégios elevados já fez ao assistente. Compare os resultados com o que a conta com privilégios baixos pode acessar diretamente através do sistema subjacente.
Desautels confirmou que é por aí que uma equipe vermelha começaria. "O primeiro teste provavelmente teria como alvo as lacunas entre os dados e as instruções, e as lacunas entre a identidade do usuário e as credenciais do assistente", escreveu ele. "Tentaríamos inserir uma instrução em um conteúdo que acreditamos que o assistente irá ingerir como dados."
Faríamos com que esse conteúdo direcionasse uma ação privilegiada com efeito colateral que o usuário atacante não está autorizado a executar
Se o assistente retornar mais informações do que o acesso direto da conta permitiria, o limite de permissão de recuperação não será aplicado no momento da consulta. Esse teste custa duas contas e trinta minutos. Ele produz um resultado que uma pontuação de avaliação não consegue replicar.
Cioffi criou o agente em um pipeline personalizado do Azure OpenAI que ignorava a camada nativa de filtragem de ACL. Ele executou todas as avaliações que sua equipe havia solicitado. Ele encontrou a falha em seus próprios logs depois que todas as avaliações foram aprovadas. A avaliação testava se o agente respondia corretamente. Ela não testava quais permissões o agente estava usando. Execute a comparação entre as duas contas antes da próxima implantação entrar em produção. Trinta minutos lhe dirão de que lado da linha você está.
