Ask anything official about AppDefender.dev. I only answer from approved knowledge. I do not invent capabilities, and I do not enforce policy.
Newsroom
The Launch Security Gate is the control. The token is not.
AppDefender decides ALLOW, RESTRICT, or BLOCK before the Client UI loads. A valid access token never overrides BLOCK.
AppDefender.dev is built around one order: detect on the device, decide in policy, enforce before UI. The Launch Security Gate is that order in product form. Native AppDefender, CodeDefender, KeysDefender, and CryptoEngine run when the Client app opens — not after a login screen has already rendered.
Banks and UPI teams still need access tokens. Those tokens prove a session, not a clean device. If the launch score is BLOCK, the app shows a security screen and reports the threat. The token stays irrelevant. That rule is RASP-AUTHZ-001 in the operator briefing, and it is the same in Sandbox and Production.
Offline Threat Handling sits inside the same gate. When the network is down, a signed cached policy plus local sensors still produce ALLOW, RESTRICT, or BLOCK. Waiting for ATS is not a fail-open path.
Super Admin owns the catalog defaults. Each Client gets an isolated Sandbox first. Production opens only after Super Admin enables it, and production policy changes go through Maker–Checker — two makers, two checkers, no self-approval.
If you are mapping this to a Client React Native app, start with initialize, then launchSecurityCheck, then protected screens. Docs for the gate, the native bridge, and the SDK are on docs.AppDefender.dev.