Cloudflare推AI临时账号：安全护城河还是花架子？

2026年6月21日

Cloudflare 又整新活了。这次不是什么 CDN 加速也不是 DDoS 防护，而是一套专门给 AI Agent 用的临时账号系统。说实话，我第一反应是——又来了，又来了。

发布会演示我一般只信一半。剩下那一半呢？得等开发者社区开始吐槽以后才知道。PPT 谁都会做。

Cloudflare 这公司有意思，它从来不缺点子。从 Workers 到 D1 到 R2，每个产品出来的时候都让人眼前一亮。但亮完之后呢？落地才是真功夫。

这次他们搞的临时账号（Temporary Accounts），说白了就是给 AI Agent 一个"用完即走"的身份。Agent 要访问你的数据？给你一个短期令牌，做完事自动过期。听起来很美对吧？

嗯。

我盯着屏幕愣了三秒。然后开始想一个问题——谁会给 Agent 开这个权限？

场景：我到底敢不敢让 Agent 替我干活？

先讲一个真实踩坑。

上个月我写了个自动化脚本，让 GPT-4o 帮我整理公司的一堆合同。不是什么敏感合同，就是一些公开的招标文档。我把 PDF 一股脑丢进一个临时目录，告诉 GPT "帮我提取关键条款、截止日期、预算范围"。

结果呢？

第一次运行，它把我桌面的截图文件夹也扫进去了。第二次，它把我微信聊天记录导出也给当合同分析了。第三次——好吧第三次我放弃了。

你说这是 Agent 的锅还是我配置的锅？都有。但问题的核心是：我根本控制不了 Agent 的边界。它像个三岁小孩，你给它一块糖它就乱跑。

冲了一杯咖啡——周五下午就是这样——然后开始干活。我看着 Cloudflare 的临时账号方案，突然觉得它走了一条很危险的路。

临时账号到底解决什么问题？

Cloudflare 的博客写得很清楚。他们说，现在 AI Agent 面临的最大问题不是能力不够，而是授权泛滥。

你今天让一个 Agent 帮你做一件事，就得给它一把钥匙。这把钥匙可能是你的 GitHub token、你的 Google Drive 权限、你的 AWS 凭证。Agent 用完之后呢？Token 没吊销。六个月后，这个 Agent 的某个版本被攻破了，你的所有数据就飞了。

临时账号的想法是：Agent 每次需要访问资源时，创建一个临时的、作用域极窄的身份。这个身份只能看到它当下需要的数据，而且几个小时后自动消失。

逻辑上无懈可击对吧？

但吃过亏的人就懂。

理想 vs 现实：落地之后会发生什么？

矛盾是吧？但吃过亏的人就懂。

让我列举几个可能翻车的地方。不过先说好——我不列编号，我就是想到哪说到哪。

第一，Agent 的"需要"怎么定义？ 你让 Agent 写一篇市场分析报告，它需要看过去三年的销售数据。但这个"需要"是一次性评估的，还是动态变化的？如果 Agent 写到一半发现还需要查看竞品数据，它得申请一个新权限，还是原来的临时账号自动扩展？如果是前者，Agent 的工作流会被频繁打断；如果是后者，那临时账号和普通账号就没区别了。

第二——这个才是真的大问题——谁授权？ 临时账号的创建总得有人批准吧？如果每次都需要人工点击"同意"，那 Agent 的效率优势就没了。如果不需要人工批准，那临时账号和开放 API 又有什么区别？Cloudflare 的说法是"支持策略驱动的自动化授权"，但策略怎么写？谁写？写错了怎么办？

我揉了揉眼睛接着看文档。然后看到更让我头大的东西。

第三，服务端怎么接？ 临时账号不是 Cloudflare 一家能搞定的事。你的数据库、你的对象存储、你的消息队列——这些服务都得认可 Cloudflare 颁发的临时凭证。AWS 支持吗？Azure 支持吗？企业内部的老系统支持吗？都不支持。那临时账号就只能管 Cloudflare 自家那一亩三分地。Agent 要访问别的东西呢？还是得给全套凭据。

怎么说呢。想法是好的，但落地的坑至少还有三丈深。

横向对比：其他人怎么做的？

其实不只是 Cloudflare 在做这个方向。

OpenAI 今年早些时候搞了个"受限执行环境"（Constrained Execution Environment），让 GPT-4 系列模型在一个沙箱里跑代码。想法差不多——限制 Agent 的权限，不让它越界。但 OpenAI 的沙箱是在模型层做限制，而不是在基础设施层。

Anthropic 走的是另一条路。他们搞了"工具使用策略"（Tool Use Policy），在模型输出的格式里就嵌入了权限声明。Agent 想调用一个 API？它得先声明调用理由，由策略引擎裁决。但这个方案的问题是——它跟具体模型绑定太紧。你用别的模型？对不起，这套策略不生效。

Google 的 Vertex AI Agent Builder 也在做类似的事，他们管这叫"上下文感知授权"（Context-Aware Authorization）。听起来很高级，但实际就是在每个 API 调用里夹带一个上下文令牌。令牌过期了或者上下文不对，调用就失败。

Cloudflare 这次的路线跟谁都不一样。它说你们都在模型层和应用层做限制，我在基础设施层做。只要流量经过 Cloudflare 网络——无论是 API 请求、数据库查询还是文件访问——我都能在中间插入一个授权检查层。

这个思路很 Cloudflare。什么流量都管，什么都想做中间人。

我原本以为…后来发现…

我原本以为这套方案很聪明。Cloudflare 网络确实无处不在，它确实能看到巨大的流量，理论上做个中间授权层是可行的。

后来发现我太天真了。

原因很简单：加密流量。今天的网络流量绝大部分是 HTTPS 加密的。Cloudflare 能拦截加密流量做检查吗？能，但前提是你的流量通过它的反向代理。也就是说，你得把服务部署在 Cloudflare 后面，或者至少把 DNS 交给 Cloudflare 托管。

问题是，很多企业服务的流量根本不经过 Cloudflare。企业内部 API 走内网，数据库走专线，SaaS 服务直接调用 AWS 或 Azure API。这些流量 Cloudflare 看都看不到，它怎么做授权检查？

所以这套方案的实际适用范围，比宣传的小得多。

不过话说回来，Cloudflare 自己也知道这个问题。他们在博客里提到——用的是很委婉的说法——"我们正在与主要云服务商合作，扩展临时账号的适用范围。"翻译成人话就是：现在还只能管我自家的东西，别人的以后再说。

技术深扒：临时账号是怎么实现的？

既然要写，就把技术细节拆清楚。

Cloudflare 的临时账号系统，底层用的是他们的 Workers 平台 + D1 数据库 + 短期令牌服务。

流程大概是这样的：

Agent 发起一个资源访问请求，请求里带一个"意图声明"（Intent Declaration）
Workers 上的授权服务收到请求，解析意图
策略引擎根据预定义的策略（用 Cloudflare 的配置语言写的）做出决策
如果通过，D1 里创建一条临时账号记录，包含作用域、过期时间、审计日志
返回一个短期令牌（JWT格式），有效期从5分钟到24小时不等
Agent 拿着令牌去访问目标资源
资源方的网关验证令牌（通过 Cloudflare 的公共验证端点）
令牌过期后，D1 记录标记为"已过期"，后续任何使用令牌的请求被拒绝

关键点在于第7步：资源方的网关必须集成 Cloudflare 的令牌验证 API。如果你的服务不集成这一步，那临时账号就是一张废纸。

再说说这个"意图声明"（Intent Declaration）。它是 Agent 发来的一个 JSON 对象，描述了 Agent 想做什么：

{
  "intent": "read_customer_data",
  "scope": {
    "resources": ["database://customers/transactions"],
    "operations": ["read"],
    "time_range": "2026-01-01/2026-06-01"
  },
  "rationale": "Generate quarterly report for customer transaction analysis",
  "max_duration": "3600"
}

我原本以为这种结构化的声明很可靠。后来发现，Agent 完全可以在"rationale"字段里写"为了生成报告"，然后实际访问了不该访问的数据。声明只是声明，不是保证。Cloudflare 的方案建立在 Agent 是诚实的这个假设上——而这个假设在安全领域几乎是最危险的假设。

怎么说呢。这东西就像一个保险箱，所有锁都是好的，但你把钥匙交给了来修水管的人，然后告诉他"你只用开水龙头就好"。

安全领域的老问题：最小权限原则

临时账号这个概念本身不新。它其实就是计算机安全里最经典的最小权限原则（Principle of Least Privilege）的一个具体实现。阿里云有 RAM 角色的临时令牌，AWS 有 STS 的临时凭证，Google Cloud 有临时访问令牌。这些都已经跑了好多年了。

Cloudflare 的"创新"在于，它把临时身份这个概念扩展到了 AI Agent 这个新物种上。以前的临时令牌是给人用的——开发者需要临时访问一个服务器，去 AWS STS 拿一个临时密钥。现在的临时令牌是给 Agent 用的——Agent 需要临时访问一个数据源，去 Cloudflare 的临时账号服务申请一个身份。

形式上一样，但本质完全不同。

人的行为是可预测的。我给一个运维人员一个临时密钥，他在 2 小时内做完运维操作就会关掉。但 Agent 的行为呢？Agent 可能在执行过程中因为提示词注入，被恶意用户引导去做一些奇怪的事。这时候临时账号反而成了帮凶——Agent 有合法的临时身份，然后它拿着这个身份去做了坏事。

我喝了口水继续看。Cloudflare 显然也想到了这个问题，所以他们在方案里加了一个"行为审计"（Behavioral Audit）的模块。每次 Agent 使用临时账号时，操作都会被记录，然后会被离线分析。如果发现异常行为模式，立即吊销账号并告警。

但这里又有一个问题：审计是事后诸葛亮。真正危险的操作可能在你察觉到之前就已经完成了。对于读取类操作，事后审计没问题。但对于删除类、修改类操作，事后审计就是马后炮。

所以到底用不用？

行吧。吐槽了这么多，也得说点正经的。

Cloudflare 这套方案，对于特定场景确实有价值。

场景一：公开数据分析。比如你的 Agent 需要分析 GitHub 上的开源项目趋势、抓取公开网页内容、分析公开数据集。这些场景下，临时账号基本没有安全风险，还能让 Agent 的工作流更自动化。

场景二：沙盒环境。如果你在开发阶段让 Agent 访问测试环境，临时账号可以防止测试数据污染正式环境。

场景三：一次性任务。比如"帮我比较这三款产品的定价"，Agent 只需要一次只读访问。临时账号用完即焚，确实比手动管理 API Key 好。

但对于生产环境的核心数据——比如客户信息、财务数据、代码仓库——我还是那句话：我不敢。

至少目前还不敢。

生成代码必须人工审查，否则线上事故背锅的是自己。同理，给 Agent 开数据访问权限，也必须有人盯着。不是说 Cloudflare 的方案不好，而是这个问题的复杂度本身就超出了纯技术方案能解决的范畴。

它涉及的是信任模型的问题——你有多信任一个 AI Agent？你用什么机制来验证它的每一次操作都是合法的？当 Agent 的行为和预期不一致时，你有足够快的熔断机制吗？

这些问题，不是一个临时账号系统能回答的。

社区反馈怎么样？

我去翻了 HN 上那个帖子的评论区——187 条评论。这是 HN 上比较活跃的帖子了，说明开发者对这个话题确实有话说。

有意思的是，前排高赞评论跟我的感觉差不多。有人说："So Cloudflare wants to be the identity provider for all AI agents? That's ambitious." 下面有人回："They already want to be the network for everything. Why not identity too?"

但也有人提出了一个我没想过的角度：临时账号对小型开发者和独立黑客的价值被低估了。大公司有自己的 IAM 系统，可以轻松管理 Agent 的权限。但一个独立开发者，让他搭建一套完整的权限管理系统根本不现实。Cloudflare 如果能提供一个"开箱即用"的临时账号服务，对于小团队来说是巨大的效率提升。

这个角度确实有道理。独立开发者不需要管理复杂的 RBAC 策略——"你只要告诉我你的 Agent 要做什么，剩下的 Cloudflare 来管"——这个体验确实吸引人。

不过底下立刻有人反驳："Then you're locked into Cloudflare." 嗯，这是 Cloudflare 的惯用套路了。给你一个超好用的一键解决方案，然后你发现以后离不开它了。自由不是免费的。

总结——不是总结

说了这么多，其实没有一个简单的答案。

Cloudflare 的临时账号方案，方向是对的。AI Agent 需要更好的授权管理，这件事毋庸置疑。但"方向对"和"现在就能用"之间，隔着一个巨大的鸿沟。

我自己的判断是：今年下半年到明年上半年，我们会看到至少 3-5 家类似的服务出现。AWS 肯定会跟进，Google Cloud 也不会闲着。AI Agent 的授权管理将成为一个新的赛道，就像当年的 API Gateway 市场一样。

至于 Cloudflare 能不能在这个赛道里跑出来，我不做预测。但有一点是肯定的——安全从来不是一个技术问题，它是一个流程问题。最好的技术方案，如果配合的是松散的流程管理，照样形同虚设。

反正我已经注册了 Cloudflare 的临时账号 Beta。先玩了再说。好不好用，等踩了坑再告诉你们。

实际上，我更好奇的是：当所有大厂都推出 Agent 授权方案后，开发者会选择哪个？是选 Cloudflare 这种"插在中间"的方案，还是选 OpenAI/Anthropic 这种"在模型层解决"的方案，还是选 AWS/GCP 这种"跟云基础设施深度绑定"的方案？

这其实不只一个技术问题。它背后决定了 AI 行业的基础设施格局。如果 Cloudflare 赢了，意味着 AI 时代的认证层从云服务商手中转移到了"网络中间层"。如果云服务商赢了，意味着 AI Agent 的授权将继续绑死在云平台上。如果模型厂商赢了——那意味着认证逻辑将被嵌入到模型本身，这将是真正的范式转变。

我觉得最后会是三足鼎立的局面。不同的场景用不同的方案。高安全性场景用云服务商的方案，灵活性场景用网络中间层方案，轻量场景用模型层方案。

再说一个冷知识：Cloudflare 这个临时账号系统的核心代码，有一部分是基于开源项目 OAuth 2.0 的 Token Exchange 模式扩展的。如果你懂 OAuth 2.0 的 Token Exchange 流程，你基本上能猜到 Cloudflare 的实现思路。只不过他们把 Token 的生命周期从"按天"压缩到了"按小时甚至按分钟"，并且加入了 Agent 的"意图声明"这样一个新的抽象层。

讲真，我觉得这个"意图声明"的概念才是 Cloudflare 这次最有价值的部分。意图驱动授权（Intent-Driven Authorization）这个思路如果做成熟了，它可能比临时账号本身更有影响力。它让 Agent 从"被动调 API"变成了"主动声明意图"——这个思维转换，可能会影响未来 AI Agent 架构的设计。

但这些都是后话了。眼前的现实是：Cloudflare 的临时账号现在才 Beta，文档还不全，API 还在迭代。想上生产的，请三思。

反正我是会用它来写一些低风险的小工具的。至于让它碰我的生产数据库——

算了。等它迭代几个版本再说吧。

关于维基框架

维基框架（Wiki Framework）是一套面向复杂业务场景的轻量级开发框架，支持多语言、多协议、多部署形态。适用于企业级应用开发、微服务架构、云原生部署等场景。

官网：https://framewiki.com
Gitee：https://gitee.com/wiki-framework
GitHub：https://github.com/wiki-framework
示例项目：https://gitee.com/cdkjframework/framewiki-example
📄 许可证：MulanPSL-2.0（木兰宽松许可证，第2版）