Skip to content

Enterprise AI Tool Governance: Controlling Access, Data Flows, and Shadow AI Risk

The rollout of ChatGPT Lockdown Mode highlights the broader challenge of governing AI tool access in enterprise environments: organisations must balance productivity benefits against data loss risk, prompt-injection exposure, and the proliferation of unofficial AI tools used without IT oversight. This guide covers the IAM and DLP controls that define an enterprise AI governance posture.

Article identity-access-management

The security discussion around AI tools in enterprise environments often focuses on what the AI platform does with data after submission. The equally important question is what controls the enterprise has over which data reaches which AI platforms in the first place.

ChatGPT Lockdown Mode addresses one post-submission risk (prompt-injection exfiltration). The pre-submission governance question — who can use which AI tools, with what data, and with what logging — requires a different set of controls: identity and access management policies, data loss prevention rules, and an inventory of AI tools in active use across the organisation.

The Shadow AI Problem

Shadow IT has a well-established governance framework in most enterprises: unsanctioned applications are blocked via web filtering, cloud access security broker (CASB) policies, and network controls. Shadow AI is the same problem in a new form, with several complicating factors:

  • AI tools are frequently accessed through web browsers as SaaS applications, making them indistinguishable from approved cloud tools without URL-level categorisation
  • The productivity benefits of AI tools are immediate and visible to employees, creating strong incentive to use unapproved tools when approved options are not available
  • Many AI tools that were consumer-only in 2024 now have enterprise variants with appropriate data processing agreements — the policy landscape is moving faster than most enterprise policy review cycles

The consequence is that most organisations have significant AI tool usage that is neither formally approved nor formally prohibited — employees using personal ChatGPT accounts, Claude.ai, Google Gemini, Perplexity, and others for work tasks using work data, without the enterprise’s DLP policies, audit logging, or contractual data processing protections applying to that interaction.

IAM Controls for AI Platforms

Conditional Access for sanctioned AI platforms:

For AI tools the enterprise has approved (e.g., Microsoft Copilot, ChatGPT Enterprise), enforce Conditional Access policies that restrict access to:

  • Compliant managed devices only (not personal devices or BYOD)
  • Specific user groups based on role (not all-staff by default)
  • Trusted network locations or VPN-connected sessions

This ensures that approved AI tool usage occurs within the enterprise’s security perimeter and is logged through the identity provider.

CASB policy for unsanctioned AI:

Deploy a Cloud Access Security Broker (Microsoft Defender for Cloud Apps, Netskope, Zscaler CASB) with AI/LLM category policies:

  • Block access to known AI platforms that do not have enterprise data processing agreements
  • Monitor and report on AI platform usage in the “allowed but monitored” category
  • Enforce stepped-up authentication (additional MFA factor) for access to AI platforms that handle sensitive data categories

OAuth app governance:

AI tools that request OAuth access to Microsoft 365 or Google Workspace (email, calendar, documents) represent a significant data access risk. Review OAuth application consents across the Microsoft Entra ID and Google Admin portals:

  • Block new OAuth grants to AI applications unless pre-approved through the IT request process
  • Review existing grants — any AI application with Mail.Read, Files.Read, or Calendar.Read access has broad visibility into corporate data

DLP Rules for AI Platform Submissions

Data Loss Prevention rules that flag or block submission of sensitive data to AI platforms:

Classify what cannot go to AI: Identify data categories that should not be submitted to external AI platforms: financial forecasts, M&A-related documents, personal data subject to GDPR/HIPAA, client data under NDA, source code for unreleased products, and internal strategic planning documents.

DLP policy configuration (Microsoft Purview example):

  • Condition: content matches classification policy (e.g., “Highly Confidential”, “Personal Data”, “Financial”)
  • Action: Block upload to AI platform URLs, notify user with policy explanation, log to compliance audit

DLP for ChatGPT Enterprise (Microsoft integration): The ChatGPT Enterprise Microsoft Purview connector allows DLP classification labels to be applied to ChatGPT conversations. Conversations marked as containing sensitive data trigger DLP policy actions and are included in eDiscovery scope.

Logging and Audit Requirements

Enterprise AI tool usage should generate audit logs that support:

  • Who used which AI tool
  • What data classifications were present in the session (via DLP scanning)
  • Whether Lockdown Mode or equivalent restrictions were enforced
  • Whether any DLP policy actions were triggered

For ChatGPT Enterprise, audit logs are available via the Admin Console → Reports → Activity Log. For Microsoft Copilot, logs are in the Microsoft Purview compliance portal and Microsoft 365 Unified Audit Log.

A Practical Governance Posture

The practical AI governance posture for most enterprises in 2026 is:

  1. One or two sanctioned AI platforms with enterprise contracts (ChatGPT Enterprise, Microsoft Copilot)
  2. Conditional Access restricting those platforms to managed devices and approved user groups
  3. DLP rules blocking sensitive data submission to those platforms
  4. CASB policies monitoring and blocking access to unsanctioned AI platforms
  5. Quarterly review of OAuth application grants to identify new AI tool integrations

This posture accepts that AI tools will be used — the goal is to channel that usage through controlled environments rather than eliminate it, which is operationally infeasible.

Share this article

Related Intelligence

🔑 IAM

Pwn2Own Week Exposes the Limits of Identity as a Security Control — What IAM Teams Should Review

The week of 12–18 May 2026 produced two distinct scenarios where identity controls — Conditional Access, MFA, and Zero Trust enforcement — provided no meaningful protection: Exchange Server-side RCE (operating below the authentication layer) and Exchange OWA session hijacking (stealing tokens after authentication). Both are active or imminent threats. Both require defences that go beyond the identity layer.

#identity +7
🔑 IAM

Why Exchange SYSTEM RCE Bypasses Conditional Access and MFA: The Authentication Architecture Problem

The Exchange SYSTEM RCE chain demonstrated by DEVCORE at Pwn2Own Berlin 2026 achieves code execution at the operating system level, bypassing all identity controls including Conditional Access policies, MFA requirements, and Azure AD authentication entirely. Understanding why server-side RCE renders identity controls irrelevant is essential for accurate risk assessment.

#exchange +7
🔑 IAM

ConsentFix v3 Automates Azure OAuth Abuse at Scale — MFA-Bypassing Phishing Platform Circulating on Forums

The third iteration of the ConsentFix Azure OAuth phishing toolkit has been observed circulating on cybercriminal forums, adding Pipedream-powered automation to the consent flow abuse technique that allows attackers to gain persistent access to Microsoft 365 tenants without requiring MFA. Enterprise security teams should review conditional access policies governing OAuth app registrations and user consent.

#oauth +6