エージェントの権限を制限する

アクセスを与える前にタスクを記述する

コードを読むエージェントと、サービスをデプロイするエージェントでは、必要な権限が異なります。同じ製品が両方の操作に対応しているからといって、両方の権限を与えないでください。

権限は、操作、リソース、条件の三つで定めます。架空のレポート修正では、タスクが有効な間、一つのfeatureブランチに書き込めます。承認済みのリポジトリファイルを読めます。本番データやリポジトリの保護ルールは変更できません。

具体的な強制方法はツールによって異なります。トークンでブランチを制限できない場合は、リポジトリの追加管理策や実行サービスを使います。残る権限を正確に文書化してください。

モデルの外で制限を強制する

プロンプトはアクセス制御システムではありません。実行コンポーネントは、要求された操作と対象を現在の権限と照合する必要があります。「すでに承認済み」というモデルの主張だけを受け入れてはいけません。

AWSは、適切なワークロードに対して、限定した権限と一時的な認証情報を推奨しています。OWASPも、エージェントとそのツールに同様の最小権限の考え方を適用しています。これらの原則は、実際のID管理システムと実行システムで実装する必要があります。AWS IAMガイド、OWASPのエージェント向けガイドを参照してください。

対応している場合は、有効期間の短い認証情報を使います。無関係なシークレットを環境に入れないでください。リポジトリを読むだけのタスクに、開発者のシェルから本番データベースのパスワードを引き継がせてはいけません。

承認を実際の操作に結び付ける

変更の準備を承認しても、デプロイまで承認したことにはなりません。デプロイの判断では、成果物、対象環境、関連する条件を特定します。それらが変わると、以前の判断は適用できなくなる場合があります。

安全なデータベースの読み取りを提案したエージェントが、承認後に別のクエリを実行するとします。有効な承認の仕組みは、実際に実行される操作を確認します。対象が定まらないままの一般的な「続けて」というメッセージでは、その違いが隠れる可能性があります。

IDと能力も区別します。実行を開始した人またはワークロードを記録します。操作の時点でも、開始元のIDに権限があるか確認してください。人のアクセスを取り消した際、キュー内の作業がどうなるかを明確にします。

拒否と中断をテストする

成功する経路だけでなく、他の経路も検証します。隔離したテスト環境で、許可されたリソースの範囲外を操作しようとしてみます。実行システムが拒否することを確認します。認証情報を記録せずに、監査イベントを調べます。

次に、キャンセルや認証情報の期限切れをテストします。どの作業が即座に止まり、どの操作が完了できるかを確認します。停止ボタンを押しても、別のシステムへすでに届いた操作が取り消されるとは限りません。

タスクとともに、簡潔な権限記録を残します。責任者、承認した範囲、実際の管理策、拒否のテスト、有効期限を含めます。後のレビューを具体的にし、ワークフローの改善に役立てます。