同一个销售助手，可以回答区域经理和全国负责人，却不应让他们看到完全相同的企业数据。难点在于，问题离开界面、变成 SQL、模型调用或代理工具操作之后，这种差别是否仍然存在。
Databricks 在2026年10月7日将 Apps 用户授权正式发布，此前已公开预览超过18个月。代表用户授权（OBO）让受支持请求以登录者身份执行，不再让每项操作都经过应用自己的服务主体。已有 Unity Catalog 控制可以跟随用户进入请求。这能够实质减少重复的策略代码，但不表示委托授权自动让应用安全。
正式版新增身份路径，而非取代应用身份
Databricks Apps 在无服务器基础设施上运行数据应用、仪表板、运营工具和自定义代理。每个已部署应用获得专属服务主体，即拥有该实例授权的非人类身份。这种应用授权依旧适合共享配置、遥测、维护和自动化任务。
用户授权增加另一条路径。对于由已认证用户发起的受支持操作，Databricks 将访问令牌转发至运行时，应用再以该用户权限调用获准的 Databricks API。其 OAuth 2.0 模型区分用户到机器的委托，与机器到机器的任务。
访问受治理数据时，Unity Catalog 会评估已有授权、行过滤器和列掩码。仓库权限另外决定查询能否执行。区域经理可看到一个地区，全国负责人看到更多，两人仍使用同一应用路径。后续请求依据更新的目录策略评估，而不是依据应用另存的一份规则。
这避免了一种常见偏差：共享应用身份向后端提供单一权限集，开发者再用角色、映射、中间件或其他策略服务重建每名员工应获得的结果。这些办法可以有效，但目录授权改变而本地映射未改时，就可能泄露信息或拒绝合法访问。
Apps OBO 公开预览始于2025年3月26日，涵盖 Unity Catalog 表和模型服务端点等资源。正式发布意味着在文档限制内可用于生产，并不意味着每个云、区域、工作区、合规配置或下游 API 都普遍支持。原报道还提到，面向启用合规安全配置文件工作区的支持曾计划于2026年9月下旬推出；客户仍需确认自身环境。
应用可以用自身身份读取共享指令和记录指标，再以当前用户身份访问客户和销售记录。身份认证确定是谁在场，授权决定该身份能在下游做什么。混淆两者，会错过此次发布真正改变的部分。
用户已有权限与应用范围必须同时满足
应用提出请求，不代表用户就能访问表或仓库。用户必须原本就具备所需资源权限。与此同时，开发者还要声明 API 权限范围，限制应用能够代表该用户执行哪些类别的操作。
这是两道独立边界。范围不会给用户新增数据授权，只会约束应用如何行使既有权限。Databricks 为只读 SQL 分析提供 sql:restricted-query，可作为当前用户提交受限查询，而不获得广泛的仓库管理或无关行政操作权限。
这对高权限用户尤其重要。高管或管理员可能合理地访问许多敏感数据集，但权限范围狭窄的应用，不应继承其能够直接行使的全部能力。即使用户自身权限广，应用可执行的操作仍应受限。
工作区管理员还控制开发者可添加的范围上限。允许列表可以包括所有受支持 API、选定范围，或者完全不开放用户授权。公告称默认设置可能包含全部受支持 API，因此这是一项治理选择，不能据此推断默认基线已经足够严格。
这个看似明确的上限还有重要例外。账户管理员可以添加工作区列表排除的范围。撤回之前允许的范围，也不会立即停止已有应用：它们可以继续运行。但受影响的应用在移除不获允许的范围之前，后续无法启动、部署或更新。
因此，修改允许列表不等于立刻撤销所有正在运行的使用。管理员需要掌握已部署应用、范围责任人及业务依赖，理解过渡状态，避免下一次部署意外受阻。受限基线加上有记录的例外通道，比认为配置本身已解决所有执行问题更可靠。
令牌属于一次请求，不属于整个代理
应用必须区分用户范围客户端与应用范围客户端。受治理的交互查询应走用户路径；共享配置和必须在无用户会话时继续的工作，应走权限适当受限的应用路径。分离依赖和处理程序，比让通用客户端隐藏实际主体，更容易发现误用凭据。
若某条路径要求用户授权却没有转发令牌，就应拒绝请求。静默回退到服务主体，可能在完全不同的权限下生成技术上有效的答案，访问范围比预期更宽或更窄，而用户看不到身份已切换。
转发令牌不应打印、写入日志或持久保存。对于通过 Apps 部署的自定义代理，Databricks 要求在当前 invoke 或 stream 处理程序内初始化用户范围工作区客户端。令牌仅在请求运行期间存在，而不是在应用全局启动阶段存在。
一个代理进程能够服务多人。将用户身份当作全局状态，会造成请求上下文缺失或混用。多步骤流程可能先以应用身份取得共享指令，再以用户身份查询受治理财务数据，最后用应用身份写入一般遥测，而不保存用户凭据。每次切换都需要明确主体与范围。
长时间或延迟任务又构成另一道边界。用户发起的任务可能超出请求生命周期，但这不授权开发者保存转发令牌。属于应用的工作需要范围有限的服务主体；必须维持用户上下文的工作，要采用另一种文档支持的委托方式，而非留存凭据。
OBO 也不会自动贯穿每项外部集成。下游服务必须支持该模型，并可能需要独立凭据、同意、范围和审计控制。令牌有特定受众与用途；Microsoft OBO 指南同样警告不要把中间层令牌转给非预期接收方。这是受限委托，不是对整条工具链的无限身份模拟。
能打开应用，不代表能读取它的数据
Databricks Apps 不是匿名公共应用模式。用户必须认证，外部协作者也须通过受支持的身份联合接入。它自然面向采用托管身份的员工和伙伴，而非不受限制的匿名访客。
在这些用户中，CAN USE 与 CAN MANAGE 决定谁能运行或管理应用，不授予其底层表、记录或仓库的访问权。某人可以获准打开应用，却得到数据访问被拒或受限的响应。反过来，获得表权限，也不必然有权打开应用。
因此，这些控制必须与 Unity Catalog 授权分开审查。界面可能将正确使用委托的 SQL 结果，与意外以应用身份执行的文件结果合并。平台执行无法保证开发者为每条代码路径分配了预期身份。
代理会解释开放式问题、选择工具并跨步骤组装查询，使风险扩大。检索内容中的提示注入可能诱导披露或不适当操作。OBO 将数据访问限制在当前用户权限内，但有效身份或只读范围，都不能证明每条获准查询符合用户意图。
同意也无法替代管理员审查。用户可能在不了解服务和结果如何组合的情况下批准范围。输入处理、工具约束、输出控制与运行监控仍然必要，包括观察异常查询、反复拒绝、非预期数据量及应用行为变化。
仅用管理员测试会掩盖缺陷，因为该账户很少遇到拒绝。具有区域权限、更广权限和无表权限的用户能揭示不同结果，返回数据与拒绝行为都要验证。Databricks 建议治理变化后重复测试。日志应区分应用操作与代个人执行的操作，但不记录持有者令牌或敏感响应内容。
减少策略副本，也增加平台依赖
委托无法修复来源授权过宽。群组、目录权限、仓库访问、行过滤器与掩码仍需准确维护。可搜索的技术知识库可将威胁模型、授权决策和审查证据与实现文档一起保存，但文档本身不是权限执行。
Databricks 的差异在于把委托身份与自身受治理数据、SQL 和应用运行时整合，而不是发明委托。Microsoft 已为各类 API 记录 OBO；Google 的身份感知访问侧重托管应用和上下文策略；AWS 则提供自定义系统可组合的授权组件。各方案在平台与开发者之间分配不同集成责任。
若数据已由 Unity Catalog 治理，Databricks 方案可以减少安全团队与应用框架之间的规则转换工作。代价是更紧密依赖 Databricks 特有范围与身份行为。多云资源仍可能需要另一层授权。
尚无独立基准证明具体节省了多少开发时间，或企业避免权限缺陷的比例。服务真实不同用户的生产模式、可审计的混合服务流程、更细范围与更清晰的同意体验，比正式版标签更有说服力。令牌事故、范围膨胀或身份回退漏洞则会削弱其价值。
此次发布降低了一道生产采用门槛，却仍把关键架构选择留在眼前：哪些操作属于应用，哪些属于个人？其价值取决于 SQL、代理、文件与外部服务被组合成一个产品后，能否继续维持这条界线，而非将登录用户视为无限制凭据。
来源与相关阅读
Databricks 正式发布公告；Apps 授权模型；2025年3月预览记录；Microsoft OBO 指南；可搜索技术知识库相关阅读；Apps 权限级别；Google 身份感知访问。