
Nobody sees the full picture.
Consent, permissions and activity live in different places, so risky access goes unnoticed.
Application Protection · Coming soon
The planned module will show app permissions, who approved them and what they reach. Review access before choosing a supported response.
App access, explained before you act.
The problem
Employees approve apps every day. Some ask for far more than they need, and the access stays after the tool is forgotten or compromised.

Consent, permissions and activity live in different places, so risky access goes unnoticed.

The proposed module would connect consent, permission and activity evidence so an owner can review a grant and, where supported, decide whether to keep, restrict or revoke it.
Planned grant workflow
This example shows how a future review could explain who approved access and what it reaches.

Concept preview. No customer data or live control is connected.
The grant remains active beyond the approving user's session.
Outcome: the owner and current business need can be assessed.
Restriction and revocation remain conditional on tenant policy, authority, permissions, licensing, the connected provider's documented controls and the ability to read the resulting state back.
A provider accepting the action does not prove that the application's access has ended.
Built for your team
A planned view of which apps may access company email and files, explained plainly.
A planned workflow for reviewing app grants across eligible customers while each retains authority.
Review persistent grants against local ownership and policy when the module arrives.
Bring an app grant into the wider identity and data-access investigation once supported.
Questions people ask
OAuth consent governance means tracking which apps retain access to business data, what they can reach and who approved them. Application Protection is planned to help review those grants and coordinate supported changes. It is not available yet.
Identity Protection covers access used by people and sessions. The planned Application Protection module would focus on standing app grants: which app holds each grant, its permissions, who consented and whether access is still needed.
It can. The proposed workflow would explain the grant, owner, age, scope and reported activity before a team chooses any supported action under local approval. Narrowing one permission may be more proportionate than revoking the full grant.
The planned design uses grants, consent records and app configuration to explain potential reach. It is not designed to read mailbox messages, documents or file contents for that purpose. Confirm the final data-handling model at release.
A standing grant may remain after the project or person that justified it has changed. Application Protection is designed to surface who consented, the grant's age, its current permissions and what those permissions can reach, so the approval can be reviewed against today's need.
No. The planned review, restriction and revocation paths depend on the connected environment, configuration, permissions, licensing and provider capability. The choices shown here are illustrative, not actions currently available in Application Protection.
Application Protection is not live, so it does not currently share an app inventory. The planned model would keep inventory, consent records and case evidence within the customer environment. Confirm its final data boundaries before release.
Available platform capabilities
Application Protection is coming soon. See the capabilities already available on the platform, or ask our team about the roadmap.