Understand how Monitor actions work
Monitor actions define how your application responds when a protection module detects a threat. Each module can be assigned its own action, so you can log low-confidence detections, terminate the application for critical threats, or execute custom logic for enterprise workflows.
Action Types
SDK Actions
These actions are available in JSON configuration and the Configuration API. They execute inside the application at the point where the threat is detected.
| Action | Behavior | Use Case |
|---|---|---|
| Close | Terminates the application immediately | Critical threats (debugger attached, tampering detected) |
| Log | Records the incident and continues execution | Non-critical threats, monitoring, analytics |
| Erase | Securely deletes sensitive data, then terminates | Financial or healthcare applications on compromised devices |
| Custom | Executes your own async handler | SIEM integration, Slack alerts, custom escalation workflows |
| None | Detects the threat but takes no action | Development, testing, shadow mode before enforcing |
Cloud Dashboard Actions
These actions are available when configuring Workflow Rules in the Cloud Dashboard. They extend the SDK actions with server-side responses.
| Action | Behavior | Use Case |
|---|---|---|
| Log incident | Records the incident with full forensic context | Audit trail, compliance, analytics |
Click to expand
Action Selection Guide
By Threat Severity
| Threat Severity | Development | Staging | Production |
|---|---|---|---|
| Critical (Debugger, Tampering) | None / Log | Close | Close |
| High (Jailbreak, Memory Dump) | Log | Close | Close / Erase |
| Medium (Simulator, Process Injection) | None | Log | Log / Close |
| Low (Clock Tampering, Network Tampering) | None | Log | Log |
Common Scenarios
| Scenario | Action | Why |
|---|---|---|
| Debugger attached in production | Close | Immediate shutdown to prevent reverse engineering |
| Simulator detected on release build | Log | Track for analytics, block in enterprise settings |
| Jailbreak on a banking app | Close | Regulatory requirement, compromised device cannot be trusted |
| Tampering detected with sensitive data | Erase | Delete Keychain items and credentials before shutting down |
| New protection in shadow mode | None | Observe detections before enforcing in production |
| Memory dump attempt detected | Erase | Wipe sensitive data immediately, terminate the app |
| Network proxy detected | Custom | Show user warning, allow continue or exit based on context |
Configuring Actions
Actions can be assigned per protection module from any configuration source:
- Cloud Dashboard: Assign actions in Workflow rules with the IF/THEN editor.
- JSON Configuration: Set the
actionfield per protection in your configuration file. - Configuration API: Pass the action type when registering protections in code.
{
"protections": [
{ "type": "DebuggerDetection", "action": "close", "intervalMs": 5000 },
{ "type": "JailbreakDetection", "action": "close", "intervalMs": 60000 },
{ "type": "NetworkTampering", "action": "log", "intervalMs": 30000 }
]
}{
"protections": [
{ "type": "DebuggerDetection", "action": "close", "intervalMs": 5000 },
{ "type": "JailbreakDetection", "action": "close", "intervalMs": 60000 },
{ "type": "NetworkTampering", "action": "log", "intervalMs": 30000 }
]
}See JSON Configuration for the full schema reference.
Next Steps
Protection Modules
All available protection modules and what they detect
Custom Actions
Create custom response handlers for enterprise workflows
Cloud Configuration
Configure Workflow rules from the Cloud Dashboard
JSON Configuration
Full schema reference for per-module action configuration