DevOps

AI Agent 写代码已经不稀奇了，真正尴尬的是下一步：它写完以后，怎么上线？ 很多团队做 Agentic Coding Demo 时都会跳过这个问题。让 Agent 改一个 React 页面、生成一个 API、补一组测试，这些都能在本地仓库里闭环。但只要任务变成“把这个服务部署到云上，给我一个可访问的 URL”，Agent 很快就会撞墙：登录、注册、OAuth、MFA、创建 API Token、复制粘贴密钥、选择账单计划。 这些流程对人类是安全护栏，对后台 Agent 则是硬中断。 Cloudflare 这次在 HN 上火起来的 Temporary Cloudflare Accounts for AI agents 很有意思，不是因为它又发了一个“AI 平台功能”，而是因为它回答了一个非常工程化的问题：能不能让 Agent 先完成部署，再让人类决定是否接管？ 我的判断是，这个方向比“给 Agent 一个长期 Root API Key”健康得多。它不完美，但至少把 Agent 部署的权限边界，从“信任一个会写代码的黑盒”改成了“给它一段短命的、可丢弃的执行空间”。 这个功能到底解决了什么 Cloudflare 的方案很直接：Agent 或开发工具可以执行： wrangler deploy --temporary 然后 Worker 会被部署到一个临时 Cloudflare 账号下，部署结果可以在线访问。官方博客说明，这个临时部署会保持 60 分钟；如果用户觉得结果可用，可以在这段时间内 claim 这个临时账号，把它变成自己的正式资源。 用人话说就是：先让 Agent 把东西跑起来，不要一上来就问我要身份证、银行卡和长期 Token。 这跟传统 PaaS 的匿名预览有点像，但关键差异在于它面向的是 Agent 工作流。Cloudflare 明确把场景放在 AI coding agents 上：Agent 写了 Worker、网站、API，马上就能把产物部署出去，给用户一个可点开的结果，而不是停在“请你登录 Cloudflare Dashboard”的半成品状态。 ...

如果你在生产环境跑过 AI Agent，大概率遇到过一个头疼的问题：Agent 怎么安全地访问那些需要 API Key 的服务？ 传统方案很简单：把密钥配置在环境变量里，Agent 启动时读取。但这套逻辑是给"确定性程序"设计的——程序行为可预测，不会被外部指令诱导去做你没想过的事。 AI Agent 不一样。它们是非确定性的，能被 prompt injection 诱导，能被恶意网页操纵，能在 RAG 流程里接收有害指令。密钥一旦进了 Agent 的上下文，就等于随时可能被抽走。 这是一个真实存在的威胁，不是理论推演。Infisical 最近的博客详细描述了攻击路径：攻击者通过文档注入、恶意网页或工具调用让 Agent “主动"把环境里的密钥发到攻击者控制的端点。哪怕你上了多层 guardrails，也没有办法保证 Agent 绝对不泄露。 传统解法为什么不够用 业界的应对思路大概分三类： ① 短命凭证（Short-lived Tokens） OAuth2 的 access/refresh token 模式，API 返回临时凭证，过期自动失效。配合自动化密钥轮换，攻击者拿到的那串字符很快变成废纸。 听起来合理，但本质上只是降低窗口期，没有解决根本问题——凭证依然会泄露，攻击者只要在失效前用完就赚了。 ② 防火墙和网络隔离 只允许 Agent 访问特定 IP 段，不允许出站直连。攻击者通过 Agent 发起请求，同样会经过那些被允许的端点，该泄露还是泄露。 ③ 自行实现凭证代理 Anthropic 的 Managed Agents 架构、Vercel 的 credential brokering、Cloudflare 的 outbound workers，都走了同一条路：Agent 的请求经过一个代理层，由代理负责在请求发出前把凭证注入，Agent 自己从不直接接触密钥。 这条路是对的，但每家公司都得自己造轮子。 Agent Vault 的思路 Infisical 新开源的 Agent Vault 把这条路做成了通用产品。它的核心设计原则只有一条：Agent 永远拿不到金库里的密钥，只能通过代理间接使用。 ...