5.1標準
RAGが取得した文書に『前の指示を無視せよ』という文章が含まれる。
文書の内容を根拠として使うが、命令として実行させない。
防御として適切なものを2つ選べ。
× 不正解
取得文書は根拠データであって命令ではないと区切り、ツールや機密操作は許可範囲と確認を通して実行する。
詳細解説
正しいツール呼び出しや機密操作の前に、許可範囲と人手確認を適用する
検索結果から危険な操作へ直接つながる経路を制限できる。
誤り検索文書に書かれた命令を最優先する
外部データがアプリの制御を奪う。
誤り取得文書は社内データなので常に安全とみなす
社内文書にも誤りや攻撃者が埋めた命令があり得る。
正しい取得文書を信頼されていないデータとして明示し、固定指示と区切る
文書内の命令がシステムやアプリの指示へ昇格しにくくなる。
公式資料で確認する
以下の項目を公式資料の記述と照合して確認します。
Task 5.1とBedrock Agentsのユーザー確認を読む。取得文書が操作を提案する仮想例で、文書の区切り、実行主体の許可範囲、確認する操作・対象・引数、拒否または未確認の場合の停止を分ける。
参考にした公式資料
確認できる内容
文書の分離だけで実行を許可せず、必要な承認を具体的な操作と結び付け、独立した認可も確認できる。
理解のポイント
- 非信頼データ
- 区切り
- ツール認可
確認時の注意
- 確認環境: 公式資料と仮想例による参照確認。AWS APIの呼出し、業務データの取得、後続処理の実行は不要。
- 確認画面で示した操作や引数が変わった場合に、古い承認をそのまま流用しない。機密操作へ進む条件を実行境界で確認する。
- Bedrock Agentsの確認は設定したアクションが対象になる。全てのツールに自動的に適用されるとみなさず、拒否・未確認の処理と、アプリ側の権限を別に確認する。
基礎のおさらい
文書と指示の分離
取得文書を根拠データとして明示し、アプリの方針を定める指示と区別すること。区切りだけで攻撃の影響がなくなるとは限らない。
操作に対する承認
実行する操作・対象・引数が分かる形で、必要な確認を受けること。承認があっても実行主体の権限確認は別に必要となる。
問題IDAWS-AIF-193
確認環境公式資料と仮想例による参照確認。AWS APIの呼出し、業務データの取得、後続処理の実行は不要。
最終技術確認2026-10-26
誤り・権利侵害を報告