No cenário atual de adoção massiva de Inteligência Artificial, um desafio crítico para empresas de tecnologia é garantir que o acesso aos dados pelos modelos seja tão restrito quanto o acesso de um ser humano. Quando um agente de IA consulta sistemas back-end, a prática de usar contas de serviço genéricas ou Tokens de Acesso Pessoal (PAT) cria um risco operacional severo: o bypass das políticas de row-level security (RLS) e column masking.
A arquitetura discutida aqui demonstra como resolver essa lacuna de segurança utilizando o fluxo On-Behalf-Of (OBO) do Microsoft Entra ID em uma estrutura de múltiplos agentes orquestrada pelo LangGraph. A premissa central é que o token enviado ao sistema (neste caso, o Azure Databricks) deve carregar a identidade do usuário final, e não a do sistema, garantindo que o Unity Catalog aplique os controles de RBAC (Role-Based Access Control) corretamente a cada interação.
A Arquitetura Proposta
O sistema foi estruturado com os seguintes componentes:
- Chainlit: Interface web baseada em Python que lida com a camada de autenticação OAuth 2.0.
- Azure App Service: Hospedagem com suporte nativo a autenticação e escalabilidade.
- LangGraph: Framework de orquestração para os agentes (ex: Genie para SQL e agentes de carga de trabalho).
- Azure Cosmos DB: Armazenamento de memória e checkpoints para o estado dos agentes.
- Microsoft Entra ID: O provedor de identidade que viabiliza o OBO.
O fluxo garante que o agente Genie realize consultas apenas de leitura seguindo o contexto do usuário, enquanto agentes com permissão de escrita operam sob supervisão human-in-the-loop (HITL).
O Problema do Provedor OAuth do Chainlit
A implementação out-of-the-box do Chainlit com Microsoft Entra ID é desenhada para Microsoft Graph API. Tokens gerados dessa forma têm o público (aud) definido como graph.microsoft.com, o que inviabiliza a troca de tokens (OBO flow) para serviços como Databricks. Para contornar isso, é imperativo que o scope solicitado no registro da aplicação inclua a permissão customizada api://{client_id}/access_as_user.
Implementação e Troca de Token OBO
Com o token correto, a mágica ocorre via MSAL (Microsoft Authentication Library). Ao realizar o OBO Token Exchange, o sistema troca o token original por um novo, cujo público (aud) é o ID do recurso do Databricks. Esse novo token, ao ser injetado no WorkspaceClient do SDK, garante que o Unity Catalog identifique e restrinja as queries ao usuário autenticado.
Uma decisão de design observada é fundamental: não cacheie clientes de agentes de forma global. Cada instância de um agente em cache deve ser volátil e vinculada estritamente à sessão do usuário para evitar vazamento de privilégios entre contextos.
Governança e Human-in-the-Loop
Para operações destrutivas (DELETE ou UPDATE), a dependência apenas do RBAC pode não ser suficiente. A utilização do recurso de interrupção do LangGraph permite uma camada de aprovação humana, reforçando o alinhamento com a Zero Trust architecture. Isso garante que o AI Agent atue como um facilitador técnico sem ter o "cheque em branco" na camada de dados.
Conclusão: Identidade como Fundação de AI Governance
A transição para arquiteturas multi-agente é um caminho sem volta, mas a segurança não pode ser um bottleneck. A implementação do fluxo OBO não é apenas um detalhe técnico; é a base para o cumprimento da Microsoft Secure Future Initiative (SFI).
À medida que o ecossistema evolui com ferramentas como Azure AI Foundry, o papel dos times de engenharia é garantir que a identidade do usuário seja preservada através do pipeline. A governança de dados agora é, definitivamente, uma preocupação estratégica para o nível C-suite.
Artigo originalmente publicado em Azure Updates - Latest from Azure Charts.
