Label Audit Records Now Name the Label ​

August 28, 2026 · InfraScout Team

Microsoft Purview sensitivity labels leave a trail in the Microsoft 365 Unified Audit Log — a label applied, a policy matched, a labeled file acted on. Those records are genuinely useful for an assessment, because a label being removed from a document is often the interesting half of an exfiltration story.

They carry the label as a bare GUID and nothing else.

So a finding read:

label 89d530c4-… was removed from a document by j.doe@example.com

Which is technically complete and practically useless. Nobody reading a report knows whether that GUID was the label for public marketing material or the one that encrypts personnel files.

Two tools, one join ​

Two new security tools read the tenant's label taxonomy: mscloud_security_list_sensitivity_labels and mscloud_security_get_sensitivity_label.

We tried it against a real tenant: the three GUIDs that appeared across thirty days of label activity resolved to an internal-use label, a personal-data label, and an HR label. Which turns the record above into:

a document labeled Confidential – HR had its encryption stripped

That is the whole point of the change. The secondary benefit is label posture in its own right — which label is the tenant default, whether the top classification is disabled, and whether a label is actually published to users rather than merely defined. All questions an identity or data-protection review asks, and none of them previously answerable.

The documentation was wrong, so we probed it ​

The published property list for this endpoint names seven properties. The response actually carries around twenty-five, and includes none of one that the documentation does list.

We tested the endpoint's real behavior rather than trusting the reference, and several findings shaped the tools:

  • The label's text is in name, not displayName. displayName comes back empty on every label. The tool descriptions call this out, because a model reading an empty display name would reasonably report the label as unnamed.
  • A malformed identifier returns a server error rather than a not-found. The tool rejects a non-GUID before it makes a call, so the model gets a usable message instead of an opaque failure.
  • A well-formed identifier matching no label returns a success with an empty body. Left alone, that reads to a model as "the label exists and has no properties" — a false statement about your tenant. It is classified as not-found.
  • There is no paging. The taxonomy comes back whole, so the tools deliberately do not advertise paging arguments that would do nothing.

Filtering is supported where Microsoft supports it — enabled labels, and labels applicable to files, email or Teams content — and rejected where it is not, rather than passed through to fail.

We also declined the newer preview path for this data, deliberately. It needs a different permission and refuses access with an empty error message, which means we could not tell you which permission you were missing. The generally-available path can.

These tools need SensitivityLabels.Read.All, which is now in the onboarding script. Tenants onboarded before September 2026 need to re-run it — it is idempotent and leaves your existing secret alone with -GenerateSecret $false.

The licensing side is undemanding: Purview Information Protection, which every Microsoft 365 E3 and E5 tenant already has. See Microsoft License Requirements.

If you would rather not re-run anything yet, the connection's capability panel will tell you the permission is missing and name it, rather than leaving you to find out when an assessment reaches for it.

What this does not cover ​

Data loss prevention policy configuration is not obtainable through app-only access at all — the endpoint that would serve it does not exist, and the one that looks like it is an undocumented stub carrying nothing but an identifier and a name. DLP enforcement events are a different matter and have been reachable through the existing audit log tools all along, with no new permission.

Questions or feedback? Reach us at info@infrascout.cloud.