# Lethal Trifectaを設計で崩す3つの切り口

> AIエージェントの情報漏えいは、私的データ・信頼できない入力・外部通信の3要素が揃うと成立します。中小企業が1要素を設計で外す手順を、Claude Codeの設定例で解説します。

- Canonical: https://kuucorp.com/blog/lethal-trifecta-agent-design-smb-checklist/
- Date: 2026-10-09
- Last modified: 2026-10-09
- Publisher: Kuu株式会社 (https://kuucorp.com)

---
メールやWebページを読み、社内ファイルにも触れ、外部へ送信もできるAIエージェントを便利だと感じて導入したものの、「プロンプトインジェクション対策はどこまでやれば十分か」に答えられない担当者は多いはずです。検知フィルタを積み増しても、突破される可能性は残ります。

IT専任者が少ない中小企業にとって現実的なのは、攻撃を全部検知することではなく、被害が成立する構成そのものを避けることです。本記事では「Lethal Trifecta（致命的な三要素）」を軸に、設計段階で外すべき要素を決める手順を整理します。関連する防御層は[プロンプトインジェクション5層防御](/blog/prompt-injection-layered-defense-architecture/)も参照してください。

## Lethal Trifectaとは何か

> Lethal Trifectaは、私的データへのアクセス・信頼できない入力・外部通信の3つが揃ったエージェントで、データ窃取が成立するという整理です。

開発者のSimon Willisonが2025年6月に提示した枠組みで、3要素は次のとおりです。

- **私的データへのアクセス**: 顧客情報、社内文書、認証情報などをツール経由で読める
- **信頼できない入力への露出**: 攻撃者が書いたテキストや画像がLLMに届く経路がある（受信メール、Webページ、共有ファイル）
- **外部への通信能力**: データを社外へ送れる（メール送信、HTTPリクエスト、外部画像の読み込み）

LLMは指示がどこに書かれていても従ってしまうため、3つが揃うと攻撃者の文章1つで漏えいが成立します。OWASPのLLM01も、外部のWebサイトやファイルを取り込む間接プロンプトインジェクションを主要な攻撃経路として挙げています。

## なぜ検知フィルタだけでは足りないのか

> 検知は確率的な対策であり、取りこぼしが1件でもあれば3要素が揃った構成では漏えいに直結します。

Willisonは、検知率95%をうたう製品でもWebセキュリティでは不合格に等しいと指摘しています。OWASPが挙げる緩和策（出力形式の検証、入力・出力フィルタ、最小権限、高リスク操作の人間承認、外部コンテンツの分離）も、組み合わせて被害を減らす位置づけです。

したがって優先順位は、(1) 3要素のうち1つを構造的に外す、(2) 残る要素は権限とネットワークで絞る、(3) その上で検知を重ねる、の順になります。

## どの要素から外すべきか

> 1つの業務フローに3要素が同居していないかを棚卸しし、最も外しやすい要素を1つ削るのが最短の手順です。

エージェントごとに、次の表を埋めてください。

1. 読めるデータは何か（共有ドライブ全体か、特定フォルダか）
2. 外部から届く入力は何か（メール本文、Web検索結果、添付ファイル）
3. 外へ出せる経路は何か（送信メール、HTTP、MCPサーバー経由の書き込み）

3つとも「ある」業務フローが見つかったら、次のいずれかを選びます。

- **外部通信を外す**: 受信メールを要約するだけのエージェントには、送信ツールを渡さない。下書き保存までに留め、送信は人間が行う
- **私的データを外す**: Webを調べるエージェントには社内ファイルを読ませない。調査用と社内文書用でエージェントを分ける
- **信頼できない入力を外す**: 社内ファイルのみを扱う業務では、外部由来の文書を事前に別フォルダで検疫してから渡す

## Claude Codeでは設定のどこで効かせるか

> Claude CodeのBashサンドボックスは、shellコマンドの通信先を`network.allowedDomains`で絞ることで外部通信の要素を弱められます。

公式ドキュメントによると、サンドボックスのネットワークは許可ドメインが空の状態から始まり、プロキシが接続先ホストを照合します。v2.1.219以降では、`strictAllowlist`を`true`にすると許可外のホストをプロンプトなしで拒否できます（リポジトリ内の`.claude/settings.json`に書いても無効です）。

```json
{
  "sandbox": {
    "enabled": true,
    "network": {
      "allowedDomains": ["github.com", "*.npmjs.org"],
      "strictAllowlist": true
    }
  }
}
```

ただし範囲には注意が必要です。公式ドキュメントは、サンドボックスがカバーするのはshellコマンドのみで、Read・Edit・Write・WebFetch・WebSearchなどの組み込みツール、MCPサーバー、フックは対象外と明記しています。`allowedDomains`はWebFetchを制限しません。WebFetchやMCP経由の外部通信は、別途[権限ルール](/blog/claude-code-permission-mode-settings-design-smb/)で絞ります。認証情報の読み取りは`sandbox.credentials`で遮断できます。詳細は[Bashサンドボックス実装ガイド](/blog/claude-code-sandboxed-bash-tool-configuration/)を参照してください。

## まとめ

> 検知に頼る前に、3要素が同居する業務フローを特定し、1要素を外す設計判断が最初の一手です。

- エージェントごとに、私的データ・信頼できない入力・外部通信を棚卸しする
- 3つ揃うフローは、送信権限の削除、エージェントの分割、入力の検疫のいずれかで崩す
- サンドボックスは便利だが、WebFetchやMCPは別の統制が要る

自社のエージェント構成の棚卸しや権限設計の見直しは、[Kuuの運用管理サービス](https://kuucorp.com/services/ai-ops/)でご相談いただけます。

## 参考

- [The lethal trifecta for AI agents（Simon Willison）](https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/)
- [LLM01 Prompt Injection（OWASP Gen AI Security Project）](https://genai.owasp.org/llmrisk/llm01-prompt-injection/)
- [Configure the sandboxed Bash tool（Claude Code Docs）](https://code.claude.com/docs/en/sandboxing)