OpenAI × 1Password：讓 Codex 寫程式，但看不到你的密鑰

AI coding agent（例如 OpenAI 的 Codex）已經能寫程式、執行指令、呼叫 API，甚至自動部署應用。但一旦 AI 要在真實系統中工作，就不可避免需要憑證（credentials）：API 金鑰、存取權杖、資料庫密碼或雲端服務憑證。

問題是，傳統做法往往很危險。開發者常把 API key 直接貼進 prompt、.env 檔案或設定檔。只要這些機密被送進模型的 context window，它們就可能出現在日誌、生成程式碼或其他輸出中，之後就很難再控制其流向。

OpenAI 與密碼管理平台 1Password 所採用的新整合模式，正是為了解決這個問題：讓 AI 可以使用憑證，但永遠看不到它們。

核心問題：機密資料進入模型上下文

在許多 AI 開發流程中，機密外洩其實是無意間發生的。

例如：

• 開發者把 API key 貼進 prompt
• 將 token 存在 .env 或設定檔
• 把憑證提交到 Git 儲存庫

一旦機密被送進模型 API，它可能被記錄在 session logs，或在生成程式碼與註解中再次出現。當秘密進入模型上下文後，開發者通常就無法控制它是否會再次被輸出。

1Password 的開發者指南也直接警告：不要把原始憑證直接提供給 AI 模型。建議改用短期、權限範圍有限的存取權杖，並盡量減少模型直接接觸敏感資料。

AI coding agent 讓問題更複雜，因為它們會自動分析整個專案，包括文件、README 與設定檔。如果某些檔案包含惡意或隱藏指令，還可能觸發 間接 prompt injection，誘導代理程式洩漏憑證。

新模式：由工具代管憑證

OpenAI 與 1Password 的整合核心理念很簡單：

不是「把密碼交給 AI」，而是「讓 AI 請求一個被授權的能力」。

在這個架構中：

• 憑證保存在安全 vault（例如 1Password）
• Codex 透過工具呼叫來使用憑證
• 工具只提供完成任務所需的最小能力

換句話說：

AI 負責編排流程，但從不直接接觸秘密。

例如，如果 Codex 需要部署程式或呼叫 API，它不會在 prompt 中包含 API key。相反地，它會呼叫一個受控工具，由該工具從 1Password vault 取出憑證並注入執行環境，而不是暴露給模型。

MCP：讓 Codex 安全連接外部工具

這種架構能成立，關鍵在於 Model Context Protocol（MCP）。

MCP 是 OpenAI 提供的一種標準介面，讓模型能與外部工具、文件系統或企業服務互動。

在 Codex 中，MCP server 可以：

• 在本機執行
• 透過 HTTP 遠端提供服務
• 提供模型可呼叫的工具

因此，開發者可以建立一個 1Password Environments MCP Server，讓 Codex 在需要時透過工具取得憑證，而不是把憑證放進 prompt 或設定檔。

在這種情況下：

• 模型只看到「呼叫工具」
• MCP server 負責真正的敏感操作

即時（Just‑in‑Time）與最小權限憑證

這個架構的一個重要安全特性是 just‑in‑time access。

也就是說，AI 代理不會持有長期憑證，而是只在需要時獲得短暫授權。

1Password 建議 AI 系統使用：

• 短期憑證（short‑lived tokens）
• 最小權限（least privilege）

這樣即使憑證被濫用，影響範圍也會被限制，因為：

• 憑證會快速過期
• 權限僅限特定任務
• 可以集中稽核與撤銷存取權

這其實是傳統 IT 安全原則在 AI agent 時代的延伸。

企業級安全控制

在大型企業中，AI coding agent 需要更多治理機制。

OpenAI 的 Codex 企業配置允許管理員設定多種安全政策，例如：

• 允許哪些 MCP servers 被使用
• 控制 sandbox 或執行模式
• 為高風險操作建立審批流程

這些策略可以透過 管理預設值（managed defaults） 和 強制要求（requirements） 來實施。

當這些控制與 1Password 的憑證管理平台結合時，就能形成一層完整的治理框架，確保 AI agent 如何存取外部系統都有可控的規範。

為什麼這對 AI 開發安全很重要

AI agent 的能力正在快速提升。

今天的 coding agent 已經可以：

• 部署應用
• 查詢資料庫
• 呼叫雲端 API
• 修改生產環境設定

如果沒有妥善的憑證管理，這些流程很容易讓 API key 或密碼出現在 prompt、日誌或生成程式碼中。

透過把憑證完全移出模型上下文，OpenAI 與 1Password 的模式能大幅降低機密洩漏的風險。AI 只負責協調工作，而真正的身份驗證在背後由安全工具處理。

仍然存在的安全風險

即使這種架構改善了許多問題，它仍然不是萬靈丹。

風險仍可能來自：

• 設定錯誤或惡意的 MCP server
• 權限過大的憑證
• AI 生成程式碼中的漏洞

因此，企業通常會搭配其他安全措施，例如：

• MCP server allowlist
• vault 存取政策
• 程式碼審查
• secret scanning 工具

這些措施一起才能形成完整防護。

更大的趨勢：AI 也需要身份管理

OpenAI 與 1Password 的整合其實反映了一個更大的產業趨勢：

身份與存取控制不再只屬於人類使用者，也涵蓋機器與 AI agent。

像 1Password 的 Unified Access 平台，就是試圖建立一個統一的身份控制層，用來：

• 發現 AI agent
• 管理憑證
• 即時授權
• 稽核所有存取行為

這讓企業能同時管理「人、機器與 AI」的身份與權限。

隨著 AI agent 逐漸進入實際生產環境，這種模式很可能成為標準：

不是把密碼交給 AI，而是授權 AI 在受控路徑下完成特定行動。