本記事は元々 blog.logto.io に掲載されたものです。
2025年はAIの年になりつつあります。LLMとエージェント体験の急速な成長に伴い、私たちはしばしば尋ねられます: この新しい時代をどのように受け入れるべきか？そして、AIエージェントの認証と認可の新しいユースケースは何か？この記事では、典型的なエージェントの体験を探りながら、セキュリティと認証のシナリオを指摘します。
ChatGPTオペレーターエージェントの認証体験
最近、ChatGPTオペレーターを購入し、いくつかの一般的なワークフローを探りました。1つの例としては、東京、日本での宿泊予約でした。オペレーターは、私のプロンプトに基づいて適切な部屋を見つけるのを非常に簡単にしてくれました。
チェックアウト中に、サインインを求められ、再び操作を自分に戻されました。
この体験は私を不安にさせました。エージェントが私の代わりにログインすることはできなかったとしても、オペレーターのブラウザでメールアドレスとパスワードを入力する必要があるということです。つまり、オペレーターを通じてメール（または他のサービス）にログインする場合、資格情報はクッキーに保存されることになります。
OpenAIのオペレーターは、ユーザーの資格情報を一切保存せず、SOC II などのコンプライアンス基準に従っていると述べています。しかし、サードパーティのエージェントが外部サービスとやり取りする場合、セキュリティリスクは大幅に増加します。
一般的に、エージェントにあなたのアカウントアクセスと資格情報を直接与えるのは良い考えではありません。
まだまだ改善の余地があります。次のセクションでは、さまざまな認証と資格情報管理のアプローチについて、その利点と欠点を掘り下げます。
この X Threads が議論するように。
資格情報はどのように扱われ、どのようなセキュリティリスクがあるのか？
AIエージェントに直接資格情報を与える
このアプローチでは、AIがあなたの代わりにプレーンテキストの資格情報（メールアドレスやパスワードなど）を入力します。例えば、AIエージェントがあなたのログイン詳細を要求し、それを入力するかもしれません。
しかし、この方法はセンシティブな情報が露出する可能性があるため、セキュリティリスクがあります。実装が必要な場合は、パスワードマネージャーや秘密管理システムを統合するのが安全です。さらに、資格情報の保存期間を制限することで、漏洩のリスクを最小限に抑えることができます。
プレーンテキストの資格情報の代わりに、パーソナルアクセストークン (PAT) は、パスワードやインタラクティブなサインインを必要としない、より安全なアクセス提供方法を提供します。PATは、CI/CD、スクリプト、リソースにプログラムでアクセスする必要がある自動化されたアプリケーションで役立ちます。セキュリティを強化するために、PATのスコープを制限し、有効期限を設定し、リークとアカウント乗っ取りを防ぐために取り消しを許可することが最善です。
OAuthによるユーザー委任
OAuth (Open Authorization) は、ウェブ上で広く使用されている委任型認可の標準です。ユーザーは、自分のログイン資格情報を共有せずに、別のサービス上のデータへの限定的なアクセスをサードパーティアプリケーションに許可できます。
本質的に、OAuthは安全なアクセス委任の問題を解決します: 例えば、Googleパスワードを提供することなく、旅行アプリにあなたのGoogleカレンダーの読み取りを許可できます。これは、データプロバイダー（例: Google）と認証し、サードパーティアプリにトークンを発行することで、ユーザーの資格情報を公開せずに実現されます。
このシナリオを処理するより良い方法は、ChatGPTオペレーター（または他のエージェント）に、Airbnb上での読み書きを許可し、パスワードや資格情報を共有しないことです。オペレーターに直接ログインさせるのではなく、セキュアな認可プロセスを通じてアクセスを許可できます。
OpenAIオペレーターが信頼とアイデンティティのセキュリティを強化したい場合、いくつかの方法があります。
-
ログインプロセスをオペレーターの外に移す: ChatGPTオペレーターの外でユーザーサインインを処理する。つまり、"[サービス]でログイン"ボタンをクリックすると、そのサービスのセキュアなログインページにリダイレクトされ、チャットやChatGPTオペレーターの完全に外で自分自身を認証します。例えば、Airbnbプラグインがあった場合、Airbnbのウェブサイトに送られて資格情報を入力し、ChatGPTを認可し、次にプラグインがトークンを受け取ります。ChatGPTは実際のパスワードを見ることなく、限定的なアクセス（例: "私の旅程を読む"）を許可する一時的なアクセストークンまたは鍵を受け取るだけです。
-
AIエージェントがタスクを実行する前にユーザーが同意フローを完了する。このアプローチは、多くの製品が統合、マーケットプレイス、接続サービスを処理する方法に似ています。
Notion接続ページここにもう一つの例があります。例えば、Slackのマーケットプレイス統合で、Notionに対する特定のワークスペースへのアクセスを要求しており、記事を読み取ってSlackチャンネル内に表示できます。
同時に、Slackはこのプロセス中にNotionにワークスペースにアクセスするための同意ページを提供します。
ChatGPTオペレーターは、OAuthを統合し、エージェントが複数のサードパーティサービスに安全にアクセスできるようにすることで、同様のアプローチを取るべきです。これにより、必要な権限でのアクセスを許可するトークンを取得し、タスクを安全に実行することができます。
センシティブなアクションのためのステップアップ認証
AIエージェントは、日常的なタスクを独立して自動的に処理できますが、資金の送金やセキュリティ設定の変更などの高リスクなアクションについては、セキュリティを確保するために追加の確認が必要です。これは、多要素認証 (MFA) を通じてユーザーが自分のアイデンティティを確認する方法です。プッシュ通知、ワンタイムパスワード (OTP)、またはバイオメトリックによる確認が可能です。
しかし、頻繁なステップアップ認証はユーザーのフラストレーションを引き起こす可能性があり、特に頻繁にトリガーされる場合には問題です。この新しいパラダイムの中で、エージェント固有の体験はユーザー体験を考慮する必要があります。
ユーザー体験を損なわずにセキュリティを強化するには、アダプティブ認証とMFA を使用して、いつ追加の確認が必要かを決定するべきです。IPの変更や異常な行動などのリスクベースのトリガーが、不必要な認証要求を最小限に抑えるのに役立ちます。
マルチエージェントエコシステムのためのフェデレーテッドアイデンティティとシングルサインオン (SSO)
マルチエージェントの企業エコシステムでは、AIエージェントがさまざまなプラットフォーム間でやり取りする必要があります。認証を簡素化するために、ユーザーはOkta、Azure AD、Google Workspaceなどのアイデンティティプロバイダー (IdP) を通じて一度認証します。エージェントはSAML、OpenID Connect (OIDC)を使用して認証し、ロールベース (RBAC)または属性ベース (ABAC) のアクセス制御を通じてアクセスが管理されます。
このアプローチは、ユーザーが何度もログインする必要をなくし、中央集権的なアイデンティティ管理を通じてセキュリティとコンプライアンスを向上させます。また、エージェントが定義された許可範囲内で動作することを確保する動的なアクセスポリシーを可能にします。
スコープと権限の管理
オペレーターとエージェントはユーザーの代わりに行動できますので、ユーザーに十分な制御を提供し、AIエージェントの権限を慎重に定義することが重要です。従うべき2つの重要な原則は次のとおりです:
- 最小限の特権 – タスクに必要な権限のみを付与する。
- 時間制限付きアクセス – セキュリティリスクを減らすためにアクセス期間を制限する。
ロールベースアクセス制御 (RBAC) は、特定のタスクに特定の役割を割り当て、エージェントのスコープを管理するのに役立ちます。より詳細な制御のために、属性ベースアクセス制御 (ABAC) は、動的でコンテキストに基づく権限管理を可能にし、AIエージェントが必要なときに必要なものだけにアクセスします。
인증 통한 MCP 서버 연결
MCP는 AI 에이전트를 향상시켜 컨텍스트 정보를 제공하여 전반적인 성능과 사용자 경험을 향상시키기 위해 점점 더 인기를 끌고 있습니다.
MCP 서버가 인증과 관련이 있는 이유와 그 이유는 무엇입니까?
이전에 MCP 서버가 무엇인지 이해하는 데 도움이 되도록 다음 기사에서 설명했습니다:MCP 서버란 무엇입니까.
MCP 서버는 모델 컨텍스트 프로토콜의 중요한 부분으로, AI 모델과 외부 데이터 소스 간의 다리 역할을합니다. 이는 Slack, Gmail, Google 캘린더와 같은 서비스에서 실시간 쿼리 및 데이터 검색을 가능하게 합니다. MCP 서버를 구축하면 원격 서비스를 LLM에 연결하여 AI 기반 애플리케이션을 더 나은 컨텍스트와 더 스마트한 작업 실행으로 개선할 수 있습니다.
정보 검색 생성 (RAG) 시스템과 달리, 벡터 데이터베이스에 문서를 저장하고 인덱싱하기 전에는 데이터에 액세스할 수 없습니다. MCP 서버는 데이터를 사전 인덱싱 없이 직접 액세스합니다. 따라서 정보는 더 정밀하고 최신 상태일뿐만 아니라 보안을 손상시키지 않고 최소한의 계산 오버헤드로 통합됩니다.
参考: https://norahsakal.com/blog/mcp-vs-api-model-context-protocol-explained
MCP 서버를 사용하는 AI 에이전트로 인하여 MCP 서버, LLM, 에이전트, 사용자 간의 여러 상호 작용이 발생합니다.
오늘날 AI 중심의 세계에서는 에이전트가 여러 서비스에서 여러 작업을 관리하여 여러 MCP 서버와의 통합이 수요가 증가하고 있습니다.
エージェントの認証は、あなたの製品が適応すべき新興トレンドです
大きな例としては、Composio.dev という開発者向けの統合プラットフォームがあり、AIエージェントとLLMが外部アプリおよびサービスと接続する方法を簡素化します。「ユーザーの代わりに行動するためのAIエージェントの認証」と呼ばれているこのプラットフォームは、AIを基盤とした製品に簡単に統合できるMCPサーバー（コネクタ）を提供します。
認証分野の関係者として、現実には、これはより広範なCIAM（カスタマーアイデンティティおよびアクセス管理）分野の一部に過ぎません。彼らが構築したものは、実際にはMCPサーバー（コネクタ）のコレクションであり、役立つが、全体的なCIAMソリューションのごく一部分でしかありません。
先ほどの例を踏まえ、Google Drive（リモートサービス）をAirbnbではなくMCPサーバーと考えると、単なるサードパーティ統合以上のものとなります。これにより、エージェントにコンテクスト情報へのアクセス、LLMとの対話、作成、読み取り、更新、削除（CRUD）ファイルの許可が与えられる可能性があります。
しかし、コアな認証と認可の要件は変わりません。
Logtoを使用してエージェント製品の認証を処理する
LogtoはSaaSおよびAIエージェント製品をサポートする多用途のCIAMソリューションで、認証と認可を容易にします。その理由は以下の通りです:
- AIエージェント製品のためのマネージド認証 – LogtoはOAuth 2.0、SAML、APIキー、パーソナルアクセストークン、JWTをサポートし、複数のMCPサーバーと簡単に統合できます。開放標準基盤のおかげで独自のMCPサーバーを構築し、Logtoに接続することさえも可能です。
- アイデンティティプロバイダー (IdP) 機能 – 製品に確立されたユーザーがいる場合、LogtoはIdPとして機能し、あなたのサービスをMCPサーバーに変え、AIエコシステムに統合できます。
- 高度な認可
- ユーザー役割を管理するためのロールベースアクセス制御 (RBAC)
- 細かい粒度の動的アクセス管理のためのカスタムJWTベースのABAC
- セキュリティの強化 – 多要素認証 (MFA) やステップアップ認証などの機能は、重要なアクションを保護し、エージェントの安全性を向上させます。
質問がありますか？LogtoがあなたのAIエージェント体験を向上させ、あなたのセキュリティニーズを満たす方法について、私たちのチームにお問い合わせください。