From “No” to “Now”: A 7-Layer Strategy for Enterprise AI Safety
The “block” posture on Generative AI has failed. In a global enterprise, banning these tools doesn't stop usage; it simply pushes intellectual property into unmanaged channels and creates a massive visibility gap in corporate telemetry. The priority has now shifted from stopping AI to hardening the environment so that innovation can run at velocity without compromising data sovereignty. Traditional security perimeters are ineffective against the “slow bleed” of AI leakage - where data moves through prompts, clipboards, and autonomous agents rather than bulk file transfers. To secure this environment, a 7-layer defense-in-depth model is required to treat the conversation itself as the new perimeter. 1. Identity: The Only Verifiable Perimeter Identity is the primary control plane. Access to AI services must be treated with the same rigor as administrative access to core infrastructure. The strategy centers on enforcing device-bound Conditional Access, where access is strictly contingent on device health. To solve the "Account Leak" problem, the deployment of Tenant Restrictions v2 (TRv2) is essential to prevent users from signing into personal tenants using corporate-managed devices. For enhanced coverage, Universal Tenant Restrictions (UTR) via Global Secure Access (GSA) allows for consistent enforcement at the cloud edge. While TRv2 authentication-plane is GA, data-plane protection is GA for the Microsoft 365 admin center and remains in preview for other workloads such as SharePoint and Teams. 2. Eliminating the Visibility Gap (Shadow AI) You can’t secure what you can't see. Microsoft Defender for Cloud Apps (MDCA) serves to discover and govern the enterprise AI footprint, while Purview DSPM for AI (formerly AI Hub) monitors Copilot and third-party interactions. By categorizing tools using MDCA risk scores and compliance attributes, organizations can apply automated sanctioning decisions and enforce session controls for high-risk endpoints. 3. Data Hygiene: Hardening the “Work IQ” AI acts as a mirror of internal permissions. In a "flat" environment, AI acts like a search engine for your over-shared data. Hardening the foundation requires automated sensitivity labeling in Purview Information Protection. Identifying PII and proprietary code before assigning AI licenses ensures that labels travel with the data, preventing labeled content from being exfiltrated via prompts or unauthorized sharing. 4. Session Governance: Solving the “Clipboard Leak” The most common leak in 2025 is not a file upload; it’s a simple copy-paste action or a USB transfer. Deploying Conditional Access App Control (CAAC) via MDCA session policies allows sanctioned apps to function while specifically blocking cut/copy/paste. This is complemented by Endpoint DLP, which extends governance to the physical device level, preventing sensitive data from being moved to unmanaged USB storage or printers during an AI-assisted workflow. Purview Information Protection with IRM rounds this out by enforcing encryption and usage rights on the files themselves. When a user tries to print a "Do Not Print" document, Purview triggers an alert that flows into Microsoft Sentinel. This gives the SOC visibility into actual policy violations instead of them having to hunt through generic activity logs. 5. The “Agentic” Era: Agent 365 & Sharing Controls Now that we're moving from "Chat" to "Agents", Agent 365 and Entra Agent ID provide the necessary identity and control plane for autonomous entities. A quick tip: in large-scale tenants, default settings often present a governance risk. A critical first step is navigating to the Microsoft 365 admin center (Copilot > Agents) to disable the default “Anyone in organization” sharing option. Restricting agent creation and sharing to a validated security group is essential to prevent unvetted agent sprawl and ensure that only compliant agents are discoverable. 6. The Human Layer: “Safe Harbors” over Bans Security fails when it creates more friction than the risk it seeks to mitigate. Instead of an outright ban, investment in AI skilling-teaching users context minimization (redacting specifics before interacting with a model) - is the better path. Providing a sanctioned, enterprise-grade "Safe Harbor" like M365 Copilot offers a superior tool that naturally cuts down the use of Shadow AI. 7. Continuous Ops: Monitoring & Regulatory Audit Security is not a “set and forget” project, particularly with the EU AI Act on the horizon. Correlating AI interactions and DLP alerts in Microsoft Sentinel using Purview Audit (specifically the CopilotInteraction logs) data allows for real-time responses. Automated SOAR playbooks can then trigger protective actions - such as revoking an Agent ID - if an entity attempts to access sensitive HR or financial data. Final Thoughts Securing AI at scale is an architectural shift. By layering Identity, Session Governance, and Agentic Identity, AI moves from being a fragmented risk to a governed tool that actually works for the modern workplace.Never Get Locked Out: The Importance of a Break Glass Admin Account
One of the simplest but most critical safeguards in Microsoft Entra ID is having a Break Glass Admin account. In my lab, I created a dedicated emergency account with: - Permanent Global Admin role (for emergencies only) - Excluded from Conditional Access policies - Strong password stored securely - Monitoring in place to detect any sign-in attempts This account is never used for daily operations — it exists only to guarantee access in case Conditional Access, MFA, or identity protection policies block all other admins. This setup prevents accidental lockouts and ensures continuity. Does your organization maintain a Break Glass Admin account, and how do you secure it?
Authenticator not displaying numbers on MacOS
I'm have an issue with MFA on a Mac (all the latest versions). We have conditional access policies in place, so once a day I'm prompted for MFA (I work off-site) and the Office app (e.g. Outlook, Teams) will create the pop-up window that 'should' display a number that I then match on my phone. My phone see's the push notification, but the Mac never creates the numbers in the first place. The pop-up is there, just no number. The workaround is: Answer 'its not me' on the phone On the Mac, select 'I can't use Authenticator right now' Tell the Mac to send a new request This time it creates the number and I can authenticate on the phone. It only appears to happen for the installed Office applications i.e. if I'm accessing applications/admin-centre via the browser, then the pop-up is within the browser and everything works first time. Is this a known issue?
Is it possible to allow MFA registration only in a work profile on a managed phone
Hello, I'm currently rolling out MDM via Endpoint Manager and also enforcing compliance policies using conditional access. I would like to allow MFA registration only in work profiles, so that users can only register MFA (for Passwordless sign in) on the Microsoft Authenticator app in their work profile. Does anyone have experience with this, or is this currently even possible? BrSBlocking Personal Outlook and Gmail Accounts on Corporate Device
Hello Community, In my organization, we use the Microsoft 365 environment. We have a hybrid infrastructure, but we aim to deploy as many policies as possible through Microsoft 365 (Intune, Purview, Defender, etc.). One of our goals is to limit the use of corporate devices for personal purposes. We use Outlook as our corporate email service, and we would like to block employees from signing into their personal email accounts (either via web or desktop application). Additionally, we would like to block access to other email services, such as Gmail, both via web and desktop apps. Could you provide guidance on how to achieve this? I would greatly appreciate any help or suggestions. Thank you very much! Juan RojasAnomalies with Conditional Access Policy "Terms of Use" Failures
Hello Microsoft Community, I'm reaching out with a bit of a puzzle regarding our "Terms of Use" Conditional Access policy, and I'm eager to tap into the collective wisdom here for some insights. In our Entra ID User Sign-In logs, we've identified intermittent "failure" entries associated with the "Terms of Use" Conditional Access policy. Interestingly, even for users who had previously accepted the "Terms of Use". There appears to be no discernible impact, and they continue their tasks without interruption. This observation became apparent during the troubleshooting of unrelated Surface Hub and Edge Sync issues at some client sites. What adds to the complexity of the situation is that for the same users, both before and after these "failure" entries, the Conditional Access policy is marked as "success". Hence, it doesn't seem to be a straightforward case of the policy erroneously detecting non-acceptance of the "Terms of Use". The mystery lies in understanding why these intermittent "failure" entries occur for users who have already accepted the terms, especially when the policy consistently reports "success" for the same users. Furthermore, the Insights for the "Terms of Use" Conditional Access policy show around 1.48k successes and 1.43k failures in the last 90 days, yet there's no discernible impact on user functionality. Observations: "Failure" entries in Sign-In logs don't seem to disrupt users' day-to-day activities. The ratio of successes to failures is balanced, yet users experience no noticeable problems. The issue complicates troubleshooting efforts but doesn't significantly affect the user experience. I'm turning to the community for guidance on interpreting and resolving this discrepancy between "failure" entries in the Conditional Access policy logs and the seemingly unaffected user experience. Any insights into why these failures occur without user impact would be greatly appreciated. For additional context, I've attached screenshots of a user's Sign-In log entry and the insight chart from the Conditional Access policy. Sign-In log of a user (failure): Sign-In log of same user (success): Current Conditional Access insights: Thank you in advance for your time and assistance. I look forward to any guidance or solutions you can provide. Best regards, Leon Tüpker
Only Outlook and Teams on Personal mobile devices
We are looking to let users access Outlook and Teams using their personal iOS and Android devices but not allow them to access the SharePoint side within the Outlook app. I have made two conditional access policies to accomplish this, but only the Outlook side of things is working. Teams won't let a user log in and are being blocked by the first Conditional access policy. First CA - Target Resources Include = Office 365 Exclude = Micorosft Teams Service, Office 365 Exchange Online - Conditions Device Platform = Android, iOS Filter for devices = device.deviceOwnership -eq "Personal" - Grant = Block access Second CA - Target Resources Include = Microsoft Teams Services, Office 365 Exchange Online -Conditions Device Platform = Android, iOS Filter for devices = device.deviceOwnership -eq "Personal" - Grant = Grant Access > Require device to be Marked compliant Can anyone help?
Allow use of One Time Password
Hello, We have setup Passwordless authentication using Conditional Access Policies, which is working great. The question I have is how can I setup the option to allow the use of the one time password (6 digit code in the authenticator) to be used when the mobile device is offline and cannot receive the number matching. For example, the user is in a plane and has purchased the use of WiFi for the laptop, but the phone is offline and want to use the 6 digit code from the authenticator.
