資格情報を公開せずにAIエージェントを内部システムに接続する方法

¿資格情報を公開せずに AI エージェントを内部ツールに接続するにはどうすればよいですか? 仕事に就くことを決めたら 社内のAIエージェント真の課題は、エージェントをスマートにするだけでなく、社内ツールに接続する際に認証情報が漏れないようにすることです。コードにCookieを埋め込んだり、プロンプトからユーザー名とパスワードをプレーンテキストで渡したりすることは避けましょう。エージェントがCRM、ERP、メール、カレンダー、データベースにアクセスする場合は、以下の点を考慮する必要があります… アイデンティティ、権限、認証 初日から。

典型的なシナリオは明確です。AIエージェントにサポートの自動化、チケット管理、社内ドキュメントの参照、レポートの作成、インフラ上でのタスク実行などを行ってもらいたいと考えています。そのためには、AIエージェントは… 内部データソースとビジネスサービス難しいのは、広範囲かつ永続的なアクセスを与えると、巨大な攻撃対象領域を持つ自動化された「スーパーユーザー」になってしまうことです。重要なのは、エージェントが 一時的なトークン、非常に限定されたスコープ、そして制御されたチャネルOAuth2/OIDC、MCP サーバー、シークレット マネージャーなどの標準プロトコルに依存し、実際の資格情報を公開することはありません。

資格情報をフィルタリングせずに AI エージェントを内部システムに接続するとはどういう意味ですか?

AIエージェントを社内ツールに接続すると、 アクションを読み取り、実行する CRM、ERP、チケットプラットフォーム、プライベートクラウド、ドキュメント管理システムなどのシステムを介して行われますが、常に明確に定義されたセキュリティレイヤーを介して行われます。ユーザー名とパスワードを入力する代わりに、エージェントは アクセストークン、管理されたセッション、タスク固有の権限.

この文脈では、AIエージェントは単なるフレンドリーなチャットボットではありません。 環境を認識する自律ソフトウェア （ログ、ドキュメント、チケット、メール） 理由 言語モデルまたは特殊モデルと ツールに作用する （API、データベース、ワークフロー）をセキュリティポリシーを遵守しながら構築します。目標は、社内システムとのこの関係を、 API、ミドルウェア、標準プロトコル、中間サーバー ユーザーまたはサービスの資格情報が直接公開されるのを防ぎます。

資格情報を使った即席の解決策のリスク

最も一般的な誘惑の一つは、エージェントに 静的資格情報 （ユーザー名/パスワード）または コードに埋め込まれたセッションCookie 「すぐに機能させるためです。」短期的には実用的に見えますが、中期的には時限爆弾です。資格情報をローテーションしたり、エージェントによるきめ細かなアクセスを取り消したり、誰が何をしたかを監査したりする簡単な方法はありません。

セッションがコードに結びついている場合、 トークンの有効期限、取り消しの不可能性、追跡可能性の欠如 あらゆる統合がビジネス継続性の問題を引き起こします。さらに、ソースコードの漏洩、ログの保護が不十分な場合、あるいはリポジトリ内の不適切なプラクティスによって、本番環境の認証情報が漏洩する可能性があります。そのため、適切なアーキテクチャには、 エージェント向け認証サービスエージェント自身とは別に、登録、更新、取り消し、アクセス記録を管理する組織です。

各エージェントの固有のID：出発点

本格的な設計の基本は、各AIエージェントを 差別化されたデジタルアイデンティティ全員に対して同じ管理者アカウントを共有しない (または共有すべきではない) のと同様に、各エージェントには独自のプロファイル、権限、および追跡可能性が必要です。

そのエージェントのアイデンティティは次のように表される。 企業IdPの技術アカウント （Okta、Azure AD、Google Workspaceなど）、または非対称キーとエージェントを一意に識別する内部レコードを介して認証できます。重要なのは、 役割、スコープ、ポリシーを割り当てる 各エージェントに通知し、そのエージェントが代理を務めるエンド ユーザーに関係なく、誰が社内システムに各通話を発信したかを記録します。

エージェントからの認証を分離する: 資格情報「ブローカー」。

エージェントに認証情報を埋め込む代わりに、エージェントと社内システムの間に[不足している単語/フレーズ]を配置することが効果的です。 コア認証コンポーネントAIエージェントに特化した「セッションブローカー」のようなサービスです。このサービスは以下の処理を行います。

• 問題 一時アクセストークン 範囲が非常に限られています。
• セッションを更新する 各システムのポリシー（時間制限や非アクティブ制限など）に従って。
• マスター資格情報のローテーションシークレット マネージャーに保存されます。
• 登録と監査 エージェントに代わって実行されるすべての操作。

このアプローチでは、エージェントは実際のパスワードやマスターキーを見ることはありません。 要求に応じて発行される一時トークン ブローカーによって許可され、異常な動作が検出されたか、エージェントが非アクティブ化された場合は、直ちに取り消すことができます。

安全な委任のための標準プロトコル: OAuth2、OIDC、SSO

これをサポートするサービスの場合、最も堅牢なアプローチはエージェントが使用することです。 OAuth2 と OpenID Connect (OIDC) 他の最新の統合と同様に、エージェントが対象システムのユーザー名とパスワードを要求する代わりに、 委任フロー 人間のユーザーまたは管理者が、エージェントに特定の権限で動作することを許可します。

実際には、これは次のようになります。

• 人間のオペレーターがクリックすると 「接続」ボタン エージェント構成インターフェースで。
• リダイレクトされます 公式プロバイダーログイン (例: Airbnb、Google、Slack)、エージェントの環境外。
• ユーザーはログインし、特定の権限（「カレンダーの読み取り」、「チケットの作成」など）を付与します。
• エージェントは アクセストークンおよび/またはリフレッシュトークン 承認されたスコープは表示されますが、実際の資格情報は表示されません。

このパターンは、 シングルサインオン（SSO）とフェデレーションIDユーザーはIDプロバイダで一度認証し、エージェントは 中央管理されたトークンSAML、OIDC、ロールベース アクセス制御 (RBAC) または属性ベース アクセス制御 (ABAC) ポリシーを組み合わせることで、各エージェントが実行できる内容、ネットワーク コンテキスト、実行期間を細かく制限できます。

個人アクセストークンとAPIキー：正しい使用方法と制限

いくつかのシナリオでは、社内システムやサードパーティのツールは依然として 個人アクセストークン（PAT） または従来のAPIキー。OAuth2ほど柔軟ではありませんが、正しく使用すれば共有パスワードのより優れた代替手段となります。

重要なのは、これらのトークンが次の点であるということです。

• 持っている 最小範囲 （必須の許可のみ）。
• 含む 明確な有効期限、無期限のアクセスを防止します。
• ショーン シークレットマネージャーでローテーションして保存する (例: AWS Secrets Manager、Azure Key Vault) が適切に管理されている必要があります。
• 彼らは割り当てられています 特定のエージェントID一般アカウントや個人アカウントには適用されません。

繰り返しますが、エージェントはトークンをコードに「縫い付ける」のではなく、必要に応じてトークンを要求する必要があります。 内部認証情報サービス 使用状況を記録し、異常な動作が検出された場合はブロックできます。

秘密管理と自動ローテーション

エージェントを内部システムに接続する際に資格情報の漏洩を避けるには、 秘密のマネージャー 堅牢。これらのサービスを使用すると、暗号化されたキー、証明書、パスワード、トークンを保存し、実行時にそれらを読み取るための安全なAPIを提供できます。

通常のメカニズムの中で、特に目立つのは次のものです。

• 管理されたクラウドボールト: AWS Secrets Manager や Azure Key Vault など、自動ローテーション、バージョン管理、ID ベースのアクセス制御を容易にするサービス。
• きめ細かなアクセス制御 RBAC/ABAC を通じて秘密にアクセスできるため、各エージェントは必要な秘密のみを要求できます。
• 積極的なローテーション ブローカーによって使用され、CI/CD パイプラインとスケジュールされたタスクによってオーケストレーションされるマスター資格情報。

エージェント自体は資格情報をリソースとして扱う 非永続的: ケースバイケースでトークンを要求し、一時的なトークンを交換するために使用し、長期メモリやログには保存しません。

モデルコンテキストプロトコル（MCP）：エージェントをツールに接続するための「USB-C」

資格情報を公開せずにAIエージェントを内部システムに接続するための新しく強力な方法は、 モデルコンテキストプロトコル（MCP）このプロトコルは、当初はAnthropicによって推進され、Microsoftや他のプレーヤーによってすでに採用されており、 言語モデルはデータソースやツールに接続します MCP サーバー経由で。

このアーキテクチャは次の 3 つの部分で構成されます。

• ホストMCP: エージェントまたはモデルが存在するアプリケーション (アシスタント デスクトップ、IDE、エンタープライズ エージェントなど)。
• MCPクライアント: 通常は HTTP/S または同様のチャネル経由の JSON-RPC を介して MCP サーバーと通信するホスト内のコンポーネント。
• MCP サーバー: 公開する小さなサービス リソース、ツール、プロンプト 外部システムまたは内部システムを標準化された方法で管理します。

アイデアとしては、社内システム（データベース、社内Slack、社内メール、SharePointなど）がMCPサーバーを介してAIに「プラグイン」され、 認証を含むすべての低レベルアクセスエージェントは内部システムの資格情報を参照することはなく、特定のパラメータを使用して MCP ツールを呼び出し、フィルタリングされた結果を受け取るだけです。

MCP プリミティブ: リソース、ツール、プロンプト

MCP がどのようにして資格情報の漏洩を防ぐのかを理解するには、次の 3 つの主要な基本要素を分解すると役立ちます。

• リソースこれらは、ファイルの内容、データベースのレコード、Slackのメッセージ、Google Driveのドキュメント、企業APIからのレスポンスなど、読み取り専用でアクセス可能なデータを表します。各リソースはURIで識別され、テキストまたはバイナリとして配信できます。多くの場合、ユーザーまたはアプリケーションはモデルのコンテキストに挿入するリソースを選択するため、エージェントが無差別にすべてのリソースをトラバースするのを防ぎます。
• ツールこれらは実行可能なアクションです（例えば、「このチャネルでメッセージを検索する」、「SQLクエリを実行する」、「チケットを作成する」など）。MCPサーバーは、バックエンドシステムに認証と認可のロジックを実装します。 内部トークンと秘密はモデルに公開されないモデルはツールと入力/出力パラメータの説明のみを参照します。
• プロンプトこれらは、モデルに特定のタスク（例えば、「コードエラーの分析」、「会話の要約」など）をリクエストする方法を標準化する、事前定義されたインタラクションテンプレートです。これらのテンプレートは、関連するリソースを自動的に含めることができますが、常にサーバーによって定義されたルールに従います。

このアプローチでは、ERPやCRMをMCP経由で接続する場合、MCPサーバーはOAuth2、内部トークン、またはVaultに保存されているシークレットを使用して認証情報をネゴシエートします。一方、エージェントは 記述インターフェース 機密性の高い認証データを直接処理することなく作業できます。

MCP との実際の統合: Copilot Studio と Azure AI Foundry

MCP を取り巻くエコシステムは急速に変化しています。 マイクロソフト コパイロットスタジオ例えば、カスタムエージェントをMCPサーバーに、まるで定義済みのアクションのように接続できるようになりました。エージェント作成者はコンソールから、ビジネスツールを公開するMCPコネクタを選択すると、それらのツールが名前、説明、パラメータスキーマとともにエージェントに自動的に表示されます。

Copilot Studioの優れた点は、 独自の企業方針データ制御、DLP、企業認証など。MCPサーバーは、シークレットマネージャーと標準プロトコルを用いて、内部サービスに対する認証を処理します。繰り返しになりますが、エージェントはユーザー名やパスワードには一切触れず、承認済みツールの論理レイヤー内で動作します。

En Azure AI ファウンドリー (旧Azure AI Studio)、Azure AI Agentsで作成されたエージェントは、 外向きのMCPサーバーこれにより、互換性のあるクライアント アプリケーション (Claude Desktop などのアシスタントを含む) は、MCP を介して、既に Bing、Cognitive Search、SharePoint、または内部データベースに安全に接続されている Azure エージェントの機能を使用できるようになります。

セキュリティの観点から、Azureは次の責任を負います。 アイデンティティ、ネットワーク、シークレット、スケーリングを管理するAI エージェントは承認されたツールとリソースのみを参照しますが、内部システムへの実際のアクセス資格情報は、Azure とインフラストラクチャの制御された境界内に留まります。

機密性の高いアクションのための追加認証と適応型MFA

このようなインフラストラクチャがあっても、エージェントが有効なトークンを持っているだけでは不十分な操作があります。例えば、 金銭の移動、権限の変更、重要な記録の削除、大量のデータの流出 彼らには追加の確認が必要です。

このような場合、最善の戦略は、 多要素認証（MFA） y 適応型認証つまり、エージェントは日常的なタスクを自律的に実行できますが、次のようになります。

• 大きな影響を与える操作を行う前に、ユーザーに 追加検証 (モバイル プッシュ、OTP、生体認証)。
• 使用 リスクトリガー (IP の変更、異常なデータ量、異常なスケジュール) に基づいて、MFA をいつ要求するかを決定します。

これにより、ユーザーに何度も確認を求める必要がなくなり、 人間の緊急ブレーキ エージェントが、間違えると深刻な結果を招くようなアクションを実行しようとしているとき。

権限管理: 最小権限、RBAC、ABAC

利便性のためにAIエージェントにすべてのルートアクセス権限を与えることは、重大な脆弱性を排除する最も早い方法です。権限管理は、以下の原則に従う必要があります。 最小限の権限: 各エージェントは、 あなたの機能に必要なもの、他には何もありません。

通常のアプローチは、以下を組み合わせることです。

• ロールベースのアクセス制御 (RBAC): 明確に定義された権限を持つ 1 つ以上のロール (たとえば、「サポート チケット リーダー」、「ナレッジ ベース エディター」、「メンテナンス スクリプト実行者」) をエージェントに割り当てます。
• 属性ベースのアクセス制御（ABAC）: エージェントが実行できる操作を動的に調整するコンテキスト ルール (スケジュール、ネットワークの場所、リソースの種類、データの分類) を追加します。

さらに、 詳細な記録 すべてのツールの呼び出しとアクセスされたすべてのリソースは、エージェントによって、さらにはそのエージェントが代理を務めるエンドユーザーによってタグ付けされます。このトレーサビリティにより、 監査と属性アクション インシデントが発生した場合に備え、規制遵守を実証します。

MCPサーバーおよびエージェント固有の認証製品

エージェントの認証層を簡素化し、 「AIのためのCIAM」一部のソリューションは、数十の一般的な SaaS およびサービス用の MCP サーバーのコレクションとして提供され、認証情報を直接管理することなくエージェントが接続するための標準化された OAuth フロー、PAT、および API キーを提供します。

一方、アイデンティティ製品としては、 ロゴ OAuth2、SAML、JWT、APIキーによる統合認証および認可機能を提供し、 従来のSaaSアプリケーションとAIエージェントベースの製品通常のパターンは次のとおりです。

• エージェントを登録する お客様 アイデンティティシステム内。
• 管理 ユーザーとセッション エージェントと対話します。
• 問題 署名付きトークン バックエンドが機密データを公開することなく検証できるロールと属性情報を備えています。

これにより、エージェントが複数の MCP サーバーまたは API に接続する場合でも、誰が誰であり、誰が何を実行できるかというレイヤー全体を単一のポイントから制御できるようになります。 共通アイデンティティの核さまざまな機能を備えた数十のエージェントを展開し始めるときに非常に便利です。

内部データへの安全な接続: ネットワーク、セグメンテーション、強化

すべてのセキュリティがトークンとプロトコルの論理層に依存するわけではない。AIエージェントが展開されると 企業ネットワーク内ネットワークアーキテクチャと強化にも取り組む必要があり、 ネットワークの安定性を向上特に、インターネット接続のないローカル AI モデルやサーバーが関係する場合はそうです。

実用的なガイドライン:

• VLANによるセグメンテーションユーザーネットワークをAIサーバーネットワーク、管理ネットワーク、そして必要に応じてゲストネットワークから分離し、それらの間には厳格なファイアウォールルールを設定します。例えば、チャットボットのVLANは内部リクエストを受信したり、データベースやActive Directoryと通信したりできますが、 インターネットアクセスなし.
• デフォルトでブロックするファイアウォール明示的に必要なトラフィック（ボットAPIポート、データベース、LDAP、管理者SSH）のみが許可されます。それ以外のトラフィック、特にAIサーバーから外部への接続はすべて拒否されます。
• 企業認証: チャットボットへのユーザー アクセスを Active Directory または LDAP と統合し、グループと役割に応じて誰が使用できるか、何を表示できるかを制御します。

このアプローチをアプリケーションレベルの認証および認可メカニズムと組み合わせることで、 たとえ攻撃者がエージェントのモデルやコードを侵害したとしても他のシステムにジャンプしたり、データをインターネットに持ち出したりする能力は大幅に制限されます。

AIエージェントの監視、DLP、インシデント対応

エージェントは非決定論的な決定を下し、悪意のあるプロンプトやデータに遭遇する可能性があるため、 深い観測可能性 彼らの行動について。APIを呼び出したということを知るだけでは十分ではありません。 彼らはどのようなコンテキストを使用し、なぜ特定のアクションを実行したのでしょうか?.

関連する措置には以下が含まれます。

• 包括的な記録 インタラクション: プロンプト、呼び出されたツール、パラメーター、応答、エラー、およびユーザー コンテキスト。
• SIEMとの統合 (スプランク、ELK、Wazuh、Graylog など）を使用して、エージェントのアクティビティを一般的なセキュリティ イベントと相関させます。
• DLPルール AI 固有の機能: 応答内の機密データ (カード、ID カード、パスワード、トークン、機密情報) をフィルタリングし、不適切なコンテンツをブロックしたり、重要な部分を編集したりします。
• 自動応答メカニズム 大量のデータ抽出の試み、疑わしいクエリ、またはパターンから逸脱した動作があった場合、エージェントの一時的なブロックや追加の MFA の要求などが含まれます。

この観察可能性と能動的な制御の組み合わせにより、AIが 増幅された内部脅威また、モデルドリフト、プロンプトインジェクション攻撃、設計エラーなどにより何か問題が発生した場合にも、迅速に対応できます。

これらすべての要素（個別のエージェントID、セッションブローカー、OAuth2/OIDC、MCP、シークレットマネージャー、セグメント化されたネットワーク、監視、DLP）を適切に統合することで、社内システムと真に統合されたAIエージェントを構築することが可能になります。 重要なプロセスを自動化するのに十分なパワーを備えながら、資格情報は常に保護され、権限は調整され、完全な追跡可能性が確保されています。このようにして、エージェントは危険な実験ではなくなり、企業のセキュリティとビジネス アーキテクチャ内の信頼できるコンポーネントになります。