Almost two-thirds of iPhone apps with IA display payment keys and can generate millionaire bills

A recent study of Wake Forest University researchers shook the idea that iPhone apps that make up large language assistants (LLMs) are secure by default: by analyzing 444 applications, they found that 282 - almost two thirds - somehow exposed the payment access to models in their network traffic. This is not an isolated academic finding, but a practical warning: flat text keys, reusable tokens or intermediate servers that accept any request allow third parties to run models with the developer's account and for the key owner to receive the invoice.

What makes this problem particularly disturbing is the simplicity of the attack. The team used a tool of its own, LLMKeyLens, to observe the outgoing traffic and extract credentials without the need for jailbreak or complex reverse engineering: it was enough to capture packages and read what the app sent. The operating vector is pure unsafe design: To embed secrets in the mobile client or not to validate who calls the backend exposes a paid and revocable access by default.

The findings show three recurring patterns. A group sent the key in clear text and the same request sometimes included the system prompt hidden that defines the personality of the assistant; another group trusted unauthenticated servers that acted as open retransmitters; and the third hand over temporary tokens that, even so, leaked with traffic and often remained valid. In several cases the tokens never expired with practical meaning - one was in 2125 - or persisted long after what was expected.

The consequences go beyond a technical rush: there is a direct risk of economic abuse, known as LLMjacking, where attackers use stolen credentials to consume API and generate millionaire bills in a few days. There is also reputational and privacy damage when prompts and conversations are leaked, which can affect users using health, productivity or finance apps.

For developers the recipe is old but not applied: never store secret keys on the client. Instead, calls to model providers must pass through a server of their own that autentifies users, applies limits, registers activity and can rotate or revoke credentials as soon as you detect abnormal use. In addition, it is appropriate to issue tokens with the lowest possible scope and life, and to program automatic rotation. Best practice documents for the management of APIs credentials and security such as those of OWASP and the same suppliers are useful resources: OWASP API Security Project and the security recommendations of OpenAI in official documentation.

Beyond architecture, there are crucial operational measures: enable unusual-use alerts on the model provider panel, set budgets and spending limits, record and monitor calls by key and source, and automate the revocation of compromised keys. Cloud suppliers also offer controls to restrict the use of keys by IP direction or by reference; taking advantage of these policies reduces the attack surface. Google Cloud and other suppliers document concrete practices to protect API keys in your guides.

End users can also act: prefer developer apps that publish clear policies on how they use and protect IA APIs, review ratings and reputation, and pay attention to abnormal permissions and behavior. If you are affected developer, consider it a priority to rotate exposed keys, inform users if there was a risk of data leakage and publish a public mitigation plan; transparency is key to regain confidence.

The platforms have a critical role to play. Apple could expand the review process controls and provide automated scans that detect traffic or binary key sending patterns, as well as require minimum safety practices for IA integration. For their part, model providers should clearly mark their documentation and consoles when a key is issued for customer use and restrict hazardous capabilities by default, as well as warning about mass and unusual uses.

This problem is not new in essence: previous and broader Android audits already showed that developers tend not to revoke keys or put controls. The difference now is the cost of abuse: each token used by a LLM represents real expenditure. The practical lesson is direct: security and design must go ahead of rapid integration, because a filtered credential is not just a technical vulnerability, it is a line that connects billing, privacy and trust.

If you are technical responsible for a mobile app, act today: remove customer secrets, redesign the flow to pass through an authenticated backend, implement monitoring and alerts in the supplier and implement key rotation and revocation. Industry has to change the inertia of "it works now, then we park" towards a discipline where protecting access to models is part of the development cycle. Without that change, we will continue to see research that shows the same thing again: open doors where they should not exist.