```
Google has begun pushing AI-powered protections to Android devices aimed at two distinct and increasingly common fraud techniques: scam messaging and call-forwarding rule hijacking. BleepingComputer reports that these features are currently rolling out to eligible devices and that all analysis runs locally — message contents and call settings are not uploaded to Google's servers.
For IT administrators managing mobile fleets, the news is welcome but incomplete. The protections are real, but heuristic, unevenly distributed, and invisible when they are missing.
What actually ships
The rollout bundles two separate defences that address different attack surfaces and should be understood separately.
Scam message detection. On eligible devices, a lightweight on-device model scans incoming messages for patterns associated with fraud — urgency cues, suspicious links, payment requests from unknown senders — and surfaces a warning before the user acts. The analysis happens locally; no message text leaves the handset.
Call-forwarding abuse alerts. Attackers who gain limited access to a victim's phone account can quietly add call-forwarding rules, diverting calls — and therefore one-time passcodes — to their own number. Android now monitors for changes to call-forwarding configuration and prompts the user to confirm that the change was intentional.
The second feature is arguably the more consequential of the pair. SIM-swap and call-forwarding abuse have become staples of account-takeover chains precisely because the victim often sees nothing. A visible prompt breaks that silence.
The honest limits
Several caveats matter more than the feature announcement itself.
- Heuristic, not deterministic. Detection is pattern-based. Google has published no false-positive or false-negative rates, so administrators cannot model these protections as a control with a known assurance level.
- The alert depends on the user. The call-forwarding prompt is a speed bump, not a wall. A distracted or confused user can dismiss it, and attackers who social-engineer victims into approving the change defeat the defence entirely.
- Language tuning progress will lag. Model-based scam detection typically performs best on the languages it was tuned on first; organisations operating outside those primary training languages should expect detection quality to trail during the tuning period. For Hong Kong environments, where message-based lures routinely arrive in Chinese alongside English, this is the single most relevant caveat to set expectations around.
- Coverage gaps. The messaging protection is scoped to supported channels; third-party messaging apps, and voice or video-based lures, fall outside its reach.
- Deployment fragmentation. Eligibility depends on device model, OEM, and Android version. Corporate fleets running older hardware or heavily customised vendor ROMs may never receive the feature — and pinned Google Play services versions enforced by mobile device management can silently block it too.
What IT admins should do
These protections supplement user verification procedures; they do not replace them. Three practical steps:
- Audit your MDM policy. Confirm that Google Play services updates are not pinned or blocked on enrolled devices. A detection feature that never reaches the handset provides no protection at all.
- Brief end users explicitly. Tell staff that scam-message warnings are advisory, not authoritative — a flagged message may be legitimate, and an unflagged one may still be fraudulent. Users should continue to verify unexpected requests through a separate channel.
- Treat call-forwarding alerts as urgent. Any prompt about call-forwarding changes should be escalated to the helpdesk if the user did not deliberately make the change. Admins should also schedule periodic verification of call-forwarding settings on corporate lines, and remind staff to report suspected scams through official channels.
The bigger picture
Google's decision to run this inference on-device is the strategically significant part of the story. Fraud detection that requires centralising message contents is a privacy non-starter in most jurisdictions; running a small model locally reconciles the two objectives. That architecture is becoming an industry default — Apple, WhatsApp, and carriers have all moved analytics toward the edge.
For now, the human verification loop remains the last line of defence. The AI just makes the first line a little wider — on the devices that actually get it.
```
Google 已開始向 Android 裝置推送 AI 驅動的防護功能，針對兩種截然不同且日益常見的詐騙手法：詐騙訊息以及來電轉接規則劫持。BleepingComputer 報道稱，該等功能現時正逐步向合資格裝置推出，所有分析均在裝置端本地進行——訊息內容及通話設定不會上傳至 Google 伺服器。
對於管理流動裝置機隊的 IT 管理員而言，此消息令人鼓舞但並不完整。防護功能確實存在，但屬啟發式（heuristic）、分佈不均，而且在缺失時難以察覺。
實際推出的內容
是次推出包含兩項獨立防禦，針對不同攻擊面，應分別理解。
詐騙訊息偵測。 在合資格裝置上，一個輕量級裝置端模型會掃描收到的訊息，尋找與詐騙相關的模式——如緊迫性提示、可疑連結、來自不明發件人的付款要求——並在用戶採取行動前顯示警告。分析在本地進行；訊息文字不會離開手機。
來電轉接濫用警示。 攻擊者若取得受害者電話帳戶的有限權限，可靜靜加入來電轉接規則，將通話——因而也包括一次性通行碼（one-time passcode）——轉移至自己的號碼。Android 現會監察來電轉接設定的變更，並提示用戶確認該變更是否為本人所為。
第二項功能可說是兩者之中影響較大的一項。SIM 卡互換（SIM-swap）及來電轉接濫用之所以成為帳戶接管鏈的慣用手法，正因受害者往往毫無察覺。一個可見的提示打破了這種沉默。
實際限制
數項注意事項比功能公告本身更為重要。
- 屬啟發式，並非確定性。 偵測以模式為基礎。Google 未有公布誤報率或漏報率，管理員無法將此等防護視為具有已知保障水平的控制措施。
- 警示效果取決於用戶。 來電轉接提示只是減速帶，並非高牆。分心或困惑的用戶可將其略過；而透過社交工程（social engineering）誘使受害者批准變更的攻擊者，則可完全繞過此防禦。
- 語言調校進度將有所落後。 基於模型的詐騙偵測通常在最初調校的語言上表現最佳；使用非主要訓練語言的機構，在調校期內應預期偵測質素有所落後。對香港環境而言，詐騙訊息往往以中文連同英文發出，這是最值得設定合理期望的一項注意事項。
- 覆蓋範圍有缺口。 訊息防護僅限於受支援的通訊渠道；第三方通訊應用程式，以及以語音或視像為形式的誘騙，均不在其涵蓋範圍之內。
- 部署碎片化。 合資格與否取決於裝置型號、OEM 及 Android 版本。使用較舊硬件或高度定製廠商 ROM 的企業機隊可能永遠收不到該功能——而由流動裝置管理（MDM）強制固定的 Google Play services 版本，亦可能無聲地將其阻截。
IT 管理員應採取的措施
此等防護是用戶查證程序的補充，並不能取而代之。三個實際步驟：
- 審核貴公司的 MDM 政策。 確認已註冊裝置上的 Google Play services 更新未有被固定版本或阻截。從未能送達手機的偵測功能，完全等同於毫無防護。
- 向最終用戶明確交代。 告知員工詐騙訊息警示僅屬建議性質，並非權威判斷——被標記的訊息可能屬真實，未被標記的亦可能仍是詐騙。用戶應繼續透過另一獨立渠道查證任何意外的請求。
- 將來電轉接警示視為緊急事項。 若用戶並非刻意作出變更，任何來電轉接變更提示均應上報至服務台（helpdesk）。管理員亦應安排定期核實公司線路的來電轉接設定，並提醒員工透過官方渠道舉報懷疑詐騙。
更宏觀的圖景
Google 決定在裝置端執行此推論，才是整件事最具策略意義的部分。需要集中處理訊息內容的詐騙偵測，在大多數司法管轄區都是私隱方面的致命傷；在本地運行小型模型則調和了兩個目標。此架構正成為業界標準做法——Apple、WhatsApp 及電信營運商均已將分析推向邊緣（edge）。
目前而言，人工查證流程依然是最後防線。AI 只是讓第一道防線略為加寬——而且僅限於真正收到該功能的裝置。