10月6日、Postmanが「How Postman governs AI agent access to 42 production systems」と題した記事を公開した。この記事では、70体のAIエージェントが稼働する環境で42の本番システムへのアクセスをどう管理・統制したかについて詳しく紹介されている。

「278本のAPIキーが開発者のPCに散在していた」

AIエージェント開発が加速するにつれ、クレデンシャル（認証情報）管理の問題は規模が大きくなるほど深刻になる。Postman社内でも同じ問題が起きていた。

Postmanは自社のagentOS上で70体のAIエージェントを運用しており、マーケティング・製品・エンジニアリングの各チームを支援している。エージェントの開発者はClaude Code、Codex、Cursor、Postmanといったコーディングツールを使い、33のSaaSサービスと9つの内部システム、合計42システムにアクセスする必要があった。

内部監査で発覚したのは、278本のAPIキーが開発者のノートPC、CI設定、デプロイメントマニフェストに散在しているという実態だ。問題はそれだけではない。

• 過剰スコープのクレデンシャル：読み取りアクセスだけ必要なエージェントが、レコード削除やパイプラインデータ変更、組織全体の設定変更まで可能なキーを保持していた。
• コーディングエージェントとキーの同居：開発者がClaude CodeやCursorを動かすファイルシステム上に、そのままAPIキーが置かれていた。エージェントが増えるたびにキーと.envファイルが増殖する構造だった。
• 共有サービスキーのメンテナンス：一部APIでは開発者個別ではなくサービスキーのみ発行可能で、セキュリティチームがローテーションするたびにそのキーを使う全開発者・全エージェントが一斉に壊れた。

解決策：Passport——「.envの値を参照に置き換える」

こうした課題に対してPostmanのプロダクトチームが構築したのが**Passport**だ。同様の問題を複数の顧客で繰り返し目にしたことが開発のきっかけだという。

※なお、PassportはURLがapp.usepassport.aiであることからもわかるように、Postman本体とは独立したプロダクトとして提供されている。元記事ではPostmanのプロダクトチームが構築したと説明されているが、Postmanブランドの既存製品とは別に開発・展開されたサービスという位置づけであることに注意されたい。

仕組みの核心は「開発者は本物のキーを一切持たない」という設計だ。

.envファイルに書かれる値は、すべてPassportの参照トークンに置き換わる：

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}}

開発者のPCにはPassportの軽量デーモンがインストールされており（Jamf経由でセキュリティチームが一括管理）、APIコール時にPassportプロキシへ転送する。プロキシは社内ネットワーク内で動作し、開発者のID・スコープを検証した上でVaultから本物のシークレットをメモリに読み込み、ベンダーへの実際のAPIコールを発行する。本物のクレデンシャルに触れるのはプロキシのみという構造だ。

スコープはリソース単位で、しかも承認済みエンドポイントのみ

セキュリティチームは42システムを精査し、104の承認済みエンドポイントからなるリソースカタログを整備した。ベンダーが発行するキー自体は削除権限を持っていても、プロキシはカタログに登録された読み取りエンドポイントしか通さない。

アクセス申請は開発者が「理由」と「期間」を添えて行い、セキュリティチームが管理キューから承認する。また、特定の開発者のアクセスをエージェント群全体で一括取り消し（ワンクリック）できる。すべてのAPIコールは開発者・エージェント・実行単位で記録される。

5日間でのロールアウト

• 1〜2日目：セキュリティとエージェント開発チームが協力してカタログを構築（42システム・104エンドポイント）
• 3〜4日目：全.envファイルの値をPassport参照に置き換え
• 5日目：旧キーをベンダーごとにローテーション・削除し、278本を無効化

開発者は既存のツールをそのまま使い続けることができた。

結果

ロールアウト後の成果は数字で明確だ：

エージェント数はロールアウト開始時の32体から70体に増加し、統合システム数も27から42に拡大した。クレデンシャルの漏洩はゼロのままだという。

「エージェントが社内システムに触れることへの承認がずっとやりやすくなった。エンジニアはスピードを落とさずに開発でき、我々はコントロールを手放さずに済んでいる」

Sam Chehab（Postman セキュリティ責任者）

詳細はHow Postman governs AI agent access to 42 production systemsを参照していただきたい。