このリクエストをしているのは誰か?エージェント認証の基礎 (Agent Auth 101) - カミル・ポトレツ (Kamil Potrec)、Keycard

Original · Who Is Making This Request? Agent Auth 101 - Kamil Potrec, Keycard

18:353 min readAI Engineer10/28/2026Computing/Software · Internet Technology

Key Takeaway

非決定論的に動作するエージェントの安全性を確保するためには、静的なアクセストークンの使用を廃し、OAuthやゲートウェイを介した動的かつ短命な資格情報の管理システムを導入する必要がある。

Highlights

  • エージェントは非決定論的であるため、従来のような静的なパーソナルアクセストークンや特権的なサービスアカウントをそのまま利用するとセキュリティ上の重大なリスクが生じる。

  • ユーザーのクレデンシャルをそのままエージェントに渡す運用や、エージェントを実行環境内で野放しにする手法は、企業のインフラストラクチャをバイパスされる原因となる。

  • OAuthやワークロードIDフェデレーションなどの技術を活用し、動的でスコープが限定された短命な資格情報をその都度発行する仕組みが必要である。

  • すべての認証情報を安全なエンクレーブやボルトサービスに格納し、APIゲートウェイを介して通信を制御することで、不正なアクセスや過剰な権限行使を防ぐことができる。

  • Keycardが提供する単一のコントロールプレーンや、リファレンス実装を公開しているagentbaseline.orgを活用することで、分散システムにおける複雑なエージェント認証を安全に実現できる。

Timeline

  1. エージェント通信における認証の現状と課題

    エージェントの普及に伴い、ユーザーの代理としてシステムにアクセスするためのトークンやAPIキーの利用が増加している。しかし、これらのクレデンシャルが個人のマシンに放置されたり、サービスアカウントに過剰な権限が集中したりすることで、セキュリティ上の管理が困難になっている。従来の決定論的なソフトウェアと異なり、エージェントは予測不可能な行動を起こすため、従来のセキュリティ前提が通用しなくなっている。

    • エージェントとユーザー、MCPサーバー間の通信において、パーソナルアクセストークンなどの不透明なクレデンシャルが頻繁に使用されている。
    • MCPサーバー側ではリクエストの実行主体がユーザーなのかエージェントなのかを判別できない。
    • エージェントは非決定論的に動作するため、取得したクレデンシャルを用いて意図しないアクションを実行する危険性がある。
  2. エージェント認証における動的アプローチと解決策

    ユーザーが事前に固定のアクセストークンを用意するのではなく、エージェント自身が動的にスコープの限定されたクレデンシャルを取得する仕組みへの移行が求められている。ワークロードIDフェデレーションや秘密鍵認証などの既存技術を適切に組み合わせることで、永続的な特権アカウントへの依存を断ち切ることができる。これにより、エージェントが不必要に広範な権限を持つ状態を防ぎ、安全なシステム間通信を構築することが可能になる。

    • エージェント自身が外部システムから動的な認可を要求する仕組みが必要である。
    • OAuthやワークロードIDフェデレーション、証明書認証などの技術を利用してエージェントに認証を行わせるべきである。
    • レガシーソフトウェアとエージェントはどちらもソフトウェアに過ぎず、従来型のセキュリティパターンを適用可能である。
  3. 大規模環境における認証実装の複雑さとゲートウェイの役割

    数百に及ぶAPIや異なるエージェントが混在する環境では、単一のSDKやクライアント側のコードだけでセキュリティを担保することは不可能である。エージェントが自身の実行環境内で認証情報を探索・悪用するリスクを防ぐため、認証情報を安全なエンクレーブに隔離し、ゲートウェイ経由で通信を仲介するアプローチが取られる。これにより、通信のレイテンシ増加やネットワーク制御の徹底といった課題はあるものの、不正なリクエストのブロックやリアルタイムでのトークン失効が可能になる。

    • 多数のAPIや多様なエージェントが存在する大規模環境では、認証の統合管理が非常に複雑になる。
    • エージェントの実行環境から認証情報を完全に隠すために、専用のボルトサービスとAPIゲートウェイが有効である。
    • ゲートウェイを介してすべてのリクエストを検査・制御することで、即時失効や細やかな権限管理、オブザーバビリティの向上が実現できる。
  4. Keycardによる統合コントロールプレーンと今後の展望

    独自の認証機能を個別に再実装する非効率性を避けるため、Keycardはアイデンティティ付与、システム統合、ポリシー適用、監査機能などを包括的に提供するコントロールプレーンを構築している。エージェントのセキュリティ対策を怠るいわゆる「YOLO実装」を避け、オープン標準を活用して他のシステムと相互運用性を確保することが重要である。興味を持った開発者は、公開されているリファレンス実装やコミュニティを通じて、安全なエージェント基盤の構築に取り組むことが推奨される。

    • Keycardはエージェントにアイデンティティを付与し、トークン発行やポリシー管理を行う単一のコントロールプレーンを提供している。
    • エージェントのセキュリティはもはや任意ではなく、オープン標準に基づいた堅牢な実装が不可欠である。
    • agentbaseline.orgにてリファレンス実装となるソフトウェアファクトリーが公開されている。

Description

When an agent sends an invoice using your token, who actually made the request? Kamil Potrec of Keycard breaks down how agents get credentials today (personal tokens, static keys, over-privileged service accounts) and what proper agent auth requires: per-agent identity, delegation, short-lived scoped credentials, federation with legacy systems, policy and audit. He compares SDKs and gateways for keeping credentials out of an agent's reach, including the gateway tradeoffs. Chapters: 0:00 Intro 0:43 How agents get credentials today 3:46 What's wrong with this picture 5:15 Using OAuth for agents 7:10 Why it gets hard at scale 8:21 What proper agent auth needs 9:52 One request, many steps 11:16 Why SDKs aren't enough 12:37 Gateways: keep credentials away from agents 14:55 Gateway tradeoffs 16:24 How Keycard approaches it 17:26 Takeaways Kamil Potrec https://keycard.ai Agent Baseline: https://agentbaseline.org Join us in SF for the second annual AIE CODE summit: https://aie.codes our last flagship summit of 2026. Applications live now!

Write about this video