手机端AI操作金融App须双重授权，智能体产品怎么合规设计？

金融智能体的权限规则已经从用户单方授权转向双重授权：既要用户同意，也要金融机构授权。这意味着凡具备读屏、模拟点击、OCR识别金融App能力的产品，都必须在设计阶段重构权限架构，而不是靠用户协议里的一句免责条款兜底。技术路线同样被改写——经机构授权通过MCP或API调用是合规路径，未经授权的界面自动化操作被明确禁止。责任划分也随之清晰：技术中立不是免责理由。

二、为什么金融场景要设双重授权

传统上，用户在自己手机上操作App属于用户自主行为，App提供方无权干涉。但第三方智能体介入后，情况发生了质变。

其一，行为性质变了。 智能体代替用户执行操作，本质上是代理行为，而不是用户亲自操作。代理就会产生授权范围与越权后果的问题。

其二，技术路径绕开了接口控制。 智能体通过无障碍服务、截屏权限获取金融App的界面数据，这条路径绕过了App提供方对接口、频率、参数的管控，金融机构对过程完全不知情，也无法在风险发生时及时干预。

其三，责任归属模糊。 一旦发生资金损失，用户、智能体提供方、金融机构三方之间的责任难以厘清，而金融机构对客户账户安全与业务合规负有法定责任，不能因为第三方介入而免除。

法理上的落点很清楚：金融业务属于特许经营领域，第三方智能体实质上是在金融机构不知情的情况下进入了其受监管的业务场景，因此必须获得机构端授权。这不是新增的行政要求，而是把既有的金融监管逻辑延伸到智能体这一新主体上。

三、标准对产品的四项具体要求

第一，初始化与输入阶段的边界声明。 智能体启动时须向用户明示可操作的金融App范围；输入阶段对用户指令做安全过滤，防止注入式攻击与诱导式操作；不得默认开启金融App操作能力，须用户主动选择并确认。

第二，推理与决策阶段的可追溯。 推理逻辑与决策路径需留存日志供事后审计；涉及转账、支付、理财购买等资金操作的决策，必须有明确风险提示与二次确认；不得自主决定超出预设范围的操作。

第三，身份鉴别与操作阶段的双重认证。 这是核心要求。手机端第三方智能体操作金融App，不仅要获得用户的系统权限授权，还必须获得金融机构授权——金融机构主动开放接口或提供MCP服务，允许智能体在授权范围内接入调用。

第四，数据安全和隐私保护。 通过麦克风、截屏、录屏、共享屏幕等权限获取的数据，须遵守被调用方的安全策略；不得将通过金融App获取的界面数据用于模型训练或其他非授权用途。这一条最容易被忽略，却是算法侧最常见的违规点——用真实金融界面数据做模型微调，等于把用户账户信息变成了训练语料。

四、没有机构授权，智能体就完全不能用了吗？

不是。合规路径是明确的，标准实际上区分了两条技术路线。

| 维度 | 路线一：接口授权调用 | 路线二：界面自动化操作 |

|---|---|---|

| 技术方式 | 金融机构提供MCP服务或开放API | 无障碍服务读屏、模拟点击、OCR识别 |

| 授权来源 | 用户授权＋机构授权 | 仅用户系统权限授权 |

| 合规状态 | 标准鼓励的路径 | 明确禁止 |

| 数据范围 | 接口约定的字段 | 界面可见的全部信息 |

| 风险特征 | 可控、可审计、可熔断 | 不可控、不可审计、责任难分 |

路线一之所以被鼓励，是因为它把权限收敛到了接口约定的字段范围内，金融机构可以限流、可以审计、可以在异常时切断。路线二之所以被禁止，不是因为技术本身有问题，而是因为它让智能体获得了远超必要范围的信息——一个查询余额的动作，可能同时读到了账户列表、交易明细、身份信息。

对于不涉及金融App操作的智能体（日程管理、文档处理、翻译等），本标准不直接适用。但产品若定位为全能助手，存在未来接入金融场景的可能，建议提前做预评估，在架构层面预留权限分级能力——事后改造的代价远高于设计时预留。

五、出了资金损失，责任怎么分？

责任划分取决于智能体的角色与控制力，可以分三种情形看。

未经机构授权、通过读屏操作的。 智能体提供方可能承担主要责任。原因在于标准已明确禁止此类操作，仍实施即构成过错，且提供方对技术路径的选择具有完全的控制力。

已获机构授权、通过接口调用但因决策错误致损的。 按合作协议的责任条款与各方过错程度分配。此时合同条款的质量直接决定责任比例，这也是为什么合作协议必须写清决策边界、二次确认机制与异常处置流程。

用户故意利用智能体实施欺诈或违规操作的。 用户本人承担相应责任，但提供方不能因此完全免责，仍须证明自身已尽到身份核验与行为监测义务。

一个值得强调的实务判断是：技术中立在这类案件中几乎没有抗辩空间。原因很简单——提供方决定了产品做什么、不做什么、默认开什么权限，这不是中立，这是选择。

六、企业的四步自查与改造

第一步，功能排查。 逐项检查产品是否具备通过读屏、模拟点击、OCR识别等方式操作金融App的能力；如有，核实是否存在对应的机构授权合作；对未经授权的功能制定调整或下线时间表。

第二步，权限分级。 把智能体可操作的应用分为已授权、待授权、未授权三级；金融类应用实施最高级别管控，除非获得机构授权否则禁止默认开启；在用户协议中明确告知可操作范围与限制。

第三步，建立机构通道。 主动对接目标金融机构，了解其MCP服务或API开放计划；在合作协议中明确数据安全、行为管控、责任划分条款；优先选择金融机构官方提供的合作方案，而不是自行设计接入方式。

第四步，行为审计与应急。 对金融场景的所有操作留存日志，包括操作时间、内容、用户确认记录；建立异常行为检测与自动熔断，操作超出预设范围时自动暂停；制定资金安全事件应急预案，明确与金融机构的协同处置流程。

七、三个常见的认知误区

1. 以为用户点了同意就万事大吉。 用户授权解决的是个人信息处理的合法性，机构授权解决的是业务准入的合法性，两者不能互相替代。
2. 以为不叫金融助手就不算金融场景。 判断标准是实际能力，不是产品命名。一个全能助手只要能读银行App界面，就在规制范围内。
3. 以为日志是负担。 日志既是合规义务，也是责任划分时唯一能自证的证据。没有日志，出了事只能各说各话，而举证不利的一方通常是产品方。

需要补充一个判断标准：日志的价值不在数量，而在能否回答三个问题——用户当时授权了什么、智能体实际做了什么、两者是否一致。三个问题都能回答，举证就是完整的；只能回答其中一个，等于没有记录。

广东华商律师事务所潘杰峰律师点评

金融智能体安全标准的发布，标志着我国AI智能体监管从原则性规范进入场景化落地阶段。双重授权规则的法理内核是：金融业务是特许经营领域，第三方智能体不能以用户授权为由绕开金融机构的合规控制。我的实务判断有三点：第一，所有开发手机端AI助手、智能体类产品的企业应立即排查金融场景功能，对未经机构授权的操作能力及时调整，否则标准落地后可能面临整改压力；第二，行业趋势已从读屏模拟转向MCP接口授权，企业应主动与金融机构建立合作通道，而不是继续依赖技术绕行；第三，智能体权限管理不能只靠用户协议约定，而要嵌入产品底层架构——权限分级、行为审计、异常熔断三道防线缺一不可。另外提醒，涉及金融场景的产品在上线前最好做一次合规留痕，把安全评估、权限设计、测试记录归档，这些材料在监管问询时会成为最直接的证明材料。以上分析基于公开标准信息与现行法，具体产品的适用判断建议结合技术方案另行评估。

FAQ

问：智能体产品只做日程管理、文档处理，是否受本标准约束？

答：本标准专门针对金融场景的智能体应用，产品不涉及金融App操作则不直接受约束。但若产品定位为全能助手、可能在未来版本中涉及金融场景，建议参照标准做预评估，并在架构中预留权限分级管理能力。判断时看实际能力而非产品名称，能读到金融App界面数据，就在规制范围内。

问：什么是MCP服务？金融机构提供后智能体怎么接入？

答：MCP是模型上下文协议，是AI智能体与外部应用系统对接的技术规范。金融机构提供MCP服务后，智能体可通过该协议在授权范围内调用接口能力，例如查询余额、发起转账等，而无需通过读屏等绕行方式操作。这是标准鼓励的合规路径，优势在于权限可约定、频次可限制、行为可审计。

问：智能体在金融场景操作导致资金损失，用户向谁索赔？

答：需按情形判断。若智能体提供方未经金融机构授权、通过读屏方式操作导致损失，用户可向提供方主张赔偿；若已获授权并通过接口调用，则按各方过错程度与合作协议分配责任；若用户故意利用智能体实施欺诈，用户本人承担责任，但提供方仍须证明已尽身份核验与行为监测义务。建议用户在使用前仔细阅读服务协议中的责任条款，并保留操作记录。