Limits and guarantees

Security products tend to oversell. This page says plainly what Moatgator does and what it does not, with the same weight on both.

The protection engine is in preview

Until the engine ships, builds are registered and scanned, but no protected package is produced. Everything below describes the intended behavior of the protection, except where a row says "available today". See the state table on the introduction.

What it is for

Moatgator raises the cost of attacking your app and makes attempts visible. It reduces risk. It does not eliminate it.

What each layer does, and does not do

Layer	What it does	What it does not do
Shield (hardening)	Encrypts sensitive strings, protects bundled assets, obfuscates names, so the binary is harder to read and reuse.	Stop a determined attacker. Obfuscation raises the cost of analysis; it is not encryption of your logic.
Runtime (detections)	Detects root or jailbreak, emulators, debuggers, instrumentation (Frida, Xposed), tampering and, for payment flows, overlays, accessibility abuse, screen capture and remote access, and responds by your policy.	Detect everything. No single detection is perfect, which is why several signals are layered. A skilled attacker with a device they control can sometimes bypass a check.
Attest	Merges signals into one signed verdict your backend can verify.	Make a decision for you. If no verdict arrives, you decide whether a sensitive action fails open or closed.
Pulse	Reports security signals (threat type, action taken, app version) so you can see attack patterns.	Collect your users' content. It records signals about devices and attempts only.
Scan (available today)	Reads an APK, AAB or IPA statically and grades protection gaps, mapped to OWASP MASVS.	Prove an app is safe. Not detected is not the same as not vulnerable: the scan is static and covers what it can read from the package.

What we promise

• Monitor first. Every detection starts in monitor: the app reports what it would have done and takes no action. Nothing blocks users until you choose it.
• A new feature never blocks by itself. Anything not listed in your moatgator.yml stays in monitor.
• No signing keys. Signing happens in your pipeline. Moatgator never holds your signing keys, certificates or provisioning profiles.
• No long-lived CI secrets. The GitHub Action and CLI authenticate with OIDC. The GitHub App asks for the minimum permissions and, deliberately, not the permission to edit your workflows.
• We say when the engine is not there. The CLI, the Action and the pull-request check state that no protected package was produced instead of reporting a success.

What we do not promise

• That an app is unhackable, or that a given attack will always be stopped.
• A specific detection rate against a specific tool or version. Attackers and platforms change; detections are updated, with no guarantee of a time to fix.
• That protection has no cost: it can change app size and startup time. The pull-request check reports the measured delta when a protected build exists.
• Compliance outcomes. Mapping to a standard (for example OWASP MASVS) describes what a tool looks for; it is not a certification.

Failure modes you should plan for

• Detections can be wrong. A rooted but legitimate device may be flagged; an unusual emulator may be missed. Start in monitor, read the events, and tighten gradually. warn before block before terminate.
• The network can fail. Decide, per action, whether it fails open or closed when no verdict arrives.
• Builds are a supply chain. Pin third-party actions to full commit SHAs, keep OIDC rules narrow, and review the pull request the GitHub App opens before merging it.

Questions about a specific guarantee? Ask before you depend on it. We would rather correct this page than have you discover a gap in production.