AI Agent 自动发布成功了，密钥却泄漏了？聊聊 STS 临时凭据与自动化部署安全

前言

现在使用 AI Agent 开发和发布项目越来越方便。

以前需要手动完成的流程，例如编写代码、运行测试、推送 Git 仓库、上传发布材料，现在可以交给 AI 自动执行。

但我在研究 AI 自动化部署流程时，发现一个容易被忽略的问题：

项目成功发布了，并不意味着整个发布过程就是安全的。

例如，AI Agent 在调用云平台 API 时，可能需要使用 Access Key、Secret Key 或临时安全令牌。

如果这些凭据被写入项目目录、终端日志或者发布压缩包，即使任务最终执行成功，也可能留下安全隐患。

本文从开发者角度，介绍 STS 临时凭据的基本概念，以及如何在 AI Agent 自动化发布过程中减少敏感信息泄漏风险。

一、什么是 STS 临时凭据？

STS（Security Token Service）是一类用于获取临时安全凭据的服务机制。

与长期有效的访问密钥相比，临时凭据通常具有明确的有效期和权限范围。

一组临时凭据可能包含：

Access Key ID
Secret Access Key
Security Token
Expiration

这些字段分别用于身份识别、请求签名、临时授权和有效期控制，具体含义取决于云平台实现。

临时凭据的优点是可以减少长期密钥直接暴露的风险。

但是，需要注意：

临时凭据不等于可以公开的凭据。

只要凭据仍然有效，且具有相应权限，就可能被用于执行未经授权的操作。

因此，开发者仍然需要保护它们。

二、AI Agent 自动发布最容易出现的三类泄漏

1. 凭据被保存在项目目录

假设项目结构如下：

my-project/
├── index.html
├── style.css
├── script.js
├── sts-creds.json
└── publish-params.json

其中，sts-creds.json 保存临时身份信息，publish-params.json 可能包含调用发布接口所需的认证字段。

如果 AI Agent 执行：

git add .
git commit -m "publish project"
git push

这些文件就可能被意外提交到远程仓库。

即使之后删除文件，敏感信息也可能仍然存在于 Git 历史中。

2. 凭据被打印到终端日志

某些自动化脚本为了方便调试，会输出完整请求参数。

例如：

cat publish-params.json

如果文件包含密钥，那么整个终端输出就可能保存敏感数据。

对于 AI Agent，这一点尤其需要注意。

因为模型经常会读取终端输出，并将其加入执行记录或最终报告。

调试信息越详细，并不一定越安全。

应该优先输出状态码、错误类型和请求 ID，而不是完整凭据。

3. 凭据被打包进发布材料

一些平台要求上传 ZIP 文件作为项目介绍或交付材料。

如果直接打包整个项目目录，就可能把临时凭据一起上传。

因此，发布压缩包不能简单地等同于项目文件夹的完整副本。

应当明确规定允许打包的文件和目录。

三、实践一：把凭据放在项目目录之外

一个简单而有效的方法，是将临时凭据与项目代码分离。

例如：

/workspace/my-project/
├── index.html
├── style.css
└── script.js

/tmp/agent-private-XXXXXX/
├── sts-creds.json
└── publish-params.json

这样，正常的项目代码提交不会直接包含凭据目录。

在 Linux 环境中，可以使用以下方式创建专用临时目录：

umask 077

SECRET_DIR=$(mktemp -d /tmp/agent-private.XXXXXX) \
  || exit 1

trap 'rm -rf -- "$SECRET_DIR"' EXIT

echo "临时凭据目录已准备"

其中：

umask 077 用于限制新建文件和目录的默认权限。

mktemp -d 用于创建名称不可预测的临时目录。

trap 用于在 Shell 正常退出及部分异常退出时清理目录。

需要说明的是，trap 并不能保证在进程被强制终止、机器断电等所有情况下完成清理。

生产环境还应配合凭据过期机制和安全清理策略。

四、实践二：提交 Git 前检查敏感文件

仅仅在 .gitignore 中加入：

.env
.env.*
*-creds.json
*-creds.sh
publish-params.json

还不够。

因为 .gitignore 不能阻止已经被 Git 跟踪的文件继续提交。

因此，在提交前，建议同时检查待提交的文件。

例如：

git diff --cached --name-only

这条命令可以查看当前暂存区中的文件。

如果发现包含密钥、令牌或环境配置的文件，就应该停止提交并检查。

对于自动化系统，可以进一步设置提交前检查脚本，对文件名和内容进行敏感信息扫描。

但这类扫描需要注意误报和漏报，不能只依赖文件名。

尤其需要避免把扫描出来的真实密钥再次打印到日志中。

五、实践三：发布 ZIP 采用白名单机制

相比直接压缩整个目录，我更推荐采用白名单方式构建发布材料。

例如，一个简单网页项目只需要：

README.md
resources/screenshot.png

那么就只打包这两个明确需要的文件。

zip -j detail.zip README.md

zip detail.zip resources/screenshot.png

这里假设相关文件已存在，并且符合平台要求。

不要把整个工作区、隐藏配置文件和临时身份文件一并压缩。

在正式上传前，还可以检查压缩包内容：

unzip -Z1 detail.zip

确认其中不包含凭据、密钥或无关文件。

如果平台有官方打包与校验工具，应当优先使用官方工具，并在其允许范围内明确控制输入文件。

六、实践四：限制凭据权限与有效期

即使临时凭据没有进入 Git 仓库，也不代表可以忽略访问权限。

一个比较合理的自动化发布流程应该遵循以下原则：

特别是对于具备终端能力的 AI Agent，不应该因为方便，就默认赋予其不受限制的云平台管理权限。

如果任务只是发布一个网页作品，就应尽量使用范围受限、符合平台正式授权流程的凭据。

七、如果密钥已经泄漏怎么办？

如果发现真实凭据进入公开仓库或日志，不能只把文件删除就认为问题解决了。

建议按以下顺序处理：

第一，判断凭据是否仍然有效。

如果是仍然有效的长期密钥，应尽快通过官方机制禁用或轮换。

如果是临时凭据，也要根据平台能力判断是否可以提前撤销，并检查其剩余有效期。

第二，检查使用记录。

查看是否出现异常的 API 调用或资源操作。

第三，清理泄漏位置。

包括公开仓库、Git 历史、CI 日志、构建产物和临时文件。

Git 历史清理通常需要专门处理，而且不能保证删除已经被他人获取的副本。

第四，修复自动化流程。

找到凭据为什么进入了不应该出现的位置，避免下次再次发生。

这里最重要的原则是：

撤销或轮换有效凭据优先于单纯删除泄漏记录。

八、总结

AI Agent 自动化开发可以大幅减少人工操作，但也让敏感凭据的管理变得更加重要。

以前由开发者手动控制的发布流程，现在可能变成 AI 连续执行的多个工具调用。

如果缺乏安全边界，密钥就可能在代码提交、日志记录和发布打包过程中意外泄漏。

通过本文的讨论，可以总结出几个重要原则：

1. STS 临时凭据仍然属于敏感信息。

2. 凭据应与项目代码分离存储。

3. Git 提交前需要检查敏感文件。

4. 发布材料优先采用白名单打包。

5. 日志不应该打印完整认证信息。

6. 发现泄漏后，应优先处理凭据有效性与权限风险。

我认为，AI Agent 工程化不仅要关注任务成功率，还应该关注完成任务时是否引入了新的安全风险。

真正可靠的 AI 自动化，不只是把项目成功发布出去，还要确保发布过程没有把本应保密的信息一起发布出去。