Databricks publicou um padrão de produção para Genie Agents que roteia toda aplicação de governança através do Unity Catalog em vez da camada do modelo. O padrão rejeita diretamente o que Databricks chama de "aposta perigosa": confiar em engenharia de prompts e instruções de LLM para restringir o que um agente retorna.

O princípio central é credential passthrough. Genie Agents executam com a identidade do usuário final, não com uma conta de serviço com permissões amplas. Cada consulta é executada sob os privilégios de objeto existentes do usuário, políticas ABAC, filtros de linha e máscaras de coluna. O agente não pode retornar linhas que o usuário não consegue ver—sem necessidade de engenharia de prompts.

A sincronização de identidade usa Automatic Identity Management (AIM), que sincroniza usuários, grupos e service principals do Microsoft Entra ID ou Okta. O provisionamento just-in-time significa que um usuário pela primeira vez chega com as memberships dos grupos IdP já anexadas. Quando um funcionário se move entre unidades organizacionais, a atualização do IdP se propaga e sua próxima consulta Genie reflete o novo escopo de acesso. Desativá-lo no IdP revoga todo acesso Genie imediatamente.

O grounding estruturado cobre o inventário completo de ativos do Unity Catalog: Managed Tables, External Tables, Foreign Tables, Views, Metric Views, Materialized Views e Streaming Tables. Metric Views codificam métricas de negócio—fórmulas de receita, cálculos de KPI—uma vez em YAML para que cada consumidor, humano ou agente, compute-as identicamente. Foreign Tables estendem o padrão para sistemas federados sem copiar dados. Quatro controles em camadas aplicam acesso: Object Privileges controlam SELECT em recursos; políticas ABAC determinam quais regras se aplicam a quais atributos de usuário; Row Filters restringem linhas retornadas no tempo de consulta; Column Masks reduzem valores na camada de dados.

Dados não estruturados fluem através de Unity Catalog Volumes, permitindo que um único agente responda através de tabelas estruturadas e coleções de documentos—PDFs, logs, arquivos não estruturados—sem um pipeline RAG separado fora do limite de governança. Controles de acesso de Volume espelham controles de consulta de tabela.

A maioria das implementações de agentes corporativos concedem ao agente um service principal com permissões amplas e filtram saídas via system prompt. Isso torna o LLM o perímetro de segurança. Databricks é direta: dizer a um auditor que dados restritos são protegidos por system prompt não é um controle defensável. Modelos podem ser manipulados. Injeção de prompt é real.

A restrição é que esse padrão requer que a governança do Unity Catalog já esteja bem configurada. AIM e ABAC apenas aplicam o que definições de identidade e política existem. Arquitetos implantando agentes em ambientes Databricks com privilégios de objeto inconsistentes ou grupos obsoletos revelam essas lacunas imediatamente. O agente fielmente aplica quaisquer políticas de acesso que existam—corretas ou não. Este padrão não é um atalho de governança; é um multiplicador de governança.

Trate a questão do perímetro de segurança como uma decisão de design de primeira classe, não um remendo. Se a resposta do seu agente para "o que este usuário pode ver?" vive em um system prompt, seu modelo de ameaça está errado.