安全设计中的「故意变慢」：冷却期为何有效

一个「什么都不做」的安全功能

在银行 App 里添加一个新收款人，然后立刻转账试试。很多系统会给你一堵墙——它不是在阻止你，只是想让你慢一点。收款人能正常添加，转账却不会马上放行，要等一小时甚至更久才清算。

如果你确实是本人操作，钱只是晚到一会儿。但如果有人用你被盗的登录凭证添加了收款人，这一小时就毁掉了他转移资金的最佳窗口。

这一小时本身就是功能，而不是两端登录校验的附属品。

两个问题，两套工具

银行设计冷却期，并不是因为登录安全做得不够好。他们担心的是账号被接管——通过撞库、钓鱼或 SIM 卡劫持。这类攻击在发生的那一刻，看起来和正常的新收款人操作毫无区别：登录有效、会话真实、请求本身没有任何异常。

真正拦住欺诈的，是时间：

• 给风控后台留出跑检查的时间
• 给用户留出注意到「不记得添加过这个收款人」短信的时间
• 让转账还躺在队列里，直到有人真正去看它

大多数访问控制只问一个问题：是否授权。是就放行，否就拒绝。而冷却期引入了第三种答案，并且只针对一小部分操作：已授权，但暂时不行。

登录不会享受这种待遇，查余额也不会。它只出现在那些代价高昂、且出错后难以撤销的操作上——向从未转账过的对象汇款，就是最典型的例子。

Agent 安全已经做了什么

Agent 工具链在这方面并非原地踏步，值得实事求是地承认。

• Human-in-the-loop 门控：已是标准建议，并且落地了。OpenAI 的 Agents SDK 提供原生流程，工具调用可以在执行中途暂停，等待人工批准或拒绝，然后从暂停点继续。
• 熔断器：直接借鉴分布式系统。失败次数够多，或越过某个风险阈值，熔断器跳闸，调用被拒，直到冷却期结束。

但这些机制抓的是「看起来不对劲」的情况：置信度下降、失败计数越线、行为偏离该 Agent 的常规模式。

冷却期回答的是另一个问题

新收款人冷却期根本不在意这笔转账是否可疑。它一视同仁地延迟整个类别，无论请求多么正常、多么自信——因为已经拿到你有效登录凭证的人，在系统眼里并不异常，他们看起来就是你。

从登录流程能获取的信息来看，他们确实是你。

这就是缺口所在。熔断器和人工审批处理的是「异常信号」，而账号接管类攻击恰恰不产生异常信号。它产生的是完美合法的请求。

对开发者意味着什么

如果你在设计 Agent 的权限体系，可以问自己几个问题：

1. 哪些操作不可逆？ 发消息、转账、删除数据、调用外部 API 下单——这些是冷却期的候选对象。
2. 异常检测能覆盖这类攻击吗？ 如果攻击者持有合法凭证，行为看起来完全正常，基于异常的防护就会失效。
3. 能否引入「已授权，但延迟执行」状态？ 对高风险操作强制排队，给人工复核或用户确认留出窗口。
4. 延迟的代价是否可接受？ 冷却期会让正常用户也变慢，所以只应施加在真正昂贵、难以撤回的操作上。

安全并不总是关于「拦住谁」。有时候，它只是关于让正确的事情慢下来，让错误的事情来不及发生。