Microsoft Purview Agent Framework SDK GA Delayed to March 2027: DLP Setup and Oversharing Limits

That GA date has been pushed back more than once. Developers can already use the integration today, though, so the date matters less than the roadmap entry suggests.

The release dates keep moving​

There are three snapshots of the schedule, and they don't agree:

The third-party M365 Admin tracker mirrored an earlier version of the roadmap entry. It listed the Release date: March CY2026 Preview date: November CY2025. The Message Center post for the same roadmap ID was later mirrored by msmessagecenter.com. It said GA would begin rolling out in September 2026 (previously late-May) and expect to complete by end of September 2026 (previously late-June). September has now passed and the roadmap shows March 2027. By roadmap estimates alone, GA is about a year later than first planned.

The preview has been available for a while. Microsoft's Security Community blog says that at Microsoft Ignite, we announced the public preview of Purview integration with the Agent Framework SDK. Microsoft Learn's integration page was last updated on October 5, 2026, and it already gives working code, package names and setup steps. The .NET package README on GitHub still shows Status: Preview.

In practice, you can build against this now as preview software. Microsoft's roadmap itself warns that all dates are estimates and subject to change. Production SLAs and GA support guarantees are a different matter.

Section summary: The preview has been public since Ignite. GA has slipped from March 2026 to September 2026 to the current March 2027 estimate.

What the integration actually does​

The roadmap description promises "automatic classification and protection of sensitive data" and prevention of "data leaks and oversharing." Microsoft's developer documentation describes something narrower and more specific.

The integration is policy middleware. You add it to the middleware pipeline of an agent built with Microsoft Agent Framework. It intercepts prompts and responses, sends them to Purview to be checked against your organization's configured policies, and enforces the result. Microsoft Learn says it covers both end-user chat and agent-to-agent traffic.

Microsoft lists three main uses:

• Preventing sensitive data leaks: content can be blocked inline based on Purview DLP policies.
• Governance logging: AI interactions can feed Audit, Communication Compliance, Insider Risk Management, eDiscovery and Data Lifecycle Management.
• Faster adoption: compliance teams often won't approve AI apps that lack these controls, and this gives them what they need.

The GitHub README describes the .NET plugin as applying policies on both the prompt (user input + conversation history) and the model response before they proceed further in your workflow. It supports middleware-based policy enforcement (agent-level and chat-client level). Microsoft's blog also highlights workflow-level enforcement across orchestration steps for multi-agent designs.

The oversharing caveat​

Microsoft's own Purview developer guidance includes a scenario comparison table, and it qualifies the roadmap claim:

The Agent Framework middleware alone does not prevent oversharing, meaning it does not stop an agent from showing users documents they aren't entitled to see. For that, Microsoft points developers to the Purview sensitivity-label APIs, or to Azure AI Search with Purview label indexing turned on. With indexing on, Azure AI Search checks label metadata at query time and returns only results the requesting user can access.

The roadmap's "prevents oversharing" line therefore describes what the wider Purview developer stack can do, not what this SDK does by itself. If your agent uses retrieval-augmented generation over SharePoint content, you still need to handle authorization in the retrieval layer.

Section summary: The middleware does DLP enforcement and compliance logging. Preventing oversharing requires separate label-aware retrieval.

How to set it up​

This is a code-level integration for developers, not a no-code switch for Copilot Studio. Microsoft has a separate preview for that: inline DLP for Copilot Studio agents.

Prerequisites (per Microsoft Learn)​

1. An Azure subscription with Microsoft Purview configured.
2. A Microsoft 365 subscription with an E5 license and pay-as-you-go billing set up. Microsoft says a Microsoft 365 Developer Program tenant works for testing.
3. The Agent Framework SDK. For Python, run pip install agent-framework. For .NET, install the Microsoft.Agents.AI.Purview package from NuGet.

Step 1: Add the middleware​

• .NET: Microsoft's sample builds an AIAgent and calls .AsBuilder().WithPurview(credential, new PurviewSettings("My Secure Agent")).Build().
• Python: create a PurviewPolicyMiddleware, imported from agent_framework.microsoft, with a credential and PurviewSettings(app_name=...). Pass it into the Agent through the middleware list.

The samples use InteractiveBrowserCredential together with Azure OpenAI environment variables. These are choices made for the demo, not requirements. Microsoft's own warning notes that DefaultAzureCredential suits development, while production should use a specific credential such as ManagedIdentityCredential.

Step 2: Register the agent in Entra ID​

Register the agent as an application and add these Microsoft Graph permissions to its service principal:

• ProtectionScopes.Compute.All
• ContentActivity.Write
• Content.Process.All

Step 3: Configure Purview policies​

Use the Entra app ID from Step 2 to configure Purview policies, so the agent's traffic actually reaches Purview. To create a test DLP policy, Microsoft's developer guidance points to the New-DlpComplianceRule cmdlet.

What success looks like​

Microsoft's blog describes the runtime flow. Content passes through the pipeline, Purview checks it, and a decision is returned: allow, redact, or block, and governance signals are logged. In testing, a prompt that matches your DLP rule should be blocked or replaced, and the interaction should show up in Purview's audit and compliance tools.

Section summary: Getting this working takes three things: the code, the Entra registration with Graph permissions, and Purview policies tied to the app ID. Installing the package alone does nothing.

Python details that matter​

The current Microsoft Learn page adds behavioral detail for Python that administrators and developers should read closely:

• Everything gets evaluated. Text and reasoning text are checked as text. Base64 data URIs are checked as binary. Function calls, function results and other structured content are serialized to text so they aren't skipped. Only empty content and usage content are left out.
• It fails closed. If the middleware can't resolve a user ID, tenant or application location, policy evaluation fails. Microsoft says identity should come from a validated server-side token, not from message fields the caller controls. That's sound advice, since otherwise a user could claim to be someone else.
• ignore_exceptions turns off enforcement. Microsoft says setting it bypasses enforcement for every error. Only use it if you have deliberately decided availability matters more than compliance.
• Streaming is buffered. Both middleware types hold the full streamed response and evaluate it before releasing anything, so users won't see token-by-token output while Purview is attached.

Agent middleware or chat middleware?​

Python has two options, and the difference matters for security:

Microsoft recommends the chat middleware when DLP has to cover the complete model request. In either case, put the Purview middleware last in the list so no later middleware can change content after Purview has checked it.

Here's an example of why that matters. A retrieval tool pulls a customer record containing a credit card number into context. Agent-level middleware won't see that before the model call, but chat-level middleware will.

Section summary: For agents that use tools, chat-level middleware placed last gives the most complete coverage. Expect buffered streaming and fail-closed behavior.

Language support and related paths​

Today the integration supports .NET and Python. Microsoft Learn says Go support is "coming soon," so don't plan around it yet.

Microsoft Foundry also has a native Purview integration. An Azure admin turns it on per subscription and developers don't need to change any code. It covers runtime governance, but Microsoft's table marks DLP and insider-risk protection as unsupported on that path. If you need inline blocking, Foundry's native setting isn't enough, and you'll need Agent Framework middleware or direct calls to the Purview APIs.

Analysis: who should care​

According to msmessagecenter.com's mirror of MC1302905, Microsoft says it affects organizations building or planning to build AI agents using the Microsoft Agent Framework SDK. If you don't build custom agents, there's nothing to do.

If you do, my take, based on general industry experience: this is a sensible design. Putting policy enforcement inside the agent runtime is far better than finding leaks in an audit log three weeks later. Teams should keep these costs in mind:

• Licensing: E5 plus pay-as-you-go billing is a real cost, not a technicality.
• Latency: buffered streaming changes how responsive your agent feels, so let your UX team know.
• Schedule risk: GA has slipped twice. If your compliance program requires GA-supported components, plan for March 2027 or later.

DLP for AI agents isn't optional anymore. The Purview middleware is a solid preview-stage answer for teams building on Agent Framework, but it doesn't handle oversharing, and the GA date is still moving.