As early as September 2026, Storm-0940, a China-state aligned actor, used the agentic AI penetration testing framework ARTEX to automate attacks targeting hundreds of organizations globally across a broad range of industries. Several of these Storm-0940 ARTEX-driven attacks have resulted in the actor obtaining privileged access to an organization’s cloud infrastructure – including multiple instances where the time from initial targeting to privileged access was less than 3 hours. Microsoft assesses that Storm-0940 was responsible for the recently disclosed ConnectWise supply chain compromise of a multi-tenant application.

This activity demonstrates how threat actors are integrating agentic AI into existing offensive security workflows and allows them to scale their operations exponentially. Agents are not constrained by factors affecting humans – they can work around the clock, on weekends, and on holidays and attempt multiple breach paths simultaneously enabling significantly reduced time from selecting a target to achieving objectives, increasing the speed and impact of complex attacks like supply chain compromises.

Storm-0940’s use of ARTEX accelerated the speed of compromised application abuse to authenticate to Microsoft 365 customer environments through applications that had already been granted access. This allowed the threat actor to operate without requiring an interactive user sign-in. In multiple affected environments, Microsoft observed AI-accelerated follow-on activity through Microsoft Graph, including reconnaissance, application credential changes, and attempts to modify privileges that could enable expanded or persistent access. The activity conducted by the threat actor through the usage of ARTEX framework did not result from a compromise of or a vulnerability in Microsoft corporate systems, products, or services.

Although Microsoft identified Storm-0940-initiated authentication and follow-on activity in multiple customer environments, the presence of an affected application or successful threat actor authentication does not necessarily indicate that customer data was accessed or exfiltrated. Microsoft Defender XDR provides detections and hunting queries for suspicious Microsoft Graph activity and activity associated with known threat infrastructure. Customers should review service principal sign-ins, investigate unexpected application credential or privilege changes, and follow ConnectWise’s published containment guidance while preserving relevant evidence for investigation. For a full list of detections please see the detections section.

What’s happening

Storm-0940 is a China-state aligned actor (with no known industry aliases) that has been active since 2021 and targets organizations across multiple industries for data theft. The actor has historically gained initial access using password spraying and exploitation of internet-facing applications, before using compromised accounts to move through targeted environments. In cloud environments, the actor has also established persistence by adding credentials to existing OAuth applications, allowing continued access to Microsoft 365 resources. The actor has used these applications to access and exfiltrate email and other data through Microsoft Graph.

As early as September 2026, Storm-0940 used the agentic AI penetration testing framework ARTEX to automate attacks targeting hundreds of organizations globally across a broad range of industries. These include aerospace and defense, automotive, chemicals, energy, financial services, government, legal, manufacturing, media, military, semiconductor, software, technology, and think tanks and non-profits. During the ConnectWise supply chain compromise, Storm-0940 used ARTEX to accelerate scanning and reconnaissance, password spraying, and OAuth application abuse at downstream victims.

Several of these Storm-0940 ARTEX-driven attacks have resulted in the actor obtaining privileged access to an organization’s cloud infrastructure – including multiple instances where the time from initial targeting to privileged access was less than 3 hours. When automated with AI, these activities generate a large volume of traffic and log data that may generate alerts. However, the speed of the activity allows very little time for Defenders to respond to those alerts and remediate the actor’s access in a coordinated fashion. Storm-0940’s activity illustrates how a threat actor with a broad target set can use an agentic AI tool and privileged authentication material to quickly attempt to compromise many organizations. While the majority of the targeting wasn’t successful, Storm-0940 achieved privileged cloud persistence at many organizations in a brief time.

What is ARTEX?

ARTEX is an open-source penetration testing framework that can use any AI model to automate a variety of offensive security workflows. The ARTEX framework is a multi-agent LLM system written in GO with a Next.js frontend. While the UI and generated output default to English, the framework can be switched to Korean, Mandarin, Spanish, or Japanese. ARTEX is a system of LLM-driven agents that run an autonomous penetration test from reconnaissance through data exfiltration with little needed human interaction. The agents then accumulate the discovered assets and vulnerabilities into a graph during the penetration test. In October 2026, public reporting noted that the ARTEX framework was being used by threat actors, such as the personal data breaches targeting Korean financial institutions. Microsoft Threat Intelligence has identified threat actors across multiple geographic regions leveraging the ARTEX framework.

ConnectWise published an initial advisory on October 16, 2026, and subsequently expanded its disclosures and containment guidance. The advisory details ConnectWise’s investigation of attempted unauthorized access associated with Cloud Backup. Following the unauthorized access, Storm-0940 used ARTEX to attempt to sign-in to more than 2,250 tenants. While OAuth application abuse is a typical part of Storm-0940’s toolset, in this case the actor used ARTEX to accelerate the activity to machine speed.

Password Spraying

Between October 10 and 14, 2026, Storm-0940 infrastructure at 144.172.64[.]99 conducted an automated cross-tenant password-spray campaign targeting 327 accounts across eight organizations to gain access to Microsoft 365 and Exchange Online. During this large campaign, Microsoft telemetry captured 151,000+ failed logon events, with activity peaking on October 11 at 2,900 failures per minute and concentrating more than 111,000 failures into a single day. The campaign blended broad, low-rate account spraying with sustained, high-volume authentication attempts against selected identities; 48 accounts received more than 1,000 failures, and lockout responses represented nearly 98% of all activity. Despite the scale, no successful authentication, token issuance, Graph call, or directory change was observed.

Downstream customer access

On October 15, immediately after this notable activity, public reports of the compromise of the popular cloud backup application ConnectWise started to surface with direct references to indicators of compromise matching the same network range observed for the earlier password-spray campaign (144.172.64.x). An advisory from the affected cloud backup vendor posted on October 16 shared later additional indicators with one IP address matching exactly the 144.172.64[.]99 infrastructure responsible for the earlier password-spray campaign.

Additionally, after acquiring control of the identities of multiple ConnectWise cloud applications, the AI agents operating on behalf of the threat actor continued to use the same IP range to authenticate to customer environments using the illicit access acquired through these stolen app credentials, effectively taking advantage of the already established trust by these apps within a tenant. In some of these environments, the AI agents (on behalf of the threat actor) progressed beyond authentication to Microsoft Graph and directory operations, including reconnaissance, application credential modifications to establish persistence, and changes involving identities, groups, and privileged roles. Microsoft identified multiple customer environments with evidence of follow-on activity, highlighting how a compromised third-party application with high privileges could provide access beyond its originally intended purpose.

The application credential modification made by Storm-0940’s associated agents in the targeted victims’ environments can lead to persistence through other identities, credentials, and cloud services. These changes can remain active as a backdoor even after the original compromised application is mediated. Organizations should examine service principal sign-ins alongside subsequent Microsoft Graph activity, directory changes, and resource access, correlating suspicious events with authorized administrative activity. The presence of an affected application, or even successful authentication, does not necessarily indicate unauthorized data access or data exfiltration.

Mitigation and protection guidance

Microsoft recommends the following mitigations to reduce the impact of this threat. Check the recommendations card for the deployment status of monitored mitigations.

Immediate actions

• Keep affected ConnectWise application connections disabled until ConnectWise provides formal restoration instructions.
• Do not delete enterprise applications as the first response. Preserve configuration and evidence before making irreversible changes.
• Inventory all four application IDs listed in this profile and record the local service-principal Object ID in each tenant.
• Review every Microsoft 365 tenant where the affected applications are currently or were previously installed or authorized, even if the integration is no longer in use. Search by application ID rather than display name.
• Preserve available Microsoft Entra sign-in and audit records, Microsoft Purview Audit records, SIEM data, and previously configured Microsoft Graph telemetry. Do not delay urgent containment while waiting for exports.
• Review activity starting from at least October 15, 2026. Where records are available, extend service-principal sign-in review to October 1 and investigate earlier related activity, including failed authentications and volume anomalies.
• Review successful and failed service-principal sign-ins separately. Investigate unfamiliar sources and activity outside expected vendor infrastructure; do not limit review to the published IPs.
• Review Microsoft Entra audit records for application or service-principal credential additions; new applications, service principals, or owners; app-role assignments and consent grants; privileged role assignments; and changes to users, groups, authentication methods, or Conditional Access. On confirmed suspicious activity, revoke unnecessary permissions and rotate credentials.
• Review Microsoft 365 audit records to look for reconnaissance activities like listing directories, permissions, and approvals coming from unusual IPs.
• Review Microsoft 365 audit records for unusual mail or file access, downloads, forwarding, inbox or transport rules, delegated mailbox permissions, and related resource activity.
• Preserve evidence, then have an appropriately authorized responder remove confirmed unauthorized credentials, grants, owners, assignments, and identities.

Additional recommendations

• Threat actor misuse of AI accelerates risk across enterprise environments by amplifying existing threats such as exploitation of vulnerabilities, phishing, malware threats, and insider activity. To help organizations stay ahead of AI-enabled threat activity, Microsoft has introduced the Security Dashboard for AI. The dashboard provides users with a unified view of AI security posture by aggregating security, identity, and data risk across Microsoft Defender, Microsoft Entra, and Microsoft Purview. This allows organizations to understand what AI assets exist in their environment, recognize emerging risk patterns, and prioritize governance and security across AI agents, applications, and platforms. To learn more about the Microsoft Security Dashboard for AI see: Assess your organization’s AI risk with Microsoft Security Dashboard for AI (Preview).
• Enable threat protection for AI services in Microsoft Defender for Cloud to identify threats to generative AI applications in real time and for assistance in responding to security issues.
• Apply least privilege to multi-tenant application permissions and consent grants.
• Monitor credential additions, privilege assignments, and anomalous app-only activity, especially to applications with high privileged permissions and scopes.
• Verify that vendor credential rotation and any tenant-level remediation eliminated remaining unauthorized access.

Assess the operational effect on backup and restore workflows and follow current ConnectWise restoration guidance.

Microsoft Defender XDR detections

Microsoft Defender XDR customers can refer to the list of applicable detections below. Microsoft Defender XDR coordinates detection, prevention, investigation, and response across endpoints, identities, email, and apps to provide integrated protection against attacks like the threat discussed in this blog.

Customers with provisioned access can also use Microsoft Security Copilot in Microsoft Defender to investigate and respond to incidents, hunt for threats, and protect their organization with relevant threat intelligence.

Microsoft Defender for Cloud Apps detections

Microsoft Defender for Cloud (Microsoft Defender for Key Vault)

Microsoft Security Copilot

Security Copilot customers can use the standalone experience to create their own prompts or run the following prebuilt promptbooks to automate incident response or investigation tasks related to this threat:

• Incident investigation
• Threat actor profile
• Threat Intelligence 360 report based on MDTI article

Note that some promptbooks require access to plugins for Microsoft products such as Microsoft Defender XDR or Microsoft Sentinel.

Threat intelligence reports

Microsoft customers can use the following reports in Microsoft products to get the most up-to-date information about the threat actor, malicious activity, and techniques discussed in this blog. These reports provide intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.

Microsoft Defender XDR Threat analytics

Activity Profile: ConnectWise Cloud Backup credential abuse: assessment and response guidance

Indicators of compromise (IOC)

Advanced hunting

NOTE: The following sample queries let you search for a week’s worth of events. To explore up to 30 days’ worth of raw data to inspect events in your network and locate potential indicators related to this campaign for more than a week, go to the Advanced Hunting page > Query tab, select the calendar dropdown menu to update your query to hunt for the Last 30 days.

Microsoft Defender XDR advanced hunting

1- OAuthAppInfo → Is the affected app present, enabled, and what permissions does it hold?

Start with OAuthAppInfo to determine whether any of the affected ConnectWise applications are present in the tenant and understand the access they have been granted. The query identifies the application and its tenant-specific service principal, whether it is enabled, its privilege level, consent information, and the individual permissions assigned to it.

This establishes the customer’s potential exposure and gives investigators the ServicePrincipalId needed for further hunting. A match does not mean the application was abused, only that it is present and potentially had access, so the next step is to determine whether the service principal was actually used. Run query

let ConnectWiseApps = dynamic([
    "506e08f9-6e9a-4da4-942b-a099a03644ae", // ConnectWise Cloud Backup
    "24205314-2b89-4e07-a2a4-579e898a5640", // ConnectWise - MS Teams
    "0de14c77-b9b0-4137-9360-34878a929827" // ConnectWise - MS Graph 
]);
OAuthAppInfo
| where OAuthAppId in (ConnectWiseApps)
| mv-expand Permission = Permissions
| extend
    PermissionName = tostring(Permission.PermissionName),
    TargetApp = tostring(Permission.TargetAppDisplayName),
    TargetAppId = tostring(Permission.TargetAppId),
    PermissionType = tostring(Permission.PermissionType),
    PermissionPrivilegeLevel = tostring(Permission.PrivilegeLevel),
    UsageStatus = tostring(Permission.UsageStatus)
| project
    AppName,
    OAuthAppId,
    ServicePrincipalId,
    AppStatus,
    PrivilegeLevel,
    IsAdminConsented,
    PermissionName,
    PermissionType,
    PermissionPrivilegeLevel,
    TargetApp,
    TargetAppId,
    UsageStatus
| order by AppName asc, PermissionPrivilegeLevel desc

2 – EntraIdSpnSignInEvents + GraphAPIAuditEvents → Did the service principal authenticate, and what Microsoft Graph activity followed?

Use this query to investigate service-principal sign-ins and Microsoft Graph API activity associated with the identified ConnectWise applications and suspicious IP addresses, starting October 13, 2026.

The query combines both event types into a chronological view, helping defenders identify suspicious authentication and related Graph operations, including potential credential changes, privilege modifications, and unusual resource access. Remove the IP filter for broader hunting. Results require further correlation, as authentication alone does not establish compromise. Run query

let Apps = dynamic([
    "506e08f9-6e9a-4da4-942b-a099a03644ae",
    "24205314-2b89-4e07-a2a4-579e898a5640",
    "0de14c77-b9b0-4137-9360-34878a929827"   
]);
let IPs = dynamic(["144.172.64.60", "144.172.64.99", "144.172.64.128"]);
union kind=outer
    (EntraIdSpnSignInEvents
     | extend EventType = "Sign-in"),
    (GraphAPIAuditEvents
     | extend EventType = "Graph API", IPAddress = IpAddress)
| where Timestamp >= datetime(2026-10-13)
| where ApplicationId in (Apps)
| where IPAddress in (IPs) // Comment out for broader hunting
| project-away IpAddress
| order by Timestamp asc

3 – Bulk Key Vault secret reads by a single identity across multiple vaults

Run query

CloudKeyVaultEvents
| where Timestamp > ago(14d)
| where ActivityName == "SecretGet" and HttpStatusCode == 200
| summarize SecretGets = count(), VaultCount = dcount(AzureResourceId),
   IPs = make_set(IPAddress, 20)
   by bin(Timestamp, 15m), AccountObjectId, AccountTenantId
| where SecretGets >= 20 and VaultCount >= 3

4 – Key Vault, Storage and ARM activity from the IOC IPs

Run query

let IPs = dynamic(["144.172.64.128","144.172.64.60","144.172.64.99"]);
union
 (CloudKeyVaultEvents | where IPAddress in (IPs) | extend Source = "KeyVault", Operation = ActivityName),
 (CloudStorageAggregatedEvents | where IPAddress in (IPs) | extend Source = "Storage", Operation = tostring(OperationNamesList)),
 (CloudAuditEvents | where IPAddress in (IPs) | extend Source = "ARM", Operation = OperationName)
| where Timestamp > ago(30d)
| project Timestamp, Source, IPAddress, Operation, AzureResourceId
| order by Timestamp asc

Sentinel hunting queries

1-SigninLogs → Did a service principal authenticate, from where, and against what resource?

Use SigninLogs to determine whether an affected application identity actually authenticated. This moves the investigation from potential exposure to observed authentication, allowing defenders to examine the application and service principal alongside the source IP address, geographic information, authentication result, and resource being accessed. Investigators should evaluate these sign-ins against the application’s expected activity and look for unusual source infrastructure, resources, or authentication patterns before pivoting into subsequent Graph activity. Run query

let IPIndicators = dynamic([
    "144.172.64.60",  // IP Indicator
    "144.172.64.99",  // IP Indicator
    "144.172.64.128"  // IP Indicator
]);
let ConnectWiseApps = dynamic([
    "506e08f9-6e9a-4da4-942b-a099a03644ae", // ConnectWise Cloud Backup
    "24205314-2b89-4e07-a2a4-579e898a5640", // ConnectWise - MS Teams
    "0de14c77-b9b0-4137-9360-34878a929827" // ConnectWise - MS Graph 
]);
SigninLogs
| where TimeGenerated >= datetime(2026-10-13)
| where AppId in (ConnectWiseApps)
//| where IPAddress in (IPIndicators) // Comment out to review all activity from these applications
| project
    TimeGenerated,
    AppId,
    ServicePrincipalName,
    ResourceDisplayName,
    ResourceId,
    IPAddress,
    CorrelationId
| order by TimeGenerated asc

2 – MicrosoftGraphActivityLogs → What observable Graph API activity followed?

Use MicrosoftGraphActivityLogs to investigate observable Microsoft Graph activity following authentication. This query allows defenders to pivot on the affected ApplicationId or tenant-specific ServicePrincipalId and examine details such as the request URI, HTTP method, response status, scopes, source IP address, and target workload. This helps establish what Graph activity occurred after the service principal authenticated and provides additional context around the resources the application attempted to access.

Importantly, the absence of results should not be treated as confirmation that no access occurred; Graph API telemetry should be considered alongside the application permissions and service principal authentication activity identified in the previous hunting steps. Run query

let IPIndicators = dynamic([
    "144.172.64.60",  // IP Indicator
    "144.172.64.99",  // IP Indicator
    "144.172.64.128"  // IP Indicator
]);
let ConnectWiseApps = dynamic([
    "506e08f9-6e9a-4da4-942b-a099a03644ae", // ConnectWise Cloud Backup
    "24205314-2b89-4e07-a2a4-579e898a5640", // ConnectWise - MS Teams
    "0de14c77-b9b0-4137-9360-34878a929827" // ConnectWise - MS Graph 
]);
MicrosoftGraphActivityLogs 
| where TimeGenerated >= datetime(2026-10-13)
| where AppId in (ConnectWiseApps)
| where IPAddress in (IPIndicators) // Comment out to review all Graph activity from these applications
| project
    TimeGenerated,
    AppId,
    IPAddress,
    RequestMethod,
    RequestUri,
    ResponseStatusCode,
    Scopes,
    ClientRequestId,
    OperationId,
    RequestId
| order by TimeGenerated asc

MITRE ATT&CK Techniques observed

This threat has exhibited use of the following attack techniques. For standard industry documentation about these techniques, refer to the MITRE ATT&CK framework.

Reconnaissance

• T1595 Active Scanning | Scanning cloud resources to identify targets for compromise.

Initial Access

• T1078.004 Valid Accounts: Cloud Accounts | Using compromised cloud accounts to obtain access.
• T1195 Supply Chain Compromise | Compromising a multi-tenant OAuth application to access downstream customer environments.
• T1199 Trusted Relationship | Access to customer environments through a compromised, trusted third-party application

Privilege Escalation

• T1098.003 Account Manipulation: Additional Cloud Roles | Addition of privileged cloud role assignments, including self assignment of global admin from one of the ConnectWise Management Application.
• T1098.001 Account Manipulation: Additional Cloud Credentials | Addition or modification of application credentials.

Credential Access

• T1528 Steal Application Access Token | Compromising OAuth application authentication material.
• T1555.006 Cloud Secrets Management Stores | Bulk secret reads from Azure Key Vaults

Discovery

• T1087.004 Account Discovery: Cloud Account | Identifying privileged cloud accounts for further targeting.
• T1580 Cloud Infrastructure Discovery | Mapping cloud infrastructure for further targeting.

References

• ConnectWise (SkyKick) Vendor Credentials Abused in M365 Attacks. Huntress
• ConnectWise Trust Center – Cloud Backup advisories. ConnectWise (accessed 2026-10-19).
• ConnectWise Cloud Backup technical investigation and remediation guide. ConnectWise (accessed 2026-10-19).

Learn more

• For guidance on investigating and responding to compromised applications, see Compromised and malicious applications investigation.
• Learn how to investigate app-only authentication with Service principal sign-in logs.
• Review application credentials, permissions, role assignments, and configuration changes in Microsoft Entra security operations for applications.
• Learn how to proactively investigate threats with Advanced hunting in Microsoft Defender XDR.
• Explore the OAuthAppInfo and GraphAPIAuditEvents advanced hunting tables.
• Learn how to find Microsoft 365 activity with Search the audit log.
• Review guidance for reducing excessive application permissions in Secure applications using least privilege.
• For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog.
• To get notified about new publications and to join discussions on social media, follow us on LinkedIn, X (formerly Twitter), and Bluesky.
• To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.

The post AI-driven, large-scale nation-state campaign using ARTEX enables supply chain compromise appeared first on Microsoft Security Blog.

This does not mean agents are inherently malicious. It means they are capable tools that can be granted access to important systems by users. They can make mistakes, be manipulated, or be compromised. Their models can produce variable outputs, their context can change, and their plans can evolve as they work. An agent that operates as intended when a task begins may respond differently as context or inputs change. Depending on how they are designed and deployed, agents can operate continuously, at machine speed and scale.

Satya Nadella, Chairman and Chief Executive Officer of Microsoft, recently described the trust architecture this new era requires: we must separate the supply of intelligence from the authority over it. We should not ask a model to be its own security authority. The controls that determine what it can access, what actions it can take, and whether it should continue operating must sit outside the model, where the model cannot bypass or tamper with them.

Project Perception—Securing your agentic insider

We introduced Project Perception and the Microsoft cyber stack to help organizations defend with agents. Today, we are extending Perception to secure the agentic insider. Guardian Agents help security teams operate continuously, at machine speed and scale, while sensors, context, and actuators across the cyber stack help understand changing agent risk and continuously adapt protection in response. Project Perception and Microsoft Agent 365 share signals, context, and a unified registry giving IT and security teams a consistent view of agents and risk, with the controls each needs.

This builds on a simple security principle: surround non-deterministic intelligence with deterministic controls, independent evidence, and containment boundaries. Assume an agent can fail or be compromised. Observe it continuously. Minimize and tailor its authority before it acts. And continuously adjust that authority as risk changes.

This requires protection across identity, permissions, data, endpoints, network, cloud, and runtime. The system has four continuous responsibilities:

• Know which agents exist, who owns them, why they exist, and what they are doing.
• Contain what each agent can access and do before it acts.
• Protect the data, tools, runtime, resources, and systems in the agent’s path.
• Adapt protection continuously as behavior, context, and risk change.

These are not four products or sequential phases. They operate together. Evidence changes risk. Risk changes policy. Policy changes what the agent is allowed to do. Consider an expense-approval agent. It may need to read expense submissions, check policy, and approve routine reimbursements, but it should not inherit every permission of the employee who sponsors it. Its identity, runtime, access paths, and task-scoped authority should be explicit from the start. If it later encounters a prompt injection or attempts an action outside that task, the system should respond proportionately: preserve safe reads while blocking writes, narrow the resources it can reach, require provable human approval for a consequential step, or isolate and stop the agent when the risk warrants it. This is what continuous containment looks like in practice.

Know every agent and give it an accountable identity

You cannot secure what you cannot see. Agents can be created through Microsoft platforms, integrated through partner platforms and software development kits (SDKs), or introduced locally without a central deployment process. Microsoft Security uses native integrations, connectors, and sensors across the cyber stack to discover more of the agent estate.

We are expanding discovery to 35 additional types of local agents, bringing the total to 60 supported local agents, including Claude Code, OpenAI Codex, and GitHub Copilot. Organizations can bring these agents into a unified registry, regardless of how they were discovered, to understand ownership, activity, and risk.

Discovery tells you that an agent exists. Identity gives security and governance systems a durable anchor for controlling it.

Every agent should have a first-class identity distinct from the person using or sponsoring it. We are extending Microsoft Entra Agent ID with identity types for additional agent patterns, including local and previously unknown agents discovered through security sensors. This means an agent can become a policy target even when it was not originally integrated with Microsoft Security. Agent identity anchors attribution, ownership, lifecycle, risk, permissions, authorization, and policy, so the enterprise can distinguish what a person did from what an agent did on that person’s behalf.

Contain what the agent can do before it acts

Being able to find and identify an agent is necessary, but it is just the start. We need to understand the potential impact the agent can have in the enterprise environment. The next step is to bound the agent across its runtime, its paths to tools and resources, and the authority it can exercise.

Contain the runtime

The model and harness should execute inside a controlled environment rather than inherit fully-privileged access to the device. Sandboxes such as Microsoft Execution Container (MXC) provide policy-controlled access to resources the agent needs to complete its task. They also create an enforcement boundary where security controls and observability can operate outside the agent’s reach. If the agent or harness is compromised, it should not be able to disable the controls watching it.

Control the action space

An agent should not be free to call any tool, API, Model Context Protocol (MCP) server, resource, or other agent it can find. Local and network and data controls must mediate those paths, observe the calls, and enforce enterprise policy. Controlling the destination alone is not enough. Security must also understand the content flowing into and out of the agent, including its sensitivity, provenance, and whether untrusted data may be influencing the agent’s behavior.

Start with no permissions, or least privilege

We have spent decades applying Zero Trust and least privilege to people. Agents make those principles even more important. An agent should not automatically inherit all the standing access of its user. It should begin with no authority and receive only what it needs for the approved task, for only as long as the task requires.

To enable this, we are introducing Dynamic Permissions. Organization-wide policy sets the outer boundary, including preventing an agent from obtaining authority its user does not have. Permissions can then be scoped to the task, made time-bound, and contracted or removed as the task changes or completes. Higher-impact actions can require verified human approval.

Adapt protection as agent risk changes

Least privilege reduces exposure, but it does not eliminate risk. An expense-approval agent may begin a task with the right access and then encounter a prompt injection in an external document. Its configuration has not changed, but its behavior and risk have.

For human users, a delay between detection and response may be manageable. For an agent operating at machine speed, it can be the difference between containment and impact. The security system must be able to understand what changed and act before a person can manually investigate every signal.

That is why we are introducing Dynamic Agent Risk and Dynamic Conditional Access for agents.

Dynamic Agent Risk

Dynamic Agent Risk combines signals from identity, data, endpoints, cloud, network, runtime, and the agent’s own activity. It considers how securely the agent is configured, what resources it can reach, the potential impact if something goes wrong, and whether its actions are drifting from the user’s or organization’s intent.

The result is not a one-time score assigned at onboarding. It is a continuously updated understanding of the agent’s current risk and whether its current authority still matches that risk. The question is not simply whether the agent should run or stop. It is what the agent should be allowed to read, change, invoke, or approve at that moment.

Dynamic Conditional Access

Dynamic Conditional Access extends Microsoft Entra Conditional Access for agents so a change in risk can drive coordinated action across multiple enforcement points. The response is graduated, not binary. Policy can reduce permissions, preserve reads while blocking writes, narrow the data and resources the agent can reach, restrict network paths, shorten or revoke time-bound access, or require provable human approval before a consequential action proceeds. At the highest levels of risk, it can isolate the runtime or stop execution entirely.

Return to the expense agent. It begins with narrowly scoped permission to review and approve expenses within policy. When it encounters untrusted content and attempts an unrelated action, new evidence raises its Dynamic Agent Risk. Policy responds proportionately: it can preserve read access while removing the ability to approve or write, block access to sensitive resources, and require cryptographically provable human approval for a high-impact step. If the risk continues to rise, the system can isolate the runtime or stop execution. The employee remains productive. The agent is constrained without treating every risk change as a kill-switch event.

Secure agentic systems at scale with Guardian Agents

As organizations deploy thousands or hundreds of thousands of agents, manually triaging every alert and coordinating every response will not scale. Securing agents must itself become agentic, while remaining inside boundaries people set.

That is why we are introducing new Playbooks and a team of Guardian Agents in Project Perception. People define policy, approval boundaries, and delegation rules. Playbooks define the desired security outcome and coordinate protective actions. Guardian Agents carry out the work at machine speed, adapting as agent activity, risk, security context, and organizational policy change.

Guardian Agents can help teams understand why risk changed, investigate the relevant evidence, recommend or apply containment, and use what they learn to harden policy. This is not about outsourcing judgment. People retain control over objectives and consequential decisions. The system carries the continuous work that does not scale through manual operations.

Agents will only be adopted at scale if they can be trusted at scale. At Microsoft, we are already operating in a world of hundreds of thousands of agents. As Customer Zero, we have learned that securing agents requires continuous visibility into agent activity, proactive protection of access and data, and adaptive protection that keeps pace with evolving threats. Those lessons directly inform the innovations we are delivering to help every organization adopt agents with confidence.”

—Terrell Cox, Corporate Vice President (CVP) and Deputy Chief Information Security Officer (CISO), Customer Security, Microsoft

Extending containment to the model

As model transparency increases, it creates a new source of security evidence. Chain-of-thought and other model-level signals can help identify intent drift, understand whether untrusted information is influencing reasoning, and detect when an agent’s planned actions are diverging from the task it was given.

We are bringing this deeper evidence into Dynamic Agent Risk, together with signals from across the cyber stack. This builds on Satya Nadella’s principle: increase transparency into the model while keeping security decisions and enforcement independent of it.

Greater model transparency gives security systems deeper evidence to detect suspicious behavior and inform Dynamic Agent Risk. But the core security principle does not change: the model cannot be its own security boundary. Independent systems must observe every layer, including the model itself, and ultimately determine and enforce what the system is allowed to do.

These are not separate pillars. They make the same containment architecture stronger: better evidence, stronger assurance, more accurate risk, and more effective protection.

Confidence to move faster

Organizations are adopting agents to serve customers better, solve problems faster, and give people more time for the work that matters most. The goal is not to make every model perfectly predictable before it can be useful. The goal is to build systems that remain secure even when the model is not.

That requires a clear division of responsibility. Models supply intelligence. People and organizations retain authority. Independent controls establish identity, limit privilege, protect data, preserve evidence, and contain unsafe action. Security continuously reassesses risk and adapts protection as the agent works.

That is what we are working toward: an agentic world where organizations can put intelligence to work with confidence because security can observe it, govern it, and contain it at the same speed.

Learn more here and join us at Microsoft Ignite.

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

The post Agents are your newest insiders. Security must move at their speed.  appeared first on Microsoft Security Blog.

While that flexibility can be valuable, it also affects how enterprises evaluate models, where they implement safeguards, and who is responsible for maintaining those safeguards over time.

As enterprises choose which models to deploy, the relevant question is broader than whether a model is open-weight or closed-weight. Enterprises need to understand what they are using the model for, what could go wrong in that context, and what evidence and controls they need to manage risks.

Today, Microsoft and NVIDIA are publishing Risk Management for Open-Weight Models in Enterprise, the first in a planned series of joint resources intended to help enterprises address those questions. The paper introduces a shared risk taxonomy and an approach to managing model risks grounded in established standards and frameworks, including International Organization for Standardization (ISO) standards and the National Institute of Standards and Technology (NIST) AI Risk Management Framework.

The paper reflects a core idea: weight openness alone does not determine an AI system’s risk. Risk depends on the model, use case, deployment, and safeguards.

Understanding risk in the deployment context

Open- and closed-weight models can share many of the same underlying risks, but how those risks materialize depends on the deployment. A model used to help an employee draft a document presents different considerations than the same model used in a customer-facing workflow, just as a standalone inference endpoint differs from a system connected to external data or tools.

The architecture matters too. A risk may originate in the model, while the most effective control may sit in the inference environment, application, or surrounding operational processes. The joint guidance looks beyond the model label to factors including provenance, intended use, users, deployment conditions, and surrounding controls. This first paper focuses primarily on model-layer risks. Evaluating a model alone does not establish the safety of an agent or application: teams must also assess its permissions, data access, tools, runtime, and operational controls.

Establishing a common language

Managing these risks consistently also requires a common vocabulary across engineering, security, legal, safety, and business teams.

The initial Microsoft and NVIDIA taxonomy organizes risks into five broad categories: Cybersecurity, Data Protection, Content, Human-AI Interaction, and Bias. It is not a policy or deployment checklist, but instead it should be used by enterprises to adapt it to their own systems, use cases, and risk criteria, then connect relevant risks to evaluations, mitigations, and accountable owners.

Using evaluations as risk evidence

Evaluations help turn the taxonomy into something enterprises can use. The paper maps evaluations to a selection of risks across the five categories, giving teams a way to start with a risk that matters for their deployment and identify evaluations that can produce relevant evidence about it.

Microsoft Foundry helps enterprises assess quality, groundedness, and safety with built-in and custom evaluations and automated red teaming. Its configurable content-safety controls help detect and mitigate harmful inputs and outputs and prompt attacks. Teams should validate control availability for their model and deployment, including preview status, and combine these capabilities with application-specific testing, monitoring, and human oversight.

Evaluations still need to be interpreted in the context of a particular deployment and the goal is to make it easier for teams to connect the risks they identify with useful evidence, while building a broader set of evaluation resources that can evolve alongside models, deployment patterns, and emerging risks. Microsoft and NVIDIA plan to use the joint repository to share additional evaluations and point to existing resources that can help enterprises assess specific risks.

Accounting for changes in control and responsibility

Open-weight access gives enterprises greater control over how a model is evaluated, modified, and deployed. Model access and deployment are separate choices: open-weight models can also be used through managed platforms. Responsibility for safeguards depends on the service and deployment configuration; enterprises that operate their own model deployments may take on controls otherwise provided by a managed service.

Those safeguards can operate at different layers, and (depending on the risk) enterprises might use model changes, access controls, input and output filtering, monitoring, or human review. The important step is connecting each identified risk to controls that can effectively address it within the deployed system. Those decisions need to be revisited as models and deployments change.

Building on this work

Risk Management for Open-Weight Models in Enterprise focuses primarily on the model layer. Future work from Microsoft and NVIDIA is intended to extend this approach across the runtime, harness, and application layers, with additional technical guidance on evaluation and mitigation.

We also expect the resources supporting this work to evolve as new models, evaluations, and deployment patterns emerge. The joint repository will provide a place to share additional evaluation resources, including contributions from the broader community.

For enterprises deploying open-weight models today, the paper provides guidance they can begin applying to their own use cases. We encourage developers, security practitioners, researchers, and others working in this space to read the paper, explore the evaluations, and contribute evaluations that can help strengthen this shared body of work.

Read the joint Microsoft-NVIDIA paper, Risk Management for Open-Weight Models in Enterprise.

Explore the joint repository and technical resources.

Risk Management for Open-Weight Models in Enterprise was developed jointly by Microsoft and NVIDIA, with Andrew Berkley and April Chen of Microsoft and Michael Boone, Eileen Long, and Arun Rao of NVIDIA leading the development and editing of the paper.

Explore Microsoft Foundry evaluations and content-safety controls for implementation guidance.

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

The post Managing open-weight model risk in enterprise deployments appeared first on Microsoft Security Blog.

The mission of Microsoft Security’s Frontier Offensive Research & Generative Exploitation (FORGE) Lab is to advance the frontier of autonomous security engineering. We’re building a team that enables AI-native vulnerability research at Microsoft, pushing the boundaries of finding and fixing zero-day vulnerabilities. Four principles guide that work: autonomy over labor, defense through offense, building ecosystems over individual examples, and understanding over findings. This post reflects those principles in practice across Windows, the Linux kernel, and widely used open-source projects.

From May 2026 through September 2026, FORGE helped discover Windows vulnerabilities assigned 140 common vulnerabilities and exposures (CVEs), including 52 addressed in September 2026’s security release alone. The work reaches well beyond Windows. FORGE members submitted 155 internally validated reports across 23 open-source projects, including the Linux kernel. And through Akrites, a Linux Foundation initiative that coordinates confidential remediation and disclosure for vulnerabilities in critical open-source software, one of our Linux reports became the first Akrites submission to result in a patch merged into the Linux kernel.

These results demonstrate that agentic discovery can operate at meaningful volume, but they also expose the next constraint. Finding a difficult vulnerability proves an agent’s frontier capability. Repeatedly converting such findings into security updates requires a different kind of system—one that can move credible work through validation, remediation, and release. Discovery creates security value only when validation and remediation can keep pace. For security leaders, the question is no longer only whether AI can find vulnerabilities, but whether an organization can validate and fix them as fast as they are found.

Three lessons follow, each marking a shift in how we approach vulnerability research:

1. From frontier capability to scale.
2. From token consumption to reasoning economics.
3. From isolated discovery to coordinated validation and remediation.

The scarce resource is not always model intelligence. It can be a working build and deployment, a reproducible trigger, or even an engineer’s time.

At FORGE Lab, we use the multi-model agentic scanning harness, codename MDASH, to organize this work. Our May 2026 introduction detailed its design, while the June 2026 update covered pipeline improvements and benchmark analysis. Here, we focus on what those experiences teach us about operating vulnerability research at scale—across Windows and open-source projects.

Shift 1. From frontier capability to scale

The frontier question is whether a system can find a bug that demands deep reasoning, as we explored in our early work on the CyberGym benchmark. The scale question is whether it can repeat that result across targets without rebuilding every environment, investigation, and review process from scratch. Better models still matter, especially for difficult or unfamiliar bug classes. But once discovery becomes repeatable, model capability is only one constraint on useful output.

Adding auditors can increase candidate volume without increasing the rate of validated findings or shipped fixes. If reports arrive faster than reviewers—in our case, Microsoft Security Response Center (MSRC)—can resolve them, the immediate result is a growing queue. A larger search budget can even reduce useful throughput when duplicate or poorly supported reports consume attention that stronger findings need.

The unit to optimize, therefore, is neither the scan nor the report. It is a reproducible finding that advances with enough evidence for the next stage to act. Reusable preparation, deduplication, and review capacity are therefore core components of the research system.

As agentic systems produce more candidates, the bottleneck shifts from discovery to determining which reports are real, reachable, and security-relevant. Project-specific automated provers—such as proof of vulnerability (PoV)/proof of concept (PoC) generators, harness builders, and trigger-input finders—turn plausible reports into reproducible evidence that engineers and maintainers can act on. By finding crashing inputs, confirming reachable execution paths, and producing regression-ready triggers within each project’s build and test environment, these tools can help reduce human triage, accelerate remediation, and make vulnerability research sustainable at scale. For example, by leveraging deterministic algorithms such as abstract syntax tree (AST), one of our internal projects reduced about 45% duplicate findings across multiple scans of the same code which reduced the load on the PoC generator and subsequently human triage effort.

More candidates do not create more throughput when the review queue grows faster than fixes ship.

Shift 2. From token consumption to reasoning economics

At scale, every repeated orientation, speculative branch, and redundant debate carries a cost. But minimizing tokens alone is the wrong objective. A short, ambiguous report may be cheap to generate yet expensive to investigate; a longer analysis that establishes the missing execution path may reduce total system cost.

The key question is where the next unit of reasoning will change a decision. If an index can identify callers, asking a frontier model to rediscover them wastes capacity. If the uncertainty is whether two lifetime conditions can coexist across callbacks, deeper reasoning may be warranted. If the question is whether an input triggers the failure, an executable check can provide evidence that more prose cannot.

MDASH combines frontier and distilled models, specialized auditors, and code-analysis tools, enabling work to be allocated by task. That flexibility does not guarantee optimal allocation. Routing routine work to cheaper models, reusing verified context, and escalating unresolved questions to stronger reasoning are hypotheses to test—not efficiency gains to assume.

A useful allocation policy starts by identifying what remains unknown: a caller, a build configuration, a reproducer, or a causal explanation. The next action should close that specific evidence gap. Repeating a review without adding evidence spends more tokens while preserving the same uncertainty. Early filtering can also discard real bugs, so any savings must be measured against coverage and missed findings.

Scan outcomes can also become training data. At scale, vulnerability scanning should become a training loop, not only a discovery pipeline. Each MDASH run produces signals that can improve future models: true-positive and false-positive verdicts, duplicate findings, failed reachability claims, reviewer feedback, verifier results, severity assessments, patch outcomes, and regression-test evidence. Capturing those signals with the code context and causal argument behind each candidate creates the dataset needed for reinforcement learning and fine-tuning specialized cyber models. The goal is for future models to learn not just what a vulnerability looks like, but which findings survive validation, which explanations help humans and provers act, and which patterns lead to useful remediation.

Spend reasoning to remove uncertainty, not simply to produce more analysis.

Shift 3. Validation and remediation as a continuous learning loop

Validation and remediation are not downstream cleanup; they are part of the discovery loop. Each candidate should move through automated verification, human review, patch development, and regression testing, with every stage returning evidence to the system. A reproducible trigger strengthens the report, guides the fix, and can seed a regression test. A failed validation is also useful when it records why: an unreachable path, missing precondition, incorrect build configuration, insufficient attacker control, duplicate report, or incomplete causal explanation.

That evidence is how the system improves. Project-specific provers, harnesses, and trigger generators accumulate operational knowledge about how each target builds, runs, fails, and accepts fixes. Remediation outcomes show the discovery pipeline which evidence changed a decision, which assumptions failed, and which bug patterns warrant more or less attention. The objective is to make every investigation leave reusable capacity behind: a validated trigger, clearer invariant, better harness, stronger regression test, or routing rule that prevents the same mistake.

Human attention remains essential, but it should concentrate where judgment has the highest leverage: assessing security impact, reviewing patches, and determining whether a change restores the component’s intended invariant. Automation can handle the repeatable work of establishing reachability, reproducing behavior, and preserving evidence. Over time, this loop converts individual findings into system knowledge—raising the quality of future discovery while shortening the path from credible report to shipped fix.

A reproducible defect is not yet a serviced fix. To shorten the path from discovery to remediation, MDASH needs to operate as part of the engineering loop: continuously scanning code, connecting findings to the builds and artifacts produced by continuous integration and continuous delivery (CI/CD), and feeding validation results back into development, as described in the Windows team’s blog post. Broad analysis can identify suspicious code paths, but component-specific proving needs the right binaries, symbols, configurations, harnesses, and runtime conditions to reproduce a candidate defect against the version that matters for customers and releases. Each handoff should be both owned and machine-usable: research supplies the candidate claim, causal path, and uncertainty; proving supplies execution evidence from the relevant build artifact; component teams assess the violated invariant, repair strategy, compatibility risk, and related variants; and servicing connects the approved change to release validation. A failed reproduction, rejected finding, incomplete patch, or regression result should feed back into MDASH as structured evidence, not simply move a ticket into another queue. The goal is not to remove human code review or release validation, but to automate the repeatable work around them—finding candidates, selecting artifacts, reproducing behavior, preserving evidence, suggesting related paths, and returning what was learned to the next scan.

The goal is to build an organization-wide system that automates repeatable work while preserving clear engineering accountability.

Transferring security research to help open source projects

In open source, all three constraints apply at once. Each project has its own setup costs, mix of analysis and execution work, and maintainer workflows and review capacity. Within Windows, vulnerability research connects to established component owners and servicing infrastructure. Across open-source projects, reusable methods can reduce repeated setup, but they cannot replace the technical and human context required to move a finding toward a fix.

Open-source vulnerability reporting snapshot

Over three months, FORGE members audited open-source projects spanning kernels, runtimes, networking libraries, container technologies, and media parsers. The team submitted 155 internally validated reports across 23 projects. At the time of writing, 93 reports across 14 projects or project families had documented maintainer acknowledgement or acceptance: apple/container, apple/containerization, curl, Escargot, FFmpeg, Hyperlight, Linux, llama.cpp, Node.js, PyRIT, Rust, SQLite, vLLM, etc.

Since the reports are at different stages of that process, only subsets are publicly disclosed today, such as curl’s CVE-2026-9545 and CVE-2026-13608, Node.js’s CVE-2026-56848, and Linux kernel CVE-2026-64563. Our public CVE index lists the CVEs currently cleared for disclosure, and you can find all our public channel Linux kernel reports through lore.kernel.org query.

Measured costs of automated validation

MDASH surfaced thousands of suspicious locations in the Linux kernel, and our validation agents produced supporting evidences for 627 findings. The figures below summarize automated validation costs for a subset of these efforts. Across 182 confirmed crash findings, generating a PoC averaged $3.61 in model cost and 21.5 minutes. For six selected cases, using automatic exploit generation (AEG) to test local privilege-escalation potential averaged $8.56 and 25.4 minutes.

These evaluations used GPT-5.5, without extensive task-specific tuning of either the model or the harness. These averages include all attempts associated with the successful cases shown, but exclude initial screening, candidates that failed or were filtered out, and human investigation and patch preparation. Within those limits, the results still strongly indicate that automated validation can produce useful results at practical cost and latency, even at Linux-kernel scale. Tighter co-design of models and agent harnesses could improve both validation yield and efficiency. If costs fell by another order of magnitude, for example, 10x or even 50x, the range of findings that could be economically validated would expand substantially, further reshaping vulnerability research.

FORGE OSS Bug Hunt Party: Human coordination at scale (Hackathon)

Looking back to those efforts, technical evidence was only part of the job. Getting it fixed also required understanding and respecting each project’s context and workflow: some required a patch while others did not; some preferred private disclosure while others used public channels; and maintainers sometimes differed on whether an issue crossed a security boundary. In practice, this meant adapting to each project’s submission requirements, working with maintainers to reproduce the issue, and, where applicable, refining and retesting a proposed fix. As AI-assisted discovery increases report volume, open-source security research can scale only if research teams absorb the resulting complexity rather than pass it on to maintainers.

Scaling this work also requires more developers who understand the full security workflow. At Microsoft’s annual Hackathon, we hosted the FORGE Open Source Software (OSS) Bug Hunt Party (Project Sunshine) as a forum where developers across Microsoft could exchange security research practices and gain hands-on experience with vulnerability investigation, validation, and responsible reporting. With MDASH and supporting guidance, 50 participants produced 39 reports across six projects, including Microsoft’s open-source Hyperlight project, Linux, vLLM, Gemini CLI, and llama.cpp. Those 39 reports are included in the 155-report snapshot above. Project Sunshine has continued beyond the Hackathon as a forum for open-source security collaboration within Microsoft.

Akrites: Coordinated effort to remediate vulnerabilities

Akrites is a Linux Foundation initiative that coordinates confidential remediation and disclosure for vulnerabilities in critical open-source software. FORGE has submitted nine Linux findings with internally assessed common vulnerability scoring system (CVSS) scores above 7.0. Together with submissions from other participants, including Google, these cases helped test and refine Akrites’ early Coordinated Vulnerability Disclosure (CVD) workflow. One of those reports was the first Akrites submission to result in a patch merged into the Linux kernel. FORGE will keep contributing to those responsible disclosure efforts.

The work also showed that a systematic approach is not just a larger scan. It is a repeatable path from a finding to an upstream fix and coordinated disclosure. Each case needs reproducible evidence, a clear causal explanation, a severity assessment, and an understanding of which downstream projects may be affected. The right owners and collaborators can then be brought in at the right time and on a need-to-know basis.

What’s next for FORGE Lab?

In a matter of months, FORGE Lab has helped discover Windows vulnerabilities and assigned 140 CVEs, including 52 in September 2026’s security release. Beyond Windows, FORGE submitted 155 internally validated reports across 23 open-source projects—93 of which had documented maintainer acknowledgement or acceptance at the time of writing—and one of our Linux reports became the first Akrites submission to result in a patch merged into the Linux kernel. Our Linux kernel results also indicate that automated validation can work at practical cost, with proofs of concept averaging $3.61 in model cost and 21.5 minutes per successful case. The lesson behind those numbers: once agents can find difficult bugs, progress depends on the system around them, how it scales, where it spends reasoning, and how quickly it turns discoveries into validated fixes.

These three lessons are becoming foundational guidelines for FORGE’s next phase of research:

1. Moving from frontier capability to scale means measuring the full pipeline, not just the number of findings: candidate arrivals, duplicates, rejected reports, validated defects, queue age, unresolved cases, and time through each stage.
2. Moving from token consumption to reasoning economics means evaluating model and execution cost alongside human review time, and asking whether each additional pass removes uncertainty, improves coverage, or produces independently validated findings.
3. Moving from isolated discovery to continuous validation and remediation means tracking reproduction success, patch rework, regression evidence, and elapsed time from validated defect to approved fix and release.

For security leaders evaluating AI-powered vulnerability discovery, these are useful measures too: count validated fixes, not just findings, and weigh model cost alongside the human review time it takes to act on them.

The next advance won’t come from a better model alone. It will come from research systems that combine frontier capability, systems engineering, and reasoning economics, focusing machine reasoning and human attention on turning credible findings into validated fixes.

Our team is growing. Check out our open positions at FORGE Lab.

Further reading:

• Defense at AI speed: Microsoft’s new multi-model agentic security system tops leading industry benchmark.
• Beyond the benchmark: Advancing security at AI speed.
• Evolving Windows vulnerability management to meet the speed of AI-powered discovery.
• From research to reality: An interview with Microsoft VP of Security Research Taesoo Kim.
• Microsoft Security FORGE Lab.
• Berkeley Vulnerability Initiative—Agentic Vulnerability Coverage Map.
• Akrites | Patch the Commons, Together.
• Introducing MAI-Cyber-1-Flash inside MDASH | Microsoft AI.

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

The post 3 lessons from frontier AI vulnerability research appeared first on Microsoft Security Blog.

The more challenging question is what happens after the scan? Frontier AI models are about to hand every security team a far larger set of findings than they have ever had to work through. The real test for chief information security officers (CISOs) and IT security leaders is not how fast they can patch. It is whether they can keep the balance between patching quickly and patching correctly, at a scale no human review process was built for.

This shift creates both new challenges and new opportunities. The same AI capabilities accelerating cyberattackers are also enabling defenders to identify exposures earlier, automate remediation, and build more resilient security programs.

Not every vulnerability will be patched in time, so the controls that limit what an attacker can do by defense in depth matter more than ever. CISOs can dramatically improve the security posture of their Microsoft infrastructure by deploying Microsoft Baseline Security Mode (BSM), building on how Microsoft protects Microsoft.

How do frontier AI models change vulnerability management for CISOs?

Microsoft uses frontier AI models to find vulnerabilities in its code base and mitigate them at controlled pace. Potential vulnerabilities are reviewed on validity, severity, and potential impact. As we have explained in previous blogs, many steps in our vulnerability handling and disclosure processes now are AI-powered, allowing them to scale.

Most vulnerabilities in cloud software are being mitigated by Microsoft without customer intervention. For on-premises Microsoft software, customers should continue to expect a substantial increase in the number of vulnerabilities released on Patch Tuesdays relative to historic volumes before the advent of frontier AI models earlier this year—September 2026 saw a record number, close to 1,000.¹

Due to the non-deterministic nature of AI models, different runs by the same model or with different models may yield different results. With better models becoming available over time, AI-powered vulnerability scanning of our existing code base and new code should become part of our standard security assurance.

We use a ‘harness’ layer around AI models in vulnerability scanning for better results. This layer controls how models access code, validate outputs, and integrate findings into triage and remediation workflows. Microsoft has expanded the use of harnesses in scanning its code bases across all the engineering groups. One of these harnesses, codename MDASH, has now also been made available to customers. In addition to AI-powered vulnerability scanning, our internal Red Teaming engagements now leverage AI, enhancing the team’s capacity to find weaknesses in controls and boosting the efficiency and speed of the operations.

What can CISOs do to mitigate the risk of vulnerabilities to their organization?

How can CISOs prepare for what’s coming, as new AI models in the hands of threat actors increase the risk and pace of cyberattacks using unknown or unpatched vulnerabilities?

1. CISOs should increase the resources allocated to Microsoft on-premises software patching, prioritization, and timing as they should continue to expect a high volume of patches on future Patch Tuesdays, at least over the coming period.
2. CISOs should rethink patch timing for their most critical systems. Traditionally, critical components such as domain controllers and edge devices have been patched when downtime is least disruptive, such as weekends or holidays. As AI shortens the time between patch release and exploitation, that trade-off may need to change. Consider deploying fixes to these systems within 24 hours rather than waiting for the next maintenance window.
3. CISOs should use harnesses to scan and remediate vulnerabilities in the code base of their organizations. They should do so without delay, rather than wait for access to frontier AI models. They should allocate appropriate resources for tokens and human resources to triage and remediate bugs.
4. CISOs should focus, more than ever, on defense-in-depth and monitoring of the state of health of their critical controls. As governments and regulators around the world raise expectations for cyber resilience through legislative frameworks, these authorities are compelling organizations to strengthen their security posture, operational resilience and regulatory readiness. Extensive guidance can be found in a new Microsoft Security Exposure Management page with capabilities customers can use to act.

Microsoft helps by tackling open-source vulnerabilities with industry peers

Many organizations use open-source software in their infrastructure or their products. As governments and regulators increase expectations around software security, the ability to find and fix open-source vulnerabilities is becoming more important, but many open-source maintainers don’t have the tools or resources to respond quickly, which increases supply chain risk in the face of AI-supported vulnerability discovery.

Microsoft has teamed up with industry peers to coordinate the scanning and patching of vulnerabilities in critical open-source components before cyberattackers find them. Participating organizations are pooling resources to prioritize and scan open-source packages and remediate in cooperation with the maintainers.

Microsoft helps by offering Secure by Design and Secure by Default to customers

The implementation of defense in depth by organizations worldwide can be vastly improved by implementing baseline security controls by default across their estate. The implementation of Secure by Default requires to carefully balance useful features and fast innovation with security controls and guardrails. Microsoft is committed to implementing Secure by Design and Secure by Default across its products, thereby removing part of the burden of implementing critical controls from customers. See our latest Secure Future Initiative (SFI) report for more details.

With Secure by Design, security comes first when designing a product or service. Customers do not need to opt in and cannot opt out. Recent examples where we have implemented Secure by Design changes in Microsoft products are:

• Mandatory multifactor authentication for Microsoft Azure administrators.²
• Enforcing Conditional Access policies to Windows Hello for Business and macOS Platform single sign-on (SSO) registration.³
• Secure-by-design under the hood in Azure.⁴

Secure by Default means that security protections and secure configurations are enabled by default, requiring no extra effort. Recent examples where we have implemented Secure by Default changes in Microsoft products are:

• Azure Backup soft delete enabled by default.⁵
• Azure VNet default outbound access disabled.⁶

Customers can opt out of certain controls if they accept a higher risk posture. Customers may also create a better risk posture by opting in to more demanding or more sophisticated controls.

CISOs can dramatically improve the default security posture of their Microsoft infrastructure by deploying Microsoft Baseline Security Mode (BSM). BSM helps organizations to implement and monitor secure configurations at scale, based on “How Microsoft protects Microsoft.” Scenario analyses are available to assess the impact of additional controls in existing tenants, allowing a staged and controlled rollout. Controls can be turned on and off, and exceptions can be made and removed.

Microsoft Baseline Security Mode is available to existing customers within their current license agreement. We highly recommend CISOs to use BSM to increase the defense-in-depth of their existing infrastructure. New Microsoft customer tenants will come with BSM controls gradually implemented by default.

Final notes

The advent of frontier AI models to discover and exploit vulnerabilities creates both risks and opportunities. Responsible use of these tools allows us to secure the software that we built in the past and mitigate exposure in the future in a way not possible until now.

Microsoft will continue to use the latest technologies to find and correct vulnerabilities in existing code and to avoid vulnerabilities in future code, to decrease the likelihood of exploitation. It will also extensively use AI to protect its own infrastructure and the infrastructure of its clients.

For CISOs, the bottom line remains that risk-based management of cybersecurity is the cornerstone of our defense. AI and the principles of Secure by Default have become an integral part of this approach.

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

¹September 2026 Security Updates, Microsoft.

²Azure mandatory multifactor authentication: Phase 2 starting in October 2025, Microsoft Azure blog. September 5, 2025.

³Protect security info registration with Conditional Access policy, Microsoft Learn.

⁴Azure IaaS: Defense in depth built on secure-by-design principles, Microsoft Azure blog. May 4, 2026.

⁵Secure by Default with Soft Delete for Azure Backup, Microsoft Learn.

⁶Default Outbound Access in Azure – Azure Virtual Network, Microsoft Learn.

The post CISO perspectives on managing vulnerability risks in the age of AI appeared first on Microsoft Security Blog.

We see that across the report. Threat activity can span infrastructure, identities, applications, cloud environments, and software supply chains. AI systems and agents increasingly interact with data, tools, and business systems. And activity that looks incomplete in one part of an environment can become clearer when separate signals are considered together. That makes the connections across an environment increasingly relevant to how we understand both cyberthreats and defense.

The pace of change also matters. AI models are becoming more capable, automation is expanding, and new connections are forming across the systems organizations rely on. These developments can change the speed and scale of security activity even as the underlying security fundamentals remain familiar.

Several findings in this year’s report illustrate that.

AI in the threat landscape

Threat actors are incorporating AI into reconnaissance, social engineering, malware and exploit development, and post-compromise activity. For now, much of their use remains focused on specific parts of existing attack workflows, even as more advanced applications of AI continue to develop.

AI can give threat actors greater speed, scale, and ability to tailor activity more efficiently. We see that in social engineering, where AI can make campaigns more targeted, and in technical work, where automation can compress parts of the attack process. The underlying methods often remain familiar. People, identities, exposed systems, and trusted access continue to feature prominently in the threat activity Microsoft observes.

AI is also becoming more connected to the systems and processes organizations already rely on. That brings another dimension to the security work.

Securing AI as part of the enterprise

Agents are a good example of these observations. They can interact with enterprise data, applications, APIs, and tools, with different levels of access and autonomy depending on how they are designed and deployed. Those connections are what allow agents to perform useful work, and they are also part of what security teams need to understand.

That makes it increasingly important to look at AI as part of a broader system. A model may be one component, but its security also depends on the data it can reach, the tools it can use, the identities and permissions involved, and the infrastructure and services around it.

The report looks at agent identity, appropriate access, authentication between agents, attribution, and the ability to revoke access. It also examines security considerations specific to AI, including prompt injection, memory, models and data, agent behavior, and the integrity of software and services around AI systems.

There is a lot we are still learning as these technologies develop. Security teams do have a strong foundation to build from. Identity and authorization, data protection, least privilege, monitoring, testing, and secure software development all remain relevant. AI puts those disciplines into new systems and increasingly connected workflows.

AI and vulnerability discovery

Advances in the application of AI toward code analysis are making it possible to examine software and identify weaknesses more effectively. That creates new opportunities to find vulnerabilities earlier and strengthen software before weaknesses are exploited. Those same advances can give threat actors more capable tools for vulnerability discovery and exploit development.

This is an important area to watch as capabilities develop. AI is giving defenders new ways to find and address weaknesses while giving cyberattackers new ways to look for them. The work on both sides continues to advance.

Connecting what defenders know

The same interconnectedness that shapes how activity moves across systems also shapes how defenders understand it. Security teams work with information from endpoints, identities, cloud environments, applications, email, networks, and threat intelligence. The report shows why those signals become more useful when they can be considered together. Threat activity spanning several systems may leave a pattern that no individual source shows on its own. In a more connected environment, the ability to relate activity across systems becomes an important part of understanding what is happening and where attention is needed.

The same principle extends beyond an individual organization. Trusted sharing of intelligence and information across organizations and public-private partnerships can connect pieces of activity that no one organization sees on its own.

AI can help with that work. Established techniques and repeatable tasks are increasingly candidates for automation, including bringing relevant information together and giving experienced defenders more capacity for deeper investigation.

The discussion of red teaming in this year’s report captures the balance well. Connecting known information and running established techniques can increasingly be automated. Finding an undocumented attack path, or recognizing how weaknesses that appear unrelated fit together, continues to benefit from experienced operators staying close to the work.

That balance will continue to evolve. There is substantial opportunity to use AI to help defenders work more effectively while preserving the human judgment, context, and expertise that remain essential to security work.

The 2026 Microsoft Digital Defense Report looks across the threat landscape, cybercrime, resilience, and the relationships among technologies, identities, systems, and people. Taken together, those findings give us a broader view of the increasingly interconnected environment security teams are responsible for understanding and protecting.

I encourage you to read the full report for a deeper look at the findings, data, and recommendations from Microsoft’s security and threat intelligence teams.

Read the 2026 Digital Defense Report for the full findings, data, and recommendations.

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

The post Insights from the 2026 Microsoft Digital Defense Report  appeared first on Microsoft Security Blog.

Dwell time, the period between when an attacker gains access and when defenders detect and stop them, also increased this year across multiple sectors. While organizations responded faster once an intrusion was identified, detecting threats early remains a challenge. Attackers increasingly gain access through techniques that mimic legitimate activity, making malicious behavior harder to spot. For example, phishing accounted for 23% of observed intrusions in 2026, up from 7% in 2025, highlighting the continued importance of compromised identities as an entry point for broader attacks.

Taken together, the implication for governments is clear. Security in the AI era is no longer simply about preventing individual intrusions. It is about ensuring institutions can operate effectively in an environment where risks are interconnected, threats move faster, and attackers remain hidden longer. Public-private partnerships are also more important than ever for securing critical government infrastructure and developing the policies and regulations needed for emerging technologies.

In this year’s report, which examines cyber threat trends observed between July 2025 and June 2026, Terrell Cox, Microsoft’s Corporate Vice President & Deputy Chief Information Security Officer, and I explore how these dynamics are reshaping cyber risk. In a companion blog, Terrell takes a closer look at what these findings mean for CISOs and security professionals.

To strengthen resilience, governments should focus on five priorities:

1. Prepare for a faster threat environment
   AI is compressing the window for action. Adversaries are moving faster. A vulnerability’s discovery in the wild to active weaponization can be well below 24 hours. While the number of publicly disclosed software vulnerabilities (commonly tracked as CVEs) is projected to reach a record 72,000 in 2026.

Governments best prepared for the future will be those that can rapidly gather and assess information, make decisions, coordinate across institutions and industries, and communicate effectively during a crisis. This requires clearly defined responsibilities and trusted relationships established before an incident occurs, enabling swift and coordinated action when it matters most.

2. Build security into the AI ecosystem
   AI is becoming part of the infrastructure that governments, businesses, and citizens rely on every day. As governments continue to adopt AI across public services and encourage its broader use, they should approach its security as a resilience challenge rather than a narrow technical issue.

AI systems depend on interconnected infrastructure, data, models, applications, suppliers, and governance processes. Governments should promote security across this ecosystem through secure-by-design practices, testing and evaluation, stronger supply chain protections, transparency, accountability, and international cooperation on AI risk.

The goal is not to create a separate AI security agenda. It is to integrate AI security into broader efforts to protect critical infrastructure and build national resilience.

3. Plan for incidents to spread
   Governments may not immediately know whether an intrusion is criminal, geopolitical, or something else. Cybercriminals and nation-state actors pursue different objectives, but increasingly rely on many of the same entry points, including compromised identities, exposed applications, social engineering, and legitimate administrative tools.

Microsoft found that 52.2% of intrusions involving valid accounts resulted in additional credential theft, highlighting how quickly attackers can expand beyond an initial foothold. A seemingly isolated compromise can evolve into ransomware, espionage, data theft, or disruption of essential services.

Governments should therefore assess incidents not only by how they begin, but by where they could lead. Response plans should account for the suppliers, partners, and service providers supporting critical functions. As attacks expand beyond their initial targets, they can also cross organizational, sectoral, and national boundaries, reinforcing the need for global collaboration.

4. Enable timely, two-way public-private information sharing
   A compromised account at one organization may provide early warning of a broader campaign. Signals that appear inconclusive in isolation can reveal coordinated activity when combined across organizations and jurisdictions. Modern cybercrime operates through interconnected networks of actors, services, and infrastructure that no single institution can fully see or disrupt on its own.

Information sharing must be timely, trusted, and two-way—also known as bidirectional. The goal is not simply for companies to report threats to government. Public agencies should also return actionable intelligence, guidance, and warnings that help organizations protect their networks, customers, and operations. Trusted channels can enable this exchange among government agencies, law enforcement, critical infrastructure operators, technology providers, and international partners while respecting legal and privacy requirements.

Policymakers can support this cooperation through protections for good-faith information sharing, common anonymization standards, and investment in shared threat intelligence and detection capabilities. Information sharing should also lead to action, including investigations, disruption efforts, and accountability for those responsible for serious cyber intrusions.

5. Prepare essential services to operate through disruption
   The organizations governments depend on to deliver public services, including transportation systems, communications infrastructure, schools, universities, and critical infrastructure operators, are increasingly targeted by cyber threats. Resilience therefore requires understanding not only government systems, but the broader ecosystem that supports them.

Planning documents alone are not enough. Governments should regularly conduct tabletop exercises bringing together policymakers, operational leaders, law enforcement, critical infrastructure operators, and private-sector partners to test how they would respond to incidents disrupting essential services. These exercises can expose gaps in decision-making, information sharing, public communications, and cross-sector coordination before a real-world crisis. Microsoft’s work through initiatives such as the Advancing Regional Cybersecurity (ARC) program, most recently in Kenya, illustrates how scenario-based exercises and cross-sector collaboration can help strengthen preparedness and response capabilities across the broader ecosystem.

Government leaders should also know which services are most critical, which identities, systems, suppliers, and infrastructure support them, and how incidents will be escalated. Shared-service approaches can help extend security and response capabilities to local governments and public institutions that cannot build them independently.

As cyber incidents cross organizational and national boundaries, resilience depends not only on technical preparedness, but on whether institutions can coordinate effectively under pressure.

In an era of AI-enabled and increasingly interconnected cyber threats, resilience is no longer simply about recovering from an attack. It is about preparing for a world in which cyber incidents move faster, spread further, and affect more organizations than ever before. Governments best prepared for the future will be those that can contain harm, adapt quickly, and continue delivering critical services when citizens need them the most.

The post Preparing governments for an era of interconnected cyber risk appeared first on Microsoft Security Blog.

In the agentic era, the stakes are higher: AI agents now act with real access to your identities, your data, and your cloud, so every adoption decision is a trust decision. That is why security is a through line at Microsoft Ignite 2026, from a Security Pre-Day before the event opens to a security segment in the keynote, and four security themes across all four days.

Join us in San Francisco from November 17 to 20, 2026, or online. See the Microsoft Security roadmap first, get hands-on with new agentic security solutions, and connect directly with the experts, partners, and peers who can help you make it real. This year we spotlight our AI-first, end-to-end security platform designed to protect identities, devices, data, applications, clouds, infrastructure, and the AI agents now working alongside your teams.

Why you should attend Microsoft Ignite

• Understand where Microsoft is placing its bets. See what is being announced, what is shipping next, and what it means for your architecture, your security operations center (SOC), and your governance model.
• Build skills you can use immediately. Technical breakouts run from level 200 to level 400, paired with instructor-led labs and onsite certifications, so you leave with implementation guidance rather than slideware.
• Pressure-test your plans with the people who built it. Bring your real architecture, deployment, and roadmap questions to Microsoft engineers, MVPs, and the product teams behind these tools.
• See the proof, not the promise. Customer stories, live demos, and partner solutions show what is already working in production today.
• Connect with the people who make it real. Expert meetups, connection pods, table talks, and evening events put you alongside security practitioners, leaders, Microsoft partners, and peers working the same problems.

Make the most of your time at Microsoft Ignite

Whether you join us in San Francisco or online, you will have access to a full slate of experiences designed to help you connect, learn, and grow as a security professional. Here is what is in store.

Start a day early at the Security Pre-Day

On Monday, November 16, 2026, from 1:00 PM PT to 5:00 PM PT, the Security Pre-Day gives you four hours with Microsoft Security leaders and external industry voices before the main event begins. Expect presentations paired with interactive roundtables and ask-me-anythings (AMAs) with our security experts, built for security decision makers and practitioners alike.

Select the Security Pre-Day option during Microsoft Ignite registration.

Hear the news first in the keynote and Innovation Session

The opening keynote runs Tuesday, November 17, 2026, from 10:00 AM PT to 12:00 PM PT at Chase Center and sets the direction for the week with Satya Nadella, Microsoft CEO, and Judson Althoff.

Later in the week, the Security Innovation Session goes deeper on the security news with executive-led demos.

Where the security community comes together

Microsoft Ignite is where the security community gathers. Beyond the sessions, you will find expert meetups, connection pods, and evening experiences created for security professionals and leaders.

Secure the Night

You are invited to Secure the Night on Tuesday, November 17, 2026, an evening bringing the security community together to connect, celebrate, and have some fun. Join fellow customers and Microsoft Security leaders for a night designed to make meaningful connections.

Interested in attending? Fill out the interest form to be notified when registration goes live.

Security and Agent 365 Neighborhood at Microsoft Hub

Bring your hardest questions to the people who build and defend with these products every day. Microsoft engineers, MVPs, and partners staff the Hub throughout the week. Experience hands-on demo, participate in community conversations and happy hours with industry experts. Also check out our Security Insider podcast recorded real time.

Partners and the Microsoft Intelligent Security Association

Microsoft Intelligent Security Association (MISA) members have a full week ahead at Microsoft Ignite. Beyond the partner-focused security sessions running throughout the event, the MISA Demo Station returns to the Expert Meetup Hub from November 17 to 19, 2026, where 15 of our MISA members will demo their solutions with customers on the show floor. Attendees can also catch five MISA partners (AdaQuest, Capgemini, Huntress, IBM, and Inforcer) live in theater sessions, sharing fresh security insights and solutions that are shaping the industry.

Thank you to our MISA partners Ascent Solutions, Avertium, BlueVoyant, Devicie, Huntress, Illumio, Mphasis, and RSM who are sponsoring the Microsoft Secure the Night party, each hosting an interactive activation on the party floor, and the week wraps with an exclusive MISA Happy Hour on November 19, 2026—a chance for MISA partners to network with fellow members and select Microsoft Security stakeholders. For information on registration for the MISA Happy Hour, please reach out to your dedicated MISA representative.

Explore the Security sessions at Microsoft Ignite 2026

Below are the four themes shaping this year’s Security track, along with a few sessions you will not want to miss. You can view the full catalog here and filter by topic, format, and role to plan your week.

Here is an overview of the Security tracks with some highlights of our top sessions.

Defend with AI

Security operations are being rebuilt around agents. This track covers what changes when AI can not only analyze but act, and how the SOC’s operating model, data foundation, and response playbooks have to evolve to keep pace.

Sessions to watch for

• The Alert Is Dead. The Blueprint for the Agentic SOC, which maps what replaces alert-centric operations end to end.
• The Agentic SOC Reality Check: Market Hype vs. AI Models vs. Automation, a real-time architectural breakdown with no slides and no canned speeches.
• Winning the Race Against Time with Autonomous Protection, on how AI is changing the economics of cyberattacks and how to compress your response window.
• Turn signal into real-time protections with Project Perception, a hands-on lab in agentic security.

Also in this track: threat intelligence at AI speed, AI-powered endpoint vulnerability discovery and remediation, attack disruption, finding and fixing code vulnerabilities with codename MDASH, and building the security data foundation the agentic SOC runs on.

Secure AI

Your organization is already shipping agents. This track is about seeing them, governing them, and protecting them from code to runtime, across the identities they use and the data they touch.

Sessions to watch for

• When AI acts, security has to answer: Microsoft Security for AI, the platform view of securing agentic AI.
• Inside look: Microsoft Security as customer zero for Agent 365, covering what we learned running it ourselves.
• Local agents are here. Can you find and secure them?, paired with a companion lab on end-to-end threat protection for local agents.
• AI Agents Are Scaling. Are Your Access Controls Ready?, a peer discussion on identity for non-human actors.

Also in this track: prioritizing and remediating your riskiest agents, a Zero Trust approach to securing AI runtime with Microsoft Defender, data protection and governance for agents with Microsoft Purview, securing Microsoft 365 Copilot and Cowork, and turning AI security research into deployable defenses.

Get Ready for AI

Before you scale AI, the fundamentals have to hold: identity, device and app trust, data hygiene, exposure management, and Zero Trust. This track is the practitioner’s path to an AI-ready security foundation.

Sessions to watch for

• Build secure foundations to scale AI across your organization, the anchor session for this track.
• Identity Knows What Your SOC Doesn’t: Stop Threats Faster Together, on closing the gap between identity and security operations.
• Can’t Phish a Passkey. But Can You Prove Who’s Behind It? and SMS MFA Is Dead. What Comes Next?, a pair on the state of phishing-resistant authentication.
• Zero Trust for AI workshop, a hands-on lab with a companion lightning talk, Apply Zero Trust for AI: the practitioner’s shortlist.
• Insights from Microsoft’s journey to prepare its data for AI adoption, on what it actually took internally.

Also in this track: reducing exposure across your digital estate, a single policy model for humans and agents, protecting cloud and container applications from code to runtime, getting privileged access right, and getting more out of the E5 you already own.

Secure Data

Data is the substrate AI runs on, and the thing cyberattackers are after. This track is about discovering, classifying, and protecting sensitive data across clouds, devices, AI apps, and agents.

Sessions to watch for

• Microsoft Purview: Build the Trusted Data Foundation for AI, the place to start.
• Strengthen and Manage Data Security Posture with Microsoft Purview, on data security posture management in practice.
• Deploy Copilot with confidence: Find and protect exposed sensitive data, a hands-on lab to run before you turn Copilot loose.
• Microsoft Purview AMA: Preparing Your Data for Secure AI, where you can bring your questions to the product team.

Also in this track: closing exfiltration gaps with data loss prevention, and turning global regulatory requirements into operating controls.

Choose the session format that fits how you learn

• Breakout sessions run 45 minutes at level 200 to 400, led by experts with live demos and real architecture. They are the technical core of the Security track.
• Theater sessions are 25 minutes of fast, demo-driven content in the Hub, designed to show rather than tell.
• Lightning talks are 15 minutes in intimate mini-theaters, built for curiosity, questions, and quick insight.
• Table talks are 45-minute, small-group technical discussions on real-world challenges and trade-offs, moderated by Microsoft subject matter experts.
• Hands-on labs are 75 minutes, instructor-led and proctor-supported, in a live environment. RSVP is required and labs fill fast.

Build your schedule

Do not miss your chance to be part of Microsoft Ignite. Explore the full session catalog, filter by topic, format, and role to plan your week, and register today to connect with the global security community and get hands-on with the latest innovations.

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

The post ​​Secure what’s next: Your guide to Microsoft Security at Microsoft Ignite 2026 appeared first on Microsoft Security Blog.

Microsoft Security Research has identified malicious cloud activity associated with JADEPUFFER, a threat actor discovered by Sysdig in July 2026 and reported to be the first documented agentic ransomware operation. Our investigation found an extensive Azure-focused resource destruction activity using compromised service principals and cloud credential collection that could be used to facilitate future exfiltration.

These findings expand the publicly documented activity associated with JADEPUFFER, tracked by Microsoft as Storm-3168, demonstrating an evolution in the threat actor’s cloud operations and providing the first detailed view into its Azure activity. We identified bulk destructive operations in a compromised Azure environment. The destructive operations were facilitated by compromising service principals and targeted Azure Storage Accounts, SQL databases, Key Vaults, Function Apps, recovery protection locks, Virtual Machines, and App Services.

Organizations can reduce exposure by protecting workload identities and secrets, enforcing least privilege, safeguarding recovery resources, and enabling relevant Microsoft Defender for Cloud protections. Publicly exposed credentials remain usable until revoked or rotated; removing the original disclosure alone does not remediate the exposure.

This activity highlights a broader shift toward AI-orchestrated attacks, where threat actors can coordinate complex post-compromise operations across cloud environments with greater speed and scale. As these capabilities evolve, defenders must similarly use AI to investigate and respond across large environments. Rather than requiring analysts to manually follow each individual action, efforts such as Project Perception and MDASH are intended to support a model in which defenders can investigate and respond across increasingly large and complex environments using AI.

Attack overview

Microsoft observed two compromised service principals belonging to the same tenant. One performed reconnaissance and resource discovery. The other performed discovery, destructive operations, and credential collection.

Discovery before destruction

For the impacted tenant, in early June 2026, one of the compromised service principals enumerated Azure Virtual Machines, subscriptions, resource groups and resources for about 15 hours and 30 minutes with 300+ successful read operations. This breadth of activity would give the threat actor visibility across the organization’s Azure environment.

About 90 minutes after the first compromised service principal started enumeration, the second compromised service principal enumerated virtual machines and resource groups across two subscriptions in five seconds. Both service principals used Storm-3168 linked infrastructure, the same network fingerprint, and the user agent python-requests/2.34.2.

16 hours later, the second service principal successfully enumerated Azure App Service configuration stores, possibly looking for exposed credentials. It also unsuccessfully attempted to look for Azure OpenSearch resources.

70 seconds after this final inventory operation, the same service principal also attempted a ListKey operation against a non-existent storage account.

A seven-minute destructive sequence

Less than one second after the unsuccessful ListKey operation against a non-existent storage account, the second compromised service principal began with its destructive activities. This compromised service principal then attempted 150+ destructive or credential collection related operations in 35 minutes.

The destructive sequence lasted for about 7 minutes. This involved 100+ storage account deletion attempts. Most Azure Storage accounts targeted by the threat actor were successfully deleted. However, Azure resource locks and storage account-level deletion protection blocked deletion attempts for few of the storage accounts, demonstrating the value of independent safeguards that remain effective even when a compromised identity has broad administrative permissions. An Azure Key Vault, Function App, App service plan were also deleted, all of which belonged to the same resource group and appeared to support the Function app.

The same service principal also attempted to delete multiple Azure SQL databases in parallel with the storage account deletions mentioned earlier, but every deletion attempt failed because it used an unsupported API version for the Azure SQL database resource type.

Multiple unsuccessful deletion attempts were also made against Azure Site Recovery locks and Azure Backup protection locks protecting storage accounts.

Credential collection

About 30 minutes after the final destructive activity, the same service principal made an inventory request for Azure Storage Accounts and sent 30+ successful ListKeys requests, asking ARM to return each storage account’s access keys. These storage accounts included Azure Site Recovery related storage accounts.

Technical analysis

Possible initial access

• Credential exposure: While it is unclear how the service principal was initially compromised, its client ID, client secret, and tenant ID had previously been exposed in plaintext in a public GitHub issue by an employee of the impacted organization. The issue was later edited to remove the secret, but the secret remained accessible through the issue’s public edit history. Removing or redacting an exposed secret does not invalidate it; credentials exposed in any public internet location should be treated as compromised and promptly revoked or rotated. We could not confirm whether this secret was used for the activity described here.
• Application Probing: Since the beginning of this year, we also observed repeated probing from Storm-3168 linked infrastructure against multiple Azure App services for different customers, against sensitive paths related to WordPress administration, PHP-CGI, LangFlow’s code validation endpoint (/api/v1/validate/code) and other web-shell like paths. However, the App Service targets did not overlap with the affected Azure subscriptions, and we found no App Service to ARM (Azure Resource Manager) credential path for the impacted tenant.

Coordinated automation

The timing between the different operations and the division of work using multiple service principals and overlapping token streams from the same service principal strongly indicates automated or scripted execution.

We observed five unique tokens issued for the service principal used for destruction and credential collection – four tokens supported deletion, while the fifth token handled storage inventory and key retrieval. Two of the tokens used for deletion were active during the same 70 second period. While one of these tokens focused on Storage account deletion, the other focused on a mixture of Storage and SQL deletion.

While the Key Vault, Function App, and App Service plan associated with the same application were deleted, a similarly named storage account in the same resource group was spared and later targeted by the compromised service principal through a successful ListKeys operation.

The operations followed the identity’s existing Azure role assignments. A group-granted Storage Account Contributor role authorized the destructive storage operations. Direct Contributor access authorized the three application-resource deletions and the one additional successful key retrieval. Direct SQL DB Contributor access authorized the multiple SQL deletion attempts, which were ultimately unsuccessful because of the unsupported API version used for the Azure SQL Database resource type.

Destructive activity indicative of a ransomware-aligned objective

The threat actor deleted numerous Azure resources, while also targeting backup and recovery related resources such as Azure Site Recovery locks or Azure Storage Accounts which had terraform and backup themed names, potentially intending to impair the victim’s ability to recover from the destructive activity.

The parallel targeting of Azure SQL databases and storage accounts suggests an effort to broaden the destructive impact across different data services rather than concentrating on a single resource type. Although the database deletions were unsuccessful, their inclusion in the same destructive sequence provides additional insight into the intended scope of the activity.

The compromised service principal also made multiple attempts to retrieve storage account keys, which could provide access to sensitive data.

Taken together, the resource destruction, attempts to interfere with recovery mechanisms, and collection of credentials that could provide access to data are consistent with tactics that can support ransomware and extortion operations.

However, we did not observe a ransom note or confirm successful data exfiltration in the activity described here.

Mitigation and protection guidance

Microsoft recommends the following mitigations to reduce the risk and impact of activity similar to that observed in this campaign:

• Enable appropriate Microsoft Defender for Cloud plans for critical Azure workloads. Consider enabling workload protections relevant to the resources in your environment, including Defender for Resource Manager, Defender for Storage, Defender for Key Vault, Defender for App Service and Defender for Databases. Learn more in the Microsoft Defender for Cloud overview.
• Protect and continuously assess application credentials and secrets. Avoid storing service principal credentials, storage keys, connection strings, and other secrets in source code, configuration files, public repositories, issues, or other locations where they might be inadvertently exposed. Learn more in the Microsoft Entra Workload ID documentation.
• Rotate compromised or exposed credentials immediately and establish credential lifecycle practices. Treat credentials that have been publicly exposed as compromised, even if the original location has subsequently been edited or deleted. Removing the content does not invalidate the credential or eliminate copies retained in edit history, caches, archives, logs, or other systems. Immediately revoke or rotate the affected credentials and investigate their historical use. Where supported, organizations should favor mechanisms that reduce reliance on long-lived credentials. Learn more about protecting secrets with Defender for Cloud.
• Apply least privilege to service principals and other workload identities. Review the Azure RBAC permissions assigned to service principals and restrict their privileges to the resources and operations required by their applications. Learn more about best practices for Azure RBAC.
• Protect backup and recovery infrastructure as part of ransomware resilience. Restrict access to backup and recovery resources and closely monitor attempts to modify or remove their protection controls. Learn more about Azure Backup security best practices.
• Scale investigation and response with agentic defenses. Use Project Perception to help defenders deploy AI agents that investigate and respond across large, complex environments at machine speed.
• Strengthen security posture for AI applications and agentic systems. Use Microsoft Defender for AI Security (codename MDASH) to discover AI assets, identify vulnerabilities and misconfigurations, and reduce exposure to AI-related attack paths.

Microsoft Defender XDR detections

Microsoft Defender XDR customers can refer to the list of applicable detections below.

Microsoft Defender XDR coordinates detection, prevention, investigation, and response across cloud endpoints, identities, email, and apps to provide integrated protection against attacks like the threat discussed in this blog. Customers with provisioned access can also use Microsoft Security Copilot in Microsoft Defender to investigate and respond to incidents, hunt for threats, and protect their organization with relevant threat intelligence.

Microsoft Security Copilot

Security Copilot customers can use the standalone experience to create their own prompts or run the following prebuilt promptbooks to automate incident response or investigation tasks related to this threat:

• Incident investigation
• Microsoft User analysis
• Threat actor profile
• Threat Intelligence 360 report based on MDTI article

Note that some promptbooks require access to plugins for Microsoft products such as Microsoft Defender XDR or Microsoft Sentinel.

Threat intelligence reports

Microsoft Defender XDR customers can use the following threat analytics reports in the Defender portal (requires license for at least one Defender XDR product) to get the most up-to-date information about the activity and techniques discussed in this blog. These reports provide intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.

• Microsoft Defender XDR Threat Analytics report on Storm-3168

Microsoft Security Copilot customers can also use the Microsoft Security Copilot integration in Microsoft Defender Threat Intelligence, either in the Security Copilot standalone portal or in the embedded experience in the Microsoft Defender portal to get more information about this threat threat.

MITRE ATT&CK Techniques observed

The following MITRE ATT&CK mappings reflect behaviors observed during this activity.

• T1190 Exploit Public-Facing Application | Storm-3168 linked infrastructure repeatedly probed sensitive application paths on applications hosted in Azure App Service for potential exploitation.
• T1078.004 Valid Accounts: Cloud Accounts | Compromised service principals were used for Azure resource discovery and destruction.
• T1526 Cloud Service Discovery | The identities enumerated subscriptions, virtual machines, resource groups, Azure Storage, Web Apps, App Service plans, locks, and Recovery Services.
• T1485 Data Destruction | Azure Storage, Key Vault, Function App, and App Service plan resources were deleted. Azure SQL deletion was also attempted, extending the destructive objective toward databases.
• T1490 Inhibit System Recovery | Site Recovery disk locks and an Azure Backup protection lock were targeted for deletion

Indicators of compromise (IOC)

References

• JADEPUFFER: Agentic ransomware for automated database extortion by Sysdig

Learn More

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog.

To get notified about new publications and to join discussions on social media, follow us on LinkedIn, X (formerly Twitter), and Bluesky.

To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.

Review our documentation to learn more about our real-time protection capabilities and see how to enable them within your organization.  

• Learn more about securing Copilot Studio agents with Microsoft Defender 
• Evaluate your AI readiness with our latest Zero Trust for AI workshop.
• Microsoft 365 Copilot AI security documentation
• How Microsoft discovers and mitigates evolving attacks against AI guardrails
• Prompt injection protection in Microsoft Defender for Office 365 – official documentation of the prompt injection protection in Microsoft Defender for Office 365.
• How Microsoft discovers and mitigates evolving attacks against AI guardrails | Microsoft Security Blog
• Manipulating AI memory for profit: The rise of AI Recommendation Poisoning | Microsoft Security Blog – a related example of an AI-era technique observed in email traffic
• Defending the inbox against prompt injection attacks | Microsoft Defender for Office 365 Blog – feature announcement introducing prompt injection protection in Microsoft Defender for Office 365.
• Learn how Microsoft is reimagining the SOC for the agentic era with ISOC in Microsoft Defender

The post Storm-3168: Agentic-driven cloud attacks using compromised service principals appeared first on Microsoft Security Blog.

Here’s what’s new:

Extend protection and support investigations with Microsoft Defender

Bring more context into email investigation and hunting with Microsoft Security Copilot

Available for organizations using both Microsoft Defender and Microsoft Security Copilot, a new email detonation summary delivers AI-generated explanations of URL and file sandboxing results, helping SOC teams investigate faster by reducing the manual effort required to correlate detonation evidence and contextual signals.

Protect sensitive data in motion with Microsoft Purview and Microsoft Entra

Stop sensitive data from reaching shadow AI over the network

Now generally available, Microsoft Purview and Microsoft Entra Global Secure Access bring data security to the network across human actions and on-behalf-of (OBO) agentic traffic. Context-aware Microsoft Purview classification and policies are enforced by Entra at the network layer. Organizations can discover sensitive files and text in real time and block them from being shared to risky destinations. For example, if an employee or OBO agent tries to upload a sensitive document to an unsanctioned AI tool, the policy can stop the transfer before the data leaves.

Protect, investigate, and clean up enterprise data with Microsoft Purview

Manage labeling at enterprise scale with less administrative overhead

Microsoft Purview auto-labeling helps organizations automatically apply data security controls to sensitive content at enterprise scale. New auto-labeling enhancements improve policy scale, admin experience, and reporting. Policies now support simulations of up to 20 million items and up to 50,000 sites through adaptive scopes. Administrators can edit a policy without re-running simulation. New audit insights and reporting show policy coverage and processing activity. Together, these enhancements help organizations scale auto-labeling across larger environments with less administrative effort.

Investigate content created in Copilot apps such as Microsoft Loop, Copilot pages through established compliance processes

Microsoft Purview eDiscovery now supports search, hold, review, and export content in user-owned SharePoint embedded containers, to help streamline eDiscovery processes for legal, regulatory, and internal investigations. Investigators can find content from AI-powered experiences, including Microsoft Loop, Copilot Pages, Copilot Notebooks, and applications, such as Outlook newsletters, mapped to a user without requesting the container URL from a SharePoint administrator. An optional HTML conversion produces a more readable version for downstream legal tools, improving the review and export experience for experts.

Archive and permanently remove inactive content to improve AI readiness

With Microsoft Purview Data Lifecycle Management, administrators can now archive inactive SharePoint content without archiving the entire site. Archived content remains subject to retention and legal hold policies, and remains discoverable for eDiscovery, while dropping out of Microsoft 365 Copilot indexing (until reactivated). Organizations can also use Priority Cleanup to permanently delete approved content, including stale Teams recordings and transcripts, so it is no longer discoverable in eDiscovery, SharePoint search, or Microsoft 365 Copilot. Together, these capabilities help organizations meet compliance regulations, including those in highly regulated industries.

Advanced endpoint management extends to GCC High and DoD with Microsoft Intune

Bring modern endpoint management to regulated environments

Microsoft Intune Enterprise Application Management, Microsoft Cloud PKI, and Intune Remote Help are coming to Government Community Cloud with High security needs (GCC High), with Enterprise Application Management also being offered to organizations of the Department of Defense (DoD). These capabilities help government and defense organizations simplify application management, modernize certificate lifecycle management, resolve device issues faster, and reduce total cost of ownership, all while operating within their accredited cloud environment.

Stay in the Loop

Microsoft Security continually ships meaningful innovations across our portfolio, as well as research-driven insights and reports for the security community. In the Loop posts are your reliable source of what’s new across Microsoft Security and what it means for your security strategy. Check back for the next drop.

And join us at Microsoft Ignite, from November 17 to 20, 2026, in San Francisco or online, to see Microsoft Security innovations in action and go hands-on with the team that built it.

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

The post ​​​​​​​​What’s new in Microsoft Security: September 2026​​ appeared first on Microsoft Security Blog.