Seu agente pode ler o documento. E quem pergunta? O padrão da Microsoft para SharePoint responde por usuário
Na arquitetura de referência da Microsoft, o agente do Foundry infere com a própria identidade e busca no SharePoint como o usuário. O teste com dois usuários vale para todo RAG.
Ouça este artigo · 5 min
Narração completa do artigo, gerada por IA.
Uma analista de finanças, um business partner de RH e um gerente de projetos fazem a mesma pergunta a um agente interno. No SharePoint, cada um deles abre um conjunto diferente de documentos. O agente, rodando com a própria identidade, abre o que recebeu permissão para abrir. As permissões de quem decidem a resposta?
Em muitos sistemas de RAG (busca em documentos da empresa antes de responder), a resposta honesta é: as do agente. A busca roda com uma identidade de serviço, e o funcionário recebe uma resposta construída a partir de documentos que ele mesmo jamais conseguiria abrir. Nenhum prompt resolve isso, e a Microsoft diz com todas as letras numa arquitetura de referência publicada em 12 de outubro: “Mudar o modelo ou o prompt não resolve. A arquitetura precisa levar a identidade do usuário até o SharePoint.”
Duas identidades no mesmo pedido
O padrão divide o pedido em dois. Um agente hospedado no Foundry Agent Service “continua usando a própria identidade para a inferência do modelo, enquanto a busca roda com a identidade do usuário logado”. Três peças levam a identidade do usuário de ponta a ponta:
- o Foundry toolbox no agente envia um ID de chamada por requisição em cada chamada de ferramenta, para que o Foundry saiba a qual usuário ela pertence;
- uma conexão UserEntraToken repassa o token do Microsoft Entra ID desse usuário para uma base de conhecimento do Foundry IQ no Azure AI Search, um repasse On-Behalf-Of;
- uma fonte de conhecimento remota do SharePoint consulta o SharePoint ao vivo pela Microsoft 365 Copilot Retrieval API como esse usuário, limitada aos sites escolhidos. “Nada é copiado para um índice.”
| Passo | Roda como | Por quê |
|---|---|---|
| Inferência do modelo | O agente | Usa o acesso do próprio agente ao modelo |
| Roteamento da chamada de ferramenta | O agente, com o ID de chamada do usuário | Liga cada chamada a um único usuário |
| Consulta à base de conhecimento | O usuário | Token do Entra repassado em nome do usuário |
| Busca no SharePoint | O usuário | O SharePoint aplica o próprio filtro de permissões |
O desenho importa tanto pelo que tira quanto pelo que acrescenta. Não há índice separado para proteger, nenhuma cópia das permissões dos documentos para manter sincronizada e nenhuma conta de serviço capaz de ler todos os sites. O SharePoint continua sendo a autoridade sobre quem pode abrir o quê, que é onde essa decisão deve ficar.
As armadilhas são a parte útil
O texto da Microsoft vale mais onde descreve o que deu errado nos testes:
- Uma managed identity na conexão falha. A busca passa a rodar como o agente, o SharePoint fica sem usuário para verificar e a requisição é rejeitada.
- Um cliente MCP customizado pode misturar usuários. Um cliente feito à mão que anexava só a credencial do agente perdia o ID de chamada por requisição; nos testes da Microsoft com outra ferramenta OAuth, “todos os usuários acabaram rodando como quem deu consentimento primeiro”. É uma exposição de dados entre usuários causada por um detalhe de integração, não pelo modelo.
- Todo usuário precisa de um papel no serviço de busca, porque o token de cada um agora chega ao Azure AI Search. Atribua a um grupo, ou a busca falha para quem consegue acessar o agente.
- Um proxy On-Behalf-Of customizado pode funcionar, mas aí o time passa a responder por hospedagem, segredos, validação de tokens e patches.
A segunda armadilha merece entrar em toda revisão de segurança de agente que chama ferramentas em nome de usuários. A propagação de identidade não é uma propriedade do protocolo; é uma propriedade do cliente que o implementa. A mesma lição aparece na nossa análise de por que o MCP enterprise começa pela identidade e das três identidades que todo agente carrega.
Limites antes de planejar em cima disso
É uma implementação de referência, não um produto novo. As fontes de conhecimento remotas do SharePoint no Foundry IQ estavam em preview quando o texto foi escrito. Os usuários finais precisam de uma licença do Microsoft 365 Copilot, de um papel de leitura no serviço de busca e de acesso ao agente, e o serviço de busca tem de estar numa região que suporte agentic retrieval, no mesmo tenant do Entra que o Microsoft 365. A Microsoft posiciona o Work IQ, que também busca como o usuário, para agentes que precisam do contexto mais amplo do Microsoft 365 de uma pessoa; este padrão é para agentes que devem ficar dentro de sites definidos do SharePoint.
O teste para guardar
O conselho final da Microsoft é o que vale copiar para o checklist de release: “Uma boa resposta não prova que as permissões certas foram usadas.” Escolha um documento que só um de dois usuários de teste consegue abrir. O usuário A deve receber uma resposta com citação; o usuário B deve ouvir que as fontes não contêm a resposta. Rode o teste em conversas separadas e repita a cada mudança de permissão. As instruções do agente também ajudam: diga a ele para avisar quando as ferramentas não retornarem nada relevante em vez de chutar, para que um limite de permissão apareça como “não sei” e não como uma resposta inventada.
Um sistema de RAG que passa nesse teste está aplicando as permissões da empresa. Um que nunca o rodou está apenas supondo que sim.