Omnigentが目的に反するAIエージェント操作を遮断

Databricksは、AIエージェントの各操作をセッションで宣言した目的と照合するOmnigentの目的ベース認可を紹介しました。

要点

• 身元の権限だけでは、許可済みだが依頼外の操作を防げません。
• 操作ごとに許可、人の同意要求、拒否を返し、目的外は既定で拒否します。
• 目的文はエージェントが下書きできても、人が承認し、エージェント自身は拡張できません。

今回のブログ記事で語られていること

従来の役割ベース制御は「この身元が表を読めるか、権限を付与できるか」を判定しますが、「今回の品質確認で権限付与が必要か」は判断しません。エージェントが文書、メール、表の自由記述欄から間接的な指示注入を受けると、正規の資格情報で依頼外の操作を実行しても、認可上は正当になります。

記事の例では、表を読み、品質指標を計算し、画面へ要約を書くエージェントが、別業務のために権限付与ツールも持っています。攻撃者が顧客表へ外部監査人への閲覧権限付与を求める文章を埋め込むと、身元ベース制御だけでは実行されます。セッション目的を「品質確認と要約」に限定すると、読み取りは許可、画面更新は人の同意、外部への権限付与は拒否と判定できます。

Omnigentの文脈ポリシーは各ツール呼び出し前に許可、確認、拒否を返します。目的は短い規則として設定し、エージェントが説明から下書きしても人が承認します。実行中にエージェントが目的を広げたり削除したりできず、明記されない操作は拒否されます。セッション危険度など別の文脈ポリシーと併用し、一つでも拒否なら操作を止めます。

実装では、目的文が広すぎれば効果がなく、細かすぎれば通常業務が止まります。過去の作業から必要なツールと引数範囲を整理し、確認へ回す操作の待機時間、承認者、期限を決めます。目的文の変更も監査し、注入を含む入力で拒否が維持されるか回帰試験してください。

目的の下書きを生成するモデルも攻撃対象になり得るため、利用者の依頼と承認済みひな型を基にし、外部文書の内容から目的を広げない設計が必要です。拒否の多さだけで品質を判断せず、必要な操作が確認待ちで滞留していないか、承認者が文脈を理解できる証拠が表示されるかも測ります。

今回のブログ記事が関係する人

ツール実行型エージェントの開発者、認可基盤担当、データ権限と監査を担うセキュリティチームに関係します。

結局、今回のブログ記事をどう読むべきか

最小権限を身元だけでなく作業目的へ適用する防御です。万能な注入検出ではなく、モデルが騙されても危険な操作を実行させない第二の境界として評価すべきです。