What 282 leaking iOS AI apps say about secrets in mobile apps

At the end of last week, researchers at Wake Forest University published a study that should make any mobile engineer wince. They pointed a traffic-watching tool at 444 AI chatbot apps on the iPhone and found 282 of them, close to two in three, handing out the keys to their own AI. Some shipped a plaintext API key. Some issued a token that never really expired. Some ran a backend that answered anyone who knew the address.

I run engineering at a mobile security company, so this one filled my inbox fast. The headline says "AI apps", and that is what got the clicks. Strip the AI off it and you are looking at the oldest finding in the field: a secret shipped inside an app that runs on a phone you do not own. AI did not create this problem. It gave a lot of teams a fresh reason to make it, all in the same quarter. Here is what the study found, why it keeps happening, and the short list I run against our own builds.

What the study actually found

Take the facts as reported before drawing lessons from them. The work comes from Wake Forest University and was written up by The Hacker News on 30 June 2026. The researchers built a tool they call LLMKeyLens that watches an app's network traffic and reads the credentials as they pass by. No jailbreak, no cracking the binary open. They ran it against 444 AI chatbot apps and 282 of them leaked.

The leaks fell into three shapes.

One more detail is worth keeping. Of the 54 apps leaking a plaintext key, 28 also exposed the hidden system prompt behind the product. And three months after the researchers warned the developers, only about 28 percent had clearly fixed it. Close to a quarter were still wide open.

An old mistake in new clothes

Here is the part that matters more than the AI angle. A key shipped inside a mobile app has been the number one finding in this field for as long as the field has existed. We wrote up finding hardcoded secrets because it is the single most common serious result in a real scan queue. The lesson never changed. What changed is the reason people ignore it.

A few years back the key in the app was a maps key or an analytics token. Annoying, sometimes costly, rarely fatal. Now it is a key to a metered AI service that bills by the request. The blast radius grew. A leaked LLM key is a running meter someone else controls, and the bill lands on you. A mistake that used to be a low-severity note is now a finance problem with your name on it.

The other thing AI changed is speed. Every team wanted a chatbot in the app this year, and the fastest way to ship one is to paste the provider key into the client and call the API straight from the phone. It works in the demo. It ships. And it leaks, all across the same quarter, which is why one study can find 282 of them at once.

They found it by watching traffic. So can you.

The method in this study is the part I want engineers to sit with. The researchers did not have the source code. They did not need it. They watched what the apps sent over the network and the secrets walked right out.

That is exactly how an attacker works, and exactly how a scanner works. You do not test the app you think you built. You test the app that ships, the same file and the same traffic a stranger sees. A plaintext key in a request shows up in a dynamic pass with a proxy in the middle. A key baked into the package shows up in a static pass. A replayable token shows up when you take a captured token, send it again a week later, and it still works. None of this needs the developer's cooperation, which is the whole point.

If watching an app's traffic for half a minute can pull out a live key, then a review that only reads your backend code was never going to catch it. The secret is not on the server. It is on the wire and in the file.

What I check in our own build

When a study like this lands, I do not forward it as a scare. I turn it into a checklist and run it against our own apps first. Here is that list, in the order I care about.

• No provider key in the client, ever. The researchers' own advice is the whole answer: do not put the key in the app, route AI calls through your own server. The app talks to your backend, the backend holds the key and talks to the AI provider. That one move kills the plaintext-key case outright.
• Make tokens short and checkable. If the app carries a token, give it a real expiry measured in minutes, bind it to a user and a device, and verify it on the server every time. A token that lasts until 2125 is not a token, it is a key with extra steps.
• Lock the proxy. Your backend endpoint is not private just because it is undocumented. Require authentication on every route, rate-limit per user, and watch for a single token driving a strange amount of traffic. An open relay is a bill waiting to happen.
• Know which SDKs move data. AI features often arrive inside a bundled SDK that sends data to an endpoint nobody on the team reviewed. Keep an inventory, know what each one sends and where, and make the privacy notice match the code. This is the shadow-AI problem, and it hides in the supply chain.
• Kill cleartext. Everything over TLS, certificate checks left on, and no debug flag that quietly turns them off. A key sent over plain HTTP is a key handed to anyone on the same network.
• Rotate what already shipped. If a key ever lived in a released build, treat it as burned and rotate it. The old version stays on phones and stays exploitable until every user updates, and many never do.

Then I check that each of these holds on the build we actually ship, not the one on a developer's laptop, and I check it again next release. A control that was true three versions ago is not a control today.

Where this maps on OWASP MASVS and the Mobile Top 10

If you answer to a board or an auditor, this lines up cleanly with the frameworks they already know, which helps when you ask for the time to fix it.

• Improper credential usage. A key or long-lived token in the client is the textbook case of the first risk on the OWASP Mobile Top 10, M1. It also lands on the MASVS requirements for how an app stores and uses credentials.
• Insecure communication. A secret readable in traffic is M5, insecure communication, and the matching MASVS network checks. The fix is TLS everywhere and validation you did not weaken.
• Inadequate supply chain security. An AI SDK that carries or leaks a credential is M2. You own the risk of every library you bundle, whether you wrote it or not.

We broke these categories down in mobile app security findings by category if you want the wider picture. The point of the mapping is not paperwork. These are known, named problems with known fixes, not a new kind of danger that arrived with AI.

The takeaway

The headline was about AI apps, but the finding is about secrets, and secrets in mobile apps are a solved problem that teams keep re-opening. The researchers put the fix in one sentence: do not put the key in the app, route the call through your own server. Everything else on my list is there to catch the cases where someone did it anyway.

Watch your own traffic before someone else does. Pull apart the build you ship, look for a key or a token in the request, send that token again a week later and see if it still works, and knock on your own backend with no key to see if it answers. If any of that turns something up, you found it on your terms. A scanner built for mobile apps, Mobexa included, runs these as standard checks and maps each finding to the OWASP MASVS control behind it, so a leaked key comes back as a fixable line item rather than a news story with your app in it. One note on method: only test apps you own or are authorised to test. The goal is to find your own weak spots before someone else makes them your problem.

Common questions