Why On-Device Model Encryption Cannot Replace API Authorization

Deconstruct Mobile AI Applications into Seven Asset Classes

Mobile AI security is often oversimplified to whether the model is encrypted. In reality, the attack surface includes at least model files, inference runtimes, input preprocessing, output post-processing, prompts or business rules, remote API credentials, user data, and logs. Each asset class carries different consequences upon leakage, distinct update mechanisms, and separate ownership responsibilities.

Copying model weights may lead to intellectual property theft and loss of business capability; modifying prompt templates or post-processing logic can alter business behavior; leaking long-lived API Keys can directly result in financial loss, unauthorized data access, or resource abuse; input/output logs may contain user privacy data. Protecting only the model file fails to cover these remaining risks.

An asset register must document storage location, generation source, transmission path, runtime usage patterns, update and rollback mechanisms, least privilege principles, log scope, and retention periods. Assets without a defined lifecycle should not be deemed protected solely by enabling an encryption switch.

Model Files Must Become Usable Material During Runtime

Whether using Core ML, LiteRT, or other on-device runtimes, models must be loaded, parsed, and engaged in computation. File-layer encryption reduces the convenience of direct copying from installation packages or app directories, but it cannot prevent the running application from accessing model materials. If an attacker controls the process or observes the runtime, the risk model shifts from static files to loading, memory, invocations, and outputs.

This does not imply model encryption lacks value. It raises the cost of low-effort copying, prevents direct substitution, and forms part of a defense-in-depth strategy alongside package protection, integrity checks, runtime environment detection, and version pairing. The key is to frame the benefit as increasing attacker cost and reducing the exposure surface, rather than claiming extraction is impossible.

Model updates also introduce compatibility challenges. Model versions must be paired with preprocessing logic, feature shapes, runtime versions, hardware capabilities, and post-processing rules. Update failures require safe rollbacks to prevent random combinations of old models and new logic.

Long-Lived High-Privilege API Keys Should Not Be Client Secrets

Android security documentation explicitly states that API Keys embedded in source code may be discovered via decompilation after the app is compiled. Obfuscation and application hardening can increase the cost of locating them, but they cannot change the fact that the client must hold and use these credentials. As long as a key remains long-lived and highly privileged within a generic client, the impact of leakage is difficult to constrain.

Android Keystore can keep certain key materials non-exportable, but official documentation clarifies that if the application process is compromised, attackers may still be able to use the app's keys to perform operations. It is suitable for protecting device-bound private keys and local encryption, but should not be misinterpreted as a secure vault for arbitrary long-lived shared secrets for remote services.

A more robust architecture requires the client to request short-lived, restricted, and revocable tokens from its own service based on user identity and device context, or have the server-side proxy handle high-risk model invocations. The server must enforce account authorization, quotas, rate limiting, model scope, data scope, and anomalous behavior monitoring.

• Isolate credentials by development, testing, and production environments
• Ensure tokens possess minimal model and data permissions
• Enable server-side revocation and enforce quota and rate limits
• Prevent clients from storing long-lived high-privilege shared keys

request = verify_user_session(input.session)
app = verify_app_evidence(input.attestation)
policy = load_policy(user=request.user, app=app.identity)

if policy.version_state == UNKNOWN:
    return CHALLENGE_OR_LIMIT
if policy.account_scope.allows(input.model_scope) == false:
    return DENY
if policy.risk_score >= HIGH:
    return STEP_UP_VERIFICATION

return issue_short_lived_token(
    scope=input.model_scope,
    quota=policy.quota,
    expires_in=policy.short_window
)

Integrity Signals Should Only Inform Server-Side Decisions

Play Integrity provides Android backends with signals regarding app identification, device integrity, account licensing, and partial environmental risks. Apple App Attest helps the server determine if a request originates from a valid app instance by generating device keys, issuing one-time challenges, verifying attestation on the server, and processing subsequent assertions. The commonality is that evidence is ultimately validated by the server.

These mechanisms have clear boundaries. Play-related signals are influenced by distribution sources, device status, and service conditions; Apple documentation notes that App Attest is not supported on all device types and that no single policy eliminates all fraud. The server must distinguish between pass, fail, unavailable, transient errors, and unconfigured states. It should not equate 'unavailable' directly with an attack, nor should it perform final judgments locally on the client.

Integrity signals and model encryption address different problems. The former helps verify application instances and runtime environments, while the latter reduces static model exposure. True authorization still requires account context, business resource checks, version validation, request content analysis, quota enforcement, and behavioral context.

Validating Mobile AI Applications Requires Static, Runtime, and Server-Side Views

Static checks answer what models, configurations, strings, credentials, and debug resources exist in the installation package; runtime checks answer how models are loaded, how failures are handled, whether logs leak data, and if updates can roll back; server-side checks answer whether account, version, integrity, quota, and data permissions are truly enforced. Missing any of these three evidence types biases conclusions toward partial views.

Testing must use unique release candidates and explicit model versions, documenting target systems, device capabilities, runtime backends, model sources, and update states. On-device inference performance, memory usage, and compatibility depend on model structure, quantization, hardware, and runtime; figures from other models or devices cannot be cited.

Exception paths are critical: missing or corrupted model files, interrupted updates, unsupported runtimes, expired server tokens, unavailable integrity signals, failed log uploads, and revoked user permissions. The system must degrade safely, providing recoverable states for both users and operations teams.

Design Conclusions and Scope Limitations

Model encryption is worthwhile, but it represents only one control point within the model lifecycle. Commercial AI apps also need to protect pre/post-processing logic, prevent long-lived high-privilege keys from entering the client, ensure the server performs final authorization, implement fault tolerance for platform integrity signals, and govern user data and logs.

Without actual release candidates, model versions, target devices, and server-side interfaces, we can only review architecture and pending validation items. We cannot claim models are extraction-proof, interfaces are abuse-proof, runtime injection is blocked, or performance targets are met. Any such conclusions require current evidence packages.

The action entry point for Yudun on this page is for applying for application hardening and compatibility assessment; it does not represent validation of any specific model framework or AI-exclusive capability. Project scope must be confirmed separately after submitting the tech stack, model delivery method, and critical business paths.

• Maintain separate registers for models, runtimes, credentials, and data
• Ensure high-risk invocations are finally authorized by the server
• Provide unavailable and degradation paths for platform signals
• Enable model updates to support verification, atomic switching, and rollback
• Bind all conclusions to specific release candidates and model versions