Mobile security used to be a fairly well-mapped problem: store secrets in the keystore, pin certificates if you're serious, validate on the server, don't trust the client. AI features don't replace any of that — they add a new layer on top of it, with failure modes that most mobile security checklists were never written to catch.
I came to this from a cybersecurity background before I came to it from mobile, and the combination changes how I architect AI features. Here is what I actually worry about, in rough order of how often teams get it wrong.
The number one mistake: model keys in the binary
The single most common AI-on-mobile security failure is shipping a model provider API key inside the app.
A mobile binary is not a secret. Anyone can pull the IPA or APK off a device, unzip it, and grep for strings. An embedded provider key is an embedded liability: it can be extracted and used to run up your bill, exfiltrate data, or abuse the provider under your account.
The fix is structural, not cosmetic. Put your own backend in front of every model call. The app authenticates to your API with a short-lived user token; your server holds the provider key and makes the upstream call. The key never touches the device.
This also draws a clean line between two kinds of keys:
- Publishable keys are fine on the client. Auth-provider publishable keys, billing SDK app keys, analytics project keys — these are designed to be public and are safe in the bundle.
- Secret keys are not. Model provider keys, storage-gateway secrets, anything that grants privileged server-side capability must live behind your authenticated backend.
If you remember one thing from this article: audit your client config for secret keys, and proxy anything that isn't explicitly publishable.
Secrets at rest belong in the keystore
Auth tokens, refresh tokens, anything sensitive that persists between launches goes in the platform secure store — Keychain on iOS, Keystore on Android — never in general key-value storage.
It is genuinely easy to get this wrong, because the convenient default for app state (an async key-value store) is plaintext on disk. The discipline is to route the sensitive slice of state through a secure-store adapter while ordinary preferences use the normal store. Most managed auth SDKs back their token cache with secure storage automatically; confirm yours does, and don't hand-roll a token cache that doesn't.
What leaves the device, and saying so honestly
A cloud AI app cannot truthfully claim "your data never leaves your device" — the model lives in the cloud. Pretending otherwise is both a trust problem and, increasingly, a compliance one.
The honest posture is specific:
- Keep what can be local, local. Profiles, logs, history in the on-device database.
- Be explicit that AI features use secure cloud services, and scope exactly what's sent: the message and a bounded context payload, not your entire local dataset.
- Mind the context you assemble. The personalization payload you build for each request is data leaving the device — keep it minimal and intentional, not a kitchen-sink dump of everything you know about the user.
Privacy copy that names the real boundary builds more trust than a comforting falsehood that a curious user can disprove.
Prompt injection is a mobile problem too
Prompt injection is usually framed as an agent or web problem, but it reaches any app where untrusted content can flow into a model prompt. On mobile that includes user-generated text, OCR'd documents, content pulled from a URL, transcribed audio — anything that ends up concatenated into the context you send.
The mobile-relevant defenses:
- Treat assembled context as untrusted input, even when it originated on-device. Validate and bound it.
- Keep the system prompt and safety rules server-side, out of reach of anything the client or the user can manipulate.
- Don't let model output drive privileged actions unchecked. If a response can trigger a tool, a deep link, or a state change, validate it server-side before acting — the model's text is a suggestion, not an authorization.
Backend-authoritative trust
The deepest principle is one that predates AI: the client cannot be the source of truth for anything that matters.
This shows up sharply in entitlements. If the app decides locally whether the user is "premium" and unlocks features accordingly, that decision can be spoofed by a patched build. The correct model is that the backend is authoritative — it verifies purchase state server-side and enforces access at the API. The client's feature gates are cosmetic; the real lock is on the endpoint. A locked capability returns a 403 from the server, regardless of what the app thinks.
The same logic governs AI capability: a free user shouldn't reach a premium model just because they edited a local flag. Enforcement lives where the request is served.
Token hygiene
Long-lived tokens are a long-lived risk. The pattern that works well on mobile:
- Short-lived JWTs minted from a dedicated template scoped to your backend.
- Centralized retrieval through a single token manager, so every request gets a fresh token the same way.
- A
fetchWithAuthwrapper that, on a401, refreshes once and retries — which transparently handles the extremely common "token went stale while the app was backgrounded for hours" case without bouncing the user to a login screen.
A short, honest checklist
For any AI-powered mobile app, I want to be able to answer these:
- Are there any secret keys in the client bundle? (There should be none — proxy them.)
- Are auth tokens in the keystore, never in plaintext storage?
- Is every model call authenticated to our own backend, which holds the provider key?
- Is the context payload minimal and intentional, and is our privacy copy honest about it?
- Is untrusted content treated as untrusted before it reaches a prompt?
- Is every entitlement and capability enforced server-side, with the client gate merely cosmetic?
- Are tokens short-lived, centrally retrieved, and refreshed-and-retried on
401?
None of this makes the product slower to build if you design it in from the start. Bolting it on after launch is where it gets expensive — which is the real argument for treating security as architecture, not as a later checklist.