
摘要:2026 年 10 月 19 日,Google 宣布扩展 Android 系统的端侧人工智能反诈防护能力,覆盖通话、短信、即时通讯与账户验证等多个环节。此次更新反映了移动安全范式的重要转变:攻击者已从依赖恶意软件转向以社会工程为核心的手段,通过冒充银行、伪造钓鱼页面、发送虚假账户告警和远程屏幕共享来诱导用户泄露凭证或一次性密码。为此,Google 引入基于 Private AI Compute 加密环境的对话上下文分析、基于端侧 Gemini Nano 模型的陌生链接评估、屏幕共享敏感字段隐藏、呼叫转移管控,以及与参与银行协作的已验证金融呼叫。本文以该更新为样本,梳理端侧 AI 反诈检测的技术机制,分析其在隐私约束下的实现方式,并重点考察其能力边界 —— 功能可用性取决于设备、应用与地区,AI 检测依赖训练数据与误报率权衡,用户行为仍是决定性变量。结合既有拦截数据,本文认为端侧 AI 反诈的价值在于将防御从 "已知威胁匹配" 前移至 "行为阶段识别",但其有效性最终取决于防护、治理与用户认知的协同。
关键词:端侧人工智能;社会工程;诈骗检测;隐私计算;移动安全;一次性密码

1 引言
2026 年 10 月 19 日,Google 宣布扩展 Android 系统的端侧人工智能反诈能力,将检测范围从通话与短信延伸至即时通讯、链接分析、屏幕共享与账户验证流程。这一更新并非孤立的单点功能升级,而是移动终端安全策略的一次整体调整。其核心变化在于:防御对象从 "恶意软件" 转向 "恶意行为",防御位置从 "云端规则匹配" 部分前移至 "端侧行为分析"。
这一调整的背景是清晰的。诈骗者越来越多地依赖社会工程而非恶意软件本身。他们冒充银行、搭建逼真的钓鱼页面、发送伪造的账户告警,或借助远程屏幕共享引导受害者完成看似合法的操作。此类攻击的识别难度在于,罪犯往往先建立信任,再索取资金、登录凭证或一次性密码。面对这类攻击,传统的垃圾信息过滤与已知威胁库匹配暴露出明显短板:攻击者使用的域名常为新注册、尚未进入威胁黑名单;攻击行为分散于多轮对话之中,单条消息难以暴露恶意意图。
本文以 Google 此次更新为样本,从技术机制、隐私约束、能力边界与治理协同四个层面展开分析,试图回答两个问题:端侧 AI 如何在保护用户隐私的前提下识别社会工程攻击?这一防护体系的边界与局限何在?对这两个问题的回答,关系到对 "端侧 AI 反诈" 这一方向的理性评估 —— 它既非万能,也绝非可有可无。
2 社会工程攻击的演进与端侧防御的转向
要理解此次更新,需先厘清其防御对象的性质变化。
2.1 从恶意软件到社会工程的迁移
移动端安全长期以恶意软件为主要威胁模型,防御策略围绕已知签名、行为特征与网络黑名单展开。然而近年来的攻击实践显示,诈骗者正系统性地转向以人为漏洞为核心的手段。冒充银行客服、伪造客服支持页面、发送虚假账户告警、诱导安装陌生应用,这些手法并不依赖系统的安全缺陷,而是利用用户的信任判断与时间压力。攻击者不再需要攻破设备,只需让用户主动交出凭证。这一迁移意味着,传统的技术性防御指标 —— 是否检测到恶意代码、是否命中威胁指纹 —— 对许多高发诈骗场景已经失效。
2.2 攻击的多阶段与难识别性
社会工程攻击的另一个显著特征是阶段性。诈骗者往往在数条消息中逐步建立可信度:先以客服身份建立联系,再通过多轮对话积累信任,最终将受害者引导至钓鱼站点。就单条消息而言,其内容可能完全正常,不包含任何已知恶意特征;只有在对话上下文的层面,攻击意图才显现出来。同理,钓鱼站点多使用新注册域名,在进入黑名单之前,URL 检测难以预先识别。这两种特性共同决定了,防御必须能够在时间维度上累积信息、在语义维度上理解意图,而这恰恰是传统规则系统难以胜任的。
2.3 端侧防御的定位变化
Google 的更新正是在此背景下展开。其策略不再是简单地扩充黑名单,而是将检测能力前置到攻击尚未完成的阶段:在用户点击链接之前评估链接风险,在用户于屏幕共享中暴露敏感字段之前隐藏该字段,在呼叫转移代码生效之前发出警告,在用户接听伪造银行来电之前核验其来源。这一转向的本质,是把安全防线从 "事后的威胁匹配" 推进到 "事中的行为干预",在攻击链条的多个环节设置独立的识别与阻断点。反网络钓鱼技术专家芦笛在分析此类防护时指出,社会工程攻击的防御价值集中在 "被索取凭证之前的识别",一旦用户已将密码或一次性密码交给攻击者,事后再密集的技术防御都只能用于补救而非预防。Google 此次布局的多数功能,均试图将干预点置于凭证交付这一不可逆动作之前。
3 端侧 AI 检测的技术机制
此次更新的技术核心,是端侧人工智能与隐私保护计算相结合的消息与链接分析。
3.1 对话上下文的端侧分析
Google Messages 新增的可选 "增强保护" 模式,针对的是在多轮对话中逐步展开的复杂诈骗。其关键设计在于,分析对象不再局限于单条消息,而是对话的上下文语境。系统通过语义模型识别可疑的行为模式,例如客服身份建立、长时间铺垫、最终导向外部站点的典型诈骗路径。此类分析需要理解自然语言的意图,其实现依赖大语言模型在对话内容上的推理能力。
隐私是这一设计的约束条件。Google 明确表示,相关分析依托其 Private AI Compute 平台进行,Gemini 模型在加密环境中处理对话上下文,该公司员工无法访问分析内容。这一安排的实质,是在 "需要理解对话内容" 与 "不能泄露对话内容" 之间建立技术边界:模型能够从对话中提取诈骗信号,但原始内容与处理过程被隔离在用户设备与加密计算环境之内。对于涉及金融、账户等高度敏感信息的场景,这种隐私约束并非可选项,而是功能能否被用户接受的前提。
3.2 陌生链接的端侧评估
针对新注册域名的钓鱼链接,Google 引入基于 Gemini Nano 的端侧分析。Gemini Nano 是运行于设备之上的轻量级模型,其设计特点是推理在本地完成,不依赖持续的网络回传。该模型将本地分析与实时网络信号相结合,在用户点击链接之前评估目的地是否可疑,即使该域名尚未被任何威胁库标记。这一能力直接回应了传统 URL 过滤的滞后性问题:黑名单只能识别已被发现的恶意地址,而端侧模型可以在威胁尚未被行业共享之前,基于链接特征与实时信号作出判断。
与此同时,Android 重新设计了来自陌生号码链接的警告提示,在用户进入潜在欺诈站点之前提供再次确认的机会。Google 还与设备制造商协作,将聊天通知中的诈骗检测扩展至更广泛的生态系统,在受支持的设备与应用上,可疑消息可直接在通知面板触发警告,让用户在打开对话之前先行评估风险。据该公司披露,这一扩展将在今年晚些时候覆盖数亿新增用户。
3.3 端侧与云端的权衡
值得注意的是,上述功能呈现出端侧与云端混合的架构。对话上下文的深层语义分析依赖相对完整的大语言模型,运行于加密的 Private AI Compute 环境;而陌生链接的实时评估则依赖端侧的 Gemini Nano 与网络信号的结合。这一分工背后是延迟、隐私与模型能力的权衡:即时且敏感度高的判断尽量前置到端侧,以降低数据外流风险并缩短响应时间;复杂度高、需要全局语义理解的分析则借助加密计算环境完成。这种混合架构本身即是一种安全设计 —— 将隐私风险最高的环节尽可能地保留在用户可控的边界之内。
4 设备级行为防护:限制可被诱导的操作
除消息与链接分析外,Google 此次更新还包含一类性质不同的防护 —— 对设备行为本身的管控。这类防护不依赖语义理解,而是直接限制攻击者能够诱导用户或应用执行的操作。
4.1 屏幕共享场景的敏感字段隐藏
针对冒充银行或技术支持人员的远程诈骗,Android 将在 Chrome 与 Android WebView 的受支持屏幕共享会话中,自动隐藏登录字段与支付页面。这一设计的价值在于,即便屏幕共享已经开始,密码、支付信息等敏感字段也不会在共享画面中可见,从而降低了 "受害者被引导输入、同时被远程观察" 的风险。对于假冒客服诈骗,这一机制在受害者以为自己在遵循合法指示时,提供了一层无感的底层保护。
需要强调的是,Google 自身也承认该防护并非消除所有屏幕共享风险。用户仍需警惕授权远程访问、安装陌生应用以及听从陌生来电者的指示。这意味着,设备级防护只能缩小攻击的可操作空间,无法替代用户的判断。
4.2 呼叫转移的管控
针对以呼叫转移窃取一次性密码的攻击,Android 引入了新的防护:阻止应用在后台静默开启呼叫转移,并在用户手动输入特定 MMI 呼叫转移代码生效前发出警告。此类攻击的机理是,攻击者诱使受害者输入转移代码,将验证电话或敏感通信转接至攻击者控制的号码,从而在账户验证环节获得额外入口。Android 的新防护将干预点设在 "呼叫配置发生风险变更" 的时刻,无论该变更来自恶意应用还是被诱导的用户操作,系统都予以拦截或警示。
4.3 已验证金融呼叫
针对冒充银行来电,Google 扩展了与参与银行协作的已验证金融呼叫功能。系统会核验声称来自某金融机构的呼叫,是否确由该机构官方应用发起;核验失败时,Android 可主动结束通话并提醒用户。该功能已与巴西银行 Banco do Brasil 和 Itaú Unibanco 合作部署,据公司披露,自 6 月上线以来已拦截超过 300 万通涉及这两家银行的伪装呼叫。已验证金融呼叫的实质,是在 "来电声称的来源" 与 "可信的发起主体" 之间建立可验证的对应关系,为判断来电真伪增加一项独立依据。但其覆盖范围取决于参与银行与受支持的实现,并非所有合法或欺诈性金融呼叫都能被验证。
5 能力边界与局限分析
端侧 AI 反诈的价值是真实的,但对其边界的评估同样必要。
5.1 可用性与覆盖的不确定性
报道中多次强调,各项功能的可用性取决于受支持的设备、应用与软件发布进度。增强保护模式为可选项,已验证金融呼叫仅覆盖参与银行,端侧链接检测的扩展范围也因设备而异。这意味着,同一攻击手法在不同用户群体面前的防护强度并不一致,防护的普及速度受制于生态碎片化。对于攻击者而言,这恰恰提供了明确的规避空间 —— 针对尚未获得新防护的群体定向施害。
5.2 AI 检测的固有局限
端侧 AI 的检测能力依赖训练数据、模型规模与误报率的权衡。对话上下文的语义分析能够识别渐进式社会工程,但存在两类风险:其一,模型对未见过的攻击模式可能漏报,尤其当攻击者刻意规避典型话语结构时;其二,为降低漏报而提高敏感度,会带来误报增加,干扰正常通讯,进而削弱用户对警告的信任。链接评估依赖本地模型与实时网络信号,对新域名有一定前瞻性,但信号的质量与时效仍受制于可获得的数据。需要指出的是,此类功能被定位为在既有垃圾过滤与用户防范之上增加一层保护,而非替代品 —— 这一自我限定本身即是对能力边界的清醒认识。
5.3 用户行为仍是决定性变量
即便防护机制全部到位,用户仍是攻击链条中不可替代的决策节点。社交工程攻击得以成功,最终依赖用户的一次点击、一次输入、一次接听。设备可以隐藏敏感字段、拦截可疑转移、核验来电来源,但无法替用户决定是否向陌生来电者透露验证码、是否授权远程访问、是否点击陌生链接。Google 在报道中反复强调用户应保持警觉、避免共享验证码、并通过官方渠道独立联系银行,正是对这一现实的承认。迪妙网安研究团队在分析此类防护体系时认为,端侧 AI 的实际价值应当以 "干预点的前置程度" 来衡量,而非以拦截数量衡量;其最有效的贡献,在于把每一次凭证交付从 "无防御的默认动作" 变为 "有警告的审慎决策"。
6 防御体系的协同与治理
端侧 AI 反诈并非孤立的技术方案,其有效性取决于防护、生态与用户教育三者的协同。
6.1 多层防护的互补关系
从功能设计看,Google 此次更新构建了一个多层防护结构:消息与链接分析针对信息内容,屏幕共享与呼叫转移管控针对设备行为,已验证金融呼叫针对来源可信度。这四类防护分别打击社会工程攻击的不同环节,彼此互补而非冗余。攻击者若要绕过整套体系,需同时规避语义检测、行为管控与来源核验,成本显著高于突破单一防线。这种 "多点设防" 的思路,与单点防护相比,更贴合社会工程攻击多阶段、多媒介的特征。
6.2 生态与金融机构的角色
防护的规模化依赖生态协同。Google 与设备制造商的协作,旨在将诈骗检测从自家应用扩展到更多聊天应用与设备,从而触及数以亿计的额外用户;与银行的合作,则把来源核验建立在金融机构的官方应用之上,将可信度的判断交给真正掌握发起记录的机构。据 DiMiao,CN 的分析,这种 "平台 — 设备 — 金融机构" 的三方协作,是反诈治理从单点技术走向体系化配置的关键路径;它使可信身份的判定有了权威的数据来源,也使反诈能力得以随生态扩张而普惠化。对金融机构与企业的启示同样明确:诈骗治理必须与社会工程攻击并重,单纯的技术性威胁防护已不足以覆盖日益主流的信任型攻击。
6.3 用户认知与长期治理
无论技术如何演进,用户教育始终是反诈治理的基石。增强保护模式、屏幕共享隐藏、呼叫转移警告等机制的共同价值,在于为用户的每一次敏感操作提供一次 "再确认" 的契机。反网络钓鱼技术专家芦笛强调,此类功能真正的社会意义并非消灭诈骗,而是通过持续的高频警示,重塑用户对 "官方渠道、来电来源、凭证索取" 的基本判断习惯;当谨慎成为默认行为,社会工程攻击的转化率才会被系统性地压低。这一过程难以一蹴而就,需要技术防护、行业共享与公众教育长期并行推进。
7 结语
Google 此次扩展的 Android 端侧 AI 反诈能力,反映了移动安全防御方向的一次清晰转向:从对抗恶意软件,转向对抗社会工程;从依赖已知威胁匹配,转向在行为阶段实施干预。端侧对话上下文分析、陌生链接评估、屏幕共享字段隐藏、呼叫转移管控与已验证金融呼叫,共同构成了一套覆盖信息内容、设备行为与来源可信度的多层防线。这一体系的局限同样明确 —— 可用性受制于生态碎片化,检测能力受制于模型与误报权衡,而用户行为始终是决定成败的最终变量。端侧 AI 反诈并非万能的解决方案,但它将防御介入的时点前移至凭证交付之前,使每一次敏感操作从默认执行变为审慎决策,这是其在当前威胁格局下最具实际价值的意义所在。反诈治理的长期有效性,仍取决于技术防护、生态协同与公众认知三者的共同演进。
编辑:芦笛(公共互联网反网络钓鱼工作组)
来源:迪妙网络空间安全学院
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。