Securing and governing AI agents with Microsoft Purview

In this ebook, I provide an example of how a large enterprise can use Microsoft Purview as the data security and compliance layer for AI agents, together with Microsoft Entra for identity and access, Microsoft Defender for security and runtime protection, and Microsoft 365 agent management capabilities for inventory and lifecycle governance.

Executive summary

AI agents introduce a different security challenge from traditional applications. An agent can access information, reason over it, call tools and potentially take actions on behalf of a user or the organization. No single Microsoft product controls all of this.

Microsoft Purview provides the data security and compliance layer. It can help organizations identify sensitive information involved in AI interactions, prevent inappropriate data movement, monitor activity, identify risky AI usage, retain relevant interactions and support investigations and eDiscovery.

Microsoft Entra provides the identity and access layer. Where supported, Entra Agent ID gives an agent its own identity so organizations can authenticate it, govern its permissions and apply lifecycle controls.

Microsoft Defender helps address security risks around AI applications and agents. Defender for Cloud Apps can help organizations discover and assess cloud-based AI services and identify services that should be unsanctioned. Together with Defender for Endpoint, organizations can block access to unsanctioned services from managed devices. Defender also provides threat detection and, for supported agents, runtime protection against risks such as prompt injection and unsafe tool activity.

Microsoft 365 also provides an Agent Registry for maintaining an inventory of agents and performing basic governance and lifecycle actions. Microsoft Agent 365 adds more advanced agent-specific capabilities across the Microsoft 365 admin center, Entra, Purview, Defender and Intune.

A practical governance model therefore starts with the problem rather than the product.

If an agent can access information it should not see, investigate its identity and the permissions on the source system. If a user is accessing a risky or unapproved AI service, Defender can help identify and block that service. If an approved AI service is being used inappropriately with sensitive information, Purview DLP provides the data control. If an agent behaves suspiciously or is manipulated through prompt injection, Defender becomes important. If prompts, responses or agent activity need to be investigated, retained or produced as evidence, Purview provides the compliance controls where the interaction is supported.

Background

A large enterprise is expanding its use of AI agents across the business.

Employees use Microsoft 365 Copilot and agents to improve productivity. Development teams build custom agents. Business teams are beginning to connect agents to enterprise systems and information. At the same time, employees use third-party AI services such as ChatGPT and Google Gemini.

The benefits are significant. Agents can automate repetitive work, retrieve information from several systems and perform activities that previously required multiple applications and manual steps.

They also change the risk picture.

A traditional application normally performs a relatively predictable set of functions. An AI agent can interpret instructions, retrieve information, interact with tools and make decisions about what to do next. If its permissions are excessive, or the information it can reach is already overshared, the agent can amplify an existing security problem.

The organization already uses Microsoft Purview for information protection, Data Loss Prevention, Audit, Insider Risk Management, Communication Compliance, eDiscovery and Data Lifecycle Management. The objective is therefore not to create a completely separate data governance framework for AI, but to extend existing controls to AI and agent scenarios.

That does not mean every AI control belongs in Purview. A good architecture distinguishes between four areas:

• Agent inventory and lifecycle management — Which agents exist, who owns them and whether they should remain active.
• Identity and access — How the agent authenticates and which resources it is allowed to use.
• Data security and compliance — Which sensitive information the agent interacts with, how data movement is controlled, and what evidence must be retained.
• Security and runtime protection — Whether an AI service is trusted, whether access to it should be allowed, and whether an agent is behaving maliciously, has been compromised or is attempting unsafe actions.

Business challenge

Users accessing risky AI services or copying sensitive information into AI

An employee accesses an AI website and attempts to paste customer information, financial data, source code, credentials or confidential project information into it.

There are two separate questions to address.

First, should the AI service be accessible at all? Defender for Cloud Apps can help organizations discover cloud applications, assess their risk and mark inappropriate AI services as unsanctioned. When integrated with Defender for Endpoint, access to unsanctioned cloud services can be blocked from managed devices.

Second, if the AI service is approved, what information should users be allowed to send to it? This is where Microsoft Purview DLP becomes important.

Microsoft Purview DLP provides the policy framework for detecting and protecting sensitive information across supported Microsoft 365 locations and endpoints. For managed devices, a DLP policy that includes the Devices location uses Endpoint DLP capabilities to monitor or restrict activities on the endpoint. These include controls such as Paste to supported browsers and Upload to a restricted cloud service domain.

Purview DLP does not require content to have a sensitivity label before it can be protected. Policies can detect sensitive information using Sensitive Information Types (SITs), trainable classifiers and other supported conditions. Sensitivity labels can also be used as a condition where appropriate.

This is particularly relevant for browser-based AI. Endpoint DLP can evaluate content being pasted into a supported browser independently of how the source item was classified. Sensitive information can therefore be detected and controlled even if the source document does not have a sensitivity label.

The distinction between Purview DLP and Endpoint DLP is also important. They are not two separate DLP products. Purview DLP provides the overall policy framework, while Endpoint DLP provides device-level inspection and enforcement for policies that include the Devices location.

The two security layers therefore solve different problems:

• Defender controls whether the AI service should be accessed.
• Purview DLP controls what sensitive information can be sent to services that users are allowed to access.

Users uploading sensitive files to external AI tools

An employee uploads a sensitive document to an approved AI service to summarize, translate or analyze it.

On a managed endpoint, a Purview DLP policy scoped to Devices can use Endpoint DLP controls to audit, warn, block or allow with override when protected information is uploaded to a configured sensitive service domain.

Microsoft also provides a predefined Generative AI Websites group that can be used in Endpoint DLP scenarios.

Again, the policy does not need to depend on a sensitivity label. A file can be identified as sensitive because of its actual content, for example because it contains credentials, personal information, financial information or source code detected through supported classifiers.

The objective is to protect the information, not simply files that happen to have a particular label.

Third-party AI applications installed on laptops

An employee installs an AI assistant, browser extension, coding assistant or desktop utility that can access local information.

The first question is whether that application should be allowed to run at all. That is primarily an endpoint-management and security question. Defender and endpoint management controls can assess application risk and identify suspicious behavior.

Purview becomes relevant when the application interacts with sensitive data. Endpoint DLP can restrict supported actions involving sensitive information, including movement to applications, browsers and cloud destinations.

A simple distinction is useful:

• Defender and endpoint management help determine whether the application should be running.
• Purview DLP helps determine what users and applications are allowed to do with sensitive information on managed endpoints.

Agents with too much access

An agent retrieves information from SharePoint, OneDrive, email or another enterprise system and exposes more information than the business intended.

This is first an access problem. The organization needs to understand why the agent can retrieve the information. The agent itself may have excessive permissions, or the source data may already be available too broadly.

The answer should not be to compensate for excessive permissions with more sensitivity labels. Where an agent has its own identity, its access should be reduced to the minimum required. Where SharePoint, OneDrive or another source is overshared, those permissions should be corrected at source.

Sensitivity labels remain useful for classification and protection, and encryption can impose additional access restrictions. They should complement the identity and source-permission model rather than become the primary mechanism for granting an agent access.

Prompt injection and unsafe agent actions

Agents may process malicious instructions contained in prompts, email, documents, websites or tool responses.

Purview Insider Risk Management includes a Risky AI usage policy template that can identify risky AI usage, including signals related to prompt-injection attacks and attempts to access protected materials.

That is different from runtime protection. For supported agents, Microsoft Defender provides threat-detection capabilities and runtime security controls that can help detect malicious prompt injection, suspicious behavior and unsafe agent actions.

Communication Compliance has a different purpose. It can identify regulatory, conduct and inappropriate-communication issues in supported AI interactions. It should not be positioned as the main control for detecting or preventing prompt-injection attacks.

Compliance teams lacking evidence

Prompts, responses and agent interactions may later be relevant to an investigation, regulatory request or legal matter.

Purview Audit, eDiscovery and Data Lifecycle Management can provide this evidence for supported interactions.

The exact coverage is important. For Agent 365, Microsoft documents Audit support across a broader range of interaction types than eDiscovery and retention. Organizations should therefore check the current support matrix rather than assume that everything visible in Audit can automatically be searched, preserved or retained in the same way.

How the controls fit together

A useful way to decide where to start is to look at the problem that needs to be solved.

In most real environments, several of these controls will work together. The distinction matters because it avoids trying to solve an access problem with DLP, a risky website problem with information classification, or a runtime attack with a sensitivity label.

1. Establish an inventory of agents

Before an organization can govern AI agents, it needs to know which agents exist.

The Microsoft 365 admin center includes an Agent Registry, which provides inventory and governance capabilities for agents across the organization.

An important licensing distinction is that the Agent Registry itself is not exclusive to the Microsoft Agent 365 license. Microsoft's current service description shows that inventory and several basic governance capabilities are available with eligible Microsoft 365 plans.

The Agent Registry should therefore be the primary place to establish the enterprise inventory of agents.

Purview DSPM has a different purpose. DSPM AI observability can provide visibility into agent activity and the associated data-security risks. This can help security teams understand which agents are interacting with sensitive information and where those interactions may create additional exposure.

That makes DSPM valuable, but it should not be treated as the organization's authoritative inventory of agents.

A useful distinction is:

• The Agent Registry answers: Which agents do we have?
• Purview DSPM answers: What data-security risks can we see around their activity?

2. Give agents an identity

Once an agent is known, the organization needs to understand how it authenticates.

Microsoft Entra Agent ID introduces a purpose-built identity model for AI agents. An agent identity is a special type of service principal in Microsoft Entra ID that uniquely represents an individual AI agent. The identity can be used when the agent authenticates to systems and participates in authorization decisions.

Agent identities are created from an agent identity blueprint. The blueprint provides a reusable definition for a particular type of agent.

For example, a company might develop a Sales Assistant and deploy instances of that agent for several business units. Individual instances can have their own agent identities while sharing the same blueprint. This makes it possible to manage controls consistently across agents of the same type. Microsoft gives examples such as applying Conditional Access, disabling agents created from a particular blueprint and revoking permission grants.

Accountability is also built into the model. Microsoft requires a sponsor when an agent identity or agent identity blueprint is created. Sponsors represent the people or groups accountable for the agent. Owners are separate and can provide technical administrative control of the identity.

Some systems still require a normal Entra user account rather than an agent identity. Microsoft therefore also supports an optional agent user account linked one-to-one with the agent identity. This gives organizations a clearer way to distinguish human users, applications and agents when applying identity and access controls.

3. Control what agents can access

An agent should receive only the access required to perform its intended function.

The first layer is identity and source permissions. The agent's Entra identity establishes who or what is making the request. Permissions on SharePoint, OneDrive and other systems determine which resources that identity can use.

The exact authorization model can vary. An agent may operate autonomously using permissions granted directly to its own identity, or it may act on behalf of a user using delegated access.

If an agent can see information it does not need, the first response should therefore be to investigate the permissions and authorization model. That might mean reducing access granted to the agent, correcting group membership, removing unnecessary sharing links or fixing permissions on the repository itself.

Purview can help identify the data risk created by those permissions. DSPM data-risk assessments can identify and monitor potential oversharing, including risky SharePoint exposure.

Where sensitivity labels fit. Sensitivity labels remain important, but they solve a different problem. Labels can classify information and, where encryption is configured, apply additional protection and usage restrictions.

For supported Agent 365 scenarios, an agent still needs access to the underlying information. If a sensitivity label applies encryption, the agent also needs the appropriate rights to use that encrypted information. This demonstrates why identity, permissions and information protection should be treated as separate layers.

The recommended principle is: use identity and source permissions to establish what an agent is entitled to access. Use sensitivity labels and encryption as an additional protection layer where appropriate. Sensitivity labels should therefore not be used as a substitute for fixing excessive agent or source permissions.

4. Prevent sensitive information from being sent to AI services

For many organizations, one of the most immediate AI risks is not an autonomous agent at all. It is an employee accessing an AI website and pasting or uploading corporate information.

There are two controls to consider.

Block AI services that should not be used. The first decision is whether employees should have access to the service. Defender for Cloud Apps can provide visibility into cloud applications being used by the organization and help security teams assess their risk. AI services that do not meet company requirements can be marked as unsanctioned. When Defender for Cloud Apps is integrated with Defender for Endpoint, access to unsanctioned cloud applications can be blocked on managed endpoints. This is useful for services that the organization does not want employees to use at all.

Protect data when approved AI services are used. An approved AI service can still create data-security risk. A user may have a legitimate reason to use ChatGPT, Gemini or another approved service but should not necessarily be able to paste customer data, credentials, source code or confidential business information into it. This is where Microsoft Purview DLP applies.

A DLP policy can identify sensitive information using conditions such as:

• Sensitive Information Types
• trainable classifiers
• sensitivity labels
• other supported contextual and content conditions

For managed endpoints, the policy includes the Devices location and Endpoint DLP provides device-level enforcement. Relevant Endpoint DLP activities include:

• Paste to supported browsers
• Upload to a restricted cloud service domain

Depending on policy design, organizations can audit the activity, warn the user, allow an override or block the action.

One particularly useful capability is that Endpoint DLP evaluates content being pasted into a supported browser independently of how the original item was classified. For example, an employee may open an unlabeled document containing confidential customer information and paste a paragraph into an approved AI website. A DLP policy can still detect sensitive information within that pasted content and apply the configured action. A sensitivity label is therefore one possible DLP condition, but it is not a prerequisite for DLP protection.

The overall model becomes:

• Unsanctioned or risky AI service → Defender can block access.
• Approved AI service and inappropriate sensitive data → Purview DLP can control the data movement.

That distinction is important because the objective is not necessarily to block AI. It is to enable approved AI use without allowing sensitive information to move to inappropriate destinations.

5. Reduce risk from third-party AI applications

The same principle applies to AI software running locally.

Purview is not the primary technology for deciding whether an unknown desktop AI application is trusted. Defender and endpoint-management technologies should be used to assess and control application and runtime risk.

Purview Endpoint DLP becomes relevant when sensitive information moves through the application. For managed endpoints, DLP policies can monitor and restrict supported file and browser activities involving sensitive data.

This makes the split straightforward:

• Defender asks whether the application or agent presents a security threat.
• Purview DLP asks whether sensitive information is being handled in a way that violates data policy.

For supported AI agent scenarios, Defender can also provide runtime protection against threats such as prompt injection and risky tool activity.

6. Monitor and investigate AI and agent activity

Organizations also need evidence of what agents are doing.

Microsoft Purview Audit captures supported AI and agent activities. For Agent 365, Microsoft documents audit coverage across human-to-agent, agent-to-human, agent-to-tool and agent-to-agent interactions.

Those signals can support investigation and can also contribute to other Purview experiences such as Activity Explorer and AI observability.

The investigation path depends on what triggered the case. If sensitive information appears in an AI interaction, the investigation may begin with Purview. If Defender identifies suspicious tool use or a runtime attack, the investigation will normally begin in Defender and use Purview to understand what information was involved. The products provide different views of the same incident.

7. Detect risky AI behavior

Purview Insider Risk Management provides another perspective. The Risky AI usage policy template can identify risky behavior associated with AI, including signals related to prompt injection and attempts to access protected material.

This does not make Insider Risk Management a runtime firewall for agents. It is primarily a risk-detection and investigation capability.

Defender provides the threat-detection and security-operations side of the architecture and can identify malicious or suspicious agent activity in supported scenarios.

Communication Compliance provides another, separate capability. It is designed to detect business-conduct, regulatory and inappropriate-communication issues in supported AI interactions.

These capabilities may inspect related activity, but their objectives are different:

• Insider Risk Management: Is the user's AI activity creating insider risk?
• Communication Compliance: Does the interaction create communication, conduct or regulatory concerns?
• Defender: Is the agent, AI application or interaction malicious or unsafe from a security perspective?

8. Support eDiscovery, retention and compliance

AI interactions may become business records or evidence. A prompt, response or agent-generated communication could later be relevant to litigation, an internal investigation or a regulatory request.

Purview eDiscovery can search supported AI interaction data and make it available for investigation and review. Data Lifecycle Management can retain or delete supported AI interactions according to organizational retention requirements.

However, not every Purview capability currently supports every type of agent interaction. For Agent 365, Audit has broader interaction coverage than eDiscovery and retention. Organizations should therefore check Microsoft's current capability matrix for the particular agent architecture and interaction type rather than assuming that every audited event can automatically be retained or collected through eDiscovery.

What the company needs in place

• An inventory of enterprise agents through the Microsoft 365 Agent Registry.
• Clear accountability for agents, including appropriate sponsors and owners.
• Microsoft Entra Agent ID where appropriate, using agent identities and agent identity blueprints.
• Least-privilege access for agents.
• A clear understanding of whether agents operate autonomously or through delegated user access.
• Remediation of excessive SharePoint, OneDrive and other source-system permissions.
• Microsoft Purview DSPM for AI activity and data-risk visibility rather than as the authoritative agent inventory.
• Defender for Cloud Apps to discover and assess cloud-based AI services and identify services that should be unsanctioned.
• Defender for Endpoint integration where access to unsanctioned AI services needs to be blocked from managed devices.
• Purview DLP policies for sensitive-data protection, including the Devices location where Endpoint DLP enforcement is needed.
• Sensitive Information Types, trainable classifiers and other appropriate classification mechanisms so DLP does not depend exclusively on sensitivity labels.
• Sensitivity labels where classification, marking and encryption provide value.
• Purview Audit, Insider Risk Management, Communication Compliance, eDiscovery and Data Lifecycle Management for the interaction types each capability supports.
• Device onboarding and appropriate browser integration for Endpoint DLP scenarios.
• Defender capabilities for security posture, threat detection and supported runtime protection.
• Clear operating processes across security, compliance, privacy, legal, IT and business owners.

Technology does not remove the need to decide which agents and AI services are approved, what they may do, who is accountable for them and when access should be removed.

What Microsoft Agent 365 adds

The licensing distinction needs some care because not everything visible in Microsoft's agent-management experience requires an Agent 365 license.

Eligible Microsoft 365 plans already include Agent Registry and several basic agent-governance capabilities. Agent 365 should therefore not simply be described as the product that provides the agent inventory.

What Microsoft Agent 365 adds is a more advanced agent-specific control plane. Depending on the capability and licensing, this can include:

• richer agent observability and telemetry
• more advanced agent governance and policy controls
• Entra identity, access and lifecycle capabilities for agents
• Purview data security and compliance controls for supported agents
• Defender posture assessment, detection, investigation and runtime protection
• additional controls for agent environments and endpoints

Microsoft Agent 365 is available as a standalone subscription for eligible Microsoft 365 environments and is also included with Microsoft 365 E7.

This makes Agent 365 particularly relevant when an organization moves beyond simply knowing which agents exist and wants a more integrated operating model for agent identity, security, data protection and lifecycle governance.

Extend AI and agent governance with Infotechtion

Microsoft Purview, Entra and Defender provide the foundation for securing AI and agents in the Microsoft ecosystem, but many organizations also need visibility and control across data stored outside Microsoft 365.

Infotechtion's Data & AI Security Posture Management solutions help organizations discover sensitive and overshared information across their wider data estate, identify where excessive access or poor data governance could increase AI and agent risk, and prioritize remediation before that data is exposed through Copilot or AI agents. Infotechtion also provides the governance workflows, ownership and remediation processes needed to turn security findings into action, helping organizations move from AI risk visibility to continuous, governed AI adoption.

Outcome

The company moves from unmanaged AI adoption towards governed AI enablement.

The objective is not to block AI or to put a Purview policy around every action an agent might take. It is to establish the right control at the right point.

• Agent Registry establishes which agents exist and provides a starting point for lifecycle governance.
• Entra establishes agent identity and helps govern access.
• Permissions on SharePoint, OneDrive and other source systems determine what information an agent can reach.
• Defender helps identify risky applications and AI services, block unsanctioned destinations and detect malicious or suspicious behavior.
• Purview identifies sensitive information, controls inappropriate data movement and provides data-security, risk and compliance evidence.

When an agent can access information it should not see, fix the identity or source permissions. When information is overshared, fix the source. When an AI service is considered too risky for corporate use, use Defender controls to restrict access. When an approved AI service is being used with information that should not leave the organization, use Purview DLP and, on managed devices, the appropriate Endpoint DLP controls.

Importantly, those controls should not depend solely on sensitivity labels. Purview can inspect the information itself and apply policy based on its content.

When an agent is being manipulated or behaving suspiciously, use the relevant Defender capabilities. When the organization needs to understand what sensitive information was involved, investigate risky activity, preserve interactions or demonstrate compliance, use the supported Purview capabilities.

The result is not a completely new governance model for AI. It is an extension of disciplines that enterprises already understand, identity, least privilege, application security, data security, endpoint security, information governance and accountability, to a new class of non-human actor.

That is ultimately what makes enterprise AI agents governable: knowing which agents exist, who is accountable for them, what identity they use, what they can access, which AI services are approved, what sensitive information they interact with, what actions they take and what evidence those actions leave behind.

Microsoft resources

• Overview of agent identities in Microsoft Entra
• Administrative relationships in Microsoft Entra Agent ID: owners, sponsors and managers
• Microsoft Agent 365 service description
• Microsoft Purview data security and compliance for Microsoft Agent 365
• Microsoft Purview data security and compliance for other AI apps
• Configure Microsoft Purview Endpoint DLP settings
• Microsoft Purview Endpoint DLP overview
• Microsoft Purview DLP policy reference
• Microsoft Purview data security and compliance protections for generative AI
• Microsoft Defender for Cloud Apps - govern discovered apps
• Microsoft Defender for Endpoint integration with Defender for Cloud Apps
• Microsoft Defender security for AI agents