Read this article in English

Todo agente sobre o Microsoft 365 que eu revisei nos últimos anos tinha o mesmo encanamento. Um conector copiava e-mail, chat e arquivos para um storage do projeto; um pipeline cortava tudo em chunks, gerava embeddings e carregava um índice vetorial; um job noturno mantinha a sincronia; e a permissão vinha por último, reproduzida à mão no código de busca. A demonstração sempre funcionava. O problema aparecia depois: alguém saía de um grupo do SharePoint às dez da manhã e o agente continuava citando os documentos daquele grupo até o sync da madrugada. O índice estava atrasado, e o atraso era exposição. Na reunião seguinte, a pergunta de compliance não era sobre o modelo. Era onde mora a cópia.

Do índice à identidade O Microsoft Work IQ tira esse encanamento da sua mão: não existe índice seu para manter, e a resposta volta cortada pela permissão de quem pergunta. O preço é arquitetural e quase ninguém lê antes de ligar: não há autenticação application-only, cada chamada roda como uma pessoa e a política do tenant bloqueia escrita por padrão. Este artigo é sobre a troca do índice pela identidade — e sobre o que acontece com ela quando o agente também conversa com o Foundry, com os data agents do Microsoft Fabric e com o Genie do Databricks.

O que é o Microsoft Work IQ?

A documentação define o Work IQ como “a workplace intelligence layer that enables agents to access and reason over organizational and business data, context, and tools”. Na prática, são três endpoints de serviço e um CLI local: A2A para conversa entre agentes, MCP remoto para clientes de ferramentas e REST para quem quer pergunta e resposta. O CLI se configura como servidor MCP local na máquina do desenvolvedor (workiq mcp, por stdio), para IDE e assistente de código, e não entra na conta dos endpoints de serviço. O alcance cobre e-mail, calendário, arquivos, pessoas, chat e sites, e a página inclui também dados de negócio e de fluxo do Dynamics 365 e da Power Platform.

O contraste é com o RAG que você monta. No RAG, o índice é seu: você decide o que entra, quando atualiza e como corta permissão, e responde por cada uma dessas decisões. No Work IQ, a página da API resume a troca numa frase: “No need to manage vector stores, data sync jobs, or custom compliance enforcement.” O resultado vem “automatically permission-trimmed and policy-enforced”. Mas repare no overview: a camada “continuously builds a semantic understanding across Microsoft 365 and external systems”. O índice continua existindo. O que muda é que não existe índice seu — e isso é bem diferente de não existir índice.

O produto se organiza em quatro frentes — “Combining chat, context, tools, and workspaces” — e a de workspaces merece atenção de quem desenha: “SharePoint Embedded working storage gives agents a persistent space within your Microsoft 365 tenant boundary”. A memória de trabalho do agente fica dentro do tenant, e não num storage account seu. O MCP remoto, por sua vez, “collapses hundreds of operations into just 10 generic tools”: são 10 ferramentas genéricas, e novos workloads acrescentam caminhos, não ferramentas. Esse desenho merece um artigo próprio. Na documentação do Fabric, o Work IQ é uma das quatro camadas do Microsoft IQ, ao lado do Foundry IQ, do Web IQ e do Fabric IQ: “Work IQ provides context on how employees work”. O mapa das quatro também fica para um artigo próprio.

O problema que resolve

O RAG sobre o Microsoft 365 falha menos no modelo e mais no encanamento. São quatro peças que você passa a operar para sempre: o conector, que copia o conteúdo para fora do Microsoft 365; o índice vetorial, com chunks e embeddings sob a sua guarda; o job de sync, que define o frescor por agenda e, portanto, garante atraso; e o corte de permissão, a ACL do SharePoint reproduzida no seu código. Cada peça é um risco seu. A cópia amplia a superfície de dado sensível, o atraso transforma revogação de acesso em janela de exposição, e o corte à mão diverge da permissão real no primeiro caso de borda: grupo aninhado, link de compartilhamento, rótulo de sensibilidade.

Foi esse o limite que apareceu no artigo sobre RAG ou text-to-SQL: o índice vetorial não herda a permissão da fonte, e alguém precisa reconstruí-la. Aqui a pergunta muda de lugar. O Work IQ não ajuda a reconstruir a permissão; ele remove a cópia, e com ela o índice, o sync e o corte. O que sobra é a pergunta que o índice escondia: em nome de quem o agente está lendo?

Como funciona — passo a passo

1. Habilite o Work IQ no tenant. O serviço vem antes de qualquer consentimento: “An organization administrator must enable Work IQ in your organization before these permissions can be used”.
2. Registre o app e peça o escopo delegado. O escopo é um só, api://workiq.svc.cloud.microsoft/WorkIQAgent.Ask, sem versão de aplicação e com consentimento de administrador obrigatório. Se houver usuário de outro tenant, registre o app como multitenant desde o início.
3. Obtenha o token do usuário — ou troque o dele por OBO. Cliente com usuário na frente usa o token delegado; backend que recebe a chamada de um front-end faz OBO (on-behalf-of) e segue em nome de quem entrou.
4. Escolha o endpoint pelo cliente. A2A para agente que delega a outro agente; MCP remoto para cliente de ferramentas; REST para orquestrador que só quer pergunta e resposta; o CLI para a máquina do desenvolvedor.
5. Deixe a permissão e a política trabalharem. A resposta volta cortada pela permissão do usuário no Microsoft 365, e cada pedido de ferramenta passa pela política do tenant, que segura criação, alteração e exclusão até o administrador liberar.
6. Meça o consumo por agente. O uso é cobrado em Copilot Credits, de forma “independent of Microsoft 365 Copilot licensing”: quem já tem licença também paga quando a chamada vem de agente custom ou de terceiro. As moedas de cobrança do Work IQ, do Fabric e do Foundry ficam para um artigo próprio.

O que sai da sua mão — e o que fica

O que não sai da sua mão é justamente o que o índice deixava esconder: quem é o usuário, o que ele pode ver e o que o agente pode fazer em nome dele. O Work IQ aplica a permissão que existe; ele não conserta a permissão errada. Se o site do jurídico está compartilhado com a empresa inteira, o agente de qualquer funcionário também está. A higiene de compartilhamento que o corte à mão mascarava passa a ser visível — e passa a ser sua.

A identidade é o preço: sem app-only, com OBO

A frase mais importante da documentação cabe numa linha: “Application-only authentication isn’t supported.” Não existe client credentials, não existe conta de serviço, não existe job noturno lendo a caixa de todo mundo. O que existe é delegação: “On-behalf-of (OBO) flows are supported.” e “Requests run in the context of the signed-in user.” A tabela de permissões confirma pelo lado do Entra: WorkIQAgent.Ask tem a coluna de aplicação vazia.

Isso muda o desenho de três formas. Primeiro, todo agente que inclui o Work IQ roda com gente atrás: um agente autônomo, disparado por agenda, não tem de quem tomar a identidade emprestada. Segundo, o backend vira intermediário de identidade: recebe o token do front-end, troca por OBO, e a trilha mostra o usuário, não o app. Terceiro, multitenant tem regra própria: em organizações pai e filho, o iss do token precisa ser o tenant de casa do usuário — “Work IQ enabled in both tenants isn’t enough” —, e o app precisa estar registrado como AzureADMultipleOrgs; do contrário, a chamada volta 400 AuthenticationError.

No A2A, a versão do protocolo vai no cabeçalho: “The A2A-Version: 1.0 header is required to use v1.0 method names (SendMessage). Omitting it defaults to v0.3.” Este é o exemplo da documentação, com o fuso ajustado para São Paulo:

POST https://workiq.svc.cloud.microsoft/a2a/
Authorization: Bearer <token delegado do usuário>
Content-Type: application/json
A2A-Version: 1.0

{
  "jsonrpc": "2.0",
  "id": "<request-guid>",
  "method": "SendMessage",
  "params": {
    "message": {
      "role": "ROLE_USER",
      "messageId": "<message-guid>",
      "parts": [{ "text": "Resuma as decisões da última reunião do comitê de crédito." }],
      "metadata": {
        "Location": { "timeZoneOffset": -180, "timeZone": "America/Sao_Paulo" }
      }
    }
  }
}

O artigo sobre A2A cobre o protocolo; aqui o ponto é outro: quem delega é um agente, mas quem responde é o usuário. E a identidade própria do agente, tema do artigo sobre Entra Agent ID, não aparece nas páginas da API do Work IQ como alternativa: o que elas aceitam é o usuário, direto ou por OBO.

Escrever é outra conversa: a política do tenant decide

Um detalhe desmente a leitura apressada de read-only. O escopo concede “read and write access to Microsoft 365 resources that are accessible to Work IQ agents and scoped to the signed-in user”. Quem segura a escrita não é o OAuth; é uma camada de política: “A separate tenant policy layer evaluates each tool request and blocks mutation operations by default.” O administrador libera por cenário — “Administrators can enable supported mutation scenarios through tenant policy” —, e o motor dessa política é baseado em Rego. No Copilot Studio, a mesma regra aparece do lado do produto: “Microsoft 365 Work IQ is read only unless an administrator explicitly turns on write operations”. Para o desenho, a consequência é direta: a política é do tenant, e o cenário de escrita precisa de dono antes de existir, não depois do primeiro incidente. Como escrever essa política fica para um artigo próprio.

Compondo com Foundry, Fabric e Databricks

O Work IQ raramente vai estar sozinho. A pergunta do comitê de crédito junta a ata da reunião, que mora no Microsoft 365, o número da carteira, que mora num lakehouse do Fabric, e o modelo de risco, que mora no Databricks. A boa notícia é que cada plataforma tem um agente que responde no lugar, com a identidade de quem pergunta: o Work IQ no Microsoft 365, o data agent no Fabric e o Genie no Databricks. A má notícia é que cada uma também tem uma porta em que a identidade troca.

A regra: compor por agente, não por catálogo

A regra que amarra esta seção: compor por agente preserva a identidade; compor por catálogo troca a identidade. Quando o orquestrador chama outro agente com o token do usuário, cada plataforma aplica a própria permissão. Quando você junta os dados num catálogo — federação, espelho, cópia —, a consulta passa a rodar com a credencial da conexão. E mesmo dentro do agente há duas exceções: o modo Maker e o token de service principal.

usuário ── token delegado ──► agente no Foundry
                                ├── OBO ─────────► Work IQ ──────► Microsoft 365, como o usuário
                                ├── usuário ─────► data agent ───► OneLake, como o usuário
                                └── passthrough ─► Genie ────────► Unity Catalog, como o usuário

catálogo ── credencial da conexão ──► federação ou espelho ──► dado, como a conexão

Foundry: três ferramentas, todas delegadas

No Foundry, o Work IQ entra como a ferramenta work_iq_preview, ainda em preview: “Authentication uses On-Behalf-Of (OBO) so the request runs in the context of the signed-in user”. Na montagem da caixa de ferramentas, “Work IQ Chat connects through an A2A endpoint”, e as demais opções — Copilot Chat, Teams, Word, Outlook Calendar, Outlook Mail, o perfil de usuário do Microsoft 365, SharePoint e OneDrive — vão por MCP. A preparação é única: um Global Administrator provisiona o service principal do recurso Work IQ no tenant (não é uma identidade para o agente usar) e concede o consentimento de WorkIQAgent.Ask, com o papel ativado “just in time through Microsoft Entra Privileged Identity Management (PIM)” e desativado depois.

O data agent do Fabric entra pela ferramenta do Fabric, com duas travas: “Service principal authentication isn’t supported for the Fabric data agent”, e data agent e projeto ficam no mesmo tenant, com as fontes em capacidades da mesma região. O Genie entra pela ferramenta Azure Databricks Genie, em Public Preview, com a autenticação “Automatically set to OAuth identity passthrough” e um app OAuth próprio registrado na conta do Databricks. No Foundry, as três são delegadas: o agente composto é OBO de ponta a ponta.

Há um segundo caminho do Foundry até o Microsoft 365: o knowledge source de SharePoint remoto, que usa a Copilot Retrieval API — “Unlike indexed knowledge sources, remote SharePoint knowledge sources query live data directly at retrieval time.” Em preview, ele cobre só SharePoint, cobra pela licença de Microsoft 365 Copilot e tem limite de 200 requisições por usuário por hora. Serve para recuperar documento; para e-mail, agenda e chat, o caminho é o Work IQ.

Fabric: o data agent não lê o Microsoft 365

Aqui mora a confusão mais provável. O data agent do Fabric combina até cinco fontes, “in any combination”, e é “a generally available feature”; ele “strictly enforces read-only access” e “uses the requesting user’s credentials and permissions to enforce least-privilege access”. Entre as fontes em preview há uma chamada Graph — e ela é o Graph Model do Fabric, consultado em GQL, para “Relationship-rich data exploration and graph analytics”. Não é o Microsoft Graph do Microsoft 365. A página da ferramenta do Fabric no Foundry descreve a permissão dessa fonte como “Delegated access to the Microsoft 365 content requested by the signed-in user”, mas a página de compartilhamento do Fabric chama a mesma linha de “Microsoft Graph in Fabric”, com leitura no item de grafo. Leia como item de grafo do Fabric: o contexto do Microsoft 365 entra pelo Work IQ, na camada do agente.

No Copilot Studio, o data agent tem dois modos. No modo User, responde com a credencial de quem conversa. No modo Maker, com a de quem configurou: “Everyone who uses the agent sees data through the maker’s access.” Num agente que também usa o Work IQ, a resposta mistura identidades: o e-mail vem pelo usuário, o número vem pelo criador do agente. Em banco, essa é a diferença entre um assistente e um vazamento. O servidor MCP do data agent, útil para plugar o Fabric em qualquer cliente de ferramentas, abre a mesma questão por outra porta: “The token can represent either a user identity or a service principal”.

Publicado no Microsoft 365 Copilot, em preview, o data agent aparece na Agent Store e roda sob o orquestrador do Copilot, que “uses the chat context, user intent, and its own model’s reasoning to shape the final response”. A página avisa que “some level of change is inevitable”. Em FSI, o número do data agent pode voltar reescrito, e o contrato do artigo sobre o data agent vale em dobro.

E se a ideia for levar o Microsoft 365 para o lakehouse? O caminho documentado é a cópia pelo conector do Microsoft 365 no Data Factory, que exige aprovação no Privileged Access Management: “A member of the data access approver group needs to approve the request in the Privileged Access Management before the data extraction can proceed.” A conexão é por service principal. É o encanamento de antes, com outro nome: útil para análise em lote, e justamente o que o Work IQ existe para evitar no caminho do agente.

Databricks: o Genie responde no lugar

No Databricks, o equivalente é o Genie — “Genie Agents were formerly known as Genie Spaces”. Pelo Foundry, a conexão é por identity passthrough. Por MCP, o endpoint atual é o Genie One, system.ai.genie_one_mcp, em que “Unity Catalog permissions are enforced on every request”; o endpoint Beta anterior está descontinuado e sai do ar em 31 de outubro de 2026. Ele aceita OBO, com o escopo OAuth do ai-gateway, e também service principal, para cargas automatizadas. No Copilot Studio, também em Public Preview, o Genie usa a conexão do Power Platform, e entre tenants o service principal é obrigatório. As portas por catálogo trocam a identidade: a federação do Databricks com o OneLake lê com identidade gerenciada ou service principal — “Data access is read-only.” —, e o espelho do Unity Catalog no Fabric usa uma credencial só, “The credential used to create the connection to Unity Catalog of this catalog mirroring is used for all data queries”, sem levar as permissões junto: “Unity Catalog policies and permission aren’t mirrored in Fabric”. Não há integração direta documentada entre Databricks e Work IQ; o encontro acontece no agente.

Duas fronteiras de conformidade

Compor também soma fronteiras. A ferramenta do Work IQ no Foundry avisa que “data might be sent outside the Azure compliance boundary”; o data agent no Microsoft 365 Copilot avisa que “responses returned by Fabric data agents may be sent outside of Fabric’s compliance boundary or geographic region”. Para quem responde à LGPD e às normas do Banco Central, cada seta do agente composto é uma transferência a documentar antes de virar linha de código.

Onde a documentação pede leitura atenta

Nenhuma dessas divergências impede o desenho, mas cada uma vira pergunta de auditoria. Anote a página e a data em que você leu: essas páginas mudam em semanas, e a revisão de arquitetura precisa saber qual versão valeu.

Boas práticas para produção

• Desenhe o agente com usuário na frente. Se o caso de uso é um job sem pessoa, o Work IQ não é o caminho; não contorne com uma conta humana genérica.
• Faça OBO no backend e leve o usuário até a trilha de auditoria de cada chamada.
• Decida o multitenant no registro do app, com AzureADMultipleOrgs, e trate 400 AuthenticationError como erro de desenho, não de rede.
• Saneie o compartilhamento antes de ligar. O agente enxerga o que o usuário enxerga; o site aberto para a empresa inteira vira resposta.
• Dê dono a cada cenário de escrita na política do tenant; bloqueado por padrão é o estado certo para começar.
• Use o data agent no modo User. O modo Maker é exceção, com justificativa escrita e revisão de acesso.
• Mande token de usuário para o MCP do data agent sempre que houver uma pessoa no fluxo.
• Troque o endpoint Beta do Genie pelo system.ai.genie_one_mcp antes de 31/10/2026.
• Documente a fronteira de conformidade de cada seta do agente composto.
• Separe o caminho em lote. Levar o Microsoft 365 para o lakehouse é cópia com aprovação no PAM: outro pipeline, com outro dono.
• Meça Copilot Credits por agente, não por tenant.

O que precisa estar de pé

A ordem abaixo é causal, não cronológica: cada estágio existe porque o anterior ficou de pé.

Fundação — a identidade chega inteira. O Work IQ está habilitado, o consentimento de WorkIQAgent.Ask foi dado com papel ativado sob demanda, o backend faz OBO e o registro multitenant está decidido. Nenhuma peça do agente depende de conta de serviço.

Está de pé quando cada chamada ao Work IQ aparece na auditoria com o nome de uma pessoa — e nenhuma com o nome de um app.

Produção com contexto — cada porta preserva a identidade. A composição com Foundry, data agent e Genie está mapeada porta a porta; o data agent roda no modo User; o MCP do data agent recebe token de usuário; e cada fronteira de conformidade foi revisada por quem responde pela LGPD.

Está de pé quando a tabela de portas e identidades do seu agente cabe numa página e nenhuma linha diz “a credencial da conexão” sem justificativa.

Escala e eficiência — a plataforma vira produto. O consumo em Copilot Credits é medido por agente; cenários de escrita são liberados por política, com dono e revisão; o caminho em lote tem pipeline e dono próprios; e as páginas em preview entram no seu ciclo de revisão.

Está de pé quando um agente novo nasce de um padrão que já traz OBO, modo User e orçamento de créditos, sem ninguém redescobrir as armadilhas.

Pular estágio não acelera nada: sem a identidade inteira, compor só multiplica o problema; sem as portas mapeadas, escalar é multiplicar portas que ninguém revisou.

Perguntas frequentes (FAQ)

O Work IQ substitui o Azure AI Search?

Para o conteúdo do Microsoft 365 lido por agente, ele tira de você o índice. Para o seu próprio corpus — contratos num storage, base de conhecimento do produto —, o índice continua sendo seu, e o Azure AI Search continua sendo o lugar dele.

Preciso de licença de Microsoft 365 Copilot?

Para a API, não: o uso é “independent of Microsoft 365 Copilot licensing” e é cobrado em Copilot Credits. Ferramentas do Foundry que passam por conector e o knowledge source de SharePoint remoto podem exigir a licença de cada usuário.

Dá para rodar um job noturno com service principal?

Não. “Application-only authentication isn’t supported.” Se não há usuário, o caso de uso pertence a outro caminho: em lote, com cópia e aprovação.

O data agent do Fabric lê meus e-mails?

Não. A fonte Graph do data agent é o Graph Model do Fabric, em GQL. E-mail, agenda e chat entram pelo Work IQ, na camada do agente.

O Work IQ está em preview?

As páginas da API não trazem rótulo de preview, mas a página do Foundry lista a mesma API como (preview), e a ferramenta work_iq_preview e a integração com o Copilot Studio estão em preview. Planeje pela integração que você vai usar, não pela API.

Existe integração direta entre Databricks e Work IQ?

Não há integração direta documentada. O encontro acontece no agente: o Foundry chama o Work IQ por OBO e o Genie por identity passthrough, e cada plataforma aplica a própria permissão.

Conclusão

O Microsoft Work IQ não é mais um conector. É o fim do encanamento que você mantinha para ler o Microsoft 365: o índice, o sync e o corte à mão saem da sua mão. Fica a pergunta que eles escondiam — em nome de quem? — e ela passa a ter resposta obrigatória: sempre uma pessoa.

Quando o agente também fala com o Fabric e com o Databricks, a regra se estende: compor por agente preserva a identidade; federação, espelho, modo Maker e service principal trocam. O desenho seguro não é o que tem menos portas. É o que sabe, porta a porta, de quem é a identidade que chega ao dado.

Referências oficiais

• Microsoft Work IQ — visão geral
• Work IQ API — protocolos, autenticação e cobrança
• Permissões do Work IQ
• Work IQ MCP — visão geral
• Work IQ MCP — referência de ferramentas
• Work IQ MCP — política e governança
• Work IQ no Copilot Studio
• Ferramenta Work IQ no Microsoft Foundry
• Ferramenta Fabric data agent no Microsoft Foundry
• Knowledge source de SharePoint remoto
• Data agent no Microsoft Fabric — conceito
• Fontes de dados do data agent
• Compartilhamento e permissões do data agent
• Data agent como ferramenta no Copilot Studio
• Servidor MCP do data agent
• Data agent no Microsoft 365 Copilot
• Conector do Microsoft 365 no Data Factory — visão geral
• Conector do Microsoft 365 no Data Factory — cópia
• Microsoft IQ na visão geral do Fabric IQ
• Segurança do espelho do Azure Databricks no Fabric
• Genie Agents
• Genie no Microsoft Foundry
• Genie One MCP
• Azure Databricks e Power Platform
• Genie no Copilot Studio
• Federação do OneLake no Azure Databricks

👉 Se você está levando agentes para o Microsoft 365 — especialmente em banco ou seguradora, onde cada resposta precisa dizer em nome de quem leu —, desenhe a identidade antes do prompt: OBO no backend, data agent no modo User e uma tabela de portas e identidades revisada por compliance.
Quer trocar ideia sobre Work IQ, data agents e identidade em agentes compostos? Me chama no LinkedIn.