Unified AI Governance

A Unified Defense-in-Depth Governance Model for Enterprise AI & Multi-LLM Access

1.0 Introduction: Balancing AI Innovation with Enterprise-Grade Security

The enterprise goal is to harness the power of generative AI and multi-LLM access to create a durable competitive advantage. This pursuit of innovation, however, must be balanced with a robust governance framework to manage the novel risks of data exposure, regulatory non-compliance, and malicious use. A unified, defense-in-depth security model is not an optional add-on but an essential prerequisite for the safe and scalable adoption of AI. This report details a coordinated framework across four distinct but interconnected control surfaces: the Front Door, the Perimeter, the Data Layer, and the Threat Defense Layer. This integrated approach, underpinned by identity and a mature threat response capability, enables the organization to innovate safely and confidently.

2.0 Control Surface 1: The Front Door (M365 Admin Center)

The M365 Admin Center is the strategic "Front Door" to the enterprise AI ecosystem. Its primary function is to establish the initial governance boundary by controlling precisely who can access AI capabilities and what AI applications and agents are permitted to integrate with the corporate environment. This layer enforces identity-led admission, preventing the proliferation of "Shadow AI" by ensuring all access is inventoried and explicitly authorized before any corporate data or language models are reachable.

2.1 Analyzing and Controlling Agent Proliferation

To prevent "Shadow AI," administrators must establish a sanctioned inventory of all AI agents operating within the tenant. The M365 Admin Center provides centralized controls to create a formal allowlist and block unsanctioned agents. The Allowed agent types setting enables administrators to specify which categories of agents are permitted for use. If an agent type is disabled, agents of that type will not appear for users in the Agent store.

The three agent categories that can be managed are:

  • Agents built by Microsoft: Enables users to install and use agents created by Microsoft.
  • Agents built by your organization: Enables users to install custom agents developed internally within the tenant.
  • Agents built by external publishers: Enables users to install third-party agents from external developers.

By disabling unapproved categories, such as agents from external publishers, and using Integrated Apps consent settings to govern integrations, administrators effectively block unsanctioned add-ins and shadow agents. This creates a secure, curated catalog of approved AI capabilities.

2.2 Evaluating and Governing User Access to AI Capabilities

Controlling which users are enabled for AI is a critical governance function. Within the M365 Admin Center, the User access settings allow for precise, granular control over AI and Copilot enablement. Administrators can grant permissions to:

  • All users: The default setting, allowing universal access subject to licensing.
  • No users: Disables AI agent access across the organization.
  • Specific users/groups: The most critical option, allowing administrators to select specific users or security groups to have access.

This control enables a phased, risk-managed rollout of AI capabilities. Access can be tied to specific job roles, risk tiers, and license assignments, ensuring that powerful tools are deployed deliberately and only to authorized individuals.

2.3 Enforcing Identity-Led Admission for Humans and Agents

Microsoft Entra ID is the foundation for securing the "Front Door." In this model, every AI agent is treated as a first-class security principal and must be assigned a unique Entra Agent ID. This ensures that agents are not anonymous processes but are instead accountable identities with auditable lifecycles.

With both human and agent identities established, Conditional Access policies can enforce security requirements before entry is granted. These policies can mandate Multi-Factor Authentication (MFA) or apply risk-based access checks for both users and agent identities, ensuring that only authenticated and compliant principals can engage with the AI ecosystem.

These controls work in concert to prevent shadow AI and enforce identity-led admission, effectively securing the enterprise entry point before any AI model is engaged. With admission controls rigorously enforced at the Front Door, the governance focus shifts from preventing unauthorized entry to controlling authorized activity within the perimeter.

3.0 Control Surface 2: The Perimeter (Power Platform Admin Center)

The Power Platform Admin Center (PPAC) functions as the "Perimeter" control surface. While the Front Door controls who gets in, the Perimeter controls where they can go and what data they can move. PPAC's data policies act as a critical firewall for agent logic, managing data movement across different services and containing the potential blast radius of any single AI agent or automated workflow.

3.1 Preventing Data Exfiltration via Connector Policies

Power Platform Data Loss Prevention (DLP) policies serve as a data firewall by segmenting connectors into distinct groups, thereby preventing data from being moved between them. Administrators can classify connectors into "Business" (trusted) and "Non-Business" (untrusted) categories. This segmentation blocks Power Automate flows from moving data between these two groups, which is a primary vector for data exfiltration.

Business Connectors (Trusted) Non-Business Connectors (Untrusted) SharePoint Social media connectors Dataverse Personal cloud storage

This segmentation effectively prevents an AI agent or flow from reading data from a trusted corporate repository like SharePoint and writing it to an untrusted external endpoint like personal cloud storage or a social media platform.

3.2 Containing Blast Radius with Environment and Sharing Controls

The PPAC provides further containment capabilities to limit an agent's operational scope. Environment routing allows administrators to segregate agents into distinct development, testing, and production environments. This ensures that untested or experimental agent logic cannot impact live business systems or data, effectively isolating the blast radius of development activities.

Additionally, administrators can configure sharing limits to prevent the viral or unsafe promotion of powerful agents and workflows across the organization. By restricting who can share agents and with whom, the organization can avoid the uncontrolled proliferation of high-impact automations.

By establishing a robust perimeter that governs data movement and contains blast radii, the framework ensures that even authorized agents operate within strict boundaries. The next logical control layer addresses the data itself, applying persistent protections that are independent of agent logic or location.

4.0 Control Surface 3: The Data Layer (Microsoft Purview)

Microsoft Purview serves as the central "Data Layer" and policy engine for AI governance. This control surface addresses the critical risk of data over-sharing by ensuring that security policy is not dependent on the application but travels with the data itself. Purview provides persistent, enforceable controls with complete auditability, ensuring that corporate data is protected regardless of where an AI agent attempts to access, process, or use it.

4.1 Analyzing and Enforcing Persistent Data Rights

Sensitivity Labels combined with encryption are the core mechanism for persistent data protection. When applied to files and emails, these labels attach a policy that remains with the content. Critically, these policies enforce specific usage rights, such as VIEW and EXTRACT. For an AI agent to process encrypted content on behalf of a user, the user's identity must possess these specific rights. Crucially, the AI agent operates under the security context of the user invoking it; it cannot bypass these permissions and will fail to process content for which the user lacks the necessary rights. This ensures the agent cannot downgrade data protection and inherits the access level of the user.

4.2 Mitigating Data Leakage in AI Interactions

Microsoft 365 Data Loss Prevention (DLP) policies can be configured to specifically monitor prompts and responses for Copilot and other AI agents. These policies use deep content inspection to detect and block sensitive content—such as financial records, health information, or intellectual property—from being entered into prompts or returned in AI-generated outputs. This control prevents data leakage directly at the point of interaction, protecting against both inadvertent user error and malicious attempts to exfiltrate data via AI conversations.

4.3 Proactively Remediating Oversharing at the Source

Data Security Posture Management (DSPM) for AI provides the ability to proactively remediate data exposure risks at their source. DSPM runs automated data risk assessments against repositories like SharePoint and OneDrive, identifying over-shared sites and files that could be exposed to AI agents. The strategic value of this is immense: it allows risk and compliance leaders to find and remediate oversharing before the data is indexed and made accessible to tools like Microsoft 365 Copilot, effectively closing security gaps before they can be exploited.

4.4 Implementing Compensating Controls with Restricted Search

Restricted SharePoint Search acts as a vital compensating control while an organization improves its data permissions hygiene. This feature allows administrators to constrain Copilot's data retrieval scope to a curated list of approved SharePoint sites. By limiting where Copilot can search for information, this control acts as a powerful guardrail, preventing accidental data exposure from un-remediated sites or legacy data stores that have not yet been fully secured.

With persistent, data-centric controls enforced by Purview, the framework ensures data is protected regardless of location or the agent accessing it. The final governance surface addresses the models themselves, providing a real-time defense against malicious inputs and unsafe content generation.

5.0 Control Surface 4: The Threat Defense Layer (Azure AI Services)

The suite of Azure AI Services constitutes the "Threat Defense Layer." This layer is the real-time, runtime safety gateway that stands directly between user prompts and the Large Language Models (LLMs). Leveraging components like Azure AI Content Safety and Azure Machine Learning, its purpose is to inspect the content and intent of both prompts and model responses to detect and block malicious instructions, jailbreak attempts, and the generation of harmful content. This ensures that manipulative inputs are neutralized before they can be processed by the model and that unsafe outputs are suppressed before they are returned to the user.

5.1 Defending Against Adversarial and Malicious Inputs

Specialized defenses are required to protect against attempts to manipulate model behavior. Prompt Shields and Jailbreak/Prompt Injection detection analyze incoming prompts for patterns indicative of adversarial attacks. These systems are trained to recognize instructions designed to make the model ignore its safety protocols or generate harmful content, such as role-playing scenarios or commands that try to override system instructions.

5.2 Filtering for Harmful Content

Azure AI Content Safety provides sophisticated, context-aware filtering for both inputs and outputs. It is trained to detect and block content across four key categories of harm, ensuring interactions remain safe and appropriate:

  • Hate: Language expressing discrimination or pejorative statements based on identity, such as race, religion, or gender.
  • Violence: Language that describes, advocates for, or glorifies violent acts or provides instructions for harm.
  • Sexual: Sexually explicit or abusive language that is inappropriate for a professional context.
  • Self-harm: Language that describes or encourages acts of harming oneself.

5.3 Governing Model Usage and Integrating with Security Operations (SecOps)

To prevent the use of unvetted or malicious models, organizations must establish an Approved Model Registry in Azure Machine Learning. This ensures that agents can only deploy and use models that have been formally verified and approved, preventing supply chain attacks and ensuring model integrity.

This layer must also integrate with the broader security ecosystem. Defender for Cloud's AI threat protection detects runtime threats and feeds security alerts into Microsoft Defender XDR and Microsoft Sentinel. This allows security operations (SecOps) teams to correlate AI-related threats with other signals from across the enterprise. This integration is critical, as it allows the SOC to correlate a potential prompt injection attack (detected at the Threat Defense Layer) with anomalous data access patterns (monitored at the Data Layer) by a specific user identity (managed at the Front Door), providing a unified view of a complex, multi-stage threat. Using Security Orchestration, Automation, and Response (SOAR) playbooks, teams can orchestrate automated containment actions, such as isolating a compromised agent or blocking a malicious user.

Malicious prompts are filtered, unsafe outputs are suppressed, and incidents are detected and handled at machine speed, providing a complete and resilient defense.

6.0 Conclusion: Security is a Coordinated Framework, Not a Single Control

Effective enterprise AI security is not achieved by a single product, policy, or control. Rather, it is the deliberate coordination of these four administrative planes—Front Door, Perimeter, Data, and Threat Defense—that creates a robust, defense-in-depth security posture. This layered structure allows the organization to manage risk at each stage of an AI interaction, from initial user access to final model response. This framework is further reinforced by two cross-cutting pillars: a rigorous Identity and Role-Based Access Control (RBAC) model that treats both human and non-human agents as unique principals, enforcing the principle of least privilege at every layer of the architecture, and a mature Threat Response capability (XDR/Sentinel SOAR) that unifies signals and automates containment. Together, these elements provide a comprehensive and resilient governance model for enterprise AI.

7.0 Appendix: Director's Go/No-Go Deployment Checklist

This checklist provides a practical, actionable framework for technology and risk leaders to validate security readiness before deploying any new AI agent into a production environment.

  • Access & Inventory
  • Have all AI agents been assigned unique Entra Agent IDs for accountability and access management?
  • Are Integrated Apps/app consent policies in the M365 Admin Center configured to block unsanctioned applications?
  • Perimeter
  • Are Power Platform Admin Center (PPAC) DLP policies in place to enforce the separation of "business" vs. "non-business" connectors?
  • Are development, testing, and production environments isolated?
  • Have sharing limits for agents and flows been reviewed and set?
  • Data
  • Are Sensitivity Labels published and enforced on sensitive data stores?
  • Do encrypted labels require the EXTRACT usage right to be processed by AI agents?
  • Have Data Security Posture Management (DSPM) assessments been run and oversharing remediations completed?
  • Is an M365 DLP policy active to monitor sensitive content in prompts and responses?
  • Has Copilot's Restricted Search been configured for SharePoint where necessary to limit scope?
  • Runtime Safety
  • Are Prompt Shields and Azure AI Content Safety enabled on the Azure AI service endpoints?
  • Is model usage restricted to an organization-approved registry?
  • Have recent adversarial tests (red teaming) been conducted and passed?
  • Threat Response & Audit
  • Are detection rules in Defender XDR/Sentinel live for AI-related threats?
  • Are SOAR playbooks configured for automated containment of AI-driven incidents?
  • Is the Purview unified audit log capturing prompts and responses for forensic analysis?
  • Is evidence retention aligned with data sensitivity labels and legal hold requirements?