The requirement to declare whether a pending intent can be changed after it is created. Android 12 forces developers to mark pending intents as mutable or immutable, which helps the system and app developers reason about whether another component can alter the action later.
What pending intent mutability means in Android
Pending intent mutability is an Android security boundary, because it determines whether another component can change the eventual action, extras, or target behavior after the pending intent has been created. That makes the flag a declaration of trust, not just a syntactic requirement.
Before Android 12, developers could leave this ambiguity implicit. Modern Android forces the choice to be explicit, which helps both the platform and the app reason about whether the pending intent is a fixed capability or a reusable one that can still be modified by a trusted flow.
Why the mutable and immutable distinction matters
An immutable pending intent is the safer default when the sender already knows the exact action it wants executed. Once created, the intent cannot be altered by later consumers, which reduces the chance that a different component can silently redirect the operation or inject unexpected data.
A mutable pending intent is only appropriate when a later component genuinely needs to fill in or adjust part of the request at send time. That flexibility is useful, but it also expands the trust surface because the later component can influence what ultimately runs. The distinction is closely related to access-control discipline, where the object is either a fixed capability or one that still accepts downstream changes.
As with broader Android hardening guidance, the security value comes from making authority explicit. Clear mutability choices support safer review, safer framework behavior, and fewer assumptions about what a pending intent can do when it is reused.
Common failure modes and practical examples
The main failure mode is over-granting flexibility. If an app marks a pending intent mutable without needing that behavior, another component may be able to alter parameters, trigger a different action, or strengthen an existing capability in ways the original developer did not intend.
That risk is especially important when pending intents cross process boundaries or are stored for later use. The longer a capability lives, the more opportunity there is for misuse, accidental reuse, or confusion about which component still has influence over the final action.
In practice, immutability is usually the better fit for notifications, alarms, or one-shot operations where the action should remain stable. Mutability is more specialized and should be treated as an exception, not a default convenience.
How to interpret mutability in Android security reviews
Pending intent mutability should be reviewed as part of broader Android authorization and component design. The question is not just whether the code compiles, but whether the app actually needs a later actor to modify the pending intent at all.
When that need does not exist, immutable is the cleanest expression of intent and the easiest state to reason about during code review. When mutability is required, the surrounding design should make clear which component is trusted to modify it and why that trust is justified.
For teams using Android security baselines, the right mental model is capability control: a pending intent should carry only the authority it truly needs, and no more.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Pending intent mutability affects how much authority later components can exercise. |
| SC-3 — Security Function Isolation | Immutable pending intents help separate trusted app logic from later component influence. | |
| Recommendation — Limit pending intent authority to the minimum behavior the app actually needs. Isolate trusted actions so later callers cannot alter the security-critical request. | ||
| OWASP ASVS | V8 — Authorization | The term concerns whether a later actor may change an action before execution. |
| Recommendation — Review whether each pending intent grants only the action the application intended. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Mutability is an access-control decision about who may change a capability after creation. |
| Recommendation — Treat mutable pending intents as controlled exceptions and remove unnecessary modification paths. | ||
Related resources from NHI Mgmt Group
- What is the difference between logging actions and logging intent for AI agents?
- What is the difference between role-based access and intent-based access for agents?
- What is the difference between RBAC and intent-aware access for autonomous workflows?
- What is the difference between access control and intent governance for AI agents?
