Why “Data in Switzerland” Is Not Enough
Moving from Residency to Control in Microsoft 365 Every conversation about data sovereignty in regulated industries tends to start the same way: “We use Multi-Geo. The data stays in Switzerland.” It’s the right starting point. Microsoft 365 Multi-Geo allows organizations to place selected workloads - SharePoint sites, OneDrive accounts, Teams data, or Exchange mailboxes - into specific regions, including Switzerland, while maintaining a single global tenant. This makes it possible to align sensitive data with regulatory or customer requirements without fragmenting the overall environment. But it only answers one question: Where is the data stored? It does not answer who accessed the data, from where, under which conditions, or what happened after access. That is where the real problem begins. A scenario that happens every day A Swiss engineering firm stores sensitive project documentation in Switzerland using Multi-Geo. An external contractor - working from an unmanaged device outside Switzerland - is granted access to review a file. The document opens. The data is now on a screen in an unknown location, on a device with no compliance posture, in a session with no restrictions. From the platform’s perspective, residency was enforced. From a sovereignty perspective, control was lost the moment access was granted without conditions. The file never left Switzerland. But sovereignty did. Residency is static. Control is not. The moment a document is opened, storage location stops being the relevant boundary. The file is no longer just “in Switzerland.” It moves instantly across endpoints and browsers, collaboration tools like Teams, external users and partners, and increasingly AI-driven contexts. The infrastructure remains unchanged. The data does not. From the platform’s perspective, everything is working as designed - access was granted, residency was enforced - and control was lost. Most “data in Switzerland” strategies fail at exactly this moment: when the data is used. The shift: from location to conditions If data sovereignty is the goal, the question must change. Not “Where is the data stored?” but: Under which conditions can data be accessed and used? This shift fundamentally changes the architecture. Control must be applied across three distinct layers - and all three must be connected. Layer 1: Access is conditional, not static Conditional Access extends control beyond authentication and turns it into continuous evaluation. Access decisions can depend on: Device compliance Location (geo-restriction) Identity and risk signals Multi-Geo ensures data is placed correctly. Conditional Access ensures it is reachable only under defined conditions. The two must work together - residency without access governance is an incomplete control. Layer 2: The session is the real risk surface Even with strict access controls, risk remains. A session is an exposure surface by design. During an active session, data is viewed, copied, shared, processed by applications, and connected to AI prompts. The gap does not appear at storage or authentication. It appears during active usage - inside the session. This is the layer most architectures do not explicitly address. Controls must extend into the session itself: limiting data transfer and replication, restricting interaction patterns, and enforcing policies in real time. Access is no longer a one-time event. It becomes continuously governed. This becomes even more critical as AI assistants consume content across SharePoint, Teams, Exchange, and other Microsoft 365 services. The question is no longer only where the source document resides - but whether the AI interaction itself is governed by the same access and protection controls as direct access. Layer 3: The document becomes the control point The most durable control does not sit in the network or in the session. It sits in the data itself. In regulated industries, organizations often arrive at this architecture having first evaluated sovereign or national encryption solutions. The decision to rely on native Microsoft 365 Purview encryption rather than a separate layer comes down to integration: AES-256 protection operating natively at file, user, and SharePoint level - including geo-based access restrictions - without an additional system to maintain. When protection is applied directly to the document through Microsoft Purview: Sensitivity labels define classification - automatically assigned based on content Encryption enforces access - AES-256, bound to the file itself IRM controls usage - view, copy, print, share, and presentation rights DLP governs movement across services - preventing data from leaving defined boundaries Dynamic watermarking tracks exposure - applied on open, view, or print At that point, access is enforced by the file, usage restrictions travel with it, and control persists regardless of location. The document becomes the perimeter. Platform control: limiting provider access One dimension often overlooked in sovereignty discussions is platform access itself. Even a perfectly configured tenant is only as sovereign as the controls placed on the operator. Customer Lockbox ensures that even Microsoft support cannot access customer data without explicit, logged, time-bound approval. Every access request is visible, auditable, and subject to customer veto. Data control applies not only to users - but also to the platform operating the service. Enforcement requires an integrated architecture Most organizations already have the required capabilities: Multi-Geo, Conditional Access, session control, Purview (labels, encryption, DLP, IRM), and monitoring. The issue is not capability. It is fragmentation. In practice, fragmentation looks like this: residency is configured in one project, Conditional Access policies are managed by a different team, and Purview labels were applied during a compliance initiative that never connected to the access layer. The tools exist. The signals do not flow between them. When designed as a single architecture: Data is placed intentionally - residency aligned to regulatory requirements Access is governed by context - device, location, and identity evaluated continuously Usage is controlled dynamically - session-level restrictions enforced in real time Protection is embedded in the document - encryption and IRM travel with the file Signals are connected across the platform - monitoring feeds access policy, not just audit logs “Data in Switzerland” becomes not just a statement - but an enforceable system property. Closing thought Placing data in Switzerland is the right first step. Multi-Geo makes it possible, even in global environments. But residency alone is not control. Data residency answers where information is stored. Data sovereignty requires proving who can access it, under which conditions, and what controls remain in place after access is granted. In Microsoft 365, sovereignty is no longer defined by geography alone. It is defined by the ability to enforce control wherever the data travels.Microsoft Purview enables developers with strong data security across AI apps and agents
Today, developers are at the center of a new wave of innovation—building AI applications and agents that are deeply connected to enterprise data. But with this opportunity comes a new and complex set of security challenges. AI systems operate across cloud platforms, third-party services, and even local and on-premises development environments, interacting dynamically with sensitive data such as customer records, financial information, and intellectual property. Traditional security approaches weren’t designed for this level of scale, autonomy, or fluid data movement—leaving developers to navigate fragmented tools, unclear policies, and the risk of unintentionally exposing sensitive information. At the same time, expectations are rising. Organizations need to ensure that AI applications and agents are compliant, auditable, and secure by default on an enterprise-level—not retrofitted after deployment. But for developers, adding security often means additional complexity, custom integrations, and slower time to market. This tension between speed and control has become one of the biggest barriers to moving AI from experimentation into production. Microsoft Purview is designed to help with this challenge by embedding data security and compliance controls across the development cycle. Purview provides a consistent way to govern how data is accessed, used, and shared—without requiring developers to become security experts. The result is a simpler path to building AI systems that are secure, compliant, and enterprise-ready by design. Extending data security and compliance to local agents and claws Local and endpoint agents, built in platforms such as GitHub Copilot CLI and OpenClaw, introduce a new class of data security challenges as they operate outside traditional control planes and directly on user machines. Unlike cloud systems, these agents can access local files, credentials, terminals, and enterprise apps simultaneously—often moving data across tools and environments. This expands data risks, from sensitive data being unintentionally stored, copied, or shared, to API keys and tokens being exposed, and autonomous workflows triggering data movement without explicit user intent. At the same time, many existing security controls were designed for browser or cloud-based activity, leaving a growing blind spot at the endpoint where agents are increasingly running. The result is a widening gap between how developers build agents to operate locally in the users machines, and how organizations can detect, govern, and protect the data those agents interact with. Microsoft Security and Windows are integrating management and security capabilities directly into the local agents’ development workflow, enabling security as an architectural guarantee rather than an implementation choice. At Build, we are thrilled to be extending Purview visibility and protection capabilities to local agents developed on GitHub Copilot CLI, Claude Code, OpenAI Codex, and OpenClaw - in Public Preview. Unlike traditional cloud applications, these agents operate closer to the data and often create new risks for data exposure. Purview addresses this challenge across all types of agent interactions with a clear, simplified set of scenarios: ▪ Observability: Visibility on Purview Data Security Posture Management (DSPM) across agent inventory, as well as into how local agents interact with sensitive data—across prompts, responses, and actions. ▪ Runtime data protection: Purview Data Loss Prevention (DLP) controls enforced directly into the agent execution flow, inspecting prompts and tool calls in real time to prevent sensitive data exfiltration. ▪ Agentic risk detection: Risky or anomalous agent behaviors detected through Insider Risk Management (IRM) signals, helping teams detect unsafe interactions early. ▪ Audit: Comprehensive, end-to-end logging of all local agent interactions—capturing prompts, responses, data access, and actions for data context. For example, a developer is using a local coding agent to generate code and accidentally includes sensitive credentials in a prompt. AI observability in DSPM surfaces the interaction and shows what data the agent accessed. DLP detects the sensitive data in real time and blocks it from being sent or processed (or sensitive files from being accessed and exfiltrated). At the same time, agentic risk detection flags the session as high risk based on the behavior pattern. All of this activity is captured in audit logs, enabling the security team to investigate and take action quickly. Developers and security teams gain visibility into agent activity and data interactions, while policies prevent sensitive data leakage. This ensures consistent security outcomes across both cloud and endpoint environments, without disrupting developer workflows. Strengthening visibility and controls for Foundry agents Foundry gives developers a central place to build and manage AI agents, but it also creates a need for data security context directly in that workflow—especially as prompts, model interactions, and downstream actions increasingly involve sensitive enterprise data. At Build, we are excited to announce the expansion of the Foundry integration with Purview. This includes Purview DLP runtime controls for prompt processing in Foundry, in Public Preview. As agents and applications built on Foundry increasingly interact with sensitive data, Purview ensures those interactions are governed by trusted controls, identifying Sensitive Information Types (SITs) in real time to detect and protect confidential data embedded in prompts. For example, if a user includes customer PII or financial data in a prompt, Purview can automatically identify the sensitive content and block that prompt from being processed by the model. This ensures that all Foundry apps and agents, regardless of how they’re built or deployed, inherit consistent data protection – allowing organizations to reduce risk of inadvertent data exposure, centralize compliance enforcement across AI workloads, and confidently scale AI adoption knowing sensitive data is protected by design. We’re also building up on the Purview coverage for Foundry shared at the last Microsoft Ignite by announcing Purview insights embedded directly into the Foundry Control Plane, in General Availability, bringing rich data security context to the plane where developers already work. Purview surfaces crucial signals—such as SITs detected in the agentic interactions, % of agentic interactions involving sensitive data, and spread of high-risk users — so Foundry admins can know how AI apps and agents are built in their environment. This shift enables developers to make faster, better decisions in the moment, reducing rework and closing security gaps early on. For customers, the value is clear: stronger security by design and at enterprise scale, accelerated development cycles, and reduced risk of data leaks or compliance issues—without slowing down innovation. Innovating for developers everywhere, at the pace of AI growth Microsoft is also expanding Purview’s reach across the broader developer ecosystem. New integrations help organizations apply consistent oversight to AI tools and platforms developers already use, without adding separate compliance workflows. GitHub Copilot is a critical productivity layer for developers, accelerating how code is written and shipped—making it equally important that developer interactions with GitHub Copilot are governed and secured with the same rigor as enterprise data. Microsoft Purview now extends data governance and compliance capabilities to GitHub Copilot interactions, in Public Preview, enabling GitHub Enterprise customers with Entra SSO to stream audit logs directly into Purview. This brings centralized visibility for AI activity, allowing security and compliance teams to analyze GitHub Copilot agent session activity alongside other AI workloads. With this native integration into GitHub workflows, Purview audits Copilot activity across repositories, pull requests, and developer sessions—ensuring AI-generated code aligns with enterprise data policies, compliance requirements, and secure development standards. By integrating Purview into existing workflows, organizations can govern GitHub AI usage without building parallel pipelines—reducing complexity while ensuring consistent compliance coverage across their entire data estate. Today’s AI agents aren’t built in just one ecosystem—they span custom apps, third-party platforms, and open-source frameworks. Without consistent controls, this creates blind spots where sensitive data can be exposed outside enterprise guardrails. That’s why extending Purview protection beyond Microsoft environments is critical: it ensures developers can apply the same data security, DLP policies, and compliance controls to any agent, anywhere—so innovation can scale without increasing risk. Developers already use Microsoft Purview APIs to embed data protection into enterprise workflows. Today, we’re introducing the Microsoft Purview SDK for .NET — a simple, drop-in toolkit that brings Purview capabilities directly into any application, in Public Preview. Instead of weeks spent wiring APIs, authentication, and error handling, developers can add content scanning, DLP checks, and sensitivity labeling in just a few lines of code. The SDK handles the heavy lifting — including auth, retries, caching, and telemetry — so teams can focus on building experiences. For AI apps and agents built outside of the Microsoft AI platforms, SDK adds built-in support and can evaluate prompts and responses in real time against DLP and content policies — helping prevent data exposure at runtime without custom logic. Designed for both real-time and asynchronous patterns, and for authenticated or anonymous flows, the SDK also feeds activity back into Purview to give security teams centralized visibility and control. The bottom line is- the Microsoft Purview SDK enables developers to build AI apps and agents that are secure and compliant by default — cutting integration time from weeks to days while ensuring data protection scales with AI. The SDK will be available in public preview within the next month. Together, these announcements represent a significant step forward in how developers build secure AI systems. Microsoft Purview is no longer just a data security and compliance solution—it is a first-class layer of the development process by protecting data across AI applications and agents, and enables a bridge between developers and security teams. As AI becomes more agentic, distributed, and deeply connected to enterprise data, the need for built-in security will only grow. With Purview, developers no longer must choose between speed and security—they can build both into every application from the start Getting connected with Microsoft Purview and learn more Learn more about Microsoft Purview on our website and Microsoft Learn. Explore Agent 365. Try Microsoft Purview data security. Learn more about Microsoft Purview SDK.The Fileless Paradox: How My 33-Day-Old Research Became Today's Ransomware Reality
33 Days Before BARADAI Emerged 🔴 Before You Read: What Is This Article About? This is the first article I have published on Microsoft Tech Community, and this is not a standard threat report. This is the story of being right before anyone believed it — and of a ransomware family called BARADAI that proved it. On April 5, 2026, I published a technical research article documenting, in detail, a fileless malware architecture that operated entirely in RAM using steganography and Windows Registry persistence. When I shared it on social media, the reactions were immediate and brutal: “A fileless payload cannot be persistent. If it leaves no trace on disk, it cannot survive a reboot.” “This technique is entirely theoretical. No real threat actor would ever use this in production.” “You cannot have persistence without leaving traces. Pick one.” And the most absurd ones: “Stop writing articles with AI.” “This level of technical detail is unrealistic — did AI generate this?” “Forensic artifacts cannot be erased. What kind of technique is this?” At that moment, I could not prove myself. I had a working proof-of-concept. I had built the architecture myself. The technical logic was sound. But I did not yet have a real-world threat actor using it in production. 33 days later, BARADAI appeared. And it used the exact same playbook I had written. This article is the first volume of the “We Saw It Coming” series. In this series, I correlate my independent research with emerging real-world threats, document technical overlaps, and provide actionable detection and defense guidance for Microsoft environments. Right now, I am actively trying to reverse and decrypt BARADAI. I do not yet have a definitive solution. But I am publishing this journey because my goal is to finalize a solution by collecting additional logs and intelligence. 📌 Table of Contents The Moment Nobody Believed 33 Days Later: Meet BARADAI The B-Family: Shared Infrastructure Ecosystem Side-by-Side: Technical Overlap Analysis Deep Dive: The Fileless Paradox — How Both Architectures Work The PAIDMEMES Anomaly: Forensic Residue Inside BARADAI My Technique vs BARADAI: Shared Technical Patterns Microsoft Sentinel Detection Rules (KQL) MITRE ATT&CK Mapping Decryption Research and My Current Approaches Defensive Recommendations Sources and References ------------------------------------------------------------------------------ 1. The Moment Nobody Believed April 5, 2026 — A Research Paper, a Community, and Silence On April 5, 2026, I published a detailed technical research article on Medium titled: “STEGOMALWARE — PNG Persistence Through Steganography and Windows Registry” The article documented a complete attack architecture that I designed and tested from scratch in a controlled laboratory environment. My core thesis was this: A fileless malware strain can achieve persistent, reboot-resilient execution without ever writing a malicious executable to disk — by hiding its payload inside the pixels of a PNG image using LSB steganography and leveraging the Windows Registry for persistence. I demonstrated this by building a keylogger. The architecture had four defining characteristics: Feature 1 — Fileless Execution (RAM-Only) The malicious payload never touches disk as an executable file. Instead, a small, “clean-looking” loader script extracts hidden code from the pixel data of a PNG image and executes it directly in RAM. No .exe, no .py, no .dll on disk. Traditional antivirus file-scanning mechanisms are effectively blind to this. Feature 2 — Registry-Based Persistence Contrary to critics claiming that fileless malware cannot survive reboots, the loader writes itself into the Windows Registry Run key: HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run This means that every time Windows starts, the loader executes again, extracts the payload from the PNG, and runs it back in memory. The malware lives in the Registry — not on disk. Feature 3 — Process Masquerading I compiled the loader under the name svchost.exe and assigned it a Windows service icon. When viewed in Task Manager, it appeared indistinguishable from a legitimate Windows system process. Feature 4 — Self-Repair (Self-Integrity Check) The loader continuously validated both its Registry entry and its file copy. If an antivirus product deleted the file or removed the Registry entry, the loader detected the modification and restored itself during the next execution cycle. Feature 5 — Intelligent Data Collection The keylogger I built automatically embedded collected data into the pixels of a PNG image every 10 characters or every 30 seconds — whichever occurred first. After each cycle, it reset itself, cleared temporary memory artifacts, and initiated a fresh collection loop. This architectural design enabled the malware to remain undetected on a system for months. Because there was no ever-growing log file on disk — the data was continuously transferred into images. ------------------------------------------------------------------------------------------ The Reactions The reactions I received when sharing this research did not surprise me, but they disappointed me. Technical objections: “Fileless malware, by definition, cannot survive reboots. No disk means no persistence.” “Forensic evidence cannot be erased. This makes no technical sense.” “If you are writing to the Registry, then it is not truly fileless.” Personal attacks: “Stop writing with AI.” “If you can perform technical analysis this detailed, why has nobody heard of you before?” “Copied from AI — even the formatting looks AI-generated.” This feedback revealed two things: First, people fundamentally misunderstood the concept of fileless malware — they were confusing “fileless execution” with “leaving absolutely no traces anywhere.” The Registry is not a traditional file in the conventional sense, yet it remains a persistent storage mechanism resilient across reboots. Second, it demonstrated how easily independent researchers are dismissed. Research not published by a major corporation or university was automatically labeled “AI-generated” or “theoretical.” At that moment, I could not prove myself. 33 days later, BARADAI proved me right. ------------------------------------------------------------------------------ 2. 33 Days Later: Meet BARADAI May 5–8, 2026 — A New Threat Surfaces On May 5, 2026, researchers at PCrisk documented a new ransomware sample submitted to VirusTtl. On the same day, CYFIRMA’s underground forum monitoring team flagged it in their threat intelligence feeds. By May 8, CYFIRMA’s Weekly Intelligence Report had published the first structured analysis. The threat was named BARADAI — derived from the extension it appends to encrypted files: .BARADAI -------------------------------------------- What Is BARADAI? BARADAI is a Windows ransomware variant belonging to the MedusaLocker family. MedusaLocker has been active since late 2019 and remains one of the most prolific and long-lived ransomware-as-a-service (RaaS) operations in the threat landscape. BARADAI is a specific variant of the MedusaLocker v3 architecture — sometimes tracked in threat intelligence repositories as “BabyLockerKZ.” Detection names across major security vendors: Microsoft Defender: Ransom:Win64/MedusaLocker.MZT!MTB ESET: Win64/Filecoder.MedusaLocker.A Avast: Win64:MalwareX-gen [Ransom] Kaspersky: HEUR:Trojan-Ransom.Win32.Generic ------------------------------------------------------------ How Does It Operate? BARADAI follows a double-extortion model. Silent Phase (Reconnaissance) After initial access, BARADAI does not immediately begin encryption. Instead, it performs systematic reconnaissance: -Enumerates running processes -Maps network topology -Collects browser-stored credentials -Harvests session cookies and SSL certificates -Captures desktop screenshots -Exfiltrates collected data to attacker-controlled C2 infrastructure Encryption Phase After exfiltration is complete, BARADAI activates its cryptographic payload: -AES-256-CBC for file content encryption -RSA-4096 for key protection Extortion Phase A ransom note (read_to_decrypt_files.html or WHATS_HAPPEND.txt) is dropped into every encrypted directory. Victims are given a 72-hour deadline. If payment is not made before expiration, stolen data is published on the group’s Data Leak Site (DLS). ------------------------------------------------------------------- Confirmed Targeting as of May 2026 Geographies -United States -Brazil -France -Australia -Italy -Israel -Malaysia Sectors -Education -Manufacturing -Engineering -Retail -Logistics -NGOs Ransom Demand Range -USD $10,000 — $80,000 per incident (CYFIRMA, May 2026) ------------------------------------------------------------------ 3. The B-Family: Shared Infrastructure Ecosystem One of the most important findings that emerged during my analysis was this: BARADAI is not operating alone. Threat intelligence monitoring identified a cluster of MedusaLocker variants sharing: -The same naming conventions -Similar code architecture -And most critically — the same Tor-based infrastructure I named this cluster: “The B-Family” --------------------------------------------- Evidence of Shared Infrastructure The strongest evidence of coordination inside the B-Family is not behavioral similarity — it is shared infrastructure. BARADAI’s ransom note lists the following Tor hidden service for victim negotiations: t33zoj4qwv455fog7qnb2azi5xcdxkixughmmduzbw2rtdgryqfbh6id.onion This is identical to the Tor address listed as the Data Leak Site and file leak server for BAVACAI — independently verified by ransomware.live, which identified the server running NGINX 1.24.0. PCrisk’s BARADAI documentation also includes screenshots of the leak site using the filename prefix: bavacai- This is structural evidence confirming that the same backend infrastructure serves both variants. What This Means The B-Family is not a collection of copycat operations. It is a single operation — or a tightly coordinated RaaS affiliate ecosystem — using different “brand names” per campaign in order to complicate attribution, tracking, and law enforcement disruption. ----------------------------------------------------------- Known Victims (BAVACAI DLS — Shared Backend) As of May 8, 2026, the BAVACAI DLS listed 16 victims — all published simultaneously on May 5. ------------------------------------------------------------ 4. Side-by-Side: Technical Overlap Analysis This section is the core of the article. The table below correlates the exact techniques documented in my April 5, 2026 research with the verified BARADAI behaviors documented by CYFIRMA, PCrisk, and the broader MedusaLocker analysis corpus. The conclusion is direct and unavoidable: The architecture I built, tested, documented, and published in a controlled laboratory environment on April 5, 2026 — the same architecture the community dismissed as “theoretical,” “AI-generated,” and “impossible” — was operationalized by a real threat actor 33 days later. -------------------------------------------------------- 5. Deep Dive: The Fileless Paradox Let us settle the debate permanently. The Misconception: “Fileless Malware Cannot Be Persistent” The argument I repeatedly encountered was this: “If malware does not leave files on disk, it cannot survive a reboot because RAM is volatile.” Technically correct. Strategically incomplete. It is true that RAM-resident code disappears when the system powers off. However, persistence does not require the malicious payload itself to reside on disk. It requires a mechanism that re-executes the payload after reboot. Those are two different things. -------------------------------------------------------------- The Architecture: How It Actually Works ┌──────────────────────────────────────────────────────────┐ │ ATTACK ARCHITECTURE │ │ │ │ DISK (minimal footprint): │ │ ┌──────────────────────────────────────────────────┐ │ │ │ loader.exe (masquerading as svchost.exe) │ │ │ │ cover_image.png (contains hidden payload) │ │ │ └──────────────────────────────────────────────────┘ │ │ │ │ │ REGISTRY (persistence): │ │ │ ┌──────────────────────────────────────────────────┐ │ │ │ HKCU\...\Run\WindowsUpdateService │ │ │ │ → points to loader.exe │ │ │ └──────────────────────────────────────────────────┘ │ │ │ │ │ ON EVERY BOOT: │ │ │ Registry triggers → loader.exe executes → │ │ Reads PNG pixels → extracts payload → │ │ Loads into RAM → executes │ │ (No malicious .exe is ever written to disk) │ │ │ │ RAM (execution): │ │ ┌──────────────────────────────────────────────────┐ │ │ │ Keylogger / RAT / Ransomware module │ │ │ │ Executes entirely in memory │ │ │ │ Invisible to disk-based AV scanning │ │ │ └──────────────────────────────────────────────────┘ │ └──────────────────────────────────────────────────────────┘ Only the loader exists on disk — and the loader itself is a small, legitimate-looking executable without a malicious signature. The malicious payload lives in: -The pixel data of the PNG image (steganographically encoded) -RAM (during active execution) The Registry provides the trigger mechanism — not the payload itself. That was the exact distinction critics failed to understand. ------------------------------------------------------------------ Why It Evades Traditional Detection BARADAI’s Implementation BARADAI uses the same logical architecture at larger scale. The MedusaLocker v3 binary: - Achieves persistence via Registry Run Key: HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\BabyLockerKZ -Executes core ransomware logic in memory without writing recoverable payload components to disk -Uses Parent PID Spoofing (T1134.004) to appear as a child process of explorer.exe or svchost.exe -Restores itself through persistence mechanisms if binaries are deleted ------------------------------------------------------------------------------ 6. The PAIDMEMES Anomaly: Forensic Residue Inside BARADAI One of BARADAI’s most distinctive — and frankly bizarre — technical characteristics is its configuration and key storage mechanism. Unlike most ransomware variants that attempt to keep all cryptographic material exclusively in volatile memory, BARADAI writes directly into the Windows Registry under an extremely unusual hive: HKCU\SOFTWARE\PAIDMEMES\PUBLIC HKCU\SOFTWARE\PAIDMEMES\PRIVATE - HKCU\SOFTWARE\PAIDMEMES\PUBLIC stores the Base64-encoded RSA public key extracted from the malware configuration. - HKCU\SOFTWARE\PAIDMEMES\PRIVATE stores encrypted runtime state and configuration parameters required for persistence across multiple execution instances. ------------------------------------------- Why This Matters The PAIDMEMES Registry hive is not random — it serves a specific operational purpose. When BARADAI is launched with the -network flag (instructing it to encrypt network shares), it spawns a secondary instance of itself as a non-elevated process. By storing cryptographic keys and configuration inside the Registry, that secondary instance — even without administrative privileges — can access everything necessary to continue the attack. These two Registry artifacts represent your highest-confidence BARADAI detection signals: HKCU\SOFTWARE\PAIDMEMES (Key creation = active infection) HKCU\...\Run\BabyLockerKZ (Persistence = infection survived reboot) ------------------------------------------------------------ 7. My Technique vs BARADAI: Detailed Technical Similarities Now let us go deeper technically and explain why I believe I am one of the people closest to understanding BARADAI. 7.1 Payload Concealment: LSB Steganography My Technique I replaced the least significant bits (LSB) of RGB channels in PNG pixels with Base64-encoded keylogger payload bits. A 1/255 modification inside an 8-bit value is visually imperceptible to the human eye. In BARADAI The stegomalware technique forms the core of payload transportation. The same LSB logic applies: -No visible image corruption -No signature-based scanner triggers -Payload blended into image “noise” Shared Point Mathematically, it is the same approach. The only difference is scale: I concealed a keylogger. BARADAI conceals a ransomware module. -------------------------------------------------------- 7.2 Fileless + Registry: The “Impossible” Combination My Technique I registered my loader under: HKCU\...\Run\WindowsUpdateService Every time Windows booted, the loader executed, read the PNG, extracted the payload into RAM, and launched it. A .py file never existed on disk. In BARADAI HKCU\...\Run\BabyLockerKZ Exactly the same mechanism. Same Registry path. Same logic. Same “fileless yet persistent” paradox. ------------------------------------------------- Shared Point When critics claimed these two concepts could not coexist, they were wrong. Both BARADAI and I proved it. 7.3 Process Concealment: svchost.exe Masquerading My Technique I compiled the loader with PyInstaller under the name svchost.exe and assigned it a Windows service icon. Inside Task Manager, it appeared identical to a legitimate system process. In BARADAI BARADAI uses Parent PID Spoofing. Through Windows API manipulation, it makes execution appear as if initiated by svchost.exe or explorer.exe. EDR behavioral engines typically flag unknown processes performing system-level modifications. This technique bypasses those checks. Shared Point Same concealment strategy. Different implementation layer. 7.4 Timers and Silent Collection My Technique The keylogger embedded data into PNG images every 10 characters OR every 30 seconds — whichever occurred first. After each cycle: -Temporary memory artifacts were cleared -The process reset -No ever-growing log file existed on disk This is why antivirus products could not see it. This is why it could remain undetected for months. In BARADAI “Ghost Software.” After initial compromise, BARADAI does not immediately encrypt. It silently waits. Harvests credentials. Maps the network. Exfiltrates data. Encryption is the final signature. Shared Point Both architectures rely on a “silent hunter” model. I used 30-second image-based exfiltration loops. BARADAI remains dormant for days or weeks while collecting intelligence. The logic is identical. Only the timescale differs. ---------------------------------------------------------------- 7.5 Why I Believe I Am One of the People Closest to Solving BARADAI These similarities are not coincidence. They reflect the same technical mindset reaching the same solutions to the same problems. Because I built this architecture from scratch: -I understand its weak points — because I encountered the same weak points myself -I can reverse-engineer LSB steganography workflows — because I wrote the same algorithm -I understand Registry-based configuration logic — the PAIDMEMES hive pattern is familiar to me - I understand interruption points inside timer-based collection loops — because I built the same cycle architecture myself ------------------------------------------------------------------------------ 8. Microsoft Sentinel Detection Rules (KQL) The following Kusto Query Language (KQL) queries are designed for deployment in Microsoft Sentinel. They target specific behavioral artifacts associated with BARADAI and the broader MedusaLocker family. Deploy all three as scheduled analytics rules. Rule 1: PAIDMEMES / BabyLockerKZ Registry Artifact Detection High confidence. Detects exact forensic strings unique to MedusaLocker v3 / BARADAI. If This Rule Triggers The device is actively infected with BARADAI or the malware has successfully established persistence. Treat as a P1 incident. Immediately isolate the endpoint. Rule 2: Shadow Copy & Backup Deletion Chain Detection High confidence. Detects BARADAI’s recovery-destruction sequence. If This Rule Triggers A ransomware payload is actively preparing for encryption. This is your final detection window before data loss begins. Immediately isolate the affected endpoint and every reachable network share. Rule 3: EnableLinkedConnections — Network Share Privilege Escalation Detection Medium-High confidence. Detects BARADAI’s technique for accessing administrator-mapped network drives from non-elevated processes. If This Rule Triggers An attacker is preparing to encrypt network shares normally visible only to administrator-level processes. This is a pre-encryption lateral movement signal. ---------------------------------------------------------------- 9. MITRE ATT&CK Mapping ------------------------------------------------------------------------------ 10. Decryption Research and My Current Approaches Let me be completely transparent. Current status: There is no verified public decryptor available for BARADAI. -The No More Ransom project lists no decryptor for any MedusaLocker v3 / BabyLockerKZ variant -The AES-256-CBC + RSA-4096 implementation is mathematically sound -Historical decryptors existed only for significantly older MedusaLocker v1 and early v2 variants by exploiting key sanitization weaknesses in memory management -Those vulnerabilities were patched in v3 What We Know About the Encryption BARADAI uses intermittent encryption for large files: -Files larger than ~7.7MB are not fully encrypted -The malware encrypts 750KB, skips 250KB, encrypts another 750KB, and repeats This dramatically reduces encryption time while still rendering the file structurally unusable. --------------------------------------------------------------- What I Am Currently Researching I am currently analyzing the BARADAI binary from multiple angles: PRNG Weaknesses I am investigating the entropy source used during AES key generation. If the PRNG is insufficiently random, the effective key space may be reducible. Key Sanitization Behavior I am investigating whether AES keys remain in memory after usage. This weakness existed in MedusaLocker v1 and v2 and enabled historical decryptors. Although patched in v3, implementation mistakes remain possible. PAIDMEMES Registry Storage Analysis The PAIDMEMES hive stores runtime state. I am investigating whether this storage area contains recoverable cryptographic material. Registry-stored cryptographic data could provide a viable decryption foothold. Weaknesses in Intermittent Encryption The 750KB-encrypt / 250KB-skip pattern enables structural comparisons between encrypted and unencrypted regions. Known file formats (.docx, .xlsx, etc.) contain predictable header structures. This creates potential for partial known-plaintext attacks. ------------------------------------------------------------------------------ I will publish my findings in Vol.4 of this series regardless of the outcome. ------------------------------------------------- If You Are a BARADAI Victim -Do not pay the ransom until all alternatives are exhausted -Contact professional incident response services -Preserve all encrypted files and ransom notes — a future decryptor may eventually become available -Regularly monitor nomoreransom.org ---------------------------------------------------- 11. Defensive Recommendations Priority 1: Phishing-Resistant MFA (Against AiTM) Traditional MFA — push notifications, SMS codes, authenticator apps — can be defeated by AiTM reverse-proxy attacks. Deploy: -FIDO2 hardware security keys (YubiKey, etc.) -Windows Hello for Business These technologies cryptographically bind authentication tokens to the legitimate TLS session of the login portal. Stolen cookies become useless in separate sessions. ------------------------------------------------------- Priority 2: Eliminate RDP Exposure BARADAI’s primary initial access vector is exposed RDP on TCP 3389. -Disable Internet-facing RDP at the perimeter firewall -Enforce MFA + VPN for all remote administrative access -Implement account lockout policies and Network Level Authentication (NLA) Priority 3: Immutable Backups BARADAI deletes Volume Shadow Copies via vssadmin. Implement: -A 3–2–1 backup strategy with at least one offline/immutable copy -Azure Immutable Blob Storage (WORM) -Multi-user authorization for backup vaults -Monthly restoration testing --------------------------------------------- Priority 4: FSRM Canary Files Configure Windows File Server Resource Manager (FSRM): Immediately alert when files with extensions: .BARADAI .BAVACAI .BASANAI .BAGAJAI are created. Trigger automated scripts that: -Terminate the originating user session -Revoke network share access -------------------------------------------------- Priority 5: Deploy the Sentinel KQL Rules Above The three rules in Section 8 provide layered behavioral detection that signature-based tooling cannot replicate. Deploy them before an incident occurs. -------------------------------------------------------------------------- Priority 6: Zero Trust Architecture BARADAI’s EnableLinkedConnections Registry modification allows standard user processes to encrypt administrator-mapped drives. -Segment backup servers, Domain Controllers, and critical infrastructure -Require hardware-backed MFA for sensitive segments -Implement least privilege and Just-In-Time (JIT) administrative access with Azure PIM ------------------------------------------------------------------------ 📢 Call to Action: Collective Intelligence I started this research alone. But disrupting the impact of the B-Family requires collective effort. If your organization or threat-hunting operations have observed additional logs, unusual network traffic, or alternative steganographic payload samples associated with the B-Family (BARADAI, BAVACAI, BASANAI, etc.), do not remain silent. Data Sharing You may share anonymized IoCs or log artifacts with us. and Direct Contact If you have technically significant observations or findings related to BARADAI analysis, you can contact me directly through my Webex profile. Webex Contact - email address removed for privacy reasons Our collective security depends on the aggregation of these small signals. --------------------------------------------- Sources and References For technical verification and further investigation, refer to the following resources: Threat Intelligence & Ransomware Reports CYFIRMA: Weekly Threat Intelligence Report (2026–05–08) Ransomware.live: BAVACAI Group & DLS Infrastructure PCrisk: BAVACAI | BAGAJAI | BASANAI Analysis Technical Foundations & MITRE TTPs CISA: MedusaLocker Advisory (AA22–181A) Picus Security: MedusaLocker TTPs and Simulation Barracuda: GhostFrame Phishing Kit Spotlight (2025–12–04) Detection & Response Tools Microsoft Sentinel: Official Shadow Copy Deletion Analytics Rule GitHub (Bert-JanP): Hunting Queries and Detection Rules No More Ransom: Global Decryption Tools Repository Cassandra MARE Independent Research Deniz Tektek: Stegomalware & Fileless Persistence (2026–04–05) https://medium.com/@deniizz/stegomalware-steganografi-ve-windows-registry-ile-kalıcılık-sağlayan-png-01e50849a218 Cassandra Community: Initial BARADAI Analysis (2026–05–14) https://medium.com/@cassandracommunity/baradai-ransomware-hayalet-yazılım-ı-parçalarına-ayırıyoruz-0c04bb008f73 This article has been published strictly for defensive purposes. All described techniques have been analyzed within the context of threat detection and defense. This is my debut article on the Microsoft Tech Community. I am Deniz Tektek, a Red Team Operator, Cybersecurity Analyst, and Founder of the Cassandra community. My work focuses on the intersection of human psychology, IoT security, and the development of zero-trust local AI agents. This article, “The Fileless Paradox,” is the inaugural entry in my "We Saw It Coming" threat intelligence series, where I document technical overlaps between independent research and active real-world threats. What’s Next? Vol. 2: "Invisible Exfiltration" — Analyzing how BARADAI’s C2 hides in plain sight. Vol. 3: "The Human Gateway" — Why your MFA and AI-driven defenses are currently being bypassed. Vol. 4: "Cracking BARADAI" — My ongoing decryption research. Connect With Me If you want to discuss these findings, exchange logs, or collaborate on security research, please check my profile bio for contact information or connect with me via LinkedIn. I welcome all technical perspectives and peer reviews. My LinkedIn: https://www.linkedin.com/in/deniz-t-91166438a Deniz Tektek — May 2026 © Deniz Tektek & Cassandra — All Rights Reserved. Originally published on Microsoft Tech Community. Cross-posted on Medium.Safeguarding Sensitive Data in Microsoft 365 Copilot Interactions: DLP for Microsoft 365 Copilot
Microsoft 365 Copilot is redefining how organizations work, bringing the power of generative AI directly into our secure productivity tools. As Copilot adoption accelerates, we’ve heard that you want more control over how your sensitive data can be used in interactions with Copilot. At Ignite 2025, Microsoft announced a major enhancement: Microsoft Purview Data Loss Prevention for Microsoft 365 Copilot to safeguard Microsoft 365 Copilot and Copilot Chat prompts, now entering General Availability. Even better, this capability is included for all users of Microsoft 365 Copilot and Copilot Chat. Why DLP for Copilot Prompts Is a Game-Changer As organizations adopt Copilot, their ways of sharing, creating, and interacting with data expand. With just a prompt, users can have Copilot summarize documents, analyze spreadsheets, or help brainstorm presentations. However, it raises an important question: what if the prompt includes sensitive information, like project code names, financial account numbers, health records, or other sensitive data? Over the last 2 years, Microsoft has been building a set of Data Loss Prevention (DLP) controls specifically designed for Copilot. Below is a quick overview of these related capabilities — ranging from already available to newly in preview — before we dive deep into today's GA announcement: Prevent Copilot processing of files & emails based on sensitivity labels In November 2024, Microsoft introduced the ability to create a DLP policy to restrict Microsoft 365 Copilot and Copilot Chat from processing sensitive files and emails using Sensitivity Labels for grounding data. This capability gives you control over whether content with the sensitivity labels you specify is restricted from being used in Microsoft 365 Copilot and Copilot Chat to generate summaries and responses. Prevent web searches for prompts containing Sensitive Information Types (SITs) The latest feature entering Public Preview is DLP for Microsoft 365 Copilot and Copilot Chat to prevent web searches for prompts containing sensitive data. This real-time control helps organizations mitigate data leakage and oversharing risks by preventing Microsoft 365 Copilot and agents from using sensitive data for external web searches. If a sensitive information type (SIT) is detected in a user prompt, Copilot can still leverage your enterprise data to form a response without sending the sensitive data to external search engines for web grounding. This capability extends to Microsoft 365 Copilot and agents built in Copilot Studio that are published to Microsoft 365 Copilot. DLP to Safeguard Copilot Prompts with Sensitive Information Types (SITs) The rest of this blog focuses on a key addition to this capability set: DLP for Microsoft 365 Copilot + Copilot Chat prompts to prevent processing of prompts containing sensitive information, now entering General Availability. Unlike the web search capability above, which prevents sensitive data from being sent externally during a web query, this capability evaluates the user’s text input directly, before processing occurs, to determine whether both enterprise data and web grounding can proceed. This feature uses Sensitive Information Types (SITs) as a condition within a Purview DLP policy to assess whether a user prompt sent to Copilot contains sensitive data, even if the data is unlabeled. With DLP for Copilot prompts, a user’s text input is scanned in real time for SITs, whether built-in (like Social Security Numbers, credit card numbers, etc.) or custom-defined by your organization (such as confidential terms or project names). If a text prompt contains one of the SITs you specify, Copilot restricts processing, halts any Graph or web grounding, and displays a clear message to the end user that the request cannot be completed. A user enters a prompt in Microsoft 365 Copilot Chat containing sensitive information. How DLP for Copilot Protects Prompts: Real-Time, Intelligent Protection The new DLP capability integrates seamlessly with Microsoft Purview, leveraging its powerful data classification & detection engine for sensitive information types. Here’s how it works: Input: When a user submits a prompt, Copilot checks the prompt for sensitive information using built-in or organization-defined sensitive information types (SITs). Immediate Action: If a SIT is detected, Copilot restricts the prompt from being processed. No AI response is generated, and no data is sent for Graph or web grounding. Output: Users receive a clear notification that their request cannot be completed due to company policies. This real-time protection ensures that sensitive data is not leaked or overshared, even as users explore new ways to work with AI. Setting Up DLP for Copilot Prompts: Data Security Admin Experience The easiest way to get started is through the new Microsoft Purview Data Security Posture Management (DSPM) portal, which provides a guided, one-click setup experience: 1. In Purview, go to Solutions > DSPM (preview) 2. Select the "Prevent data exposure in Microsoft 365 Copilot and Microsoft Copilot interactions" objective. 3. Follow the guided workflow and apply the recommended one-click DLP policy. The policy starts in simulation mode so you can review activity before enforcing it. Alternatively, you can configure and customize this policy directly from the Purview DLP portal Policies page or enable it from the Microsoft 365 Admin Center. view the remediation plan. view policy details and review. Then click the button, create a custom policy in DLP simulation mode to protect sensitive data referenced in Microsoft 365 Copilot and Microsoft Copilot. the confidence level and instance count. Practical Scenarios: Protecting What Matters Most Protect PII, financial data, and intellectual property: Financial institutions can block prompts containing deal terms, account numbers, or other sensitive data, preventing leaks through AI interactions. Similarly, healthcare organizations can safeguard patient information, and manufacturers can secure intellectual property and trade secrets from exposure, along with many other practical use cases. Once the prompt is detected and blocked, Microsoft Graph grounding and Bing web grounding is restricted. Safeguard sensitive non-public information: Imagine an organization involved in a confidential merger. By using DLP for Copilot prompts, administrators can set up a custom SIT that includes the project’s code name. If a user asks Copilot about the merger using the project’s code name, their request will be blocked, keeping sensitive information secure and protected. Visibility into DLP for M365 Copilot Prompts When a user’s prompt triggers a DLP policy, notifications and alerts are surfaced directly in the Microsoft Purview and Defender portals for security administrators. These alerts provide detailed information about which policy was activated, the type of sensitive information detected, and the context of the attempted Copilot interaction. Using these alert queues in Purview and Defender XDR, administrators can efficiently track policy activity, investigate potential incidents, and refine DLP rules to better align with organizational needs. The ability to review historical alerts and track ongoing enforcement empowers admins to maintain strong data security and proactively safeguard sensitive information. Defender XDR portal investigation of prompt DLP based incident. Takeaways The introduction of this latest enhancement to DLP for Copilot represents a key advancement in secure Copilot deployment and adoption. By empowering organizations to block sensitive data at the prompt level, Microsoft is helping customers unlock the full potential of Copilot, without compromising security or compliance. This innovation reflects Microsoft’s commitment to responsible AI, continuous improvement, and customer-driven development. As Copilot evolves, so will the tools to protect your data, ensuring that productivity and security go hand in hand. For more details, stay tuned for updates to the Product Roadmap and Learn documentation. Learn about using DLP to protect interactions with Microsoft 365 Copilot and Copilot Chat Learn about the default DLP policy for Microsoft 365 Copilot location | Microsoft Learn Permissions to create or edit a DLP policy to safeguard Microsoft 365 Copilot and Copilot Chat Learn about the new Microsoft Purview Data Security Posture Management (DSPM) | Microsoft Learn Roadmap Item: DLP for Microsoft 365 Copilot to safeguard prompts Roadmap Item: DLP to safeguard web search in Microsoft 365 CopilotSwitching Data Loss Prevention Client-Side Checks for OWA
Purview Data Loss Prevention (DLP) rule checks can happen client-side and server-side. This change updates the Exchange Online organization configuration to instruct OWA to stop using Exchange Online to detect potential DLP rule violations before users send email. Instead, OWA will use the workload-neutral Data Classification Services (DCS). Using a workload-neutral service comes with some consequences in terms of OWA being unable to evaluate Exchange-specific predicates. https://office365itpros.com/2026/05/22/data-loss-prevention-dcs/Security Dashboard for AI: 3 Ways CISOs Drive Impact Today
AI is reshaping the enterprise and, with it, the threat landscape. Today's organizations face new threats with AI agents that modify configurations, execute workflows, and access data without direct human oversight. As a result, the gap between AI adoption and AI governance is widening, and CISOs face growing challenges to maintain visibility, control, and compliance across an increasingly complex ecosystem. As AI becomes embedded across the enterprise, CISOs face four key challenges: Scale without visibility: Over 75% of enterprises surveyed by PWC report they are already adopting AI agents. ¹ At the same time, over 80% of security teams surveyed by Nokod report visibility gaps into the applications and AI agents created within their organization. ² Rapid AI proliferation and evolving regulations make unified visibility across AI platforms, apps, and agents critical for CISOs. Fragmentation: Organizations rely on multiple siloed tools for AI asset visibility, making oversight fragmented and inefficient. According to Gartner’s 2024 survey of 162 enterprises, organizations use 45 cybersecurity tools on average. Expanding AI risk: AI proliferation is rapidly increasing the attack and risk surface, with the surge of AI-generated identities. By 2027, 4 out of 5 organizations will face phishing attacks powered by AI-generated synthetic identities, according to IDC. ³ This makes it harder for CISOs to track emerging threats, unmanaged assets, and shifting risk patterns. Overload: Alert fatigue is now a top challenge, with organizations now receiving an average of 2,992 security alerts daily, yet 63% go unaddressed. ⁴ Increasing AI risk without a way to prioritize what matters most compounds pressure on CISOs. In conversations between Microsoft and CISOs, one common need emerged: a single place to view integrated AI risk across the enterprise. To address these growing challenges, we are excited to provide CISOs with the Security Dashboard for AI, which recently became generally available. This unified dashboard aggregates posture and real-time risk signals from Microsoft Defender, Entra, and Purview into one unified, executive-level view of AI posture, risk, and inventory across agents, apps, and platforms. The Security Dashboard for AI helps CISOs: Gain unified AI risk visibility: Discover AI agents and applications and continuously monitor posture across the environment Prioritize critical risks: Correlate signals across identity, data, and threat protection to surface the most urgent issues Drive risk mitigations: Investigate activity and take action to help reduce exposure across the AI ecosystem The dashboard is capable of aggregating and surfacing AI risks from across Microsoft Defender, Entra, Purview - including Microsoft 365 Copilot, Microsoft Copilot Studio agents, and Microsoft Foundry applications and agents as well as cross-platform AI risks with Microsoft network-based or SDK-enabled integrations, and MCP servers. This supports comprehensive visibility and control, regardless of where applications and agents are built. As you activate Microsoft Security for AI capabilities, you can gain richer visibility into different aspects of your AI risk posture. Figure 1: Security Dashboard for AI in browser Getting Started with the Security Dashboard for AI The Security Dashboard for AI is provided at no additional cost to customers already using Defender, Entra, and/or Purview to protect their AI innovation. Based on how early adopter CISOs are using the dashboard, here are three ways you can start leveraging the dashboard today. 1. Manage Daily AI Risk Beyond reporting, you must stay hands-on with AI risks, scanning for emerging issues, verifying asset governance, and delegating remediations. The Security Dashboard for AI consolidates daily operations into a single pane of glass, surfacing critical alerts, unmanaged assets, and emerging risks. Use the dashboard as a daily AI risk radar, enabling rapid triage and ensuring you focus on the most urgent threats. Scan and triage daily AI risk: Start each day by identifying and prioritizing the highest-risk AI exposures. Risks are prioritized on severity reported by underlying security tools, helping you focus on the most critical exposures. Track AI asset inventory and monitor agent sprawl: Use the Inventory page to gain comprehensive visibility into all AI assets. Identify newly registered assets to mitigate the risk of shadow or unmanaged IT and surface inactive agents to proactively monitor and control agent sprawl. Delegate tasks for remediation: Move from insight to action by delegating tasks to your security team with easy click delegation. Delegation routes ownership via email or Microsoft Teams with notifications, due date, and ownership tracking. Delegate actions to specific roles such as global admin and AI administrator, without granting full access to underlying tools. Figure 2: Security Dashboard for AI risk page 2. Guide Briefings with Security Teams You require up-to-date intelligence to guide conversations with Security Teams about what is happening across the AI estate. The Security Dashboard for AI helps you anchor discussions in specific risks, trends, and ownership gaps surfaced in the data. The dashboard becomes a conversation driver, helping you ask the right questions about risk and security posture, to help ensure you and your team are triaging the right priorities. Because the dashboard consolidates signals from Defender, Entra, and Purview, both CISO and security teams operate from the same facts, enabling more outcome-driven discussions and faster prioritization, so you can shift the conversations from status updates to targeted action planning. Prioritize top AI Risk: Use the dashboard to help you prioritize the AI risk that matters the most. In preparation for team meetings, use Microsoft Security Copilot to explore AI risks, agent activity, and security recommendations via prompts to strengthen your AI security posture. With your team, take a closer look at risk vectors like data leakage, oversharing and unethical behavior, and discuss what actions need to be taken. Review Security Recommendations: Create a routine with your security team to review the recommended Microsoft security actions and track your progress over time. Across regular team check‑ins, review what has been addressed, what remains open, and which actions require follow‑up so you are prepared to respond to regulatory, audit, or executive questions with up‑to‑date metrics. Figure 3: Security Dashboard for AI inventory page Figure 4: Security Dashboard for AI delegation 3. Executive Reporting Reporting to the board on AI security posture has historically meant weeks of manual data gathering across multiple tools. The Security Dashboard for AI streamlines the data collection process with a single source of truth for AI risk, enabling confident, data-backed insights for your board presentations and conversations. Early adopters confirm the value and are using it for quarterly executive briefings. Prepare for Board Discussions: Use the dashboard to help get the right insights at the right altitude to help you prepare for discussions with your board. The Overview page aggregates identity, data security, and threat protection signals from Defender, Entra, and Purview into an AI risk scorecard with risk factors. The embedded Security Copilot AI-powered insights provide suggested prompts with risk assessments, summaries, and recommendations to help you prioritize what matters most. Extend Observability to Executive Stakeholders: Authorize AI risk follow‑ups to the appropriate security, identity, or governance owners using Microsoft Teams or email. Distribute visibility across GRC lead, AI governance, and IT leaders, while maintaining executive‑level oversight. Figure 5: Security Dashboard for AI Copilot prompt gallery Next Steps The Security Dashboard for AI helps CISOs manage AI risk faster, more confidently and more collaboratively with their team. Defender, Entra, and Purview signals are surfaced in a single pane of glass, providing observability across your AI estate. Drive faster triage, use data to support board-level discussions about AI risk, and enable coordinated action with integrated insights, recommendations, and delegation to help accelerate remediation across existing security workflows. The Security Dashboard for AI is generally available now. If your organization uses Microsoft Defender, Entra, and/or Purview, you already have access, no additional licensing is required. Visit ai.security.microsoft.com to access the dashboard directly, or navigate to it from the Defender, Entra, or Purview portals. Learn more about the Security Dashboard for AI on the MS Learn page and the Security Dashboard for AI Security Blog. Discover new features in the Security Dashboard for AI such as the Security Reader role, new delegation flow, and new identity risk section here. ¹AI agent survey. PwC, May 2025 ²Security Teams Taking on Expanded AI Data Responsibilities. Bedrock Data, March 2025 ³IDC FutureScape: Worldwide Security and Trust 2026 Predictions, November 2025 ⁴2026 State of Threat Detection and Response Report. Vectra AI, February 2026Security Dashboard for AI - Now Generally Available
AI proliferation in the enterprise, combined with the emergence of AI governance committees and evolving AI regulations, leaves CISOs and AI risk leaders needing a clear view of their AI risks, such as data leaks, model vulnerabilities, misconfigurations, and unethical agent actions across their entire AI estate, spanning AI platforms, apps, and agents. 53% of security professionals say their current AI risk management needs improvement, presenting an opportunity to better identify, assess and manage risk effectively. 1 At the same time, 86% of leaders prefer integrated platforms over fragmented tools, citing better visibility, fewer alerts and improved efficiency. 2 To address these needs, we are excited to announce the Security Dashboard for AI, previously announced at Microsoft Ignite, is now generally available. This unified dashboard aggregates posture and real-time risk signals from Microsoft Defender, Microsoft Entra, and Microsoft Purview - enabling users to see left-to-right across purpose-built security tools from within a single pane of glass. The dashboard equips CISOs and AI risk leaders with a governance tool to discover agents and AI apps, track AI posture and drift, and correlate risk signals to investigate and act across their entire AI ecosystem. Security teams can continue using the tools they trust while empowering security leaders to govern and collaborate effectively. Gain Unified AI Risk Visibility Consolidating risk signals from across purpose-built tools can simplify AI asset visibility and oversight, increase security teams’ efficiency, and reduce the opportunity for human error. The Security Dashboard for AI provides leaders with unified AI risk visibility by aggregating security, identity, and data risk across Defender, Entra, Purview into a single interactive dashboard experience. The Overview tab of the dashboard provides users with an AI risk scorecard, providing immediate visibility to where there may be risks for security teams to address. It also assesses an organization's implementation of Microsoft security for AI capabilities and provides recommendations for improving AI security posture. The dashboard also features an AI inventory with comprehensive views to support AI assets discovery, risk assessments, and remediation actions for broad coverage of AI agents, models, MCP servers, and applications. The dashboard provides coverage for all Microsoft AI solutions supported by Entra, Defender and Purview—including Microsoft 365 Copilot, Microsoft Copilot Studio agents, and Microsoft Foundry applications and agents—as well as third-party AI models, applications, and agents, such as Google Gemini, OpenAI ChatGPT, and MCP servers. This supports comprehensive visibility and control, regardless of where applications and agents are built. Prioritize Critical Risk with Security Copilots AI-Powered Insights Risk leaders must do more than just recognize existing risks—they also need to determine which ones pose the greatest threat to their business. The dashboard provides a consolidated view of AI-related security risks and leverages Security Copilot’s AI-powered insights to help find the most critical risks within an environment. For example, Security Copilot natural language interaction improves agent discovery and categorization, helping leaders identify unmanaged and shadow AI agents to enhance security posture. Furthermore, Security Copilot allows leaders to investigate AI risks and agent activities through prompt-based exploration, putting them in the driver’s seat for additional risk investigation. Drive Risk Mitigation By streamlining risk mitigation recommendations and automated task delegation, organizations can significantly improve the efficiency of their AI risk management processes. This approach can reduce the potential hidden AI risk and accelerate compliance efforts, helping to ensure that risk mitigation is timely and accurate. To address this, the Security Dashboard for AI evaluates how organizations put Microsoft’s AI security features into practice and offers tailored suggestions to strengthen AI security posture. It leverages Microsoft’s productivity tools for immediate action within the practitioner portal, making it easy for administrators to delegate recommendation tasks to designated users. With the Security Dashboard for AI, CISOs and risk leaders gain a clear, consolidated view of AI risks across agents, apps, and platforms—eliminating fragmented visibility, disconnected posture insights, and governance gaps as AI adoption scales. Best of all, the Security Dashboard for AI is included with eligible Microsoft security products customers already use. If an organization is already using Microsoft security products to secure AI, they are already a Security Dashboard for AI customer. Getting Started Existing Microsoft Security customers can start using Security Dashboard for AI today. It is included when a customer has the Microsoft Security products—Defender, Entra and Purview—with no additional licensing required. To begin using the Security Dashboard for AI, visit http://ai.security.microsoft.com or access the dashboard from the Defender, Entra or Purview portals. Learn more about the Security Dashboard for AI at Microsoft Security MS Learn. 1AuditBoard & Ascend2 Research. The Connected Risk Report: Uniting Teams and Insights to Drive Organizational Resilience. AuditBoard, October 2024. 2Microsoft. 2026 Data Security Index: Unifying Data Protection and AI Innovation. Microsoft Security, 2026
Best practices for safely performing schema changes in Azure Database for MySQL
Azure Database for MySQL - Flexible Server is built on the open-source MySQL database engine, and the service supports MySQL 8.0 and newer versions. This means that users can take advantage of the flexibility and advanced capabilities of MySQL’s latest features while benefitting from a fully managed database service. While newer versions and features can provide a lot of value, the recent issues identified with MySQL versions 8.0+ makes it important to be aware of potential risks that can occur during certain operations, particularly if you are making online schema changes. Issues with data loss and duplicate keys with Online DDL Online Data Definition Language (DDL) operations are a powerful feature in MySQL, enabling schema changes like ALTER TABLE or OPTIMIZE TABLE with minimal impact on table availability. These operations are designed to reduce downtime by allowing concurrent reads and writes during schema modifications, making them an essential tool for managing active databases efficiently. However, a recent post on the Percona blog, Who Ate My MySQL Table Rows? highlights critical risks associated with MySQL 8.0.x versions after 8.0.27 and all versions beyond 8.4.y. Specifically, the open-source INPLACE algorithm, commonly used for online schema changes, can lead to data loss and duplicate key errors under certain conditions. These issues arise from constraints in the INPLACE algorithm, particularly during ALTER TABLE and OPTIMIZE TABLE operations, exposing vulnerabilities that compromise data integrity and system reliability. These risks are called out in the following bug reports: Bug #115511: Data loss during online ALTER operations with concurrent DML Bug #115608: Duplicate key errors caused by online ALTER operations Documented issues related to the INPLACE algorithm (used for online DDL) can cause: Data Loss: Rows may be accidentally deleted or become inaccessible. Duplicate Keys: Indexes can end up with duplicate entries, leading to data consistency issues and potential replication errors. Problems arise when INPLACE operations, such as ALTER TABLE or OPTIMIZE TABLE, run concurrently with: DML operations (INSERT, UPDATE, DELETE): Modifications to table data during the rebuild. A purge activity: Background cleanup operations for old row versions in InnoDB. These scenarios can lead to anomalies resulting from race conditions and incomplete synchronization between concurrent activities. Impact on Azure Database for MySQL - Flexible Server Customers For Azure Database for MySQL Flexible Server customers using MySQL 8.0+ and all versions after 8.4.y, this issue is particularly critical as it affects: Data Integrity: During schema changes such as ALTER TABLE or OPTIMIZE TABLE run using the INPLACE algorithm, data rows may be lost or duplicated if these operations run concurrently with a DML activity (e.g., INSERT, UPDATE, or DELETE) or background purge tasks. This can compromise the accuracy and reliability of the database, potentially leading to incorrect query results or the loss of critical business data. Replication Instability: Duplicate keys or missing rows can interrupt replication processes, which rely on a consistent data stream across the primary and replica servers. These issues can arise when there are concurrent insertions into the table during schema changes, leading to data inconsistencies between the primary and replicas. Such inconsistencies may result in replication lag, errors, or even a complete breakdown of high-availability setups, requiring manual intervention to restore synchronization. Operational Downtime: Resolving these issues often involves manually syncing data or restoring backups. These recovery efforts can be time-consuming and disruptive, leading to extended downtime for applications and potential business impact. Recommendations for safe schema changes on Azure Database for MySQL flexible servers To minimize the risks of data loss and duplicate keys while making schema changes, follow these best practices: Set old_alter_table=ON to Default to COPY Algorithm Enable the server parameter old_alter_table system variable so that ALTER TABLE operations without a specified ALGORITHM default to using the COPY algorithm instead of INPLACE. This reduces the risk for users who do not explicitly specify the ALGORITHM in their commands. Learn more on how configure server parameters in Azure Database for MySQL. Avoid using ALGORITHM=INPLACE Do not explicitly use ALGORITHM=INPLACE for ALTER TABLE commands, as it increases the risk of data loss or duplicate keys. Back up your data before schema changes Always perform a full on-demand backup of your server before executing schema changes. This precaution ensures data recoverability in case of unexpected issues. Learn more on how to take full on-demand backups for your server. Avoid Concurrent DML during schema changes Schedule schema changes like ALTER TABLE and OPTIMIZE TABLE during application maintenance windows when no concurrent writes activities occur. This minimizes race conditions and synchronization conflicts. Use External Tools for Safer Online Schema Changes Consider using external tools like pt-online-schema-change to modify table definitions without blocking concurrent changes. These tools enable you to make schema changes with minimal impact on availability and performance. Learn more about pt-online-schema-change. Disclaimer: The pt-online-schema-change tool is not managed or supported by Microsoft; use it at your discretion. Mitigation plans To address these risks, we’re actively working to integrate the necessary fixes to ensure a more robust and reliable experience for our customers. New Servers Fully Secured by End of February 2025 All new Azure Database for MySQL Flexible Server instances created after 1 st March 2025, will include the latest fixes, ensuring that schema changes are safeguarded against data loss and duplicate key risks. Rollout for Existing Servers For existing servers, we will roll out patches during upcoming maintenance windows by end of Q1 of Calendar Year 2025 We recommend monitoring your Azure portal for scheduled maintenance windows and Release notes for announcements about critical updates and patches. Priority updates available upon request If you require an urgent update outside of the scheduled maintenance windows, you can contact Azure Support. Provide the necessary server details and an appropriate maintenance window, and our team will work with you to prioritize the patching process. Note that priority patching will be available by February 2025. We recommend monitoring Release notes for announcements about critical updates and patches. Conclusion Safely managing schema changes on MySQL servers requires understanding the risks associated with online DDL operations, such as potential data loss and duplicate keys. To help safeguard data integrity and maintain server stability, implement best practices, for example enabling the COPY algorithm, using offline operations if feasible, or scheduling changes during low activity periods. Fixes are expected by the end of February 2025, and new Azure Database for MySQL flexible servers will be fully protected against these bugs. We will apply updates to existing servers during maintenance windows in Q1 2025. Following the recommendations above will help ensure that you can confidently make schema changes while preserving the reliability and performance of your server.
Activity explorer scoping to AU
I remember that Activity Explorer can be fully scoped to Admin Units, and that the Restricted admin can see activity explorer and DLP matching events for the scoped AU only, is that correct? Cause I was checking and I found the Restricted admin can see the activities also for the users out of the scoped AU. Does that make sense?Registration Open: Community-Led Purview Lightning Talks
Get ready for an electrifying event! The Microsoft Security Community proudly presents Purview Lightning Talks; an action-packed series featuring your fellow Microsoft users, partners and passionate Microsoft Security community members of all sorts. Each 3-12 minute talk cuts straight to the chase, delivering expert insights, real-world use cases, and even a few game-changing tips and tricks. Don’t miss this opportunity to learn, connect, and be inspired! Secure your spot now for the big day: April 30th at 8am Redmond Time. See agenda details below and follow this blog post (sign in and click the "follow" heart in the upper right) to receive notifications. ❗UPDATE❗This event is expected to last around 2 hours and 15 minutes, due to the incredible number of community sessions that were submitted! 💖 Please see the timing table below broken out into sections of four talks each, and plan to arrive 10 minutes before the section that interests you, OR stay for the whole time! Speakers will be available in the chat to answer your questions; please ask your questions during their session. Spillover Q&A forum links will also be shared. The full session recording will be indexed and posted to Microsoft Security Community YouTube within 24 hours after the event. Bookmark this page or follow this blog post for updates! Agenda Legend ↩️ Data Lifecycle Management 🔐 Information Protection 🚫 Data Loss Prevention (DLP) 🦾 Data Security Posture Management (DSPM) for AI 🤖 Purview for AI 👁️ Insider Risk Management (IRM) 🔍 eDiscovery 📊 Governance 🗒️ Compliance Manager 🛡️ Data Security All times are listed in US Pacific/Redmond Time. Session lengths are rounded to the nearest minute. AGENDA Section 1 - approximately 8:00 am - 8:43 am ↩️ The Day Offboarding Exposed Infinite Retention — Nikki Chapple Length: 10 minutes | Topic: Data Lifecycle Management A routine Purview request led to an unexpected discovery: more than 9,000 orphaned OneDrives and thousands of inactive mailboxes still storing content long after employees had left. This talk explains how a retain-only policy created hidden retention debt and how Adaptive Scopes can help organisations separate active users from leavers to avoid similar pitfalls. 🔐 The Purview Label Engine: Automated Classification, Translation, and co-Documentation for Enterprise Tenants — Michael Kirst-Neshva Length: 12 minutes | Topic: Information Protection Global enterprises face the challenge of implementing uniform data protection standards across borders and languages. In this talk, I’ll present a framework that makes Microsoft Purview labels truly scalable. Discover how to roll out parent and child label logics automatically, manage priorities with a single click, and generate instant compliance documentation for every business unit. 🗒️ What's In My Compliance Manager Toolbox: A Cloud Security Architect's Perspective — Jerrad Dahlager Length: 8 minutes | Topic: Compliance Manager A practical walkthrough of how I use Compliance Manager across real client engagements to map controls, track improvement actions, and simplify multi-framework compliance. No theory, just what works in the field. 🛡️ Stop, Think, Protect: Data Security in Real Life with Purview — Oliver Sahlmann Length: 8 minutes | Topic: Data Security With simple labels and matching DLP policies, Purview offers a practical and accessible way to approach data security. This lightning talk uses a real-life traffic light concept to show how a low barrier to adoption can still drive meaningful protection and awareness. Section 2 - approximately 8:44 am - 9:15 am 🔐 Using Purview to prevent oversharing with AI services — Viktor Hedberg Length: 10 minutes | Topic: Information Protection In this day and age, AI is the big thing. However, Copilot has access to everything you can access, including potentially sensitive data. In this session we will look at how to prevent Copilot to access highly sensitive data, using Information Protection. 🦾 How I Helped My Customers Understand their AI Usage (and protect their sensitive data) — Bram de Jager Length: 5 minutes | Topic: Data Security Posture Management (DSPM) for AI As AI tools explode across the web, many organizations still have no idea what’s actually happening in the browser—where employees type prompts, paste sensitive data, or visit public AI sites outside corporate governance. In this lightning talk, I’ll share how I helped customers shine a light on this issue. We’ll explore how Purview Data Security Posture Management (DSPM) can reveal which AI tools employees use, what types of data they input, and where sensitive information may leak through prompts. I’ll walk through real customer scenario where we detected risky AI usage patterns—such as employees pasting confidential documents into public chatbots. 🔐 Four Labels Max for Daily Use: Which Ones & Why? — Romain Dalle Length: 8 minutes | Topic: Information Protection Sensitivity labels are one of the most critical parts of a Purview Risk and compliance deployment, if not the most critical, because it directly impacts how end-users and business units should allow or restrict themselves to share their business data, internally and externally, on a daily basis. Labels have not other options than being precise, meaningful, and balanced in terms of embedded data security. Setting the right taxonomy is core to success, and is everything but a one-time project. 🚫 Data-driven Endpoint DLP Solution with Advanced Hunting — Tatu Seppälä Length: 8 minutes | Topic: Data Loss Prevention (DLP) This lightning talk shows you how to use KQL queries in advanced hunting to easily build initial sensitive service domain groups for authorized and unauthorized domains based on your organization's usage patterns. The same approach can be used for numerous other similar solution refinement and design purposes. Section 3 - approximately 9:16 am - 9:46 am 🔐 The Purview Hack No One Talks About: Container Sensitivity Labels That Fix Oversharing Fast — Nikki Chapple Length: 10 minutes | Topic: Information Protection Most organizations tackle oversharing with manual fixes, but the fastest solution is often overlooked. In this lightning talk, I show how container sensitivity labels automatically apply the right sharing and collaboration controls, ensuring every new Group, Team or SharePoint site starts secure by default. 🔍 Does M365 Support eDiscovery? — Julian Kusenberg Length: 11 minutes | Topic: eDiscovery A myth-busting session that separates perception from reality when it comes to Microsoft 365 eDiscovery capabilities. 📊 Improving Discovery, Trust, and Reuse of Analytics with Purview Data Products — Craig Wyndowe Length: 5 minutes | Topic: Governance This talk shows how bringing Power BI and Fabric assets into Microsoft Purview Governance Domains and Data Products creates a single, trusted view of enterprise analytics. By connecting reports, semantic models, and underlying data with shared metadata, ownership, and business context, organizations can make existing assets easy to discover and safe to reuse. 🔐 Why You Should Create Your Own Sensitive Information Types (SITs) — Niels Jakobsen Length: 5 minutes | Topic: Information Protection An in depth analysis of why Microsoft SITs are not one-size-fits-all, and how to create your own using what Microsoft has already built for you. Section 4 - approximately 9:47 am-10:30 am 👁️ From Zero to First Signal: Insider Risk Management Prerequisites That Actually Matter — Sathish Veerapandian Length: 8 minutes | Topic: Insider Risk Management (IRM) A focused live demo showing the real world prerequisites required for Microsoft Purview Insider Risk Management to work effectively. This session highlights the critical Entra ID, Intune, Microsoft Defender for Endpoint, and Purview DLP configurations that must be in place before creating IRM policies. 🤖 Securing data in the age of AI — Júlio César Gonçalves Vasconcelos Length: 11 minutes | Topic: Purview for AI AI will transform business as we know it; but without proper governance, it can introduce serious risks. We’ll show you how Microsoft Purview enables organizations to accelerate AI adoption while maintaining security, compliance, and transparency. 🔍 Beyond eDiscovery - Purview DSI for Security Investigation — Susantha Silva Length: 11 minutes | Topic: eDiscovery Most people hear “Microsoft Purview” and immediately think compliance, eDiscovery, or legal holds. But this session highlights Data Security Investigations, showing how DSI lets you take a DLP alert or insider risk signal and turn it into a structured investigation. 🚫 Elevating Purview DLP with a real world use case — Victor Wingsing Length: 14 minutes | Topic: Data Loss Prevention (DLP) Learn how I hardened Microsoft Purview DLP beyond out of the box defaults—closing real world data loss gaps, tuning policies to actual user behavior, and turning noisy alerts into protection that really blocks exfiltration. - Quick Closing/ Resource Sharing
