Imagine you have a valuable painting and you want to display it in a gallery with a notorious theft problem. The traditional fix is to rebuild the painting frame-by-frame into a custom vault — expensive, error-prone, and you have to redo it for every new painting. This paper asks: what if you instead built a universal display case that accepts any painting in a standard frame format, and bolted that case into the vault? WebAssembly is the standard frame; Arm TrustZone is the vault. The committed claim: you can run unmodified AI inference workloads inside OP-TEE (the open-source TrustZone OS) by compiling models to WebAssembly and executing them on the WebAssembly Micro Runtime (WAMR) — no manual porting to the trusted application API required. The model binary is encrypted, and the decryption key lives in a hardware fuse readable only from the secure world. An adversary with full root access to the normal OS never sees the plaintext model. The ladder here is narrow but honest. The baseline is manually porting an AI application to OP-TEE's Trusted Application framework — the current "proper" way to do this, which requires significant developer effort and model-specific adaptation. The WebAssembly approach adds 22% overhead versus that hand-ported baseline and 6% additional inference latency versus native Wasm execution outside the TEE. These are not devastating numbers, but they are not free either. The authors do not compare against other emerging approaches like Intel SGX enclaves for edge AI or GPU-based TEE solutions, which limits the ladder's reach. Architecturally, this sits in the intersection of two well-established families: WebAssembly runtimes (specifically WAMR in interpreter and ahead-of-time compilation modes) and Arm TrustZone's OP-TEE trusted OS. The key structural choice is using Wasm as an abstraction layer that decouples the model format from the TEE's native API. The system leans on the hardware property that TrustZone fuses are physically inaccessible from the normal world — this is where the security guarantee actually lives, not in the software stack. Integrity is the weakest dimension. The evaluation is entirely self-benchmarked: the authors built the system and measured it on their own hardware. There is no independent replication, no community benchmark for TEE-based AI inference, and the threat model evaluation is qualitative rather than formal. The 22% and 6% numbers come from their own test setup. The paper acknowledges limitations — Wasm's lack of SIMD support in the TEE context, memory constraints — but the absence of adversarial testing against actual side-channel attacks is a gap. The milestone question is about practical deployment scale. Today the system runs small CPU-based models on Arm edge devices. The next meaningful threshold is running models large enough to have real commercial IP value — think production-grade computer vision or NLP models in the tens-of-millions-of-parameters range — inside the TEE without the memory ceiling of OP-TEE becoming a showstopper. The paper hints at this but does not quantify where the wall is. The obvious experiment not run: adversarial side-channel analysis. If you are protecting model IP inside a TEE, the first question a security reviewer asks is whether timing attacks, power analysis, or cache-based side channels can leak the model weights. The authors cite this as future work. The honest read is (a) — this is a systems/SE paper, not a cryptanalysis paper, and the side-channel work requires different expertise and equipment. But without it, the security promise is architectural, not empirically validated.
