Obsidian Security、AIエージェントのアクションを制御するランタイムポリシーエンジンを発表

Obsidian Securityは、AIエージェントがビジネスアプリケーション内で実行するアクションを、実行前に企業が制御できるようにするランタイムポリシー判定エンジンを発表した。この発表では、MCPセキュリティプロキシ、ポリシー判定API、コーディングツールおよびサードパーティ製ソフトウェアに組み込まれたエージェントへの対応範囲拡大を通じて、同社のエージェントセキュリティプラットフォームが強化される。

今回の発表は、通常のアクセス制御だけでは十分に解決できない問題に対処するものだ。エージェントは有効な認証情報を持ち、承認済みのアプリケーションを使用していても、不適切なアクションを試みることがある。たとえば、顧客記録の閲覧が許可されていても、それを外部の送信先にエクスポートする権限まであるとは限らない。

Obsidianのアプローチでは、エージェントの背後にいる人物、その雇用状況と権限、対象のアプリケーション、顧客が提供するデータ分類を考慮し、提案されたアクションを一元管理されたポリシーに照らして評価する。接続された強制適用ポイントがその後、アクションを許可またはブロックし、その機能に対応している場合は承認を要求する。

エージェントの検出からアクションの制御へ

エージェントの検出によって、どのツールが存在し、何にアクセスできるかが分かる。ガバナンスによって、不要な権限を減らしたり、リスクのある設定を特定したりできる。ランタイムポリシーが対処するのは、残された問いだ。ほかの点では認可されているエージェントに、今この時点で何を許可すべきか。

Obsidianの発表は、従業員が操作するエージェントと、企業がすでに利用しているソフトウェアに組み込まれたエージェントの両方を対象としている。拡充された検出・ガバナンス機能は、Salesforce Agentforce、Databricks、GitHub、Microsoft 365、Snowflake、ServiceNow、Workdayに対応する。

これらはそれぞれ異なる制御ポイントだ。SaaSアプリケーション内でエージェントを検出できても、そのアプリケーション内のすべてのアクションが傍受されるとは限らない。ランタイムでの強制適用は、対応するインテグレーションと、アクションが通過するポイントによって決まる。

同社は、既存のコーディングエージェント向け制御に加え、OpenAI Codexのランタイムポリシー対応も追加した。発表では、破壊的なコマンド、認証情報の露出、プロジェクトで想定された範囲外の読み取りなどのリスクを挙げている。これらのアクションは、通常の正当な開発セッション中にも発生し得る。

Knowledge Graphが不足するコンテキストを補う

ゲートウェイはリクエストを検査できるが、リクエストだけでは、その背後にある権限の根拠が分からない場合がある。適切なセキュリティ判断を下すには、リクエストを実行したアカウントが従業員と請負業者のどちらに属するのか、雇用関係が終了しているのか、対象のアプリケーションでそのアカウントが実際にどの権限を持つのかを把握する必要がある。

ObsidianのKnowledge Graphアーキテクチャは、人、アカウント、アプリケーション、トークン、権限付与と、それらの関係を結び付ける。同社によると、管理用API、アクティビティストリーム、インテグレーションから得た情報を共通モデルに正規化し、バージョン管理されたエンティティと関係によって、時間の経過に伴う変化を捉える。

この構造により、各アカウントを個別に調べるのではなく、複数のシステムにまたがるアクセスをたどりやすくなる。エージェントの表向きの役割は限定的でも、トークンや継承された権限によって、別の場所ではより広い範囲にアクセスできる場合がある。こうした関係を結び付けることで、ポリシーエンジンは特定のアクションが組織のルールに適合するかどうかを、より確かな根拠に基づいて判断できる。

顧客は、分類ラベルなど、独自のコンテキストを追加できる。そのためポリシーは、セキュリティベンダーの汎用的な機密データの定義だけに頼るのではなく、通常のファイルと、企業が極めて機密性の高いものとして指定したファイルとを区別できる。

判定が強制適用される仕組み

このアーキテクチャでは、判断と実行を分離している。Obsidianのランタイムエンジンの解説によると、強制適用ポイントは提案された操作を一時停止し、その詳細を評価のために送信したうえで、返された判定と理由を適用する。

新しいポリシー判定APIは、この仕組みを顧客が運用するゲートウェイ、エージェントハーネス、ワークフローにも拡張する。企業は既存のインフラを維持したまま、コンテキストを考慮した判定をObsidianに求められる。その後、操作が進む前に、顧客側の強制適用コンポーネントがその判定を適用する必要がある。

Obsidianは、操作をブロックする前に、実際のトラフィックに対してポリシーに該当するかをテストするためのフラグモードについても説明している。判定記録には、エージェント、リクエストを実行した人物、ツール、引数、結果、該当したポリシーが記録されるため、セキュリティチームはアクションが許可または停止された理由を調査できる。

承認機能の対応範囲は、許可またはブロックを行うアーキテクチャ全体よりも限定的だ。同社の現行ドキュメントによると、操作前に実行されるClaude Codeのポリシーでは、承認を必須にできる。さまざまなエージェントが混在する環境の制御を設計するうえで、インテグレーションごとの機能が重要になる。

MCPプロキシがAIクライアントからアプリケーションのトークンを隔離

MCPセキュリティプロキシは、AIクライアントと対応する業務アプリケーション間の接続を管理します。Model Context Protocol（MCP）は、エージェントが外部サーバーによって公開されたツールを呼び出すための標準的な方法を提供します。Obsidianは、クライアントとアプリケーションのMCPサーバーの間にポリシーチェックを設けています。

製品ドキュメントによると、ベンダーのMCP URLに直接接続する方式を、Obsidianが管理するエンドポイントに置き換えます。ユーザーはアプリケーションベンダーの同意フローを通じてアクセスを許可し、AIクライアントはアプリケーションのアクセストークンを自ら保存する代わりに、プロキシが発行するトークンを受け取ります。

プロキシは、セッションをユーザー、そのアプリケーションアカウント、および該当するテナント（特定のSalesforce組織やワークスペースなど）に関連付けます。ツール呼び出しを転送する前にチェックし、許可またはブロックのいずれとなったかを記録します。Obsidianによると、この仕組みは共有サービスアカウントを通じて権限を追加するのではなく、ユーザーがアプリケーションですでに持っている権限の範囲内で動作します。

発表では、Cloudflareおよび同社のMCP Server Portalとの協業も明らかにされています。その目的は、ゲートウェイがトラフィック経路上に位置することによる機能と、Obsidianが持つアイデンティティ、アプリケーション、データに関するコンテキストを組み合わせることです。

アクション単位の制御が重要な理由

エージェントを導入する企業にとって、実務上の課題は、有用な作業を可能にしながら、重大なミスを防ぐことです。一律に禁止すればワークフロー全体が止まる可能性があります。一方、対象を絞った判断なら、日常的な読み取りは許可しつつ、権限のないデータのエクスポートを阻止したり、破壊的な変更に確認を求めたりできます。

Obsidianは、こうした判断を、対応ツールや適用ポイント全体で共有するポリシーレイヤーに集約しています。その価値は、基盤となるアクセスコンテキストの質と、制御対象となる経路をどれだけ網羅できるかに左右されます。エージェントが担う業務上の責任が増すにつれて、実行前に判断の理由を説明し、その判断を適用する能力は、企業セキュリティにおいてますます重要な要素となります。