Your weekly scan runs, something changed since last time, and an email lands in your inbox. A licence count shifted. A Teams policy got adjusted. An agent identity went from "doesn't exist" to "active, no owner assigned." All three can show up in that email with the exact same amber badge.
They are not the same kind of change, and treating them identically buries the one that actually matters.
Most configuration drift is routine. Settings get adjusted, policies get tuned, licences get reallocated — normal operational noise that a weekly summary should flag, but doesn't need urgent attention. Identity and governance changes are a different category entirely: they're about who can get in, what they can do once they're there, and whether anyone is accountable for it. A Conditional Access policy loosening, a new admin account appearing, an agent identity becoming active without an owner — these deserve to be seen first, not sorted alphabetically alongside a display-name change.
OneDrive sync policy: amber → green
Agent identity: none → active, no accountable owner
Both could appear in the same email. Only one of them is worth interrupting your day for.
The weekly change-alert email every M365Clarity Pro and MSP customer already receives now distinguishes identity and governance changes specifically — Conditional Access, PIM, admin and guest accounts, app registrations, Entra governance, network access, and Agent Identity Governance. These get a distinct marker in the change table, lead the AI-written summary ahead of routine changes even when they're not the most severe item in the batch, and change the email's subject line so it doesn't get scanned past.
The reasoning is the same one behind Agent Identity Governance itself: an organisation can look completely fine on a surface-level check while having no visibility into who's actually governing access underneath. The point of catching a governance change early isn't that green is required — it's that silence between scans is exactly where that gap grows unnoticed.
While building this, we found something worth being upfront about: a status that couldn't be determined during a scan — usually a transient permission or API issue — was being reported in the same "improved" category as a genuine fix. Losing visibility into a feature isn't good news, and it shouldn't read like it. That's now shown as its own category, separate from an actual improvement.
Why we're mentioning a bug fix in a feature announcement: the whole point of weighting identity changes correctly is trustworthy signal. An alert system that occasionally mislabels "we don't know" as "things got better" undermines that same goal, even in an unrelated corner of the same email. Worth fixing in the same pass, worth saying so.
Identity and governance changes surfaced distinctly, automatically, in the alert you already get.
Run a free scan →Related articles