Obsidian Securityは、AIエージェントの動作を実行前に一元的に制御できる「Runtime Policy Decision Engine」を発表しました。同社はこれまで、AIエージェントの検出とガバナンスの領域を幅広くカバーしてきました。新エンジンはその基盤の上に構築されており、エージェントの背後にいる人物、そのアクセス権限、関与するサードパーティアプリケーションといった文脈情報をもとに、動作の許可やブロックを判断します。対応する環境では、人間による承認を求めることも可能です。
アプリ、IDシステム、ユーザー独自のラベルから得た文脈情報が1つのPolicy Decision Engineに集約されます。各適用ポイントは、エージェントの動作がアプリに届く前にその判断を適用します（出典：Obsidian）
企業が直面するエージェントのリスクは2つあります。1つは、従業員がプラットフォームを使ってコードを書いたりワークフローを起動したりするケースです。もう1つは、サードパーティベンダーが自社製品にエージェントを直接組み込むケースです。Obsidianの検出・ガバナンス機能は、この両方を対象としています。対象となるのは、Codex、Claude CodeとCowork、Cursor、Microsoft Copilot、Amazon Bedrock、Google Vertex、n8nなどのプラットフォームです。Snowflake、Databricks、ServiceNow、Workdayなどのアプリケーションに組み込まれたエージェントも含まれます。
セキュリティチームは、エージェントを特定し、そのアクセス権限を把握し、リスクの高い設定に対処できます。ただし、エージェントを業務に投入すれば、ある程度のアクセスリスクを受け入れることになるのが通常です。たとえば、エージェントが顧客レコードにアクセスすること自体は正当でも、その使い方には制限が必要になる場合があります。
Obsidianの Runtime Policy Decision Engineは、エージェントが動作する瞬間に、こうしたリスクを抑える制御を提供します。一元管理されたポリシーに照らして許可された動作を評価します。その際、利用可能なID情報、雇用情報、アプリケーションの文脈情報に加え、データ分類ラベルなど顧客が提供する文脈情報も使用します。
接続された適用ポイントは、動作を許可またはブロックします。対応する環境では、人間の承認を必須にすることもできます。新たに追加された「MCP Security Proxy」は、エージェントのツール呼び出しが業務アプリケーションに届く前に検査します。同じく新機能の「Policy Decision API」は、Obsidianの判断を、顧客が運用するゲートウェイやカスタムのエージェントツールにまで広げます。
Obsidian SecurityのCEOであるHasan Imam氏（Hasan Imam）は、次のように述べています。「AIエージェントは、セキュリティの経済性を変えました。エージェントは正規の認証情報を持ち、承認済みのツールを使いながら、企業に数百万ドルの損失をもたらす行動を取ることがあります。」
「私たちは長年、サードパーティ環境全体にわたる権限の連鎖を可視化してきました。その成果として、エージェントの背後にいる人物、到達できるサードパーティアプリケーション、データの価値をもとに、エージェントの動作を進めるべきかどうかを判断する文脈をセキュリティチームに提供できます。Obsidianなら、ポリシーを一度定義するだけで、動作の瞬間に適用されます。防御のコストが下がり、ミスの影響は限定され、企業はAI活用をより速く進められます。」
新機能と拡張機能
コーディングエージェント向けの実行時ポリシーが、OpenAI Codexにも対応しました。Claude CodeとCowork に加わります。開発者によるコーディングエージェントの導入は、ガードレールの整備を上回る速さで進んでいます。複数のベンダーのエージェントを同時に使うことも少なくありません。これらのエージェントは、開発者が持つソースコード、データベース、本番システムへのアクセス権限で動作します。危険な場面はセッションの途中で訪れます。破壊的なコマンドの実行、コンテキストへのシークレットの貼り付け、プロジェクトから大きく外れたファイルの読み取りなどです。
Obsidianの実行時ポリシー適用はOpenAI Codexにも拡大されました。セキュリティチームは、Codex、Claude CodeとCowork、Microsoft Copilotに同じポリシーを1つのコンソールから適用できます。開発者は使い慣れたコーディングツールをこれまでどおり支障なく使えます。一方でセキュリティチームは、複数のベンダーやプラットフォームにまたがる状況を、Obsidianの1つのコンソールで監督できます。
Salesforce Agentforce、Databricks、GitHub、Microsoft 365、Snowflake、ServiceNow、Workdayに組み込まれたエージェントの検出とガバナンスにも対応しました。企業が依存するアプリケーションは、独自のエージェントを次々と提供しています。AI機能は最初から有効な状態で提供されることが多く、ベンダーが独自のエージェントを追加したり、ユーザーがアプリ内で直接エージェントを構築したりもします。しかも、セキュリティレビューを経ないまま使われるケースが少なくありません。こうしたエージェントは、最も機微なデータの近くに位置します。SnowflakeやDatabricksにある業務データ、Workdayにある人事データ、ServiceNowの業務ワークフローなどです。Obsidianは、こうしたアプリ内エージェントの特定を支援します。さらに、エージェントが到達できるID、ツール、データを可視化し、リスクの高い設定を指摘します。
元Gartner Distinguished AnalystのAvivah Litan氏（Avivah Litan）は、次のように話しています。「企業のエージェントの大半は、1か所にとどまっていません。SaaSアプリケーション、データプラットフォーム、開発ツールにまたがって動作し、しかもベンダーはそれぞれ異なります。セキュリティチームに必要なのは、各環境にエージェントを追いかけて適用される単一のポリシーレイヤーです。WorkdayやServiceNow、Snowflake、Databricksといったプラットフォームに対応するObsidianは、実在するギャップを埋めるものです。」
MCP Security Proxyは、エージェントのツール呼び出しをアプリに届く前にすべて検査します。エージェントがSalesforce、Slack、Google Drive、SnowflakeといったアプリにMCPサーバー経由でアクセスするケースが増えています。AIクライアントにアプリのトークンを直接渡すものもあります。Obsidianの新しいMCP Security Proxyは、AIクライアントと対応アプリの間に、従業員とエージェントのための管理されたレイヤーを置きます。ユーザーを特定し、正しいテナントへ振り分け、アプリのトークンをAIクライアントに渡さないようにします。さらに、各ツール呼び出しを実行前にポリシーと照合します。
日常的な呼び出しは通し、リスクを伴うものは停止または保留にできます。使うのはObsidianの他の機能と同じポリシーで、MCPトラフィック専用のルールセットは不要です。ObsidianはCloudflareおよびそのMCP Server Portalと提携しています。Obsidian MCP Proxyを通じて、下流のサードパーティアプリケーションへのエージェントによるアクセスに、文脈を踏まえた効果的なポリシーを提供します。
顧客が提供する文脈情報により、あらゆる判断の精度が高まります。何を機微とみなすかは企業ごとに異なり、適用を担うツール自体がその定義を知ることはありません。セキュリティチームは、データ分類ラベルなど独自の文脈情報を提供できるようになりました。Obsidianはそれを、ID、人事、アプリケーションのデータとあわせて評価します。たとえば「経営層以外の人のために動作するエージェントには、Highly Sensitiveのファイルをブロックする」というポリシーを1つ作れば、どこで適用されても自社の「機微」の定義に沿って機能します。ポリシーは必要なときにだけ作動します。そのため、業務を止めることも、被害につながる動作を見逃すこともありません。
顧客がすでに運用しているカスタムのゲートウェイやハーネスにも、文脈を踏まえた判断を提供します。多くの企業は、エージェントのトラフィックをAPI、AI、MCPの各ゲートウェイに通しています。ゲートウェイはリクエストを見ることはできますが、その背後にいるのが誰か、データにどれほどの価値があるかまでは分かりません。そのため、ルールが過剰にブロックするか、被害をもたらす動作を見逃してしまいます。すべてのゲートウェイで、それぞれの形式に合わせてポリシーを作り直すと、コピー同士が次第に食い違っていきます。
新しいPolicy Decision APIでは、顧客が管理するゲートウェイ、エージェントハーネス、ワークフローが、エージェントの各動作をObsidianのRuntime Decision Engineに送信します。そして、返ってきた判断を理由とともに適用します。判断の材料は、ID、人事、アプリケーション権限、データの文脈です。顧客が自ら追加したラベルも含まれます。
CloudflareのセキュリティPrincipal Product ManagerであるKenny Johnson氏（Kenny Johnson）は、次のように締めくくっています。「企業は、新しいツールごとにルールを書くよりも速いペースで、AIエージェントを基幹業務アプリケーションに接続しています。Cloudflareはそのトラフィックの経路上にあり、ゲートウェイはポリシーを適用するのに適した場所です。しかし、ゲートウェイが見られるのは全体像の一部にすぎません。CloudflareをObsidianのPolicy Decision APIと接続することで、顧客はエージェントのトラフィックがすでに流れている地点で、判断を適用できます。その判断には、エージェントの背後にいるのは誰か、どのようなアクセス権を持つか、どのデータが関わるかといった情報が反映されています。顧客は、頼っているインフラを作り直すことなく、エージェントの動作をより強力に制御できます。」
翻訳元: https://www.helpnetsecurity.com/2026/11/11/obsidian-security-runtime-policy-decision-engine/
