你的Dockerfile正在泄露AI密钥

周三下午，一位开发者在排查镜像体积时发现，自己打包的AI Agent镜像里，居然躺着明文的OpenAI API密钥。不是运行时环境变量，是构建历史里直接能搜到的字符串。

这不是孤例。Dockerfile常被当作"能跑就行"的基础设施文件——复制一个模板，改几条命令，装完依赖就收工。但当项目变成AI应用，风险被放大了：私有npm包、内部SDK、GitHub仓库、模型提供商凭证、MCP服务器配置，这些东西的访问令牌一旦处理不当，就会残留在镜像历史、构建层或日志里。

最危险的误区是把ARG和ENV当保险箱用。看这段典型代码：

ARG NPM_TOKEN
ENV NPM_TOKEN=$NPM_TOKEN
RUN npm config set //registry.npmjs.org/:_authToken=$NPM_TOKEN && npm ci

表面合理：构建需要npm令牌来装私有包。但ARG和ENV的设计初衷就不是为了保密——值可能出现在元数据、日志或中间层里。就算容器跑起来了，镜像携带的信息已经超标。

更糟的是把这套模式套到AI凭证上：

ARG OPENAI_API_KEY
ENV OPENAI_API_KEY=$OPENAI_API_KEY

这通常是错的。模型提供商的密钥、Anthropic密钥、GitHub令牌、MCP服务器凭证，本质上应该是运行时秘密，而非构建时值。构建过程一般不需要它们，运行中的应用才需要。

AI应用模糊了构建时和运行时的边界。普通Node.js API可能只需要构建时拉依赖、运行时连数据库；AI Agent应用还可能需要工具凭证、私有包访问、GitHub权限、提示词资产、评估数据集、模型提供商密钥。这种复杂度催生捷径：开发者往Dockerfile里塞令牌只为让构建通过，AI编程助手生成的Dockerfile可能直接照搬了有问题的模式。

Docker Build Secrets解决的就是这个特定问题：把敏感值传给构建过程，但不 baked 进最终镜像。官方文档明确区分：构建参数和环境变量不适合保密，因为它们可能残留在最终镜像里；而secret mounts和SSH mounts的设计目标，就是在构建步骤中安全暴露敏感数据，且仅限该步骤。

核心原则就三条：一，区分构建秘密和运行秘密，npm令牌是前者，OpenAI密钥通常是后者；二，需要构建时用的敏感值，用Docker Build Secrets传递；三，运行时才需要的凭证，绝对不进Dockerfile，通过容器编排或密钥管理服务注入。

AI应用的依赖链比传统软件更长，每个环节都可能成为泄露点。检查你的Dockerfile，看看有多少"临时加上的"ARG和ENV，正在镜像里沉睡。