エージェントベースライン：35のコントロール、まず何から始めるべきか？

2週間前、DockerおよびKeycardとともにAgent Baselineを公開しました。そこでは、6つのセキュリティ成果、35のコントロール、そして企業規模でAIエージェントを運用するためのオープンなリファレンスアーキテクチャを紹介しています。先週、私たちはこれを徹底的に検証しました。Black Hatのパネルに持ち込み、約1時間にわたって厳しい質問を受けたのです。

Play Video: Snyk x Docker x Keycard | Agent Baseline Panel @ Black Hat 2026

最も有益だったのは、すでに内容を読んだ人からの質問でした。その人は、こんな趣旨のことを言いました。「内容には納得です。でも、月曜日になったら何をすればいいのか、まだわかりません。」

もっともな指摘です。きちんと答える価値もあります。この質問は、私たちがこの文書であえて取り上げなかったことを示しているからです。また、Baselineがまだ意見募集中の今、読者に見つけてもらいたいと考えている課題でもあります。

混迷は現実です。私たちはその真っただ中にいます

AIエージェントのセキュリティ対策を調べ始めると、主張の壁にすぐ突き当たります。Snykを含め、市場のベンダーはどこもエージェントのセキュリティを解決すると訴えるからです。それぞれの説明は、確かに現実の課題を捉えています。しかし、問題のどの部分を指しているのか、また、その対策が残りの必要な対策とどうつながるのかは、ほとんど明確にされていません。

ただし、これは不誠実さの問題ではありません。市場の形成が、共通の用語が整うよりも速く進んだことの表れにすぎません。現在、「エージェントガバナンス」は売り手によって少なくとも5通りの意味で使われています。買い手には、2つの製品が重複するのか、補完し合うのか、それとも両者の間に誰も言及していない（さらに懸念されるのは、誰も気づいていない）ギャップがあるのかを判断する確かな方法がありません。

これは双方にとっての課題です。ベンダーは、自社がどこで価値を提供し、顧客のアーキテクチャの他の部分とどう連携するのかを明確に伝えたいと思っています。しかし、共通の用語がなければ、結局は他社と区別のつかない主張になってしまいます。

実務担当者に必要なのは、ベンダーの説明を解読する手がかりだけではありません。6つの成果に照らし合わせれば、外部のソリューションを探すべき領域と、すでに社内に強みがある領域を把握できます。これは、購入するか内製するかという議論です。ギャップに名前が付いていれば、ずっと話し合いやすくなります。

どちらも「エージェントガバナンス」として販売されている2つの製品を例にしましょう。どちらの説明も正確です。

1つ目はネットワークの境界で機能します。エージェントが外部に行うすべての呼び出しを監視し、その内容を検査して、ポリシーに基づいてブロックできます。顧客情報を含むリクエストが不適切な場所に送られたことを検知できます。しかし、その指示をそもそもエージェントに仕込んだスキルファイルがどれかはわかりません。そうした情報は、この製品の監視範囲を通らないからです。

2つ目はIDレイヤーです。利用の都度、短期間かつ範囲を限定した認証情報を仲介するため、あらゆるアクションについて、誰がどの権限で開始したのかを検証できます。エージェントが実行した操作を許可されていたことは、正確にわかります。しかし、その操作が適切な判断だったかどうかはわかりません。

両方を6つの成果に照らし合わせると、1つ目はConstrainとObserveの一部を、2つ目はAuthorizeをカバーします。どちらも誇張しておらず、互いに重複もしていませんが、両者の間にはValidateが手つかずで残ります。攻撃を受けたときにエージェントが安全に動作するか、また、生成したものが適切かどうかを、誰も検証していません。両方を導入した買い手が「エージェントガバナンスは整った」と考えるのは当然ですが、どちらの営業プロセスでも話題にならなかったため、この点について一度も議論したことがありません。

Baselineは、まさにこの比較を可能にするために作成されました。製品カテゴリーではなく、組織が達成すべきセキュリティ成果、つまりDiscover、Constrain、Authorize、Observe、Validate、Respondに基づいて課題を定義しています。どのプラットフォーム、製品、社内開発の仕組みも、この6つに照らし合わせれば、どこに強みがあり、どこで補完的なソリューションが必要になりそうかをすぐに把握できます。

十分に重視できていなかったのは、導入の順序です。6つの成果と35のコントロールは網羅性の評価にはなりますが、それだけでは計画とは言えません。（少しヨーダ風の言い回しになってしまいましたが、この言葉遊びは順序の重要性も示しています。意味は網羅されていて理解できますが、順序が違うと把握するのに余計な時間がかかります。）

この文書を今、やることリストとして読んでも、取りかかれないでしょう。始めることが、2年がかりのプログラムに見えてしまうからです。そこで、私たちが示すべきだった導入の順序をご紹介します。

まだソフトウェアファクトリーを運用している組織は多くありません

私たちの見立てをBlack Hatのパネルでも確認できました。現在、ソフトウェアファクトリーを運用している企業はごくわずかで、実際の規模で構築を進めている企業も多くありません。これは率直に伝えておく価値があります。まだそこまで到達していない組織にとって、リファレンスアーキテクチャは非難のように感じられることがあるからです。そうではありません。実現に向けて動き出したばかりの組織（大半がそうです）にとって、これは構築の土台になります。セキュリティを自動化や生産性向上に後から対応するのではなく、あらかじめ備える役割として位置づけられます。

抜けていた視点はユースケース

この文書では、ノートPC上のコーディングエージェントから、午前3時に依存関係へパッチを適用する無人サービスまで、自律性の段階をたどります。これは、コントロールが存在する理由を説明するには適しています。しかし、どのコントロールを先に導入するかを決めるには適していません。ほとんどの組織は、単一の段階を上っているのではなく、「エージェント」とひとまとめにされる、さまざまな仕組みを同時に運用しているからです。

私たちが目にする事例の大半は、次の3つのパターンに当てはまります。

1. 開発者向けコーディングエージェント。組織内の誰かがコーディングエージェントをダウンロードし、実際のリポジトリで実行します。
2. 社内共有エージェント。1つのエージェントを多くの従業員が利用します。たとえば、人事アシスタント、経費承認エージェント、オペレーション支援コパイロットなどです。
3. 本番環境のエージェント。顧客、取引、記録システムに対してアクションを実行するエージェントです。多くの場合、人間が介在する機会はごくわずかです。

つまり、35のコントロールがあっても、適用される順序は大きく異なります。すべてを1つのプログラムとして扱い始めると、問題が生じます。最初のパターンで最も重要なコントロールは、3つ目のパターンではほとんど意味がなく、その逆も同様だからです。順序を間違えると、実際のリスクがまったく別の場所にあるのに、エージェントレジストリの構築に何カ月も費やすことになります。

開発者向けコーディングエージェント：まずConstrain、次にDiscoverで調整

ここではまず、すべてのエージェントを見つけてから対策を決めるべきだ、と考えるかもしれません。しかし、このユースケースでは、それは誤った始め方です。文書では、その理由を一文で説明しています。エージェントが、強制力のある制御のないホスト上で実行されているなら、レジストリや承認ワークフローを整えても何の効果もありません。

実際にはこうなります。開発者がコーディングエージェントをインストールすると、フォルダーの読み取りやコマンドの実行のたびに許可を求めてきます。プロンプトが何度も表示されると煩わしくなり、開発者はよく使うコマンドを許可し、ファイルシステムへのアクセス範囲を広げ、場合によってはサンドボックスを無効にします。その結果、エージェントは開発者権限で動く通常のプロセスとなり、そのシェルからアクセスできるものすべてに到達できるようになります。

アクセスは、接続のたびに広がっていきます。GitHubがOAuthフローを開始し、クラウドツールが既存のログイン情報を見つけ、MCPサーバーがトークンを要求し、SSHがマシンに読み込まれている鍵を使う、といった具合です。おわかりでしょう。

個々のステップはそれぞれもっともらしく見えます。しかし最終的には、互いの状況を把握できない複数のシステムにまたがる広範な権限をエージェントが持ち、ログにはすべて開発者が実行したと記録されます。

まず境界から始めましょう。実行環境の分離と、ユースケースに応じた権限プロファイル（CON-03、CON-04）を使い、各クラスの作業に必要な権限だけをエージェントに与えます。定義とバージョン管理は中央で行い、エージェント自身が編集できないようにします。次に、MCPサーバー、スキル、プラグイン、モデル、ツールをソースとバージョンとともに記録するコンポーネントレジストリ（DIS-04）を整備します。そして、実行時のテスト（VAL-03）も行います。エージェントが生成したコードも、他のコードと同じリリースゲートを通ってサンドボックスの外に出るからです。

意外に思われるかもしれませんが、この対策は開発者の作業を楽にします。利用時に、タスクに必要な範囲に限定された認証情報が仲介されれば、「無害な」コマンドが害を及ぼせなくなるため、エージェントが毎回承認を求める必要がなくなります。同じコントロールでプロンプトが減り、境界も強化されます。これは十分に珍しく、あえて強調する価値があります。

ここで、Discoverが再び重要になります。最初のステップではありませんが、最初のステップをできる限り有効にするためのものです。

権限プロファイルの精度は、その作成に使った情報の精度に左右されます。思い込みで作成すると、2つの失敗につながります。範囲が広すぎると、エージェントはタスクに不要なアクセスを前提に計画を立てます。狭すぎると、ユーザーが「常に許可」を一度ずつクリックして、境界を取り払っていきます。どちらも、状況を確認せずにプロファイルを作成したことが根本原因です。

だからこそ、実際に調べる必要があります。有効なアクセスのマッピング（DIS-06）により、エージェントが実際にアクセスできるIDや認証情報と、それらで何が可能になるかを把握できます。コンポーネントレジストリでは、想定上ではなく実際に使用されているMCPサーバー、スキル、モデルを確認できます。

初日だけで終わりではありません。調整（DIS-07）によって、プロファイルのずれを検知できます。新しいMCPサーバーが追加されたり、ジョブの内容が変わったりするからです。この文書では、Discoverは静的なレジストリではなく、継続的に調整される運用状況のビューであると明記しています。

Constrainは制御を適用し始める場所、Discoverは何を制御すべきかを把握する場所です。両者を順に進めながらも、切り離さないでください。Discoverは制約の定義方法を決めるうえで極めて重要な情報となるため、導入の早い段階で取り組む必要があります。

社内共有エージェント：まずAuthorize

ここではサンドボックス化はほとんど効果がありません。リスクはホスト上での被害の拡大ではなく、「混乱した代理人（confused deputy）」だからです。（これは権限の問題です。Norm Hardyが1988年に提唱した概念で、正当な権限を持つプログラムがだまされ、誤った主体のためにその権限を行使してしまうことを指します。侵害も、隔離からの脱出も、脆弱性の悪用も起きていません。それでも代理人は、誰のために行動しているのかを判別できないのです。）

最も手軽な連携方法は、エージェントに1つのサービスアカウントを割り当て、全員のリクエストをそれ経由で処理することです。すぐに動きます……そこが問題です。すべてのリクエストが、同じアクセス権のプールを使うことになります。リクエストが社内APIに届くころには、送信者が誰なのか追跡できなくなっています。そのため、Aliceのデータを使うプロンプトが、Bob向けの権限を行使することもあり得ます。モデルに作業を分けて扱うよう指示するのは、単なる依頼であって、境界ではありません。

このユースケースでは、権限を仕組みとして確立する必要があります。各アクションの関係者に、個別に検証可能なIDを割り当て、開始した人、または承認済みの自律的な目的にひもづけます（AUT-01）。権限はアカウントから引き継ぐのではなく、タスクに応じて制限します（AUT-02）。最小権限の原則でアクセスの範囲を制限し、委任によって、権限を行使する理由、対象、期間を限定します。さらに、権限の縮小を連鎖させ（AUT-03）、後続のエージェントが呼び出し元より大きな権限を受け取らないようにします。

次に、相関付け（OBS-02）が必要です。複数のユーザーが使うエージェントの監査で問われるのは、「何かが起きたか」ではなく、「誰のために起きたか」だからです。リクエストとアクションを結び付ける実行IDがなければ、後からこの問いに答えられません。そして、答えを求められるのは、たいてい後になってからです。

本番環境のエージェント：まずRespond、そしてValidate

顧客や取引に関わるエージェントでは、重要な制御策ほど、必要に迫られるまで導入されないものです。まず、次の問いから始めましょう。今すぐこのエージェントを停止しなければならないとしたら、作業はどうなるでしょうか？

ここで問題なのは、ほとんどのチームがこの問いに答えられないことです。そこにギャップがあります。RES-01では、停止とは新しい作業をブロックし、実行中の処理を止め、委任の連鎖をたどって、それらの処理が作成した認証情報、許可、委任された権限、セッションを取り消すことを意味します。コンテナを削除してもトークンが有効なままなら、何も停止できていません。RES-02では、真に新しい視点が加わります。隔離の単位はホストではなく、コンポーネントであることが少なくありません。悪意のあるスキルファイルや侵害されたMCPサーバーは、数十のエージェント間で共有される可能性があります。また、ディレクトリにファイルを置くだけで利用可能になることもあるため、コピーを1つ削除しても何も解決しません。

次にRES-04です。ほぼどこでも欠けていると私たちが考える制御策で、待てない作業のためのエージェントを使わない代替手段です。ワークフローがエージェントに依存すると、作業を実行する能力はプラットフォームではなくエージェントに移ります。エージェントを止めれば、作業は行き詰まります。どのワークフローに文書化された手動の手順が必要か、その手順をどうするかは、インシデントが起きる前に決めておく必要があります。

そしてValidateの側では、VAL04です。エージェントはアクションを正常に完了しても、結果を誤ることがあります。権限があることと、正しいことは別だからです。特に取り消せないアクションでは、実行後の結果ではなく、確定する前に提案された結果を検証してください。

Snykでは、アーキテクチャのこの部分に力を注いでいます。エージェントのコードや依存関係が健全かどうかだけでなく、実行時にエージェントの振る舞いが権限の範囲内に収まっているか、つまり何が許可され、誰の代理として動き、範囲を逸脱した場合に何が起きるかを重視しています。Baselineには私たちの対象外の領域も数多く含まれていますが、それこそがベンダーに依存しないモデルの意義です。

バランスは、必ずしも妥協ではなく、設計上の選択

不安が高まると、すべてをブロックしたくなるものです。ツールを禁止し、市場が落ち着くのを待ち、「来年また検討しよう」と先送りするのです。

しかし、それではうまくいきません。よく言われる理由だけが問題なのではありません。シャドー導入が続くから（実際に続きます）だけでなく、ブロックすることで、懸念しているものへの可視性が失われる一方、事業部門はそれでも導入してしまうからです。その結果、同じリスクを抱えたまま、得られる情報だけが少なくなります。

反対に、何でも承認して、少し監視を加えただけで「ガバナンス」と呼ぶのは、さらに悪い対応です。エージェントを監視することと、その権限に上限を設けることは同じではありません。

実際に機能するのは、単なる判断というよりアーキテクチャです。Baselineの制御策は、モデルの外側に設けられるよう設計されています。エージェントが指示に従うことを前提にできないからです。これにより、生産性をめぐる議論を現実的に進められます。エージェントをどこまで信頼するかではなく、作業にどれだけの権限が必要かを決め、その上限をエージェントが覆せない場所で適用するのです。その上限の範囲内で、エージェントを動かしましょう。

ここでは、段階的な対応も重要です。「いいえ」とだけ伝える拒否では、再試行や回避策を招きます。一方、理由と、管理された次の手順を示す拒否なら、コンポーネントを登録し、理由を添えて範囲を限定した権限昇格を申請し、独立した承認を得て、実行を終わらせずに範囲内へ戻すことができます。誘導して止めるまでの間には、人が判断する間、実行中の権限をその場で縮小する対応もあります。最初から完全停止に頼れば、あらゆる異常がサービス停止につながります。

まだこの文書に含まれていないこと

Agent Baselineには、まだ2つ欠けている点があります。後から気づかせるのではなく、率直にお伝えしておきたいと思います。

まず、成熟度モデルがありません。制御策は、望ましい状態を示しますが、「成熟度ステージ1で望ましい状態」と「ステージ3で望ましい状態」の違いまでは示しません。これを読む組織はそれぞれ異なる段階にあります。シリーズBの企業とグローバル銀行を同じ基準で評価するカバレッジテストは、どちらにとってもあまり役に立ちません。上記のようにユースケースごとに順序を決めるのは、その取り組みの第一歩にすぎず、完成形ではありません。

さらに、ユースケースの視点はv1.0にまったく含まれていません。Black Hatでの対話などを通じて明らかになったため、ここで紹介しています。レビューのプロセスが機能している証拠とも言えますが、もっと早く気づくべきだったという、より強い根拠でもあります。

読んで、改善に参加してください

私たちは、この出発点に大きな自信を持っています。同時に、Baselineが存在する以前からこの取り組みを管理し、測定してきた人たちがいて、確かな見解とそれを裏付ける実績を持っていることも理解しています。ぜひ意見を聞かせていただきたいのは、まさにそうした方々です。今がその時です。Baselineは9月30日までコメントを受け付けており、その後もオープンソースとして公開され続けます。

Baselineはドラフトで、9月30日までコメントを受け付けています。各制御策には永続的な識別子が付いているため、監査指摘、ポリシー文書、RFPへの回答で引用しても、将来にわたって参照先を確認できます。

この内容に異議を唱えるなら、課題を登録するのが確実な方法です。制御策が実際には機能しない、見落としがある、あるいは実装コストが軽減できるリスクを上回る場合は、まさにそのためにレビュー期間を設けています。目指すのは、誰もが構築と評価の基準として活用できる、ベンダーに依存しない単一のモデルです。

Agent Baselineを確認し、ホワイトペーパーを読んで、GitHubでコメントを投稿し、改善にご協力ください。