El mismo asistente comercial puede responder a un responsable regional y a un ejecutivo nacional sin mostrarles los mismos datos de la empresa. Lo difícil es preservar esa diferencia cuando una solicitud sale de la interfaz y se convierte en SQL, una llamada al modelo o una acción de herramienta de un agente.
Databricks hizo generalmente disponible la autorización de usuarios de Apps el 7 de octubre de 2026, tras más de 18 meses de vista previa pública. La autorización en nombre del usuario, OBO, ejecuta solicitudes compatibles con la identidad de la persona conectada, en lugar de pasar todo por el principal de servicio de la aplicación. Los controles existentes de Unity Catalog pueden acompañarla. Reduce políticas duplicadas, pero delegar no hace automáticamente segura una aplicación.
Una segunda vía de identidad llega a producción
Databricks Apps ejecuta aplicaciones de datos, paneles, herramientas operativas y agentes personalizados en infraestructura sin servidor. Cada aplicación desplegada recibe un principal de servicio dedicado: identidad no humana con permisos concedidos a esa instancia. Esa autorización sigue siendo útil para configuración común, telemetría, mantenimiento y trabajo automatizado.
La autorización de usuario añade otra vía, sin sustituir la anterior. Para una acción compatible iniciada por una persona autenticada, Databricks reenvía un token al entorno de ejecución. La aplicación llama a una API aprobada con los permisos de esa persona. El modelo OAuth 2.0 distingue delegación usuario-máquina y trabajo máquina-máquina.
En datos gobernados, Unity Catalog evalúa concesiones existentes, filtros de filas y máscaras de columnas. Los permisos del almacén determinan por separado si la consulta puede ejecutarse. Un responsable regional ve un territorio y uno nacional más, por la misma ruta de aplicación. Las solicitudes posteriores siguen políticas actualizadas del catálogo, no una copia independiente de la aplicación.
Se evita así una desviación frecuente. Una identidad compartida presenta al backend un conjunto de derechos; los desarrolladores reconstruyen los resultados de cada empleado mediante roles, correspondencias, middleware u otro servicio de políticas. Esos controles pueden funcionar, pero cambiar el catálogo sin actualizar la correspondencia local puede exponer información o negar acceso legítimo.
La vista previa pública de Apps OBO comenzó el 26 de marzo de 2025 e incluyó tablas Unity Catalog y endpoints de servicio de modelos. GA indica preparación para producción dentro de límites documentados, no soporte universal de toda nube, región, espacio de trabajo, perfil de cumplimiento o API posterior. La fuente menciona una expansión anunciada para finales de septiembre de 2026 a espacios con perfil de seguridad de cumplimiento; los clientes aún deben confirmar su entorno.
La aplicación puede leer instrucciones comunes y registrar métricas con identidad propia, y consultar clientes y ventas como usuario actual. La autenticación establece quién está presente; la autorización determina qué puede hacer después. Confundirlas pierde la contribución principal del lanzamiento.
Permisos del usuario y ámbitos de la aplicación deben coincidir
Una solicitud de la aplicación no da acceso automático a una tabla o almacén. La persona ya necesita los derechos del recurso. Los desarrolladores también declaran ámbitos API que limitan las categorías de operación realizadas en su nombre.
Son dos fronteras. Un ámbito no crea una concesión de datos, sino que limita el ejercicio del acceso existente. Databricks documenta sql:restricted-query para análisis SQL de solo lectura: consultas restringidas como usuario actual, sin amplia administración de almacenes ni tareas administrativas ajenas.
Esto importa especialmente para personas privilegiadas. Un ejecutivo o administrador puede acceder legítimamente a muchos conjuntos sensibles, pero una aplicación restringida no debería heredar todas sus capacidades directas. Los ámbitos reducen operaciones aunque los permisos personales sean amplios.
Los administradores del espacio fijan otro techo a los ámbitos añadidos por desarrolladores. La lista puede permitir todas las API compatibles, ámbitos elegidos o ninguna autorización de usuario. Según el anuncio, el valor predeterminado puede incluir todas las API. Es una decisión de gobernanza, no prueba de una base restrictiva.
Hay excepciones importantes. Los administradores de cuenta pueden añadir ámbitos excluidos por la lista del espacio. Retirar un ámbito antes permitido tampoco detiene inmediatamente aplicaciones existentes: pueden seguir ejecutándose. Sin embargo, después no pueden iniciarse, desplegarse ni actualizarse hasta eliminar el ámbito prohibido.
Cambiar la lista no equivale, por tanto, a revocar al instante todo uso en curso. Inventarios de aplicaciones, responsables de ámbitos y dependencias empresariales permiten entender la transición y evitar bloqueos inesperados en el siguiente despliegue. Una base limitada con excepciones documentadas es más útil que suponer que la configuración resuelve toda aplicación de políticas.
Los tokens pertenecen a una solicitud, no al agente entero
El código debe separar clientes de usuario y de aplicación. Las consultas interactivas gobernadas corresponden a la vía de usuario; configuración común y trabajo sin sesión, a una vía de aplicación debidamente limitada. Dependencias y controladores distintos hacen más visible el uso accidental de credenciales que un cliente genérico que oculta su principal.
Si una ruta exige autorización de usuario y falta el token reenviado, debe rechazar la solicitud. Volver silenciosamente al principal de servicio puede producir una respuesta técnicamente válida con permisos completamente distintos, más amplios o estrechos. La persona podría no ver indicación del cambio.
Los tokens reenviados nunca deben imprimirse, registrarse ni conservarse. Para agentes personalizados en Apps, Databricks exige inicializar el cliente de espacio de trabajo del usuario dentro del controlador invoke o stream activo. El token existe durante la solicitud, no durante el inicio global de la aplicación.
Un proceso de agente atiende a muchas personas. La identidad como estado global puede perder o mezclar contextos. Un flujo puede buscar instrucciones comunes como aplicación, consultar finanzas gobernadas como usuario y volver a la aplicación para telemetría general, sin guardar sus credenciales. Cada transición exige principal y ámbito explícitos.
Las tareas largas o diferidas añaden una frontera. Que una persona inicie trabajo que dura más que la solicitud no autoriza a guardar el token. El trabajo de aplicación necesita un principal de servicio limitado. El que requiere contexto del usuario debe utilizar otro patrón delegado documentado y compatible, no conservar la credencial.
OBO tampoco atraviesa automáticamente toda integración externa. El servicio posterior debe admitir el modelo y puede necesitar credenciales, consentimiento, ámbitos y auditoría separados. Los tokens tienen audiencia y finalidad concretas; Microsoft también advierte contra retransmitir tokens intermedios a destinatarios indebidos. Es delegación limitada, no suplantación ilimitada de toda la cadena.
Abrir la aplicación no autoriza a leer sus datos
Databricks Apps no es un modelo de aplicación pública anónima. Los usuarios deben autenticarse y los colaboradores externos incorporarse mediante federación compatible. El público natural son empleados y socios con identidades gestionadas, no visitantes anónimos sin restricciones.
CAN USE y CAN MANAGE determinan quién ejecuta o administra la aplicación. No conceden tablas, registros ni almacenes subyacentes. Alguien puede abrirla y recibir datos denegados o limitados. Inversamente, una concesión de tabla no permite necesariamente abrir la aplicación.
Estos controles requieren revisión separada de las concesiones Unity Catalog. Una respuesta SQL correctamente delegada puede combinarse en pantalla con un archivo solicitado por error como aplicación. La plataforma no garantiza que los desarrolladores asignen la identidad prevista a cada ruta de código.
Los agentes amplifican el riesgo al interpretar preguntas abiertas, elegir herramientas y construir consultas sucesivas. Una inyección de prompts en contenido recuperado puede fomentar divulgación o acciones inadecuadas. OBO limita los datos a los derechos actuales, pero identidad válida y ámbito de lectura no prueban que cada consulta responda a la intención de la persona.
El consentimiento tampoco sustituye la revisión administrativa. Las personas pueden aprobar ámbitos sin entender cómo se combinarán servicios y resultados. Manejo de entradas, restricciones de herramientas, controles de salida y supervisión siguen siendo necesarios: consultas extrañas, denegaciones repetidas, volúmenes inesperados y cambios de comportamiento.
Probar solo como administrador oculta defectos porque esa cuenta encuentra pocas denegaciones. Usuarios regionales, de acceso amplio y sin tabla muestran resultados diferentes; deben comprobarse datos y rechazos. Databricks recomienda repetir tras cambios de gobernanza. Los registros distinguen acciones de la aplicación y de personas sin guardar tokens de portador ni respuestas sensibles.
Menos copias de políticas, mayor dependencia de plataforma
Delegar no corrige concesiones excesivas en origen. Grupos, privilegios de catálogo, acceso a almacenes, filtros y máscaras necesitan mantenimiento exacto. Una base técnica con búsqueda puede preservar modelos de amenazas, decisiones y pruebas de revisión junto a documentos de implementación, pero documentar no equivale a aplicar controles.
Databricks se distingue por integrar delegación con sus datos gobernados, SQL y entorno de ejecución, no por inventar el principio. Microsoft ya documenta OBO entre API. El acceso consciente de identidad de Google enfatiza aplicaciones alojadas y contexto; AWS ofrece componentes de autorización para sistemas propios. Cada enfoque reparte de forma distinta el trabajo de integración.
Si los datos ya están gobernados en Unity Catalog, Databricks puede reducir la traducción de políticas entre seguridad y frameworks de aplicaciones. La contrapartida es depender más de ámbitos y comportamientos específicos. Los recursos multinube aún pueden necesitar otra capa de autorización.
No hay benchmark independiente del tiempo de desarrollo ahorrado o la frecuencia de defectos evitados. Patrones de producción para usuarios realmente distintos, flujos mixtos auditables, ámbitos finos y consentimiento claro serían pruebas mejores que la etiqueta GA. Incidentes de tokens, proliferación de ámbitos y fallos de cambio de identidad señalarían lo contrario.
El lanzamiento reduce una barrera de producción manteniendo visible la decisión central: ¿qué operaciones pertenecen a la aplicación y cuáles a la persona? Su valor depende de mantener la diferencia cuando SQL, agentes, archivos y servicios externos se vuelven un producto, no de tratar al usuario conectado como credencial ilimitada.
Fuentes y lecturas relacionadas
Anuncio GA Databricks; modelo de autorización Apps; vista previa de marzo de 2025; guía OBO Microsoft; lectura sobre bases técnicas con búsqueda; niveles de permisos Apps; acceso consciente de identidad Google.