LLM API credential leakage in iOS apps exposes mobile AI risk

At a glance

What this is: This study shows that many LLM-enabled iOS apps leak usable API credentials, with insecure mobile integration patterns leaving secrets exposed in traffic and client code.

Why it matters: It matters because mobile AI features often depend on secrets, tokens and backend trust decisions that identity teams must govern as part of broader NHI and API access control.

By the numbers:

• 64% of 444 iOS applications with confirmed LLM functionality exposed exploitable LLM API credentials in network traffic.
• Only 28% of the applications had successfully remediated the vulnerability three months later.

Context

Mobile AI features often create a secret-handling problem before they create a model-risk problem. When an app must call an external LLM service, the real governance question becomes where credentials live, how they are proved at runtime, and whether the client ever holds reusable secrets.

The study described by Approov shows that many mobile teams still rely on static tokens, backend proxies, or obfuscation to protect LLM access. That is an atypical control posture for a high-exposure integration point, and it leaves identity, access, and API governance too weak for the threat surface.

Key questions

Q: What breaks when mobile apps still store reusable API keys or tokens on the client?

A: The control fails because the client no longer owns a trustworthy execution environment. Once a secret lives in the app binary or memory, an attacker can extract it through reverse engineering, instrumentation, or traffic analysis and then replay it outside the app. At that point, authentication shifts from proving app legitimacy to merely proving the secret was recovered.

Q: Why do backend proxies still fail to protect LLM credentials in apps?

A: A proxy only helps if the app-to-proxy trust step is strong. If the mobile app presents a static token, weak session secret, or other replayable credential to the proxy, the attacker simply steals that next credential instead of the provider key. Without attestation and short-lived issuance, the proxy becomes another place to harvest trust.

Q: How should security teams handle exposed secrets in AI-driven environments?

A: Security teams should treat exposed secrets as active access paths and respond as though misuse can begin immediately. The right sequence is to identify the owning NHI, revoke the credential everywhere it is trusted, check downstream dependencies, and then validate whether the secret was copied into collaboration or CI systems.

Q: Should organisations use certificate pinning instead of secret rotation for mobile AI access?

A: No. Certificate pinning and secret rotation solve different problems. Pinning protects the transport path from interception, while rotation reduces the lifetime of a leaked secret. For mobile AI access, both are useful, but neither is enough on its own if the app still contains a reusable credential that can be extracted and replayed.

Technical breakdown

Why static API keys fail in mobile LLM integrations

A static API key in a mobile app is effectively a reusable bearer credential embedded in hostile territory. Once the app is installed, the attacker can inspect code, instrument the runtime, or intercept traffic and recover the credential, then replay it against the LLM provider or backend proxy. Proxy architecture does not remove the problem if the proxy itself accepts weak client authentication, because the attacker simply targets the next reusable trust token in the chain. The core flaw is credential reuse outside a trusted execution boundary. See the API Key Management Guide.

Practical implication: Treat any client-side reusable credential as compromised by design and remove it from the mobile trust model.

How backend proxies still leak trust

A proxy can reduce direct exposure to an upstream provider, but it does not solve authentication if the mobile app still presents a long-lived token, weak session secret, or predictable client assertion to reach that proxy. In that case, the proxy becomes the new control point that attackers harvest. The article's key technical point is that hiding the provider key behind another service does not help when the app-to-proxy trust relationship is itself static and replayable. Stronger design requires proof of app integrity and short-lived issuance, not just indirection. See the NHI Authentication Guide.

Practical implication: Move from proxy-based concealment to runtime-verified access issuance before any backend call is authorised.

What zero secrets architecture changes for runtime trust

Zero secrets means the mobile app does not retain long-lived secrets that can be stolen and reused later. Instead, the application proves itself at runtime, the device state is checked, and only then are short-lived credentials or headers delivered for a specific transaction. This pattern shifts security from secret storage to secret issuance. In practical terms, attestation, device integrity, and ephemeral credential delivery become the control stack, while certificate pinning helps protect the transport path from interception and tampering. The architectural goal is to make credential theft unprofitable because nothing durable is present to steal. Read the Ultimate Guide to NHIs: Static vs Dynamic Secrets.

Practical implication: Design mobile AI access so that every request is conditionally issued, not permanently trusted.

Threat narrative

Attacker objective: The attacker wants to reuse stolen mobile AI credentials to consume LLM capacity, steal prompts or data, and abuse the victim's backend trust relationships.

1. Entry occurs when attackers inspect mobile app code, instrument the runtime, or intercept traffic to recover embedded LLM credentials.
2. Credential access follows through leaked JWTs, plaintext API keys, or unauthenticated proxy tokens that can be replayed against the service.
3. Impact comes when the stolen credentials are used to run unauthorized LLM queries, shift usage cost, or reach sensitive backend data.

Breaches seen in the wild

• Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.
• 12,000 secrets in LLM training data: Truffle Security found 11,908 live API keys and passwords hard-coded in web pages captured by Common Crawl, a dataset used to train LLMs.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Mobile AI access is becoming an NHI governance problem, not just an app security problem. Once a mobile client carries a reusable API key or token for an LLM service, that secret functions as a non-human identity credential with all the lifecycle burdens that implies. The issue is not simply whether the code is obfuscated but whether the credential can be discovered, replayed, and governed across issuance, use, and revocation. Practitioners should treat mobile AI integrations as part of the NHI estate, not as isolated app logic.

Proxy-first designs create a false sense of separation between the app and the credential. The article's findings show that unauthenticated or weakly authenticated proxies do not remove trust, they merely move it. Once the proxy accepts a static client secret, the real failure mode is credential replay at the mobile boundary, which aligns with API key management concerns more than with ordinary front-end hardening. Practitioners should focus on who can mint, present, and reuse the credential, not on where the key is stored.

Zero Secrets is a control model for hostile clients, not a branding phrase. The practical value lies in replacing durable secrets with attestation-based, short-lived issuance that only exists after device and app integrity checks pass. That makes the access decision depend on runtime trust rather than on a hidden string that can be extracted later. For identity teams, this is the difference between credential custody and credential governance.

LLM credential leakage shows how quickly AI adoption can outpace governance. The article's mix of exposed keys, proxy failures, and slow remediation is the signature of a programme that added AI capability before defining a governed secret path for it. The discipline gap is not limited to mobile developers; it spans IAM, API governance, and the teams responsible for secrets lifecycle. Practitioners should assume every AI feature request creates a new identity dependency unless proven otherwise.

Certificate pinning and runtime attestation belong in the same control conversation. Transport protection matters, but it does not compensate for a stolen credential or a rooted device. The better model is layered trust: verify the app, verify the device, then verify the channel before any short-lived secret is issued. That gives security teams a concrete way to bound trust in environments where client-side secrets are otherwise impossible to defend.

From our research library:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
• 54% of ransomware victims had credentials exposed before the attack, according to Verizon's 2025 Data Breach Investigations Report.
• Read next: Leaked Credential and Secret Incident Response Playbook

What this signals

Mobile AI teams need a credential-first architecture, not an app-first one. The relevant decision is no longer whether an app can call an LLM service, but whether that call can be authorised without placing a reusable secret on the device. That shift pushes identity governance into the request path and makes issuance controls more important than hidden configuration.

Secret sprawl in AI-enabled mobile apps will keep widening unless governance moves upstream. Approov's cited study shows how quickly exposed credentials appear when developers optimise for feature delivery first and trust assumptions later. The control lesson is that mobile AI access needs policy, attestation, and secret lifecycle design before the first production build ships.

LLM credential leakage is now a measurable identity risk surface. The broader pattern is consistent with the wider secrets problem in software delivery, and the exposure rate makes it hard to treat as an edge case. Security teams should expect AI enablement to increase the number of credentials they must inventory, issue, and revoke.

For practitioners

• Remove durable secrets from mobile clients Replace embedded API keys and reusable tokens with short-lived, conditionally issued credentials that are never stored in the app package. Read the Ultimate Guide to NHIs: Static vs Dynamic Secrets.
• Enforce app and device attestation before issuance Require runtime proof that the app is genuine and the device is uncompromised before any backend or LLM credential is delivered.
• Audit proxy-based AI integrations for weak client trust Review backend proxy patterns for static tokens, unauthenticated calls, and replayable session secrets that let attackers bypass the intended separation.
• Rotate exposed LLM credentials and revoke unused grants Treat any discovered mobile secret as compromised, revoke it immediately, and replace it with a new issuance path that does not persist in client code.
• Adopt certificate pinning with managed updates Use pinned trust for mobile API traffic, but manage pin changes centrally so emergency certificate handling does not create a new operational blind spot.

Key takeaways

• LLM-enabled mobile apps can expose reusable credentials even when developers believe a proxy or obfuscation layer is enough to protect them.
• The study's scale shows that leaked mobile secrets are not edge cases, and slow remediation leaves the same exposure patterns active for months.
• The strongest control shift is to remove durable secrets from clients and issue short-lived credentials only after runtime trust checks pass.

Related NHI Mgmt Group resources: Guide to the Secret Sprawl Challenge · Ultimate Guide to NHIs: Static vs Dynamic Secrets · API Key Management Guide · Leaked Credential and Secret Incident Response Playbook

Key terms

• Zero-Secrets Architecture: Zero-secrets architecture is a design approach where the client does not store durable secrets that attackers can extract and reuse. It shifts trust to runtime controls, ephemeral credentials, and back-end verification so that compromise of the app binary does not automatically expose lasting access.
• Runtime Attestation: Runtime attestation is a control that cryptographically proves a request came from the expected system or workload. It adds evidence to machine-to-machine access decisions, which is especially valuable when bearer tokens alone cannot distinguish a real integration from an attacker replaying credentials.
• Certificate Pinning: A trust control that restricts a client to a specific certificate authority, public key, or certificate for a given connection. It can reduce exposure to unexpected certificates, but it also makes trust changes harder because the client may reject valid replacements after rotation or revocation.
• Secrets Leakage: Secrets leakage is the exposure of credentials such as API keys, tokens, or certificates in places where they can be discovered and reused. The risk is not just disclosure, but unauthorized authentication that turns a coding or pipeline mistake into active access.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity and secrets management. It is suitable for practitioners who need to connect mobile AI access decisions to identity, access and lifecycle controls.