OpenAI × 1Password：如何让 Codex 在不接触密钥的情况下完成真实开发任务

AI 编程代理进一步放大了这个问题，因为它们会自动分析仓库、文档和配置文件。如果仓库内容中包含隐藏指令，还可能触发间接提示注入（indirect prompt injection），诱导代理在执行任务时泄露密钥。

新模式：通过工具中介访问凭证

OpenAI 与 1Password 的思路是把模式从：

“把密码交给 AI”

转变为：

“允许 AI 请求一个被授权的能力”。

在这种架构下：

• 凭证保存在安全的密钥库（例如 1Password）中
• Codex 通过工具调用访问这些凭证
• 工具只返回完成任务所需的最小能力

也就是说，模型负责协调流程，但不会直接看到密钥本身。

例如，当 AI 代理需要部署代码或调用 API 时：

• 代理向一个受控工具发出请求
• 工具从 1Password vault 中获取凭证
• 凭证只在执行环境中被注入
• 模型上下文中不会出现密钥

这样，API key 不会出现在 prompt、日志或生成代码中。

MCP：Codex 与外部工具的连接方式

这种模式能够实现，很大程度上依赖 Model Context Protocol（MCP）。

MCP 是 OpenAI Codex 支持的一种协议，用来让模型连接外部系统，例如开发工具、文档服务或企业系统。

MCP 服务器可以：

• 在本地运行
• 通过 HTTP 远程提供服务
• 向 Codex 暴露可调用工具

通过 MCP，Codex 可以调用一个由 1Password 提供的工具来获取凭证，而不是直接读取 .env 文件或 prompt 中的密钥。

换句话说：

模型负责决策，MCP 服务器负责处理敏感操作。

即时凭证与最小权限访问

这个安全模型的关键改进之一是 Just‑in‑Time（即时）访问。

传统方式通常给代理长期有效的 API key，而新的模式只在需要时提供临时凭证，并且权限范围非常有限。

这样做有三个明显好处：

• 凭证很快过期
• 权限只允许执行特定任务
• 所有访问都可以被审计或撤销

这实际上是经典安全原则 最小权限（least privilege） 在 AI 代理中的应用。

企业级治理：控制 AI 编程代理的行为

当企业在团队规模部署 AI 编程工具时，还需要额外的治理层。

OpenAI 的 Codex 企业配置允许管理员设置强制策略，例如：

• 只允许使用指定的 MCP 服务器
• 控制沙箱或执行环境
• 为敏感操作设置审批流程

如果再结合 1Password 这样的凭证管理平台，就可以形成一套完整的安全体系：

• 凭证存储在 vault 中
• AI 通过 MCP 请求访问
• 企业策略控制工具使用
• 所有访问行为可审计

为什么这对 AI 代码安全很重要

AI 代理正在越来越多地直接操作生产基础设施，例如：

• 自动部署代码
• 查询数据库
• 调用云服务 API

如果没有安全设计，这些流程很容易把密钥泄露到 prompt、日志或生成代码中。

OpenAI 与 1Password 的模式通过把凭证从模型上下文中彻底分离，大幅降低了模型意外泄露密钥的风险。

AI 只负责协调任务，而身份验证由安全工具在后台完成。

仍然存在的安全风险

即便如此，这种架构也不是万能的。

如果配置不当，仍然可能出现问题，例如：

• MCP 服务器被恶意配置
• 凭证权限过大
• AI 生成的代码存在漏洞

因此，很多组织会同时使用其他安全措施，例如：

• MCP 服务器白名单
• vault 访问策略
• 自动化密钥扫描
• 人工代码审查

这些措施共同构成 AI 编程代理的安全防护体系。

更大的趋势：AI 时代的统一身份控制

这类集成背后其实反映了一个更大的趋势：统一身份控制层（identity control plane）。

像 1Password 的 Unified Access 平台正在尝试把人类用户、机器账户和 AI 代理的身份统一管理，包括：

• 发现和管理凭证
• 持续授权访问
• 审计所有操作记录

在这种模式下，开发者不再把密码交给 AI，而是授权 AI 在受控路径下执行某个动作。

随着 AI 代理越来越多地参与真实生产系统，这种“能力授权而不是密钥暴露”的架构，很可能会成为未来 AI 基础设施的标准设计。