La autorización de usuarios de Databricks Apps ya está disponible de forma general, pero los límites de identidad siguen siendo importantes
Databricks puso a disposición general la autorización de usuarios de Databricks Apps el 7 de octubre, tras más de 18 meses en vista previa pública. La función permite que una aplicación llame a servicios compatibles de la plataforma usando la identidad del usuario que ha iniciado sesión. Esto cambia una decisión de seguridad fundamental para las aplicaciones de datos y los agentes de IA: ¿qué permisos rigen cada solicitud?
Hasta ahora, los desarrolladores solían depender del principal de servicio de una aplicación, una identidad no humana asignada a una instancia de aplicación. Todos los usuarios podían recibir resultados a través de esa identidad compartida, salvo que los desarrolladores recrearan dentro de la aplicación las reglas de acceso a nivel de usuario. El nuevo modelo permite que las políticas existentes de Unity Catalog acompañen al usuario en una solicitud de la aplicación.
Esta promesa conlleva una salvedad importante. La autorización en nombre del usuario, u OBO, no hace que una aplicación sea segura de forma predeterminada. Los desarrolladores deben separar las acciones impulsadas por usuarios del trabajo en segundo plano, solicitar ámbitos restringidos, proteger los tokens reenviados y rechazar solicitudes cuando falte la identidad esperada.
El anuncio sitúa a Databricks en una competencia más amplia entre la autorización administrada por la plataforma y la lógica de permisos administrada por las aplicaciones. Microsoft admite la identidad delegada mediante su propio flujo OBO, mientras que otras plataformas en la nube ofrecen componentes independientes de identidad y políticas. Databricks vincula este patrón directamente con datos empresariales gobernados, almacenes SQL, agentes y aplicaciones que se ejecutan en su plataforma.
La autorización de usuarios de Databricks Apps cambia quién rige cada solicitud
La versión GA ofrece a los desarrolladores una forma compatible de conservar los permisos de datos existentes de un usuario durante toda una solicitud de la aplicación.
Databricks Apps aloja aplicaciones de datos, herramientas operativas, paneles y agentes personalizados en infraestructura sin servidor. Cada aplicación implementada recibe un principal de servicio dedicado que puede acceder a los recursos concedidos a esa aplicación. Esta autorización de aplicación sigue disponible y continúa siendo adecuada para operaciones compartidas o automatizadas.
La autorización de usuarios añade una segunda vía de identidad. Cuando una persona que ha iniciado sesión inicia una acción compatible, Databricks reenvía un token de acceso al entorno de ejecución de la aplicación. La aplicación puede entonces llamar a una API aprobada de Databricks bajo la identidad y los permisos de esa persona.
El modelo de autorización de la plataforma utiliza OAuth 2.0, el protocolo estándar para el acceso delegado. Distingue entre la autorización de usuario a máquina y la autorización de máquina a máquina. La primera representa a un usuario interactivo, mientras que la segunda representa una aplicación o una carga de trabajo automatizada.
A continuación, Unity Catalog evalúa las concesiones existentes del usuario cuando la aplicación accede a datos gobernados. Los filtros de filas pueden restringir qué registros aparecen, mientras que las máscaras de columnas pueden ocultar o transformar campos sensibles. Los permisos de los almacenes también determinan si el usuario puede ejecutar la consulta solicitada.
El resultado depende de la persona que realiza la solicitud. Un gerente regional de ventas podría recibir datos de un territorio, mientras que un líder nacional ve todas las regiones. Ambas personas pueden usar la misma aplicación y la misma ruta de solicitud sin recibir un acceso idéntico.
Este comportamiento importa porque la aplicación no necesita una copia independiente de cada regla de gobernanza. Cuando un administrador modifica una política de Unity Catalog, las solicitudes posteriores de la aplicación se evalúan según la política actualizada. Los desarrolladores evitan mantener un sistema de autorización paralelo que puede alejarse de los controles de la plataforma.
Databricks introdujo por primera vez la autorización OBO para Apps en vista previa pública el 26 de marzo de 2025. La versión de vista previa abarcaba recursos como tablas de Unity Catalog y endpoints de servicio de modelos. La disponibilidad general indica que Databricks considera ahora que el patrón está listo para su adopción en producción dentro de los límites documentados.
La disponibilidad general no elimina la autorización de aplicación. Databricks presenta explícitamente ambos modelos como complementarios. Una aplicación puede usar su propia identidad para la configuración compartida, la telemetría o el mantenimiento rutinario, y después usar la identidad de la persona actual para una consulta gobernada.
Considérese un asistente de información de ventas que responde preguntas sobre el rendimiento de las cuentas. La identidad de su aplicación podría leer la configuración común y registrar métricas operativas. La vía de identidad del usuario consultaría los registros de clientes y ventas disponibles para el empleado solicitante.
Esta división es la base de la versión. La aplicación sigue teniendo una identidad, pero esa identidad ya no necesita convertirse en una puerta de acceso universal para cada acción interactiva. Los desarrolladores pueden decidir qué principal rige cada operación.
Por tanto, el cambio aborda más que el inicio de sesión. La autenticación establece quién está presente, mientras que la autorización determina qué puede hacer esa identidad. La autorización de usuarios de Databricks Apps lleva la segunda decisión a las llamadas posteriores de datos y servicios.
La verdadera presión recae sobre el control de acceso administrado por la aplicación
Databricks cuestiona la práctica de reconstruir los permisos de datos empresariales dentro de cada aplicación.
Una aplicación que utiliza solo un principal de servicio compartido suele ver un conjunto de permisos uniforme. Los desarrolladores deben decidir entonces qué resultados puede recibir cada empleado. Esto normalmente requiere roles personalizados, asignaciones de políticas, lógica de filtrado u otro servicio de autorización.
Estos controles pueden funcionar, pero introducen una segunda fuente de verdad. Un equipo de gobernanza puede actualizar una concesión de Unity Catalog mientras la asignación de roles local de una aplicación permanece sin cambios. La discrepancia resultante puede exponer información o denegar acceso legítimo.
La autorización de usuarios reduce esta duplicación para los recursos compatibles de Databricks. Los permisos establecidos de la persona solicitante pasan a formar parte del contexto de ejecución. El código de la aplicación puede centrarse en la tarea solicitada mientras la plataforma evalúa el acceso gobernado.
Esto importa cada vez más para los agentes de IA. Un panel convencional expone vistas y consultas predefinidas. Un agente puede interpretar lenguaje abierto, elegir herramientas, elaborar consultas y recuperar información en varios pasos.
Esta flexibilidad amplía el número de vías por las que se puede acceder a datos protegidos. Un desarrollador no puede anticipar de manera fiable todas las preguntas que podría hacer un empleado. Preservar el contexto de autorización del empleado proporciona a la plataforma posterior otro límite de aplicación.
La presión es especialmente clara cuando las organizaciones llevan prototipos a producción. Las primeras demostraciones suelen ejecutarse bajo una credencial de desarrollador o una cuenta de servicio con permisos amplios. Este atajo se vuelve difícil de defender cuando una aplicación llega a empleados con distintas funciones, territorios y requisitos de confidencialidad.
Una sola aplicación puede atender a ventas, finanzas, operaciones y ejecutivos. Estos grupos no deberían heredar automáticamente la misma visión de los detalles de clientes, las previsiones o la información de empleados. Las políticas centralizadas se vuelven más valiosas a medida que se amplía la audiencia.
Databricks también reduce la fricción entre los administradores de gobernanza y los equipos de aplicaciones. Los equipos de seguridad pueden seguir administrando los privilegios de datos mediante Unity Catalog. Los desarrolladores no necesitan traducir cada política a middleware específico de un framework.
Eso no elimina el trabajo de desarrollo. Los equipos aún deben decidir si una operación concreta corresponde al usuario o a la aplicación. También deben entender qué API de Databricks admiten OBO y qué ámbitos de autorización requiere cada acción.
Las plataformas alternativas no carecen de identidad delegada. El flujo OBO de Microsoft transmite la identidad y los permisos delegados de un usuario desde una API ascendente a una API descendente. Google Cloud proporciona acceso a aplicaciones consciente de la identidad, mientras que AWS ofrece componentes de autorización detallada para aplicaciones personalizadas.
Databricks se diferencia mediante la integración con su entorno de gobernanza de datos. La decisión de autorización está vinculada a los permisos de Unity Catalog, el acceso SQL y los servicios compatibles de la plataforma. Esto puede reducir el trabajo de integración para aplicaciones cuyos datos ya residen en Databricks.
La contrapartida es una mayor dependencia de la plataforma. Las aplicaciones creadas en torno a las reglas de Unity Catalog y los ámbitos específicos de Databricks heredan controles útiles, pero también quedan estrechamente alineadas con el modelo de identidad de una sola plataforma. Los equipos multicloud quizá sigan necesitando otra capa de autorización para recursos fuera de Databricks.
Para los compradores empresariales, por tanto, la cuestión no es si la identidad delegada existe en otros lugares. Es si Databricks puede simplificar lo suficiente el desarrollo de aplicaciones gobernadas como para mantener más datos y cargas de trabajo de IA dentro de su plataforma.
Cómo la autorización en nombre del usuario crea dos límites de permisos
Una solicitud OBO solo tiene éxito dentro de los permisos del usuario y del ámbito de API aprobado de la aplicación.
El primer límite se refiere a los datos y recursos. Un usuario no puede acceder a una tabla de Unity Catalog, un almacén SQL o un servicio compatible simplemente porque una aplicación lo solicite. La persona ya debe contar con los permisos necesarios.
El segundo límite se refiere a la aplicación. Los desarrolladores declaran ámbitos de API, que definen las clases de operaciones que una aplicación puede realizar para un usuario. Un ámbito no concede a la persona acceso a nuevos datos, pero limita cómo puede la aplicación ejercer el acceso existente.
Para análisis SQL de solo lectura, Databricks documenta un ámbito sql:restricted-query. La aplicación puede enviar consultas restringidas como el usuario actual sin recibir autoridad amplia para administrar almacenes o realizar tareas administrativas no relacionadas.
Estos límites interconectados respaldan el principio de mínimo privilegio, la práctica de conceder solo el acceso necesario para una tarea. Un usuario con muchos privilegios podría acceder directamente a numerosos conjuntos de datos. Una aplicación con un ámbito restringido debería seguir sin poder ejercer todos los privilegios que posee ese usuario.
Los administradores del espacio de trabajo controlan un límite superior adicional. Pueden determinar qué ámbitos de autorización de usuarios pueden añadir los desarrolladores a las aplicaciones del espacio de trabajo. La lista de permitidos puede incluir todas las API compatibles, ámbitos seleccionados o ninguna autorización de usuarios.
Esta estructura divide la responsabilidad. El desarrollador solicita las capacidades mínimas necesarias para el producto. El administrador decide qué capacidades pueden solicitar los desarrolladores de aplicaciones dentro del espacio de trabajo.
Sin embargo, un administrador no puede depender únicamente de la configuración. Databricks afirma que los administradores de cuenta pueden añadir ámbitos incluso cuando una lista de permitidos del espacio de trabajo los excluye. Las aplicaciones existentes también pueden seguir ejecutándose después de que se elimine un ámbito permitido.
Según el anuncio, una aplicación afectada no puede posteriormente iniciarse, implementarse ni actualizarse hasta que se elimine el ámbito no permitido. Este comportamiento evita una interrupción inmediata, pero crea un período en el que la ejecución actual y la política actual no coinciden por completo.
Por ello, los equipos deben tratar los cambios de ámbitos como eventos operativos gobernados. Los administradores necesitan un inventario de las aplicaciones implementadas, los ámbitos solicitados, los propietarios responsables y las dependencias empresariales. Eliminar una capacidad sin ese contexto puede retrasar la corrección o dejar una aplicación varada durante su siguiente implementación.
El código de la aplicación también debe mantener separadas las dos identidades. Un cliente con ámbito de usuario debe gestionar las operaciones interactivas gobernadas. Un cliente con ámbito de aplicación debe gestionar la configuración compartida, las métricas y el trabajo que debe continuar sin una sesión de usuario.
Esto es más que una preferencia de nomenclatura. Un cliente genérico puede ocultar qué identidad está ejecutando una ruta sensible. Las dependencias, pruebas y controladores de solicitudes separados facilitan detectar el uso involuntario de credenciales.
La regla más estricta se refiere a la ausencia de tokens de usuario. Si una ruta requiere autorización del usuario, pero no hay un token reenviado, la aplicación debe denegar el acceso de forma predeterminada. Debe rechazar la solicitud en lugar de cambiar silenciosamente a su principal de servicio.
Una alternativa podría generar una respuesta técnicamente válida bajo permisos completamente distintos. El usuario tendría pocos motivos para sospechar que la aplicación accedió a información más amplia o más restringida de lo previsto. Eso hace que los cambios silenciosos de identidad sean especialmente peligrosos.
El token reenviado debe existir únicamente durante la solicitud activa. Databricks recomienda a los desarrolladores no imprimirlo, registrarlo ni conservarlo nunca. Los trabajos en segundo plano deben utilizar la autorización de la aplicación en lugar de retener el token de un usuario una vez finalizada la sesión interactiva.
Para los equipos que desarrollan herramientas internas de IA, esta separación de identidades debe acompañar a otros controles de ingeniería. Una base de conocimientos técnicos con capacidad de búsqueda puede preservar decisiones de autorización, modelos de amenazas y evidencia de revisión junto a la documentación de implementación.
Los agentes de IA dificultan mantener el límite de identidad
Los agentes se benefician de permisos específicos por usuario, pero su comportamiento de varios pasos hace que los errores de identidad tengan consecuencias más graves.
Databricks afirma que los agentes personalizados implementados mediante Apps pueden utilizar el mismo modelo de autorización. El cliente de workspace con alcance de usuario debe inicializarse dentro del controlador activo invoke o stream. El token reenviado solo está disponible mientras se ejecuta la solicitud.
Esta restricción temporal evita que los desarrolladores traten la identidad del usuario como un estado global de la aplicación. Un proceso de agente puede atender a muchas personas, y el inicio de la aplicación no corresponde a ningún usuario en particular. Crear un cliente con alcance de usuario demasiado pronto puede provocar la ausencia o mezcla del contexto de la solicitud.
Los flujos de trabajo de los agentes también combinan distintos tipos de tareas. Un paso podría recuperar instrucciones compartidas mediante la identidad de la aplicación. Otro podría consultar datos financieros gobernados como el usuario. Un tercero podría escribir telemetría general sin conservar la credencial del usuario.
Cada transición implica una decisión de autorización. Los desarrolladores deben identificar el principal, el alcance, el recurso y el modo de fallo previsto para cada llamada de herramienta. Un único cliente genérico de agente puede difuminar esas distinciones.
El desafío aumenta cuando un agente llama a otro servicio. OBO puede preservar el contexto del usuario solo cuando la integración descendente admite ese modelo. Las API externas pueden requerir credenciales, consentimiento, ámbitos y controles de auditoría independientes.
El agente no debe asumir que la autorización se transfiere automáticamente a través de toda la cadena de herramientas. Un token se emite para una audiencia y un propósito determinados. La guía de OBO de Microsoft también advierte contra la retransmisión de tokens de nivel intermedio a destinatarios no previstos.
Esto significa que la autorización del usuario no debe describirse como una suplantación generalizada. La aplicación actúa en nombre del usuario únicamente dentro de los ámbitos configurados y las rutas de solicitud admitidas. Esta formulación importa porque «actuar como el usuario» puede sugerir de otro modo un acceso sin restricciones.
La inyección de prompts ofrece otro motivo de cautela. Un atacante podría incluir instrucciones en contenido que un agente recupera, animándolo a llamar herramientas o divulgar información. OBO limita los datos accesibles al usuario actual, pero no determina si una acción solicitada tiene sentido.
Los propios permisos del usuario también pueden ser amplios. Un ejecutivo, administrador o analista podría tener acceso a conjuntos de datos sensibles de muchas funciones empresariales. Una aplicación comprometida que utiliza la identidad válida de esa persona sigue representando un riesgo grave.
Los ámbitos proporcionan un importante segundo límite en esa situación. Un ámbito de consulta de solo lectura puede impedir una administración no relacionada, pero no puede decidir si cada consulta permitida responde a la intención del usuario. Las aplicaciones aún necesitan manejo de entradas, restricciones de herramientas, controles de salida y supervisión.
El consentimiento también merece escrutinio. Los usuarios pueden aprobar los permisos solicitados sin comprender cómo un agente combinará servicios o procesará resultados. Los nombres claros de los ámbitos ayudan, pero el consentimiento no sustituye la revisión administrativa ni un comportamiento restringido de la aplicación.
La auditabilidad se vuelve esencial. Los equipos de seguridad deben distinguir entre acciones realizadas por la identidad de la aplicación y acciones realizadas en nombre de una persona. Los registros deben identificar el principal y la operación relevantes sin almacenar tokens de portador ni contenido sensible de las respuestas.
Las pruebas deben involucrar a usuarios con permisos diferentes. Una prueba realizada únicamente con una cuenta de administrador puede ocultar errores, ya que esa cuenta rara vez encuentra denegaciones de acceso. Databricks recomienda repetir las pruebas después de que cambien las políticas de gobernanza.
Los casos de prueba útiles incluyen un usuario con acceso regional, un usuario con acceso más amplio y una persona que carece por completo de acceso a la tabla consultada. Los equipos deben verificar tanto los datos devueltos como el comportamiento de rechazo. También deben confirmar que los tokens ausentes nunca activen una alternativa de identidad de aplicación.
Por tanto, la limitación central es clara. La autorización de usuarios de Databricks Apps puede aplicar los permisos existentes de la plataforma, pero no puede corregir concesiones excesivamente amplias. Las organizaciones deben seguir manteniendo grupos precisos, privilegios de catálogo, acceso a warehouses, filtros de filas y máscaras de columnas.
La promesa de seguridad depende de la disciplina operativa
La parte más sólida del diseño es su modelo de control por capas, mientras que su punto más débil sigue siendo la implementación y la gobernanza en torno a ese modelo.
Databricks puede reenviar la identidad adecuada y aplicar los ámbitos declarados. No puede garantizar que cada equipo de desarrollo asigne la identidad correcta a cada ruta de código. Esa decisión permanece dentro de la arquitectura de la aplicación.
Un equipo podría utilizar correctamente OBO para una consulta SQL, pero emplear accidentalmente la identidad de la aplicación para una solicitud de archivo relacionada. La interfaz de usuario podría combinar ambas respuestas sin revelar los distintos contextos de autorización.
El procesamiento en segundo plano presenta otro límite. Un usuario podría iniciar una tarea de larga duración que continúe después de que termine la solicitud. Dado que el token reenviado pertenece a una solicitud activa, los desarrolladores no pueden simplemente conservarlo para ejecutarlo más tarde.
El diseño más seguro consiste en determinar si el trabajo diferido pertenece a la aplicación o requiere otro patrón delegado compatible. Si pertenece a la aplicación, el principal de servicio necesita permisos cuidadosamente limitados. Si requiere contexto de usuario, los desarrolladores deben seguir el comportamiento documentado de la plataforma en lugar de conservar el token.
La disponibilidad en todos los entornos también requiere confirmación. La documentación de Databricks cambia a medida que se amplían los servicios y las configuraciones de cumplimiento. Los equipos deben verificar la compatibilidad con la nube, región, workspace y perfil de seguridad antes de tratar la disponibilidad general como disponibilidad universal.
Las propias Apps no pueden ser aplicaciones públicas anónimas. Databricks afirma que los usuarios deben autenticarse, y los colaboradores externos requieren incorporación mediante federación de identidad compatible. Esto hace que el modelo sea más natural para escenarios de empleados y socios con identidades gestionadas.
La separación entre permisos de aplicaciones y autorización de datos puede confundir a los revisores. CAN USE y CAN MANAGE determinan quién puede ejecutar o administrar una aplicación. No determinan a qué tablas o registros puede acceder una persona a través de ella.
Una persona podría tener permiso para utilizar una aplicación y, al mismo tiempo, carecer de permiso para consultar sus datos subyacentes. Esa solicitud debería fallar o devolver resultados limitados. A la inversa, el acceso a los datos por sí solo no concede necesariamente permiso para abrir la aplicación.
Por lo tanto, los niveles de permisos documentados requieren revisiones separadas de las concesiones de Unity Catalog. Tratarlos como un único control puede generar una falsa sensación de seguridad durante las auditorías.
Las listas de permisos de ámbitos administrativos introducen otra tarea de gobernanza. Según el anuncio, el valor predeterminado puede incluir todas las API compatibles. Las organizaciones centradas en la seguridad deben decidir si ese valor predeterminado encaja con su modelo de desarrollo antes de adoptar ampliamente las aplicaciones.
Reducir la lista de permisos puede disminuir el riesgo, pero también puede bloquear productos legítimos. El proceso adecuado combina una base restringida con una vía documentada de excepciones. De lo contrario, los equipos pueden buscar identidades de aplicación más amplias para evitar las restricciones de ámbito.
También existe un desafío de detección. Una aplicación puede solicitar únicamente ámbitos aprobados y aun así comportarse de forma incorrecta dentro de ellos. La supervisión en tiempo de ejecución debe examinar patrones de consulta inusuales, denegaciones repetidas, volúmenes de datos inesperados y cambios en el comportamiento de la aplicación.
Actualmente, ningún benchmark independiente establece cuánto tiempo de desarrollo ahorra la función ni con qué eficacia las empresas evitan defectos de permisos. El anuncio de disponibilidad general explica el mecanismo y las prácticas recomendadas, pero los resultados de adopción aún están por demostrarse.
Databricks también tiene un incentivo para convertir su capa de gobernanza en la base predeterminada de las aplicaciones y agentes internos. Los compradores deben evaluar ese beneficio estratégico junto con la portabilidad, el esfuerzo de integración y la madurez de sus sistemas de autorización existentes.
La comparación pertinente no es una competición simplista entre Databricks y Microsoft. El patrón de identidad delegada de Microsoft es maduro y ampliamente aplicable en distintas API. Databricks está empaquetando un principio relacionado en torno a sus propios datos, cómputo, gobernanza y tiempo de ejecución de aplicaciones.
El acceso consciente de la identidad de Google se centra en controlar el acceso a aplicaciones alojadas y políticas contextuales. AWS ofrece componentes de autorización que los desarrolladores pueden combinar con proveedores de identidad y recursos de aplicaciones. Cada enfoque asigna trabajo diferente a la plataforma y al equipo de aplicaciones.
Las organizaciones deben comparar dónde residen las políticas, qué recursos cubren, cómo cruzan las identidades los límites entre servicios y cómo aparecen las denegaciones ante los usuarios. También deben comprobar si los registros de auditoría conectan claramente una acción tanto con la aplicación como con la persona que la inició.
La etiqueta de disponibilidad general reduce una barrera para la adopción, pero no resuelve esas cuestiones arquitectónicas. La función resulta más convincente cuando la gobernanza de datos ya reside en Unity Catalog y la aplicación llama principalmente a servicios de Databricks compatibles.
Tres señales mostrarán si el lanzamiento de disponibilidad general cumple lo prometido
La próxima prueba es si las empresas pueden adoptar aplicaciones conscientes del usuario sin ampliar el riesgo de tokens, la complejidad de políticas ni la dependencia de la plataforma.
La primera señal es la adopción en producción entre agentes internos y aplicaciones operativas. Databricks ha descrito un escenario claro de información comercial, pero los despliegues reales implicarán combinaciones más complejas de SQL, modelos, archivos, dashboards y servicios externos.
La evidencia de una adopción madura incluiría patrones de arquitectura repetibles, implementaciones de referencia y flujos de auditoría claros. También incluiría aplicaciones que atiendan a usuarios con permisos significativamente distintos sin duplicar esas reglas en el código.
Una adopción débil sugeriría que los ámbitos compatibles, los servicios descendentes o los procesos organizativos siguen siendo demasiado limitados. Los equipos podrían seguir utilizando principales de servicio con permisos amplios o productos de autorización independientes pese a la opción de disponibilidad general.
La segunda señal es la ampliación y el perfeccionamiento de los ámbitos de API compatibles. Los ámbitos restringidos facilitan el diseño de mínimo privilegio porque los desarrolladores pueden solicitar una capacidad sin recibir autoridad no relacionada.
Los ámbitos más amplios pero imprecisos debilitarían el segundo límite de permisos. Ámbitos más granulares, mejores controles administrativos y experiencias de consentimiento más claras reforzarían la afirmación de Databricks de que las aplicaciones pueden actuar en nombre de los usuarios sin excederse.
Los cambios en la compatibilidad con perfiles de cumplimiento también son importantes. Databricks indicó que la autorización de usuarios llegaría a los espacios de trabajo con el perfil de seguridad de cumplimiento a finales de septiembre de 2026. Los clientes deben confirmar la disponibilidad y las limitaciones en sus propios entornos.
La tercera señal es cómo los competidores integran la identidad delegada en sus plataformas de agentes. Microsoft ya documenta OBO para API convencionales y escenarios más recientes de agentes alojados. Otras plataformas también están conectando la identidad del usuario, el uso de herramientas, los motores de políticas y los entornos de ejecución de aplicaciones gestionados.
Si esas alternativas exigen una integración personalizada considerable, Databricks obtiene una ventaja para las aplicaciones construidas en torno a datos empresariales gobernados. Si los competidores ofrecen una herencia de políticas igual de directa entre las herramientas de datos y de agentes, los compradores se centrarán más en la portabilidad y el alcance del ecosistema.
Los desarrolladores deberían observar la evidencia operativa, no el lenguaje de los anuncios. Los incidentes de gestión de tokens, los flujos de consentimiento confusos, la proliferación de ámbitos y los errores de respaldo de identidad debilitarían el argumento. Auditorías claras y una menor carga de mantenimiento de autorizaciones lo reforzarían.
La tarea inmediata de ingeniería es sencilla de plantear, aunque requiere disciplina para ejecutarla. Asigne cada operación de la aplicación a la identidad de la aplicación o a la identidad del usuario actual. Otorgue el ámbito más restringido, rechace las credenciales ausentes y pruebe con usuarios realmente distintos.
Los equipos también deberían revisar los permisos existentes de Unity Catalog antes de exponerlos mediante un agente. OBO aplica fielmente esos permisos, incluidos aquellos que ya son más amplios de lo previsto. La delegación no puede mejorar una política de origen débil.
Por tanto, la autorización de usuarios de Databricks Apps es relevante porque acerca la gobernanza consciente de la identidad a los datos y al entorno de ejecución de aplicaciones. Sustituye parte de la lógica de permisos duplicada por la aplicación de políticas de la plataforma, al tiempo que conserva una identidad de aplicación para el trabajo compartido.
Su éxito dependerá de que los desarrolladores mantengan ese límite cuando las aplicaciones se vuelvan complejas. Antes de implementar el próximo asistente interno, formule una pregunta para cada ruta de solicitud: ¿debería esta operación ejecutarse como la aplicación o como la persona que la utiliza?
