Databricks Appsのユーザー認可がGAに、ただしアイデンティティ境界は依然重要

Databricksは10月7日、18カ月以上にわたるパブリックプレビューを経て、Databricks Appsのユーザー認可を一般提供した。この機能により、アプリケーションはサインイン中のユーザーのアイデンティティを用いて、対応するプラットフォームサービスを呼び出せるようになる。これは、データアプリケーションやAIエージェントにおける根本的なセキュリティ判断、すなわち各リクエストを誰の権限で統制するかを変えるものだ。

これまで開発者は、1つのアプリインスタンスに割り当てられる非人間のアイデンティティであるアプリケーションのサービスプリンシパルに依存することが多かった。開発者がアプリケーション内でユーザーレベルのアクセスルールを再実装しない限り、すべてのユーザーがその共有アイデンティティを通じて結果を取得できた。新しいモデルでは、既存のUnity Catalogポリシーを、アプリケーションリクエスト内のユーザーに引き継げる。

ただし、この利点には重要な条件がある。ユーザー代理認可、すなわちOBOは、アプリケーションをデフォルトで安全にするものではない。開発者はユーザー主導の操作とバックグラウンド処理を分離し、スコープを必要最小限に絞り、転送されるトークンを保護し、想定したアイデンティティが存在しない場合にはリクエストを拒否しなければならない。

今回の発表は、プラットフォーム管理型の認可とアプリケーション管理型の権限ロジックをめぐる、より広範な競争の中にDatabricksを位置付けるものでもある。Microsoftは独自のOBOフローを通じて委任アイデンティティをサポートしており、他のクラウドプラットフォームもアイデンティティとポリシーのための別個のコンポーネントを提供している。Databricksはこのパターンを、自社プラットフォーム上で動作するガバナンス対象のエンタープライズデータ、SQLウェアハウス、エージェント、アプリケーションへ直接結び付けている。

Databricks Appsのユーザー認可は各リクエストの統制主体を変える

GAリリースにより、開発者はアプリケーションリクエスト全体でユーザーの既存データ権限を維持するためのサポートされた方法を利用できるようになった。

Databricks Appsは、データアプリケーション、業務ツール、ダッシュボード、カスタムエージェントをサーバーレスインフラストラクチャ上でホストする。デプロイされた各アプリには専用のサービスプリンシパルが割り当てられ、アプリケーションに付与されたリソースへアクセスできる。このアプリ認可は引き続き利用可能であり、共有処理や自動化処理に適している。

ユーザー認可は第2のアイデンティティ経路を追加する。サインイン中のユーザーが対応するアクションを開始すると、Databricksはアクセス用トークンをアプリケーションランタイムへ転送する。アプリはその後、その人物のアイデンティティと権限に基づいて、承認されたDatabricks APIを呼び出せる。

プラットフォームの認可モデルは、委任アクセスの標準プロトコルであるOAuth 2.0を使用する。このモデルは、ユーザーからマシンへの認可と、マシン間の認可を区別する。前者は対話型ユーザーを表し、後者はアプリケーションまたは自動化ワークロードを表す。

アプリがガバナンス対象データにアクセスすると、Unity Catalogはユーザーに既存で付与されている権限を評価する。行フィルターは表示されるレコードを制限でき、列マスクは機密フィールドを隠したり変換したりできる。ウェアハウス権限も、ユーザーが要求されたクエリを実行できるかどうかを決定する。

結果は、リクエストを行う人物によって異なる。地域営業マネージャーは1つの担当地域のデータを受け取り、全国責任者はすべての地域を確認できる可能性がある。両者は同じアプリケーションとリクエスト経路を使用しても、同一のアクセス権限を得るわけではない。

この動作が重要なのは、アプリがガバナンスルールを個別に複製する必要がないためだ。管理者がUnity Catalogポリシーを変更すると、その後のアプリリクエストは更新後のポリシーに照らして評価される。開発者は、プラットフォームの統制から乖離しかねない並行した認可システムを保守せずに済む。

Databricksは2025年3月26日、Apps向けOBO認可をパブリックプレビューとして初めて導入した。プレビューリリースでは、Unity Catalogテーブルやモデルサービングエンドポイントなどのリソースが対象となった。一般提供は、文書化された制限の範囲内で、Databricksがこのパターンを本番導入に適したものと見なしていることを示している。

GAはアプリ認可を不要にするものではない。Databricksは両モデルを補完的なものとして明確に位置付けている。アプリケーションは共有設定、テレメトリー、定常的な保守には独自のアイデンティティを使用し、ガバナンス対象クエリには現在のユーザーのアイデンティティを使用できる。

アカウントパフォーマンスに関する質問へ回答する営業インサイトアシスタントを考えてみよう。アプリのアイデンティティは共通設定の読み取りと運用メトリクスの記録に利用できる。ユーザーアイデンティティ経路では、リクエストした従業員がアクセス可能な顧客および販売記録をクエリする。

この分離が今回のリリースの基盤である。アプリには引き続きアイデンティティがあるが、そのアイデンティティがあらゆる対話型操作の共通ゲートウェイになる必要はなくなる。開発者は、各操作をどのプリンシパルが統制するかを決定できる。

したがって、この変更はログイン以上の問題を扱う。認証は誰が存在するかを確立し、認可はそのアイデンティティに何ができるかを決定する。Databricks Appsのユーザー認可は、後者の判断を下流のデータおよびサービス呼び出しにまで持ち込む。

真の圧力はアプリケーション管理型アクセス制御にかかる

Databricksは、各アプリケーション内でエンタープライズデータ権限を再構築する慣行に挑戦している。

共有サービスプリンシパルだけを使用するアプリは、多くの場合、一貫した単一の権限セットを見ることになる。開発者はその上で、各従業員がどの結果を取得できるかを決めなければならない。通常は、カスタムロール、ポリシーマッピング、フィルタリングロジック、または別の認可サービスが必要になる。

これらの統制は機能し得るが、第2の正の情報源を持ち込むことになる。ガバナンスチームがUnity Catalogの権限付与を更新しても、アプリケーションのローカルなロールマッピングは変更されないかもしれない。その不一致は、情報の露出や正当なアクセスの拒否につながり得る。

ユーザー認可は、対応するDatabricksリソースについてこうした重複を減らす。リクエストする人物の確立済みの権限が実行コンテキストの一部となる。アプリケーションコードは要求されたタスクに集中でき、プラットフォームはガバナンス対象アクセスを評価する。

これはAIエージェントにとってますます重要になる。従来型のダッシュボードは、あらかじめ定義されたビューとクエリを公開する。エージェントは自由形式の言語を解釈し、ツールを選択し、クエリを組み立て、複数のステップにわたって情報を取得できる。

この柔軟性は、保護されたデータに到達する経路の数を増やす。開発者は、従業員が尋ねる可能性のあるすべての質問を確実に予測することはできない。従業員の認可コンテキストを維持することで、下流プラットフォームに追加の強制境界が与えられる。

組織がプロトタイプを本番環境へ移行する際、その圧力は特に明確になる。初期デモは、開発者の認証情報や広範な権限を持つサービスアカウントで実行されることが多い。異なる役割、担当地域、機密保持要件を持つ従業員へアプリが広がると、この近道を正当化することは難しくなる。

1つのアプリケーションが営業、財務、業務、経営幹部にサービスを提供することもある。これらのグループが、顧客詳細、予測、従業員情報について同じビューを自動的に継承すべきではない。対象ユーザーが広がるほど、中央ポリシーの価値は高まる。

Databricksは、ガバナンス管理者とアプリケーションチームの間の摩擦も減らしている。セキュリティチームはUnity Catalogを通じてデータ権限を管理し続けられる。開発者はすべてのポリシーをフレームワーク固有のミドルウェアへ変換する必要がない。

ただし、開発作業がなくなるわけではない。チームは、特定の操作がユーザーに属するのかアプリに属するのかを判断する必要がある。また、どのDatabricks APIがOBOに対応し、各アクションにどの認可スコープが必要かも理解しなければならない。

代替プラットフォームに委任アイデンティティがないわけではない。MicrosoftのOBOフローは、ユーザーのアイデンティティと委任された権限をアップストリームAPIからダウンストリームAPIへ渡す。Google Cloudはアイデンティティ認識型のアプリケーションアクセスを提供し、AWSはカスタムアプリケーション向けにきめ細かな認可コンポーネントを提供している。

Databricksは、データガバナンス環境との統合によって差別化を図っている。認可の判断は、Unity Catalogの権限、SQLアクセス、対応するプラットフォームサービスに結び付けられる。データがすでにDatabricks内にあるアプリケーションでは、これにより統合作業を減らせる可能性がある。

その代償は、プラットフォーム依存度の高まりだ。Unity CatalogルールとDatabricks固有のスコープを中心に構築されたアプリケーションは、有用な統制を継承する一方で、1つのプラットフォームのアイデンティティモデルと密接に整合することになる。マルチクラウドチームは、Databricks外のリソースのために別の認可レイヤーを依然として必要とする可能性がある。

したがってエンタープライズバイヤーにとっての問いは、委任アイデンティティが他の場所に存在するかどうかではない。Databricksが、より多くのデータおよびAIワークロードを自社プラットフォーム内にとどめられるほど、ガバナンス対象アプリケーションの開発を簡素化できるかどうかである。

ユーザー代理認可が2つの権限境界を作る仕組み

OBOリクエストは、ユーザーの権限とアプリケーションに承認されたAPIスコープの両方の範囲内でのみ成功する。

第1の境界はデータとリソースに関するものだ。アプリが要求したからといって、ユーザーがUnity Catalogテーブル、SQLウェアハウス、対応サービスへアクセスできるわけではない。ユーザーはすでに必要な権限を保持していなければならない。

第2の境界はアプリケーションに関するものだ。開発者はAPIスコープを宣言し、アプリがユーザーのために実行できる操作の種類を定義する。スコープはユーザーに新たなデータアクセス権を与えないが、アプリケーションが既存アクセスをどのように行使できるかを制限する。

読み取り専用のSQL分析について、Databricksはsql:restricted-queryスコープを文書化している。このアプリは、ウェアハウスを管理したり無関係な管理作業を実行したりする広範な権限を受け取ることなく、現在のユーザーとして制限付きクエリを送信できる。

こうした交差する境界は、1つのタスクに必要なアクセスだけを付与する最小権限の原則を支える。高い権限を持つユーザーは、多くのデータセットへ直接アクセスできるかもしれない。それでも、スコープが狭く設定されたアプリは、そのユーザーが持つすべての権限を行使できないようにすべきだ。

ワークスペース管理者は追加の上限を制御する。管理者は、ワークスペース内で開発者がアプリに追加できるユーザー認可スコープを決定できる。許可リストには、対応するすべてのAPI、選択したスコープ、またはユーザー認可を一切含めない設定を指定できる。

この構造は責任を分ける。開発者は、プロダクトに必要な最小限の機能を要求する。管理者は、アプリケーション開発者がワークスペース内で要求できる機能を決定する。

ただし、管理者は設定だけに依存することはできない。Databricksによると、ワークスペースの許可リストがスコープを除外していても、アカウント管理者はスコープを追加できる。また、許可されたスコープが削除された後でも、既存のアプリは実行を継続できる。

発表によれば、影響を受けるアプリは、許可されていないスコープが削除されるまで、その後の起動、デプロイ、更新を行えない。この動作は即時障害を回避するが、現在の実行状態と現在のポリシーが完全には一致しない期間を生む。

したがってチームは、スコープ変更をガバナンス対象の運用イベントとして扱うべきだ。管理者には、デプロイ済みアプリ、要求されたスコープ、責任者、業務上の依存関係のインベントリが必要になる。この文脈なしに機能を削除すると、修復を遅らせたり、次回のデプロイ時にアプリケーションを行き詰まらせたりする可能性がある。

アプリケーションコードも、2つのアイデンティティを分離して維持しなければならない。ユーザースコープのクライアントはガバナンス対象の対話型操作を処理する。アプリスコープのクライアントは共有設定、メトリクス、およびユーザーセッションなしでも継続すべき処理を扱う。

これは単なる命名上の好みではありません。汎用クライアントでは、機密性の高い処理パスをどの ID が実行しているのかが見えにくくなります。依存関係、テスト、リクエストハンドラーを分離すれば、意図しない認証情報の使用を発見しやすくなります。

最も厳格なルールは、ユーザートークンが欠けている場合に関するものです。ルートでユーザー認可が必要なのに転送されたトークンが存在しない場合、アプリケーションはフェイルクローズで動作すべきです。サービスプリンシパルに暗黙に切り替えるのではなく、リクエストを拒否する必要があります。

フォールバックは、まったく異なる権限のもとで、技術的には有効な回答を生成する可能性があります。アプリが想定より広い、あるいは狭い情報にアクセスしたことを、ユーザーが疑う理由はほとんどありません。そのため、暗黙の ID 変更は特に危険です。

転送されたトークンは、実行中のリクエストに対してのみ存在すべきです。Databricks は、開発者に対し、トークンを出力、ログ記録、永続化しないよう助言しています。バックグラウンドジョブでは、対話型セッションの終了後にユーザーのトークンを保持するのではなく、アプリ認可を使用するべきです。

社内 AI ツールを構築するチームにとって、この ID 分離は他のエンジニアリング統制と並ぶ重要事項です。検索可能な技術ナレッジベースは、認可判断、脅威モデル、レビューの証跡を、実装ドキュメントとともに保存できます。

AI エージェントは ID 境界の維持をより困難にする

エージェントはユーザー固有の権限から恩恵を得ますが、その複数ステップの動作により、ID の誤りが招く影響はより重大になります。

Databricks によれば、Apps を通じてデプロイされたカスタムエージェントでも同じ認可モデルを使用できます。ユーザースコープのワークスペースクライアントは、アクティブな invoke または stream ハンドラー内で初期化する必要があります。転送されたトークンは、リクエストの実行中にのみ利用可能です。

このタイミング上の制約により、開発者はユーザー ID をアプリケーション全体のグローバル状態として扱えなくなります。エージェントプロセスは多くの人に対応でき、アプリケーションの起動時点は特定のユーザーに属しません。ユーザースコープのクライアントを早期に作成すると、リクエストコンテキストの欠落や混在を招くおそれがあります。

エージェントのワークフローは、異なる種類の作業も組み合わせます。あるステップではアプリ ID を通じて共有の指示を取得し、別のステップではユーザーとしてガバナンス管理された財務データを照会し、さらに別のステップではユーザーの認証情報を保持せずに一般的なテレメトリーを書き込む場合があります。

それぞれの移行には認可判断が伴います。開発者は、すべてのツール呼び出しについて、プリンシパル、スコープ、リソース、予想される失敗モードを特定する必要があります。単一の汎用エージェントクライアントでは、こうした区別が曖昧になる可能性があります。

エージェントが別のサービスを呼び出す場合、課題はさらに大きくなります。OBO がユーザーコンテキストを維持できるのは、下流の統合がそのモデルをサポートしている場合に限られます。外部 API では、別個の認証情報、同意、スコープ、監査統制が必要になることがあります。

エージェントは、認可がツールチェーン全体に自動的に引き継がれると想定してはなりません。トークンは特定の対象者と目的のために発行されます。Microsoft の OBO ガイダンスも同様に、中間層のトークンを意図しない受信者へ中継しないよう警告しています。

これは、ユーザー認可を包括的ななりすましとして説明すべきではないことを意味します。アプリケーションがユーザーのために動作するのは、構成済みのスコープとサポートされるリクエストパスの範囲内に限られます。この表現は重要です。「ユーザーとして動作する」という言葉は、そうしなければ無制限のアクセスを示唆しかねません。

プロンプトインジェクションも、慎重さが必要となる別の理由です。攻撃者は、エージェントが取得するコンテンツ内に指示を埋め込み、ツールの呼び出しや情報開示を促す可能性があります。OBO はアクセス可能なデータを現在のユーザーの範囲に制限しますが、要求されたアクションが妥当かどうかを判断するものではありません。

ユーザー自身の権限が広範に及ぶ場合もあります。経営層、管理者、アナリストは、多くの業務機能にまたがる機密データセットへのアクセス権を持つ可能性があります。その人物の有効な ID を使用する侵害済みアプリは、依然として重大なリスクをもたらします。

この状況では、スコープが重要な第 2 の境界となります。読み取り専用のクエリスコープは無関係な管理操作を防止できますが、許可されたすべてのクエリがユーザーの意図に沿うかどうかは判断できません。アプリケーションには依然として、入力処理、ツール制約、出力制御、監視が必要です。

同意についても慎重に検討する必要があります。ユーザーは、エージェントがサービスをどのように組み合わせ、結果をどのように処理するかを理解しないまま、要求された権限を承認する可能性があります。明確なスコープ名は役立ちますが、同意は管理者レビューや制約されたアプリケーション動作の代替にはなりません。

監査可能性が不可欠になります。セキュリティチームは、アプリ ID により実行されたアクションと、特定の人物のために実行されたアクションを区別できなければなりません。ログでは、ベアラートークンや機密性の高いレスポンス内容を記録せずに、関連するプリンシパルと操作を特定すべきです。

テストには、異なる権限を持つユーザーを含める必要があります。管理者アカウントだけで実施したテストでは、そのアカウントがアクセス拒否に遭うことがほとんどないため、誤りが隠れてしまう可能性があります。Databricks は、ガバナンスポリシーの変更後にテストを繰り返すよう推奨しています。

有用なテストケースには、地域限定のアクセス権を持つユーザー、より広範なアクセス権を持つユーザー、照会対象のテーブルにまったくアクセスできない人物が含まれます。チームは、返されるデータと拒否時の挙動の両方を検証すべきです。また、トークンが欠落してもアプリ ID へのフォールバックが決して発生しないことを確認する必要があります。

したがって、中心的な制約は明確です。Databricks Apps のユーザー認可は既存のプラットフォーム権限を適用できますが、過度に広い権限付与を修正することはできません。組織は引き続き、正確なグループ、カタログ権限、ウェアハウスアクセス、行フィルター、列マスクを維持する必要があります。

セキュリティ上の約束は運用規律に依存する

この設計の最も強い点は階層化された統制モデルにあり、最も弱い点は依然として、そのモデルを取り巻く実装とガバナンスです。

Databricks は適切な ID を転送し、宣言されたスコープを適用できます。しかし、すべての開発チームがすべてのコードパスに正しい ID を割り当てることまでは保証できません。この判断はアプリケーションアーキテクチャの内部に残ります。

チームは SQL クエリに OBO を正しく使用していても、関連するファイルリクエストに誤ってアプリ ID を使用する可能性があります。ユーザーインターフェースは、異なる認可コンテキストを明示せずに両方のレスポンスを結合するかもしれません。

バックグラウンド処理も別の境界を提示します。ユーザーは、リクエスト終了後も継続する長時間実行タスクを開始する場合があります。転送されたトークンはアクティブなリクエストに属するため、開発者は後から実行するために単純に保存することはできません。

より安全な設計では、遅延実行される作業がアプリケーションに属するのか、別のサポートされた委任パターンを必要とするのかを判断します。アプリに属する場合、サービスプリンシパルには慎重に制限された権限が必要です。ユーザーコンテキストが必要な場合、開発者はトークンを保持するのではなく、文書化されたプラットフォームの挙動に従わなければなりません。

環境をまたぐ利用可能性についても確認が必要です。Databricks のドキュメントは、サービスやコンプライアンス構成の拡張に伴って変化します。チームは、GA を普遍的な可用性とみなす前に、クラウド、リージョン、ワークスペース、セキュリティプロファイルのサポート状況を確認すべきです。

Apps 自体を匿名のパブリックアプリケーションにすることはできません。Databricks によれば、ユーザーは認証を受ける必要があり、外部コラボレーターはサポートされる ID フェデレーションを通じてオンボーディングする必要があります。このため、このモデルは管理された ID を持つ従業員およびパートナーのシナリオに最も自然に適合します。

アプリ権限とデータ認可の分離は、レビュー担当者を混乱させることがあります。CAN USE と CAN MANAGE は、誰がアプリを実行または管理できるかを決定します。これらは、ユーザーがアプリを通じてどのテーブルやレコードにアクセスできるかを決定するものではありません。

アプリを使用する権限を持つ人物でも、基盤となるデータを照会する権限を持たない場合があります。そのリクエストは失敗するか、限定的な結果を返すべきです。逆に、データアクセス権だけでは、必ずしもアプリケーションを開く権限は付与されません。

したがって、文書化された権限レベルは、Unity Catalog の権限付与とは別にレビューする必要があります。これらを一つの統制として扱うと、監査時に誤った安心感を生む可能性があります。

管理者によるスコープ許可リストは、もう一つのガバナンス課題をもたらします。発表によれば、デフォルトではサポート対象のすべての API を含めることができます。セキュリティを重視する組織は、アプリケーションを広く導入する前に、そのデフォルトが自社の開発モデルに合致するかを判断すべきです。

許可リストを狭めればリスクを減らせますが、正当な製品を妨げる可能性もあります。適切なプロセスでは、制約されたベースラインと文書化された例外経路を組み合わせます。そうしなければ、チームはスコープ制限を回避するために、より広範なアプリ ID を求めるおそれがあります。

検出上の課題もあります。アプリは承認済みのスコープだけを要求していても、その範囲内で不適切に動作する可能性があります。ランタイム監視では、異常なクエリパターン、繰り返される拒否、想定外のデータ量、アプリケーション動作の変化を調べるべきです。

現時点では、この機能がどれほど開発時間を短縮するか、また企業が権限上の欠陥をどれほど効果的に回避できるかを示す独立したベンチマークはありません。GA の発表は仕組みと推奨プラクティスを説明していますが、導入成果はまだ実証されていません。

Databricks には、ガバナンスレイヤーを社内アプリケーションとエージェントのデフォルト基盤にしたいという動機もあります。購入者は、この戦略的な利点を、ポータビリティ、統合に要する労力、既存の認可システムの成熟度と併せて評価すべきです。

重要な比較は、単純な Databricks 対 Microsoft の競争ではありません。Microsoft の委任 ID パターンは成熟しており、API 全般に幅広く適用できます。Databricks は、関連する原則を自社のデータ、コンピュート、ガバナンス、アプリケーションランタイムを軸にパッケージ化しています。

Google のID 認識型アクセスは、ホストされたアプリケーションとコンテキストポリシーへのアクセス制御に重点を置いています。AWS は、開発者が ID プロバイダーやアプリケーションリソースと組み合わせられる認可コンポーネントを提供しています。各アプローチでは、プラットフォームとアプリケーションチームに割り当てられる作業が異なります。

組織は、ポリシーがどこに存在するか、どのリソースを対象とするか、ID がサービス境界をどう越えるか、拒否がユーザーにどう表示されるかを比較すべきです。また、監査記録がアクションをアプリケーションと開始した人物の両方に明確に結び付けているかもテストする必要があります。

GA というラベルは導入上の障壁を一つ下げますが、こうしたアーキテクチャ上の問題を解決するものではありません。この機能が最も説得力を持つのは、データガバナンスがすでに Unity Catalog にあり、アプリケーションが主にサポート対象の Databricks サービスを呼び出す場合です。

GA リリースが成果をもたらすかを示す三つのシグナル

次の試金石は、企業がトークンリスク、ポリシーの複雑さ、プラットフォームロックインを拡大せずに、ユーザー認識型アプリケーションを導入できるかどうかです。

第一のシグナルは、社内エージェントおよび業務アプリケーションにおける本番導入です。Databricks は明確な営業インサイトのシナリオを示していますが、実際のデプロイでは SQL、モデル、ファイル、ダッシュボード、外部サービスがより複雑に組み合わされます。

成熟した導入の証拠には、再利用可能なアーキテクチャパターン、リファレンス実装、明確な監査ワークフローが含まれます。また、こうしたルールをコードに重複して実装せず、実質的に異なる権限を持つユーザーにサービスを提供するアプリケーションも含まれます。

導入が進まなければ、サポートされるスコープ、下流サービス、または組織プロセスが依然として限定的すぎることを示すでしょう。チームは、GA の選択肢があるにもかかわらず、広範な権限を持つサービスプリンシパルや別個の認可製品を使い続ける可能性があります。

第二のシグナルは、サポート対象 API スコープの拡大と洗練です。きめ細かなスコープにより、開発者は無関係な権限を受け取ることなく一つの機能を要求できるため、最小権限設計が容易になります。

広範でも粗いスコープは、第 2 の権限境界を弱めます。より細分化されたスコープ、より優れた管理者統制、より明確な同意体験は、アプリが過剰な権限を得ることなくユーザーのために動作できるという Databricks の主張を強化するでしょう。

コンプライアンス・プロファイルのサポートに関する変更も重要です。Databricksは、コンプライアンス・セキュリティ・プロファイルを備えたワークスペースでのユーザー認可が、2026年9月下旬に利用可能になると示しています。顧客は、自身の環境における提供状況と制約を確認すべきです。

3つ目の注目点は、競合各社が委任されたアイデンティティをエージェント・プラットフォームへどう統合しているかです。Microsoftはすでに、従来型のAPIと新しいホステッド・エージェントのシナリオにおけるOBOを文書化しています。他のプラットフォームも、ユーザー・アイデンティティ、ツール利用、ポリシー・エンジン、管理対象アプリケーション・ランタイムを接続し始めています。

こうした代替手段に大規模なカスタム統合が必要であれば、ガバナンスの効いたエンタープライズ・データを中心に構築するアプリケーションでは、Databricksが優位に立ちます。競合がデータとエージェント用ツールをまたいで同等に直接的なポリシー継承を提供する場合、購入者はポータビリティとエコシステムの広がりをより重視するでしょう。

開発者は、発表文言ではなく運用上の証拠を注視すべきです。トークン処理のインシデント、分かりにくい同意フロー、スコープの肥大化、アイデンティティのフォールバックに関するバグは、この仕組みの価値を弱める可能性があります。明確な監査と認可維持の負担軽減は、その価値を裏付けるでしょう。

目下のエンジニアリング課題は、実行に規律を要するとはいえ、述べること自体は単純です。アプリケーションのすべての操作を、アプリのアイデンティティまたは現在のユーザーのアイデンティティのいずれかに対応付けます。最小限のスコープを割り当て、認証情報が欠けている場合は拒否し、実際に異なるユーザーでテストします。

チームは、エージェント経由で公開する前に、既存のUnity Catalog権限も見直すべきです。OBOは、意図以上に広範な権限も含め、これらの権限を忠実に適用します。委任によって、脆弱なソース・ポリシーを改善することはできません。

したがって、Databricks Appsのユーザー認可は、アイデンティティを認識するガバナンスをデータとアプリケーション・ランタイムにより近づけるという点で重要です。共有作業のためのアプリ・アイデンティティを維持しつつ、重複した権限ロジックの一部をプラットフォームによる強制へと置き換えます。

その成功は、アプリケーションが複雑化した後も開発者がこの境界を維持できるかどうかにかかっています。次の社内アシスタントを導入する前に、すべてのリクエスト経路について一つ問いかけてください。この操作はアプリケーションとして実行すべきか、それとも利用者本人として実行すべきか。