The most common question IT admins ask before connecting a third-party tool to Microsoft 365 is some version of "what can it actually access?" It's the right question. "Read-only" is a claim that deserves scrutiny — here's exactly what it means in the context of Microsoft Graph API access, and what M365Clarity specifically can and cannot do.
Third-party tools connect to Microsoft 365 through the Microsoft Graph API using OAuth 2.0. There are two models: delegated access and application access.
Delegated access means the application acts on behalf of a signed-in user. It can only do what that user could do themselves — and only while that user's session is active. Application access means the application has its own identity and can act without a signed-in user, using permissions granted directly to the application.
M365Clarity uses delegated access only. When you click Connect, you authenticate as a Global Admin and Microsoft issues a short-lived access token. That token is scoped to the specific permissions shown on the consent screen. When the session ends, the token expires.
No agent software. M365Clarity does not install anything on your tenant. There is no background process, no service account, no persistent access. Each scan uses a fresh token obtained through the Microsoft refresh token flow — a standard mechanism that allows token renewal without requiring you to sign in again each time.
Microsoft Graph permissions are explicitly named as either read or read/write. A permission like Policy.Read.All allows reading policies. Policy.ReadWrite.ConditionalAccess allows modifying them. These are enforced by Microsoft's infrastructure — they are not a promise from the application vendor, they are a technical constraint.
M365Clarity requests only read permissions. If the code attempted to write to an endpoint — say, modifying a Conditional Access policy — Microsoft's API would return a 403 Forbidden error. The read-only constraint is enforced at the API level, not by convention.
| Permission | What it reads |
|---|---|
| Policy.Read.All | Conditional Access policies, authentication methods, security defaults |
| Directory.Read.All | Users, groups, domains, organisation settings, subscription SKUs |
| DeviceManagementConfiguration.Read.All | Intune device compliance policies, configuration profiles, update rings |
| DeviceManagementManagedDevices.Read.All | Enrolled device count and compliance status (not device content) |
| Sites.Read.All | SharePoint site sharing settings and governance configuration |
| TeamSettings.Read.All | Teams external access settings and federation configuration |
| AuditLog.Read.All | Sign-in logs for risk analysis (not email or file activity) |
| Application.Read.All | Enterprise app registrations and their permission grants |
| ReportSettings.Read.All | Adoption and usage statistics |
| Action | Can M365Clarity do it? |
|---|---|
| Read email content | No — Mail.Read is not requested or granted |
| Read Teams messages | No — ChannelMessage.Read is not requested |
| Read SharePoint file content | No — Files.Read is not requested; Sites.Read.All covers site settings only |
| Modify any setting | No — no write permissions are requested or granted |
| Create or delete users | No — Directory.Read.All is read-only |
| Send email on your behalf | No — Mail.Send is not requested |
| Act without your session | No — delegated access only; application permissions not used |
| Retain your access token | No — tokens are short-lived; refresh tokens are stored encrypted in our database and used only to renew scan access |
When you connect your tenant, Microsoft issues a refresh token alongside the short-lived access token. This refresh token allows M365Clarity to obtain a new access token when scheduled scans run — so you don't need to sign in every time.
Refresh tokens are encrypted at rest in M365Clarity's database using AES-256-GCM with a key that is stored separately from the data. They are used only to obtain new access tokens for scanning. They cannot be used to access data directly.
You can revoke access at any time from the Microsoft Entra admin centre under Enterprise applications → M365Clarity → Permissions, or by disconnecting your tenant from within M365Clarity. Either action immediately terminates the refresh token and prevents further scans.
The one thing to be aware of: M365Clarity stores a refresh token for each connected tenant. If M365Clarity's infrastructure were ever compromised, an attacker with access to the database and the encryption key could potentially use these tokens to scan your tenant configuration. This is true of any SaaS tool that uses persistent OAuth tokens — it's why our security model is documented publicly and why we use separate encryption keys.
You don't have to take our word for it. After connecting your tenant, go to Microsoft Entra admin centre → Enterprise applications → M365Clarity → Permissions. You will see every permission that has been granted, listed explicitly. None of them will be write permissions.
You can also review the consent screen before connecting — Microsoft displays all requested permissions before you approve. If you see any permission that includes "write", "send", or "manage" in the name, do not consent and contact us.
See our full security documentation
Encryption model, token handling, data retention, and infrastructure details.
Read the security page →