1. 当 AI Agent 开始自己开门凭证管理的安全盲区我真正意识到 AI Agents 的凭证问题有多棘手是在一次安全审计。审计员指着我跑的自动化分析 agent 问它的数据库口令放在哪儿谁管多久轮换一次我当场答不上来。后来我用 1Password 的机器身份能力把这套自主凭证管理重新架构了一遍才在零信任的框架下把问题解决。这篇文章就把这一路的思考、架构设计和踩过的坑完整写出来给正在给 AI Agent 配密钥、又对机器身份怎么管犯迷糊的工程师和安全负责人一个参考。1.1 Agent 需要的凭证比你想的多得多先别急着谈方案我们把问题盘清楚。一个稍微正经的 AI Agent不管它是写代码、跑数据分析还是自动处理工单至少要摸到这几类凭证大模型服务商的 API Key不然它没法推理对话数据库连接串和口令不然它没数据可用对象存储、消息队列、内部 HTTP 服务的 token 或证书GitHub、Slack、Jira 这类第三方平台的集成 token偶尔还要连云主机的临时密钥。我见过很多团队的第一次部署都是同一个剧本写一个.env文件把上面这些一股脑塞进去agent 启动时加载。跑起来确实快但你要是被审计问一句这个环境变量文件有几份拷贝最后一份改于什么时候哪些 agent 在读这份文件基本就哑火了。更麻烦的是agent 是动态的同一段代码可能在三台机器上各跑一个副本每一份副本都自带一份密钥拷贝密钥的暴露面根本数不清。1.2 传统人管密码的逻辑为什么失效传统密码体系是为人设计的。人有眼睛、有手、有判断力登录时输密码、弹 2FA 就点确认、发现异常自觉改口令。可 AI Agent 不是人它不会主动辨认这个请求是不是钓鱼不会在三分钟内输完验证码更不会在权限变动的时候把自己的 token 交回来。更重要的是人和机器的安全假设完全不同。人访问系统的前提是有可信身份、有设备、有人在场机器跑在几十个容器的任何一个副本里随时可能被横向移动攻击探到。过去我们常说内网可信在 AI Agent 大量落地的今天这句话早就站不住脚了——内网里最活跃的用户恰恰是那些不受控的自动化进程。它们可能因为一段 prompt 注入就被诱导去调用不该调的资源也可能因为一个依赖库被供应链攻击而在运行时被接管。把密钥常驻在它们的环境里等于把房子钥匙放在小偷最常翻的抽屉。1.3 自主凭证的三个核心特征自主凭证这个词指的是由非人身份提交、在无人直接干预的情况下被程序化获取和使用的密钥。它和人类密码最大的区别在于三个特征机器可读凭证的请求、交付、注入都要通过 API 完成不能依赖人眼复制粘贴按需获取凭证不是常驻在 agent 环境里的存粮而是用到的那一刻才申请全程可审计谁哪个 agent、在何时、取了哪把密钥、密钥是什么版本都要能追溯。这三个特征恰好就是零信任模型对资源访问的基本要求。所以管 AI Agent 的密钥本质上不是换个工具存密钥而是把整个凭证生命周期纳入零信任的监控体系里。我后面所有的方案都围绕这三点展开。2. 零信任模型下 AI Agent 身份的三个铁律2.1 铁律一永不信任任何自己人的请求零信任的核心思想只有一句话永不信任持续验证。第一次听的时候我觉得这就是个营销概念直到真正在密钥侧落地才发现它其实是在把事前信任改成事中验证。放在 AI Agent 场景里自己人这个头衔不值钱。一段进程说我是财务分析 agent我要读生产库系统不该因为它在内网 IP 上就放行。怎么做到在凭证层面就是让 agent 每次取密钥都要出示独立的身份凭证服务账号 token并且资源侧在返回密钥之前验证三件事这个身份有没有权限取这把密钥、取的行为是否符合策略、当前上下文是否正常。细想一下这跟门卫查证件一个道理你有工牌还不够门卫还得看你是不是在非工作时间搬着主机箱往外走。这个原则落到 1Password 上就是服务账号机制。AI Agent 不继承任何人的登录态它有自己独立的机器身份。每次 SDK 请求都携带该身份后台按权限模型逐次校验——即使某一次请求异常也不会影响其他身份的授权状态。2.2 铁律二最小授权 最小时效给 AI Agent 授权最容易犯的错就是多给一点省得以后麻烦。结果 agent 手里捏着十几个 vault 的读取权等于给攻击者留了一整串钥匙串。最小授权有两层一层是范围一层是时间。范围上每个 agent 只该看到自己任务相关的几个 item而不是整个 vault时间上凭证的有效期应该短到够用就行——一次任务跑完、一个会话结束取到的密钥就该失去价值。这里有个现实困难很多基础设施的静态密钥天生就是长期有效的。这就是为什么零信任框架下凭证管理工具要提供轮换和吊销的手段——长期密钥改不了但我们可以让被使用的方式短期化每次运行前重新取、用完立刻作废、定期全局轮换。1Password 里给 item 设置轮换、服务账号令牌的随时吊销正好补上这块。而且最小时效还有一个容易被忽略的好处一旦 agent 被攻破攻击者拿到的永远只是一次运行所需的密钥而不是可以反复使用半年的大盘钥匙。2.3 铁律三持续验证与全程审计零信任的持续两字非常关键。不是 agent 启动时验证一次就完事而是每次访问资源、每次取密钥都要重新评估。落到实操里就是三件事全量日志每一次 SDK 拉取密钥的动作都要记录谁服务账号、何时、访问哪个 vault 的哪个 item异常检测同一个服务账号忽然在凌晨三点高频拉取全套密钥这本身就是告警信号行为基线与策略联动agent 的取密节奏应该符合它任务的正常形态偏离了就要拦截。很多团队觉得反正密钥加密存储了泄露不了这是最大的误区。加密只解决存储环节不解决使用环节的失控。零信任强调的正是默认它会泄露、默认有人已经攻进来我们能做的是让每一次泄露都可被发现、可被溯源、可被立刻止血。所以我在搭建这套体系时最先做的不是部署工具而是先和团队对齐一个原则密钥的每一次暴露都要是一条可回放的事件而不是一片沉默。3. 1Password Connect Server 与 SDK自主凭证的交付管线3.1 为什么选 1Password而不自己写个密钥库说句实话业界做密钥管理的工具不少HashiCorp Vault、AWS Secrets Manager、Kubernetes 的 External Secrets……我多少都试过。最后在 AI Agent 场景选了 1Password不是因为它功能最全而是因为它把人和机器两套身份放在了同一个体系里。很多公司已经有员工在用 1Password 管人力密码、共享 vault、做权限策略。再叠加上机器身份意味着安全团队只需要一套管理界面、一套审计日志、一套轮换策略就能同时覆盖人和AI Agent两类访问者。这是 Vault 和 Secrets Manager 很难给的便利——它们很强但跟人的日常使用是脱节的要么单独给人配一套要么让普通员工去面对一个 CLI 工具落地阻力很大。另外一个被低估的点是1Password 的 item 结构很适合存五花八门的凭证。字段、URI、附件、TOTP 都能放Agent 拿到的可以是完整的服务账号元数据而不是一个孤零零的密码串。比如给一个 agent 配数据库权限item 里可以同时存用户名、口令、只读开关的状态和连接参数一次拉取全拿到少写很多拼接逻辑。3.2 三个关键组件1Password 做 AI Agent 凭证交付靠的是三个组件配合Connect Server一个自托管的网关可以跑在 Docker 或 Kubernetes 里。它和 1Password 云端同步加密数据对外暴露一个 REST API让 Agent 通过标准 HTTP 请求拉取密钥。之所以需要这个组件是因为很多 AI Agent 跑在私有网络里不能直接访问外部的密码管理 API服务账号Service Account机器身份本身。在管理后台创建服务账号、分配 vault 权限后会得到一个一次性 tokenAgent 拿它来证明我是谁。这个 token 不是人的账号没有人味也不会被离职、改密这类人事流程影响SDK封装了认证、重试、解析的一层客户端库支持 Go、Python、TypeScript、Rust 等主流语言。它理解op://vault/item/field这种密钥引用格式开发者不用自己拼协议也不需要知道背后的加密细节。整体的请求链路用文字描述大概是Agent 进程启动时读取环境变量里注入的服务账号 token然后通过 SDK 向 Connect Server或直接向 1Password API发起解析请求Connect Server 校验权限并在本地解密后把明文密钥返回。整个过程发生在秒级Agent 拿到的已经是解析好的字段值可以直接用。Agent 进程持有服务账号 token │ ▼ SDK 客户端 ──携带 token 请求──► Connect Server / 1Password API │ 校验权限、解密 │ 返回明文密钥3.3 和其他方案的差异对比我整理了一个对比表方便你按团队情况判断方案定位上手成本和人密码体系的融合HashiCorp Vault基础设施密钥引擎支持动态凭证高要单独运维一套体系无需另搭AWS Secrets Manager云原生密钥托管中绑定 AWS 生态无自研密钥表各种自定义实现看命维护成本高自己造轮子1Password人和机器统一凭证体系低团队多半已在用天然融合这张表不是想说 Vault 不好。如果你的团队本来就把 Vault 运维得很成熟继续用完全没问题。但如果你的痛点是AI Agent 要会拿密钥、人要会管密钥、安全团队要能审计1Password 的路径确实短很多因为它天然长在团队已有的使用习惯上。4. 实战部署从服务账号到首个密钥解析的完整路径4.1 准备阶段把 vault 结构设计好部署之前先把 vault 规划清楚。这是我最想强调的一步。我的做法是按环境 职责拆分 vault比如agent-prod-finance、agent-staging-data每个 agent 只对应其中一两个 vault。vault 内的 item 再按服务拆prod-mysql-primary、openai-api-key、github-deploy-token。为什么这么细因为 1Password 的权限模型是 vault 级别的。服务账号一旦有某个 vault 的读取权这个 vault 里的所有 item 它都能看。所以 vault 拆得越细最小授权实现得越干净。如果所有密钥都堆在一个大 vault 里那权限控制基本等于没做。我见过最乱的案例是全公司一个 Team Vault里面躺着几百条 item任何服务账号一旦被误加进去能看的东西足够把整个基础设施的核心密钥一网打尽。4.2 部署 Connect ServerConnect Server 以容器方式部署。以 Docker Compose 为例核心配置大概是这样services: op-connect: image: 1password/connect:latest ports: - 8080:8080 environment: OP_CONNECT_CREDENTIALS: /home/opuser/1password-credentials.json OP_CONNECT_TOKEN: ${OP_CONNECT_TOKEN} volumes: - ./credentials:/home/opuser:ro两个关键环境变量OP_CONNECT_CREDENTIALS指向 1Password 账户的加密凭证文件OP_CONNECT_TOKEN是 Connect 服务本身的访问令牌两者都在 1Password 管理后台下载生成。部署位置建议放在受控的内网网段只对需要取密钥的 agent 网段开放 8080 端口别图省事直接暴露公网。Connect Server 相当于公司的钥匙柜钥匙柜本身必须是最高防护等级。我在生产环境会再加一层Connect Server 前面挂网关做流量审计确保所有请求都被记录同时限制来源 IP。如果你用的是 Kubernetes建议把 Connect 部署成单独的 Deployment配上独立的网络策略别和业务服务混在一个命名空间里减少被误伤的概率。4.3 创建服务账号并配置权限1Password 管理后台的 Automation 菜单里创建服务账号。创建时选择它可访问的 vault系统会生成一个一次性 token形如ops_xxx务必立即保存——这玩意只显示一次刷新页面就再也看不到了。权限配置上我的建议是每个服务账号只绑定一个或两个 vault先给只读确认真不需要写操作再放开读写服务账号的命名带上用途例如sa-finance-etl-prod后续审计日志一眼能认出来。这一步最容易踩的坑是图省事把服务账号加进了一个包含全部密钥的 Team Vault。一旦 token 泄露攻击者等于拿到了公司所有密钥的钥匙。宁可多建几个 vault 多花十分钟也别在权限上赌运气。权限配置完之后最好截图留档方便后面做季度清理时对照。4.4 用 SDK 写第一段取密代码Agent 集成用官方 SDK。以 Python 为例import os from onepassword.sdk import Client, ClientOptions, SecretReference # 服务账号 token 通过环境变量注入不要硬编码 service_account_token os.environ[OP_SERVICE_ACCOUNT_TOKEN] client Client( ClientOptions( integration_namefinance-etl-agent, # 标识调用方会记录在审计日志里 integration_version1.0.0, tokenservice_account_token, ) ) secret client.secrets.resolve( SecretReference(op://agent-prod-finance/prod-mysql-primary/password) )代码逻辑不复杂初始化客户端时带上 token调用secrets.resolve按op://vault/item/field的引用把密钥解析出来。注意两点integration_name一定要填它会让审计日志从一个匿名 token 拉取了密钥变成finance-etl-agent 这个集成在拉取密钥排障时价值巨大返回的密钥不要print不要写日志直接注入到目标连接配置里用掉。多打印一行密钥就多一个暴露渠道。4.5 验证和故障排查部署完第一时间做验证用一个故意授权不足的服务账号去拉密钥确认它会被拒再用正常的服务账号拉确认能拿到正确值。这两个用例都该写进自动化回归里。如果出现明明有权限却拉不到的情况优先排查三件事vault 名称和 item 名称拼写是否和后台一致引用是大小写敏感的、服务账号是否真的加进了对应 vault、Connect Server 是否能正常访问 1Password 云端离线模式下新 item 不会同步。我在公司内部就遇到过一回新加的 item 一直拉不到最后发现是 Connect Server 所在的容器网络断了它本身拿不到云端更新但报错信息长得像权限拒绝排查了很久才意识到不是权限问题。5. 跑通之后才发现的五个深坑与补救方案5.1 服务账号令牌本身的保管最大的讽刺是我们用 1Password 保护所有密钥却把服务账号令牌明文写进了 agent 的配置文件。我之前就见过一个团队的 agent 镜像里躺着ops_xxx这一个 token等于所有 vault 的钥匙写在了一张纸上——还不如不用密码管理器。补救思路是把令牌当作最高级机密对待注入到运行环境而不是写进代码仓库通过基础设施的密钥编排工具比如 K8s Secret 加 scoped 挂载或者云厂商的 secret 注入服务把 token 传给 agent 进程token 本身也要定期轮换作废旧值。密码管理工具保护的是受管密钥而唯一不受它保护的就是你自己那条通往它的路。这条路上的认证凭据反而需要你用最高标准对待。5.2 Vault 权限扩大化服务账号的权限不是分配完就完了。业务一迭代工程师很容易随手把新 vault 加给某个服务账号反正是测试环境嘛。一个月后回看那个服务账号已经能读七八个 vault名字还叫sa-test-agent。补救方案是常态化治理每季度清理一次服务账号的 vault 权限给权限变更加审批流1Password 后台的审计日志能看出谁在什么时候加了授权如果条件允许直接按每个 agent 一个 vault的硬性规则执行。规则简单粗暴但执行成本低、不容易漏比写一堆复杂的策略文档有用得多。5.3 日志与调试信息泄露密钥AI Agent 场景有个特殊风险很多 agent 会把自己的思考过程打印出来甚至发给大模型做上下文。如果取到的密钥不小心被当作普通文本打印或被模型记忆密钥就可能从侧面渠道流出。这不是 1Password 能解决的它只负责把密钥安全送到你手里之后的事你要自己保证。我在代码规范里加了硬性要求任何resolve出来的值不得进日志、不得进异常信息、不得作为 prompt 上下文调试期如果非要看用掩码输出只显示前后两位字符。另外agent 的对话历史最好定期清理避免密钥内容残留在会话记录里。5.4 轮换与吊销策略缺失服务账号 token 和 vault 里的密钥都是凭证。密钥轮换如果纯靠人肉三个月后大家就会忘记。我的做法是托管在 1Password 里的密钥开启自动轮换支持服务的优先用官方集成不支持自动轮换的建立日历提醒加脚本批量轮换轮换完成后在 1Password 的 item 上打版本标签服务账号 token 按季度轮换换掉后旧 token 立即吊销。吊销这件事还要演练。我建议做一次模拟泄露红队演练假设某个服务账号 token 泄露了看团队能不能在 10 分钟内完成吊销并恢复服务。做不了 10 分钟至少要有明确的操作手册别等到真出事再现场翻文档。我们演练完才发现光找到管理后台对应入口这一步就花了六分钟真出事的时候早就被人拖走了第一批数据。5.5 许可证与企业版选择的现实问题这块可能比较争议但确实是很多团队实际卡住的地方。据我目前了解1Password 面向机器身份的这些自动化能力Connect Server、服务账号、SDK是基于 Business 或 Enterprise 订阅方案的组织如果还在用很老的独立许可证模式这些自动化能力是接不上的。这也解释了为什么最近1password 6 许可证这个词在不少技术群里被反复讨论——很多团队还靠旧版本撑着自己的密码管理现在要做 AI Agent 自动化了才发现老许可证根本没法覆盖机器身份这一段。怎么判断自己该不该迁移我的建议是看两个指标一是你手上 AI Agent 的数量级——超过十个就值得认真评估企业版二是安全合规要求——如果要给审计提供机器访问的全量记录独立许可证基本满足不了。这里不是做广告只是讲一个现实老认证体系迁移有成本但从人肉管理密钥到机器身份自动化管理的这一步早晚要迈。越早规划越少背着旧系统的债往前走。如果团队暂时没有预算也可以先只迁移一小批高风险的 agent验证整套流程再逐步铺开。6. 自主凭证管理还能怎么演进6.1 从静态密钥走向短时凭证用 1Password 管静态密钥解决的是钥匙放在哪、谁在用的问题。下一步的演进方向是减少长期密钥本身让 AI Agent 通过云厂商的短期凭证机制比如角色扮演获取临时密钥或 OAuth 令牌交换来获取它们真正需要的权限而 1Password 负责分发换取临时凭证的初始凭据。这两个层次叠加之后即便 agent 进程被攻破攻击者拿到的也只是几分钟内有效的临时凭证而不是一把能开半年门的万能钥匙。这也更贴近零信任的终极形态没有长期信任只有一次次短期的、可验证的授权。6.2 让凭证使用具备可观测性我在日志里做了这样一个改动每次 agent 拉取密钥时自动在日志里生成一条结构化记录agent 名、vault、item、时间、耗时这些记录汇入统一观测平台。当某段时间内拉取量异常、某个 item 被多个 agent 重复拉取告警规则会自动触发。这其实就是零信任持续验证的数据基础——没有数据策略就无从谈起。把凭证使用当成业务指标一样观察你会提前看到很多安全事件。比如我们上线一个月后观测平台发现一个服务的取密频率在深夜突然翻了三倍追查下来是一个定时任务被写成了死循环虽然没出事但这种看到问题的能力本身就是安全的底气。6.3 一点实在的经验回看这段整改我最大的感受是管好 AI Agent 的凭证工具只占三分之一剩下三分之二是权限设计和工作习惯。1Password 把取密钥变得简单了但给哪个 agent 哪把钥匙、用多长时间、用完怎么销这些决策终究是靠架构师和安全团队定的。如果你正打算给 AI Agent 接密钥管理我的建议是先花一个下午把 vault 结构和服务账号权限设计画清楚再动手部署。设计阶段多花一小时后面能省下好几个加班的夜。还有一个小技巧把服务账号的命名规范和 vault 命名规范写成一份团队内部的一页纸贴进运维 wiki比任何培训都管用。毕竟密钥管理的安全最后拼的还是人在日常工作中是否走得顺、是否懒得绕路。