Here is a familiar moment for mobile developers: you get an AI-powered feature working in an afternoon, and then you reach the part where the app needs an API key.
You know you should not ship an OpenAI, Anthropic, or Gemini key inside the app. The standard advice is to put it on your backend instead.
Reasonable advice—if you have a backend.
Many independent developers and small mobile teams do not. Building and operating a server just to protect one API key can turn a promising app feature into an infrastructure project.
New research shows why mobile developers need a better option. A team studying 444 iOS apps with working LLM features found that 282 exposed access that could be used to make unauthorized AI requests.
That is 64% of the apps they tested.
The researchers did not need to crack the apps open
The paper, “Mind your key: An Empirical Study of LLM API Credential Leakage in iOS Apps”, analyzed apps collected from the US App Store and tested their AI features on physical iPhones.
The researchers did not need source code or a decrypted app binary. Their LLMKeyLens system observed app traffic, identified provider credentials and backend endpoints, and sent one small, benign request to determine whether the captured access worked outside the app.
The exposed apps followed three patterns.
Fifty-four apps sent LLM provider credentials from the phone. OpenAI keys were the most common, followed by Gemini and other providers. If an app can read a billable provider key and attach it to a request, someone controlling the device can eventually observe it too. Obfuscation may slow that person down, but it cannot turn a shipped secret into a safe secret.
Another 92 apps called backend proxies that did not authenticate the caller. Those developers had moved the provider key off the phone, but anyone who discovered the endpoint and request format could still use the developer’s LLM account.
The largest group—136 apps—used JWTs or bearer tokens that could be replayed. Some implementations omitted expiration claims, accepted expired tokens, or issued tokens with lifetimes as long as 100 years.
Mobile developers are being offered two bad choices
The first choice is to ship the provider key in the app. It is fast, and it gets the feature into TestFlight, but the key can be extracted and used by someone else. The developer receives the bill.
The second choice is usually summarized as “just build a backend.” But a responsible backend for mobile AI needs more than a single proxy endpoint.
It needs somewhere safe to store provider credentials. It needs a way to decide which app installations may call it. It needs short-lived authorization, replay protection, rate limits, usage budgets, logs, credential rotation, deployments, monitoring, and somebody responsible when it breaks.
That may be reasonable work for a company with an established backend team. It is not a small prerequisite for an iOS developer who wants to add summarization, image analysis, or a chat feature to an otherwise client-side app.
The study makes that gap visible. Some developers took the fast route and exposed a provider key. Others attempted the backend route but discovered that moving the key is only one part of building secure infrastructure.
No backend should not mean no security
There should be a third choice: use a managed service built specifically to sit between a mobile app and its AI providers.
That is what Gate/AI is for.
Your app calls Gate/AI instead of calling the AI provider directly. The provider key stays off the device, Gate/AI decides whether the app installation is allowed to make the request, and usage controls limit how much a device can consume. You add the mobile SDK to your app; you do not build, deploy, monitor, or operate a backend service.
Under the hood, Gate/AI uses platform capabilities such as Apple’s App Attest and Google’s Play Integrity, along with short-lived, device-bound authorization. Those details matter because they make copied tokens far less useful—but they are infrastructure Gate/AI handles, not a new security system the mobile developer must build.
If you want the technical details, our articles on App Attest and DPoP explain how those pieces work. You do not need to implement an authorization server to benefit from them.
Keep building the app
The researchers checked the affected apps again after responsible disclosure. Only 28% showed evidence of remediation after three months. Persistent problems included unauthenticated proxies and token implementations that did not enforce the protections developers expected.
That does not mean mobile developers are careless. It means secure AI infrastructure is a separate discipline, and “just build a backend” hides a surprising amount of work.
Gate/AI exists so a developer can keep provider secrets out of the binary, control AI usage, and ship the feature without taking on that work.
The lesson from 282 vulnerable apps is not that every mobile developer needs to become a backend engineer.
It is that they should not have to.