AI webhook回调安全怎么做：签名、重放保护和租户隔离别少一项

异步回调常被低估

模型生成、批量处理、文件解析和外部审计经常通过webhook异步通知结果。团队往往把重点放在发请求时的鉴权，却忽略了回调入口其实是一个新的写入面。只要验签、幂等或状态机不严，伪造结果、重复回调和串租户都可能发生。

验签只能解决一半问题

回调请求至少要验证来源签名、时间戳和请求体摘要，避免被篡改或伪造。但即使验签通过，也不能默认接受重复回调。还需要幂等键、事件ID和有限窗口，防止同一请求被重放。

尤其是在财务、审批、发货、发文这类会触发后续动作的流程里，重复回调和伪造成功状态的破坏力很大。

状态机要做闭环

回调处理不应只看事件类型，还要看当前任务状态是否允许跳转。比如一个任务还没创建完成，就不应该先收到成功结果；一个已取消的批次，不应因为晚到回调又被写回完成态。

如果系统按租户、多项目运行，还要核对回调里的租户ID、项目ID和本地记录是否一致。

和中转站的配合

https://top-api.cc 这类统一入口适合记录请求ID、任务ID、模型调用和下游工具链ID。回调侧只要把这些ID串回原始请求，就能在同一链路里排查是模型问题、工具问题还是回调入口问题。

检查清单

• 是否验证签名、时间戳和请求体摘要
• 是否拒绝超时窗口外的回调
• 是否基于事件ID做幂等处理
• 是否校验租户ID、项目ID与本地任务一致
• 是否按状态机限制可接受的状态跳转
• 是否记录回调原文、处理结果和拒绝原因

结语

Webhook不是附带功能，而是异步AI流程的入口。签名、重放保护和租户校验三件事缺任何一项，回调都不算真正可上线。