エージェントセキュリティスタック：トランスポート、アイデンティティ、ポリシー、ランタイム

あなたがエージェントを構築していると想像してください。Linearの課題を読み、Gmailからコンテキストを取得し、GitHubのPRを開き、Slackに更新を投稿します。あるいは、オーケストレーターが専門家にタスクを委任するエージェントシステムであり、各エージェントには独自の役割があります。今、すべてを保護する方法を考え出す必要があり、異なる方向に引っ張る複数のブラウザタブが開かれることになります。

あるタブはMCPゲートウェイを販売しています。別のタブは非人間アイデンティティインベントリツールです。また別のタブはプロンプトインジェクションを監視するランタイムガードレールです。さらに別のタブはコネクタプラットフォーム、ポリシーエンジン、そしてAPIキーを完全に置き換えようとする新しい仕様です。これらはすべて「エージェントを保護する方法」への答えのように見えますが、実際には異なる質問に対応しています。

私はKeycardでエージェントのアイデンティティとアクセスに取り組んでおり、エージェントセキュリティソリューションは非常に急速に増殖しているため、何のために何が必要なのか、なぜなのかを把握するのが困難です。この記事はエージェントセキュリティスタックの地図です：各層が何をするのか、どのようなツールが存在するのか、継ぎ目はどこか、そして現在どの層が最も整備されていないのか。

エージェントアイデンティティへの需要

2026年1月、CrowdStrikeはアイデンティティセキュリティスタートアップSGNLを約7億4000万ドルで買収することで合意しました。1か月後、Palo Alto Networksは2026年2月11日にCyberArkの250億ドル買収を完了しました。両社は買収発表時にエージェントアイデンティティの将来についてコメントしました。CrowdStrikeのCEO George Kurtzは次のように述べています：「AIエージェントは超人的な速度とアクセス権で動作するため、すべてのエージェントは保護されるべき特権アイデンティティとなります。」Palo AltoがCyberArkを買収した際、CEOのNikesh Aroraは「AIエージェントの新たな波は、人間、機械、エージェントのすべてのアイデンティティを保護することを要求するでしょう」と述べました。

彼らの言う通りですが、これは問題の始まりであり、終わりではありません。「エージェントアイデンティティ」は一つの質問ではなく、複数の質問であり、その答えはエージェントセキュリティスタックの異なる層に存在します。

なぜ一つのエージェントセキュリティ層では不十分か？

典型的な人間によるAPI呼び出しには一つの制御面があります。ボタンをクリックすると、セッションクッキーがサーバーに送信され、一つの許可チェックで結果が決まります。

エージェント呼び出しチェーンにはそれ以上の面があります。LLMがツールを呼び出すことを決定し、呼び出しはトランスポートを通過し、クレデンシャルが一緒に送られ、受信サービスが呼び出しを承認します。ますます、その「サービス」は別のエージェントであり、それがさらに別のエージェントを呼び出し、3番目を呼び出すというように、各ステップで独自のスコープ付き権限が必要であり、チェーン全体を開始した人間にまでトレース可能でなければなりません。

各面は異なる形で失敗します。トランスポート認証はクライアントが接続を許可されていることを示しますが、ユーザーが何を承認したかは示しません。ポリシーエンジンはルールを評価しますが、クレデンシャルがどのように発行されたかは知りません。ランタイムガードレールは動作を監視しますが、エージェントがアクセスを許可されているものは知りません。これらを一つのチェックにまとめることはできません。重要なものが失われるからです。

それでは、エージェントセキュリティスタックの各層を詳しく見てみましょう。

第1層：トランスポート

トランスポートは玄関です。ここでエージェントまたはクライアントはサーバーと通信することを許可されていることを証明します。

モデルコンテキストプロトコル（MCP）は現在多くの重労働を担っています。MCP承認仕様はOAuth 2.1に基づき、MCPサーバーをリソースサーバーとして扱い、認可サーバーから分離します。ディスカバリは保護リソースメタデータ（RFC 9728）を介して行われます。2025年の仕様改訂では、知っておく価値のある2つの要素が導入されました。2025年6月の改訂では、リソースインジケータ（RFC 8707）が必須となり、あるMCPサーバーに対して発行されたトークンを別のMCPサーバーで再利用できなくなりました。2025年11月の改訂では、段階的なスコープ同意が追加され、クライアントは各操作に必要な最小限のアクセス権のみを要求できるようになり、さらに大規模な動的クライアント登録を置き換えるためのクライアントIDメタデータドキュメントが導入されました。Agent2Agent（A2A）は、エージェント間通信のための独自のプロファイルで同様の問題を解決します。

MCPゲートウェイとプロキシに特化したエージェントセキュリティ製品は、ディスカバリを集中化し、監査ログを追加し、トランスポート境界でポリシーを適用します。そのようなプラットフォームは1つのトランスポートに結合されています。MCPを中心に構築されたゲートウェイは、エージェントがA2Aで通信したり、REST APIを直接呼び出したりする場合には制御を行使しません。

トランスポート層で動作するセキュリティソリューションは、このクライアントが接続を許可されているかどうか、およびクライアントのトークンがこのリソースに対して有効かどうかを示します。

トランスポート層ソリューションは、ユーザーがこの特定のアクションを承認したかどうか、誰が実際に呼び出しの背後にいるのか、またはエージェントが今これを行うべきかどうかを示しません。

第2層：アイデンティティと委任

この層は最も整備が遅れており、現在最も活発な領域です。アイデンティティ層での質問は次のとおりです：このエージェントは誰か？エージェントは誰のために行動しているのか？エージェントはどのタスクを実行しているのか？

長期間有効なAPIキーはこれらの質問のいずれにも答えません。環境変数内の静的なトークンは「この文字列を持つ者は誰でも認可される」と言っているに過ぎません。リクエストの背後にあるユーザー、認可されたタスク、または認可がまだ有効かどうかを教えることはできません。

この層にはいくつかのソリューションがあり、それらを混同することがこの領域が混乱している理由の一つです。

ワークロードアイデンティティ：SPIFFEとSPIREはワークロードに暗号アイデンティティを提供し、サービスが共有秘密なしで自分が誰であるかを証明できるようにします。クラウドプロバイダーはマネージドワークロード向けに独自のバージョンを提供しています（AWS IAM Roles Anywhere、GCPワークロードアイデンティティ、VercelのOIDCトークン）。これは他のすべての前提条件です；これがなければ、ベアラートークンに戻ることになります。しかし、ワークロードアイデンティティだけでは委任に対処できません。ワークロードが本物であることは示しますが、ワークロードが誰のために行動しているかは示しません。ランタイムアテステーションと組み合わせることで、一部のプラットフォームは静的クレデンシャルを完全に排除できます。エージェントのアイデンティティはディスク上の秘密ではなく、ランタイム環境から得られます。

委任プリミティブ：RFC 8693 OAuth 2.0トークン交換はここでの基本標準です。クライアントは自身のアイデンティティとサブジェクトトークンをセキュリティトークンサービス（STS）に提示します。その見返りとして、特定のダウンストリームリソースにスコープされた新しいトークンを受け取ります。

新しいIETFドラフト「エージェントのためのトランザクショントークン」は、Txn-Tokensにアクターとプリンシパルフィールドを拡張します。アクターはアクションを実行するエージェントであり、プリンシパルはエージェントが代わりに行動する人間またはシステムです。

Dick HardtのAAuth提案はさらに進んでいます。すべてのエージェントは独自の暗号アイデンティティを持ちます：署名キーにバインドされたエージェント識別子（aauth:local@domain）、既知のURLで公開され、事前登録や共有秘密なしに任意の当事者によって検証可能です。これらはプロトコルであり、製品ではありません。システムはそれらの上に構築されます。

クレデンシャルブローカー：これらの製品はSaaS APIのOAuthフローを処理し、エージェントにトークンを提供します。エージェントが20のSaaSサービスと通信する必要があり、20のOAuthフローを自分で管理したくない場合に便利です。一部の製品は、スコープレベルのガバナンス、ジャストインタイム確認、またはきめ細かな承認を追加します。しかし構造的に、クレデンシャルブローカーはアイデンティティ、委任権限、エージェントアテステーション、ポリシーをクレデンシャル発行時の単一のポリシー評価に融合するものはありません。クレデンシャルは最初にブローカーされ、ポリシーが存在する場合、それは別途評価されます。

エージェントのための統一アイデンティティとアクセス：Keycardはこれを提供します。ユーザーアイデンティティはOkta、Entra、Google、または任意のOIDCプロバイダーからフェデレーションされます。ワークロードアイデンティティはAWS、GCP、Vercel、GitHub Actionsなどからフェデレーションされます。エージェントアイデンティティはワークロードアテステーションを通じて確立され、エージェントを検証済みのランタイム（SPIFFE、Kubernetesサービスアカウント、クラウドインスタンスID、mTLS）にバインドします。セキュリティトークンサービスはOAuth 2.1と拡張を実装し、エージェントがアクセスを要求した時点でポリシーを評価します。チームはSDKを介して統合でき、直接STS呼び出しまたはMCPゲートウェイを介して行います。エントリポイントに関わらず、同じ認可コンテキストとポリシーエンジンが背後で動作します。

これはエージェントユースケース向けに再設計されたIAMと考えることができ、主体は人、ワークロード、または人間に代わって行動するエージェントのいずれかです。同じシステムが3つすべてを処理します。

アイデンティティと委任層は、誰が行動しているか、誰のために、どのような権限で、どのタスクのために行動しているかを示します。

この層は、エージェントがクレデンシャルを取得した後に具体的に何を許可されているかは示しません。それは次の層です。

第3層：ポリシー

ポリシーは、特定のコンテキストでの特定のアクションが特定のリソースに対して許可されるかどうかの問題です。アイデンティティとポリシーは異なる質問に答えます。アイデンティティはエージェントが誰かを示し、ポリシーは彼らが何かを許可されているかどうかを示します。

独立したポリシーエンジンがこの層を占めています。AWSはCedarをオープンソース化しました。これは形式的に検証可能で強く型付けされています。Open Policy Agentは長年存在するRegoベースのエンジンです。OpenFGAは関係ベースのアクセス制御に焦点を当てています。AuthZENは、ベンダーニュートラルなPDP/PEPクエリプロトコルのための新しいOpenID標準であり、相互運用性を促進します。

ここでの古典的なデプロイメントパターンはPDP/PEPです：ポリシー決定ポイント（PDP）は「これは許可されるか」に答え、ポリシー強制ポイント（PEP）はリクエストパスに立ってアクションを許可または拒否します。このパターンは、すでに存在するクレデンシャルに対して設計されており、それを尊重するかどうかを決定する必要があります。

その前提は重要です。

アイデンティティ、アクション、リソース、およびいくつかのコンテキストが与えられると、ポリシーはアクションが許可されるかどうかを決定します。

ポリシーは、クレデンシャルがどのようにそこに到達したか、またはアクセス評価後に何をすべきかを教えてくれません。

第4層：ランタイム行動とガバナンス

最後の層は最も混乱しており、人々が一緒にまとめている3つの異なる問題に対処します。

ランタイムガードレール：ジャストインタイムのガードレールを提供するソリューションは、エージェントが何をしているかを監視し、プロンプトインジェクション、ツールポイズニング、ジェイルブレイク、および行動異常をフラグします。これらはコンテンツに対して動作し、アイデンティティではありません。ガードレールはエージェントが悪い振る舞いをしていることを教えることができますが、エージェントがそもそもアクセス権を持つべきかどうかは教えられません。

非人間アイデンティティインベントリ：これらのソリューションは、環境内のすべてのAPIキー、サービスアカウント、OAuth許可を棚卸しし、過剰権限、古いもの、共有されているものを教えます。これらは姿勢管理です。すでに存在するクレデンシャルについて教えますが、リクエストパスでクレデンシャルを発行または評価しません。

監査と委任チェーン：これらは何が起こったか、誰が承認したか、クレデンシャルが何を許可するかをキャプチャするログです。この層のほとんどのツールはアクションの後にこれを再構築します；一部は前にキャプチャします。

ランタイム行動とガバナンスは、エージェントがすべきでないことをしているかどうか、環境にどのようなクレデンシャルが存在するか、およびエージェントが事後に何をしたかを教えます。ガードレールはランタイムで一部の攻撃タイプを防ぐことができます。

しかし、この層はエージェントがそもそもアクセス権を持つべきかどうかを教えません。

プロトコル層は急速に動いている

過去18か月間で、プロトコル面は実際の変化を経験しました。MCP承認仕様は1年足らずで3つのバージョンを出荷しました。A2Aは独自の認証プロファイルを持っています。RFC 8693トークン交換は2020年から存在しますが、突然エージェントシナリオで新しい仕事をしています。「エージェントのためのトランザクショントークン」は2026年2月に4番目のIETFドラフトを出荷しました。AAuthはエージェントアイデンティティに対する新鮮な見解で登場しました。AuthZENはポリシークエリをベンダーニュートラルにすることで同じことを行っています。

エージェント認証がトランスポート内に構築されている場合、トランスポートの変動があなたの変動になります。MCPゲートウェイは最も明確な例です：それらはMCP境界でポリシーを集中化します。すべてのエージェントトラフィックが永遠にMCPであるならそれは素晴らしいですが、非MCPプロトコルが必要な場合は問題です。仕様が改訂されるたびに、ゲートウェイを更新する必要があります。新しいトランスポート（A2A、AAuthの署名付きHTTP、来月出荷される名前のないもの）はすべて、デプロイする新しいゲートウェイです。

エージェント認証がトランスポートの下に構築されている場合...