AIエージェントのセキュリティ設計：
プロンプトインジェクション・権限スコープ・
Human-in-the-Loop・出力フィルタリング

残念ながら「完全な防御」は存在しません。OWASP LLM Top 10（2025版）でも、RAGやファインチューニングは有効だが完全な緩和策にはならないと明記されています。UK NCSCも「LLMは命令とデータを根本的に区別しない」と述べており、設計の核心は「成功しても被害が小さい多層防御」です。具体的には、外部データを`<untrusted_context>`タグで隔離する、ツール呼び出し前にポリシーゲートを挟む、Azure AI Prompt ShieldsやAmazon Bedrock Guardrailsの専用検知機能を組み合わせる、の3層で残余リスクを最小化します。

3つの軸で権限を絞ります。第一に「機能の制限」——エージェントが使えるツールをallowlist方式で限定し、不要なツールはそもそも渡さない。第二に「権限の制限」——各ツールのスコープを最小化（例：メール読み取り権限だけ付与し、送信権限は別途承認制）。第三に「自律性の制限」——高リスク操作はHuman-in-the-Loopに回す。MCP環境では、Agens Controlの共通MCPエンドポイントを経由させることで、RBAC/ABACによるツール・スキルパック単位の権限制御と監査ログを一元管理できます。

読み取り・ドラフト生成・通知系（全ツール呼び出しの7〜8割）は自律実行させ、書き込み・外部送信・削除等の破壊的操作のみ承認フローに回すのが標準設計です。承認通知はSlack/Teamsに非同期送信するため、承認者は作業を中断せず対応できます。LangGraphのinterrupt機能やAgens Controlの承認ワークフローは状態を永続化するため、承認待ちの間も他の処理は継続できます。実績では承認待ちによるスループット低下は10〜15%程度に留まります。

OWASP 2025版が新規追加したLLM08（Vector and Embedding Weaknesses）が示すように、RAGはエージェントにとって「追加の入力面」です。2024年のInjecAgentベンチマークでは、メールやWebコンテンツを扱うツール統合エージェントがIPI（Indirect Prompt Injection）に脆弱であることが実験的に示されています。対策の核心は取り込み時点（ingestion）での統制——ソースをallowlistに限定、文書メタデータ（作成者・経路）の付与、取り込みスキャナーによる「命令っぽい文字列」の隔離レビューです。

2つのレイヤーで実装します。第一に「プロンプトレイヤー」——システムプロンプトで出力制限を記述しますが、OWASPが明示するようにこれは迂回され得るため補助的手段です。第二に「アプリケーションレイヤー」——LLM出力を下流システムに渡す前に、正規表現・NER（固有表現認識）・DLPルールで機密パターン（社員番号・カード番号・APIキー等）を検出し、Warn/Redact（マスク）/Block（遮断）の3段階で処理します。Agens ControlのWAF/DLP機能は全JSONペイロードをこの3段階で検査し、検知結果を監査ログに記録します。