AI開発ワークフローの脅威をモデル化する

範囲を限定したシナリオを選ぶ

理解しやすい一つのワークフローから始めます。例えば、エージェントがissueを読み、リポジトリを編集し、テストを実行し、pull requestを作成する流れです。これらの操作を可能にするシステムも含めます。

重要な資産を列挙します。ソースコード、顧客情報、認証情報、リリース成果物、サービスの可用性などです。それぞれの責任者を特定します。次に、各資産を読み取ったり変更したりできる人とシステムを特定します。

OWASPは、システムのモデル化、脅威の特定、対応の選択、結果の検証を推奨しています。早い段階で使い、システムの変化に合わせて更新します。脅威モデリングのガイドを参照してください。

信頼境界を描く

架空のissueからPRまでのワークフローについて、次のつながりを描きます。

Issue → agent → repository → test runner → artifact store → deployment

モデル提供者とシークレットの保管先を追加します。信頼度の低い情報源から内容が入る場所に印を付けます。IDが新しい操作能力を得る場所にも印を付けます。例えば、issueの読み取りからリポジトリファイルへの書き込みへ移る地点です。

アプリの構成図だけでは、開発全体のリスクは見えません。本番データベースが非公開でも、CIジョブが認証情報を漏らすことがあります。シナリオに影響する場合は、一時環境とサポート担当者のアクセスも含めます。

具体的な問題の発生経路を書く

「AIは危険かもしれない」のような記述は避けます。実行者、操作、影響する資産、結果を書いてください。シナリオが起こるために必要な条件も含めます。

これらは例であり、脅威の完全な一覧ではありません。関連するシナリオは、データ、ツール、運用環境によって決まります。

対応と責任者を決める

影響と、現実的に想定される曝露に基づいて優先順位を付けます。数値スコアに、実際にはない精度を持たせてはいけません。不確実性と、優先順位を変え得る証拠を記録します。

対応には、リスクのある操作能力を取り除く、範囲を狭める、管理策を追加する、定めた残余リスクを受け入れる、という選択肢があります。受け入れには、権限のある責任者と理由が必要です。未レビューのエージェントの結論にしてはいけません。

選んだ対応を、観察可能な受入条件のある作業に変えます。「エージェントのセキュリティを改善する」では検証が困難です。「テストジョブが本番のシークレットを読めない」なら、確認できる境界を定義できます。

重要な変更の後に見直す

新しいコネクター、モデルへの経路、環境、権限によって、脅威モデルが変わる可能性があります。これらの変更を見直し条件に追加します。インシデントや評価の失敗からも、仮定を更新してください。

リスクレビュー演習で、シナリオのデータ、権限、利用者、復旧条件を変えてみてください。結果は、検討すべき問いを示します。システム固有の脅威モデルの代わりにはならず、作業を許可するものでもありません。