A Autorização de Usuários do Databricks Apps Agora É GA, mas os Limites de Identidade Ainda Importam
A Databricks disponibilizou de forma geral a autorização de usuários do Databricks Apps em 7 de outubro, após mais de 18 meses em prévia pública. O recurso permite que um aplicativo chame serviços de plataforma compatíveis usando a identidade do usuário autenticado. Isso altera uma decisão central de segurança para aplicações de dados e agentes de IA: quais permissões regem cada solicitação?
Até agora, os desenvolvedores frequentemente dependiam do service principal de um aplicativo, uma identidade não humana atribuída a uma instância do app. Todos os usuários podiam receber resultados por meio dessa identidade compartilhada, a menos que os desenvolvedores recriassem regras de acesso em nível de usuário dentro do aplicativo. O novo modelo permite que as políticas existentes do Unity Catalog acompanhem o usuário em uma solicitação do app.
Essa promessa traz uma ressalva importante. A autorização em nome do usuário, ou OBO, não torna um aplicativo seguro por padrão. Os desenvolvedores precisam separar ações orientadas pelo usuário de tarefas em segundo plano, solicitar escopos restritos, proteger tokens encaminhados e rejeitar solicitações quando a identidade esperada estiver ausente.
O anúncio posiciona a Databricks em uma disputa mais ampla entre a autorização gerenciada pela plataforma e a lógica de permissões gerenciada pelo aplicativo. A Microsoft oferece suporte à identidade delegada por meio de seu próprio fluxo OBO, enquanto outras plataformas de nuvem disponibilizam componentes separados de identidade e política. A Databricks está vinculando esse padrão diretamente a dados empresariais governados, data warehouses SQL, agentes e aplicativos executados em sua plataforma.
A Autorização de Usuários do Databricks Apps Muda Quem Rege Cada Solicitação
A versão GA oferece aos desenvolvedores uma forma compatível de preservar as permissões de dados existentes de um usuário ao longo de uma solicitação do aplicativo.
O Databricks Apps hospeda aplicações de dados, ferramentas operacionais, dashboards e agentes personalizados em infraestrutura serverless. Cada app implantado recebe um service principal dedicado que pode acessar os recursos concedidos a esse aplicativo. Essa autorização do app continua disponível e segue adequada para operações compartilhadas ou automatizadas.
A autorização de usuário adiciona um segundo caminho de identidade. Quando uma pessoa autenticada inicia uma ação compatível, a Databricks encaminha um token de acesso ao runtime do aplicativo. O app pode então chamar uma API aprovada da Databricks sob a identidade e as permissões dessa pessoa.
O modelo de autorização da plataforma usa OAuth 2.0, o protocolo padrão para acesso delegado. Ele diferencia a autorização de usuário para máquina da autorização de máquina para máquina. A primeira representa um usuário interativo, enquanto a segunda representa um aplicativo ou carga de trabalho automatizada.
O Unity Catalog então avalia as concessões existentes do usuário quando o app acessa dados governados. Filtros de linha podem restringir quais registros aparecem, enquanto máscaras de coluna podem ocultar ou transformar campos sensíveis. As permissões do warehouse também determinam se o usuário pode executar a consulta solicitada.
O resultado depende da pessoa que faz a solicitação. Um gerente regional de vendas pode receber dados de um território, enquanto um líder nacional vê todas as regiões. Ambas as pessoas podem usar o mesmo aplicativo e o mesmo caminho de solicitação sem receber acesso idêntico.
Esse comportamento é importante porque o app não precisa manter uma cópia separada de cada regra de governança. Quando um administrador altera uma política do Unity Catalog, solicitações posteriores do app são avaliadas com base na política atualizada. Os desenvolvedores evitam manter um sistema paralelo de autorização que pode se distanciar dos controles da plataforma.
A Databricks introduziu pela primeira vez a autorização OBO para Apps em prévia pública em 26 de março de 2025. A versão de prévia abrangia recursos como tabelas do Unity Catalog e endpoints de serving de modelos. A disponibilidade geral sinaliza que a Databricks agora considera o padrão pronto para adoção em produção dentro dos limites documentados.
A GA não elimina a autorização do app. A Databricks apresenta explicitamente os dois modelos como complementares. Um aplicativo pode usar sua própria identidade para configurações compartilhadas, telemetria ou manutenção de rotina e, em seguida, usar a identidade da pessoa atual para uma consulta governada.
Considere um assistente de insights de vendas que responde a perguntas sobre o desempenho de contas. Sua identidade de app pode ler configurações comuns e registrar métricas operacionais. Seu caminho de identidade de usuário consultaria registros de clientes e vendas disponíveis ao funcionário solicitante.
Essa divisão é a base do lançamento. O app ainda tem uma identidade, mas essa identidade não precisa mais se tornar um gateway universal para toda ação interativa. Os desenvolvedores podem decidir qual principal rege cada operação.
A mudança, portanto, aborda mais do que o login. A autenticação estabelece quem está presente, enquanto a autorização determina o que essa identidade pode fazer. A autorização de usuários do Databricks Apps leva a segunda decisão para chamadas subsequentes de dados e serviços.
A Pressão Real Recai sobre o Controle de Acesso Gerenciado pelo Aplicativo
A Databricks está questionando a prática de reconstruir permissões de dados empresariais dentro de cada aplicativo.
Um app que usa apenas um service principal compartilhado costuma enxergar um conjunto consistente de permissões. Os desenvolvedores precisam então decidir quais resultados cada funcionário pode receber. Isso geralmente exige funções personalizadas, mapeamentos de políticas, lógica de filtragem ou outro serviço de autorização.
Esses controles podem funcionar, mas introduzem uma segunda fonte de verdade. Uma equipe de governança pode atualizar uma concessão do Unity Catalog enquanto o mapeamento local de funções de um aplicativo permanece inalterado. A incompatibilidade resultante pode expor informações ou negar acesso legítimo.
A autorização de usuário reduz essa duplicação para recursos compatíveis da Databricks. As permissões estabelecidas da pessoa solicitante passam a integrar o contexto de execução. O código do aplicativo pode se concentrar na tarefa solicitada enquanto a plataforma avalia o acesso governado.
Isso importa cada vez mais para agentes de IA. Um dashboard convencional expõe visualizações e consultas predefinidas. Um agente pode interpretar linguagem aberta, escolher ferramentas, montar consultas e recuperar informações em várias etapas.
Essa flexibilidade amplia o número de caminhos pelos quais dados protegidos podem ser alcançados. Um desenvolvedor não consegue antecipar de forma confiável todas as perguntas que um funcionário pode fazer. Preservar o contexto de autorização do funcionário oferece à plataforma downstream outra fronteira de aplicação.
A pressão é especialmente evidente quando as organizações levam protótipos à produção. Demonstrações iniciais costumam ser executadas com uma credencial de desenvolvedor ou uma conta de serviço com permissões amplas. Esse atalho se torna difícil de defender quando um app alcança funcionários com diferentes funções, territórios e requisitos de confidencialidade.
Um único aplicativo pode atender vendas, finanças, operações e executivos. Esses grupos não deveriam herdar automaticamente a mesma visão de detalhes de clientes, previsões ou informações de funcionários. Políticas centralizadas se tornam mais valiosas à medida que o público se amplia.
A Databricks também está reduzindo o atrito entre administradores de governança e equipes de aplicativos. As equipes de segurança podem continuar gerenciando privilégios de dados por meio do Unity Catalog. Os desenvolvedores não precisam traduzir cada política em middleware específico de framework.
Isso não elimina o trabalho de desenvolvimento. As equipes ainda precisam decidir se uma operação específica pertence ao usuário ou ao app. Também devem entender quais APIs da Databricks oferecem suporte a OBO e quais escopos de autorização cada ação exige.
As plataformas alternativas não deixam de oferecer identidade delegada. O fluxo OBO da Microsoft transmite a identidade e as permissões delegadas de um usuário de uma API upstream para uma API downstream. O Google Cloud fornece acesso a aplicativos orientado por identidade, enquanto a AWS oferece componentes de autorização granular para aplicações personalizadas.
A Databricks se diferencia pela integração com seu ambiente de governança de dados. A decisão de autorização está vinculada às permissões do Unity Catalog, ao acesso SQL e aos serviços de plataforma compatíveis. Isso pode reduzir o trabalho de integração para aplicações cujos dados já estão na Databricks.
A contrapartida é uma dependência maior da plataforma. Aplicações construídas em torno das regras do Unity Catalog e de escopos específicos da Databricks herdam controles úteis, mas também ficam estreitamente alinhadas ao modelo de identidade de uma plataforma. Equipes multicloud ainda podem precisar de outra camada de autorização para recursos fora da Databricks.
Para compradores empresariais, portanto, a questão não é se a identidade delegada existe em outros lugares. É se a Databricks consegue simplificar suficientemente o desenvolvimento de aplicações governadas para manter mais dados e cargas de trabalho de IA em sua plataforma.
Como a Autorização em Nome do Usuário Cria Dois Limites de Permissão
Uma solicitação OBO só é bem-sucedida dentro das permissões do usuário e do escopo de API aprovado para o aplicativo.
O primeiro limite diz respeito aos dados e recursos. Um usuário não pode acessar uma tabela do Unity Catalog, um warehouse SQL ou um serviço compatível apenas porque um app o solicita. A pessoa já deve possuir as permissões necessárias.
O segundo limite diz respeito ao aplicativo. Os desenvolvedores declaram escopos de API, que definem as classes de operações que um app pode executar em nome de um usuário. Um escopo não concede à pessoa novo acesso a dados, mas limita como o aplicativo pode exercer o acesso existente.
Para análises SQL somente de leitura, a Databricks documenta o escopo sql:restricted-query. O app pode enviar consultas restritas como o usuário atual sem receber autoridade ampla para administrar warehouses ou realizar trabalho administrativo não relacionado.
Esses limites que se cruzam sustentam o princípio do menor privilégio, a prática de conceder apenas o acesso necessário para uma tarefa. Um usuário altamente privilegiado pode acessar diretamente muitos conjuntos de dados. Um app de escopo restrito ainda deve ser incapaz de exercer todos os privilégios que esse usuário possui.
Os administradores do workspace controlam um limite superior adicional. Eles podem determinar quais escopos de autorização de usuário os desenvolvedores podem adicionar a apps no workspace. A lista de permissões pode incluir todas as APIs compatíveis, escopos selecionados ou nenhuma autorização de usuário.
Essa estrutura divide a responsabilidade. O desenvolvedor solicita os recursos mínimos exigidos pelo produto. O administrador decide quais recursos os desenvolvedores de aplicativos podem solicitar dentro do workspace.
No entanto, um administrador não pode depender apenas da configuração. A Databricks afirma que administradores de conta podem adicionar escopos mesmo quando uma lista de permissões do workspace os exclui. Apps existentes também podem continuar em execução após a remoção de um escopo permitido.
Segundo o anúncio, um app afetado não poderá posteriormente iniciar, implantar nem atualizar até que o escopo não permitido seja removido. Esse comportamento evita uma interrupção imediata, mas cria um período em que a execução atual e a política atual não correspondem completamente.
Portanto, as equipes devem tratar mudanças de escopo como eventos operacionais governados. Os administradores precisam de um inventário de apps implantados, escopos solicitados, proprietários responsáveis e dependências de negócio. Remover uma capacidade sem esse contexto pode atrasar a correção ou deixar um aplicativo sem condições de operar em sua próxima implantação.
O código do aplicativo também precisa manter as duas identidades separadas. Um cliente com escopo de usuário deve tratar operações interativas governadas. Um cliente com escopo de app deve tratar configurações compartilhadas, métricas e trabalhos que precisam continuar sem uma sessão de usuário.
Isso é mais do que uma preferência de nomenclatura. Um cliente genérico pode ocultar qual identidade está executando um caminho sensível. Dependências, testes e manipuladores de solicitação separados facilitam a detecção do uso não intencional de credenciais.
A regra mais rigorosa diz respeito à ausência de tokens de usuário. Se uma rota exige autorização do usuário, mas nenhum token encaminhado está presente, o aplicativo deve falhar de forma segura. Ele deve rejeitar a solicitação em vez de alternar silenciosamente para sua entidade de serviço.
Uma alternativa de contingência pode produzir uma resposta tecnicamente válida sob permissões totalmente diferentes. O usuário teria poucos motivos para suspeitar que o aplicativo acessou informações mais amplas ou mais restritas do que o esperado. Isso torna mudanças silenciosas de identidade particularmente perigosas.
O token encaminhado deve existir apenas durante a solicitação ativa. A Databricks aconselha desenvolvedores a nunca imprimi-lo, registrá-lo em logs ou persistí-lo. Trabalhos em segundo plano devem usar a autorização do aplicativo, em vez de reter o token de um usuário após o fim da sessão interativa.
Para equipes que desenvolvem ferramentas internas de IA, essa separação de identidade deve acompanhar outros controles de engenharia. Uma base de conhecimento técnica pesquisável pode preservar decisões de autorização, modelos de ameaça e evidências de revisão ao lado da documentação de implementação.
Os Agentes de IA Tornam a Fronteira de Identidade Mais Difícil de Manter
Os agentes se beneficiam de permissões específicas do usuário, mas seu comportamento em várias etapas torna erros de identidade mais consequentes.
A Databricks afirma que agentes personalizados implantados por meio de Apps podem usar o mesmo modelo de autorização. O cliente de workspace com escopo de usuário deve ser inicializado dentro do manipulador invoke ou stream ativo. O token encaminhado fica disponível apenas enquanto a solicitação está em execução.
Essa restrição de tempo impede que desenvolvedores tratem a identidade do usuário como estado global do aplicativo. Um processo de agente pode atender muitas pessoas, e a inicialização do aplicativo não pertence a nenhum usuário específico. Criar um cliente com escopo de usuário cedo demais cria o risco de contexto de solicitação ausente ou misturado.
Os fluxos de trabalho de agentes também combinam diferentes tipos de trabalho. Uma etapa pode recuperar instruções compartilhadas por meio da identidade do aplicativo. Outra pode consultar dados financeiros governados como o usuário. Uma terceira pode gravar telemetria geral sem reter a credencial do usuário.
Cada transição cria uma decisão de autorização. Os desenvolvedores precisam identificar o principal, o escopo, o recurso e o modo de falha esperado para cada chamada de ferramenta. Um único cliente genérico de agente pode obscurecer essas distinções.
O desafio cresce quando um agente chama outro serviço. O OBO pode preservar o contexto do usuário apenas quando a integração downstream oferece suporte a esse modelo. APIs externas podem exigir credenciais, consentimento, escopos e controles de auditoria separados.
O agente não deve presumir que a autorização é transferida automaticamente por toda a cadeia de ferramentas. Um token é emitido para um público e uma finalidade específicos. As orientações da Microsoft sobre OBO também alertam contra o repasse de tokens de camada intermediária a destinatários não pretendidos.
Isso significa que a autorização do usuário não deve ser descrita como personificação irrestrita. O aplicativo age em nome do usuário apenas dentro dos escopos configurados e dos caminhos de solicitação compatíveis. Essa formulação importa porque “agir como o usuário” pode, de outro modo, sugerir acesso sem restrições.
A injeção de prompt cria outro motivo para cautela. Um invasor pode inserir instruções em conteúdos recuperados por um agente, incentivando-o a chamar ferramentas ou divulgar informações. O OBO limita os dados acessíveis ao usuário atual, mas não determina se uma ação solicitada faz sentido.
As próprias permissões do usuário também podem ser extensas. Um executivo, administrador ou analista pode ter acesso a conjuntos de dados sensíveis em diversas funções de negócio. Um aplicativo comprometido que usa a identidade válida dessa pessoa ainda representa um risco sério.
Os escopos fornecem uma segunda fronteira importante nessa situação. Um escopo de consulta somente leitura pode impedir administração não relacionada, mas não consegue decidir se cada consulta permitida atende à intenção do usuário. Os aplicativos ainda precisam de tratamento de entradas, restrições de ferramentas, controles de saída e monitoramento.
O consentimento também merece escrutínio. Usuários podem aprovar permissões solicitadas sem compreender como um agente combinará serviços ou processará resultados. Nomes claros de escopo ajudam, mas o consentimento não substitui a revisão administrativa e o comportamento restrito do aplicativo.
A auditabilidade torna-se essencial. As equipes de segurança precisam distinguir ações realizadas pela identidade do aplicativo de ações realizadas em nome de uma pessoa. Os logs devem identificar o principal e a operação relevantes sem registrar tokens de portador ou conteúdo sensível de respostas.
Os testes devem envolver usuários com permissões diferentes. Um teste realizado apenas com uma conta de administrador pode ocultar erros, pois essa conta raramente encontra negações de acesso. A Databricks recomenda repetir os testes após mudanças nas políticas de governança.
Casos de teste úteis incluem um usuário com acesso regional, um usuário com acesso mais amplo e uma pessoa que não tem acesso à tabela consultada. As equipes devem verificar tanto os dados retornados quanto o comportamento de rejeição. Também devem confirmar que tokens ausentes nunca acionam uma alternativa baseada na identidade do aplicativo.
A limitação central, portanto, é clara. A autorização de usuário do Databricks Apps pode aplicar permissões existentes da plataforma, mas não pode corrigir concessões excessivamente amplas. As organizações ainda devem manter grupos precisos, privilégios de catálogo, acesso a warehouses, filtros de linha e máscaras de coluna.
A Promessa de Segurança Depende de Disciplina Operacional
A parte mais forte do design é seu modelo de controle em camadas, enquanto a parte mais fraca continua sendo a implementação e a governança em torno desse modelo.
A Databricks pode encaminhar a identidade apropriada e aplicar os escopos declarados. Ela não pode garantir que cada equipe de desenvolvimento atribua a identidade correta a cada caminho de código. Essa decisão continua dentro da arquitetura do aplicativo.
Uma equipe pode usar OBO corretamente para uma consulta SQL, mas empregar acidentalmente a identidade do aplicativo para uma solicitação de arquivo relacionada. A interface do usuário poderia combinar ambas as respostas sem revelar os diferentes contextos de autorização.
O processamento em segundo plano apresenta outra fronteira. Um usuário pode iniciar uma tarefa de longa duração que continua após o fim da solicitação. Como o token encaminhado pertence a uma solicitação ativa, os desenvolvedores não podem simplesmente preservá-lo para execução posterior.
O design mais seguro é determinar se o trabalho adiado pertence ao aplicativo ou exige outro padrão delegado compatível. Se pertencer ao aplicativo, a entidade de serviço precisa de permissões cuidadosamente limitadas. Se exigir contexto de usuário, os desenvolvedores devem seguir o comportamento documentado da plataforma em vez de reter o token.
A disponibilidade em todos os ambientes também exige confirmação. A documentação da Databricks muda à medida que os serviços e as configurações de conformidade se expandem. As equipes devem verificar o suporte de nuvem, região, workspace e perfil de segurança antes de tratar a disponibilidade geral como universal.
Os próprios Apps não podem ser aplicativos públicos anônimos. A Databricks afirma que os usuários devem se autenticar, e colaboradores externos exigem integração por meio de federação de identidade compatível. Isso torna o modelo mais natural para cenários de força de trabalho e parceiros com identidades gerenciadas.
A separação entre permissões do aplicativo e autorização de dados pode confundir revisores. CAN USE e CAN MANAGE determinam quem pode executar ou administrar um aplicativo. Eles não determinam quais tabelas ou registros uma pessoa pode acessar por meio dele.
Uma pessoa pode ter permissão para usar um aplicativo e, ainda assim, não ter permissão para consultar seus dados subjacentes. Essa solicitação deve falhar ou retornar resultados limitados. Por outro lado, o acesso aos dados, por si só, não concede necessariamente permissão para abrir o aplicativo.
Os níveis de permissão documentados, portanto, exigem revisões separadas das concessões do Unity Catalog. Tratá-los como um único controle pode criar falsa segurança durante auditorias.
As listas de permissões de escopo administrativo introduzem outra tarefa de governança. O padrão pode incluir todas as APIs compatíveis, segundo o anúncio. Organizações conscientes da segurança devem decidir se esse padrão corresponde ao seu modelo de desenvolvimento antes de adotar amplamente os aplicativos.
Restringir a lista de permissões pode reduzir riscos, mas também pode bloquear produtos legítimos. O processo adequado combina uma linha de base restrita com um caminho documentado de exceção. Caso contrário, as equipes podem buscar identidades de aplicativo mais amplas para evitar restrições de escopo.
Há também um desafio de detecção. Um aplicativo pode solicitar apenas escopos aprovados e ainda assim se comportar incorretamente dentro deles. O monitoramento em tempo de execução deve examinar padrões de consulta incomuns, negações repetidas, volumes inesperados de dados e mudanças no comportamento do aplicativo.
Nenhum benchmark independente estabelece atualmente quanto tempo de desenvolvimento o recurso economiza ou quão eficazmente as empresas evitam defeitos de permissão. O anúncio de disponibilidade geral explica o mecanismo e as práticas recomendadas, mas os resultados de adoção ainda precisam ser demonstrados.
A Databricks também tem incentivo para tornar sua camada de governança a base padrão para aplicativos internos e agentes. Compradores devem avaliar esse benefício estratégico juntamente com portabilidade, esforço de integração e a maturidade de seus sistemas de autorização existentes.
A comparação relevante não é uma disputa simplista entre Databricks e Microsoft. O padrão de identidade delegada da Microsoft é maduro e amplamente aplicável entre APIs. A Databricks está empacotando um princípio relacionado em torno de seus próprios dados, computação, governança e ambiente de execução de aplicativos.
O acesso com reconhecimento de identidade do Google concentra-se no controle de acesso a aplicativos hospedados e políticas contextuais. A AWS oferece componentes de autorização que os desenvolvedores podem combinar com provedores de identidade e recursos de aplicativo. Cada abordagem atribui trabalhos diferentes à plataforma e à equipe de aplicativos.
As organizações devem comparar onde as políticas residem, quais recursos elas abrangem, como as identidades atravessam fronteiras de serviços e como as negações aparecem para os usuários. Também devem testar se os registros de auditoria conectam claramente uma ação tanto ao aplicativo quanto à pessoa que a iniciou.
O rótulo de disponibilidade geral reduz uma barreira à adoção, mas não resolve essas questões arquiteturais. O recurso é mais convincente quando a governança de dados já reside no Unity Catalog e o aplicativo chama principalmente serviços Databricks compatíveis.
Três Sinais Mostrarão se a Versão GA Cumpre o que Promete
O próximo teste é se as empresas conseguem adotar aplicativos conscientes do usuário sem ampliar o risco de tokens, a complexidade das políticas ou a dependência da plataforma.
O primeiro sinal é a adoção em produção entre agentes internos e aplicativos operacionais. A Databricks descreveu um cenário claro de insights de vendas, mas implantações reais envolverão combinações mais complexas de SQL, modelos, arquivos, dashboards e serviços externos.
Evidências de adoção madura incluiriam padrões de arquitetura reproduzíveis, implementações de referência e fluxos de auditoria claros. Também incluiriam aplicativos que atendam usuários com permissões significativamente diferentes sem duplicar essas regras no código.
Uma adoção fraca sugeriria que os escopos compatíveis, os serviços downstream ou os processos organizacionais continuam limitados demais. As equipes poderiam continuar usando entidades de serviço com permissões amplas ou produtos de autorização separados, apesar da opção GA.
O segundo sinal é a expansão e o refinamento dos escopos de API compatíveis. Escopos restritos tornam o design de privilégio mínimo mais fácil, porque desenvolvedores podem solicitar uma capacidade sem receber autoridade não relacionada.
Escopos mais amplos, porém grosseiros, enfraqueceriam a segunda fronteira de permissões. Escopos mais granulares, melhores controles administrativos e experiências de consentimento mais claras fortaleceriam a alegação da Databricks de que aplicativos podem agir em nome dos usuários sem extrapolar.
As mudanças no suporte a perfis de conformidade também são importantes. A Databricks indicou que a autorização de usuários chegaria aos workspaces com o perfil de segurança de conformidade no fim de setembro de 2026. Os clientes devem confirmar a disponibilidade e as limitações em seus próprios ambientes.
O terceiro sinal é como os concorrentes integram identidade delegada às suas plataformas de agentes. A Microsoft já documenta OBO para APIs convencionais e cenários mais recentes de agentes hospedados. Outras plataformas também estão conectando identidade do usuário, uso de ferramentas, mecanismos de política e runtimes de aplicações gerenciadas.
Se essas alternativas exigirem uma integração personalizada substancial, a Databricks ganhará uma vantagem para aplicações construídas em torno de dados empresariais governados. Se os concorrentes oferecerem uma herança de políticas igualmente direta entre dados e ferramentas de agentes, os compradores darão maior peso à portabilidade e ao alcance do ecossistema.
Os desenvolvedores devem acompanhar evidências operacionais, e não a linguagem dos anúncios. Incidentes no tratamento de tokens, fluxos de consentimento confusos, proliferação de escopos e bugs de fallback de identidade enfraqueceriam o argumento. Auditorias claras e menor manutenção de autorização o reforçariam.
A tarefa imediata de engenharia é simples de descrever, embora exija disciplina para ser executada. Mapeie cada operação da aplicação para a identidade do app ou para a identidade do usuário atual. Atribua o escopo mais restrito, rejeite credenciais ausentes e teste com usuários realmente diferentes.
As equipes também devem revisar as permissões existentes do Unity Catalog antes de expô-las por meio de um agente. O OBO aplica essas permissões fielmente, inclusive permissões que já são mais amplas do que o pretendido. A delegação não pode melhorar uma política de origem fraca.
A autorização de usuários no Databricks Apps é, portanto, significativa porque aproxima a governança consciente de identidade dos dados e do runtime da aplicação. Ela substitui parte da lógica de permissões duplicada pela aplicação da plataforma, preservando ao mesmo tempo uma identidade de app para o trabalho compartilhado.
Seu sucesso dependerá de os desenvolvedores manterem essa separação quando as aplicações se tornarem complexas. Antes de implantar o próximo assistente interno, faça uma pergunta para cada caminho de solicitação: esta operação deve ser executada como a aplicação ou como a pessoa que a utiliza?
