Databricks publicó un patrón de producción para Genie Agents que enruta la aplicación de gobernanza a través de Unity Catalog en lugar de la capa del modelo. El patrón rechaza directamente lo que Databricks llama una "apuesta peligrosa": confiar en ingeniería de prompts e instrucciones de LLM para restringir lo que retorna un agente.
El principio central es credential passthrough. Genie Agents se ejecutan con la identidad del usuario final, no con una cuenta de servicio con permisos amplios. Cada consulta se ejecuta bajo los privilegios de objeto existentes del usuario, políticas ABAC, filtros de fila y máscaras de columna. El agente no puede retornar filas que el usuario no puede ver—sin necesidad de ingeniería de prompts.
La sincronización de identidad utiliza Automatic Identity Management (AIM), que sincroniza usuarios, grupos y service principals de Microsoft Entra ID u Okta. El aprovisionamiento just-in-time significa que un usuario que accede por primera vez llega con las membresías del grupo IdP ya adjuntas. Cuando un empleado se mueve entre unidades organizacionales, la actualización de IdP se propaga y su próxima consulta Genie refleja el nuevo alcance de acceso. Desactivarlos en IdP revoca todo acceso Genie inmediatamente.
El grounding estructurado cubre el inventario completo de activos de Unity Catalog: Managed Tables, External Tables, Foreign Tables, Views, Metric Views, Materialized Views y Streaming Tables. Metric Views codifican métricas de negocio—fórmulas de ingresos, cálculos de KPI—una vez en YAML para que cada consumidor, humano o agente, las compute idénticamente. Foreign Tables extienden el patrón a sistemas federados sin copiar datos. Cuatro controles en capas aplican acceso: Object Privileges controlan SELECT en recursos; políticas ABAC determinan qué reglas se aplican a qué atributos de usuario; Row Filters restringen filas retornadas en tiempo de consulta; Column Masks ofuscan valores en la capa de datos.
Los datos no estructurados fluyen a través de Unity Catalog Volumes, permitiendo que un único agente responda a través de tablas estructuradas y colecciones de documentos—PDFs, registros, archivos no estructurados—sin una canalización RAG separada fuera del límite de gobernanza. Los controles de acceso de Volume reflejan los controles de consulta de tabla.
La mayoría de las implementaciones de agentes empresariales otorgan al agente un service principal con permisos amplios y filtran las salidas a través de system prompt. Esto hace que el LLM sea el perímetro de seguridad. Databricks es directa: decirle a un auditor que los datos restringidos están protegidos por system prompt no es un control defendible. Los modelos pueden ser manipulados. La inyección de prompt es real.
La restricción es que este patrón requiere que la gobernanza de Unity Catalog ya esté bien configurada. AIM y ABAC solo aplican lo que existen definiciones de identidad y política. Arquitectos implementando agentes en entornos Databricks con privilegios de objeto inconsistentes o grupos obsoletos exponen esas brechas inmediatamente. El agente fielmente aplica cualquier política de acceso que exista—correcta o no. Este patrón no es un atajo de gobernanza; es un multiplicador de gobernanza.
Trate la pregunta del perímetro de seguridad como una decisión de diseño de primera clase, no un parche. Si la respuesta de su agente a "¿qué puede ver este usuario?" vive en un system prompt, su modelo de amenaza es incorrecto.