AIエージェントとKubernetesを組み合わせて本番運用する現場で、静かに広がっている問題がある。人間のエンジニアに発行してきたAPIキーの仕組みを、そのままAIエージェントの認証にも流用してしまうことだ。しかし、この延長線上の設計は遅かれ早かれ破綻する。本稿では、Kubernetes上でMCP（Model Context Protocol）サーバーを運用する際になぜ静的シークレットが限界を迎えるのか、そしてKeycloakとSPIFFE/SPIREを組み合わせた「キーレス」な認証設計がどう現実解になり得るのかを整理する。
なぜAIエージェントに「鍵」を持たせてはいけないのか
人間のエンジニアの認証は、1日に数回ログインし、パスワードやMFAを都度入力するというモデルを前提にしてきた。シークレットの漏洩リスクは「たまにログインする少数のアカウント」を守れば大部分をカバーできた。
ところがAIエージェントはこの前提を崩す。1つのエージェントが1秒間に何十回もAPIを呼び出し、タスクに応じて新しいインスタンスが動的に増減する。不審な挙動として気づけていたログインパターンも、エージェント間の呼び出しに紛れると識別が難しくなる。
業界でも、AIエージェントは「人間のユーザー」でも従来の「非人間型ワークロード」でもない、新しい第三のアイデンティティ区分として扱うべきだという議論が広がっている。実際、AIエージェントに関わる「アイデンティティと権限の濫用」は、エージェント型アプリケーションのセキュリティ課題の中でも上位に位置づけられている（AI Agent Identity Management: A 2026 CISO Playbook）。
静的シークレットが引き起こす典型的な事故パターン
- 影響範囲の拡大: 1つのAPIキーが複数のエージェント・タスクで使い回され、漏洩時の被害範囲が予測できない
- ローテーションの形骸化: 「動いているから触りたくない」という理由で、鍵の更新が先送りされ続ける
- 監査証跡の欠如: 「誰が」ではなく「どのキーが」しか記録されず、原因追跡が困難になる
マネージドK3s環境では、証明書・シークレットのライフサイクル管理をどう仕組み化するかが避けて通れないテーマになる。Kubo のようなマネージドK3sサービスでは cert-manager が標準搭載されており、証明書の発行・更新の仕組みが最初から組み込まれている。
MCPサーバーの認証で静的シークレットが限界を迎える理由
MCP（Model Context Protocol）は、LLMベースのAIエージェントが外部ツールやAPIと接続するオープンな標準規格だ。MCPの公式仕様では、保護されたMCPサーバーはOAuth 2.1のリソースサーバーとして振る舞い、アクセストークンを検証する役割を担うと定義されている（Model Context Protocol Authorization仕様）。
問題は、このOAuthクライアント認証の部分に、従来型の「長期間有効なクライアントシークレット」をそのまま当てはめてしまうケースが多いことだ。クライアントシークレットは本質的に「めったにローテーションされない」静的な共有情報であり、ログや設定ファイルへの誤コピーといった人為的ミスによる漏洩リスクを常に抱える（Authenticating MCP OAuth Clients With SPIFFE and SPIRE）。
さらにMCPサーバー特有のリスクとして、ツールの説明文に悪意のある指示を埋め込む「ツールポイズニング」や、承認後にツールの挙動がひそかに書き換えられる問題も指摘されている。現実的な防御策として、静的トークンを「短命でスコープが限定されたアクセストークン」に置き換えるOAuth 2.0ベースの認証と、ツール単位のきめ細かな認可を組み合わせる「二本柱」のアプローチが提案されている（Securing MCP Servers: A Comprehensive Guide）。
つまり、MCPサーバーの認証を「静的シークレットを配って終わり」にする設計は、エージェントの数が増えるほど破綻の確率が上がる構造的な欠陥を抱えているということだ。
Keycloak・SPIFFE/SPIRE・OPAで「キーレス」を実現する設計
この問題への現実的な回答が、静的シークレットの代わりにワークロード自体の暗号学的なアイデンティティを認証の起点にする設計だ。
SPIFFE（Secure Production Identity Framework For Everyone、非人間型ワークロードにも暗号学的な身元を発行する標準仕様）は、CNCFがGraduatedプロジェクトとして認定しており、SPIRE はそれを実装するランタイムだ。各ワークロードには短命で検証可能な識別子（SVID）が発行され、SPIREがそのライフサイクル（発行・検証・ローテーション）を自動管理する（SPIRE Concepts | SPIFFE公式ドキュメント）。
この仕組みとKeycloakを組み合わせる実装も具体化しつつある。Keycloakは2026年のリリースで、Kubernetes ServiceAccountトークンを静的シークレットの代わりにクライアント認証の資格情報として使えるFederated Client Authenticationをプレビュー機能として搭載した（Keycloak 26.5.0 released）。さらにSPIRE発行のJWT SVIDを検証するカスタム認証拡張をKeycloakのSPIモデル上に実装し、MCPクライアントが「短命かつ自動ローテーションされる」資格情報だけでOAuth認証を完結させる実証も報告されている（Authenticating MCP OAuth Clients With SPIFFE and SPIRE）。
認証（誰が呼んでいるか）が確立された後は、認可（何をしてよいか）の判断が必要になる。ここで使われるのがOpen Policy Agent（OPA）だ。OPAはKubernetesのアドミッションコントロールにとどまらず、宣言的なポリシー言語でAPIサーバーやアプリケーション側の認可判断を統一的に扱える汎用ポリシーエンジンとして、CNCFエコシステムで広く採用されている（Open Policy Agent 公式ドキュメント）。
この「SPIRE（アイデンティティ発行）→ Keycloak（トークン交換・認証）→ OPA（認可判断）」という3層構成にすることで、静的な鍵をどこにも配布しない「キーレス」なMCPエージェント認証が実現できる。実際、業界の議論でも「静的な資格情報ファイルをゼロにし、人手で作成するKeycloakクライアントもゼロにする」ことを明確な設計目標に掲げる動きが出てきている（KeycloakCon Japan 2026: Navigating cloud native identity and the AI frontier | CNCF）。
マネージドK3s環境でこの構成を実践する場合、証明書・トークンのライフサイクルをクラスタ横断で可視化できるかが運用上の鍵になる。Kubo Cloud はRancherベースの管理基盤を備え、マルチクラスタでの証明書・アイデンティティ関連の状態を把握できる点が、こうしたゼロトラスト設計との相性がよい。
「AIエージェント専用の新しいID基盤」は本当に必要か
AIエージェントの台頭を受けて、「エージェント専用の新しいアイデンティティ基盤が必要だ」という主張も増えている。しかし、これは半分正しく半分は行き過ぎだ。
認証・認可・監査証跡・権限委任という要素そのものは、長年アイデンティティ業界が向き合ってきた古典的な課題であり、AIエージェントによって根本から変わったわけではない。むしろ課題になるのは、人間→エージェント→別のエージェント→APIという「権限の連鎖」が長くなったときに、途中でなりすましが起きても検知できるかという点だ。
この文脈で近年注目されているのが、トークンの委任連鎖を安全に扱う「Identity Assertion JWT Authorization Grants（ID-JAG）」のような仕組みで、権限が本来意図しない主体に渡ってしまう「Confused Deputy（混乱した代理人）」問題への対策として議論されている（KeycloakCon Japan 2026: Navigating cloud native identity and the AI frontier | CNCF）。MCPのガバナンスも、OAuth 2.0のトークン委任・交換・きめ細かなスコープ制御といった既存の標準技術の組み合わせで「プロダクションレディ」な水準に到達できるという見方が有力になりつつある。
つまり、ゼロから専用基盤を作り込む前に、Keycloakのような既存のID基盤をSPIFFE/SPIREやOPAで拡張するアプローチを検討する価値は十分にある。データ主権や監査要件が厳しい業種であれば、認証基盤ごと自社管理下に置けるKubo On-Premise が現実的な受け皿になる。
まとめ
AIエージェントの運用が本番規模に拡大するほど、認証基盤の設計ミスは静かに、しかし確実に効いてくる。人間向けの静的シークレット運用をそのまま流用するのではなく、SPIFFE/SPIREでワークロードのアイデンティティを暗号学的に発行し、KeycloakとOPAで認証・認可を分離して扱う「キーレス」な設計を最初から前提に組み込んでおくことが重要だ。
AIエージェントを組織の一員として本番稼働させるには、こうした認証基盤を含めた堅牢なインフラが不可欠になる。Kubo のK3sベースのマネージドKubernetes基盤の上で、Captain.AI のようなAIエージェント実行基盤を安全に動かす発想は、AI時代のインフラ戦略として今後さらに重要性を増していくだろう。