7月7日、Databricksが「Contextual Policies in Omnigent: Using session state to better govern AI agents」と題した記事を公開した。AIエージェントのガバナンスをセッション状態に基づいて動的に制御する「コンテキスト依存ポリシー」の仕組みと実装例について詳しく紹介されている。

「アクション単位の制御」では限界がある

AIエージェントのセキュリティ対策として現在主流なのは、「このツール呼び出しを許可する／しない」というシンプルなアクション単位のルールだ。しかしこのアプローチには構造的な限界がある。

典型例として、Simon Willisonが提唱した「Lethal Trifecta」（致命的な三要素）がある。プロンプトインジェクション攻撃が成立するのは、エージェントが「信頼できないコンテンツの読み取り」「機密データへのアクセス」「外部への通信」という三つを同一セッション内で実行できるときだ。

Simon Willison's "Lethal Trifecta"とMeta's "Agents Rule of Two"は、この問題を広く知らしめた。

問題は、同一のアクションが「安全かどうか」はその前の文脈に依存するという点だ。コーディングエージェントがGitHubにプッシュする行為は、直前に信頼できない外部Webページを取得していなければ問題ない。しかし取得済みであれば、そのプッシュはインジェクション攻撃の経路になり得る。アクション単位のルールでは、この「前後の文脈」を考慮できない。

Omnigentのコンテキスト依存ポリシーとは

Databricksが開発したOmnigentは、複数のエージェントハーネスに横断して適用できるオープンソースの「メタハーネス」だ。元記事ではClaude CodeやOpenAI Codex CLIといったエージェントハーネスを具体例として挙げているが、後者は2026年時点でOpenAIに同名の複数製品が存在するため、ここでは元記事の文脈に即しCLI版のCodexを指すものとして読んでいただきたい。

Omnigentのコンテキスト依存ポリシーの核心はセッション状態（session state）にある。ポリシーはエージェントのツール呼び出しやLLMへの入出力といったイベントを監視し、従来どおりの「許可／拒否／ユーザー確認」を判断するだけでなく、セッション内で何が起きたかをポリシー専用の変数として記録し続ける。

実装はシンプルで、「古い状態」と「エージェントが試みようとしている新しいイベント」を受け取り、「状態の更新」と「判断」を返す関数を書くだけだ。Omnigentサーバーが各ポリシー・各セッションの状態を管理し、次の呼び出し時に渡す。

# ポリシーの基本構造（元記事のschema.pyを参照）
def policy_handler(state, event):
    # stateは前回までの累積情報
    # eventは今回エージェントが実行しようとしているアクション
    new_state = update_state(state, event)
    decision = compute_decision(new_state, event)
    return new_state, decision

OmnigentはOpenAI Agents SDKやClaude Agents SDKなど主要なフレームワークにも対応しており、既存のエージェントをOmnigent経由で起動するだけでポリシーが適用される。

4つの組み込みポリシー：まず重要度の高い2つを詳しく見る

元記事が紹介する4つの組み込みポリシーのうち、「Google Driveポリシー」と「インテントベース認可（IBA）」は、コンテキスト依存ポリシーの本質——セッション履歴がアクションの可否を変える——を最もよく体現している。この2つを先に詳述し、残る2つを後述する。

Google Driveポリシー：「このセッションで作ったファイル以外は書き込み禁止」

このポリシーが面白いのは、最小権限の原則をセッション状態で動的に実現している点だ。単純なアクセス制御リストでは実現できない。

デフォルトでは、エージェントは自分がそのセッション中に作成したドキュメントにのみ書き込める。既存のファイルは読めるが、書き換えられない。さらに、機密文書として指定したファイルをエージェントが一度でも開くと、そのセッションで直前まで自由に編集できていたファイルへの書き込みも禁止される。機密内容を保護されていないファイルに混入させる「ライトダウン」を防ぐためだ。これはセキュリティ理論におけるBell-LaPadulaモデルの「no write-down」ルールの実装に相当する。Bell-LaPadulaモデルは、軍事・政府システムで長く使われてきた強制アクセス制御の形式モデルで、機密度の高い情報が低い領域に「書き下ろされる」ことを禁じることでデータの漏洩を防ぐ考え方に基づく。

Figure 3: Google Driveポリシーの設定。confidential_filesで機密ドキュメントを宣言する

Figure 5: 機密ドキュメントを読み取った後、同じ書き込み操作がライトダウン防止のため拒否される

インテントベース認可（IBA）：ユーザーの最初の指示を権限の基準にする

セッション開始時のユーザーの指示内容を状態として記録し、以降のすべてのツール呼び出しをその「元々の目的」と照合する。「Google Slidesのプレゼンを更新して」とだけ指示されたエージェントが、途中でGitHubへのアクセスを試みても自動的にブロックされる。

プロンプトインジェクションで外部から悪意ある指示を注入されても、エージェントはそもそもその操作に必要な権限を持っていないため、被害を最小化できる。多くのツールをデフォルトで持つエージェントを、セッションごとに自動的に最小権限に絞り込むという考え方だ。

Figure 8: IBAが最初のリクエストと無関係なシェルコマンドをブロックする様子

そのほかの組み込みポリシー

コストポリシーは、セッション内のモデル呼び出し累計コストを追跡し、ソフトしきい値を超えるとユーザーに確認を求め、ハードキャップに達すると高コストモデルの使用をブロックして安価なモデルへの切り替えを促す。セッション単位とユーザー日次上限を重ねがけできる。

リスクスコアポリシーは、セッション内の各アクションにポイントを付与し累積スコアを管理する。スコアが閾値を超えると、メール送信やファイル共有などのアクションが自動許可から「ユーザー承認必須」に切り替わる。

まとめ

コンテキスト依存ポリシーのポイントは「何をしたか」ではなく「何をしてきたか」で判断するという発想の転換にある。エージェントが機密情報に触れるほど、同じアクションへの判断基準が厳しくなる動的なガバナンスは、ヒューマンユーザー向けの文脈依存セキュリティをエージェントに持ち込んだものだ。Omnigentは現在アルファ版としてオープンソースで公開されており、既存のエージェントにそのまま適用できる点も実用上の利点だ。

詳細はContextual Policies in Omnigent: Using session state to better govern AI agentsを参照していただきたい。