Microsoft Purview Integration
For tenants running Microsoft 365 with Purview sensitivity labels, MeetLoyd inherits those labels on M365-ingested files, maps them to the platform's C1-C4 classification, and enforces them at agent prompt-injection time -- using the same governance matrix your security team already configured for internal data.
The bank's CISO has already classified the data. MeetLoyd respects that classification rather than asking them to re-do it.
Why This Matters
The first question CISOs ask in any AI-platform procurement: "Does your platform respect our existing data classification?"
Without Purview inheritance, every AI tool reclassifies content with its own rules -- forcing a duplicate classification policy, duplicate enforcement, and a 4-hour mapping meeting with the security team. With it, MeetLoyd's governance becomes a continuation of the customer's existing Purview policy, not a parallel system.
The audit trail makes this concrete: every Purview-driven enforcement decision records the original labelId and displayName from the customer's tenant. The regulator sees the bank's own label flowing all the way to the action.
How It Works
M365 file (SharePoint / OneDrive / Outlook)
| Purview label = "Highly Confidential"
v
Microsoft Graph
|
v
MeetLoyd reads the label, maps it to C1-C4
|
v
Stored on the file with classified_by = 'purview:<labelId>'
|
v
Agent tries to use the file in a prompt
|
v
Existing CISO matrix (C1-C4 x input/response/file_ingestion) decides:
block / warn / log
No new gate, no new policy language -- the existing C1-C4 sensitivity-level matrix handles enforcement. Purview inheritance just feeds it the right level.
Default Label Mapping
MeetLoyd ships with sensible defaults that cover Microsoft's standard label kit:
| Purview label (case-insensitive contains) | C-Level | Default enforcement on agent prompt |
|---|---|---|
| Public, Personal, Non-Business | C1 | None |
| General, Internal, Unclassified | C2 | Log |
| Confidential, Business-Confidential | C3 | Log + warn |
| Highly Confidential, Restricted, Secret, Top Secret | C4 | Log + warn + block |
Tenant administrators can override the mapping per label -- by GUID for exact control, or by display name for human-readable rules. Custom labels (e.g. Project Phoenix (NDA), Bank Reserved) that don't match the defaults are recorded but unmapped until the admin assigns a C-level.
The C1-C4 enforcement actions per scope come from your existing Sensitivity Level matrix. If your CISO has tightened C3 to "block on input" or relaxed C4 to "warn only," Purview-classified files honor those choices automatically -- no separate configuration.
Merge Semantics: Higher Wins
When both an internal DLP rule and a Purview label apply to the same file, the higher C-level wins. The other classification is recorded for audit but doesn't drive enforcement.
| Internal DLP | Purview | Final C-level | classified_by |
|---|---|---|---|
| C2 (matched email pattern) | C4 (Highly Confidential) | C4 | purview:<labelId> |
| C4 (matched SSN regex) | C2 (General) | C4 | auto (internal won) |
| (no match) | C3 (Confidential) | C3 | purview:<labelId> |
| (no match) | (no label) | none | (unclassified) |
Tenants with a strong internal-DLP-first posture can disable the trust-external toggle -- internal level always wins, but Purview labels are still recorded in the audit metadata.
Admin Surface
A dedicated Microsoft Purview card in the dashboard's DLP panel exposes:
- A status chip showing whether Microsoft Graph credentials are configured
- Two toggles: enable label inheritance, and let Purview override internal DLP when higher
- A label catalog table -- discovered live from your tenant's Purview deployment via Microsoft Graph
- Per-label C-level mapping, with the origin of each mapping visible (default name match vs tenant override)
- A "Refresh from Graph" button to pick up newly created labels
Discovery is cached for 5 minutes; the refresh button bypasses the cache. The catalog endpoint surfaces the label's display name, description, GUID, and parent label (Microsoft's hierarchy is preserved).
Audit & Forensic Replay
Every Purview-classified file row in the platform's file_attachments table records:
- The C-level the label mapped to
- The
labelIdanddisplayNamefrom the customer's Purview tenant - The source surface (
drivefor SharePoint/OneDrive,messagefor Outlook) - The timestamp at which Microsoft Graph was queried
- A flag indicating whether the Purview level won the merge against internal DLP
When a file is withheld from an agent prompt by the C-level gate, the platform's audit chain captures the full chain: which agent tried to inject which file, which Purview label triggered the C-level decision, and which row of the C1-C4 matrix said "block." Forensic replay against this trail satisfies EU AI Act Article 12 logging requirements and DORA Article 17 ICT-related-incident traceability.
Prerequisites
Tenants need Microsoft Graph application credentials configured in the platform vault:
MS_TENANT_ID-- Azure AD tenant IDMS_CLIENT_ID-- Application (client) IDMS_CLIENT_SECRET-- Client secret value
These are the same credentials used by mailbox push integration. Required Graph application permissions:
Files.Read.All-- read drive item extensions (where Purview embeds the label on SharePoint/OneDrive items)Mail.Read-- read assigned labels on Outlook messagesInformationProtectionPolicy.Read.All-- discover the tenant's full label catalog
Without these, the integration is a graceful no-op: the admin card surfaces "Graph not configured," and uploaded files fall through to the internal DLP path.
What Is NOT Included
This integration is read-only. MeetLoyd reads labels from M365 -- it does not write labels back, and it does not decrypt Purview-encrypted files. Both require the Microsoft Information Protection (MIP) SDK, which is a heavier deployment dependency typically provisioned only when a customer has a contract requirement for it.
If your organization needs MeetLoyd-generated content (e.g. agent-drafted reports, exported transcripts) to be stamped with a Purview label before being written back to SharePoint or sent through Outlook, this is on the roadmap as a customer-pull-driven extension. Contact your account team if it's a procurement requirement.
EU AI Act & DORA Alignment
| Requirement | How Purview Integration Satisfies It |
|---|---|
| EU AI Act Art. 14 (human oversight) | The CISO's existing Purview policy drives AI-platform enforcement -- no parallel decision surface for an operator to monitor |
| EU AI Act Art. 12 (logging) | Every classification decision and every C-level gate decision records the original Purview label for forensic replay |
| DORA Art. 17 (incident detection) | Audit chain captures Purview label provenance, supporting traceability to the original M365 incident scope |
| GDPR Art. 32 (security of processing) | Customer-classified high-sensitivity data inherits stricter handling automatically; no operator action needed for new sensitivity classes |
Pricing
| Component | Starter | Growth | Enterprise |
|---|---|---|---|
| Read-only label inheritance from M365 | -- | Included | Included |
| Pre-LLM enforcement via C1-C4 matrix | Included | Included | Included |
| Label catalog discovery + admin UI | -- | Included | Included |
| MIP SDK label write-back / decryption | -- | -- | On request |