Intent filtering is the Android mechanism that defines which incoming intents an app component can receive and how they are matched. Android 15 tightens this process with more precise rules, requiring closer alignment between the sending intent and the receiving component’s declared filter conditions.
Expanded Definition
Intent filtering is Android’s routing rule set for app components such as activities, services, and broadcast receivers. It determines whether an incoming intent matches a component’s declared action, data, category, and other filter constraints, so the system can decide what may be delivered and what should be rejected.
The term is often confused with general access control, but it is more specific than that. It governs intent resolution at the platform boundary, not the app’s internal authorization checks. A component can be reachable through intent filtering yet still require its own validation before performing sensitive work. Android 15 tightened matching so the sender’s intent must align more closely with the receiver’s declared filter conditions, which reduces ambiguous routing. Guidance vs consensus: the Android platform direction is clear, but app teams still differ on how much trust they place in filters versus in-app validation.
For authoritative platform detail, Android’s own intents and intent filters documentation remains the most direct reference for matching behaviour and component exposure.
Examples and Use Cases
Intent filtering appears anywhere Android components need to expose controlled entry points to the system or other apps. Common use cases include:
- An activity declares a browser-style
VIEW
intent filter so it can open specific links while ignoring unrelated actions. - A broadcast receiver accepts only a narrow set of system or app-defined actions, limiting which events can wake it.
- An exported service uses filter constraints to restrict which client intents can bind or start it.
- A deep link handler matches scheme, host, and path so the app opens the right screen instead of a generic entry page.
- A legacy app component relies on a broad filter and later adds in-app checks to compensate for overly permissive routing.
The practical trade-off is simplicity versus precision. Broader filters make integration easier, but they also enlarge the set of intents the platform will deliver, which can create unintended entry paths if component behaviour is sensitive to the incoming data.
Security Implications
When intent filtering is misunderstood, apps may expose components to unintended callers or receive data in ways the developer did not anticipate. The result is often not immediate compromise, but confused-deputy behaviour, unsafe state changes, or execution of sensitive flows from untrusted entry points. The problem is especially visible when exported components rely on weak filters and assume the platform has already enforced all trust decisions.
Failure usually happens when the filter is broader than the component’s real security boundary, or when the component accepts a matched intent without verifying sender context, parameters, or user intent. That gap can lead to unauthorized navigation, privilege misuse inside the app, or abuse of sensitive functionality through crafted intents. In practice, a component that should have been reachable only by a narrow set of senders becomes discoverable by a much wider set of apps or system events.
For defenders, the warning sign is a component whose exposure is defined only by manifest matching while the business logic assumes stronger trust than the filter actually provides.
Domain and Governance Relevance
Intent filtering matters in Android application security because it is part of the platform’s exposure model for inter-component communication. It does not replace application authorization, but it shapes which surfaces are reachable in the first place. For mobile teams, that means manifest design is a governance decision, not a purely technical declaration.
In practice, Android 15’s stricter matching improves predictability, but it does not eliminate the need to review exported components, verify whether each filter is actually necessary, and confirm that the receiving component can safely handle every intent shape it accepts. The boundary is especially important for apps that process links, notifications, or other externally influenced entry paths.
Where an app mediates access to sensitive functions or data, intent filtering becomes part of the trust model. The safest interpretation is that filters reduce accidental exposure, while the app itself must still enforce the real security decision.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-3 — Access Management | Intent filters define which callers can reach an app component. |
| PR.DS-5 — Data Management | Intent handlers may process sensitive data delivered through external intents. | |
| Recommendation — Limit component exposure to approved intent patterns and review exported entry points. Treat externally supplied intent payloads as untrusted data and validate before use. | ||
| CIS Controls v8 | 4.1 — Establish and Maintain an Inventory of Authorized Software | Android components are part of the app surface that must be understood and governed. |
| Recommendation — Inventory exported components and verify each intent filter has a documented business need. | ||
| MITRE ATT&CK | T1204 — User Execution | Crafted intents can steer users or apps into unintended execution paths. |
| Recommendation — Hunt for malicious links or intents that drive execution through trusted app handlers. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Intent exposure can become relevant when apps pass tokens or credentials through handlers. |
| Recommendation — Avoid routing secrets through broad intent handlers and validate any credential-bearing input. | ||
Related resources from NHI Mgmt Group
- What is the difference between content filtering and intent security for AI agents?
- 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 prompt filtering and identity governance for AI agents?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
