AIエージェント・ガバナンスは、どのIDがどの条件、承認、制限、証拠、復旧の下で、どのアクションを実行できるか定義します。有用なポリシーは強制可能なルールとテストへ変換できます。「エージェントは責任を持って行動する」のような文は変換できません。
具体的なアクションと結果を中心にポリシーを書き、権限、approval gate、spend control、telemetry、evaluation、incident responseへつなげます。
OWASPのExcessive Agencyガイダンスは、下流で認可を強制しながら、ツール機能、権限、自律性を最小化することを求めています。ガバナンスが許可範囲を決め、エンジニアリングが実装します。
機能のinventoryから始める
デプロイ済みのすべてのエージェント、owner、environment、代理対象user、visible tool、data source、credential、external destination、modelとpromptのversion、最大の自律actionを列挙します。chat interfaceのないbackground agentとinternal toolも含めます。
各アクションについて次を記録します。
- subjectとtenant
- resourceとoperation
- conditionと数値上限
- approvalが必要か、誰が承認できるか
- enforcement point
- audit evidenceとretention
- exception ownerとexpiry
- failure、cancellation、recoveryの動作
これは、ポリシーの言葉とエージェント・コントロールプレーンを結ぶマップになります。
結果に応じてアクションを分類する
| 分類 | 例 | デフォルトの制御 |
|---|---|---|
| 読み取り | 所有する注文を取得 | スコープ付きID、データ最小化、監査metadata |
| 復元可能な書き込み | 下書きrecordを更新 | 認可、冪等性、制限付き自律性 |
| 外部通信 | メール送信またはcontent公開 | 宛先とcontentの制約、必要に応じて承認 |
| 金銭的アクション | 購入、返金、有料capacityのprovisioning | 金額と期間の上限、承認、照合 |
| 破壊的アクション | データ削除またはアクセス取り消し | 狭い権限、明示的承認、対応していれば復元可能な経路 |
| 特権管理 | policy、credential、billing、ownershipを変更 | 個別ID、強い承認、詳細な監査 |
この表は出発点であり、普遍的なrisk scoreではありません。読み取りでも機密データを露出でき、復元可能な下書き更新はほとんど影響を持たない場合があります。データ分類、テナントとの約束、workflow contextを加えます。
ポリシーをdecision contractとして表す
具体的なルールは次のように書けます。
サポートエージェントは、認証済みユーザーがsupport roleを持ち、そのtenantが所有する注文について、定義済みの上限まで1回返金できます。上限を超える、または反復する返金にはfinance approvalが必要です。すべての試行でoperation IDを使い、policy versionとoutcomeを記録します。
engineeringはこれを実装してテストでき、operationsは調査でき、business ownerは上限に異議を唱えられます。thresholdとpolicy versionは、プロンプト全体へ散らさず管理された設定に置きます。
プロンプトでルールをモデルへ説明できますが、resource ownership、amount、frequency、role、approvalはbackendで強制します。
データとモデル入力を管理する
エージェントが取得できるデータ分類、各model providerへ送れるデータ、memoryへ保持できるデータ、traceへ置けるデータ、toolへ公開できるデータを定義します。取得contentのprovenanceを記録し、信頼できない入力として扱います。
prompt、memory、artifact、evaluation fixture、trace、backupをまたいだ削除、修正、保持経路を指定します。offline evaluationで本番データを制限し、incident由来のcaseはsanitizeを必須にします。
エージェントセキュリティガイドでは、認証情報と下流認可の制御を扱っています。
model、prompt、tool、policyをversion管理する
これらのいずれが変わっても、エージェントの動作は変化します。各実行にversionを記録し、promotion前に関連evaluation suiteを必須にします。application codeだけでなく、promptとtool contractにもrollback pathを用意します。
権限、外部接続先、金銭上限、自律actionを拡大する変更には、明示的なownerとreviewが必要です。同じpromptでも新しいmodelは別のtoolを選ぶ場合があるため、管理対象のbehavior changeとして扱います。
証拠をquery可能にする
ガバナンスの証拠はpolicy decision、approval、tool call、backend operation、resultを結ぶ必要があります。安定したidentifierとredact済みの事実を保存します。監査記録を完全に見せるためだけに、完全なpromptやpersonal dataを収集しないでください。
誰が証拠へアクセスでき、どれだけ保持するか定義します。テナントをまたいだ広範なデータを持つaudit systemは、それ自体がprivileged surfaceになります。
例外に期限を設ける
例外にはowner、affected agent、reason、compensating control、start、expiry、review conditionを記載します。可能なら自動的に失効させます。日付のない「一時的」アクセスは、レビューされないまま新しいポリシーになりがちです。
例外の反復を、基本ポリシーまたはプロダクトワークフローを見直す証拠として追跡します。
ポリシーをインシデントと評価へつなげる
インシデント経路は、新しい実行を停止し、認証情報を取り消し、影響を受けた操作を特定し、証拠を保存し、結果を照合し、データを復旧し、必要な関係者へ通知し、regression caseを作成する必要があります。
本番エージェントのチェックリストは、これらの制御をworkflow単位のreviewへ変換します。意味のある各インシデントから、policy、enforcement point、alert、runbook、evaluationのいずれかを改善します。
一つの文をエンドツーエンドでテストする
数値、アクション、承認を含むポリシーを選びます。隔離環境で、許可ケース、境界値、未認可テナント、失効した承認、反復操作を試します。backendの判断とaudit evidenceが記述ルールと一致することを確認します。
以下のプロンプトは、現在のリポジトリに対してこの変換を実行します。enforcement pointとacceptance testを特定できないなら、そのポリシーはまだガバナンスではなく指針です。