Defender for Storage: Malware Automated Remediation - From Security to Protection
In our previous Defender for Cloud Storage Security blog, we likened cloud storage to a high-tech museum - housing your organization’s most valuable artifacts, from sensitive data to AI training sets. That metaphor resonated with many readers, highlighting the need for strong defenses and constant vigilance. But as every museum curator knows, security is never static. New threats emerge, and the tools we use to protect our treasures must evolve. Today, we are excited to share the next chapter in our journey: the introduction of malware automated remediation as part of our Defender for Cloud Storage Security solution (Microsoft Defender for Storage). This feature marks a pivotal shift - from simply detecting threats to actively preventing their spread, ensuring your “museum” remains not just secure, but truly protected. The Shift: From Storage Security to Storage Protection Cloud storage has become the engine room of digital transformation. It powers collaboration, fuels AI innovation, and stores the lifeblood of modern business. But with this centrality comes risk: attackers are increasingly targeting storage accounts, often using file uploads as their entry point. Historically, our storage security strategy focused on detection - surfacing risks and alerting security teams to suspicious activity. This was like installing state-of-the-art cameras and alarms in our museum, but still relying on human guards to respond to every incident. With the launch of malware automated remediation, we’re taking the next step: empowering Defender for Storage to act instantly, blocking malicious files before they can move through your environment. We are elevating our storage security solution from detection-only to a detection and response solution, which includes both malware detection and distribution prevention. Why Automated Remediation Matters Detection alone is no longer enough. Security teams are overwhelmed by alerts, and manual/custom developed response pipelines are slow and error-prone. In today’s threat landscape, speed is everything - a single malicious file can propagate rapidly, causing widespread damage before anyone has a chance to react. Automated remediation bridges this gap. When a file is uploaded to your storage account, or if on-demand scanning is initiated, Defender for Storage now not only detects malicious files and alerts security teams, but it can automatically (soft) delete the file (allowing file recovery) or trigger automated workflows for further investigation. This built-in automation closes the gap between detection and mitigation, reducing manual effort and helping organizations meet compliance and hygiene requirements. How It Works: From Detection to Protection The new automated remediation feature is designed for simplicity and effectiveness: Enablement: Customers can enable automated remediation at the storage account or subscription level, either through the Azure Portal or via API. Soft Delete: When a malicious blob is detected, Defender for Storage checks if the soft delete property is enabled. If not, it enables it with a default retention of 7 days (adjustable between 1 and 365 days). Action: The malicious file is soft-deleted, and a security alert is generated. If deletion fails (e.g., due to permissions or configuration), the alert specifies the reason, so you can quickly remediate. Restoration: If a file was deleted in error, it can be restored from soft delete The feature is opt-in, giving you control over your remediation strategy. And because it’s built into Defender for Storage, there’s no need for complex custom pipelines or third-party integrations. For added flexibility, soft delete works seamlessly with your existing retention policies, ensuring compliance with your organization’s data governance requirements. Additionally, all malware remediation alerts are fully integrated into the Defender XDR portal, so your security teams can investigate and respond using the same unified experience as the rest of your Microsoft security stack. Use Case: Preventing Malware from Spreading Through File Uploads Let’s revisit a scenario that’s become all too common: a customer-facing portal allows users to upload files and documents. Without robust protection, a single weaponized file can enter your environment and propagate - moving from storage to backend services, and potentially across your network. With Defender for Storage’s malware automated remediation: Malware is detected at the point of upload - before it can be accessed or processed Soft delete remediation action is triggered instantly, stopping the threat from spreading Security teams are notified and can review or restore files as needed This not only simplifies and protects your data pipeline but also strengthens compliance and trust. In industries like healthcare, finance, and customer service - where file uploads are common and data hygiene is critical - this feature is a game changer. Customer Impact and Feedback Early adopters have praised the simplicity and effectiveness of automated remediation. One customer shared that the feature “really simplified their future pipelines,” eliminating the need for custom quarantine workflows and reducing operational overhead. By moving from detection to protection, Defender for Storage helps organizations: Reduce the risk of malware spread and lateral movement Increase trust with customers and stakeholders Simplify solution management and improve user experience Meet compliance and data hygiene requirements with less manual effort Looking Ahead: The Future of Storage Protection Malware automated remediation is just the beginning. As we continue to evolve our storage security solution, our goal is to deliver holistic, built-in protection that keeps pace with the changing threat landscape. Whether you’re storing business-critical data or fueling innovation with AI, you can trust Defender for Cloud to help you start secure, stay secure, and keep your cloud storage truly safe. Ready to move from security to protection? Enable automated remediation in Defender for Storage today and experience the next generation of cloud storage defense. Learn more about Defender for Cloud storage security: Microsoft Defender for Cloud | Microsoft Security Start a free Azure trial. Read more about Microsoft Defender for Cloud Storage Security here.Automated Remediation for Malware Detection - Defender for Storage
Today, Defender for Storage released, in public preview for Commercial Cloud, the feature Automated Remediation for Malware Detection. This is for both On-upload and On-demand malware scanning. The full documentation can be found in this link. What does it do? Anytime that a blob is found malicious (malicious content was found in the blob), the Automated Remediation feature will kick in and soft-delete the blob. What do you mean by soft-delete? As soon as you enable Automated Remediation for Malware Detection, at the subscription level or storage account level, under “Data Management”, two settings will get automatically configured: Enable soft delete for blobs Keep deleted blobs for (in days): 7 days (if this was not configured. If you had a different retention period, we will not modify it) Enable soft delete for containers Keep deleted containers for (in days): 7 days (if this was not configured. If you had a different retention period, we will not modify it) This configuration will let you “undelete” or “recover” the deleted blobs. How do I enable it? There are two ways: sub-level and resource-level. Besides the User Interface options described in this blog, we have other sub-level and resource-level enablement options like REST API which are documented in this link. Subscription level Go to Microsoft Defender for Cloud Environment Settings Select the subscription Enable Defender for Storage (if not enabled already) Click Settings In Malware Scanning configuration, check the box Soft delete malicious blobs (preview) Save it Note: by default, enabling malware scanning will not automatically enable Automated Remediation for Malware Detection. Storage account level Select the storage account Under Security + networking, click on Microsoft Defender for Cloud If Defender for Storage is already enabled, click on Settings Under the On-upload malware scanning settings, mark the checkbox Soft delete malicious blobs (preview) Save it How does it look like? Note: If you turn on Versioning for Blobs on your storage account, see Manage and restore soft delete for blobs to learn how to restore a soft deleted blob. Try it out and let us know your feedback! 😊
Protecting Your Azure Key Vault: Why Azure RBAC Is Critical for Security
Introduction In today’s cloud-centric landscape, misconfigured access controls remain one of the most critical weaknesses in the cyber kill chain. When access policies are overly permissive, they create opportunities for adversaries to gain unauthorized access to sensitive secrets, keys, and certificates. These credentials can be leveraged for lateral movement, privilege escalation, and establishing persistent footholds across cloud environments. A compromised Azure Key Vault doesn’t just expose isolated assets it can act as a pivot point to breach broader Azure resources, potentially leading to widespread security incidents, data exfiltration, and regulatory compliance failures. Without granular permissioning and centralized access governance, organizations face elevated risks of supply chain compromise, ransomware propagation, and significant operational disruption. The Role of Azure Key Vault in Security Azure Key Vault plays a crucial role in securely storing and managing sensitive information, making it a prime target for attackers. Effective access control is essential to prevent unauthorized access, maintain compliance, and ensure operational efficiency. Historically, Azure Key Vault used Access Policies for managing permissions. However, Azure Role-Based Access Control (RBAC) has emerged as the recommended and more secure approach. RBAC provides granular permissions, centralized management, and improved security, significantly reducing risks associated with misconfigurations and privilege misuse. In this blog, we’ll highlight the security risks of a misconfigured key vault, explain why RBAC is superior to legacy Access Policies and provide RBAC best practices, and how to migrate from access policies to RBAC. Security Risks of Misconfigured Azure Key Vault Access Overexposed Key Vaults create significant security vulnerabilities, including: Unauthorized access to API tokens, database credentials, and encryption keys. Compromise of dependent Azure services such as Virtual Machines, App Services, Storage Accounts, and Azure SQL databases. Privilege escalation via managed identity tokens, enabling further attacks within your environment. Indirect permission inheritance through Azure AD (AAD) group memberships, making it harder to track and control access. Nested AAD group access, which increases the risk of unintended privilege propagation and complicates auditing and governance. Consider this real-world example of the risks posed by overly permissive access policies: A global fintech company suffered a severe breach due to an overly permissive Key Vault configuration, including public network access and excessive permissions via legacy access policies. Attackers accessed sensitive Azure SQL databases, achieved lateral movement across resources, and escalated privileges using embedded tokens. The critical lesson: protect Key Vaults using strict RBAC permissions, network restrictions, and continuous security monitoring. Why Azure RBAC is Superior to Legacy Access Policies Azure RBAC enables centralized, scalable, and auditable access management. It integrates with Microsoft Entra, supports hierarchical role assignments, and works seamlessly with advanced security controls like Conditional Access and Defender for Cloud. Access Policies, on the other hand, were designed for simpler, resource-specific use cases and lack the flexibility and control required for modern cloud environments. For a deeper comparison, see Azure RBAC vs. access policies. Best Practices for Implementing Azure RBAC with Azure Key Vault To effectively secure your Key Vault, follow these RBAC best practices: Use Managed Identities: Eliminate secrets by authenticating applications through Microsoft Entra. Enforce Least Privilege: Precisely control permissions, granting each user or application only minimal required access. Centralize and Scale Role Management: Assign roles at subscription or resource group levels to reduce complexity and improve manageability. Leverage Privileged Identity Management (PIM): Implement just-in-time, temporary access for high-privilege roles. Regularly Audit Permissions: Periodically review and prune RBAC role assignments. Detailed Microsoft Entra logging enhances auditability and simplifies compliance reporting. Integrate Security Controls: Strengthen RBAC by integrating with Microsoft Entra Conditional Access, Defender for Cloud, and Azure Policy. For more on the Azure RBAC features specific to AKV, see the Azure Key Vault RBAC Guide. For a comprehensive security checklist, see Secure your Azure Key Vault. Migrating from Access Policies to RBAC To transition your Key Vault from legacy access policies to RBAC, follow these steps: Prepare: Confirm you have the necessary administrative permissions and gather an inventory of applications and users accessing the vault. Conduct inventory: Document all current access policies, including the specific permissions granted to each identity. Assign RBAC Roles: Map each identity to an appropriate RBAC role (e.g., Reader, Contributor, Administrator) based on the principle of least privilege. Enable RBAC: Switch the Key Vault to the RBAC authorization model. Validate: Test all application and user access paths to ensure nothing is inadvertently broken. Monitor: Implement monitoring and alerting to detect and respond to access issues or misconfigurations. For detailed, step-by-step instructions—including examples in CLI and PowerShell—see Migrate from access policies to RBAC. Conclusion Now is the time to modernize access control strategies. Adopting Role-Based Access Control (RBAC) not only eliminates configuration drift and overly broad permissions but also enhances operational efficiency and strengthens your defense against evolving threat landscapes. Transitioning to RBAC is a proactive step toward building a resilient and future-ready security framework for your Azure environment. Overexposed Azure Key Vaults aren’t just isolated risks — they act as breach multipliers. Treat them as Tier-0 assets, on par with domain controllers and enterprise credential stores. Protecting them requires the same level of rigor and strategic prioritization. By enforcing network segmentation, applying least-privilege access through RBAC, and integrating continuous monitoring, organizations can dramatically reduce the blast radius of a potential compromise and ensure stronger containment in the face of advanced threats. Want to learn more? Explore Microsoft's RBAC Documentation for additional details.Exposing hidden threats across the AI development lifecycle in the cloud
Introduction: The AI Lifecycle in the Cloud and Its Risks As organizations increasingly adopt AI to drive innovation, the development and deployment of AI models, applications and agents is now taking place in the cloud more than ever before. Leading cloud platforms make it easier than ever to build, train, and deploy AI systems at scale - offering powerful compute, seamless integrations, and collaborative tools. However, this shift also introduces new security challenges at every stage of the development lifecycle. Whether you're training an AI model or deploying an AI application or agent, the AI development lifecycle in the cloud includes multiple stages, including data collection, model training, Fine-tuning pipelines, and the deployment of AI applications and agents. If attackers compromise even one part of this lifecycle, it can put the entire AI system and the business operations it supports at risk. What adds to the complexity of this landscape is the rapid evolution of cloud-based AI platforms. New features are released at a fast pace, often outpacing the maturity of existing security controls - leaving gaps that attackers can exploit. This blog will examine the risks associated with each phase of the AI development lifecycle in the cloud – whether it’s models, applications, or agents. We’ll explore how attackers can abuse them, and how Microsoft Defender for Cloud helps organizations reduce AI posture risks with AI Posture management across their multi cloud environment. Understanding the Threat Landscape Across the AI Lifecycle Whether it’s poisoning training data, stealing proprietary models, or hijacking deployed AI systems to manipulate outputs, securing the cloud-based AI development lifecycle requires a comprehensive understanding of the risks associated with every phase. Let’s explore how attackers can target various stages of the AI development lifecycle and the specific consequences of those compromises. Data and training It all begins with data, which is often the most valuable and the most vulnerable asset. Whether it's customer records, transaction logs, emails, or images, this data is used to train models that will eventually make decisions on behalf of the organization. In cloud AI environments, such data is typically stored in cloud storage. If attackers gain access to such storage account with training data, due to misconfigured storage or overly permissive cloud account permissions, the consequences can be severe. For instance, they might inject poisoned or manipulated data into the training set, subtly altering the behavior of the model. In one scenario, they could bias a credit scoring model to approve fraudulent applications. In another, they could insert a hidden backdoor - causing the model to behave normally most of the time but output incorrect or malicious predictions when triggered by a specific input. Once the data is prepared, it flows into the training pipeline: a critical but often overlooked attack surface. This pipeline automates the full training workflow: ingesting data, executing transformation scripts, spinning up GPU-powered training jobs, and saving the resulting model. If attackers infiltrate this pipeline, they can gain persistent control over the AI system. For example, they could modify preprocessing scripts to inject subtle distortions into the data, or they might replace a model artifact with a manipulated one that appears legitimate but behaves maliciously under specific conditions. Since pipelines often run with elevated permissions and can access cloud storage, compute resources, and secrets, they also become convenient pivot points for lateral movement across cloud infrastructure. Model Artifacts & Registries Once trained, models in the cloud are typically stored in model registries or artifact repositories. These are often considered secure because they’re not directly exposed to users. However, they represent a high-value target. Attackers who gain access to stored models can steal intellectual property, especially if the model architecture or parameters represent years of R&D. In addition to theft, an attacker might attempt to delete critical models to disrupt business and operations. Even more concerning, they could upload a malicious model in place of a legitimate one. Such a model could be designed to behave subtly but incorrectly, introduce biases, leak data during inference, or provide manipulated outputs that mislead downstream systems and users. This type of tampering not only undermines trust in AI systems but can also have serious operational and security consequences. Model Fine-tuning In addition to full model training, many organizations rely on fine-tuning: a process where a pre-trained foundation model is adapted using domain-specific data. Fine-tuning offers a faster and more cost-effective path to building specialized models, but it also introduces new attack vectors. The fine-tuning inherits all the risks of traditional training, plus a few more. For instance, attackers can target fine-tuning jobs or the associated fine-tuning files (e.g., in storage buckets) to manipulate the behavior of a pre-trained model without raising suspicion. By injecting poisoned fine-tuning data, they can create task-specific vulnerabilities, such as altering outputs related to a particular customer or product. The risk is especially high because fine-tuned models are often deployed directly into production environments. This means attackers don’t need to compromise the full model training workflow to achieve impact - they can introduce malicious behavior just by manipulating a smaller, faster process with fewer controls. Given this, securing fine-tuning pipelines and datasets is just as critical as protecting full-scale training jobs. Models Inference & Endpoints After deployment, models are exposed to the outside world through inference endpoints, typically REST APIs that receive input data and return predictions, decisions, text, or other outputs. The main risk at this stage is unbounded consumption. This occurs when attackers or even legitimate users are able to perform excessive, uncontrolled requests, especially with resource-intensive models like Large Language Models (LLMs). Such abuse can lead to denial of service (DoS), inflated operational costs, and overall service degradation. In cloud environments, where resource usage drives cost and performance, this kind of exploitation can have serious financial and operational impacts. In addition to consumption-based abuse, attackers with access to a poorly secured endpoint may attempt destructive actions such as deleting the endpoint to disrupt availability and business operations, or deploying a different model to the endpoint, potentially replacing trusted outputs with manipulated or malicious ones. Securing inference endpoints is critical to maintaining the integrity, availability, and cost-effectiveness of AI services in the cloud. The rise of AI Agents and apps AI agents, autonomous LLM-driven systems that can search, retrieve, write code, execute workflows, and make decisions, are rapidly becoming a central component in modern AI systems. Unlike traditional models that simply return predictions or text, agents are designed to perform complex, goal-oriented tasks by autonomously chaining multiple actions, tools, and reasoning steps. They can interact with external systems, call APIs, query databases, invoke tools like code execution environments or vector stores, and even communicate with other agents. This growing autonomy and connectivity unlock powerful capabilities - but it also introduces a new and expanding attack surface. One of the biggest concerns with AI agents is the amplification of existing risks. Vulnerabilities like prompt injection, which might have limited impact in a basic chatbot, can become far more dangerous when exploited in an agent that has access to tools and can take real actions. A single malicious input could cause an agent to leak sensitive information, perform unintended operations, or invoke tools in harmful ways. In addition, attackers with access to the agent itself, whether though a compromised cloud account permissions or leaked API keys, can access the agent tools, change the agent’s behavior by manipulating its instructions, or deleting it to disrupt business. As the adoption of AI agents grows, it's critical for organizations to integrate security thinking into their design and deployment. This includes implementing strict controls on agent permissions, monitoring and logging agent behavior, hardening agent tools and APIs, and applying layered protections against manipulation and misuse. Models’ and Agents dependencies Cloud-based AI systems increasingly rely on external data sources and tools to perform complex tasks accurately. For example, retrieval-augmented generation (RAG) models depend on grounding data from document stores or vector databases to generate up-to-date, context-aware responses. Similarly, AI agents may be configured to interact with APIs, databases, cloud functions, or internal systems as part of their reasoning or execution loop. These dependencies act as the AI system's supply chain, where a breach in one part can undermine the integrity of the entire system. If attackers tamper the grounding data, a model’s output can be intentionally skewed or poisoned. Likewise, if the tools an agent depends on - such as cloud automation function - are compromised or misconfigured, the agent could execute malicious actions or leak sensitive information. Securing these dependencies is essential, as attackers may exploit trust in the AI supply chain to manipulate behavior, exfiltrate data, or pivot deeper into the cloud infrastructure. Across all these components, one theme is clear: the interconnected nature of AI in the cloud means that a single weak link can compromise the entire lifecycle. Data corruption can lead to model failure. Pipeline compromise can lead to infrastructure access. Endpoint manipulation can lead to silent data leaks. This is why AI security posture must be end-to-end - from data to deployment. Securing AI in the cloud – it all starts with visibility AI Security Posture Management (AI-SPM), part of Microsoft Defender for Cloud's CNAPP solution, provides security from code to deployed AI models, applications and agents. It offers comprehensive visibility into AI assets, including data assets, models, endpoints, and agents. By identifying vulnerabilities and misconfigurations, AI-SPM enables organizations to reduce risks and detect and respond to AI applications. Reduce AI application risks with Defender for Cloud By leveraging its agentless detection capabilities, Defender for Cloud uncovers misconfigurations and attack paths that could be exploited to compromise AI components at every stage of the lifecycle outlined above. These insights empower security teams to focus on critical risks and address them effectively, minimizing the overall risk. For example, as illustrated in Figure 1, an attack path can demonstrate how an attacker might utilize a virtual machine with a high-severity vulnerability to gain access to an organization's AI platform. This visualization helps security admin teams to take preventative actions, safeguarding the AI environment from potential breaches. The AI-SPM capabilities in Defender for Cloud also supports multi-cloud resources. In another example, as shown in figure 2, the attack path illustrates how an attacker can exploit a vulnerable GCP compute instance to gain access to a custom model deployment in Vertex AI. This scenario underscores the importance of securing every layer of the AI environment, including cloud infrastructure and compute resources, to prevent unauthorized access to sensitive AI components. In yet another scenario, as depicted in figure 3, an attacker might exploit a vulnerable GCP compute instance not only to access the model itself, but also to target the data used to train the AI model. This type of data poisoning attack could lead to altered model and application behavior, potentially skewing outputs, introducing bias, or corrupting downstream processes. Such attacks emphasize the critical need to secure data integrity across all stages of the AI lifecycle, from ingestion and training pipelines to active deployment. Safeguarding the data layer is as vital as securing the underlying infrastructure to ensure that AI applications remain trustworthy and resilient against threats. Summary: Build AI Security from the Ground Up To address these challenges across the whole cloud AI development lifecycle, Microsoft Defender for Cloud provides a suite of security tools tailored for AI workloads. By enabling AI Security Posture Management (AI-SPM) within the Defender for Cloud Defender CSPM plan, organizations gain comprehensive multicloud posture visibility and risk prioritization across platforms such as Azure AI Foundry, OpenAI services, AWS Bedrock, and GCP Vertex AI. This multicloud approach ensures critical vulnerabilities and potential attack paths are effectively identified and mitigated, creating a unified and secure AI ecosystem. Additionally, Defender for AI Services introduces a runtime protection plan specifically designed for custom-built AI applications. This plan extends the security coverage to AI models deployed on Azure AI Foundry and OpenAI services, safeguarding the entire lifecycle - from code to runtime. Together, these integrated solutions empower enterprises to build, deploy, and operate AI technologies securely, even within a diverse and evolving threat landscape. To learn more about Security for AI with Defender for Cloud, visit our website and documentation.
Introducing the new File Integrity Monitoring with Defender for Endpoint integration
As the final and most complex piece of this puzzle is the release of File Integrity Monitoring (FIM) powered by Defender for Endpoint, marks a significant milestone in the Defender for Servers simplification journey. The new FIM solution based on Defender for Endpoint offers real-time monitoring on critical file paths and system files, ensuring that any changes indicating a potential attack are detected immediately. In addition, FIM offers built-in support for relevant security regulatory compliance standards, such as PCI-DSS, CIS, NIST, and others, allowing you to maintain compliance.
Microsoft Defender for Cloud expands U.S. Gov Cloud support for CSPM and server security
U.S. government organizations face unique security and compliance challenges as they migrate essential workloads to the cloud. To help meet these needs, Microsoft Defender for Cloud has expanded support in the Government Cloud with Defender cloud security posture management (CSPM) and Defender for Servers Plan 2. This expansion helps strengthen security posture with advanced threat protection, vulnerability management, and contextual risk insights across hybrid and multi-cloud environments. Defender CSPM and Defender for Servers are available in the following Microsoft Government Clouds: Microsoft Azure Government (MAG) – FedRamp High, DISA IL4, DISA IL5 Government Community Cloud High (GCCH) – FedRamp High, DISA IL4 Defender for Cloud offers support for CSPM in U.S. Government Cloud First, Defender CSPM is generally available for U.S. Government cloud customers. This expansion brings advanced cloud security posture management capabilities to U.S. federal and government agencies—including the Department of Defense (DoD) and civilian agencies—helping them strengthen their security posture and compliance in the cloud. Defender CSPM empowers agencies to continuously discover, assess, monitor, and improve their cloud security posture, including the ability to monitor and correct configuration drift, ensuring they meet regulatory requirements and proactively manage risk in highly regulated environments. Additional benefits for government agencies: Continuous Compliance Assurance Unlike static audits, Defender CSPM provides real-time visibility into the security posture of cloud environments. This enables agencies to demonstrate ongoing compliance with federal standards—anytime, not just during audit windows Risk-Based Prioritization Defender CSPM uses contextual insights and attack path analysis to help security teams focus on the most critical risks first—maximizing impact while optimizing limited resources Agentless Monitoring With agentless scanning, agencies can assess workloads without deploying additional software—ideal for sensitive or legacy systems Security recommendations in Defender CSPM To learn more about Defender CSPM, visit our technical documentation. Defender for Cloud now offers full feature parity for server security in U.S. Government Cloud In addition to Defender CSPM, we’re also expanding our support for server security in the U.S. GovCloud. Government agencies face mounting challenges in securing the servers that support their critical operations and sensitive data. As server environments expand across on-premises, hybrid, and multicloud platforms, maintaining consistent security controls and compliance with federal standards like FedRAMP and NIST SP 800-53 becomes increasingly difficult. Manual processes and periodic audits can’t keep up with configuration drift, unpatched vulnerabilities, and evolving threats—leaving agencies exposed to breaches and compliance risks. Defender for Servers provides continuous, automated threat protection, vulnerability management, and compliance monitoring across all server environments, enabling agencies to safeguard their infrastructure and maintain a strong security posture. We are excited to share that all capabilities in Defender for Servers Plan 2 are now available in U.S. GovCloud, including these newly added capabilities: Agent-based and agentless vulnerability assessment recommendations Secrets detection recommendations EDR detection recommendations Agentless malware detection File integrity monitoring Baseline recommendations Customers can start using all capabilities of Defender for Servers Plan 2 in U.S. Government Cloud starting today. To learn more about Defender for Servers, visit our technical documentation. Get started today! To gain access to the robust capabilities provided by Defender CSPM and Defender for Servers, you need to enable the plans on your subscription. To enable the Defender CSPM and Defender for Servers plans on your subscription: Sign in to the Azure portal. Search for and select Microsoft Defender for Cloud. In the Defender for Cloud menu, select Environment settings. Select the relevant Azure subscription On the Defender plans page, toggle the Defender CSPM plan and/or Defender for Servers to On. Select Save.New innovations to protect custom AI applications with Defender for Cloud
Today’s blog post introduced new capabilities to enhance AI security and governance across multi-model and multi-cloud environments. This follow-on blog post dives deeper into how Microsoft Defender for Cloud can help organizations protect their custom-built AI applications. The AI revolution has been transformative for organizations, driving them to integrate sophisticated AI features and products into their existing systems to maintain a competitive edge. However, this rapid development often outpaces their ability to establish adequate security measures for these advanced applications. Moreover, traditional security teams frequently lack the visibility and actionable insights needed, leaving organizations vulnerable to increasingly sophisticated attacks and struggling to protect their AI resources. To address these challenges, we are excited to announce the general availability (GA) of threat protection for AI services, a capability that enhances threat protection in Microsoft Defender for Cloud. Starting May 1, 2025, the new Defender for AI Services plan will support models in Azure AI and Azure OpenAI Services. Note: Effective August 1, 2025, the price for Defender for AI Services was updated to $0.0008 per 1,000 tokens per month (USD – list price). “Security is paramount at Icertis. That’s why we've partnered with Microsoft to host our Contract Intelligence platform on Azure, fortified by Microsoft Defender for Cloud. As large language models (LLMs) became mainstream, our Icertis ExploreAI Service leveraged generative AI and proprietary models to transform contract management and create value for our customers. Microsoft Defender for Cloud emerged as our natural choice for the first line of defense against AI-related threats. It meticulously evaluates the security of our Azure OpenAI deployments, monitors usage patterns, and promptly alerts us to potential threats. These capabilities empower our Security Operations Center (SOC) teams to make more informed decisions based on AI detections, ensuring that our AI-driven contract management remains secure, reliable, and ahead of emerging threats.” Subodh Patil, Principal Cyber Security Architect at Icertis With these new threat protection capabilities, security teams can: Monitor suspicious activity in Azure AI resources, abiding by security frameworks like the OWASP Top 10 threats for LLM applications to defend against attacks on AI applications, such as direct and indirect prompt injections, wallet abuse, suspicious access to AI resources, and more. Triage and act on detections using contextual and insightful evidence, including prompt and response evidence, application and user context, grounding data origin breadcrumbs, and Microsoft Threat Intelligence details. Gain visibility from cloud to code (right to left) for better posture discovery and remediation by translating runtime findings into posture insights, like smart discovery of grounding data sources. Requires Defender CSPM posture plan to be fully utilized. Leverage frictionless onboarding with one-click, agentless enablement on Azure resources. This includes native integrations to Defender XDR, enabling advanced hunting and incident correlation capabilities. Detect and protect against AI threats Defender for Cloud helps organizations secure their AI applications from the latest threats. It identifies vulnerabilities and protects against sophisticated attacks, such as jailbreaks, invisible encodings, malicious URLs, and sensitive data exposure. It also protects against novel threats like ASCII smuggling, which could otherwise compromise the integrity of their AI applications. Defender for Cloud helps ensure the safety and reliability of critical AI resources by leveraging signals from prompt shields, AI analysis, and Microsoft Threat Intelligence. This provides comprehensive visibility and context, enabling security teams to quickly detect and respond to suspicious activities. Prompt analysis-based detections aren’t the full story. Detections are also designed to analyze the application and user behavior to detect anomalies and suspicious behavior patterns. Analysts can leverage insights into user context, application context, access patterns, and use Microsoft Threat Intelligence tools to uncover complex attacks or threats that escape prompt-based content filtering detectors. For example, wallet attacks are a common threat where attackers aim to cause financial damage by abusing resource capacity. These attacks often appear innocent because the prompts' content looks harmless. However, the attacker's intention is to exploit the resource capacity when left unconstrained. While these prompts might go unnoticed as they don't contain suspicious content, examining the application's historical behavior patterns can reveal anomalies and lead to detection. Respond and act on AI detections effectively The lack of visibility into AI applications is a real struggle for security teams. The detections contain evidence that is hard or impossible for most SOC analysts to access. For example, in the below credential exposure detection, the user was able to solicit secrets from the organizational data connected to the Contoso Outdoors chatbot app. How would the analyst go about understanding this detection? The detection evidence shows the user prompt and the model response (secrets are redacted). The evidence also explicitly calls out what kind of secret was exposed. The prompt evidence of this suspicious interaction is rarely stored, logged, or accessible anywhere outside the detection. The prompt analysis engine also tied the user request to the model response, making sense of the interaction. What is most helpful in this specific detection is the application and user context. The application name instantly assists the SOC in determining if this is a valid scenario for this application. Contoso Outdoors chatbot is not supposed to access organizational secrets, so this is worrisome. Next, the user context reveals who was exposed to the data, through what IP (internal or external) and their supposed intention. Most AI applications are built behind AI gateways, proxies, or Azure API Management (APIM) instances, making it challenging for SOC analysts to obtain these details through conventional logging methods or network solutions. Defender for Cloud addresses this issue by using a straightforward approach that fetches these details directly from the application’s API request to Azure AI. Now, the analyst can reach out to the user (internal) or block (external) the identity or the IP. Finally, to resolve this incident, the SOC analyst intends to remove and decommission the secret to mitigate the impact of the exposure. The final piece of evidence presented reveals the origin of the exposed data. This evidence substantiates the fact that the leak is genuine and originates from internal organizational data. It also provides the analyst with a critical breadcrumb trail to successfully remove the secret from the data store and communicate with the owner on next steps. Trace the invisible lines between your AI application and the grounding sources Defender for Cloud excels in continuous feedback throughout the application lifecycle. While posture capabilities help triage detections, runtime protection provides crucial insights from traffic analysis, such as discovering data stores used for grounding AI applications. The AI application's connection to these stores is often hidden from current control or data plane tools. The credential leak example provided a real-world connection that was then integrated into our resource graph, uncovering previously overlooked data stores. Tagging these stores improves attack path and risk factor identification during posture scanning, ensuring safe configuration. This approach reinforces the feedback loop between runtime protection and posture assessment, maximizing cloud-native application protection platform (CNAPP) effectiveness. Align with AI security frameworks Our guiding principle is widely recognized by OWASP Top 10 for LLMs. By combining our posture capabilities with runtime monitoring, we can comprehensively address a wide range of threats, enabling us to proactively prepare for and detect AI-specific breaches with Defender for Cloud. As the industry evolves and new regulations emerge, frameworks such as OWASP, the EU AI Act, and NIST 600-1 are shaping security expectations. Our detections are aligned with these frameworks as well as the MITRE ATLAS framework, ensuring that organizations stay compliant and are prepared for future regulations and standards. Get started with threat protection for AI services To get started with threat protection capabilities in Defender for Cloud, it’s as simple as one-click to enable it on your relevant subscription in Azure. The integration is agentless and requires zero intervention in the application dev lifecycle. More importantly, the native integration directly inside Azure AI pipeline does not entail scale or performance degradation in the application runtime. Consuming the detections is easy, it appears in Defender for Cloud’s portal, but is also seamlessly connected to Defender XDR and Sentinel, leveraging the existing connectors. SOC analysts can leverage the correlation and analysis capabilities of Defender XDR from day one. Explore these capabilities today with a free 30-day trial*. You can leverage your existing AI application and simply enable the “AI workloads” plan on your chosen subscription to start detecting and responding to AI threats. *Trial free period is limited to up to 75B tokens scanned. Learn more about the innovations designed to help your organization protect data, defend against cyber threats, and stay compliant. Join Microsoft leaders online at Microsoft Secure on April 9. Explore additional resources Learn more about Runtime protection Learn more about Posture capabilities Watch the Defender for Cloud in the Field episode on securing AI applications Get started with Defender for CloudAgentless code scanning for GitHub and Azure DevOps (preview)
🚀 Start free preview ▶️ Watch a video on agentless code scanning Most security teams want to shift left. But for many developers, "shift left" sounds like "shift pain". Coordination. YAML edits with extra pipeline steps. Build slowdowns. More friction while they're trying to go fast. 🪛 Pipeline friction YAML edits with extra steps ⏱️ Build slowdowns More friction, less speed 🧩 Complex coordination Too many moving parts That's the tension we wanted to solve. With agentless code scanning in Defender for Cloud, you get broad visibility into code and infrastructure risks across GitHub and Azure DevOps - without touching your CI/CD pipelines or installing anything. ✨ Just connect your environment. We handle the rest. Already in preview, here's what's new Agentless code scanning was released in November 2024, and we're expanding the preview with capabilities to make it more actionable, customizable, and scalable: ✅ GitHub & Azure DevOps Connect your GitHub org and scan every repository automatically 🎯 Scoping controls Choose exactly which orgs, projects, and repos to scan 🔍 Scanner selection Enable code scanning, IaC scanning, or both 🧰 UI and REST API Manage at scale, programmatically or in-portal or Cloud portal 🎁 Available for free during the preview under Defender CSPM How agentless code scanning works Agentless code scanning runs entirely outside your pipelines. Once a connector has been created, Defender for Cloud automatically discovers your repositories, pulls the latest code, scans for security issues, and publishes findings as security recommendations - every day. Here's the flow: 1 Discover Repositories in GitHub or Azure DevOps are discovered using a built-in connector. 2 Retrieve The latest commit from the default branch is pulled immediately, then re-scanned daily. 3 Analyze Built-in scanners run in our environment: Code Scanning – looks for insecure patterns, bad crypto, and unsafe functions (e.g., `pickle.loads`, `eval()`) using Bandit and ESLint. Infrastructure as Code (IaC) – detects misconfigurations in Terraform, Bicep, ARM templates, CloudFormation, Kubernetes manifests, Dockerfiles, and more using Checkov and Template Analyzer. 4 Publish Findings appear as Security recommendations in Defender for Cloud, with full context: file path, line number, rule ID, and guidance to fix. Get started in under a minute 1 In Defender for Cloud, go to Environment settings → DevOps Security 2 Add a connector: Azure DevOps – requires Azure Security Admin and ADO Project Collection Admin GitHub – requires Azure Security Admin and GitHub Org Owner to install the Microsoft Security DevOps app 3 Choose your scanning scope and scanners 4 Click Save – and we'll run the first scan immediately s than a minute No pipeline configuration. No agent installed. No developer effort. Do I still need in-pipeline scanning? Short answer: yes - if you want depth and speed in the development workflow. Agentless scanning gives you fast, wide coverage. But Defender for Cloud also supports in-pipeline scanning using Microsoft Security DevOps (MSDO) command line application for Azure DevOps or GitHub Action. Each method has its own strengths. Here's how to think about when to use which - and why many teams choose both: When to use... ☁️ Agentless Scanning 🏗️ In-Pipeline Scanning Visibility Quickly assess all repos at org-level Scans and enforce every PR and commit Setup Requires only a connector Requires pipeline (YAML) edits Dev experience No impact on build time Inline feedback inside PRs and builds Granularity Repo-level control with code and IaC scanners Fine-tuned control per tool or branch Depth Default branch scans, no build context Full build artifact, container, and dependency scanning 💡 Best practice: start broad with agentless. Go deeper with in-pipeline scans where "break the build" makes sense. Already using GitHub Advanced Security (GHAS)? GitHub Advanced Security (GHAS) includes built-in scanning for secrets, CodeQL, and open-source dependencies - directly in GitHub and Azure DevOps. You don't need to choose. Defender for Cloud complements GHAS by: Surfaces GHAS findings inside Defender for Cloud's Security recommendations Adds broader context across code, infrastructure, and identity Requires no extra setup - findings flow in through the connector You get centralized visibility, even if your teams are split across tools. One console. Full picture. Core scenarios you can tackle today 🛡️ Catch IaC misconfigurations early Scan for critical misconfigurations in Terraform, ARM, Bicep, Dockerfiles, and Kubernetes manifests. Flag issues like public storage access or open network rules before they're deployed. 🎯 Bring code risk into context All findings appear in the same portal you use for VM and container security. No more jumping between tools - triage issues by risk, drill into the affected repository and file, and route them to the right owner. 🔍 Focus on what matters Customize which scanners run and where. Continuously scan production repositories. Skip forks. Run scoped PoCs. Keep pace as repositories grow - new ones are auto-discovered. What you'll see - and where All detected security issues show up as security recommendations in the recommendations and DevOps Security blades in Defender for Cloud. Every recommendation includes: ✅ Affected repository, branch, file path, and line number 🛠️ The scanner that found it 💡 Clear guidance to fix What's next We're not stopping here. These are already in development: 🔐 Secret scanning Identify leaked credentials alongside code and IaC findings 📦 Dependency scanning Open-source dependency scanning (SCA) 🌿 Multi-branch support Scan protected and non-default branches Follow updates in our Tech Community and release notes. Try it now - and help us shape what comes next Connect GitHub or Azure DevOps to Defender for Cloud (free during preview) and enable agentless code scanning View your discovered DevOps resources in the Inventory or DevOps Security blades Enable scanning and review recommendations Microsoft Defender for Cloud → Recommendations Shift left without slowing down. Start scanning smarter with agentless code scanning today. Helpful resources to learn more Learn more in the Defender for Cloud in the Field episode on agentless code scanning Overview of Microsoft Defender for Cloud DevOps security Agentless code scanning - configuration, capabilities, and limitations Set up in-pipeline scanning in: Azure DevOps GitHub action Other CI/CD pipeline tools (Jenkins, BitBucket Pipelines, Google Cloud Build, Bamboo, CircleCI, and more)
Microsoft AI Security Story: Protection Across the Platform
Explore how Microsoft’s end-to-end AI security platform empowers organizations to confidently adopt generative AI. Learn how to discover and control shadow AI, protect sensitive data, and defend against emerging threats—so you can innovate securely and at scaleYour cluster, your rules: Helm support for container security with Microsoft Defender for Cloud
Container security within Microsoft Defender for Cloud has helped security teams protect their Kubernetes workloads with deep visibility, real-time threat detection, and cloud-native runtime protection. Up until now it’s been delivered via Azure Kubernetes Service (AKS) add-on or Arc for Kubernetes extension, providing a streamlined, fully managed experience, deeply integrated with Azure. But for some teams, especially those operating in complex, multi-cloud environments or with specific operational requirements, this could introduce constraints around customization and deployment. To address this, we’ve introduced Helm support, making it easier to deploy the sensor for container security and enabling greater agility, customization, and seamless integration with modern DevOps workflows. Customers can now choose whether to use Helm to deploy the sensor or to use the previous method to deploy it as an AKS add-on or an Arc for Kubernetes extension for clusters outside of Azure. But why does this matter? Let’s take a step back. The backstory: Why we need more flexibility Since we first introduced our sensor back in 2021, deploying it meant using the built-in AKS add-on or provisioning it through Arc for other environments. This is one of our enablers for the “auto-provisioning" feature, which automatically installs and updates our sensor on managed clusters. This approach made setup simple and tightly integrated but also introduced some friction. Wait for the AKS release cycle to roll out new features. Harder to achieve custom deployment models, like GitOps or advanced CI/CD integrations. Limited support existed for configuring the sensor in non-standard environments. This was fine for many teams, but in larger organizations with multiple teams, strict change management, and complex multi-cluster environments, the lack of deployment flexibility of the sensor could slow down operations or create friction with established workflows. Deploying via Helm: Why is it a big deal? Helm is the de facto package manager for Kubernetes, trusted by DevOps teams to install, configure, and manage workloads in a consistent, declarative way. We’re now supporting Helm as a standalone deployment option - giving you direct access to the helm chart without the abstraction provided by the AKS add-on or Arc for Kubernetes extension. This means you can now deploy and manage the sensor like any other Helm-managed workload with full control over when, how, and where it's deployed, all while aligning naturally with GitOps, CI/CD pipelines, and your existing infrastructure-as-code practices. Helm supports multi-cloud with less overhead Traditionally, deploying Defender for Cloud on non-AKS clusters like EKS and GKE required onboarding those clusters to Azure Arc for Kubernetes. Arc provides a powerful way to centrally manage and govern clusters that live outside Azure, which is ideal for organizations looking to apply Azure-native policies, inventory, or insights across hybrid environments. But what if all you want is Defender for Cloud’s runtime security with minimal operational overhead? That’s where Helm comes in. With Helm, you can now deploy the sensor without requiring Arc onboarding, which means: Smaller footprint on your clusters No access required for your Kubernetes API server Simpler setup focused purely on security This approach is ideal for teams that want to integrate Defender for Cloud into existing EKS or GKE environments while staying aligned with GitOps or CI/CD practices — and without pulling in broader Azure governance tooling. Arc still plays an important role in hybrid Kubernetes management. But if your goal is to quickly secure workloads across clusters with minimal configuration, Helm gives you a lightweight, purpose-built path forward. What you can do with Helm-based deployment Opt-in to adopt new Private, Public Preview or General Availability (GA) features as soon as they’re published. Great for early adopters and fast-moving teams. Gain more control over upgrades by integrating into CI/CD and GitOps. Whether you're using ArgoCD, Flux, or GitHub Actions, Helm makes it easy to embed Defender for Cloud into your pipelines. This means consistent deployments across clusters and security that scales with your application delivery. Override values using your own YAML files, so you can fine-tune how the sensor behaves based on RBAC rules, logging preferences, or network settings. Experiment safely by deploying Defender for Cloud in a dev cluster. Validate new features, tear it down, and repeat the cycle. Helm simplifies experimentation, making it easier to test without risking your production environment. The (not so) fine print While Helm unlocks flexibility, there are still a few things to keep in mind: Helm support is for the sensor component only, not the full Microsoft Defender for Cloud configuration experience. If you are moving to Helm, the “auto-provisioning” feature doesn’t work. Meaning you are responsible for version upgrades and version compatibility, especially when integrating with CI/CD tools that manage Helm releases automatically. Ready to deploy? You can learn more on how to deploy the sensor via Helm to protect your containerized environment with Defender for Cloud
