Paper deep dive
SoK: Attack and Defense Landscape of Mobile On-device AI Systems
Yujin Huang, Xin Zheng, Xingliang Yuan, Kwok-Yan Lam
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 97%
Last extracted: 7/5/2026, 8:58:00 AM
Summary
This paper provides the first comprehensive Systematization of Knowledge (SoK) regarding the security of Mobile On-device AI (MoAI) systems. It defines MoAI systems as a layered architecture consisting of an Input Interface, AI Model Artifact, Runtime Execution, and Hardware Isolation layers. The authors establish three core security pillars: User-governed Input Integrity, Device-resident Model Security, and Device-native Environment Confinement. The research categorizes the attack landscape into three threat models (Input-level, Model-level, and Execution-level) and five attack categories (Adversarial, Backdoor, Adversarial Weight, Model Stealing, and Energy-latency attacks). It also provides a defense taxonomy organized by deployment phases (Pre-deployment, Runtime, and Post-deployment) and identifies future research directions such as on-device training and agentic MoAI.
Entities (11)
Relation Signals (5)
Mobile On-device AI (MoAI) â comprises â Input Interface Layer
confidence 100% ¡ MOAI systems typically comprises the following layers. Input Interface Layer...
Mobile On-device AI (MoAI) â comprises â AI Model Artifact Layer
confidence 100% ¡ MOAI systems typically comprises the following layers... AI Model Artifact Layer...
Google Tensor â supports â Mobile On-device AI (MoAI)
confidence 100% ¡ availability of dedicated AI hardware in latest mobile devices, such as Google Tensor [6]
Adversarial Attacks â threatens â User-governed Input Integrity
confidence 90% ¡ An input-level attacker... aims to induce erroneous, targeted, or trigger-activated system behavior... [Adversarial Attacks]
Model Stealing Attacks â threatens â Device-resident Model Security
confidence 90% ¡ A confidentiality failure can expose model parameters... [Model Stealing Attacks]
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Mobile on-device AI (MoAI) systems that integrate locally deployed AI models with conventional mobile software components are emerging as a key paradigm for delivering intelligent functionality directly on end-user devices. By moving inference from remote cloud services to the local mobile environment, such systems enable privacy-preserving, low-latency, and offline-capable AI functionality, yet introduce new security risks arising from the local storage of AI models. This paper presents the first comprehensive systematization of knowledge on MoAI security, covering security pillars, attack landscape, and defense landscape of MoAI systems. We further identify unresolved gaps in current attack and defense research and point to promising directions for future research in this emerging area. Our work establishes the first systematic framework for understanding the attack and defense landscapes of MoAI systems, serving as a foundation for building secure MoAI systems and advancing research in this critical domain. Companion resources are available at this https URL.
Tags
Links
- Source: https://arxiv.org/abs/2607.00362v1
- Canonical: https://arxiv.org/abs/2607.00362v1
Trouble viewing inline? Open PDF directly â
Full Text
90,018 characters extracted from source content.
Expand or collapse full text
SoK: Attack and Defense Landscape of Mobile On-device AI Systems Yujin Huang â , Xin Zheng â , Xingliang Yuan â , Kwok-Yan Lam § â The University of Melbourne, â RMIT University, § Nanyang Technological University jinx.huang, xingliang.yuan@unimelb.edu.au, xin.zheng2@rmit.edu.au, ⥠kwokyan.lam@ntu.edu.sg AbstractâMobile on-device AI (MOAI) systems that integrate locally deployed AI models with conventional mobile software components are emerging as a key paradigm for delivering intelligent functionality directly on end-user devices. By moving inference from remote cloud services to the local mobile environment, such systems enable privacy-preserving, low- latency, and offline-capable AI functionality, yet introduce new security risks arising from the local storage of AI models. This paper presents the first comprehensive systematization of knowledge on MOAI security, covering security pillars, attack landscape, and defense landscape of MOAI systems. We further identify unresolved gaps in current attack and defense research and point to promising directions for future research in this emerging area. Our work establishes the first systematic framework for understanding the attack and defense landscapes of MOAI systems, serving as a foundation for building secure MOAI systems and advancing research in this critical domain. Companion resources are available at https://github.com/Jinxhy/Awesome-MoAI-Security. 1. Introduction Mobile on-device AI(MOAI) systems are emerging as a mainstream paradigm for delivering intelligent services directly on end-user smartphones. Modern mobile apps in- creasingly rely on this paradigm to support AI-powered features such as image inpainting [35], extractive question answering [16], and speaker diarization [18] without contin- uous cloud connectivity. As shown in Figure 1a, this trend has been accelerated by the availability of dedicated AI hard- ware in latest mobile devices, such as Google Tensor [6], Apple Neural Engine [9], and Qualcomm Hexagon [13]. More recently, Googleâs Gemma 4 family [5], particularly its E2B and E4B variants for mobile deployment, illustrates this shift as increasingly capable generative and reasoning models now target practical local deployment on end-user devices. Compared to offloading AI from mobile devices to the cloud in Figure 1b, MOAI offers several distinct advantages. These include improved privacy as sensitive data is processed locally on end-user devices, lower in- ference latency since there is no need to transmit data to remote servers, and continued functionality in scenarios where network connectivity is unavailable [28], [52], [60]. Despite the manifold benefits, MOAI system inevitably stores models on end-user devices, which introduces new security threats. As shown in Figure 1c, an attacker can fully MobileBERT 25M MobileNetV2 3.4M 201820192020202120222023202420252026 1M 10M 100M 1B (1,000 M) 10B (1,0000 M) Parameter Scale (Log Scale) Release Year EfficientNet-Lite 5.4M Gemini Nano 1.8B (Pixel 8 Pro) Phi-3 Mini 3.8B Gemma 4 E2B 2B Gemma 4 E4B 4B Capability Stage Vision Models Language Models Generative Models Reasoning Models Key Industry Milestones on Hardware Apple Neural EngineGoogle TensorQualcomm Hexagon (a) Evolution of mobile on-device AI systems. Cloud-based AI Systems Client Devices ... User Instruct Present Transmit Response High latencySerious privacy risk Cloud Mobile On-deviceAI (MOAI) Systems UserMobile Instruct Present Low latencyUser privacy preserving VS (b) Comparison between cloud-based vs. MOAI paradigms. User Input Sy stem Output Mobile AI Attack Surface §Input Manipulation §Model Tempering §Model Stealing Defense Phase §Pre-deployment §Runtime Execution §Post-deployment (c) Attack surface and defense phase in MOAI system. Figure 1: Overview of the evolution, system paradigm, and security scope of MOAI systems. extract on-device models and inference-related information through techniques such as reverse engineering or device memory dumping. This exposes multiple attack surfaces and facilitates a wide range of representative attacks, including adversarial attacks [28], backdoor attacks [36], adversar- ial weight attacks [29], model stealing attacks [52], and energy-latency attacks [55]. For instance, the attacker can reverse engineer a traffic sign recognition MOAI system to obtain the on-device model, modify it to implant back- doors, reassemble it back to the system, and trigger the backdoors by placing carefully crafted triggers on specific traffic signs, posing risks to end-user safety. In response to these threats, various defense mechanisms across different deployment phases have been proposed to protect on-device models, including model obfuscation [66], model authoriza- tion [25], model execution within trusted execution envi- ronments (TEEs) [15], and model watermarking [30]. For example, a mobile system developer can obfuscate an on- arXiv:2607.00362v1 [cs.CR] 1 Jul 2026 device model before deployment to hinder model extraction and prevent subsequent malicious exploitation. Existing literature reviews primarily focus on the secu- rity of Edge AI and TinyML systems [31], [57], and a recent survey on MOAI systems solely concentrates on model stealing [45]. The community therefore lacks a systematic view or framework for understanding the overall security risks of MOAI systems as a whole, as well as guidance on the foundational security pillars and practical security solutions for MOAI systems. This paper addresses this gap by providing the first comprehensive systematization of knowledge on the security landscape of MOAI systems. We approach MOAI security from a holistic mobile system perspective, studying how local inference reshapes the trust boundaries among user- governed inputs, device-resident model artifacts, mobile AI runtimes, and device-native execution environments. Our analysis first characterizes MOAI systems as a layered architecture and derives three security pillars that capture their core protection properties. We then systematize the attack landscape of MOAI systems through a threat model analysis, an attack taxonomy organized around MOAI threat models, and a cross-pillar analysis that reveals how the cat- egorized attacks undermine the security pillars. We further examine the defense landscape of MOAI systems via secu- rity objectives, a taxonomy of existing defense mechanisms across deployment phases, and a cross-pillar assessment of how these protections cover, trade off, and fall short across the security pillars. Through this systematization, we identify open problems across attack practicality and defense effectiveness, revealing that many MOAI attacks rely on strong deployment assumptions, whereas existing defenses remain partial and incur nontrivial security, performance, and deployability tradeoffs. Finally, we outline future di- rections for securing emerging MOAI paradigms, including on-device training, on-device GenAI, and agentic MOAI. Our contributions are summarized as follows: ⢠Security Pillars of MOAI Systems. We present a system- atic framework that characterizes MOAI system security via three security pillars, i.e., Pillar I: user-governed input integrity, Pillar I: device-resident model security, and Pil- lar I: device-native environment confinement. We further analyze how local input handoff, post-deployment model residency, and device-native execution reshape attack sur- faces and defense requirements. ⢠Comprehensive Attack Landscape and Taxonomy. We develop a systematic attack taxonomy that characterizes MOAI attacks through three threat models (i.e., input- level, model-level, and execution-level adversaries) and provide a comprehensive classification of five attack cat- egories that include adversarial attacks, backdoor attacks, adversarial weight attacks, model stealing attacks, and energy-latency attacks, revealing how user-governed in- puts, device-resident model artifacts, runtime materializa- tion, and mobile hardware heterogeneity reshape attack practicability and impact. ⢠Comprehensive Defense Landscape and Taxonomy. We develop a systematic defense taxonomy that charac- terizes MOAI defenses by deployment phase (i.e., pre- deployment, runtime execution, and post-deployment), and classify existing defenses into four categories that encompass model obfuscation, model authorization, TEE, and model watermarking, revealing how mobile deploy- ment constraints affect protection across model artifacts, authorization paths, runtime states, and ownership. ⢠Future Research Directions on MOAI Systems. We outline a forward-looking research agenda for MOAI system security, including on-device training, on-device GenAI, and agentic MOAI systems. To the best of our knowledge, this is the first work to system- atically analyze the security landscape of MOAI systems. Our systematization provides a comprehensive framework for understanding MOAI attack risks and defense strategies, guiding future research toward building secure MOAI sys- tems. This work can serve as a foundational reference for researchers and practitioners working with MOAI systems. 2. Overview Scope. We focus on security risks and defenses that are unique to, or significantly amplified in, MOAI sys- tems compared with traditional mobile software and mobile cloud-based AI systems. We first characterize MOAI sys- tems as holistic compositions of traditional mobile software components and local neural components, organized into four layers, including input interface, AI model artifact, runtime execution, and hardware isolation (§3). We then analyze MOAI-specific attacks by formalizing MOAI threat models, categorizing attacks around them, and assessing the practicality of their deployment assumptions (§4). We exclude general mobile app vulnerabilities and pure cloud- side AI attacks unless they directly interact with on-device inference. Next, we systematize MOAI defenses across three deployment phases, with attention to their security-cost tradeoffs and limitations (§5). Finally, we outlines future directions for emerging paradigms in MOAI systems (§6). Differences From Existing Surveys and SoKs. Exist- ing surveys and SoKs on Edge AI and TinyML security examine adjacent but distinct deployment settings. Wingarz et al. [57] study decentralized edge-intelligence deployments that span wearable and IoT sensors, embedded devices, and edge gateways, where AI computation is placed close to data sources rather than centralized in the cloud. Huckelberry et al. [31] focus on TinyML systems, where microcontrollers face severe memory, compute, and energy constraints to- gether with physical exposure and side-channel risks. The closest work, Nayan et al. [45], only considers on-device model confidentiality in MOAI systems, without addressing the broader end-to-end security risks introduced by MOAI system deployment. In contrast, our work provides a unified systematization of knowledge of MOAI security from the holistic mobile-system perspective, deriving security pillars, systematizing attacks across adversarial capabilities, orga- nizing defenses across deployment phases, and identifying open problems that capture how local mobile deployment reshapes MOAI attack practicality and defense robustness. 3. MOAI Systems and Security Implications 3.1. MOAI Systems In this paper, we define MOAI systems as holistic compositions of traditional mobile software components and local neural components. As shown in Figure 2, a MOAI system typically comprises the following layers. Input Interface Layer. The input interface layer defines the input boundary through which task-specific mobile data is acquired from sensors, user interactions and application contexts, and transformed into the input format required by the deployed on-device model. It consists of device inter- faces and input-handling code used before model invocation, including platform APIs such as Android CameraX [2] and iOS AVCam [1], data format adapters such as LiteRT TensorImage [14] and CoreML MLFeatureValue [8], and preprocessing routines such as image resizing and normal- ization. Across deployments, this layer reconciles heteroge- neous mobile input sources, platform-specific acquisition de- tails, and modality-specific processing choices, then exposes them as input representations that conform to the deployed modelâs input specification. Consequently, downstream lay- ers operate on structured model inputs rather than raw sensor buffers, input streams, or context dictionaries. AI Model Artifact Layer. As the core layer of a MOAI system, the AI model artifact layer encapsulates trained neu- ral models in deployable artifacts that can be stored on end- user devices, loaded by the local runtime, and invoked for inference. These artifacts encode the model structure, trained weights, neural operators, input/output tensor specifications, and auxiliary resources such as labels, vocabularies, or tok- enizers. They are typically packaged into mobile-compatible formats such as LiteRT .tflite [7], CoreML .mlmodel [3], or ExecuTorch .pte [4], often with optimizations such as quanti- zation, pruning, or clustering to meet constraints on storage, latency, and hardware compatibility. After packaging, the artifacts expose concrete inference interfaces that specify input shapes, the computation graph to execute, and output semantics, and thus constitutes the executable specification for on-device inference. Runtime Execution Layer. The runtime execution layer translates executable model specification into con- crete device-level computation under runtime, hardware, and resource constraints. It loads AI model artifacts through local runtime APIs, initializes corresponding interpreters, prepares input and output tensors, manages intermediate buffers, and dispatches neural operators to available execu- tion backends such as CPU kernels, GPU delegates, NPUs, or Neural Engine [9]. These execution decisions are gov- erned by operator compatibility, memory availability, back- end selection policies, and scheduling constraints, which determine if computation is executed directly or delegated to accelerators. Together, this runtime orchestration marks the final software-controlled stage before inference enters the hardware execution environment. Hardware Isolation Layer. Beyond runtime-managed execution, the hardware isolation layer characterizes the hardware-backed environment in which on-device inference is performed and the trust boundaries that govern access to inference code, model weights, and intermediate tensors. It distinguishes the normal execution environment from hardware-isolated execution environments, such as trusted execution environments (TEEs), TrustZone, and protected kernel-based virtual machines (pKVMs). Depending on the deployment design, inference may run entirely in the normal execution environment, be fully placed inside a hardware- isolated execution environment, or be partitioned so that only selected layers, operators, or weights are protected while the remaining computation proceeds through ordi- nary execution paths. Ultimately, such isolation mechanisms serve as the hardware-enforced safeguard that protects on- device inference against software-level compromise. Overall Workflow. Given a user input, an MOAI system first employs the input interface layer to transform it into the structured input representation required by the deployed model. The AI model artifact layer then supplies the model artifact, whose executable specification determines the input tensor schema, computation graph, and output semantics for processing this structured representation. Next, the runtime execution layer invokes the model artifact on the prepared input via available execution backends, while the hardware isolation layer governs if inference computation and state re- main in normal execution or reside within isolated execution environments. Finally, the system converts the model output according to the artifact-defined output semantics and re- turns it as a classification, generated content, or recommen- dation. For instance, in an on-device skin cancer recognition system, a user-captured skin image is transformed into an input tensor, processed by a local vision model, and returned as a melanoma prediction with a dermatology referral. MOAI Systems vs. Mobile Cloud-based AI Systems. While MOAI and mobile cloud-based AI systems provide similar user-visible AI functionality, their key distinction lies in where the inference pipeline is executed. In cloud- based AI systems, the mobile client primarily serves as the entry point to remote inference by acquiring task-specific data, constructing an inference request, and presenting the returned inference result. The cloud backend hosts the model artifact, executes inference, maintains intermediate inference state, and provides the required hardware resources. In contrast, MOAI systems move the inference pipeline onto end-user devices, where structured inputs, deployed model artifacts, runtime execution, and hardware isolation are com- posed within the local mobile stack. This shift improves user privacy, inference latency, and offline availability, but also introduces new attack surfaces as models are stored locally. 3.2. Security Pillars of MOAI Systems Pillar I: User-governed Input Integrity. This pillar characterizes the integrity of user-governed input consumed by MOAI systems. Here, user-governed input denotes the distinctive property of MOAI systems that users ordinar- ily control input acquisition before inference. Its integrity hinges on the trustworthiness of acquired input and the â˘selected layers â˘operators, â˘orweights Protection AI Model Artifact Layer 2 Deployable Model Artifact â˘model structure â˘weights â˘operators â˘I/O specs â˘auxiliary resources Executable Specification Input Tensor Specification Computational Graph Output Semantics Packaging & Optimization â˘quantization â˘pruning â˘clustering .tflite.mlmodel.pte f Runtime Execution Layer 3 Runtime APIs load artifact CPU GPU NPUNeural Engine Interpreter â˘prepares I/O tensors â˘manages buffers â˘dispatch Execution Decisions â˘compatibility â˘memory â˘policies â˘scheduling Hardware Isolation Layer 4 Hardware-enforced Isolation TEE / secure enclave / pKVM Normal Execution standard OS environment Inference Process Full or Full Partial Partial and â˘selected layers â˘operators, â˘orweights Protection SystemOutput Image Classification Audio Classification Generated Text Content Recommendation User Input Image Audio Text Metadata Input Interface Layer 1 Raw Mobile Data User Input (camera, mic, etc.) Sensors (location, time, etc.) App Context Platform APIs Android (CameraX) IOS (AVCam) Data Format Adapters (TensorImage, MLFeatureValue, etc) Preprocessing Routines (resize, normalize, etc.) Figure 2: Overview of a MOAI system. continuity from user-governed acquisition to model con- sumption. A failure in either of these can make the system treat adversarial, unintended, or altered data as legitimate input, leading to unsafe behavior. Preserving this integrity requires treating it as an end-to-end security property from user-governed acquisition to model-input handoff, so that data compromised at acquisition, unintentionally captured, or altered before inference cannot drive system behavior. Pillar I: Device-resident Model Security. This pillar characterizes the security of device-resident model artifacts in MOAI systems. Such proprietary artifacts are shipped to end-user devices for local execution, moving them outside the developer-controlled boundary. This shift recasts model security as a post-deployment concern in which confiden- tiality shields deployed artifacts from unauthorized disclo- sure or extraction, and integrity safeguards them against malicious modification or replacement. A confidentiality failure can expose model parameters and structures for unauthorized reuse, while an integrity failure can cause local inference to execute over attacker-modified model artifacts. Securing device-resident models requires protection to en- compass both the shipped artifacts and all post-deployment forms in which the models are stored, loaded, transformed, or materialized on devices. Pillar I: Device-native Environment Confinement. This pillar characterizes the confinement provided by the device-native environment in MOAI systems. The device- native environment encompasses the on-device software and hardware stack that mediates MOAI inference, from the mobile OS and AI runtime to the memory subsystem and TEEs. Its confinement captures the separation of MOAI computation and sensitive runtime states from unintended observation and interference across the device stack, de- spite co-residence with untrusted system components and shared hardware backends. When confinement fails, de- crypted model buffers, runtime-resident inference states, and hardware-delegated memory regions may become visible and alterable to untrusted local components, rather than remain within the intended inference pipeline. Effective con- finement requires pipeline-level isolation, where on-device models remain protected throughout the OS, AI runtime, memory, and hardware stages that support inference. 4. Attack Landscape of MOAI Systems In this section, we systematize the attack landscape of MOAI systems by defining threat models grounded in on- device adversary capabilities (§4.1), developing a MOAI- specific taxonomy for existing attacks (§4.2), and examining how these attacks and their corresponding open problems map to the three MOAI security pillars (§4.3). Table 1 presents the attack taxonomy. 4.1. Threat Models Given that MOAI systems execute inference across user- governed inputs, device-resident model artifacts, and device- native execution environments, attackers and targeted assets vary across different scenarios. We identify three adversary types categorized by the attackerâs capabilities and points of adversarial manipulation in the on-device inference pipeline. Input-level Adversary. An input-level attacker is as- sumed to control the data supplied to an MOAI system at inference time, while leaving the deployed model artifact and device-native execution environment unchanged [21], [28], [36]. The attacker aims to induce erroneous, targeted, or trigger-activated system behavior using inputs that appear benign or otherwise consistent with the intended task. The attacker may possess task-level knowledge of the target system, such as input modality, task domain, and output semantics, and in stronger settings, model-level knowledge TABLE 1: Attack taxonomy for MOAI systems. P Attack CategoryĂş Sub-category[ Representative WorksĂŽ Threat Model Adversarial Attacks Model Similarity Exploitation Huang et al. [28], Smart App Attack [27], Deng et al. [21], Cao et al. [19], Hu et al. [24] Input-level Model-level Gradient Reconstruction REOM [67], TIM [58] Input-level Model-level Preprocessing ManipulationSang et al. [47]Input-level Backdoor Attacks Payload InjectionDeepPayload [36], MalModel [26] Input-level Model-level Model QuantizationMa et al. [41] Input-level Model-level Image SteganographyBARWM [56] Input-level Model-level Adversarial Weight AttacksParameter TamperingTYPHON [29]Model-level Model Stealing Attacks Static Analysis Xu et al. [60], Hu et al. [24], ModelXRay [52], REDLC [34] Model-level Dynamic Analysis ModelXtractor [52]; AdvDroid [21]; DeMistify [46]; ArrowMatch [53] Execution-level Side ChannelLiu and Wang [37]; DeepCache [39]Execution-level Energy-latency Attacks-Wang et al. [55] Input-level Model-level like trained weights and deployed model structure. Suc- cessful attacks can shift classification, generation, or rec- ommendation toward attacker-specified outcomes, creating user-facing safety and reliability failures without disrupting normal MOAI operation. Model-level Adversary. A model-level attacker is as- sumed to access the model artifact that an MOAI system stores, loads, or consumes on an end-user device, without relying on control over the inference-time input [29], [52], [60]. The attacker seeks to steal or compromise the deployed model by recovering its parameters and structure for unau- thorized reuse or by altering its weights or computation graph to encode attacker-desired behavior. Depending on the setting, the attacker may know regularities in mobile AI deployment, such as recognizable model file formats, framework APIs, operator sets, and model-loading inter- faces. Successful attacks can turn the deployed model into an extractable asset that can be copied and reused across various systems, or a compromised artifact that persistently steers local inference under benign inputs. Execution-level Adversary. An execution-level attacker is assumed to observe or interfere with the device-native execution process that loads model artifacts, initializes runtime states, and invokes MOAI inference [46], [52], [62]. The attacker intends to recover private inference data, confidential intermediate states, or protected models from runtime leakage exposed through memory materialization, partitioned execution, or side-channel observables. Such re- covery may rely on knowledge of execution-time state tran- sitions, including model loading, memory allocation, TEE partitioning, accelerator offloading, and ciphertext observ- ables. Successful attacks can cause local execution to expose runtime state that should remain confined, compromising user privacy and model confidentiality without relying on malicious inputs or modified model artifacts. Practicality of Adversary Assumptions. These threat models differ not only in attacker capability, but also in deployment practicality. Input-level adversaries assume control over inference-time inputs, which is a strong and less practical assumption in MOAI systems as inputs are normally governed by end users. Model-level adversaries are often more practical because MOAI systemsâ model artifacts are shipped to end-user devices and can be an- alyzed, extracted, or modified from an attacker-controlled installation. Execution-level adversaries depend on where execution is observed. They are practical when attackers run MOAI systems on their own instrumented devices, but become stronger when targeting another userâs live execu- tion or hardware isolation. This distinction separates attacks enabled by ordinary post-deployment exposure from attacks that require control over victim-side inputs. 4.2. Attack Taxonomy for MOAI Systems As MOAI systems directly run models on end-user devices, it introduces distinct attack surfaces across input, model, runtime, and hardware layers. Based on the afore- mentioned threat models (§4.1), we systematically examine existing MOAI attacks and categorize them into five types: adversarial attacks, backdoor attacks, adversarial weight at- tacks, model stealing attacks, and energy-latency attacks. 4.2.1. Adversarial Attacks. Current studies on adversarial attacks against MOAI systems primarily concentrate on how attackers leverage on-device model accessibility to craft adversarial examples that induce incorrect model outputs. Based on the attack mechanisms, we categorize existing on- device adversarial attacks into three classes: model similarity attacks, gradient reconstruction attacks, and preprocessing manipulation attacks. Model Similarity Exploitation. This class of attack ex- ploits the widespread reuse of AI models in mobile apps and constructs adversarial examples using surrogate models sim- ilar to target models. Early work [28] introduced a pretrained model-based adversarial attack that compromises on-device models deployed in Android apps through identification of their highly similar pretrained models from TensorFlow Hub based on structure and parametric similarity. Following this, Huang et al. [27] proposed Smart App Attack, a gray-box adversarial attack framework to hack on-device models by constructing highly similar binary adversarial models based on identified transfer learning approaches and pre-trained models, which successfully attacks 38 out of 53 real-world Android AI apps adopting transfer learning. Subsequent studies breach the on-device model integrity under more constrained attacker capabilities. Deng et al. [21] developed a semantic-based black-box adversarial attack that constructs substitute training datasets from Android AI app behavior to train surrogate models, enabling effective transfer-based adversarial example generation on on-device models. Similarly, Cao et al. [19] proposed a practical black- box adversarial attack that instruments Android AI apps to collect queryâresponse pairs, uses them to train substitute models, and transfers adversarial examples generated on the substitute ones to successfully fool original models. In contrast to prior analyses of on-device models in Android ecosystems, Hu et al. [24] pioneered a security analysis of CoreML-based on-device models deployed in iOS AI apps by leveraging companion Android apps as attack surrogates to mount adversarial attacks, revealing practical attack surfaces introduced by cross-platform on- device model deployment. Gradient Reconstruction. Since on-device models are inference-only with backpropagation disabled, performing white-box adversarial attacks that outperform similarity- based gray-box or black-box attacks is challenging. Mo- tivated by this, Zhou et al. [67] proposed REOM, an au- tomated reverse-engineering framework that lifts inference- only constraints of on-device models by converting them back to backpropagation-supported versions via Open Neu- ral Network Exchange [12] interoperability, enabling ef- fective gradient-based white-box adversarial attacks. Along this direction, Wu et al. [58] proposed TIM, an au- tomated white-box testing framework that reconstructs runnable IO processing code via precise Android static slicing and rebuilds inference-only on-device models into backpropagation-enabled counterparts by recovering com- putation graphs, stripped operator attributes, and parameter values for gradient-based adversarial attacks of MOAI apps. Preprocessing Manipulation. Unlike the two aforemen- tioned attacks, this class of attack targets the model prepro- cessing procedure from the model deployment perspective. Sang et al. [47] first introduced a data processing-based at- tack that injects malicious code snippets (e.g., manipulating image resizing, rotation, or RGB normalization) into the input preprocessing pipeline of real-world Android AI apps through repackaging, which affects model performance and inference latency without modifying on-device models. Open Problem 1: The deployment of adversarial attacks against on-device models in MOAI systems is non-trivial, as it necessitates input manipulation to apply adversarial perturbations or app repackaging to insert malicious code, which are impracticable and detectable once MOAI systems are deployed on end-user devices. 4.2.2. Backdoor Attacks. Recent research has also ex- plored implanting backdoors into on-device models in MOAI systems, where attackers cause the models to exhibit predetermined malicious behaviors when processing inputs stamped with specific triggers. According to the attack lo- cus, we categorize existing on-device backdoor attacks into three classes: payload injection attacks, model quantization attacks, and image steganography attacks. Payload Injection. The core of these attacks lies in embedding backdoors into on-device models through data- flow graph modification, which mainly adds additional neu- ral conditional branches into models as malicious payloads. Li et al. [36] introduced DeepPayload, the first payload injectionâbased backdoor attack, which disassembles an on- device model into a data-flow graph, adds a trigger detecting branch via graph manipulation, and recompiles the modi- fied graph into a malicious model for backdoor activation. Building on this work, Hua et al. [26] proposed MalModel, which stealthily embeds malicious payloads within model parameters to produce malware Android AI apps. Model Quantization. Quantization optimizes on-device models for efficient execution on resource-constrained mo- bile devices, yet creates opportunities for attackers to mount backdoor attacks. Ma et al. [41] first explored quantization vulnerabilities in on-device models and proposed a post- training quantization backdoor attack that exploits truncation errors in int-8 weights during standard on-device quantiza- tion, awakening dormant backdoors in low-precision models while remaining undetectable in the full-precision ones. Image Steganography. Another line of work investi- gates backdoor injection in on-device models without modi- fying the model structure to improve attack stealthiness. Wei et al. [56] presented BARWM, a stealthy backdoor attack against on-device models that utilizes image steganography to generate imperceptible and sample-specific triggers, then associates them with the models through backpropagation- supported model reconstruction and parameter reoptimiza- tion for backdoor injection. Open Problem 2: Current backdoor attacks against on- device models in MOAI systems must seek alternative entry points beyond standard training-phase insertion due to the read-only and inference-only nature of on-device models, which largely limits the development of stealthy attacks without causing observable changes. 4.2.3. Adversarial Weight Attacks. A more recent line of work has examined weight-level model tampering, where attackers directly modify the parameters of on-device mod- els in MOAI systems to induce incorrect or attacker-desired outputs. Unlike adversarial backdoor attacks that rely on input manipulation, adversarial weight attacks compromise model behavior through parameter-level perturbation while preserving benign model utility. As this attack category has only recently emerged, we do not categorize it and instead discuss the existing work. Huang et al. [29] proposed TYPHON, the first practi- cal adversarial weight attack against on-device models in MOAI systems. It circumvents the read-only and inference- only constraints of mobile AI frameworks by reconstruct- ing writable model counterparts and computing malicious weights in a training-free manner. By rewriting selected weights, TYPHON can induce performance degradation or backdoor effects without sacrificing utility on benign inputs. Open Problem 3: While adversarial weight attacks re- veal a new parameter-level integrity failure in MOAI systems, their deployment remains constrained by precise weight localization, as behavior-critical weights must be identified in a large and highly coupled parameter space without gradient guidance and under utility constraints. 4.2.4. Model Stealing Attacks. Beyond the aforementioned integrity-oriented attacks, model stealing attacks have re- ceived extensive attention as the local storage of on-device models naturally enables attackers to disassemble MOAI systems to obtain the models for intellectual property theft or downstream misuse. On the basis of extraction strategies, we categorize on-device model stealing attacks into three classes: static analysis attacks, dynamic analysis attacks, and side-channel attacks. Static Analysis. This type of attack locates and extracts an on-device model via reverse engineering of MOAI sys- tems, combined with file scanning based on model naming schemes. Xu et al. [60] first demonstrated the feasibility of stealing plaintext on-device models using Model Extractor, which scans the assets directory of decompiled mobile AI apps and identifies model files according to AI framework- specific suffixes, such as .tflite for LiteRT and .pb for TensorFlow. Similarly, Hu et al. [24] leveraged Core ML model file suffixes (e.g., .proto and .mlmodel) to extract on-device models from iOS AI apps. Meanwhile, Sun et al. [52] designed ModelXRay to more precisely identify and extract on-device models by leveraging model suffix and AI frameworkârelated magic words, such as LSTM, CNN, and RNN. From a compiler-binary perspective, Li et al. [34] proposed REDLC, a learning-driven reverse engineering pipeline that analyzes TVM-compiled executables, recovers model computation graphs, infers operator types and at- tributes from disassembled code, and regenerates retrainable on-device models from compiled binaries. Dynamic Analysis. Certain on-device models employ encryption to thwart static analysis attacks, but their runtime model decryption for inference in mobile AI apps exposes them to dynamic analysis attacks. Sun et al. [52] developed ModelXtractor that uses app instrumentation to dynamically locate memory buffers where decrypted on-device models are loaded and accessed by the corresponding AI frame- works, followed by in-memory model extraction. Following this, Deng et al. [21] proposed AdvDroid, which hooks model-loading code, dynamically executes a mobile AI app to trigger model inference, and dumps models from memory after loading. Ren et al. [46] further advanced this dynamic analysis paradigm with DeMistify, an automated tool that combines static program slicing with runtime instrumenta- tion to systematically identify, extract, and reuse on-device models and services from mobile AI apps at scale. Re- cently, Wang et al. [53] proposed ArrowMatch, which breaks lightweight weight obfuscation in TEE-shielded LLM par- tition schemes by matching direction distances between obfuscated offloaded weights and public pre-trained weights, thereby recovering private model weights. Side Channel. Complementing the instrumentation- based attacks, Liu and Wang [37] introduced a power side- channel based model extraction attack that profiles open- source on-device models with a power monitor, trains a model architecture predictor from collected power traces, and uses runtime traces of victim inference to infer the model architecture without injecting malicious code into the target device. At the cache level, Liu et al. [39] proposed DeepCache, a cache side-channel based model extraction at- tack, which exploits cache-aware optimizations in compiler- generated model executables, collects Prime+Probe traces during inference, and infers operator types, hyperparameters, and optimized weights for model architecture stealing. Open Problem 4: Despite local model storage in MOAI systems on end-user devices, model stealing attacks re- main far from trivial, because developers may employ customized encryption algorithms and AI frameworks, which substantially complicate reliable model identifica- tion, decryption, and extraction in practice. 4.2.5. Energy-latency Attacks. In addition to compromis- ing model integrity or confidentiality, existing research has also studied energy-latency attacks against on-device mod- els, which aim to increase energy consumption and inference latency during MOAI system execution. Different from the aforementioned attacks targeting prediction integrity and model confidentiality, this type of attack focuses on model availability under resource-constrained mobile deployment. Since such attacks remain largely underexplored in the MOAI system, we discuss it separately rather than cate- gorize it into a standalone taxonomy class. Wang et al. [55] first adapted sponge poisoning to on- device models by poisoning training examples to increase activation density and weaken sparsity-based acceleration. Their on-device attack pipeline deploys poisoned models on mobile processors and simulates continuous inference over streaming inputs, showing that sponge poisoning can increase energy consumption and inference latency without sacrificing prediction accuracy. Open Problem 5: The practicality of energy-latency attacks in MOAI systems is constrained by mobile hard- ware heterogeneity, as poisoned activation patterns may amplify energy consumption and latency on sparsity- Mitigated Attacks: Backdoor + Adversarial Weight + Model Stealing Attacks User-governed Input Integrity Protect what the model sees. User ControlHandoff to Model PILLAR IPILLAR I Protect the model itself. Device-resident Model Security In-memory Execution On-device ModelMobile OSTEE PILLAR I Protect where the model runs. Device-native Environment Confinement Hardware Adversarial Attacks §Model Similarity Exploitation(P I) §Gradient Reconstruction (P I + P I) §Preprocessing Manipulation(P I) Backdoor Attacks §Payload Injection(P I + P I) §Model Quantization(P I + P I) §Image Steganography(P I + P I) Model Stealing Attacks §Static Analysis(P I) §Dynamic Analysis(P I + P I) §Side Channel(P I + P I) Adversarial Weight Attack (P I) Energy-latency Attacks (P I + P I + P I) Attack Categories Model Obfuscation §Software-level Concealment (P I) §Hardware-level Concealment (P I + P I) Trusted Execution Environment (TEE) §Monolithic Execution(P I + P I) §Partitioned Execution(P I + P I) §Obfuscated Offloading(P I + P I) Defense Categories Model Watermarking (P I) Model Authorization (P I) Mitigated Attacks: Adversarial + Model Stealing Attacks Mitigated Attacks: Model Stealing Attacks Mitigated Attacks: Model Stealing Attacks Defense OPs OP 1: Attack Deployment Practicality (P I) OP 2: Stealthy Model Modification(P I) OP 3: Precise Weight Localization(P I) OP 4: Reliable Model Extraction(P I) OP 5: Hardware Heterogeneity(P I + P I + P I) OP 6: Executable Equivalence(P I + P I) Open Problems OP 7: Client-side Enforcement(P I) OP 9: Watermark Robustness(P I) OP 8: TEE Deployment Feasibility(P I) Attack OPs Figure 3: Cross-pillar security analysis of attacks, defenses, and open problems in MOAI systems. sensitive accelerators but remain ineffective on those lacking sparsity-dependent execution behavior. 4.3. Cross-pillar Analysis of MOAI Attacks Figure 3 (the upper half) illustrates how the attack cate- gories in §4.2 and their corresponding open problems (OP1- OP5) map to the three security pillars of MOAI systems. Understanding these connections reveals that the security of MOAI systems cannot rest on isolated safeguards for user- governed inputs, device-resident model artifacts, or device- native execution environments. The mapping further shows that the identified OPs are shaped by deployment conditions that span pillars, since practical exploitation depends on coupled assumptions about input access, model exposure, and execution behavior. Security Pillars to MOAI Attacks. The attack mapping reveals a security asymmetry in MOAI systems, with Pillar I recurring as the central model-security concern, Pillar I remaining prominent in attacks that manipulate what the model consumes, and Pillar I surfacing only when attacks depend on hardware-mediated behavior. Adversarial attacks primarily stress Pillar I as they manipulate the data presented to local inference, yet on-device model accessibility brings Pillar I into the attack path when surrogate models, recon- structed gradients, or deployment-specific preprocessing are used to strengthen the attacks. The key deployment chal- lenge for such attacks captured by OP1 lies in delivering ef- fective perturbations to model inputs through user-governed input paths. Backdoor attacks couple Pillars I and I because trigger-stamped inputs only become harmful when the on- device model encodes the corresponding malicious behavior. OP2 therefore pinpoints the stealth problem in backdoor realization, where hidden malicious behavior needs to be introduced without causing observable changes to deployed model artifacts. Adversarial weight attacks concentrate on Pillar I since they directly perturb deployed model pa- rameters to alter inference behavior on targeted inputs. At this parameter granularity, OP3 centers on precision rather than access, as practical tampering depends on identifying behavior-critical weights in a large parameter search space while preserving benign utility. Model stealing attacks shift from corrupting inference behavior to recovering the model artifacts protected by Pillar I, and extend to Pillar I when the recoverable forms of the model appear only after runtime loading, decryption, or exe- cution. Here, OP4 separates model reachability from model recoverability, since local storage of on-device models does not ensure reconstruction of a complete, reusable model ar- tifact in the presence of customized encryption schemes and nonstandard AI framework implementations. Energy-latency attacks span Pillars I-I because availability degradation does not arise from inputs or models alone, but from their interaction with device-native scheduling, acceleration, and resource behavior. Given this dependence on device-native execution, OP5 captures the hardware-heterogeneity bottle- neck, since the same cost-inflating behavior may not transfer across mobile stacks with different runtimes, accelerators, and resource-management policies. Takeaway. At the system level, MOAI attack practi- cality turns on end-to-end deployment feasibility, governed by whether attackers can achieve input delivery, artifact modification, model recovery, or resource-cost amplifica- tion in the target mobile stack. Such requirements arise because deployed MOAI inference is not merely a direct model invocation. User inputs are acquired through user- governed interfaces and transformed before model consump- tion, model artifacts are packaged, optimized, or encrypted before release, runtime states are materialized during loading and execution, and computation is scheduled across het- erogeneous backends. This deployment pipeline means that local model exposure does not directly translate into system- level exploitability, since access to on-device models does not ensure control over user-governed input paths, stealthy or precise artifact changes, complete model recovery, or predictable resource effects. OP1-OP5 therefore characterize the practical gap between attacks enabled by local model access and attacks that remain feasible across the deployed MOAI inference pipeline. 5. Defense Landscape of MOAI Systems In this section, we systematize the defense landscape of MOAI systems by defining security objectives (§5.1), developing a MOAI-specific taxonomy for existing defenses across three deployment phases (§5.2), and examining how these defenses and their corresponding open problems map to the three MOAI security pillars (§5.3). Table 2 presents the defense taxonomy. 5.1. Security Objectives In this section, we define the security objectives for MOAI systems. Such objectives are grounded in the stan- dard Confidentiality, Integrity, and Availability (CIA) triad. In addition, we introduce Post-deployment Accountability as an additional objective for capturing security requirements that arise after on-device models are released into uncon- trolled deployment environments. Confidentiality. Confidentiality ensures that device- resident model artifacts and inference-related information in MOAI systems are protected from unauthorized disclosure. This protection covers model structures, trained parameters, computation graphs, operator types and attributes, input/out- put specifications, and runtime inference states. This ob- jective primarily addresses model stealing attacks (§4.2.4), where adversaries extract on-device models through static analysis, dynamic analysis, or side-channel leakage, and further constrains downstream attacks that rely on access to model internals, including adversarial, backdoor, and adversarial weight attacks (§4.2.1,§4.2.2,§4.2.3). Integrity. Integrity ensures that the inputs, model ar- tifacts, and execution semantics of MOAI systems remain resistant to unauthorized modification. It includes preventing tampering with user-governed inputs, model preprocessing routines, model parameters, computation graphs, and infer- ence outputs. This objective addresses adversarial attacks (§4.2.1), backdoor attacks (§4.2.2), and adversarial weight attacks (§4.2.3), where adversaries compromise local in- ference through malicious input perturbation, preprocess- ing manipulation, structural payload injection, quantization- induced model modification, or parameter-level tampering. Availability. Availability ensures that on-device in- ference in MOAI systems is protected from adversarial degradation under resource-constrained mobile deployment. This includes preserving acceptable inference latency, en- ergy consumption, memory footprint, and execution sta- bility across heterogeneous mobile runtimes and hardware backends. This objective addresses energy-latency attacks (§4.2.5), where adversaries degrade inference quality by increasing computation cost or weakening hardware accel- eration without necessarily affecting prediction accuracy. Post-deployment Accountability. As mentioned in §3, on-device models are unique and essential to MOAI sys- tems because local inference requires these models to re- side within the end-user mobile devices. This deployment paradigm recasts model ownership as a post-deployment security concern, since on-device models may be extracted and reused after preventive protections fail. Therefore, we introduce post-deployment accountability as a complemen- tary security objective for MOAI systems. It ensures that the ownership of on-device models can be verified after suspected extraction or unauthorized reuse, providing the security basis for watermark-based ownership verification in the post-compromise phase. 5.2. Defense Taxonomy for MOAI Systems To mitigate the aforementioned attacks, various defense mechanisms have been proposed across different phases of the MOAI system deployment lifecycle, including pre- deployment, runtime execution, and post-deployment, as illustrated in Figure 1c. In this section, we systematically examine MOAI defenses that realize across these deploy- ment phases and categorize existing defense mechanisms into three types: model obfuscation, model authorization, TEE, and model watermarking. 5.2.1. Model Obfuscation. Existing work on model obfus- cation for MOAI systems focuses on concealing on-device model structures, parameters, or execution dependencies to hinder model localization, white-box inspection, extraction, and unauthorized reuse after deployment. Based on the protection mechanisms, we categorize existing on-device model obfuscation defenses into two classes: software-level concealment and hardware-level concealment. Software-level Concealment. This class of defenses safeguards the binary representation of on-device models by obscuring the model during conversion, so as to restrict adversarial access to model structure and parameter infor- mation. Zhou et al. [66] first proposed ModelObfuscator, a prototype tool that obfuscates on-device modelsâ structures and parameters through renaming, parameter encapsulation, neural structure obfuscation, shortcut injection, and extra layer injection to hinder static analysis and white-box ad- versarial attacks. Later, Zhou et al. [64] revealed that Mode- lObfuscator remains vulnerable to dynamic instrumentation and proposed DynaMO, which obfuscates on-device models by randomly coupling DL operators and applying linear weight transformations such that correct model information emerges only during paired execution. To further obscure explicit model representations, Zhou et al. [65] proposed CustomDLCoder, which replaces standard on-device model files with generated C/C++ implementations, thereby con- cealing model structures and parameters within native code to impede direct model localization and extraction. TABLE 2: Defense taxonomy for MOAI systems. ĂŠ Defense CategoryĂş Sub-category[ Representative WorksĂŽ Mitigated Attacks Model Obfuscation Software-level Concealment ModelObfuscator [66], DynaMO [64], CustomDLCoder [65] §4.2.1 Adversarial Attacks §4.2.4 Model Stealing Attacks Hardware-level Concealment NNSplitter [68], Mohseni et al. [43] §4.2.4 Model Stealing Attacks Model Authorization-MMGuard [25] §4.2.2 Backdoor Attacks §4.2.3 Adversarial Weight Attacks §4.2.4 Model Stealing Attacks Trusted Execution Environment (TEE) Monolithic Execution Offline Model Guard [15], GuardiaNN [20], Hu et al. [23], T-Slices [32], LEAP [48], ASGARD [44], TZ-LLM [54], FlexServe [59] §4.2.4 Model Stealing Attacks Partitioned Execution DarkneTZ [42], HybridTEE [22], SecDeep [38], ShadowNet [51], MirrorNet [40], TSQP [50], TEESlice [33], TensorShield [49] §4.2.4 Model Stealing Attacks Obfuscated Offloading GroupCover [61], ARROWCLOAK [53], ConvShatter [63] §4.2.4 Model Stealing Attacks Model Watermarking-THEMIS [30]§4.2.4 Model Stealing Attacks Hardware-level Concealment. Other studies safeguard on-device models at the hardware level by embedding access control and failure-inducing mechanisms into the model execution substrate, preventing unauthorized use even when models are exposed. Zhou et al. [68] proposed NNSplitter, which splits an on-device model into an exposed obfuscated submodel and a compact set of model secrets stored in trusted hardware. The exposed submodel alone produces degraded predictions, while authorized execution restores the original functionality by combining it with the protected secrets. Subsequently, Mohseni et al. [43] introduced a majority-logic-based method that obfuscates on-device mod- els by transforming first-layer filters into a minority-derived weight configuration through hardware logic, thereby induc- ing unauthorized-use failure. Security-cost Trade-off: Model obfuscation improves confidentiality with generally modest latency cost, but its overhead shifts to memory, package size, native-code deployment, or hardware integration. For software-level concealment, ModelObfuscator [66] lowers structural similarity to 0.67 with only an approximate 1% latency overhead, but adds approximately 20% RAM overhead and 3.2â59.8 MB package growth, DynaMO [64] re- duces weight extraction from 98.76% to 52.52%, but adds 28.1% RAM overhead, and CustomDLCoder [65] removes explicit model artifacts to hinder model file parsing, but requires generated native-code deployment. For hardware-level concealment, NNSplitter [68] lowers unauthorized accuracy to 10% by protecting only 0.002% of weights, but incurs TEE-based secret storage and restoration requirements, and Mohseni et al. [43] reduce wrong-key model accuracy to 1.0â9.5% with reported 43%, 79%, and 71% reductions in area, power, and weight-modification energy, but require specialized hard- ware integration. Open Problem 6: The robustness of model obfusca- tion defenses in MOAI systems remains bounded by the executable equivalence that obfuscation must preserve, as structures and weights hidden through transformed parameters, coupled operators, generated native code, or hardware-protected secrets still need to be composed into the original prediction function during authorized infer- ence, exposing recoverable execution states for semantic, structural, and parameter recovery. 5.2.2. Model Authorization. Instead of concealing model internals, model authorization protects on-device models by binding correct inference and model integrity to an authenti- cated deployment context, so that unauthorized models lose utility and modified models fail verification before infer- ence. As model authorization defenses for MOAI systems remain underexplored, we discuss existing work in this line separately rather than organize it into finer-grained classes. Hua et al. [25] proposed MMGuard, the first automated framework for building mutual authentication between An- droid AI apps and on-device models. It rewrites compiled models and mobile AI frameworks to add key-dependent input branches to selected layers and verify model hashes during initialization, so that packed weights can be correctly recovered only with the app-specific key generated from owner- and app-related signature information. As a result, stolen models lose prediction utility without the correct key, while tampered models fail verification and abort before inference, protecting against model stealing and tampering. Security-cost Trade-off: Model authorization improves confidentiality and integrity by making model utility de- pend on an authenticated appâmodel binding, but it incurs overhead from startup checks. MMGuard [25] renders unauthorized or tampered models unusable, but its initialization overhead reaches 50â69% (449 ms on average), and automatic protection succeeds on 37/43 evaluated mobile AI apps, with failures mainly caused by unsupported models or operators. Open Problem 7: Model authorization in MOAI systems protects on-device models by coupling correct inference with app-specific credentials and integrity verification, but the credential generation, model-hash verification, and packed-weight recovery must execute inside the mobile stack, making authorization enforcement depen- dent on client-side code that can be reverse engineered, repackaged, or instrumented after deployment. 5.2.3. TEE. Moving beyond artifact-level concealment or authorization, TEE defenses for MOAI systems use hardware-isolated execution to protect on-device models during runtime, establishing trusted domains for full in- ference execution, security-sensitive model components, or obfuscated-output reconstruction. According to the protected execution scope and computation placement, we categorize existing TEE defenses into three classes: monolithic execu- tion, partitioned execution, and obfuscated offloading. Monolithic Execution. The principle of these defenses is to execute the full on-device inference pipeline within TEE-backed runtimes, with the goal of safeguarding model parameters, intermediate data, and computation logic under mobile resource constraints. Bayerl et al. [15] proposed Offline Model Guard, which leverages SANCTUARY [17] to create user-space enclaves, attests to the enclave before encrypted model provisioning, and decrypts the model only inside the enclave to securely process peripheral inputs for on-device inference. To address memory exposure and latency bottlenecks in such secure execution, Choi et al. [20] introduced GuardiaNN, a TrustZone-based framework that keeps model data encrypted in DRAM, confines plaintext computation to the secure world, and uses direct convo- lution, SRAM-aware data reuse, and cryptographic hard- ware to lower overhead. Hu et al. [23] further reduced secure memory pressure with a mobile TEE framework that combines progressive pruning, memory reclamation, and adaptive model loading to fit the entire inference process within constrained TEE memory. Later studies shifted this direction toward more flexible TEE-backed inference under mobile deployment constraints. Islam et al. [32] proposed T-Slices, a dynamic fragmentation framework, which divides unmodified model layers into memory-fit slices, sequentially loads them into TrustZone, and keeps inactive slices encrypted in untrusted memory to protect the entire inference execution. At the application level, Sun et al. [48] developed LEAP, a developer-friendly solution that extracts on-device models and inference codes from AI apps and runs them in lightweight isolated sand- boxes with verified launch, exclusive peripheral access, and flexible resource control to shield sensitive inference from compromised rich-OS access and interference. Beyond TrustZone-only designs, Moon et al. [44] introduced AS- GARD, a virtualization-based TEE framework that extends protected execution to SoC-integrated accelerators through secure I/O passthrough, reduces the trusted computing base via platform and application debloating, and mitigates TEE- to-REE exits with model execution planning. For on-device LLM inference, Wang et al. [54] proposed TZ-LLM, an Arm TrustZone-based secure inference system that runs the LLM framework as a trusted application, com- bines pipelined parameter restoration with dynamic secure- memory scaling, and uses a minimal TEE-side NPU co- driver to protect LLM parameters, activations, and KV cache against compromised REE and DMA-based extraction. Sim- ilarly, Wu et al. [59] presented FlexServe, which supports TrustZone-based mobile LLM serving with page-granular secure memory and switchable NPU execution to protect model weights, KV caches, and intermediate results from compromised-kernel access. Partitioned Execution. Given limited TEE memory and costly accelerator access, partitioned execution has emerged to place security-sensitive model components or framework routines inside the TEE and delegate less sensitive work- loads to the untrusted normal world. Mo et al. [42] proposed DarkneTZ, a layer-level partitioning framework that profiles a modelâs layer privacy sensitivity and executes sensitive layers inside the TEE while leaving the remaining layers in the normal world to reduce privacy risks with limited overhead. Similarly, Gangal et al. [22] introduced Hybrid- TEE, which bridges local ARM TrustZone and remote Intel SGX through a trusted channel and assigns model parti- tions across the two TEEs to alleviate local secure-memory constraints. Then, Liu et al. [38] presented SecDeep, a TrustZone-based framework with a split ARM N design to keep plaintext tensor computation inside the TEE and protect normal world preparation and accelerator configu- ration through integrity checks and encryption. Later, Sun et al. [51] proposed ShadowNet, which transforms linear- layer weights before untrusted accelerator offloading, keeps nonlinear operations inside the TEE, and restores outsourced results in the TEE to preserve model confidentiality. Recent works reduce the trusted footprint from coarse execution partitions to compact trusted logic and critical model states. Liu et al. [40] proposed MirrorNet, a TEE- friendly framework in which a degraded BackboneNet ex- ecutes in the normal world and a lightweight Companion Partial Monitor resides in the secure world to rectify out- puts for authorized inference. Subsequently, Sun et al. [50] introduced TSQP, a quantization model partition framework that shields crucial re-quantization scales inside the TEE, offloads 8-bit operations to the normal environment, and uses parameter de-similarity with an integrity monitor to preserve model confidentiality and integrity. Additionally, Li et al. [33] designed TEESlice, which partitions mod- els before training into a public backbone and privacy- sensitive slices, prunes these slices to fit TEE memory, and offloads backbone linear layers to GPUs over encrypted and verifiable channels. Furthermore, Sun et al. [49] presented TensorShield, a tensor-level partitioning framework that uses attention-transition analysis to identify critical tensors, pro- tects selected tensors through TEE shielding, and combines critical-feature identification with latency-aware placement to maintain model confidentiality. Obfuscated Offloading. Since heavy neural operators are often delegated to untrusted accelerators for efficiency, this class protects outsourced inference through the exposure of only transformed weights and TEE-based recovery of authentic outputs. Zhang et al. [61] proposed GroupCover, which applies reverse clustering and mutual covering to obfuscate convolution kernels before GPU offloading, and reconstructs authentic layer outputs inside the TEE to re- sist model stealing. At the LLM scale, Wang et al. [53] introduced ARROWCLOAK, a lightweight obfuscation al- gorithm that randomizes private weight-vector directions inside the TEE before GPU offloading to mitigate direction- similarity-based weight recovery, with efficient TEE-side reconstruction of original layer outputs. Recently, Zheng et al. [63] designed ConvShatter, a convolution obfuscation scheme that decomposes kernels into shared patch bases and kernel-specific damaged components, injects decoy kernels, permutes channels and kernels, and uses TEE-sealed meta- data to recover GPU-computed obfuscated outputs. Security-cost Trade-off: TEE defenses improve model confidentiality through hardware-backed isolation, but their overhead shifts to secure-memory pressure, TEE/REE coordination, and accelerator integration. For monolithic execution, TZ-LLM [54] protects on- device model parameters and runtime states with Trust- Zone/NPU support, but incurs 5.2â28.3% TTFT overhead and 1.3â4.9% decoding overhead over REE inference. For partitioned execution, TensorShield [49] achieves near full-TEE protection with up to 25.35Ă speedup over prior TEE-based inference, but incurs offline pro- filing and selection costs, including 23 minâ1 h 25 min hardware profiling and 10.9 average evaluation epochs for critical-tensor selection. For obfuscated offloading, ARROWCLOAK [53] increases weight-direction distance by over 900Ă and improves defense by 6.5Ă, but adds 0.46Ă overhead over non-obfuscated TSLP, with TEE- side recovery taking 40.70% of runtime. Open Problem 8: The practical scalability of TEE defenses for MOAI systems remains limited by a deployment-integration gap, as protecting diverse on- device models requires coordinated support across model formats, AI frameworks, operator libraries, delegates, and CPU/GPU/NPU isolation interfaces, yet current mo- bile ecosystems still lack widely adopted, developer- transparent TEE-backed inference stacks. 5.2.4. Model Watermarking. In contrast to the aforemen- tioned proactive defenses, which aim to prevent unautho- rized model access or misuse before and during inference, model watermarking protects on-device models through ownership verification after model extraction, copying, or unauthorized reuse occurs. Since watermarking for on- device models in MOAI systems remains less explored than preventive defenses, we discuss existing watermarking work separately rather than further categorizing it. Huang et al. [30] proposed THEMIS, the first prac- tical watermarking tool for intellectual property protec- tion of post-deployment on-device models in MOAI sys- tems. It lifts the read-only and inference-only constraints of on-device models by reconstructing writable counterparts through Model Rooting and solving watermark parameters through training-free Model Reweighting. Through selective parameter modification, THEMIS enables black-box owner- ship verification of suspected stolen models while preserving utility on benign inputs. Security-cost Trade-off: Model watermarking improves post-deployment accountability by enabling ownership verification after model extraction or unauthorized reuse, but its cost shifts to utility degradation, offline embed- ding time, and deployment compatibility. THEMIS [30] achieves over 80% watermark success rate across eval- uated on-device scenarios, but may reduce benign accu- racy by up to 12.76% when label data is missing. In addi- tion, THEMIS successfully watermarks 81.14% (327/403) of evaluated Google Play AI apps, while failures arise from anti-repackaging mechanisms and unknown model- decryption APIs. Open Problem 9: Although model watermarking en- ables post-deployment ownership verification for on- device models in MOAI systems, its effectiveness remains limited by redeployment-induced watermark fragility, as stolen models may be reused via framework conver- sion, encryption, or app-level input-output mediation that preserves benign inference while disrupting the trigger responses, confidence patterns, or output semantics used for ownership verification. 5.3. Cross-pillar Analysis of MOAI Defenses Figure 3 (the lower half) illustrates how the defense categories in §5.2 and their corresponding open problems (OP6-OP9) map to the three security pillars of MOAI sys- tems. Existing defenses are model-oriented in purpose but lifecycle-dependent in enforcement, with protection realized through pre-release concealment, app-bound authorization, TEE-backed execution, and post-deployment ownership ver- ification. The mapping further shows that the identified OPs expose the robustness limits of current defenses, since their effectiveness depends on executable equivalence under obfuscation, app-bound authorization in client-side code, TEE-backed inference support across heterogeneous mobile stacks, and watermark verifiability after reuse. Security Pillars to MOAI Defenses. The defense map- ping reveals a model-centric protection orientation in MOAI systems, with Pillar I serving as the common locus of protection, Pillar I carrying those protections into runtime- confined execution, and Pillar I mediating the app-level invocation path for authorized model use. Model obfuscation protects Pillars I and I because it conceals the structures, parameters, and operators of deployed models and makes correct inference behavior available only through authorized runtime execution. OP6 captures the residual exposure inher- ent to this design, as the runtime states materialized during authorized inference provide recovery signals for semantic, structural, or parameter reconstruction. Model authorization concentrates on Pillar I as it protects model artifacts through conditional correctness, where app-specific credentials and artifact verification govern correct inference behavior. This authorization check places the trust decision in the deployed mobile stack, so OP7 concerns the robustness of client-side authorization against reverse engineering, repackaging, or instrumentation. TEE defenses cover Pillars I and I since they safeguard deployed models through hardware-backed isolation, ranging from full-model execution and security- sensitive partitions to TEE-side recovery of accelerator- offloaded outputs. The key challenge for such defenses captured by OP8 lies in making them deployable at scale across heterogeneous mobile inference and isolation stacks. Model watermarking strengthens Pillar I because it embeds ownership evidence into deployed models and enables be- havioral verification of suspected model extraction or reuse. OP9 captures the fragility of this evidence after model reuse, as redeployment through model conversion, encryption, or app-level mediation can preserve normal functionality while weakening the behavioral signals needed for verification. Takeaway. Although current MOAI defenses attach pro- tections to deployed models, their robustness depends on post-release assurance mechanisms that realize those pro- tections through authorized execution, client-side checks, hardware-backed isolation, or post-reuse verification. These mechanisms are not auxiliary implementations around pro- tected models, but the enforcement basis on which defense guarantees depend after release. Their constraints lie in preserving legitimate use of protected models while avoiding recovery handles in authorized execution, bypass targets in client-side checks, portability bottlenecks in hardware- backed isolation, and ownership blind spots in post-reuse verification. Hence, OP6âOP9 characterize the post-release robustness requirements for model defenses, calling for guarantees that resist execution-based recovery and client- side bypass, remain deployable at scale, and preserve owner- ship verifiability after reuse in realistic MOAI deployments. 6. Future Directions Security of On-Device Training in MOAI Systems. As discussed in §4.2 and §5.2, existing research on MOAI security solely focuses on deployed models that are read- only and inference-only, leaving the security implications of on-device training unexplored. Emerging on-device train- ing [11] enable models to be updated on end-user devices. For example, a fashion item recognition MOAI system can locally fine-tune its on-device model using user data to better recognize items of interest to users. This process exposes model gradients, parameter updates, and user data at runtime, which introduces new security threats beyond those considered in inference-only on-device models. Hence, future research should explore the expanded threat landscape introduced by on-device training, with particular emphasis on how exposure of the training process enables novel on- device models attacks against MOAI systems and motivates the design of corresponding defenses. Security of On-device GenAI in MOAI Systems. Current research on MOAI security predominantly focuses on computer vision tasks, particularly image classification, while security assessment of other domains like natural language processing remains unexplored. With the rapid evolution of LLMs, on-device GenAI [10] has become feasi- ble across smartphones to support LLM inference and image generation. For instance, a conversational MOAI system can execute an on-device LLM to process user prompts and generate responses locally, handling sensitive conversational data on end-user devices. However, on-device GenAI intro- duces security challenges that differ from those of vision- based models, such as prompt injection, jailbreaking be- haviors, and unintended information disclosure. Therefore, future research should consider on-device security beyond vision-based models and establish practical threat models that capture the distinctive attack surfaces and defense chal- lenges in on-device GenAI. Security of Agentic MOAI Systems. Driven by increas- ingly capable LLMs and emerging mobile tool interfaces, MOAI systems are expanding from passive on-device in- ference toward agentic workflows that connect mobile app contexts, private user data, sensors, OS services, and cross- app interfaces with foundation models executed on device, in the cloud, or through hybrid paths. This transition expands the security scope from protecting deployed models and inference pipelines to securing context-to-action chains on end-user devices, where malicious prompts, poisoned app context, compromised tool outputs, or misleading sensor sig- nals may trigger privacy leakage, unauthorized operations, cross-app abuse, or persistent device-state changes without modifying the deployed model artifact. Thus, future research should move beyond prompt-level defenses and develop end-to-end action governance for agentic MOAI systems, with particular emphasis on establishing provenance for mobile context, separating trusted user intent from untrusted environmental content, binding tool and API invocations to task-scoped permissions, enforcing confirmation and roll- back for sensitive operations, and auditing agent plans, memory, and actions. 7. Conclusion This paper systematizes the security landscape of MOAI systems, where AI models are stored, loaded, and executed on end-user devices. We introduce three security pillars to characterize MOAI-specific security properties, develop at- tack and defense taxonomies across adversarial capabilities and deployment phases, and identify nine open problems that expose how mobile deployment reshape both attack practicality and defense robustness. Looking forward, we outline on-device training, on-device GenAI, and agentic MOAI systems, as future directions for extending MOAI security landscape. Our SoK can serve as a foundation for principled security analysis and practical defense design for next-generation MOAI systems. References [1]Avcam. https://developer.apple.com/documentation/avfoundation/avc am-building-a-camera-app, 2026. [2]Camerax. developer.android.com/media/camera/camerax, 2026. [3]Coreml. developer.apple.com/machine-learning/core-ml/, 2026. [4]Executorch. https://executorch.ai/, 2026. [5]Google gemma 4. https://developers.google.com/edge/litert-lm/mode ls/gemma-4, 2026. [6]Google tensor. https://developers.google.com/edge/litert/next/tenso r-sdk, 2026. [7]Litert. https://ai.google.dev/edge/litert, 2026. [8]Mlfeaturevalue. https://developer.apple.com/documentation/coreml/m lfeaturevalue, 2026. [9]Neural engine. https://apple.fandom.com/wiki/Neural Engine, 2026. [10] On-device genai. https://developers.googleblog.com/on-device-genai -in-chrome-chromebook-plus-and-pixel-watch-with-litert-lm/, 2026. [11] On-device training with litert. https://developers.google.com/edge/lit ert/conversion/tensorflow/build/ondevicetraining, 2026. [12] Open neural network exchange. https://onnx.ai/, 2026. [13] Qualcomm hexagon. w.qualcomm.com/processors/hexagon, 2026. [14] Tensorimage. https://ai.google.dev/edge/api/tflite/java/org/tensorflow/ lite/support/image/TensorImage, 2026. [15] Sebastian P Bayerl, Tommaso Frassetto, Patrick Jauernig, Korbinian Riedhammer, Ahmad-Reza Sadeghi, Thomas Schneider, Emmanuel Stapf, and Christian Weinert. Offline model guard: secure and private ml on mobile devices. In Proceedings of the 23rd Conference on Design, Automation and Test in Europe, pages 460â465, 2020. [16] Ondrej Bohdal, Mete Ozay, Jijoong Moon, Kyenghun Lee, Hyeonmok Ko, and Umberto Michieli. Efficient compositional multi-tasking for on-device large language models. In Proceedings of the 2025 Conference on Empirical Methods in Natural Language Processing, pages 28129â28153, 2025. [17] Ferdinand Brasser, David Gens, Patrick Jauernig, Ahmad-Reza Sadeghi, and Emmanuel Stapf. Sanctuary: Arming trustzone with user-space enclaves. In NDSS, volume 100, page 102, 2019. [18] Samuel J Broughton and Lahiru Samarakoon. Improving end-to-end neural diarization using conversational summary representations. In Proc. Interspeech 2023, pages 3157â3161, 2023. [19] Hongchen Cao, Shuai Li, Yuming Zhou, Ming Fan, Xuejiao Zhao, and Yutian Tang. Cheating your apps: Black-box adversarial attacks on deep learning apps. Journal of Software: Evolution and Process, 36(4):e2528, 2024. [20] Jinwoo Choi, Jaeyeon Kim, Chaemin Lim, Suhyun Lee, Jinho Lee, Dokyung Song, and Youngsok Kim. Guardiann: Fast and secure on- device inference in trustzone using embedded sram and cryptographic hardware. In Proceedings of the 23rd ACM/IFIP International Mid- dleware Conference, pages 15â28, 2022. [21] Zizhuang Deng, Kai Chen, Guozhu Meng, Xiaodong Zhang, Ke Xu, and Yao Cheng. Understanding real-world threats to deep learning models in android apps. In Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security, pages 785â 799, 2022. [22] Akshay Gangal, Mengmei Ye, and Sheng Wei. Hybridtee: Secure mobile dnn execution using hybrid trusted execution environment. In 2020 Asian Hardware Oriented Security and Trust Symposium (AsianHOST), pages 1â6. IEEE, 2020. [23] Bin Hu, Yan Wang, Jerry Cheng, Tianming Zhao, Yucheng Xie, Xiaonan Guo, and Yingying Chen. Secure and efficient mobile dnn using trusted execution environments. In Proceedings of the 2023 ACM Asia Conference on Computer and Communications Security, pages 274â285, 2023. [24] Han Hu, Yujin Huang, Qiuyuan Chen, Terry Yue Zhuo, and Chunyang Chen. A first look at on-device models in ios apps. ACM Transactions on Software Engineering and Methodology, 33(1):1â30, 2023. [25] Jiayi Hua, Yuanchun Li, and Haoyu Wang. Mmguard: Automatically protecting on-device deep learning models in android apps. In 2021 IEEE Security and Privacy Workshops (SPW), pages 71â77. IEEE, 2021. [26] Jiayi Hua, Kailong Wang, Meizhen Wang, Guangdong Bai, Xiapu Luo, and Haoyu Wang. Malmodel: Hiding malicious payload in mo- bile deep learning models with black-box backdoor attack. Automated Software Engineering, 33(1):28, 2026. [27] Yujin Huang and Chunyang Chen. Smart app attack: hacking deep learning models in android apps. IEEE Transactions on Information Forensics and Security, 17:1827â1840, 2022. [28] Yujin Huang, Han Hu, and Chunyang Chen.Robustness of on- device models: Adversarial attack to deep learning models on android apps. In 2021 IEEE/ACM 43rd International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP), pages 101â110. IEEE, 2021. [29] Yujin Huang, Xingliang Yuan, Chunyang Chen, and Seong Oun Hwang.Typhon unleashed: Practical adversarial weight attacks against on-device deep learning models.IEEE Transactions on Dependable and Secure Computing, 2026. [30] Yujin Huang, Zhi Zhang, Qingchuan Zhao, Xingliang Yuan, and Chunyang Chen.Themis: Towards practical intellectual property protection for post-deployment on-device deep learning models. In 34th USENIX security symposium (USENIX Security 25), 2025. [31] Jacob Huckelberry, Yuke Zhang, Allison Sansone, James Mickens, Peter A Beerel, and Vijay Janapa Reddi. Tinyml security: Explor- ing vulnerabilities in resource-constrained machine learning systems. arXiv preprint arXiv:2411.07114, 2024. [32] Md Shihabul Islam, Mahmoud Zamani, Chung Hwan Kim, Latifur Khan, and Kevin W Hamlen. Confidential execution of deep learning inference at the untrusted edge with arm trustzone. In Proceedings of the Thirteenth ACM Conference on Data and Application Security and Privacy, pages 153â164, 2023. [33] Ding Li, Ziqi Zhang, Mengyu Yao, Yifeng Cai, Yao Guo, and Xi- angqun Chen. Teeslice: Protecting sensitive neural network models in trusted execution environments when attackers have pre-trained mod- els. ACM Transactions on Software Engineering and Methodology, 34(6):1â49, 2025. [34] Minghui Li, Yang Li, Hao Han, Xiaopeng Ke, Tongyu Wang, Fengyuan Xu, and Liming Fang. Redlc: Learning-driven reverse engi- neering for deep learning compilers. In 2024 IEEE 35th International Symposium on Software Reliability Engineering (ISSRE), pages 204â 215. IEEE, 2024. [35] Wenbo Li, Yi Wei, Yilin Shen, and Hongxia Jin. Efficient layout- guided image inpainting for mobile use.In Proceedings of the IEEE/CVF Winter Conference on Applications of Computer Vision, pages 8450â8459, 2024. [36] Yuanchun Li, Jiayi Hua, Haoyu Wang, Chunyang Chen, and Yunxin Liu.Deeppayload: Black-box backdoor attack on deep learning models through neural payload injection. In 2021 IEEE/ACM 43rd International Conference on Software Engineering (ICSE), pages 263â274. IEEE, 2021. [37] Jialin Liu and Han Wang. Model extraction attack against on-device deep learning with power side channel. In 2024 25th International Symposium on Quality Electronic Design (ISQED), pages 1â5. IEEE, 2024. [38] Renju Liu, Luis Garcia, Zaoxing Liu, Botong Ou, and Mani Sri- vastava. Secdeep: Secure and performant on-device deep learning inference framework for mobile and iot devices. In Proceedings of the International Conference on Internet-of-Things Design and Implementation, pages 67â79, 2021. [39] Zhibo Liu, Yuanyuan Yuan, Yanzuo Chen, Sihang Hu, Tianxiang Li, and Shuai Wang. Deepcache: Revisiting cache side-channel attacks in deep neural networks executables. In Proceedings of the 2024 on ACM SIGSAC Conference on Computer and Communications Security, pages 4495â4508, 2024. [40] Ziyu Liu, Yukui Luo, Shijin Duan, Tong Zhou, and Xiaolin Xu. Mir- rornet: A tee-friendly framework for secure on-device dnn inference. In 2023 IEEE/ACM International Conference on Computer Aided Design (ICCAD), pages 1â9. IEEE, 2023. [41] Hua Ma, Huming Qiu, Yansong Gao, Zhi Zhang, Alsharif Abuadbba, Minhui Xue, Anmin Fu, Jiliang Zhang, Said F Al-Sarawi, and Derek Abbott. Quantization backdoors to deep learning commercial frame- works. IEEE Transactions on Dependable and Secure Computing, 21(3):1155â1172, 2023. [42] Fan Mo, Ali Shahin Shamsabadi, Kleomenis Katevas, Soteris Demetriou, Ilias Leontiadis, Andrea Cavallaro, and Hamed Haddadi. Darknetz: towards model privacy at the edge using trusted execution environments. In Proceedings of the 18th International Conference on Mobile Systems, Applications, and Services, pages 161â174, 2020. [43] Alireza Mohseni, Mohammad Hossein Moaiyeri, and Moham- mad Javad Adel. A novel obfuscation method based on majority logic for preventing unauthorized access to binary deep neural networks. Scientific Reports, 15(1):24416, 2025. [44] Myungsuk Moon, Minhee Kim, Joonkyo Jung, and Dokyung Song.Asgard: Protecting on-device deep neural networks with virtualization-based trusted execution environments. In Proceedings 2025 Network and Distributed System Security Symposium, 2025. [45] Tushar Nayan, Qiming Guo, Mohammed Al Duniawi, Marcus Botacin, Selcuk Uluagac, and Ruimin Sun. SoK: All you need to know aboutOn-DeviceML model extraction-the gap between research and practice. In 33rd USENIX Security Symposium (USENIX Security 24), pages 5233â5250, 2024. [46] Pengcheng Ren, Chaoshun Zuo, Xiaofeng Liu, Wenrui Diao, Qingchuan Zhao, and Shanqing Guo.Demistify: Identifying on- device machine learning models stealing and reuse vulnerabilities in mobile apps. In Proceedings of the 46th IEEE/ACM International Conference on Software Engineering, pages 1â13, 2024. [47] Ye Sang, Yujin Huang, Shuo Huang, and Helei Cui. Beyond the model: Data pre-processing attack to deep learning models in android apps. In Proceedings of the 2023 Secure and Trustworthy Deep Learning Systems Workshop, pages 1â9, 2023. [48] Lizhi Sun, Shuocheng Wang, Hao Wu, Yuhang Gong, Fengyuan Xu, Yunxin Liu, Hao Han, and Sheng Zhong. Leap: Trustzone based developer-friendly tee for intelligent mobile apps. IEEE Transactions on Mobile Computing, 22(12):7138â7155, 2022. [49] Tong Sun, Bowen Jiang, Hailong Lin, Borui Li, Yixiao Teng, Yi Gao, and Wei Dong.Tensorshield: Safeguarding on-device inference by shielding critical dnn tensors with tee. In Proceedings of the 2025 ACM SIGSAC Conference on Computer and Communications Security, pages 1008â1022, 2025. [50] Yu Sun, Gaojian Xiong, Jianhua Liu, Zheng Liu, and Jian Cui. Tsqp: Safeguarding real-time inference for quantization neural networks on edge devices. In 2025 IEEE Symposium on Security and Privacy (SP), pages 2114â2132. IEEE, 2025. [51] Zhichuang Sun, Ruimin Sun, Changming Liu, Amrita Roy Chowd- hury, Long Lu, and Somesh Jha. Shadownet: A secure and efficient on-device model inference system for convolutional neural networks. In 2023 IEEE Symposium on Security and Privacy (SP), pages 1596â 1612. IEEE, 2023. [52] Zhichuang Sun, Ruimin Sun, Long Lu, and Alan Mislove. Mind your weight (s): A large-scale study on insufficient machine learning model protection in mobile apps. In 30th USENIX security symposium (USENIX security 21), pages 1955â1972, 2021. [53] Pengli Wang, Bingyou Dong, Yifeng Cai, Zheng Zhang, Junlin Liu, Huanran Xue, Ye Wu, Yao Zhang, and Ziqi Zhang. Game of arrows: On the (In-) Security of weight obfuscation forOn-DeviceTEE- ShieldedLLM partition algorithms.In 34th USENIX Security Symposium (USENIX Security 25), pages 279â298, 2025. [54] Xunjie Wang, Jiacheng Shi, Zihan Zhao, Yang Yu, Zhichao Hua, and Jinyu Gu. Tz-llm: Protecting on-device large language models with arm trustzone. In Proceedings of the 21st European Conference on Computer Systems, pages 657â674, 2026. [55] Zijian Wang, Shuo Huang, Yujin Huang, and Helei Cui. Energy- latency attacks to on-device neural networks via sponge poisoning. In Proceedings of the 2023 Secure and Trustworthy Deep Learning Systems Workshop, pages 1â11, 2023. [56] Jiali Wei, Ming Fan, Xicheng Zhang, Wenjing Jiao, Haijun Wang, and Ting Liu. Stealthy backdoor attack to real-world models in android apps. arXiv preprint arXiv:2501.01263, 2025. [57] Tatjana Wingarz, Anne Lauscher, Janick Edinger, Dominik Kaaser, Stefan Schulte, and Mathias Fischer. Sok: towards security and safety of edge ai. arXiv preprint arXiv:2410.05349, 2024. [58] Hao Wu, Yuhang Gong, Xiaopeng Ke, Hanzhong Liang, Fengyuan Xu, Yunxin Liu, and Sheng Zhong. Tim: Enabling large-scale white- box testing on in-app deep learning models. IEEE Transactions on Information Forensics and Security, 19:8188â8203, 2024. [59] Yinpeng Wu, Yitong Chen, Lixiang Wang, Jinyu Gu, Zhichao Hua, and Yubin Xia. Flexserve: A fast and secure llm serving system for mobile devices with flexible resource isolation. arXiv preprint arXiv:2603.09046, 2026. [60] Mengwei Xu, Jiawei Liu, Yuanqiang Liu, Felix Xiaozhu Lin, Yunxin Liu, and Xuanzhe Liu.A first look at deep learning apps on smartphones. In The World Wide Web Conference, pages 2125â2136, 2019. [61] Zheng Zhang, Na Wang, Ziqi Zhang, Yao Zhang, Tianyi Zhang, Jianwei Liu, and Ye Wu. Groupcover: A secure, efficient and scalable inference framework for on-device model protection based on tees. In Forty-first international conference on machine learning, 2024. [62] Ziqi Zhang, Chen Gong, Yifeng Cai, Yuanyuan Yuan, Bingyan Liu, Ding Li, Yao Guo, and Xiangqun Chen. No privacy left outside: On the (in-) security of tee-shielded dnn partition for on-device ml. In 2024 IEEE Symposium on Security and Privacy (SP), pages 3327â 3345. IEEE, 2024. [63] Huadi Zheng, Li Cheng, and Yan Ding. Miragenet: A secure, efficient, and scalable on-device model protection in heterogeneous tee and gpu system. arXiv preprint arXiv:2601.13826, 2026. [64] Mingyi Zhou, Xiang Gao, Xiao Chen, Chunyang Chen, John Grundy, and Li Li. Dynamo: Protecting mobile dl models through coupling obfuscated dl operators.In Proceedings of the 39th IEEE/ACM International Conference on Automated Software Engineering, pages 204â215, 2024. [65] Mingyi Zhou, Xiang Gao, Pei Liu, John Grundy, Chunyang Chen, Xiao Chen, and Li Li. Model-less is the best model: Generating pure code implementations to replace on-device dl models. In Proceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis, pages 174â185, 2024. [66] Mingyi Zhou, Xiang Gao, Jing Wu, John Grundy, Xiao Chen, Chunyang Chen, and Li Li. Modelobfuscator: Obfuscating model information to protect deployed ml-based systems. In Proceedings of the 32nd ACM SIGSOFT International Symposium on Software Testing and Analysis, pages 1005â1017, 2023. [67] Mingyi Zhou, Xiang Gao, Jing Wu, Kui Liu, Hailong Sun, and Li Li. Investigating white-box attacks for on-device models. In Proceedings of the IEEE/ACM 46th International Conference on Software Engineering, pages 1â12, 2024. [68] Tong Zhou, Yukui Luo, Shaolei Ren, and Xiaolin Xu. Nnsplitter: an active defense solution for dnn model via automated weight obfuscation. In International Conference on Machine Learning, pages 42614â42624. PMLR, 2023.