OpenAIと1PasswordはどうやってCodexの認証情報を守るのか

つまり、AIはワークフローを指示するだけで、秘密情報そのものを見ることはありません。

たとえばAIエージェントが次の作業を行う場合を考えます。

• クラウドへコードをデプロイ
• 外部APIを呼び出す

従来ならAPIキーをプロンプトや設定ファイルに入れていました。しかしこの仕組みでは、エージェントは認証ツールにアクセスを要求するだけです。

ツール側が1Passwordから秘密情報を取得し、実行環境へ注入します。モデルのコンテキストには秘密が入りません。

MCPがCodexと安全なツールをつなぐ

この仕組みを可能にするのが、OpenAIの**Model Context Protocol（MCP）**です。

MCPは、モデルを外部ツールやシステムと接続するためのプロトコルで、CodexのCLIやIDE拡張で利用できます。

MCPサーバーは次のような機能を提供できます。

• 開発ツール
• ドキュメント検索
• 社内サービス
• 認証情報管理

この構造により、Codexは以下のような形で動作します。

1. Codexがツールを呼び出す
2. MCPサーバーが処理を実行
3. 必要な場合だけ安全に認証情報を取得

つまり、AIはオーケストレーター（指揮役）であり、機密処理は外部ツールが担当します。

ジャストインタイム認証と最小権限

このアーキテクチャの重要なポイントは、ジャストインタイム（JIT）アクセスです。

AIエージェントには恒久的な認証情報を与えません。

代わりに、

• 必要な瞬間だけ
• 必要な操作だけ
• 短時間だけ有効

という認証を発行します。

1PasswordはAI向けセキュリティ設計として、短命トークンと厳密な権限スコープを推奨しています。

これにより、仮に認証情報が悪用された場合でも影響は限定されます。

• トークンはすぐ失効する
• 権限は特定の操作だけ
• 監査ログで追跡できる

これはセキュリティの基本原則である**最小権限アクセス（Least Privilege）**をAIエージェントに適用したものです。

企業向け：Codexの管理とポリシー制御

企業でAIコーディングツールを使う場合、追加の統制も必要になります。

OpenAIのCodexには、企業管理者がローカルエージェントの挙動を制御するための管理設定があります。

例えば次のような制御が可能です。

• 使用可能なMCPサーバーの許可リスト
• 実行環境やサンドボックスの制限
• 危険な操作の承認ワークフロー

これを1Passwordのようなシークレット管理システムと組み合わせることで、AIエージェントの認証アクセスをガバナンス下に置くことができます。

AIがインフラを操作する時代のセキュリティ

AIエージェントはすでに次のような作業を行うようになっています。

• 本番環境へのデプロイ
• データベース操作
• クラウドAPIの呼び出し

もし認証情報がプロンプトやログに含まれていれば、漏えいのリスクは大きくなります。

OpenAIと1Passwordの設計は、認証管理とAIの推論を分離することでこの問題を減らします。

• AI → ワークフローを指示
• セキュアツール → 認証処理

この分離により、モデルが誤って秘密情報を出力する可能性を大幅に下げられます。

それでも残るセキュリティ課題

この仕組みは強力ですが、完全な防御ではありません。

依然として次のようなリスクは存在します。

• 不正なMCPサーバー
• 権限が広すぎる認証情報
• AIが生成した脆弱なコード

そのため多くの組織では、以下の対策を組み合わせています。

• MCPサーバーの許可リスト
• Vaultポリシー管理
• コードレビュー
• シークレットスキャン

こうした多層防御が必要です。

次の大きな変化：AIも含めた「アイデンティティ管理」

この統合の背景には、より大きなトレンドがあります。

それは、人間・マシン・AIエージェントをまとめて管理するアイデンティティ基盤です。

1Passwordの「Unified Access」などの取り組みは、次の要素を統合することを目指しています。

• AIエージェントの発見
• 認証情報の保護
• 継続的なアクセス認可
• 全アクションの監査

つまり今後のインフラでは、次のようなモデルが標準になる可能性があります。

「AIにパスワードを渡す」のではなく、
AIに特定の操作を許可する。

この設計こそが、AIエージェントを本番環境で安全に使うための重要な鍵になっています。