---
title: "Formal：给云端 Agent 生产访问，用 OIDC，不用长期密钥 - Angryecho"
description: "我们讨厌密钥。从第一天起，Formal 就在把基础设施里的长期密钥往零推。几周前上线的 OIDC Integrations，让任意机器工作负载靠自己的基础设施身份认证到 Formal，并可顺带附上人类身份证明。"
canonical_url: "https://www.angryecho.com/c/DevOps/p/P2TBBrj7QavAoH0x2p8ki"
meta:
  "og:description": "我们讨厌密钥。从第一天起，Formal 就在把基础设施里的长期密钥往零推。几周前上线的 OIDC Integrations，让任意机器工作负载靠自己的基础设施身份认证到 Formal，并可顺带附上人类身份证明。"
  "og:image": "https://www.angryecho.com/_og/d/c_Post%2Ctitle_~5ZCQ5qe9572R%2Cdescription_~5ZCQ5qe95LiA5LiL77yM5bCx5LiK5ZCQ5qe9572R44CC%2CpostId_P2TBBrj7QavAoH0x2p8ki%2Crevision_~MjAyNi0xMC0yOVQwMjo1NTo1OS41MDEzMzFa%2Cp_Ii9jL0Rldk9wcy9wL1AyVEJCcmo3UWF2QW9IMHgycDhraSI%2Cs_r8c48uDBQ8G5f3lM.png"
  "og:image:height": "630"
  "og:image:type": image/png
  "og:image:width": "1200"
  "og:title": "Formal：给云端 Agent 生产访问，用 OIDC，不用长期密钥"
---

> Index of every page on this site: [llms.txt](https://www.angryecho.com/llms.txt)

# **Formal：给云端 Agent 生产访问，用 OIDC，不用长期密钥**

我们讨厌密钥。从第一天起，Formal 就在把基础设施里的长期密钥往零推。几周前上线的 OIDC Integrations，让任意机器工作负载靠自己的基础设施身份认证到 Formal，并可顺带附上人类身份证明。工程师 Aditya Saligrama 在 2026 年 10 月 23 日的博文里，讲了他们怎么把同一套机制用到 Cursor、Devin 这类云端编码 Agent 上：可审计、可策略控制、以只读为主的生产数据与云访问。\[1]

## 我们在 Formal 怎么接 OIDC

机器工作负载的 OIDC 流程大致是：从环境变量或云元数据拿到短时 JWT，当作 Bearer 打到依赖方（RP）；RP 用 IdP 的 JWKS 验签，并核对多租户下的 claim，再映射成本地机器身份。Formal 在此之上加了几块：

- 每条集成可写 **CEL 条件**，只有条件为真才允许认证；OIDC claim 也可进入 Permissions，做更细的控制面授权。
- 调用方可打 `CreateFederationToken`，换取嵌入源 OIDC claim 的**短时 Connector token**，让工作负载走凭据注入代理，而不必自己存长期密钥。
- **SPIFFE / SPIRE** 的 JWT-SVID 按同类 OIDC 校验；SPIFFE ID 可进策略。
- Endpoint 与 Kubernetes Egress Agent 也可走 OIDC 认证。

每条 OIDC 集成默认对应一个机器用户。但很多工作负载并不「为自己」行动：CI 往往能归因到推 commit 的人，云端 Agent 也常是有人从 Slack 拉起的。于是集成可再指定一个 token claim，Formal 把它解析成**人类身份**，写入日志并作为策略输入。机器身份可以密码学认证；人类身份则由下游系统主张——我们接受它，是因为客户信任作出主张的系统，并在 Formal 里显式配置了这份信任。

这个形状其实最早是为 BI 场景准备的：Metabase 一类工具对每个库往往只有一份凭据，却要按登录的人做不同控制。把终端用户身份透传进查询，Formal 就能按人评策略。同一套原语，也正好套在多人共用、可从 Slack / Linear / GitHub 拉起的云端 Agent 上：平台很难为每个可能启动 Agent 的人发一份独立长期凭据，却可以签发写明「哪次会话、哪个仓库、谁拉起」的签名 token。\[1]

## 我们自己怎么吃狗粮

生产库、S3、日志集群前有 Connector；笔记本上的编码 Agent 用法有 Formal Endpoint 盯着。控制面用 Terraform 管，内部最早一批用例就是把 Terraform Cloud 对 Formal 控制面的认证从长期 API key 换成 OIDC。

我们也在大量用云端编码 Agent，开发逐渐从本机挪到云沙箱。以前不愿把基础设施交给它们，是因为几乎只能发静态凭据、粒度又粗。OIDC 之后不必再发静态凭据，还可以按「谁拉起、在哪个 GitHub 仓库干活」评策略。文中举例的用法包括：

1. **产品分析**：过去工程师手写 SQL、导出 CSV 再贴回 Agent；现在可把每次云端 Agent 会话当成独立身份，经审批拿短时、只读的库访问（受会话 ID 与具体库约束）。
2. **异步工作流排障**：编排侧没有现成远程 MCP 时，把编排器登记为 Formal 资源、只读 API key 存为 Native User，Agent 仍按审批拿短时访问，请求记日志并归因到 Agent 与发起工程师。
3. **测云原生能力**：Agent 可经 OIDC 联邦到 Formal 开发租户与云厂商开发账号，在真实环境里验证改动（例如在开发用 Azure 账号里起 AKS、验证 Operator 与策略同步），减少脆的 mock。\[1]

## 边界：临时委托，不是再发一把永久钥匙

云端 Agent 要自己闭环——拉用量、查故障、在接近真实的环境里验收——不该等于再发一把可复用的长期密钥。OIDC 把单次 Agent run 建模成唯一工作负载身份；经 Formal 外出时，访问可绑到拉起的人、仓库与会话。文中口径是：生产侧保持**只读**且**审批门槛**；开发环境权限可以更宽，但不要变成永久。\[1]

> 说明：以上据 Formal 工程博文转述，属厂商自家实践。短时 token、审批与只读并不等于「零风险开生产」；具体集成、策略与权限范围以 Formal 文档及各组织自身配置为准。

## 来源

> \[1] [Giving Cloud Agents Production Access with OIDC, Not Secrets](https://www.formal.ai/blog/cloud-agents-oidc-infrastructure/)，Aditya Saligrama / Formal，2026年10月23日。查询日：2026年10月28日。

> \[2] Hacker News： https://news.ycombinator.com/item?id=50261584

#Formal #OIDC #云端Agent #基础设施安全 #零长期密钥 #Cursor #Devin

排序方式 :

### **成为第一条评论！**

Nobody's responded to this post yet. Add your thoughts and get the conversation going.

```json
{"@context":"https://schema.org","@graph":[{"@id":"https://www.angryecho.com/c/DevOps/p/P2TBBrj7QavAoH0x2p8ki#post","@type":"DiscussionForumPosting","commentCount":0,"dateModified":"2026-10-29T02:55:59.501Z","datePublished":"2026-10-27T16:25:00.000Z","description":"我们讨厌密钥。从第一天起，Formal 就在把基础设施里的长期密钥往零推。几周前上线的 OIDC Integrations，让任意机器工作负载靠自己的基础设施身份认证到 Formal，并可顺带附上人类身份证明。","headline":"Formal：给云端 Agent 生产访问，用 OIDC，不用长期密钥","isPartOf":"https://www.angryecho.com/c/DevOps","mainEntityOfPage":"https://www.angryecho.com/c/DevOps/p/P2TBBrj7QavAoH0x2p8ki","text":"我们讨厌密钥。从第一天起，Formal 就在把基础设施里的长期密钥往零推。几周前上线的 OIDC Integrations，让任意机器工作负载靠自己的基础设施身份认证到 Formal，并可顺带附上人类身份证明。工程师 Aditya Saligrama 在 2026 年 10 月 23 日的博文里，讲了他们怎么把同一套机制用到 Cursor、Devin 这类云端编码 Agent 上：可审计、可策略控制、以只读为主的生产数据与云访问。[1]\n\n我们在 Formal 怎么接 OIDC\n\n机器工作负载的 OIDC 流程大致是：从环境变量或云元数据拿到短时 JWT，当作 Bearer 打到依赖方（RP）；RP 用 IdP 的 JWKS 验签，并核对多租户下的 claim，再映射成本地机器身份。Formal 在此之上加了几块：\n\n\n\n\n\n每条集成可写 CEL 条件，只有条件为真才允许认证；OIDC claim 也可进入 Permissions，做更细的控制面授权。\n\n\n\n调用方可打 CreateFederationToken，换取嵌入源 OIDC claim 的短时 Connector token，让工作负载走凭据注入代理，而不必自己存长期密钥。\n\n\n\nSPIFFE / SPIRE 的 JWT-SVID 按同类 OIDC 校验；SPIFFE ID 可进策略。\n\n\n\nEndpoint 与 Kubernetes Egress Agent 也可走 OIDC 认证。\n\n每条 OIDC 集成默认对应一个机器用户。但很多工作负载并不「为自己」行动：CI 往往能归因到推 commit 的人，云端 Agent 也常是有人从 Slack 拉起的。于是集成可再指定一个 token claim，Formal 把它解析成人类身份，写入日志并作为策略输入。机器身份可以密码学认证；人类身份则由下游系统主张——我们接受它，是因为客户信任作出主张的系统，并在 Formal 里显式配置了这份信任。\n\n这个形状其实最早是为 BI 场景准备的：Metabase 一类工具对每个库往往只有一份凭据，却要按登录的人做不同控制。把终端用户身份透传进查询，Formal 就能按人评策略。同一套原语，也正好套在多人共用、可从 Slack / Linear / GitHub 拉起的云端 Agent 上：平台很难为每个可能启动 Agent 的人发一份独立长期凭据，却可以签发写明「哪次会话、哪个仓库、谁拉起」的签名 token。[1]\n\n我们自己怎么吃狗粮\n\n生产库、S3、日志集群前有 Connector；笔记本上的编码 Agent 用法有 Formal Endpoint 盯着。控制面用 Terraform 管，内部最早一批用例就是把 Terraform Cloud 对 Formal 控制面的认证从长期 API key 换成 OIDC。\n\n我们也在大量用云端编码 Agent，开发逐渐从本机挪到云沙箱。以前不愿把基础设施交给它们，是因为几乎只能发静态凭据、粒度又粗。OIDC 之后不必再发静态凭据，还可以按「谁拉起、在哪个 GitHub 仓库干活」评策略。文中举例的用法包括：\n\n\n\n\n\n产品分析：过去工程师手写 SQL、导出 CSV 再贴回 Agent；现在可把每次云端 Agent 会话当成独立身份，经审批拿短时、只读的库访问（受会话 ID 与具体库约束）。\n\n\n\n异步工作流排障：编排侧没有现成远程 MCP 时，把编排器登记为 Formal 资源、只读 API key 存为 Native User，Agent 仍按审批拿短时访问，请求记日志并归因到 Agent 与发起工程师。\n\n\n\n测云原生能力：Agent 可经 OIDC 联邦到 Formal 开发租户与云厂商开发账号，在真实环境里验证改动（例如在开发用 Azure 账号里起 AKS、验证 Operator 与策略同步），减少脆的 mock。[1]\n\n边界：临时委托，不是再发一把永久钥匙\n\n云端 Agent 要自己闭环——拉用量、查故障、在接近真实的环境里验收——不该等于再发一把可复用的长期密钥。OIDC 把单次 Agent run 建模成唯一工作负载身份；经 Formal 外出时，访问可绑到拉起的人、仓库与会话。文中口径是：生产侧保持只读且审批门槛；开发环境权限可以更宽，但不要变成永久。[1]\n\n\n\n说明：以上据 Formal 工程博文转述，属厂商自家实践。短时 token、审批与只读并不等于「零风险开生产」；具体集成、策略与权限范围以 Formal 文档及各组织自身配置为准。\n\n来源\n\n\n\n[1] Giving Cloud Agents Production Access with OIDC, Not Secrets，Aditya Saligrama / Formal，2026年10月23日。查询日：2026年10月28日。\n\n\n\n[2] Hacker News：https://news.ycombinator.com/item?id=50261584\n\n#Formal #OIDC #云端Agent #基础设施安全 #零长期密钥 #Cursor #Devin","url":"https://www.angryecho.com/c/DevOps/p/P2TBBrj7QavAoH0x2p8ki","author":{"@type":"Person","name":"UID:51426","url":"https://www.angryecho.com/u/NGA51426"},"interactionStatistic":[{"@type":"InteractionCounter","interactionType":"https://schema.org/LikeAction","userInteractionCount":0},{"@type":"InteractionCounter","interactionType":"https://schema.org/DislikeAction","userInteractionCount":0},{"@type":"InteractionCounter","interactionType":"https://schema.org/ViewAction","userInteractionCount":0},{"@type":"InteractionCounter","interactionType":"https://schema.org/ShareAction","userInteractionCount":0}]}]}
```

## Sitemap

See the full [sitemap](https://www.angryecho.com/sitemap.md) for all pages.