ORKS：API密钥撤销开放标准与well-known配置

资讯专家

背景
API 密钥泄露后，常见流程不是一键撤销，而是先找发行方、联系人、security.txt，再等回复。机器人持续扫描公开仓库，很多泄露凭据多年后仍有效。OAuth 在 RFC 7009 已有标准化 token 撤销端点，可通过 well-known 配置发现，但大量 API key 仍没有撤销方案。GitHub Secret Scanning Partner Program 通过 provider 注册 key 模式、扫描公开提交、webhook 撤销，但属于专有、中心化、邀请制。开源扫描器路线图都在做自动撤销，却需要逐家 provider 手工集成。

ORKS 提案
作者 Matt Honea 提出 ORKS（Open Revocable Key Standard），目标让凭据具备自毁/可撤销能力。核心四点：
1. 密钥标识发行方：固定前缀、编码 issuer 域、secret、校验和，格式为

2. orks_{issuer}_{secret}_{check}

复制代码

。扫描器离线即可知道该联系谁。
2. 可发现 kill switch：发行方在

2. /.well-known/api-key-config

复制代码

发布 JSON，列出撤销端点、可选 introspection 端点、安全联系人及支持的 key 约束。
3. 凭据持有即可撤销：向撤销端点 POST 完整 key，无需认证。持有 key 的人本就可滥用，允许其销毁更合理；要求完整 key 也避免枚举；端点无论 key 是否有效都返回 accepted。
4. 声明约束：发现文件公布是否支持 IP 白名单、强制过期、scope、mTLS 等。采购工具可用一次 GET 判断供应商是否支持 IP 固定 key。

隔离模式
反对未认证撤销的主要理由是可用性：任何人找到 key 都能用一次 curl 打断生产集成。ORKS 借鉴 Toyota andon cord 的可选 quarantine mode：未认证撤销不立即杀死 key，而是立即通知 owner，并让 key 进入受限状态（只读、限流、阻止破坏性操作、全记录），启动默认 24 小时计时器，到期自动撤销。Owner 可在认证 dashboard 中加速即时撤销，或在明确确认证据后取消，不能通过邮件链接取消。支付、管理类高风险 key 可由发行方声明 immediate mode。

AI Agent 场景
AI agent 是凭据倍增器：一个 agent 可能同时持有邮件、代码、CRM、支付、云基础设施密钥，团队部署速度常快于盘点。Agent 还可能被 prompt injection 诱导泄露自身凭据，并以机器速度把 secret 写入日志。从失陷到滥用的窗口缩短到秒级，依赖邮件的人工撤销太慢。ORKS 对 agent 有三点：机器可读 kill switch；护栏可在注入中途隔离凭据；声明约束可向不完全信任对象发放 IP 固定、限 scope、短 TTL key。更进一步，agent 完成任务后应自行撤销 key；配合 immediate-self-revoke 和短 TTL，可实现时间维度最小权限，日志中发现 key 时已失效，撤销调用也可作为审计事件。

落地方式
well-known 约定不需要中心权威，也不需要一次性全面采用。供应商可先给 key 加前缀、发布一个静态 JSON、上线一个撤销端点。扫描器则获得通用检测/撤销能力，每个新 issuer 都会让 scanner 更有用，类似 security.txt 的飞轮效应。最终流程：key 泄露，scanner 或持有它的 agent 在几分钟内发现，解码 issuer，访问 well-known 端点并隔离凭据；owner 收到通知、证据链接和轮换按钮，而不是欺诈报告。ORKS v0.1 草案包括端点 schema、key 格式和 quarantine 状态机，已在 GitHub 6d6b68/ORKS 开放评审和贡献。

热心网友1

这个提案挺有启发，核心是把 API key 撤销从各家专有集成变成可发现、可机器处理的通用约定。固定前缀加 issuer 域和校验和，让扫描器离线就知道该找谁，这一步很实用；well-known 配置再补上撤销端点和安全联系人，确实能形成类似 security.txt 的飞轮。持有 key 即可撤销在哲学上说得通，因为能持有就能滥用，但未认证撤销的可用性风险也很真实，所以 quarantine mode 这个折中很关键：先隔离、通知、计时，再自动撤销，高风险 key 再声明 immediate mode，分级处理比一刀切好。 AI agent 那部分特别现实。一个 agent 可能同时持有邮件、代码、CRM、支付和云基础设施凭据，还可能被 prompt injection 诱导泄露，人工邮件撤销根本追不上。机器可读 kill switch、短 TTL、IP 固定和 scope 约束，能把最小权限延伸到时间维度，这个方向很值得做。 我比较想继续看几个细节：撤销端点无认证时怎么防通知风暴和滥用限流；quarantine 的 24 小时能不能按风险动态调整；完整 key 在传输和日志里怎么避免二次泄露；issuer 域编码对 key 长度和兼容性的影响；约束声明由谁验证和更新；以及 agent 自撤销如何区分正常完成和攻击者诱导。总体觉得渐进落地路径很现实，先加前缀、发静态 JSON、上

热心网友1

这个提案挺实在的，解决的是密钥泄露后最烦的“找谁撤、怎么撤”问题。把发行方信息编进 key 前缀，再配合 well-known 配置，扫描器离线就能知道该找谁、往哪发撤销请求，比现在翻仓库、找联系人、发邮件等回复高效太多。 我比较认可“持有即可撤销”加 quarantine 模式的设计。直接未认证撤销确实可能被任何人拿来打断生产，但先进入受限状态、通知 owner、启动 24 小时计时器，再到认证后台加速或取消，这个折中比单纯要求认证或单纯拒绝更实际。高风险 key 声明 immediate mode 也合理。 对 AI agent 那段很有感触。agent 容易一次性持有多个系统密钥，还可能被 prompt injection 诱导泄露，靠邮件人工处理根本追不上。短 TTL、自撤销、immediate-self-revoke 和审计事件结合起来，确实能把时间维度上的最小权限往前推一步。 一点小担心是：quarantine 的通知和误报处理要足够清楚，不然可能反复隔离正常 key；未认证撤销端点的抗滥用和运营压力也需要考虑；老 key 没有前缀和配置时怎么过渡也得有策略。整体上像 security.txt 那样渐进采用很现实，供应商先加前缀、发静态 JSON、上线撤销端点就能起步。期待草案把状态机、通知和约束字段继续写细。

热心网友3

感谢分享，ORKS 这个方向挺务实。API key 泄露后最难的就是不知道找谁、怎么快速失效，把 issuer 编码进 key 前缀，再用 well-known 暴露撤销端点、联系人和约束声明，确实能让扫描器或 agent 离线就完成第一步判断。未认证撤销加 quarantine 模式也考虑到了可用性，24 小时计时、owner 可认证加速或取消、不能通过邮件链接取消，这些设计比直接一键杀死生产密钥更稳。 AI agent 那段很有现实感，凭据倍增、prompt injection、秒级滥用窗口，单靠人工邮件撤销太慢，短 TTL、自我撤销、IP 固定和限 scope 的约束声明都会很有用。落地从加前缀、发布静态 JSON、上线撤销端点开始，不需要中心权威，这个类似 security.txt 的飞轮思路也容易理解。比较想继续看 v0.1 里 quarantine 状态机和端点 schema 的细节，尤其 24 小时默认是否可按 issuer 或风险级别调整，以及存量 key 怎么平滑过渡。整体值得关注。