How to Guard Streaming AI Agents with Microsoft Purview Policies

In this blog post How to Guard Streaming AI Agents with Microsoft Purview Policies we will explain how to stop sensitive information escaping while an AI agent sends its answer to a user in real time.

Streaming makes an AI assistant feel fast because words appear as they are generated. The risk is that confidential content may already be on screen before your security policy has inspected the complete answer.

Microsoft Agent Framework helps organisations build and operate AI agents using .NET or Python. Microsoft Purview, Microsoft’s data security and compliance platform, can sit in the agent’s processing path and check prompts and responses against centrally managed rules.

Why streaming changes the security problem

With a normal AI response, the application can wait for the complete answer, inspect it and then decide whether to display it. A streaming agent sends small pieces of the response to the browser as they arrive.

Imagine an HR assistant preparing a summary about salary reviews. The first few streamed sentences may be harmless, but a later section could include employee names, salaries or health information pulled from an internal document.

If those early response fragments have already reached the user, deleting the message at the end is too late. Screenshots, browser logs and connected applications may have retained the information.

This is why streaming guardrails must control what leaves the agent, not simply review the final transcript.

How Purview policy enforcement works

Microsoft Purview can apply data loss prevention rules, commonly called DLP rules. These are policies that identify sensitive information and decide whether it should be allowed, recorded, restricted or blocked.

The policies can look for recognised information types such as payment card numbers, passport details and health data. They can also use sensitivity labels, which are tags such as Public, Internal or Highly Confidential applied to Microsoft 365 files and emails.

Microsoft Agent Framework supports middleware, which is a checkpoint placed between the user, the AI model and the final application. Purview middleware can inspect the incoming prompt and the generated response without forcing every development team to write its own detection system.

If you are still planning the wider platform, our guide to building production AI agents with Microsoft Agent Framework and .NET explains the underlying application structure.

Five policy patterns that work in practice

1. Check the prompt before it reaches the model

The first checkpoint should inspect the user’s prompt and relevant conversation history. This reduces the chance of staff submitting customer lists, credentials, legal documents or other restricted information to an agent that is not approved to process it.

Low-risk content can continue normally. Higher-risk content can be blocked with a useful explanation, rather than a vague error message.

For example, tell the user that the request contains payroll information and must be handled through the approved HR workflow. This turns a security control into practical guidance instead of an obstacle employees try to bypass.

2. Buffer the response before releasing the stream

For sensitive business agents, the safest pattern is to temporarily hold the complete response, evaluate it and only then release it to the user. Current Purview integration for Microsoft Agent Framework supports full-buffer policy evaluation for streamed responses.

This creates a small delay, but it prevents a confidential sentence from appearing before the policy decision is complete. The interface can display a message such as “Checking this response against company data policy” so the user understands what is happening.

Not every agent needs this treatment. A public website assistant answering questions from approved marketing content may accept more immediate streaming. An HR, finance, legal or customer-data agent generally should not.

3. Put controls close to the model connection

Purview can be added at the overall agent level or around the chat client, which is the component that communicates with the AI model. For strong response control, we generally prefer enforcement close to that model connection.

This helps ensure a blocked response is stopped before it is displayed or stored in conversation history. Otherwise, an unsafe answer may be hidden from the current screen but remain available to a later conversation turn.

The following simplified C# pattern shows the intended structure. Microsoft’s integration remains in preview, so package versions and behaviour should be tested before production rollout.

// Simplified example for architectural guidance
TokenCredential purviewCredential =
 GetApprovedPurviewCredentialForCurrentUser();

IChatClient protectedClient = rawChatClient
 .AsBuilder()
 .WithPurview(
 purviewCredential,
 new PurviewSettings("Finance Assistant"))
 .Build();

AIAgent agent = protectedClient.AsAIAgent(
 instructions: "Help authorised finance staff analyse approved data.");

await foreach (AgentResponseUpdate update in
 agent.RunStreamingAsync(prompt, session, cancellationToken: ct))
{
 await userInterface.SendAsync(update.ToString(), ct);
}

The important point is not the exact syntax. It is that policy enforcement sits inside the response path, rather than being added later as a reporting feature.

4. Keep tool permissions separate from data policy

Purview can decide whether content should move through the agent, but it should not be your only guardrail. It does not replace normal access controls or approval processes.

An agent that can read a customer record should not automatically be allowed to update it. An agent that drafts a payment request should not be able to approve the payment.

Use explicit tool permissions, limited user access and human approval for high-impact actions. Our article on designing a secure control plane for enterprise AI agents covers these broader controls in more detail.

5. Decide what happens when policy checks fail

Many teams design for a blocked response but forget to design for an unavailable policy service. If Purview cannot return a decision, should the agent continue, retry or stop?

For a public knowledge assistant, a short retry followed by a restricted response may be reasonable. For payroll, healthcare or legal data, the safer choice is usually to stop and record the event.

This is known as failing closed. It means the business accepts temporary inconvenience rather than releasing information without a completed security check.

A realistic business scenario

Consider a 200-person professional services firm introducing an agent that searches project documents and drafts client updates. Without proper controls, a consultant could ask a reasonable question and receive information copied from another client’s commercially sensitive file.

A practical policy design would block highly confidential labelled documents, inspect prompts for personal and financial information, buffer responses before display and require human approval before anything is emailed externally.

The business outcome is clear. Staff still save time finding and summarising information, but the firm reduces the chance of a privacy incident, contractual breach or damaging client conversation.

What CIOs should ask before approving streaming

• Which agents are allowed to stream responses immediately?
• Which data types and sensitivity labels must trigger blocking?
• Is policy evaluated using the real user’s identity or a shared service account?
• Can blocked content remain in conversation history or application logs?
• What happens if the policy service is slow or unavailable?
• Are policy decisions, overrides and failed checks retained for investigation?
• Have security, privacy and business owners tested realistic scenarios?

These controls also support broader Australian governance obligations. The Essential 8, the Australian government’s cybersecurity framework, does not provide a complete AI policy, but its focus on controlled access, application security and administrative discipline remains highly relevant.

Organisations should also consider their obligations under Australian privacy legislation when agents process personal information. Purview can provide useful controls and evidence, but technology cannot replace a clear purpose, appropriate access and accountable data handling.

Build guardrails before users depend on the agent

The best time to add streaming controls is before the agent becomes part of daily work. Retrofitting them later can change response times, application design and how conversation history is stored.

Purview provides a strong policy layer, but it works best alongside identity controls, limited tool access, monitoring and human approval. You also need an operating model for investigating blocks and tuning false positives, as covered in our guide to operationalising Microsoft Agent Framework in production.

CloudProInc brings more than 20 years of enterprise IT experience to this work. As a Melbourne-based Microsoft Partner and Wiz Security Integrator, we help organisations connect Azure, Microsoft 365, Purview, Defender and AI services without turning the project into a giant, faceless consulting exercise.

If you are unsure whether your streaming agent can expose information before its controls react, we are happy to review the design and point out the practical gaps — no strings attached.