We're trying to figure out the best way to manage generative AI in our enterprise without employees pasting confidential information into personal accounts. So far, we've blocked most public AI services, allowed Microsoft Copilot, and introduced a policy prohibiting unsanctioned tools. The problem is that Copilot doesn't meet every department's needs, and leadership now wants one team to use Claude.
We're implementing Microsoft Purview DLP and reviewing Defender cloud-app controls. Our domain is federated through Okta for single sign-on, so I'm also trying to understand which session and access policies are still possible. We have Microsoft 365 E5.
What approaches are other IT teams using to support useful AI tools while preventing sensitive information—such as payroll spreadsheets—from being uploaded to consumer AI services?
5 Answers
Blocking every service usually drives users toward personal accounts and unmanaged phones, where your controls have no visibility. The better goal is to make the approved option convenient, capable, and clearly safer than the workaround. Provide sanctioned tools, publish examples of prohibited data, train users, and monitor for risky activity rather than relying on a blocklist alone.
Treat accidental uploads as inevitable: have an incident process, DLP alerts, data classification, and a way to investigate and contain exposure. Technical controls help, but users need a practical approved path.
A Microsoft-focused environment can combine Purview sensitivity labels and DLP with Defender monitoring, firewall or DNS restrictions, browser controls, and identity-based access. Expect this to be an ongoing security-stack project—especially if browsers have built-in AI features that can index or process company content.
For Claude specifically, an enterprise offering or Claude through a managed cloud service such as Amazon Bedrock may provide better control than consumer accounts. A curated internal marketplace for approved models, agents, and plugins can also keep teams productive without letting everyone install arbitrary integrations.
The hardest part is convincing people to stop using personal AI accounts. We’re finding that the approved service has to be good enough for the common workflows, and the policy needs to explain the risk in practical terms rather than just saying “don’t use it.”
For labeled files in SharePoint or OneDrive, review Azure Rights Management permissions and consider restricting copy or extract rights for sensitive categories. That can help prevent authorized AI features from freely extracting protected content. However, don’t assume the same control protects external Graph or Copilot connectors: those generally depend on the source system’s ACLs and connector configuration, not simply on RMS extract permissions. Audit connector scope and permissions separately to avoid oversharing.
First figure out exactly what that department needs: a browser chatbot, coding assistance, an agent, or something else. A managed Copilot or Copilot Studio deployment may cover some Claude-style use cases while keeping the organization under Microsoft’s enterprise protections. If they truly need direct Claude access, look at an enterprise contract and verify its retention, training, identity, audit, and data-processing terms against your policy.
Also, don’t quietly make an exception to an existing policy. Either the requested use case passes the policy or leadership should formally amend the policy and accept the risk.

Related Questions
Can't Load PhpMyadmin On After Server Update
Redirect www to non-www in Apache Conf
How To Check If Your SSL Cert Is SHA 1
Windows TrackPad Gestures