エージェント・コントロールプレーンは、実行を取り巻く判断を担います。ID、認可、認証情報のscope、承認、制限、操作状態、リソース所有権、監査記録が対象です。データプレーンは、許可されたデータベースquery、ブラウザー操作、デプロイ、API呼び出しを実行します。
各ツールがこれらを別々に判断するなら、システムに実質的なコントロールプレーンはありません。ツールを追加するたびにずれていく規則の集まりにすぎません。
判断と実行を分ける
flowchart LR
Agent[Agent request] --> Identity[Resolve identity and tenant]
Identity --> Policy{Policy and approval}
Policy -->|deny| Audit[Audit decision]
Policy -->|allow| Broker[Issue scoped credential]
Broker --> Operation[Create or resume operation]
Operation --> Tool[Execute tool in data plane]
Tool --> Resource[(Database, API, browser, compute)]
Tool --> Operation
Operation --> Audit
コントロールプレーンは、誰が操作し、どのリソースを所有し、どのアクションが許可され、同意が必要か、どれだけの作業を実行でき、操作をどう停止できるかに答える必要があります。データプレーンは、範囲の狭い指示と、その実行に十分な権限を受け取ります。
この境界はAIエージェント・アーキテクチャ全体を補完します。初日から別サービスにする必要はありませんが、コード上で契約を確認できるようにします。
ツール選択より先にIDを確立する
ツールを実行する前に、認証済みの人間、テナント、エージェント、セッションを解決します。認証情報からサーバーがテナント識別子を紐づけられる場合、モデル出力から受け取ってはいけません。
NISTのゼロトラスト・アーキテクチャは、呼び出し元がネットワーク内にいるという理由で信頼を与えるのではなく、リクエストごとに評価します。エージェントでは、社内ツールからのリクエストであっても、下流サービスが代理対象のIDを認可することを意味します。
コントロールプレーン、エージェントセッション、アプリケーションランタイムには別々の認証情報を使います。リソースをプロビジョニングできる管理認証情報を、通常のアプリケーション呼び出しで利用できるようにしてはいけません。
ポリシーから具体的な判断を返す
有用なポリシー判断は、次を記録します。
- subject、テナント、リソース、アクション
- ポリシーのバージョンと一致したルール
- 人間の承認が必要か
- 支出、呼び出し、時間、データ量の制限
- 安定した理由を伴うallowまたはdenyの結果
ツール説明は承認を求める時期をモデルへ伝えられますが、強制はプロンプトの外に置きます。OWASPのExcessive Agencyガイダンスは、ツール機能、権限、自律性を最小化し、下流システムで認可を強制することを推奨しています。
実用的な最小scopeで認証情報を仲介する
プロバイダーが対応している場合、データプレーンworkerには、承認済みのリソースとアクション向けの短期認証情報を渡します。対応していない場合は、プロバイダー認証情報をサーバー側ツールに保持し、ラッパーで同じ制限を適用します。
モデルコンテキスト、ツール説明、URL、モデルから見えるエラーを通じてシークレットを渡してはいけません。トレースには認証情報の値ではなく、参照を記録します。
エージェントセキュリティガイドでは、IDとシークレットの経路全体を説明しています。
操作を会話から分けて追跡する
chatのturnは操作記録ではありません。書き込み、待機、再試行を行う作業や、リクエストより長く続く可能性がある作業には操作IDを作成します。状態、redact後の入力、冪等性キー、承認状態、試行、出力または参照、最終結果を保存します。
これにより、デプロイリクエストをreplayせず、エージェントがデプロイの実行状態を問い合わせられます。また、人間がキャンセル、再開、調査できる安定したオブジェクトになります。
inventoryと所有権を同じプレーンに置く
コントロールプレーンは、各データベース、bucket、デプロイ、ブラウザーセッション、エージェント認証情報をどのテナントが所有するか把握する必要があります。inventoryによって、取り消しと削除を管理しやすくなります。また、二つのテナントに同じ表示名で存在するリソースをモデルが選ぶことを防げます。
quotaは、モデルが指定したテナントフィールドではなく、認証済みテナントと操作へ適用します。制限に達したら、エージェントが無条件に再試行せず説明できる、安定した結果を返します。
判断と結果を一緒に監査する
監査記録には、ポリシー判断と観測した結果の両方が必要です。「削除を許可」と「削除が完了」は別のイベントです。操作ID、actor、テナント、リソース、アクション、ポリシーバージョン、承認参照、timestamp、結果分類を保持します。
生のプロンプト、シークレット、完全なツール結果を、デフォルトで監査ログへ含めないでください。正確なcontentを保持する必要がある場合は、独立したアクセスポリシーの下にhashまたは参照を保存します。
既存アプリケーション内から始める
小規模なシステムでは、middleware、ポリシーモジュール、credential adapter、operations table、append-only audit tableとして実装できます。規模や所有権の要件が生じたらサービスへ分割します。最初の目標は、一貫した判断経路を一つ作ることです。
以下のプロンプトは既存ワークフローを追跡し、個々のツールhandlerに埋もれた制御を見つけます。重複している制御が、共通契約の背後へ移す最初の候補です。