Preventing Data Leakage to AI: A Strategic Framework for the Global Enterprise
In an organization with thousands of users, "Shadow AI" isn't just an IT nuisance - it’s a fundamental shift in the risk surface. We’ve all seen it: a well-intentioned employee pastes proprietary code into a public LLM to "clean it up," or a team lead uploads a customer list to a "free" AI formatter. These aren't malicious acts; they are productivity shortcuts that create massive security gaps. To enable innovation without compromising safety, we need a Zero Trust–aligned framework that acts as a guardrail rather than a gate. This requires a layered model centered on Identity, Device Health, and Data Intelligence. The 7-Layer Defense Architecture In a complex tenant, we don't rely on a single gatekeeper. We implement a stack where each layer provides a fail-safe for the one before it. Layer Enterprise Objective Primary Technology 1. Identity Anchor Verified Access & Device Health Microsoft Entra ID + Intune 2. Global Radar Continuous Shadow AI Discovery Purview AI Hub + Defender for Cloud Apps 3. Session Guard Real-time Intervention & Input Filtering Conditional Access App Control (MCAS) 4. Data Core Auto-Labeling & Persistent DLP Microsoft Purview Information Protection 5. Agent Governance Lifecycle & Identity for AI Agents Agent 365 + Entra Agent ID 6. The Human Layer Secure Prompting & AI Skilling Approved Prompt Templates & Training 7. Continuous Ops Monitoring & Regulatory Auditability Microsoft Sentinel + Insider Risk Mgmt 1. Universal Discovery via the Purview AI Hub Visibility is the prerequisite for governance. In a complex environment, you need a "single pane of glass" to monitor AI usage across the tenant. The Insight: Use the Purview AI Hub to identify "high-risk" prompts and see exactly which sensitive data types (PII, IP, Code) are being shared. The Radar: Integration with Defender for Endpoint ensures we capture AI usage even when users are off-network or traveling, leaving no blind spots in the global telemetry. 2. Identity-Driven Access & Tenant Boundaries Access must be tied to the health of the device. If the device isn't managed, the AI shouldn't be reachable. Conditional Access: Enforce policies requiring a "Managed and Compliant" device for any AI service. The "Account Leak" Fix: Deploy Tenant Restrictions v2 (TRv2). This is the only way to effectively stop employees from using corporate assets to sign into personal Microsoft accounts, keeping data strictly within your managed boundary. 3. Real-Time Session Governance & Inbound Protection The biggest leak in the enterprise isn't a hack; it's the copy-paste. However, we must also guard against Prompt Injection. Granular Controls: Use Session Policies to allow an AI tool while blocking specific risky actions - like uploading a document with a "Highly Confidential" label. Inbound Sanitization: Implement filters to detect malicious external data that might attempt to "hijack" a session via Indirect Prompt Injection. Continuous Access Evaluation (CAE): This ensures that if a user’s risk level changes, their access to AI is revoked in near real-time. 4. Hardening the Data (Auto-Classification & DLP) If security is embedded in the data, the location of the data becomes secondary. Intelligent Labeling: Move beyond manual tagging. Use Auto-labeling at the service level to scan and encrypt sensitive data (e.g., credit card numbers or internal project names) before it can be processed by an LLM. Clipboard Guard: Use Endpoint DLP to stop the "Clipboard Leak." This prevents users from moving sensitive text from a protected document into a web-based AI interface. 5. The "Agentic" Era: Agent 365 As we move from chatbots to autonomous agents, governance must manage an ecosystem of AI agents. Agent 365: A centralized control plane to manage the registry and lifecycle of every AI agent (sanctioned or "shadow") active in your tenant. Entra Agent ID: Treat agents like enterprise identities. Assign unique IDs to manage permissions so an agent’s access doesn't outlive its business purpose. 6. The Human Layer: Skilling & Secure Prompting Technical guardrails are the safety net, but user intent is the driver. Context Minimization: Train users to provide AI with only the data it needs. Redacting proprietary names or PII before prompting should be a baseline habit. The "Safe Harbor": Move users away from risky public tools by providing a superior experience in Microsoft 365 Copilot. Security shouldn't be a "No," it should be a "Yes, use this instead." 7. Continuous Ops & Regulatory Compliance Security is not a "set and forget" project. For the global enterprise, this layer provides the Audit Trail required for the EU AI Act and GDPR. Shadow AI Migration: Track the % of users moving from "Shadow" to sanctioned tools. Sentinel Correlation: Correlate AI prompts and DLP alerts in Microsoft Sentinel to allow the SOC to automate responses to misuse. Compliance Reporting: Generate automated reports on data residency and AI interaction logs to satisfy global regulatory requirements. Technical & Licensing Baseline This framework focuses on identity-, data-, and app/session-level controls (e.g., Defender for Cloud Apps/CAAC). It does not include network-level controls such as Cloud Proxy or ZTNA, which can complement these measures. Most capabilities require Microsoft 365 E5 and Entra ID P2. Features like Purview AI Hub, Agent 365, and Entra Agent ID may be in preview or offered as add-ons - verify availability and licensing with your Microsoft account team. Conclusion Securing AI at scale is not about building a wall; it is about engineering a dynamic foundation. In a global enterprise, "No" is a temporary delay, not a sustainable policy. By anchoring our strategy in Identity, Auto-Classification, and Agentic Governance, we transform AI from a fragmented "shadow risk" into a governed, competitive advantage. This framework ensures that as our digital ecosystem evolves, the organization's "crown jewels" remain protected - not by restricting innovation, but by making security the adaptive, automated engine that powers it.
How to foce intune client in Ubuntu to synch automatically
Hello, in my company we have enrolled Devs Ubuntu devices to control some security setting and allow or not the access to our company apps and content. We have set compliance policies and enabled conditional access to check its. i have been surprised this morning by the last checking date of my Ubuntu laptops and ask my Devs of last signin in company portal client and the date match with the last checking date. I concluded, the company portal is synching only when the user open it and signin. This is a big problem for us because we are certified ISO27001 and we must check all devices compliance. Somebody has a script to deploy on those ubuntu devices and force a synch every day waiting for a Microsoft evolution of this process. Thanks a lot and regards Majid
Conditional Access Policy Not Allowing Users to Access AVD
We have an existing conditional access policy which requires a users' device to be marked as "compliant" in order to access "All Agent Resources". We are trying to deploy an AVD as an alternative to allowing users to use personal devices, but this CA policy seems to be interfering with users being able to access the AVD via Windows App. Yhe device they're accessing from isn't "Compliant" with Intune enrollment being one of the requirements for being compliant. Again, we do not want to allow personal devices into Intune which the MSP allowed previously. For the CA policy it's applied to all users EXCEPT for specific users in an exclusion group. Putting users in this exclusion group allows them to access the AVD via Windows App but at this point they can just access all resources from their personal machine defeating the purpose of the AVD. Target Resources Include All Resources Exclude: The AVD Itself, Windows 365, Azure Virtual Desktop, Azure Windows VM Sign-in Conditions Device Platforms - Windows, MacOS Client apps - Browser, Mobile apps and desktop clients, exchange ActiveSync clients, other clients are checked Grant Access Require MFA and Require device to be marked as compliant are both checked. Access to the AVD works in the browser but not in Windows App.
Cert Based Auth no longer working on Android devices.
Curious as to how wide spread this is/will be. Windows and iOS is fine, only affecting android. You can easily test this by revoking MFA sessions on a user who is using cert based auth on a android phone. I'm not sure if there has been a update recently to Android Microsoft Office apps where it thinks the certs live inside the intune company portal and is not looking for certs in the phones cert store. BYOD work profile Android 14 phones are being problematic, when a user changed their password and Azure revoked their sessions for a reauth, the issue started occurring. I tested this on another user manually revoking their MFA sessions without changing their password same issue occurred. I also setup a brand new Android phone and had the same issue after enrolling it. The issue is when the user opens outlook or teams and goes to sign in, it will pop up asking to use a cert on the device or a physical key. When selecting on the device the phone will freeze it will then eventually say ""company portal isn't responding" with the options of wait or cancel. Opening chrome in the work profile and going to a office app site will popup asking for the cert and works fine. So the issue doesn't appear to be the phone getting the cert, just the Office Apps are not accessing the Phones cert Store. I can confirm the Cert is inside the work profile as a browser or cert viewer app inside the workprofile can see it, auths work fine when using a browser in work profile, just not outlook or teams inside the work profile.Global Secure Access - Conditional Access Require GSA - Android Blocked
Hello all, I am currently working on deploying Global Secure Access client with Microsoft Forward Traffic profile and a conditional access policy to block access to M365 services unless connected through the GSA client. I have this working as I want it for Windows and mobile devices in a tenant we use for development. However, when I set this up at our live tenant, I cannot get the Android device to work. My setup is a Personally Owned Work Profile with the Defender app deployed and configured to enable GSA. I can connect to Global Secure Access and it does show some traffic tunneling to Microsoft. However, when I go to login to another app like Outlook, it blocks the sign-in. This is not the case for an iPhone I have personally enrolled and my Entra Joined laptop. Upon investigation of any differences between our development tenant (working fully) and our tenant (Android not working) I found that in the GSA section under Services, there is an extra service called “Microsoft Entra Channel Access”. This service does not show up when I am logged in our developer tenant. Even on the same phone by removing work profiles and signing in to both tenants, our live tenant shows the new channel, and the developer tenant does not have it. I did some log review with the advanced diagnostics feature and the app and noted a few things I am lead to believe that the issue is with this new Entra Channel that has been deployed to our live tenant and not to our dev tenant yet. When I go to sign-in to the Outlook application in the work profile for the developer tenant, I can see the authentication traffic being tunneled through the Microsoft 365 profile. (login.live.com, login.microsoftonline.com, and aadcdn.msftauth.net). However, in our production tenant when doing the same test I do not see those destinations being tunneled at all. I do see the traffic being collected in the “Hostname” section, but is not being tunneled. Another interesting point with this is that on an iPhone I am testing; I do see the authentication destinations being tunneled through the Entra Channel. Here are the screenshots of my findings. https://imgur.com/a/82r3HQC I have an open Microsoft support case and hoping to get the attention of a Microsoft employee or MVP who may be able to get this in front of the Entra product team to see if this is a bug.
Block all 365 apps except Outlook via CA
Trying to block 365 for a subset of users, except email. The old app-based CA rules made this easy. The new 'resource' based setup... I'm not even sure if it's possible. CoPilot just keeps telling me to use the old version of CA, because it hasn't clued into Microsoft's downgrade cycle. If I try to filter by resource attribute, I'm told I don't have permission to do so. I'm the global admin. Here's what searching for Outlook gives me and Exchange Advice? We ARE intune licensed, but i'm not sure App Protection Policies will help here. The intention is to block BYOD from accessing anything but Outlook / Exchange. That is, Mobile devices that aren't (whatever param I decide on)Stolen session token from Edge
We can steal the session token from Edge using tools like Burp Suite or Fiddler to intercept proxy traffic on the mobile phone, even when the Edge is MAM protected by Intune. This makes the Edge browser unsafe to use for Enterprise Applications on personal mobile. Recently I discovered that the https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-token-protection in Conditional Access Policy. However it is only available for Windows. I am wondering if anyone knows when it would become available for mobile on Entra roadmap. Also, if you know any Edge configuration, I could use to stop Token Theft, please let me know! Thank you everyone.
