FullAgenticStack WhatsApp‑first:RFC‑WF‑0020
Source: Dev.to
速率限制、滥用控制与运营安全 (RAOS)
状态: 草案标准
版本: 1.0.0
日期: 2025年11月20日
类别: 标准轨道
作者: FullAgenticStack 倡议
依赖: RFC‑WF‑0003 (CCP), RFC‑WF‑0004 (ACSM), RFC‑WF‑0007 (OoC), RFC‑WF‑0008 (RCP), RFC‑WF‑0009 (TMSI), RFC‑WF‑0010 (IDS), RFC‑WF‑0015 (PPGP)
许可证: 开放规范(公共,免版税)
摘要
本文档规定了 WhatsApp‑first 系统 的 速率限制、滥用控制与运行安全(RAOS)。RAOS 为命令执行、可观测性查询、恢复操作以及令牌/确认流程中的限流、滥用检测、安全降级和“封锁”运行模式定义了规范性要求。RAOS 在保持 WhatsApp‑first 可操作性的同时,降低垃圾信息、暴力破解、拒绝服务以及运行失控(例如重复重试或代理循环)等风险。
Index Terms— 速率限制, 滥用防护, 拒绝服务, 节流, 安全降级, 操作安全, 对话系统.
I. 引言
WhatsApp‑first 系统通过对话界面公开强大的操作功能。若缺乏明确的滥用控制,同样的便利性会成为攻击向量:命令泛滥、暴力破解确认令牌、抓取可观测性数据,或反复触发恢复操作。RAOS 标准化了一套最小控制措施,以在遭受滥用时保持系统的稳定性和可审计性,同时维持可用的对话体验。
RAOS 还涵盖了自动化和代理的运行安全:防止失控循环、无限重试以及大规模影响。
II. 范围
RAOS 指定:
- 按行为者 / 租户 / 命令类别的速率限制要求
- 滥用检测信号和升级操作
- OoC 和 RCP 的安全降级策略
- 令牌暴力破解防护
- 重试 / 重新处理的安全限制和循环防止
- 可通过 WhatsApp(管理员)控制的锁定 / 维护模式
- 滥用事件的证据 / 遥测要求
RAOS 未 规定具体的算法(令牌桶、漏桶);它定义行为约束。
III. 规范性语言
MUST、MUST NOT、SHOULD、SHOULD NOT、MAY 为规范性词汇。
IV. Definitions
- Rate Limit(速率限制): 在时间窗口内限制请求频率的规则。
- Abuse Event(滥用事件): 检测到的可疑模式(垃圾信息、暴力破解、抓取、循环)。
- Safe Degradation(安全降级): 在不破坏核心可操作性的前提下,降低系统功能/冗余度。
- Lockdown Mode(封锁模式): 一种受管控的运行模式,暂时限制高风险操作。
V. 设计目标
RAOS 必须确保:
| 目标 | 描述 |
|---|---|
| G1. 稳定性 | 防止通过对话入口导致资源耗尽。 |
| G2. 安全性 | 防止暴力破解和失控的自动化。 |
| G3. 可用性 | 优雅降级;不要不必要地硬性失败普通用户。 |
| G4. 可审计性 | 记录滥用信号和操作作为证据/遥测。 |
| G5. 治理 | 允许特权运营者通过 WhatsApp 控制模式。 |
VI. 限流模型(规范最低)
A. 必需维度
Rate limits MUST be enforceable across at least the following dimensions:
- actor(用户 / 管理员 / 代理 ID)
- tenant(
tenant_id) - command class(只读 vs. 变更 vs. 破坏性 vs. 管理员)
- endpoint type(入口、OoC 查询、RCP 操作)
B. 最小桶
Implementations MUST define separate limits for:
- Read‑only commands(OoC / 状态查询)
- State‑mutating commands(状态变更命令)
- Destructive commands (S2)(破坏性命令(S2))
- Admin high‑impact commands (S3)(管理员高影响命令(S3))
- Recovery actions (RCP)(恢复操作(RCP))
- Confirmation attempts / token submissions(确认尝试 / 令牌提交)
C. 默认原则(规范)
Destructive, admin, and recovery flows MUST have stricter limits than read‑only flows.
(破坏性、管理员以及恢复流程的限额 必须 比只读流程更严格。)
VII. 滥用检测信号(最小集合)
Systems MUST detect at least the following signals:
| Signal | Description |
|---|---|
| A1 垃圾信息入口 | 来自某个行为体的高消息速率 |
| A2 重复的授权拒绝 | 重复的范围拒绝 |
| A3 确认暴力破解 | 重复的令牌/短语失败 |
| A4 OoC 抓取 | 高频可观测性查询 |
| A5 恢复循环 | 重复的重试/重新处理且未收敛 |
| A6 代理失控 | 超出阈值的重复代理提案/行为 |
Detection MAY be threshold‑based or risk‑scored, but MUST be explainable and auditable.
VIII. 缓解措施(规范性)
在检测到滥用后,实现必须支持以下缓解措施:
A. 限流
降低违规行为者/租户的允许速率。
B. 挑战 / 提升验证
对于敏感操作,需要更早或更频繁地进行提升验证。
C. 降级
对于 OoC,在压力或可疑活动下仅提供摘要级别的细节。
D. 临时暂停(范围限定)
在可能的情况下,仅临时暂停特定行为者或能力类别(而非整个租户)。
E. 锁定模式(管理员控制)
启用一种模式,其中:
- 破坏性 / 管理员 / 恢复操作仅限于最小的操作员集合。
- 对更广泛的类别必须使用确认令牌。
- OoC 输出细节被降低。
锁定 必须 通过 WhatsApp 管理员命令(受 ACSM 提升验证约束)来启用/禁用。
IX. 确认令牌强化
A. 尝试限制
系统 必须 对以下维度的确认令牌实施尝试限制:
- actor
command_id- 时间窗口
超过限制 必须 触发缓解措施(限流或临时暂停)。
B. 令牌属性
令牌 必须 具备:
- 短期有效
- 单次使用
- 与信封绑定(
command_id+idempotency_key)
C. 边信道安全
系统 应当 避免向攻击者提供高分辨率的 oracle(例如 “令牌错误仅差 1 字符”)。响应 应当 保持通用,而证据日志则保持精确。
X. 恢复安全性与循环防止
A. 重试上限
RCP 重试 MUST 对每个命令进行上限限制(尝试计数),并 MUST 采用退避策略。
B. 循环检测
实现必须 MUST 检测非收敛的重试模式(例如,在 M 秒内超过 N 次重试),并采取缓解措施(限流、临时挂起或升级)。
C. 幂等性
恢复操作 MUST 在可能的情况下保持幂等;如果无法做到,则 MUST 通过显式确认令牌进行保护。
XI. 证据与遥测
对于每个滥用事件,系统 MUST 记录:
- Actor ID
- Tenant ID
- Timestamp(s)
- Event type (A1‑A6)
- Mitigation applied
- Relevant request/response metadata (sanitized of PII)
Telemetry SHOULD 可导出到集中审计日志(例如 SIEM),并且 MAY 通过特权 AoC 端点进行查询。
XII. 安全考虑
RAOS 本身并未引入新的密码学原语,但它依赖于底层令牌生成、传输加密(TLS)以及 WhatsApp 的端到端加密的安全性。实现者 必须 确保速率限制执行和滥用检测逻辑不能被精心构造的负载或重放攻击绕过。
XIII. IANA 考虑事项
无。
XIV. 参考文献
规范性
- RFC 2119 – 用于 RFC 中指示需求级别的关键字
- RFC‑WF‑0003 – 会话控制协议 (CCP)
- RFC‑WF‑0004 – 身份验证和凭证安全模型 (ACSM)
- RFC‑WF‑0007 – 可观测性即指令 (OoC)
- RFC‑WF‑0008 – 恢复控制协议 (RCP)
信息性
- OWASP Rate‑Limiting Cheat Sheet – 速率限制备忘单
- NIST SP 800‑63B – 数字身份指南
XI. 代理安全控制 (AIP 对齐)
- 代理 MUST 具有提案速率限制。
- 基于代理的恢复建议 MUST 设上限。
- “Agent loop detection”(代理循环检测) MUST 存在 (A6)。
代理 MUST NOT 在没有人工干预的情况下持续提出相同的失败计划;重复的提案 MUST 降级为 “suggestion‑only” 模式。
XII. 证据与遥测要求
滥用和缓解事件 MUST 记录为:
- 遥测信号(指标 / 日志 / 跟踪),以及
- 证据制品或相关的证据链接观察(如适用)。
系统至少 MUST 记录:
- 行为者 / 租户
- 触发信号(A1–A6)
- 所采取的缓解措施
- 时间窗口
- 如适用,受影响的命令
OoC SHOULD 允许特权用户以脱敏摘要形式查询最近的滥用操作。
XIII. Policy Binding (PPGP)
RAOS 限制和阈值 SHOULD 能够通过策略包 (PPGP) 进行配置,包括每租户的覆盖。
如果高影响操作缺少策略包,系统 MUST 对这些操作进行闭合失败(符合治理闭合失败原则)。
XIV. Relationship to Other RFCs
- CCP (0003): RAOS 限制确认和命令入口。
- ACSM (0004): 缓解可能需要提升步骤和范围强制。
- OoC (0007): RAOS 定义 OoC 抓取控制和安全降级。
- RCP (0008): RAOS 限制恢复循环和补偿滥用。
- TMSI (0009): RAOS 缓解 DoS/滥用威胁和令牌暴力破解。
- IDS (0010): 重放安全补充去重但不取代 RAOS。
- PPGP (0015): 用于阈值和模式的策略绑定。
XV. Security Considerations
过于严格的限制可能导致自我造成的停机;过于宽松的限制则会被滥用。实现 MUST 在稳定性和可用性之间取得平衡。锁定模式必须通过强大的管理员控制进行保护,以防止攻击者恶意“锁定”系统。
XVI. 结论
RAOS 为 WhatsApp‑first 系统标准化了运营安全层:速率限制、滥用检测、缓解策略和受管控的锁定控制。这些机制保护系统及其用户免受垃圾信息、暴力破解、抓取和失控自动化的侵害——同时保持对话的可操作性和基于证据的问责。
附加参考
- RFC‑WF‑0003,对话命令协议 (CCP)。
- RFC‑WF‑0004,管理命令安全模型 (ACSM)。
- RFC‑WF‑0007,对话可观测性 (OoC)。
- RFC‑WF‑0008,恢复与补偿协议 (RCP)。
- RFC‑WF‑0009,威胁模型与安全不变式 (TMSI)。
- RFC‑WF‑0010,幂等性与投递语义 (IDS)。
- RFC‑WF‑0015,策略包与治理配置文件 (PPGP)。
概念与技术
- 限流桶
- 滥用信号检测
- 令牌暴力破解防护
- 安全降级
- 锁定模式
- 重试上限与退避
- 恢复循环防止
- 代理失控检测
- 基于证据的滥用报告