No cenário atual, onde a automação por IA deixa de ser um experimento e se torna parte do core da operação enterprise, surge o desafio técnico de manter a governança de dados. Em muitas implementações, o uso excessivo de service accounts ou PAT tokens (Personal Access Tokens) cria uma falha crítica de segurança: o contorno de políticas essenciais como row-level security (RLS), column masking e as regras de data governance do Unity Catalog.
Quando um agente, seja ele um assistente de BI ou uma ferramenta de automação de dados, consulta o backend sem a identidade do usuário final, a organização perde a visibilidade, o controle de acesso e a auditabilidade. O problema central é garantir que a IA, agindo em nome de, nunca possua privilégios superiores aos do humano que disparou a solicitação.
A Arquitetura
Nesta solução, o foco foi garantir a delegação de identidade usando o fluxo On-Behalf-Of (OBO) do Microsoft Entra ID. A arquitetura integra os seguintes componentes:
- Chainlit: Interface de conversação, personalizada para suportar autenticação baseada em OAuth 2.0.
- Azure App Service: Hospedagem com autoscaling e suporte nativo a autenticação.
- LangGraph: Framework para orquestração de múltiplos agentes.
- Azure Databricks Genie: Agente de conversão de linguagem natural para SQL.
- Azure Cosmos DB: Armazenamento de long-term memory e checkpoint storage.
- Microsoft Entra ID: Provedor de identidade central.
O fluxo estabelecido garante que o Databricks Genie realize consultas em modo read-only conforme o contexto do usuário, enquanto um Task Agent isolado cuida de modificações em delta tables com aprovação Human-in-the-Loop (HITL).
O Desafio da Integração OAuth com Chainlit
A implementação padrão do Chainlit frequentemente assume escopos do Microsoft Graph API. Para o fluxo OBO com o Databricks, isso é insuficiente. O desafio é garantir que o access token recebido tenha a audiência correta para a troca entre serviços (api://{client_id}/access_as_user), permitindo que a aplicação faça a troca segura do token de usuário para um token de serviço downstream sem comprometer o Zero Trust.
O Fluxo de Troca de Token (OBO)
Uma vez obtido o access token com a audiência ideal, utilizamos a biblioteca MSAL para efetuar a troca pelo token de escopo do Databricks. O resultado é um token que contém o UPN do usuário: ao passar isso para o WorkspaceClient do Databricks SDK, garantimos que cada query executada pelo agente obedeça rigorosamente às permissões do Unity Catalog configuradas para aquele indivíduo.
Pontos de Atenção para Engenharia
- Isolamento de Agentes: Jamais utilize agentes globais em cache. Cada sessão de usuário requer instâncias independentes de agentes para evitar vazamento de contexto ou privilégios.
- Tokens e Claims: Quando a audiência impedie o acesso direto ao Graph API, utilize as claims do ID Token para extrair o contexto de identidade necessário.
- Human-in-the-Loop (HITL): Mesmo com RBAC alinhado no Unity Catalog, operações destrutivas (DROP, DELETE, UPDATE) devem sempre exigir aprovação explícita do usuário via interrupt feature do LangGraph.
Para empresas brasileiras, que enfrentam regulamentações rígidas de privacidade de dados e conformidade com a LGPD, esta abordagem de identity-first não é um luxo, mas uma necessidade estratégica. O uso de tokens específicos por usuário, integrados ao Unity Catalog, elimina o risco de acessos não autorizados por ferramentas de IA e reforça a postura de zero-trust exigida pelos CISO's modernos.
Artigo originalmente publicado em Azure Updates - Latest from Azure Charts.
