For Android, detect Execution Guardrails from documented management, network, or vetting evidence; treat state queries as periodic observations rather than real-time events. Correlate Application Permission via Android Enterprise DPC / Application Vetting [DevicePolicyManager.getPermissionGrantState(); PackageManager manifest/requested-permission review]; Application State via Android Enterprise / EMM [Managed package inventory/status and package metadata]; OS API Execution via Application Vetting / Instrumented Dynamic Analysis [Dynamic API/runtime trace: App performs burst of environmental check APIs (Build properties, TelephonyManager IMSI, PackageManager security-tool query) at cold launch before user interaction — multi-category environment fingerprint is the guardrail setup]. Alert on a sequence or state change inconsistent with the device/app baseline, approved management policy, or expected user workflow; do not infer unobserved API calls, file/process activity, or payload content from management state alone.
| Data Component | Name | Channel |
|---|---|---|
| Application Permission (DC0114) | android:DevicePolicyManager | DevicePolicyManager.getPermissionGrantState(); PackageManager manifest/requested-permission review |
| Application State (DC0123) | android:EMM | Managed package inventory/status and package metadata |
| OS API Execution (DC0021) | mobile:DynamicAnalysis | Dynamic API/runtime trace: App performs burst of environmental check APIs (Build properties, TelephonyManager IMSI, PackageManager security-tool query) at cold launch before user interaction — multi-category environment fingerprint is the guardrail setup |
| Field | Description |
|---|---|
| GuardrailCheckWindow | Default 30s at cold launch. Environmental checks at launch before user interaction are guardrail setup. Post-interaction checks may be feature-driven. |
| PopulationComparisonRequired | Behavioral fork detection requires telemetry across multiple device populations (enrolled vs unenrolled). Without population comparison, single-device detection is Low confidence. |
For iOS, detect Execution Guardrails from documented management, network, or vetting evidence; treat state queries as periodic observations rather than real-time events. Correlate Application Permission via Application Vetting [Code-signing entitlements and Info.plist privacy usage-description keys]; Application State via Apple MDM [InstalledApplicationList / ManagedApplicationList]; OS API Execution via Application Vetting / Instrumented Dynamic Analysis [Dynamic API/runtime trace: App performs UIDevice model + iOS version + enrollment state checks at cold launch before user interaction — device fingerprinting guardrail setup]. Alert on a sequence or state change inconsistent with the device/app baseline, approved management policy, or expected user workflow; do not infer unobserved API calls, file/process activity, or payload content from management state alone.
| Data Component | Name | Channel |
|---|---|---|
| Application Permission (DC0114) | mobile:ApplicationVetting | Code-signing entitlements and Info.plist privacy usage-description keys |
| Application State (DC0123) | iOS:MDM | InstalledApplicationList / ManagedApplicationList |
| OS API Execution (DC0021) | mobile:DynamicAnalysis | Dynamic API/runtime trace: App performs UIDevice model + iOS version + enrollment state checks at cold launch before user interaction — device fingerprinting guardrail setup |
| Field | Description |
|---|---|
| GuardrailCheckWindow | Default 30s at cold launch. Environmental checks at launch before user interaction are guardrail setup. Post-interaction checks may be feature-driven. |
| PopulationComparisonRequired | Behavioral fork detection requires telemetry across multiple device populations (enrolled vs unenrolled). Without population comparison, single-device detection is Low confidence. |