AI Security for Apps GA時代の実行時防御パターン

GA到達は「安全になった」ではなく「安全を運用できる段階に入った」

AI Security for AppsのGAは重要な節目です。しかし実務では、機能提供そのものより「どこで、何を、どう判定し、どう記録するか」が成否を分けます。エージェント型アプリは、プロンプト、ツール、出力の3経路すべてが攻撃面です。

先に脅威パターンを固定する

主要な事故は次の4類型に集約できます。

• プロンプト注入による意図逸脱
• 過剰権限ツールの誤用
• ログ/出力経由の機微情報漏えい
• 複数ツール連鎖でのポリシー回避

「AIリスク一般論」ではなく、この4類型ごとに制御を置くと設計が明瞭になります。

ランタイム防御の4層

1. 入力防御: 分類・正規化・機微情報マスキング
2. 判定層: ID、文脈、目的に基づくポリシー評価
3. ツール仲介: 許可・拒否・引数制約
4. 出力防御: 機密漏えい・危険誘導の遮断

各層で同一セッションIDを保持すると、監査と障害調査が高速化します。

エッジとアプリの役割分担

• エッジ側: 早期遮断、レート制御、入力整形
• アプリ側: 業務文脈に沿った詳細判定、例外処理

どちらか一方に寄せると抜け漏れが増えます。多層防御を前提に責任分担を明文化します。

Policy as Codeで権限制御を再現可能にする

ポリシーはコードとして管理し、レビュー可能にします。最低要素は以下です。

• 実行主体の信頼レベル
• ワークフロー種別
• ツール分類（読取/更新/実行/外部連携）
• 必要承認種別
• 扱えるデータ機密度

インシデント後に手作業で復元する運用は持続しません。

検知設計

有効な検知例:

• ポリシー開示を誘う繰り返し入力
• 短時間での異常なツール分岐
• テナント境界をまたぐデータ形状の逸脱
• 出力内の認証情報パターン

誤検知率もKPI化し、SOCの可処理範囲に収めます。

インシデント対応

• 問題ツール資格情報の即時無効化
• セッション系列（入力→判定→実行→出力）の固定保存
• 信頼レベル単位での隔離
• フォレンジック再実行で再現確認

対応時間短縮には、平時の証跡設計が効きます。

導入計画

Week 1-2: 脅威モデルとデータ分類合意。

Week 3-6: 判定エンジンとツール仲介をステージング実装。

Week 7-10: 本番導入と検知チューニング。

Week 11-12: 監査リハーサル、例外運用の厳格化。

まとめ

GAは出発点です。エージェントアプリの安全性を高める鍵は、実行時の多層防御、Policy as Code、監査可能な判定履歴を継続運用することにあります。