供应商平台如何成为银行资金盗取通道？

据Reddit社区讨论，Crédit Mutuel Arkéa银行近期确认了一起不寻常的资金盗取事件：攻击者并未直接入侵银行系统，而是通过攻陷一家第三方供应商的平台，利用该供应商已有的合法凭证，授权并转移了银行资金。银行自身的系统从未被突破，供应商也拥有正当的访问权限——问题在于，这份权限被用来发起了它本不该发起的转账，而银行的控制措施全程未能拦截。

事件核心：信任边界内的盗窃

这起事件的结构性症结并非防火墙配置错误或弱密码。供应商是受信任的，其凭证是有效的。在银行所有边界控制措施看来，这不过是一个授权方在执行授权操作。盗窃完全发生在信任边界内部。这揭示了一个被广泛忽视的盲区：当第三方平台被接入支付或审批流程时，它获得的凭证在技术上距离发起转账仅有一次API调用之遥。

信任边界（Trust Boundary） 是安全架构中的核心概念，指系统或组织之间允许数据与指令自由流动的逻辑分界。边界之内，主体通常被视为已认证、可信任；边界之外则需额外验证。传统安全模型将大量精力投入边界防护（防火墙、入侵检测、VPN等），却默认边界内部的主体行为是善意的。然而，当第三方供应商被授予凭证接入支付流程时，它便处于信任边界之内，其操作不再触发边界告警。攻击者正是利用这一盲区：无需突破边界，只需借用边界内一个合法身份。这也解释了为何银行的全套边界控制措施全程未能拦截——它们监控的是“谁在门外”，而非“门内的人是否在做越界之事”。零信任架构的提出，正是为了打破这种对内网或已认证主体的默认信任。

授权模型的时间差难题

大多数授权模型在集成设置阶段就预先回答了“这个调用是否会被允许”的问题，而非在调用发生的实时瞬间进行判断。这意味着，一个被授权读取账户数据的供应商，其凭证可能同时具备发起转账的能力——是否动用这种能力，取决于集成时的静态策略，而非执行时的动态评估。对于金融服务或企业财务运营者而言，关键问题在于：当持有凭证的第三方尝试一种它从未执行过的操作类型时，你的授权模型在执行时刻究竟会做什么？不是政策编写时，而是执行时。

静态授权与动态授权的区别是理解本事件的关键。静态授权（如OAuth 2.0中的scope、RBAC角色绑定）在集成或令牌颁发时确定权限集合，之后每次调用仅做“令牌是否有效、scope是否包含该操作”的检查，而不评估上下文。动态授权（如ABAC、PBAC、持续访问评估）则在每次请求发生时结合用户身份、设备状态、行为基线、交易金额、时间地点等多维属性实时判定。静态模型的优势是低延迟、易实现，但代价是权限一旦授予便长期有效，且难以区分“从未执行过的操作”与“常规操作”。动态模型能识别异常操作类型并触发二次认证或阻断，但需要更丰富的行为基线数据和更复杂的策略引擎。本事件中，供应商凭证具备转账能力却从未执行过转账，正是静态模型无法区分的典型场景。

代理式金融工作流放大风险

代理式（Agentic）金融工作流使这一暴露面进一步扩大。在供应商平台内运行的AI代理通常继承宽泛的委托权限，而在入驻时商定的权限范围，很少能匹配任何单一操作的最小必需权限。这种权限膨胀与静态授权模型的结合，为内部信任边界内的越权操作提供了温床。

代理式工作流（Agentic Workflow） 指由具备自主决策能力的AI代理串联多个步骤、调用外部工具完成复杂任务的流程。与传统的固定脚本或规则引擎不同，代理会根据目标动态选择调用哪些API、以何种顺序执行。在金融场景中，这意味着代理可能组合读取账户、计算额度、发起支付等多种能力。问题在于，代理通常继承部署它的供应商的委托权限（delegated permissions），而入驻时商定的权限范围往往以“功能”为单位而非“最小操作”为单位，造成权限膨胀（privilege creep）。更棘手的是，代理的自主性使其可能发起人类操作者从未预料到的操作组合，而静态授权模型对此毫无防备。最小权限原则（PoLP）和即时授权（JIT）是缓解这一风险的主要方向。

多源视角与行业启示

这一事件并非孤立模式。据Reddit讨论和行业分析，每一家将外部平台连接到支付或审批工作流的金融机构都面临同样的缺口。共识在于：问题根源是授权模型的设计缺陷，而非单点安全失误。分歧则在于解决方案的优先级——部分观点主张收紧供应商准入时的权限范围，另一部分则认为需要实时行为监控与动态授权。无论哪种路径，核心教训一致：信任边界内的合法凭证，可能成为最危险的攻击载体。

对于金融科技从业者，这起事件提出了一个必须回答的问题：你的授权模型在执行时刻，如何应对持有凭证的第三方发起的全新操作类型？