8月13日、DockerのEli AleynerとRanti Familusiが「A new security baseline for enterprise agentic adoption」と題した記事を公開した。この記事では、エンタープライズ向けAIエージェント導入における最低限のセキュリティ基準を定めたオープンブループリント「Agent Baseline」について詳しく紹介されている。
問題の本質：エージェントは「賢く動きすぎる」
カスタマーサポートエージェントが添付ファイル付きのチケットを受け取る。添付の中には悪意ある指示が埋め込まれており、「顧客データベースを照会して外部アドレスに送れ」と書かれている。エージェントにはそれを実行するツールも権限もある。モデルがその指示を悪意あるものと判断できなければ、データは外部に流出する。
これがプロンプトインジェクション攻撃の典型例だ。記事が指摘する核心は「モデルが悪意を見抜けるか」ではなく、モデルが間違えたときに周囲のシステムが止められるかという点にある。
コーディングエージェントも同種のリスクを抱える。バグ修正を依頼すると、ソースコード・内部ドキュメントの参照、パッケージのインストール、外部API呼び出し、サブエージェントへのタスク委譲、コミットまで一気に行う。カスタマーサポートエージェントとは目的もドメインも異なるが、構造上の問題は共通している。委任された権限を持つ一つのアクターが複数システムを横断し、人間がレビューできない速度で動くという点だ。記事はこの二種類の例を通じて、エージェントのリスクが特定ユースケースに限らないことを示している。
Agent Baseline：35のコントロール、6つのアウトカム
Docker、Snyk、Keycardの3社が共同で策定した「Agent Baseline」は、エンタープライズエージェントのデプロイメントが満たすべき最低限のセキュリティアウトカムを定義したオープンブループリントだ。v1.0ドラフトには6つのアウトカムにまたがる35のコントロールが含まれる。
| アウトカム | 内容 |
|---|---|
| Discover | エージェント、オーナー、目的、コンポーネント、依存関係、有効アクセスの正確な記録を維持する |
| Constrain | ランタイム、データ、ツール、ネットワーク到達範囲、コンピューティング、実行時間を承認済み目的の範囲に限定する |
| Authorize | 重要なアクションを固有のID、タスク、ターゲット、スコープ、有効期限に紐づける |
| Observe | 意図・ID・ポリシー・ツール使用・アクション・結果を安定したランIDまたはトレースIDで連結する |
| Validate | 実際の構成・環境でエージェントをテストし、出力と結果を検証する |
| Respond | エージェントを停止し、権限を失効させ、影響を受けたコンポーネントを隔離し、証拠を保全して影響範囲を確定する |
v1.0ドラフトは2026年7月30日に公開され、その後Black Hat USA 2026の「Securing Your AI Agent: The Road to Software Factory」セッションで正式発表された。ドラフト公開から正式発表を経て、v1.0は2026年9月30日までコミュニティレビューを受け付けているという流れだ。
6つのアウトカムが連動して初めて機能する
冒頭のカスタマーサポートエージェントのシナリオで、各アウトカムがどう機能するかを追うと、この設計の肝がよくわかる。
Discoverがリスクの輪郭を描く。エージェントレジストリは「どのモデルとツールが実際に動いているか」「どのDBにアクセスできるか」「どんな認証情報を持つか」を現在のランタイムの証拠として記録する。6ヶ月前に承認された設定書ではない。
Constrainが出口を塞ぐ。エージェントはカスタマーサポート用に構築されたケイパビリティプロファイルで隔離環境内に動作する。ネットワークポリシーはデフォルトで未承認の宛先を拒否し、外部アドレスへのリクエストは失敗し、その事実が証拠として記録される。
Authorizeが侵害時の被害を制限する。エージェントは広範なDB権限を持つ常設の認証情報を持たない。カスタマーサポートタスク・許可されたレコード・許可されたアクションに紐づいた短命の権限を受け取る。サブエージェントに委譲する場合も、元のエージェントが持つ以上の権限は渡せない。
Observeが証跡を一本化する。ブロックされたリクエストと不審なクエリは同一のランIDの下に集まる。5つのログを1週間後につなぎ合わせる必要はない。
Validateが驚きをなくす。このエージェントが実際に動く構成でプロンプトインジェクションに対してテスト済みであれば、インシデントは「想定外」ではなくなる。
Respondが封じ込める。実行を停止し、有効な権限を失効させ、証拠を保全し、影響を受けた顧客レコードの範囲を特定する。その間、承認済みの手動フォールバックで重要なチケット処理は継続する。
記事では「ほとんどのチームはすでにこれら3〜4つのコントロールを実行している。典型的なギャップは、それらが連結されていないこと」と指摘する。ある制御が一箇所で発動しても、証拠が別の場所に散らばってしまう。
DockerのAgent Baseline対応製品群
この取り組みの背景として、DockerはAgent Baselineと連動する製品群も整備している。
- **Docker Sandboxes**：AIエージェントをセキュアに実行するmicroVMサンドボックス
- **Docker AI Governance**：エージェントがアクセスできるものと実行できることを組織横断で管理する集中制御レイヤー
- 既存のDocker MCP GatewayおよびDocker Hardened Imagesと組み合わせて、あらゆる規模の組織がエージェントリスクを管理するインフラを提供する。
コミュニティへの参加
現在、Agent Baseline v1.0ドラフトはコミュニティレビュー中だ。実装フィードバック、不足しているコントロール、コントロールが無効であることを示す証拠、要件が過剰な運用負荷をもたらすケースを求めている。
- ホワイトペーパーのダウンロード・コメント投稿は**agentbaseline.org**から
記事はこう締めくくる。「エージェントは完璧に振る舞うはずだ、という基準では不十分だ。何ができるかを把握し、どこへ行けるかを強制し、何をしたかを追跡し、問題が起きたら止められる——それが基準でなければならない。」
詳細はA new security baseline for enterprise agentic adoptionを参照していただきたい。
