What you are granting, and why

• The diagnostics read and never write. Every Microsoft Graph permission requested by a scan is a Microsoft read permission (the name ends in .Read.All or .Read.Directory).
• HELMGATE is the exception, and it is what HELMGATE is for. It is a separate application you consent to separately, and it holds 4 permissions that change your tenant. Nothing under any of them runs until a second named person approves that specific action. The full list is below.
• You are the controller. For the directory data these tools read, you are the data controller and ITSailor acts as your data processor. The processing runs on your instruction, which you give by connecting your tenant.
• Identities are digested before logging. Raw names, email addresses, and user principal names are replaced with a one-way digest before anything is written to our logs. The report shown to your administrator still carries real identities, because it is your own tenant and you need them to act.
• You can revoke at any time. Your administrator removes the grant directly with Microsoft or Google, without us, and all further reads stop at once.

Reads directory, licence, and security posture to find dormant accounts, wasted licences, Shadow IT, and standing admin risk.

A Microsoft 365 tenant administrator approves the connection. Nothing below can change your tenant.

Reads the Workspace directory and per-user security state for the same dormant-account, licence, and Shadow IT audit.

A Google Workspace super administrator approves the connection. 1 of the 3 permissions below grants more than a read, marked Broader than read in the table, and each one says what it can do beyond reading.

Reads leaver-relevant evidence (disabled users, sign-in activity, OAuth grants, roles, devices, drives, sharing) to build an offboarding evidence pack. No remediation permission is requested.

A Microsoft 365 tenant administrator approves the connection. Nothing below can change your tenant.

Reads Conditional Access, Security Defaults, admin roles, PIM, app-consent policy, Intune enrolment, and SharePoint sharing to verify posture against the ITS-M365 baseline.

A Microsoft 365 tenant administrator approves the connection. Nothing below can change your tenant.

The only ITSailor connection that can change your tenant. It ends sign-in sessions, blocks sign-in, removes standard group memberships and changes licences, each one only after a second named person approves that specific action.

A Microsoft 365 tenant administrator, on a separate application from every scan above approves the connection. 4 of the 5 permissions below grant more than a read, marked Broader than read in the table, and each one says what it can do beyond reading.

The Offboarding Evidence subscription requests two permissions the free scan above does not: offline_access and MailboxSettings.Read. Both are still read permissions; neither can change your tenant.

The free scan above is one browser session and finishes well inside the hour a Microsoft Graph access token stays valid, so it never needs to renew one. The paid subscription reruns once a day with nobody at the console, and a token that has expired cannot renew itself: offline_access is what lets the connector refresh its own access token instead of asking your administrator to reconnect before every run.

MailboxSettings.Read is not requested by the free scan at all, which is why its own evidence pack states that mailbox forwarding and redirect rules can only be checked once this permission is granted. The paid connector requests it so a leaver's mailbox rules are read directly rather than left as a gap in the evidence.

Every party that receives personal data from ITSailor, condensed from the Privacy Policy. Most are sub-processors, acting on documented instruction. Some are not, and their rows open by saying so. The policy is the authoritative source and is updated first when this list changes.

SEAWALL Azure requests no Microsoft Graph permissions. Not a narrow set: none. Access to an Azure subscription does not come from a consented API permission at all, it comes from an RBAC role assignment you make yourself in your own portal and can delete in one click, without telling us.

The role is the built-in Reader, which grants */read and nothing else.

We deliberately do not ask for Cost Management Reader, despite the name suggesting it is the read-only one for cost. Its action list contains the wildcard Microsoft.Support/*, which permits support-ticket creation. Reading a permission by its name rather than by its action list is a mistake this practice has made once before and does not intend to repeat.

Sufficiency was settled by running every read path the collector needs as a principal holding Reader and nothing else, on 2026-08-15: budgets, Advisor, policy assignments, resources, Resource Graph and Cost Management all answered. SEAWALL never writes to your Azure, in any tier.