各ステップが許可されても全体は制御を失う：企業AIにセッション単位の防御を

企業AIエージェントに検索、通知、発注、支払い、データ更新のツールを与えると、通常は各呼び出しの権限を確認します。しかし、個別には許可された操作でも、連続すると危険な業務フローになる場合があります。AWSは2026年8月にセッションを対象とする時間的ポリシーと流量制限を発表し、9月初めには機械速度に対応する検知を強調しました。焦点は一回のAPI呼び出しから、タスク全体の順序と累計影響へ移っています。

一つの許可は全体の妥当性を保証しない

正しい口座を確認した後に別の宛先へ送金する、承認額を超える発注を小口に分ける、失敗したツールをTokenやAPI枠が尽きるまで再試行する、といった事態が起こり得ます。リスクは各操作ではなく、前後関係と累計結果にあります。

実行順序をシステム規則にする

高リスク業務では、案件取得、対象確認、提案作成、人の承認、更新という順序を定義します。確認の省略、承認期限切れ、データ版の変更があれば次の書き込みを止めます。規則はワークフロー、状態機械、API Gateway、ポリシーサービスで強制します。

合計、流量、再試行を管理する

一回の上限だけでなく、利用者、エージェント、タスク、ツールごとに累計金額、件数、呼び出し回数、Token予算、時間、再試行上限を設けます。流量制限は下流システムを保護し、累計しきい値は分割、ループ、異常拡大の前にタスクを停止します。

防御はモデルの外で実行する

プロンプトの制約は有用ですが、唯一の制御にはできません。エージェントが次の操作を提案し、独立したポリシー層がID、タスク状態、履歴、累計値を読み、許可、拒否、一時停止、承認要求を判断して監査記録を残す構成が堅実です。

一つのセッションリスク表から始める

見積承認、購買、会員情報変更、一括メール、返金から一つ選び、タスクID、依頼者、エージェントID、許可順序、単発と累計の上限、流量、承認期限、停止条件、復旧、必要ログを記録します。順序飛ばし、重複、分割、期限切れ、データ変更をテストします。

Millionasia の提案

エージェントがWeb、アプリ、RAG、ERP、CRM、外部APIを横断するなら、セキュリティ境界も一回の呼び出しからタスク全体へ広げる必要があります。順序、累計、流量、承認、停止、復旧をID、権限、ログ、管理画面と一体で設計し、小さな判断ミスが制御不能な業務リスクへ拡大しないようにします。