Microsoft's Network DLP Now Watches AI Agent Uploads. Roll It Out in Audit Mode

TL;DR

• Microsoft's September 2026 security roundup moves Purview data loss prevention into the network path: Microsoft Entra Global Secure Access now routes matching traffic to Purview for classification, real-time when a DLP policy enforces.
• The agent-relevant part is what Microsoft's own roundup claims: coverage of on-behalf-of (OBO) traffic — requests an AI agent makes using a user's identity. An agent uploading a sensitive document to an unsanctioned AI tool now hits the same network enforcement point as the user.
• Licensing is the first gate: Microsoft 365 E7, or Purview E5 plus Entra Internet Access. Pay-as-you-go is required only for third-party SASE integrations.
• The limits matter more than the headline: 3 MB file and 4 MB text inspection caps, no B2B guest coverage, up to 24 hours for a policy to reach the network service, and no UDP traffic, so QUIC is not supported (sites fall back to TCP).
• The Netics read: start with the DSPM detection policy, pilot in audit mode, and switch Block on for a narrow, high-confidence scope — not the other way round.

Microsoft's September 2026 security roundup, published September 24, contains one change most tenants will need to weigh: Purview network data security on Entra Global Secure Access is now the enforcement point for data leaving the network. Microsoft's own September 24 "In the Loop" roundup post describes the network-layer DLP as bringing data security to the network "across human actions and on-behalf-of (OBO) agentic traffic"; the Microsoft Learn documentation itself, last updated September 16, 2026, describes the two-service exchange — Global Secure Access watches traffic and sends matching content to Purview for classification and policy evaluation — without using the on-behalf-of framing. When a DLP policy is enforcing, the exchange happens in real time; collection policies for discovery run asynchronously.

The four monitored activities are text sent to a cloud or AI app, files uploaded, text received, and files downloaded. Global Secure Access supports all four with the two available actions, Audit only and Block. Scope is broad: policies can target any app in the Microsoft Defender for Cloud Apps catalog — more than 35,000 apps — or adaptive app scopes covering whole categories such as generative AI, cloud storage, webmail, and social networks.

Licensing is where most evaluations will stop first. The documentation states two paths: Microsoft 365 E7 per-seat licenses, or Purview E5 (or equivalent) plus Entra Internet Access (or equivalent). Pay-as-you-go billing is not needed for the Global Secure Access integration, but it is required if you connect third-party SASE or secure-browser products instead, which are billed per network request.

The OBO case is the part worth testing first

The on-behalf-of (OBO) coverage is the reason this belongs in the agent conversation. Traditional DLP assumed a human at a browser. Agents blur that assumption: a request an AI agent makes with a user's identity looks like the user's traffic to every downstream system, but no human reviewed it. Microsoft's own roundup post puts the example in these terms: "if an employee or OBO agent tries to upload a sensitive document to an unsanctioned AI tool, the policy can stop the transfer before the data leaves", and says the capability is "Now generally available" for "human actions and on-behalf-of (OBO) agentic traffic". Microsoft's Global Secure Access content-policy documentation, also linked in the Sources section, frames this feature around agents: content policies "provide real-time control over what users and agents share with generative AI applications", and a rule can be scoped by setting the session type condition to Agent, which matches "traffic classified as AI agent traffic". Windows Forum's coverage of the roundup lists the item as "Network-layer DLP for human and on-behalf-of agent traffic", status "Generally available". The Purview Learn page itself does not use the terms "agent" or "on-behalf-of"; the OBO label and the GA status come from Microsoft's roundup post, corroborated by that coverage.

That is a real enforcement gain, and it is also where the semantics deserve scrutiny. Network-layer DLP sees the bytes leaving; it does not see the agent's intent, the prompt that produced the upload, or the chain of tool calls behind it. What it buys a security team is a hard boundary on exfiltration paths. What it does not buy is visibility into which agent misbehaved — that still lives in the agent's own logs and identity layer. Teams that treat network DLP as the whole agent-governance story will replicate the gap this blog flagged in the agent access-graphs discussion: enforcement without identity mapping is a fence, not a governance model.

One practical note from the documentation: if the consumer and enterprise versions of an app share a URL, as ChatGPT's do, a policy aimed at the unmanaged app can catch traffic to both. Some AI apps, including Runway and Meta AI, sometimes send content in encoded form to dynamically generated endpoints, which can interfere with enforcement. Test these against your own catalog before promising a complete block.

The limits that shape a real rollout

The documentation lists several constraints that determine whether this is a pilot tool or a production control, and they deserve equal billing with the headline:

• Content inspection is capped at 4 MB for text and 3 MB for files. The documentation does not say what happens to larger payloads, so test that before relying on a block policy.
• Network data security policies do not apply to B2B guest users. Contractor-heavy organizations will need a separate control for that population.
• After setup, a policy can take up to 24 hours to reach the network service, and individual events can take up to 30 minutes to appear in the audit log and activity explorer.
• Content policies do not support UDP traffic, including QUIC; most websites fall back to TCP, and Microsoft recommends a firewall rule that blocks outbound UDP 443. Coverage spans HTTP and HTTPS; WebSocket support depends on the integration.
• Basic content policy (block or allow by file MIME type) needs no Purview license; the Scan with Purview action that performs actual content inspection requires Purview DLP licensing and a matching DLP policy.

The licensing distinction is the most load-bearing detail for any compliance review: the roundup headline says network DLP is broadly available, but the content-scanning action that makes it a DLP product rather than a MIME filter requires a Purview DLP license on top of the Global Secure Access deployment. Read the licensing notes for your own tenant, not the marketing summary.

The rollout sequence that avoids a false-start Block

The recommended sequence in Microsoft's own documentation matches what this blog has argued for bounded AI controls: measurement before blocking.

• Start with the one-click Data Security Posture Management policy, "DSPM for AI — Detect sensitive info shared with AI via network." It detects without blocking, and it is the lowest-risk way to see what your traffic actually contains.
• Run that in collection mode until you know which apps, users, and agent identities generate the sensitive text and file flows. The asynchronous collection path feeds Activity Explorer and DSPM for AI.
• Then enable a DLP policy in Audit mode for a narrow scope — one high-risk user group, one sensitive-information type, one destination category like unmanaged AI apps.
• Only after the audit data shows matches that match your risk model should Block be turned on, and even then for the narrow scope first.

The reason for that sequence is not caution for its own sake; it is that the limits (3 MB/4 MB caps, no B2B coverage, 24-hour propagation, no QUIC) mean a broad Block policy will fail loudly in ways that damage user trust and occupy the DLP and identity teams simultaneously. A narrow audit-first rollout produces the evidence to justify the narrower Block scope.

What the September roundup does not say

The Microsoft security roundup's headline promises more on AI agents than it delivers — the list is mostly data governance for the Copilot era. The one concrete agent-facing change is the on-behalf-of (OBO) network DLP coverage the roundup describes. Nothing in the September list is a tool for finding agents running on endpoints; that is still endpoint-detection territory. Teams that read the roundup as a full agent-governance signal will overestimate the control surface. The roundup's real message is narrower and more useful: the network layer is now a Purview enforcement plane for data loss, and agents are included in the flows it can police.

The next showcase for more agent-focused controls is Ignite, November 17–20, 2026, in San Francisco. That is the correct place to look for endpoint-side agent discovery and a wider enforcement surface.

Sources

This article is grounded in the Purview Network Data Security documentation (updated September 16, 2026), the Global Secure Access content-policy article, Microsoft's own September 2026 "In the Loop" security roundup (Microsoft Security Blog, September 24, 2026), and Windows Forum's coverage of that roundup (September 24, 2026). The licensing, limits, and protocol details cited here come from the Learn pages; the agent-traffic (OBO) framing and the generally-available status come from Microsoft's own roundup post, corroborated by Windows Forum's coverage. All pages were fetched on September 26, 2026.

Source: Microsoft Learn — learn.microsoft.com, documentation updated 2026-09-16; Microsoft Security Blog "In the Loop", 2026-09-24.

Explore the Netics approach to data security and AI operations