エンタープライズ AI プロジェクトには痛みを伴う真実がある: 多くのチームはモデル品質に夢中になり、アカウンタビリティを無視する。エージェントが本番データを書き込んだり読み取ったりしたとき、最初のインシデントレビューの質問は「回答は良かったか？」ではない。「実際にこれをやったのは誰か？」である。
オリジナルソース: https://devblogs.microsoft.com/azure-sql/sql-mcp-server-obo-auth/
これこそが、Data API builder 2.0 と SQL MCP Server における OBO サポートが、一見した以上に重要である理由である。ユーザー名/パスワードとマネージド ID のアプローチは運用上は機能するが、どちらも ID をサービス境界に崩壊させる。ログにはアプリまたはミドルウェアが表示され、人間のリクエスト発信元は表示されない。それは単純な自動化には許容できる。規制対象のエージェンティックワークフローには許容できない。
OBO を使用すると、SQL は委任されたユーザーコンテキストを認証し、ツールホスト ID は認証しない。これにより、根本的により優れた監査モデルが得られる: ユーザープリンシパル、アクション、ステートメントコンテキスト、ミドルティアアプリ識別子がすべて揃う。MCP ツールと DAB エンティティ権限の制御サーフェスを失うことなく、トレーサビリティを得られる。
私の意見は固い: エージェントが機密 SQL データに触れることができるなら、OBO をデフォルトのアーキテクチャにすべきであり、オプションの強化タスクにしてはならない。セットアップはより複雑だが、ID 負債は常に後で支払われる。通常はセキュリティインシデント、コンプライアンス監査、またはエグゼクティブエスカレーションのときである。
実践的な実装ガイダンス
- 最小限の「WhoAmI」ビューと統合テストの自動チェックで ID フローを検証することから始める。 SQL プリンシパルがサインインユーザーと一致しない場合、出荷前に停止して修正する。
- SQLSecurityAuditEvents の Log Analytics クエリを SOC ダッシュボードに配線し、OBO パスを通じて開始された高リスクアクションにアラートを設定する。
- RBAC と DAB 権限を整合させ、ユーザーレベルの ID とアクションレベルの認可がエンドツーエンドで一貫するようにする。
アナウンスメントにおける微妙だが重要な設計ポイントのひとつは、キャッシュ動作である。DAB は、ユーザー委任認証が有効な場合、レスポンスキャッシングを明示的にブロックする。そのトレードオフは正しい。ユーザースコープの結果を漏洩させる可能性のあるパフォーマンストリックは、マルチテナントまたは規制環境では価値がない。
SQL MCP Server と OBO は、成熟したパターンの始まりである: 制御されたオペレーターとしてのエージェント、アカウンタブルなプリンシパルとしてのユーザー、監査可能なシステムとしてのデータプレーン。アーキテクチャが「誰がこれをやったか」に自信を持って答えられないなら、そのデモがどんなに洗練されていても、それはプロダクション対応の AI ではない。
