> For the complete documentation index, see [llms.txt](https://docs.material.security/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.material.security/learn-more/risk-areas/malicious-oauth-apps/oauth-detections-and-classification.md).

# OAuth Detections and Classification

## Detections

Material includes five OAuth detections across two plan tiers. One fires in real time when a new app is connected and is available on all plans. The other four run a periodic audit every 90 days, are powered by the OAuth Remediation Agent, and are available on Advanced plans. Audit detections also run once when the feature is first enabled.

<figure><img src="/files/9p68bWJv7C5r8yokXcsU" alt="" width="375"><figcaption></figcaption></figure>

<table><thead><tr><th>Detection</th><th>Plan</th><th width="105.42578125">Severity</th><th width="423.78515625">Description</th><th>When it fires</th></tr></thead><tbody><tr><td>Application was granted OAuth access for the first time</td><td>All plans</td><td>Variable</td><td>A new OAuth app connection was detected in your environment</td><td>When a user connects a new app (real time)</td></tr><tr><td>Application found to be Suspicious in latest audit</td><td>Advanced</td><td>Variable</td><td><p>Identifies OAuth applications whose latest automated audit flagged trust gaps, anomalies, or adversarial-by-design properties warrant investigation</p><p>Unlike Malicious, the evidence is not conclusive. A human should review before revoking.</p></td><td>Every 90 days</td></tr><tr><td>Application found to be Malicious in latest audit</td><td>Advanced</td><td>Critical</td><td><p>Identifies OAuth applications whose latest automated audit classified them as Malicious.</p><p>These apps may pose an active threat and should be remediated.</p></td><td>Every 90 days</td></tr><tr><td>Application found to be Overprivileged in latest audit</td><td>Advanced</td><td>Medium</td><td>Identifies OAuth applications whose granted scopes substantially exceed what the app actually needs or uses. The app's behavior aligns with its stated function but the grant is broader than necessary. The natural remediation is re-granting with tighter scopes rather than full removal.</td><td>Every 90 days</td></tr><tr><td>Application found to be Unnecessary in latest audit</td><td>Advanced</td><td>Low</td><td>Identifies OAuth applications that are benign and appropriately scoped, but no longer have a reason to be installed: dormant, redundant with a sanctioned app, or vendor-sunset. Removal here is a hygiene action, not a security one.</td><td>Every 90 days</td></tr></tbody></table>

#### To view OAuth detections:

1. From the left navigation, click **Detections**.
2. Filter[^1] by **Entity Type** > **Apps**.
3. From there, click a detection to open the detail view where you can see the detection description, view related issues, and give feedback.

<figure><img src="/files/9LrR6htToFGOrXfFoZTh" alt=""><figcaption></figcaption></figure>

<details>

<summary>Disable detections</summary>

OAuth detections are on by default. If you don't want a detection to identify and create issues, you can disable it from the Detections page.

1. From the left navigation, click **Detections**.
2. Find the OAuth detection you want to manage.
3. Click the **detection** to view its description and any related issues.
4. Toggle **Enabled** to **Off** then **Save**.

Disabling a detection stops issue creation entirely for that detection type. No issues will be created and no responses will execute.

</details>

### Get notified when the audit identifies a new issue

You can [create an event subscription](#user-content-fn-2)[^2] to let you know when one or more of the OAuth Remediation Agent detections created an issue.

When you configure your notification, use these parameters:

* IF `Issue Change` and
* Detections: one or more of `Application found to be suspicious in latest audit`, `Application should be Denied based on latest audit`, `Application found to be Malicious in latest audit`

Review [Set up a notification](/getting-started/deployment-guides/your-first-30-days/6-enable-email-remediation/set-up-a-notification.md) to learn more about creating notifications or [Integrations](/integrations/integration-fundamentals.md) if you want to send this data downstream to another tool.

***

## Classification

App classifications drive response. You can manually classify any app from the Apps list, regardless of your plan.

On Advanced plans, the OAuth Remediation Agent investigates each app automatically, scoring it across four risk factors and providing a detailed report to inform your classification decision.

To view investigation details (Advanced):

1. Navigate to **Explorer** > **Apps** > **OAuth.**
2. Select an app to open the detail view.
3. Scroll to **Latest Investigation** for a summary, or click **View full investigation** for more details about the analysis.

<figure><img src="/files/VxXyTRbMsEb2fvnFimGa" alt=""><figcaption></figcaption></figure>

Each factor is labeled with a severity and a color code: red for high risk, orange for medium, and neutral for low or unclear.

<details>

<summary>Risk factors</summary>

**App Behavior Risk:** What the app has actually done at runtime, including API call patterns, data access events, and behavioral anomalies. If the app is new or has no recorded activity, this appears as **Unclear**, which is not the same as safe.

**Scope Risk:** Whether the permissions the app is requesting are proportionate to its stated purpose. The agent flags cases where the scope significantly exceeds the apparent use case. For example, a PDF tool requesting full Gmail read/write access.

**User Blast Radius:** The potential impact if the app or its token were compromised. The agent factors in both the number of connected users and the sensitivity of their roles. A single high-privilege user can generate a Large blast radius even with a low user count.

**Vendor Trust**: The reputation and verifiability of the app developer. The agent checks the vendor's website, documentation, marketplace presence, verification status, and whether the vendor is already approved elsewhere in your organization.

</details>

{% hint style="info" %}

#### Why does an app show as "Unclear" for App Behavior Risk?

**Unclear** means the agent has no recorded runtime activity for the app yet. It does not mean the app is safe. This is common for newly connected apps or apps that have not been used since authorization.

Treat **Unclear** as unknown until activity is recorded. Review [risk factors and classification](#classification) for more context.
{% endhint %}

#### How to classify an App

{% hint style="info" %}
To classify apps and configure remediation and response you must have a [Super Admin, Tenant Admin, Settings Admin, or Triage Admin role](/learn-more/administration/admin-roles.md).
{% endhint %}

1. Navigate to **Explorer** > **Apps** > **OAuth**.
2. Select an app.
3. From the drop-down on the right, choose a classification. There are six classification types to assign to an app.

<figure><img src="/files/3DiMtbTkQvnS8J1l9BCN" alt="" width="159"><figcaption></figcaption></figure>

{% hint style="success" %}
When you accept the agent's suggested classification (Suspicious, Unnecessary, Overprivileged, or Safe), the underlying issue is automatically resolved. You don't need to close it separately.
{% endhint %}

#### Classification Definitions

{% tabs %}
{% tab title="Malicious" %}
The app shows observed behavioral evidence of acting against the customer's interests, strong enough that an analyst would revoke without further investigation. Signals must be grounded in activity or technical evidence, such as API call sequences whose only plausible explanation is abuse, deceptive impersonation of a legitimate brand, or a publisher tied to confirmed threat activity.

ToS or privacy-policy language alone, even when it discloses data harvesting, resale, or training on customer data, is **not** sufficient for Malicious. That belongs in Suspicious so a human can judge intent and scope. The bar is intentionally high: false positives here cause unwanted revocations, so when in doubt between Malicious and Suspicious, choose Suspicious.
{% endtab %}

{% tab title="Suspicious" %}
The app shows trust gaps, anomalies, or adversarial-by-design properties that warrant investigation but are not conclusive enough to confirm active harm. This covers: unknown or low-reputation publisher requesting sensitive scopes, lookalike of a known brand, recent vendor compromise in the news, activity that diverges from the app's stated purpose, **and** disclosed business-model concerns, such as a privacy policy or ToS that grants the vendor the right to harvest, resell, or train on customer data.

Suspicious is fundamentally about *behavior or trustworthiness*, not grant shape. If the app behaves consistently with its stated function but was simply granted too much, that is Overprivileged. This is also the conservative default when evidence could support Malicious: a human should review first, and Malicious is reserved for cases where behavioral evidence of harm is already conclusive.
{% endtab %}

{% tab title="Overprivileged" %}
The app is behaving in line with its stated purpose, but its granted OAuth scopes substantially exceed what the app actually needs or uses. Signals: activity logs exercise only a narrow subset of granted scopes, the scopes requested are broader than the app's documented function, or the grant is org-wide for a tool a single team uses.

The natural remediation is re-granting with tighter scopes rather than full removal. The bar versus Suspicious is *behavior alignment*. If observed activity matches the app's stated function, a scope-vs-need imbalance is Overprivileged. If observed activity is itself off-pattern, it's Suspicious. The bar versus Unnecessary is *active use*. If the app isn't used at all, classify as Unnecessary regardless of scope shape.
{% endtab %}

{% tab title="Unnecessary" %}
The app is benign and appropriately scoped, but there is no longer a reason to keep it installed. Signals: no meaningful activity over a relevant window, functionality fully covered by another sanctioned app already in use, or the vendor has sunset the product or gone defunct. Removal here is a hygiene action, not a security one. Nothing about the app is wrong. It simply isn't earning its' grant.

The bar versus Overprivileged is *whether the app should exist at all*. Overprivileged keeps the app and tightens scopes. Unnecessary removes the app entirely. The bar versus Safe is the presence of a specific, articulable reason to remove.
{% endtab %}

{% tab title="Safe" %}
The app comes from a reputable publisher, its granted scopes are appropriate for its stated function, its activity in logs is consistent with that function, and it shows ongoing use that justifies keeping it installed. This is the default classification when no specific concern applies. There is no threat signal, no scope or usage mismatch, and no hygiene issue.

Choose Safe only when you can affirmatively account for the publisher, the scopes, and the activity. An app you cannot make a clean positive case for belongs in Suspicious or Unnecessary depending on whether the doubt is about trust or about utility. Safe is not "absence of evidence of harm." It is "evidence of fit."
{% endtab %}
{% endtabs %}

To configure how the agent responds to each classification, see [OAuth Response](/learn-more/risk-areas/malicious-oauth-apps/oauth-remediation-responses.md).

{% hint style="info" %}
Auto-classification will be added in the future, stay tuned! We'll share more news in our release announcements and [What's New](/whats-new.md).
{% endhint %}

***

## Issues

To view issues related to an OAuth Remediation Agent detection, you can drill down into them directly from the App detail view or filter the issue list.

1. From the workspace, click **Issues**.
2. Filter by **entity type** > **apps**.
3. Click an issue row to view details.

{% hint style="success" %}
To return to this filtered issue list easily, create a [Saved View](/getting-started/fundamentals/investigate/saved-views.md).
{% endhint %}

### Severity

Issues are assigned severity levels. Severity is tied to the detection, not the classification. It indicates how much attention an issue requires, independent of how the app is ultimately classified.

Some OAuth Remediation Agent detections use a **Variable** severity meaning severity is determined by the agent's investigation findings at the time the detection fires, and may differ from one audit to the next.

### Internal Apps

Internal OAuth apps are not investigated by the OAuth Remediation Agent. If you open an internal app, you'll see an info callout noting that investigation doesn't run for internal apps, along with an **Internal App** badge in the Properties card and on any related issue details.

<figure><img src="/files/nsoSQYhQKW4n7MNItJjU" alt=""><figcaption></figcaption></figure>

[^1]: To the right of search, the button with three lines

[^2]: From the top toolbar, **integrations** > **api and mcp** > **events** then click **Create Event**.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.material.security/learn-more/risk-areas/malicious-oauth-apps/oauth-detections-and-classification.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.