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を開発しました。

開発者は実際のキーを一切保持しません。.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}}

実際の認証情報は保管庫内に保持されます。Passportプロキシは社内ネットワーク内で稼働します。IDとアクセス範囲を検証し、保管庫から実際のシークレットをメモリ上に読み込んで、ベンダーに通常のAPIコールを行います。システム内で実際の認証情報にアクセスするのは、このプロキシだけです。

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

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

セキュリティチームの管理画面：アクセス範囲と期間が表示された承認待ちの申請

5日間で導入

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

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

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

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

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

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

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

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

Sam Chehab, Head of Information Security, Postman

始める

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