O mesmo assistente de vendas pode responder a um gerente regional e a um executivo nacional sem mostrar a ambos os mesmos dados. A dificuldade é preservar essa diferença depois que a solicitação sai da interface e vira SQL, chamada de modelo ou ação de ferramenta de um agente.
A Databricks disponibilizou de forma geral a autorização de usuários do Apps em 7 de outubro de 2026, após mais de 18 meses de prévia pública. A autorização em nome do usuário, OBO, permite executar solicitações compatíveis com a identidade da pessoa autenticada, em vez de passar tudo pelo service principal do aplicativo. Os controles existentes do Unity Catalog acompanham a pessoa. Reduz-se a duplicação de políticas, mas delegar não torna um app automaticamente seguro.
Uma segunda identidade chega à produção
O Databricks Apps executa aplicações de dados, dashboards, ferramentas operacionais e agentes personalizados em infraestrutura serverless. Cada app implantado recebe um service principal dedicado: identidade não humana com permissões concedidas àquela instância. Essa autorização continua útil para configuração comum, telemetria, manutenção e trabalho automatizado.
A autorização de usuário acrescenta outro caminho, sem substituir o anterior. Para uma ação compatível iniciada por pessoa autenticada, a Databricks encaminha um token ao runtime. O app chama uma API aprovada com as permissões dessa pessoa. O modelo OAuth 2.0 distingue delegação usuário-máquina de trabalho máquina-máquina.
Em dados governados, o Unity Catalog avalia concessões, filtros de linha e máscaras de coluna existentes. Permissões do warehouse determinam separadamente se a consulta pode executar. Um gerente vê seu território, enquanto o executivo nacional vê mais, pelo mesmo caminho do app. Solicitações posteriores seguem políticas atualizadas do catálogo, não uma cópia mantida à parte.
Isso evita um desvio frequente. Uma identidade compartilhada apresenta ao backend um conjunto de permissões; desenvolvedores recriam quem pode receber cada resultado usando funções, mapeamentos, middleware ou outro serviço de política. Esses controles podem funcionar, mas alterar o catálogo sem atualizar o mapeamento local pode expor informações ou negar acesso legítimo.
A prévia pública de Apps OBO começou em 26 de março de 2025, incluindo tabelas Unity Catalog e endpoints de serving de modelos. GA indica prontidão para produção dentro dos limites documentados, não suporte universal a toda nuvem, região, workspace, perfil de conformidade ou API downstream. A fonte menciona uma indicação de expansão a workspaces com perfil de segurança de conformidade no fim de setembro de 2026; clientes ainda precisam confirmar seu ambiente.
O app pode ler instruções comuns e registrar métricas com sua identidade, depois consultar registros de clientes e vendas como o usuário atual. Autenticação estabelece quem está presente; autorização define o que pode fazer nos serviços seguintes. Confundir ambas perde a principal contribuição do lançamento.
Permissões do usuário e escopos do app precisam coincidir
Uma solicitação do app não dá acesso automático a tabela ou warehouse. A pessoa já precisa das permissões necessárias. Desenvolvedores também declaram escopos de API que limitam as classes de operação executadas em seu nome.
São duas fronteiras. O escopo não cria uma concessão de dados; restringe o uso do acesso existente. A Databricks documenta sql:restricted-query para análise SQL somente leitura, permitindo consultas restritas como usuário atual sem administração ampla de warehouses ou tarefas administrativas sem relação.
Isso importa especialmente para pessoas privilegiadas. Um executivo ou administrador pode acessar legitimamente muitos conjuntos sensíveis, mas um app restrito não deveria herdar toda capacidade que essa pessoa exerce diretamente. Escopos reduzem operações mesmo quando as permissões do usuário são extensas.
Administradores do workspace estabelecem outro teto para escopos adicionados por desenvolvedores. A lista pode permitir todas as APIs compatíveis, escopos selecionados ou nenhuma autorização de usuário. Segundo o anúncio, o padrão pode incluir todas as APIs. Trata-se de escolha de governança, não prova de uma base restritiva.
Há exceções importantes. Administradores de conta podem adicionar escopos excluídos pela lista do workspace. Remover um escopo antes permitido também não interrompe imediatamente apps existentes: eles podem continuar funcionando. Contudo, não podem depois iniciar, ser implantados ou atualizados até que removam o escopo proibido.
Mudar a lista, portanto, não equivale a revogar instantaneamente todo uso em execução. Inventários de apps implantados, responsáveis pelos escopos e dependências de negócio permitem entender a transição e evitar bloqueios inesperados na próxima implantação. Uma base limitada com exceções documentadas é melhor que supor que a configuração resolve toda aplicação da política.
Tokens pertencem à solicitação, não ao agente inteiro
O código deve separar clientes de usuário e de aplicativo. Consultas interativas governadas pertencem ao caminho do usuário; configurações compartilhadas e trabalho sem sessão seguem uma identidade de app adequadamente limitada. Dependências e handlers separados tornam credenciais indevidas mais visíveis que um cliente genérico escondendo seu principal.
Se uma rota exige autorização de usuário e falta o token encaminhado, deve rejeitar a solicitação. Fazer fallback silencioso para o service principal pode produzir resposta tecnicamente válida com permissões inteiramente diferentes, mais amplas ou estreitas. A pessoa talvez nem perceba a troca de identidade.
Tokens encaminhados nunca devem ser impressos, registrados ou persistidos. Para agentes personalizados em Apps, a Databricks exige inicializar o cliente de workspace do usuário dentro do handler invoke ou stream ativo. O token só existe durante a solicitação, não na inicialização global do aplicativo.
Um processo de agente atende muitas pessoas. Tratar a identidade como estado global pode perder ou misturar contexto. Um fluxo pode buscar instruções comuns como app, consultar finanças governadas como usuário e voltar ao app para telemetria geral, sem guardar sua credencial. Cada transição requer principal e escopo explícitos.
Tarefas longas ou adiadas criam outra fronteira. A pessoa iniciar um trabalho que supera a duração da solicitação não autoriza salvar o token. Trabalho do aplicativo exige service principal restrito. Se depender de contexto de usuário, precisa de outro padrão delegado documentado e compatível, não de retenção da credencial.
OBO tampouco atravessa automaticamente toda integração externa. O serviço downstream precisa oferecer suporte e pode exigir credenciais, consentimento, escopos e auditoria separados. Tokens têm público e finalidade específicos; a orientação Microsoft também alerta contra repassar tokens intermediários a destinatários indevidos. É delegação limitada, não representação irrestrita de toda cadeia.
Abrir o aplicativo não autoriza ler seus dados
Databricks Apps não é um modelo de aplicativo público anônimo. Usuários devem se autenticar, e colaboradores externos precisam de onboarding por federação de identidade compatível. O público natural é de funcionários e parceiros com identidades gerenciadas, não visitantes anônimos ilimitados.
CAN USE e CAN MANAGE regulam quem executa ou administra o app. Não concedem acesso às tabelas, registros ou warehouses subjacentes. Alguém pode abrir o app e receber dados negados ou limitados. Inversamente, uma concessão de tabela não autoriza necessariamente abrir o aplicativo.
Esses controles precisam de revisão separada das concessões Unity Catalog. Uma resposta SQL corretamente delegada pode ser combinada na interface com uma solicitação de arquivo executada por engano como app. A plataforma não garante que desenvolvedores atribuam a identidade pretendida a todo caminho de código.
Agentes ampliam o risco ao interpretar perguntas abertas, escolher ferramentas e construir consultas em várias etapas. Injeção de prompt no conteúdo pode estimular divulgação ou ação inadequada. OBO limita dados às permissões atuais, mas identidade válida e escopo somente leitura não provam que cada consulta atende à intenção da pessoa.
Consentimento também não substitui revisão administrativa. Pessoas podem aprovar escopos sem compreender como serviços e resultados se combinam. Tratamento de entradas, restrições de ferramentas, controles de saída e monitoramento continuam necessários: consultas incomuns, negações repetidas, volumes inesperados e mudanças de comportamento.
Testar apenas com administrador pode esconder defeitos porque essa conta raramente recebe negações. Usuários regionais, mais amplos e sem a tabela revelam resultados diferentes; é preciso verificar dados e rejeições. A Databricks recomenda repetir testes após mudanças de governança. Logs devem distinguir ações do app e de pessoas sem gravar tokens de portador ou respostas sensíveis.
Menos cópias de políticas, maior dependência da plataforma
Delegar não corrige concessões excessivas na origem. Grupos, privilégios do catálogo, acesso ao warehouse, filtros e máscaras precisam de manutenção correta. Uma base técnica pesquisável pode preservar modelos de ameaça, decisões de autorização e evidências de revisão junto à documentação, mas documentação não é aplicação da política.
A distinção da Databricks é integrar delegação aos seus dados governados, SQL e runtime, não inventar o conceito. A Microsoft já documenta OBO para APIs. O acesso orientado por identidade do Google enfatiza apps hospedados e políticas contextuais; a AWS fornece componentes de autorização para sistemas próprios. Cada abordagem divide de forma diferente o trabalho de integração.
Se os dados já estão no Unity Catalog, a Databricks pode reduzir a tradução de políticas entre segurança e frameworks de apps. A contrapartida é depender mais de escopos e comportamentos específicos. Recursos multicloud ainda podem precisar de outra camada de autorização.
Não há benchmark independente de tempo de desenvolvimento poupado ou taxa de defeitos de permissão evitados. Padrões produtivos para usuários realmente distintos, fluxos mistos auditáveis, escopos finos e consentimento claro seriam evidências melhores que o rótulo GA. Incidentes de token, expansão de escopos e bugs de fallback apontariam o contrário.
O lançamento reduz uma barreira à produção, mantendo visível a escolha central: quais operações pertencem ao app e quais à pessoa? Seu valor depende de preservar a diferença quando SQL, agentes, arquivos e serviços externos se tornam um produto, não de tratar o usuário autenticado como credencial ilimitada.
Fontes e leitura relacionada
Anúncio GA Databricks; modelo de autorização Apps; prévia de março de 2025; orientação OBO Microsoft; leitura sobre bases técnicas pesquisáveis; níveis de permissão Apps; acesso orientado por identidade Google.