Omnigentにおけるコンテキストポリシー：セッション状態を活用したAIエージェントのガバナンス向上

先日、AIエージェント向けのオープンソースのメタハーネスであるOmnigentをローンチしました。これにより、Claude Code、Codex、カスタムエージェントなど、すでにお気に入りのエージェントハーネスを引き続き使用しながら、コラボレーション、コンポジション、ポリシーのための共有レイヤーを追加できます。

セキュリティとコスト管理のために、Omnigentは強力な新しいツール、コンテキストポリシーを導入します。現在のエージェントフレームワークには、エージェントができることを制限するためのシンプルな制御機能（さまざまなツール呼び出しを許可、拒否、またはユーザーに確認するルールなど）しかありません。しかし、これではセキュリティとユーザーの利便性を両立するポリシーを作成することが困難になります。対照的に、Omnigentのコンテキストポリシーは、セッション内でこれまでに発生したこと（エージェントが何を読み取ったか、これまでに何ドル費やしたかなど）を記憶し、その状態（state）を使用して次のアクションを進めるべきかどうかを判断できます。これにより、セッションのリスクレベルを動的に追跡することから、最小権限のセキュリティモデルの実装、支出を管理するためにユーザーが個々のタスクの予算を設定できるようにすることまで、より安全でユーザーにとって便利な、幅広い高度なポリシーが可能になります。

エージェント制御にコンテキストが必要な理由

AIエージェントは、企業に新しいタイプのリスクをもたらします。たとえば、エージェントは信頼できないコンテンツによってプロンプトインジェクションを受け、有害なアクションを実行させられる可能性があるため、同一のエージェントが信頼できないコンテンツを読み取ること、機密データにアクセスすること、そして外部の世界と通信することを防ぐことが望ましいとされています（これはSimon Willison氏の「Lethal Trifecta（致命的な3要素）」や、Metaの「Agents Rule of Two（エージェントの2つのルール）」として知られています）。あるアクションが「安全」かどうかは、部分的にはそれ以前に何が起こったかに依存します。たとえば、コーディングエージェントがGitHubにプッシュすることは、エンジニアのために機能を開発した直後であれば通常は問題ありません。しかし、そのエージェントが事前にインジェクション攻撃を含む可能性のある信頼できないウェブページをダウンロードしていた場合、同じGitHubへのプッシュは危険なものになります。

残念ながら、現在ほとんどのエージェントソフトウェアは、Gitプッシュやウェブ検索を許可するかどうかなど、個々のアクションに対するシンプルな許可リスト（allow-list）制御やガードレールしか提供していません。インジェクション攻撃を防ぐには、これらのアクションの少なくとも1つを完全にブロックする必要がありますが、これでは多くの無害なユースケースにおいて制限が厳しくなりすぎてしまいます。アクションごとにユーザーに承認を求めるのも、ユーザーが承認プロンプトに疲弊してしまうため、うまく機能しません。

これは他の状況でも同様です。たとえば、営業担当者のエージェントが顧客に1通のメールを送信することは問題なくても、数千通のメールを送信する場合は、アカウントの乗っ取りやバグを示唆している可能性があります。エージェントが自身で作成したドキュメントを編集することは問題ありませんが、同じエージェントが数千の社内ドキュメントを編集する場合は、精査が必要になるかもしれません。実際、人間のユーザー向けの多くのセキュリティツールも、現在のアクションだけでなく履歴を考慮します（これはコンテキストセキュリティと呼ばれます）。

コンテキストポリシーの登場

Omnigentでは、従来の agent guardrail と同様に、ポリシーがエージェントが実行しているイベント（ツールの呼び出しと応答、LLMへの入力と出力など）を監視し、許可、拒否、メッセージの変換、またはユーザーへの許可の要求を行うかどうかを決定できます。しかし、ポリシーはセッションに関する状態（state）、つまりそのポリシーにのみ表示される任意の変数を更新することもできます。これには、エージェントが特定のツールを何回使用したか、どのドキュメントを読み取ったかなどの追跡が含まれます。Omnigentサーバーは、各ポリシーとセッションの状態を記憶し、次回ハンドラーを呼び出すときにそれをポリシーハンドラーに渡します。コンテキストポリシーを作成するには、古い状態（state）とエージェントが実行しようとしている新しいイベントを受け取り、状態の更新と決定を返す関数を記述するだけです。Omnigentには、便利なポリシーが最初から多数含まれています。

さらに、Omnigentはメタハーネスであるため、任意のハーネスを使用しているエージェントに対しても、同様にコンテキストポリシーを適用できます。Omnigentは、Claude Code、Codex、Antigravity、Pi、OpenCode、Hermesなどの広く使用されているコーディングエージェントや、OpenAI Agents SDKやClaude Agents SDKなどのフレームワークのカスタムエージェントをサポートしています。Omnigentを介してエージェントを起動するだけで、Omnigentサーバーがそれらのツール呼び出しをインターセプトしてポリシーを適用します。

ユースケースの例

現在、Omnigentに標準搭載されている3つのサンプルポリシーをご紹介します。それぞれが異なる種類のセッション状態（エージェントがこれまでに読み取ったコンテンツ、累積されたセッションリスクスコア、または現在のセッションの総コスト）に依存しています。

1. Google Driveポリシー：エージェントのアクセス範囲を適切なドキュメントに限定する

Google Driveポリシーは、エージェントがドキュメント、スプレッドシート、スライドで読み取りおよび変更できる内容を管理します。デフォルトでは、書き込みはエージェントがこのセッション中に作成したドキュメントに限定されます。そのため、エージェントは新しいドキュメントを作成して自由に編集できますが、触れるべきではない既存のファイルを密かに変更することはできません。この動作は、シンプルな許可リストでは実装できません。「ドキュメントの書き込み」ツールを完全に許可または拒否するのではなく、エージェントが同じセッション内で作成したドキュメントに対してのみ許可したいためです。

このポリシーにおけるコンテキスト動作の2つ目の例として、一連のドキュメントを機密（confidential）としてマークできます。エージェントがそのうちの1つを開いた瞬間、ポリシーが厳格化され、書き込みはそのセットに限定されます。1分前にエージェントが作成したドキュメントであっても、アクセス禁止になります。機密資料をそこに追加すると、保護レベルの低いファイルにそのコンテンツが漏洩してしまうためです。従来のセキュリティにおいて、これは「no write-down（下位書き込み禁止）」ルールを持つBell-LaPadulaモデルを実装するものです。

2. リスクスコアポリシー：エージェントが機密資料に触れるにつれて警戒を強める

リスクスコアリングは、セキュリティチームが人間のアクセスを管理するために一般的に使用されています。Omnigentでは、リスクスコアリングポリシーが現在のセッションの実行スコア（エージェントの作業に伴って蓄積されたリスクの量を示す単一の数値）を保持します。ユーザーは、どのアクションがスコアをどの程度上昇させるかを設定できます。通常のツール呼び出しでは1〜2ポイント追加される一方、極秘としてマークしたドキュメントを読み取ると、はるかに多くのスコアが追加されます。スコアが低く保たれている限り、エージェントは中断されることなく動作します。しきい値を超えると、メールの送信やファイルの共有などのアクションは、ALLOWではなくASKを返し、ユーザーに承認を求めます。そのため、セッションの初期段階であれば送信されていたはずの同じメールでも、エージェントが十分な機密資料を処理してスコアが上昇した後は、人間の承認が必要になる場合があります。

3. コストポリシー：支出をコントロールする

予算ポリシーは、セッションがこれまでにモデルの呼び出しに費やしたコストを追跡します。緩やかなしきい値（ソフトしきい値）を超えると、処理を一時停止して継続するかどうかを尋ねます。支出が厳格な上限（ハードキャップ）に達すると、ポリシーはエージェントがより安価なモデルに切り替えるまで、高価なモデルへのさらなる呼び出しをブロックし、セッションを停止させることなく継続できるようにします。同じ考え方は、単一のセッション以外にも拡張できます。プラットフォームチームは、セッションごとの上限に加えて、ユーザーごとの1日の上限を重ねて設定できるため、多くの個別の会話全体でコストが膨らむのを防ぐことができます。どちらの場合も、コンテキストは累積支出です。ポリシーは個々のモデル呼び出しを判断しているのではなく、実行中の合計を監視し、セッションまたはユーザーの支出が多すぎる場合に介入します。

4. 意図に基づく認可（Intent-Based Authorization）：目的に基づいて権限を制限する

意図に基づく認可（Intent-based authorization）は、ユーザーの最初のプロンプトに基づいてエージェントの権限を設定するため、プロンプトインジェクションを受けたエージェントであっても、ほとんどのツールを使用して害を及ぼすことはできません。たとえば、エージェントにGoogleスライドのプレゼンテーションを更新するよう依頼してセッションを開始した場合、ポリシーはそのエージェントにそのプレゼンテーションの読み書きを許可しますが、エージェントが突然GitHubを使用しようとした場合はアクセスをブロックします。ポリシーは、セッションの開始時にユーザーが実際に要求した内容を状態（ステート）として記憶し、すべてのツール呼び出しをその元の目標と照合して、 最小権限の原則（Principle of Least Privilege）を適用します。これは、コンテキスト状態によって実現される非常にシンプルでありながら強力なポリシーです。デフォルトで多くのツールを使用してエージェントを構成でき、各セッションで自動的にロックダウンされます。あるセッションでは問題のない同じツールの呼び出しが、エージェントに何を依頼したかによって、別のセッションでは承認が必要になる場合があります。

まとめ

エージェントがより多くの実際のタスクを担うようになるにつれて、難しい部分はそれらをどのように制御するかに移っていきます。エージェントは、悪意のある入力や単純なバグによって害を及ぼし始める可能性があり、個々のアクションを検査する単純な許可リスト（アローリスト）ポリシーでは、エージェントの使いやすさと安全性を両立させるのに十分な柔軟性がありません。コンテキストポリシーは、セッション内の状態を動的に追跡し、エージェントが十分なリスクを蓄積した場合にのみアクションをブロックすることで、より使いやすく安全なエージェントを実現します。また、単にユーザーごと、1日ごとではなく、セッションレベルで予算を管理するための強力でシンプルなツールも提供します。Omnigentは オープンソースであり、最も人気のあるコーディングエージェントやエージェントフレームワークと統合されているため、既存のエージェントにこれらを適用し始めることができます。

試してみる

Omnigentは現在、アルファ版としてオープンソースで提供されています。

• クイックスタートから始める： https://omnigent.ai/quickstart/install
• リポジトリにスターを付け、クローンする： https://github.com/omnigent-ai/omnigent
• ポリシーチュートリアルに従う： https://omnigent.ai/quickstart/policies
• ポリシードキュメントを読む： https://omnigent.ai/docs/policies/overview
• Discordに参加する： https://discord.gg/omnigent

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事