Zero secrets architecture is becoming essential for mobile API security

At a glance

What this is: Approov says mobile app checklists are not enough because embedded secrets, static pinning, and client-side trust assumptions fail under hostile runtime conditions.

Why it matters: For IAM and NHI practitioners, the key issue is that mobile apps often become secret-distribution channels, so governance has to shift toward runtime attestation, short-lived tokens, and backend enforcement.

Context

Mobile application security is not just about hardening code. The core governance gap is that mobile apps execute on devices the enterprise does not control, which makes static assumptions about secrets, integrity, and trust unreliable. In practice, that means API keys, tokens, and attestation signals have to be treated as runtime control problems rather than build-time checklist items.

The article frames a broader shift from protecting binaries to governing how mobile clients obtain and use credentials. That has a genuine identity angle because mobile apps, APIs, and LLM integrations increasingly rely on machine credentials and short-lived authentication artefacts. Once those artefacts are exposed client-side, the control boundary moves to issuance, attestation, and backend validation.

Approov's starting position is typical of modern mobile ecosystems: the app is not the trusted perimeter, and the device is not the control plane.

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 embedded mobile credentials increase backend risk even when user login is protected?

A: User login only authenticates the person, not the app instance or device state that sends the request. If the mobile client can expose a token or API key, an attacker can bypass the intended user journey and automate direct calls to backend services. That turns a legitimate login into reusable infrastructure access.

Q: What signs show that mobile runtime protection is failing?

A: Common warning signs include successful debugging on protected builds, altered integrity results, repeated abuse of login or approval flows, and suspicious activity that appears after the app is launched but before a backend control sees it. If the app keeps running normally in hostile conditions, the shielding layer is not enforcing meaningful limits.

Q: How should teams govern mobile API access when a token broker or proxy is involved?

A: Treat the broker as an enforcement point, not a trust shortcut. If the broker cannot verify the app, device, and runtime state before releasing credentials, it simply relocates the exposure. The governance model should require attestation-bound issuance, fail-closed API validation, and short-lived credentials that cannot be reused broadly.

Technical breakdown

Why obfuscation and embedded secrets fail on hostile devices

Code obfuscation only raises attacker effort when the secret remains in the client. Modern reverse engineering, including AI-assisted decompilation and traffic interception, can recover patterns, keys, and control flow from mobile binaries far faster than traditional methods. If a credential or token exists in the app package, the attacker only needs time, tooling, and a way to observe runtime memory or traffic. That is why obfuscation is a delaying tactic, not a trust mechanism.

Practical implication: Treat any client-side secret as recoverable and remove it from the mobile binary entirely.

How runtime attestation and JIT delivery change the trust model

Runtime attestation shifts the control point from code concealment to state verification. The device and app must prove they are legitimate before the backend or secret broker releases a credential, and just-in-time delivery keeps that credential only in volatile memory for the brief period needed to complete the request. That reduces the replay window and makes extracted secrets far less durable. In identity terms, this is closer to conditional issuance than static authentication.

Practical implication: Require attestation before issuing any credential or token that the mobile app can use.

Why mobile API security now depends on backend enforcement

Mobile API security fails when the backend trusts the client to self-certify. OAuth, MFA, and user authentication prove a person logged in, but they do not prove the request came from the genuine app, on a clean device, with a valid runtime state. Fail-closed gateway checks enforce the opposite assumption: no attestation, no processing. This is a governance problem as much as a technical one, because the API becomes the real policy enforcement point.

Practical implication: Move enforcement into API gateways and reject any request that lacks a valid attestation token.

Threat narrative

Attacker objective: The attacker wants to turn a mobile app's embedded trust assumptions into reusable access to backend APIs, credentials, and costly AI services.

1. Entry occurs when an attacker targets a mobile app running on an untrusted device and uses reverse engineering, traffic interception, or instrumentation frameworks to inspect runtime behaviour.
2. Credential access follows when embedded API keys, LLM tokens, or other client-side secrets are extracted from the binary or memory despite obfuscation.
3. Escalation and abuse happen when those credentials are replayed against backend APIs, allowing scripted bot activity, LLM account hijacking, or direct use of exposed services.
4. Impact is unauthorised consumption of APIs and AI budgets, plus potential data exposure or fraud at scale.

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.
• Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.

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

Zero Secrets Architecture is the correct response to client-side trust collapse. Mobile apps that carry long-lived credentials are not protected by obfuscation in any meaningful governance sense, because the control boundary sits inside an attacker-controlled environment. The article's central point is that the secret itself has become the liability, not merely the code that contains it. Practitioners should treat this as a machine-identity problem, not a packaging problem.

Mobile app attestation now functions as a credential issuance gate. Once a client can prove runtime integrity, the backend can issue short-lived tokens or secrets with much narrower blast radius. That changes the governance model from static entitlements to conditional, session-scoped trust, which is closer to how modern NHI control should work. Teams that still issue reusable client-side credentials are carrying avoidable exposure.

API gateways are becoming the real policy boundary for mobile identity. OAuth and MFA authenticate users, but they do not authenticate the application instance or device state that is actually making the request. The stronger pattern is backend validation of attestation before any business logic runs. This is where mobile security, IAM, and NHI governance intersect most clearly, and practitioners should align API controls to that boundary.

Proxy-less isolation reduces one attack path but does not remove the governance requirement. Moving secrets to a broker or proxy can still leave a new abuse surface if the proxy accepts unauthenticated or weakly attested requests. The control problem is not where the token is stored, but whether issuance is bound to verified runtime state. Practitioners should evaluate every brokered path as an identity decision point, not a transport convenience.

From our research library:

• DeepSeek alone generated 113,000 new exposed API keys in 2025, illustrating how new AI providers create credential exposure before security guardrails catch up, according to the State of Secrets Sprawl 2026.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
• Read next: API Key Management Guide

What this signals

Mobile secret governance now has to assume automated extraction. If AI-assisted tooling can de-obfuscate binaries quickly, then build-time secrecy controls no longer define the risk boundary. Practitioners should respond by moving secrets out of the client, enforcing runtime attestation, and treating every mobile credential as a controlled issuance event rather than a stored asset.

API protection for mobile apps is increasingly an identity problem. The hard question is not whether the user authenticated, but whether the app instance deserves to receive a token at all. That distinction will matter more as mobile apps, third-party SDKs, and LLM integrations expand the number of places where reusable credentials can leak.

Credential exposure in AI-enabled apps is already at industrial scale: DeepSeek alone generated 113,000 new exposed API keys in 2025, according to the State of Secrets Sprawl 2026. That scale shows why client-side secrets and static trust controls are no longer a sustainable governance model.

For practitioners

• Eliminate client-side long-lived secrets Remove API keys, LLM tokens, and other reusable credentials from mobile binaries and shift them to cloud-managed runtime secret services.
• Bind credential release to runtime attestation Require attestation from the app and device before issuing any secret or token, and keep the credential valid only for the current request or session.
• Fail closed at the API gateway Drop requests that lack a valid, current attestation token before application logic executes, rather than allowing the backend to decide later.
• Monitor for instrumentation and tampering signals Alert on Frida, Magisk, Cydia, Xposed, emulator use, signature changes, and invalid pin or attestation results as indicators that the client runtime cannot be trusted.
• Rotate pins and tokens without app-store dependency Use dynamic certificate pinning and backend-controlled secret rotation so operational changes do not depend on waiting for a new mobile release.

Key takeaways

• Mobile checklists miss the core issue because apps run in hostile environments where embedded secrets and static pinning can be extracted or bypassed.
• The control shift is from hiding credentials in code to issuing them only after runtime attestation proves the app and device are trustworthy.
• Backend gateways, not client binaries, should enforce whether a mobile request is allowed to access sensitive APIs or LLM services.

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.
• Just-in-Time Secret Delivery: Just-in-time secret delivery provides a credential only when a task needs it, then limits further reuse. In NHI and agentic environments, this reduces standing exposure and makes access more task-scoped, which is critical when tools or agents can reuse secrets instantly.

Deepen your knowledge

NHI Mgmt Group's NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security and identity practitioners turn runtime trust into a governed control model.