Detections reference

A detection is a signal the protected app checks at runtime. For each one you pick a response in runtime:.

Preview engine

These are the detections the protection is designed to perform. The engine is in preview and no protected package is produced yet. See limits and guarantees.

The nine detections

Key	Looks for	Typical false positives	Pairs well with
root	A rooted Android device or a jailbroken iOS device.	Legitimate power users; custom ROMs.	warn first; block for money movement only.
emulator	The app running in an emulator or virtual device.	Your own QA on emulators; cloud device farms.	monitor in staging, stricter in production.
debugger	A debugger attached to the process.	Developers; some crash-reporting tools.	warn, then block.
hooking	Instrumentation frameworks (Frida, Xposed) and function hooking.	Rare; some accessibility or automation tools.	block or terminate; this is a strong signal.
tamper	A modified package or a broken signature.	Re-signed internal builds; some store re-packaging.	block or terminate.
overlay	Another window drawn over a sensitive screen.	Chat heads, screen filters, some accessibility tools.	block_sensitive_screens.
a11y	Accessibility services abused to read or drive the screen.	Real assistive technology (do not punish people who need it).	warn plus review; block_sensitive_screens with care.
capture	Screen capture or recording.	Users who record for support or accessibility.	block_sensitive_screens.
remote_access	Remote-control or screen-sharing sessions.	Legitimate remote support.	block_sensitive_screens.

The last four (overlay, a11y, capture, remote_access) are the Pix Shield set, for payment flows. Their default in moatgator:pix-shield is block_sensitive_screens. The first five are in every plan; the Pix Shield set starts at the Scale plan (see what your plan allows).

Honest limits

• No detection is perfect. Attackers adapt. Moatgator layers several signals per detection; a determined attacker with full control of a device can sometimes bypass a check.
• A detection is a signal, not proof of fraud. Use it with your own fraud engine, not instead of it.
• Accessibility is special. Blocking accessibility services can lock out people who depend on them. Prefer warn or screen-level blocking and give people a way through.

Roll out in this order

1. Everything in monitor. Ship a release. Read the events for a few days.
2. Move one detection to warn. Watch the rate of flagged sessions and support tickets.
3. Move high-confidence detections (hooking, tamper) to block.
4. Use terminate only where ending the session is acceptable.
5. Loosen staging, keep production strict, using env.

Because anything unlisted stays in monitor, adopting a newer Moatgator version never starts blocking users on its own.

What your backend sees

With Attest enabled, the signals are merged into one signed verdict your backend can verify. If no verdict arrives (offline, blocked network), you decide whether a sensitive action fails open or closed.