Postmanが42の本番システムへのAIエージェントのアクセスを制御する仕組み

認証情報の分散。どのシステムにアクセスする場合も、情報セキュリティチームにアクセスを申請し、キーを取得してローカルの.envファイルにコピーし、エージェントに組み込むという同じ手順を踏んでいました。セキュリティチームによる内部監査では、開発者のノートPC、CIの設定、デプロイマニフェストに計278個のAPIキーが見つかりました。

必要以上に広いアクセス権限。監査の結果、多くのベンダーのAPIキーでは権限を細かく設定できないことが分かりました。あるエージェントは、特定のリソースの読み取り権限しか必要としていなかったにもかかわらず、レコードの削除、パイプラインデータの変更、組織全体の設定変更まで可能なキーを保持していました。

同じマシンで稼働するコーディングエージェント。 すべての開発者が、APIキーが保存されたファイルシステムにアクセスできる環境で、Claude Code、Cursor、Codexのいずれかを実行していました。エージェントを追加するたびにキーと.envファイルが増え、エージェントの数に比例して認証情報が露出するリスクも高まっていました。

共有サービスキーの運用負担。一部のAPIでは、開発者ごとにキーを発行するのではなく、サービスキーのみを発行する方法が現実的でした。そのため、各APIアクセスを実行した開発者やエージェントを特定することが困難でした。また、セキュリティチームが共有の認証情報をローテーションする際には、それを使用するすべての開発者とエージェントに影響が及び、変更に伴う調整や管理に多大な手間がかかっていました。

Postmanが必要としていたこと

1. 認証情報を、セキュリティチームが管理するゼロトラストの境界内に保持する。
2. アクセス範囲をベンダー単位ではなくリソース単位で事前に設定し、エージェントの開発に携わるすべての開発者に同じ設定を適用する。
3. 各APIアクセスを、開発者、エージェント、個々の実行にひも付けて記録する。
4. 開発者がAPIにアクセスできる期間を、エージェントの開発や改良に取り組んでいる間だけに限定する。
5. ターミナル、IDE、コーディングエージェント、CIなど、開発者が普段使う環境で利用できる。

セキュリティチームがアクセスの制限を事前に定め、システムがすべてのAPIコールでその制限を適用します。

Passport

Postmanの製品チームは、APIキーを扱う複数の顧客が同じ課題に直面していることを受け、Passportを開発しました。

開発者は実際のAPIキーを保持しません。.envファイル内の各値は、申請した開発者にひも付けられた参照情報です。PassportはAPIコール時に、この参照情報を実際の認証情報に解決します。開発者のノートPC上で稼働する軽量なPassportデーモンが、APIコールをPassportプロキシに転送します。セキュリティチームはJamfを通じて、このデーモンをリモートで配布・管理します。

ANTHROPIC_API_KEY={{vault:e96b2432-7ca0-47a0-9d83-b6805c04396d}}
SF_CLIENT_SECRET={{vault:2912c85a-01f3-415e-afd7-a884d1d24472}}
CONFLUENCE_API_TOKEN={{vault:ad0faeed-b6be-42ea-ac14-a990bd4f2654}}
GITHUB_TOKEN={{vault:d2a76849-c215-4411-be0f-2d2c3fff36ef}}

実際の認証情報はVaultに保管されます。Passportプロキシは社内ネットワーク内で稼働します。リクエスト元のIDとアクセス権限の範囲を検証し、Vaultから実際のシークレットをメモリに読み込んで、ベンダーのAPIを通常どおり呼び出します。システム内で実際の認証情報にアクセスするのは、このプロキシだけです。

セキュリティチームがリソースカタログを管理します。セキュリティチームは、ベンダーのシステムと社内システムを合わせた42のシステムへのアクセスを、承認済みの104のエンドポイントに限定しました。プロキシはカタログで定められた制限を適用するため、リソースを削除できるベンダーのAPIキーであっても、エージェントに必要な読み取り用エンドポイントにしかアクセスできません。Passportを通じてアクセスを申請するすべての開発者に、事前に承認された同じアクセス範囲が適用されます。

すべてのAPIコールを実行元にひも付けて記録し、付与するアクセス権限にはそれぞれ有効期限を設定します。Passportは、共有サービスキーによるAPIコールも含め、各リクエストを開発者、エージェント、個々の実行にひも付けて記録します。開発者は理由とアクセス期間を指定してアクセスを申請します。セキュリティチームは管理画面の申請キューからアクセス申請を承認し、特定の開発者に付与されたエージェント群全体へのアクセス権限をワンクリックで取り消すこともできます。

セキュリティチームの管理画面：アクセス範囲と期間を含む承認待ちの申請

5日間で導入

• 1～2日目。セキュリティチームとエージェント開発チームが協力し、ベンダーのシステムと社内システムを合わせた42のシステム、承認済みの104のエンドポイントをカタログに登録しました。
• 3～4日目。すべての.envファイル内の値をPassportの参照情報に置き換えました。
• 5日目。5日目。セキュリティチームが各ベンダーの既存のキーをローテーションし、複製されていた278個のキーを無効化しました。

.envファイルの認証情報をPassportの参照情報に置き換えた後も、開発者は従来のコーディングツールを使い続けることができました。セキュリティチームはJamfを使って組織全体にPassportデーモンを配布し、Passportを通じてアクセス権限を管理しています。

セキュリティチームにとっての成果

• 開発者のマシンに保存する本番環境の認証情報をゼロに
• 278個のAPIキーの使用を廃止
• すべてのAPIコールを開発者、エージェント、個々の実行にひも付けて記録
• 開発者のアクセス権限をワンクリックで取り消し

エンジニアリングチームにとっての成果

• 新しい本番システムのカタログ登録にかかる期間を15日から3日に短縮
• 新たに参加した開発者が、2時間でどのエージェント群の開発にも参加可能に
• 新しいエージェントの開発や既存のエージェントの改良に取り組める環境が整い、開発者の満足度が向上

導入後、エージェント数は32から70に、連携するシステム数は当初の27から42に増えました。認証情報が露出する状態は引き続きゼロに保たれています。

“各エージェントのアクセス範囲を常に制御できるため、社内システムでのAIエージェントの利用を、以前よりも安心して承認できるようになりました。エンジニアはスピードを落とさず重要な開発に取り組め、その間も私たちは安全性を維持できます。”

Sam Chehab, Head of Information Security, Postman

始める

Passportの詳細をご覧いただくか担当チームにご相談ください。この取り組みの背景について詳しくは、「Agentic OS：エージェントのアクセスのあり方を見直す」をご覧ください。