TL;DR: Agentic AI bots can now adapt attack code in real time, mimic human behaviour, and defeat probabilistic bot controls, according to Approov, which argues mobile API defence now needs deterministic attestation and zero-secrets delivery. Legacy signals are no longer enough when requests must be trusted at issuance, not judged after the fact.
At a glance
What this is: Approov argues that agentic AI bots are outpacing static bot defence by dynamically adapting attack code and evading traditional probabilistic signals.
Why it matters: For IAM and security teams, the shift matters because API trust is increasingly being decided at issuance time, where device integrity, credential delivery, and request legitimacy intersect.
Context
Mobile API defence depends on trusting the client before it reaches the backend, but that trust has traditionally been built on signals that can be copied, replayed, or faked. As automation becomes more adaptive, the gap between what defenders can observe and what attackers can generate keeps widening.
The practical problem is not just bot volume, but bot quality: adversaries now use model-driven behaviour to look legitimate long enough to consume APIs, abuse credentials, or imitate user interaction patterns. That makes request trust a governance problem as much as a detection problem.
Where mobile apps expose secrets or rely on weak client verification, the attacker starts with an advantage that classic bot mitigation cannot fully remove.
Key questions
Q: What breaks when mobile API defence relies on behavioural bot detection alone?
A: Behavioural-only defence fails when the attacker can mimic human timing, fingerprints, and request patterns well enough to stay inside the normal range. The result is delayed detection, not prevention. Teams need to move the trust decision earlier, to attestation and issuance, because once a request looks legitimate enough, a probabilistic control may no longer have a safe basis to deny it.
Q: When should security teams prioritise device attestation over more bot signatures?
A: Prioritise attestation when the client itself can be modified, instrumented, or reverse engineered, because more signatures still rely on pattern recognition. If the request path depends on a mobile binary or embedded credential, proof of app and device integrity gives stronger assurance than another layer of heuristics. Use signatures for telemetry, but use attestation for access decisions.
Q: What are the signs that embedded mobile secrets are no longer safe?
A: Warning signs include reusable tokens in binaries, API calls that succeed from cloned or instrumented apps, and frequent credential abuse that survives normal bot mitigation. If attackers can keep using the same client-side secret after reverse engineering, the secret is acting as a standing access path. That is a governance failure, not just a bad secret.
Q: How do zero-secrets mobile apps change API access governance?
A: They move access governance from the client package to runtime validation. Instead of trusting a secret baked into the app, the platform issues short-lived credentials only after the app proves its integrity. That reduces theft exposure, narrows replay opportunities, and lets security teams revoke trust by changing the issuance policy rather than hunting every copied key.
Technical breakdown
Why probabilistic bot detection is losing ground
Probabilistic bot detection relies on patterns such as fingerprints, network reputation, and behavioural anomalies to estimate whether a request is human or automated. That works when attackers are rigid and noisy, but agentic bots can change tactics, replicate timing, and tune their inputs fast enough to stay inside the expected range. The result is not that signals become useless, but that they stop being trustworthy as a primary control. Once the adversary can generate convincing user-like activity on demand, defenders need stronger proof than similarity scoring.
Practical implication: Treat behavioural scoring as supporting telemetry, not the last line of trust.
What deterministic device attestation changes
Deterministic attestation shifts the question from whether a request looks normal to whether the app and device can prove their integrity. Instead of making a best guess from traffic patterns, the control checks whether the binary, runtime environment, and execution context match the expected state before credentials are issued. This closes the loop between client integrity and API access. It is especially relevant for mobile apps where the binary can be reverse engineered and the client can be instrumented outside the developer's control.
Practical implication: Bind token issuance to attested app and device integrity before any API access is granted.
Why zero-secrets mobile architecture matters
A zero-secrets architecture removes durable credentials from the mobile binary and delivers them only after the app proves itself. That matters because hardcoded or embedded API keys are not merely static secrets, they are reusable access paths that can be extracted through reverse engineering, emulation, or runtime inspection. When credentials are issued dynamically and expire quickly, the attacker loses the advantage of harvesting a reusable token from the client. The control is not just about rotation, but about eliminating the place where the secret can be stolen in the first place.
Practical implication: Move API credentials out of binaries and issue them only to validated runtime instances.
Threat narrative
Attacker objective: The attacker wants to obtain trusted API access from a mobile client without having to present a genuinely verified device or application instance.
- Entry occurs through a mobile client or app binary that contains or can request reusable API credentials.
- Credential access follows when the attacker reverse engineers the binary, extracts secrets, or uses agentic automation to imitate legitimate app behaviour.
- Escalation happens when the attacker can generate convincing requests at scale, bypassing probabilistic controls and consuming APIs as if the client were genuine.
- Impact is sustained API abuse, credential theft, and a higher-risk mobile attack surface that defenders cannot reliably distinguish from real usage.
Breaches seen in the wild
- LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.
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
Agentic traffic is turning request trust into an identity problem. When bots can behave convincingly enough to pass traditional signal checks, security teams are no longer just classifying traffic, they are deciding whether a runtime identity is legitimate. That shifts the control point from detection after connection to proof before token issuance. The organisation that cannot verify the client will keep losing to one that can impersonate it faster.
Probabilistic controls are becoming a lagging indicator of compromise. Fingerprints, behaviour scores, and network reputation still add value, but they cannot be the primary trust gate when adversaries can adapt in real time. This is the same governance failure seen whenever defenders rely on signals that arrive after the attacker has already succeeded. The control gap is not visibility alone, but verification at the point of access.
Zero-secrets delivery is a stronger governance pattern than secret rotation alone. If the credential lives in the binary, the attacker only needs one successful extraction to turn it into a reusable access path. A dynamic model that issues credentials only after attestation collapses the theft window and reduces the blast radius of compromise. In NHIMG terms, this is agent identity governance applied to the client side of the API.
Mobile API security is converging with NHI governance. The app binary, its embedded tokens, and its runtime proof state together behave like a non-human identity, with privileges, lifecycle, and trust boundaries that must be governed explicitly. That makes mobile API defence part of the broader machine identity problem, not a separate bolt-on control. Security teams should treat client attestation and secretlessness as governance primitives, not optional hardening.
Positive security model is the right framing for AI-accelerated abuse. The question is no longer whether enough bad traffic can be recognised, but whether legitimate access can be proven with cryptographic evidence. That is the only defensible posture when the attacker can continuously reauthor its own behaviour. Practitioners should shift policy from suspiciousness scoring to verified eligibility.
From our research library:
- According to PwC, 79% of organizations have already adopted AI agents to some degree.
- Read next: AI Agent Authorisation Guide
What this signals
Request trust is moving from inference to proof: mobile and API programmes that still depend on fingerprints and behavioural scoring will struggle as agentic attackers learn to imitate legitimate activity. The stronger model is to verify client integrity before credentials are issued, then treat telemetry as supporting evidence rather than the trust gate.
The governance lesson is that a mobile app with embedded credentials behaves like a non-human identity with its own lifecycle and privilege boundary. If that identity cannot prove its legitimacy at runtime, the control plane is already behind the attack.
Only 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to the 2026 Infrastructure Identity Survey. That gap matters because agentic abuse will keep pressuring teams to move verification closer to issuance and away from post-event detection.
For practitioners
- Audit the mobile API surface Map every endpoint, every credential path, and every client-side trust assumption so you know where a binary can be reverse engineered or a token can be replayed.
- Remove embedded secrets from mobile binaries Replace hardcoded API keys and tokens with runtime issuance that expires quickly and cannot be harvested from the app package.
- Bind token issuance to device attestation Require cryptographic proof of app and device integrity before issuing credentials, especially where mobile clients call sensitive APIs.
- Treat behavioural controls as supporting evidence Keep fingerprinting and anomaly scoring, but move the trust decision to deterministic checks that can prove client legitimacy before access is granted.
Key takeaways
- Agentic AI bots are eroding the reliability of behaviour-based mobile API defence because they can adapt fast enough to imitate legitimate requests.
- The key control shift is from asking whether traffic looks suspicious to proving whether the client and runtime are trustworthy before access is granted.
- Removing embedded secrets and requiring attestation reduces the attacker’s replay window and gives defenders a stronger access boundary than static bot scoring.
Related NHI Mgmt Group resources: Agentic AI Identity Guide · AI Agent Authorisation Guide · AI Agent Observability, Audit and Incident Response Guide · Agentic AI Security Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, MITRE ATT&CK and OWASP Agentic AI Top 10 define the specific risk controls and attack patterns relevant to this term.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article centres on secrets embedded in mobile binaries and stolen from client-side execution. |
| NHI-04 — Insecure Authentication | The article argues that weak client trust and probabilistic checks are no longer sufficient for API authentication. | |
| NHI-07 — Long-Lived Secrets | Static credentials in binaries create durable replay opportunities that the article explicitly rejects. | |
| Recommendation — Remove embedded credentials from mobile clients and issue them only after integrity checks pass. Replace heuristic client trust with cryptographic attestation before issuing API credentials. Shorten credential lifetime and eliminate durable secrets from the mobile application build. | ||
| MITRE ATT&CK | TA0006;TA0040 — Credential Access; Impact | The attack pattern described depends on extracting and reusing secrets to abuse APIs at scale. |
| Recommendation — Map mobile secret extraction and abuse to credential access and impact tactics in your detections. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agentic bots using stolen or replayed credentials fit the identity abuse pattern described here. |
| Recommendation — Constrain agentic access to verified identities and task-scoped privileges before API use. | ||
Key terms
- Deterministic Attestation: A control that proves a client, app, or device is in the expected state before granting access. Unlike probabilistic detection, it relies on cryptographic evidence and policy checks, making it harder for adaptive attackers to imitate legitimate behaviour long enough to receive credentials or reach protected APIs.
- 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.
- Positive Security Model: A positive security model allows only known-good behaviour and blocks everything else. In API programmes it is often implemented through schemas or allowlists, but that approach only works for what can be explicitly modelled, leaving runtime context and undocumented behaviour outside its protection boundary.
- Agentic Bot: An automated attacker that uses model-driven decision-making to adapt its behaviour, author attack code, and mimic legitimate users in real time. These bots can change tactics faster than static scripts, which makes traditional pattern-based bot mitigation less reliable as a primary defence.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It gives identity and security practitioners a shared control language for runtime trust, credential lifecycle, and privileged access.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org