Today, Microsoft published its 2026 Environmental Sustainability Report. This report covers our fiscal year 2025, and measures progress against our 2020 baseline. You can read the foreword below and explore the report in its entirety here. 

As we enter a new era for AI, Microsoft’s environmental sustainability work is entering a new phase—defined not only by ambition, but by how we deliver in a period of rapid technological change. In our pursuit of becoming a carbon negative, water positive, and zero waste company that protects ecosystems, the context has evolved, and so must our approach. 

The global shift toward AI is reshaping economies, accelerating innovation, and becoming foundational to how technology is built and used. It is also increasing demand for the energy, water, land, and materials required to support that growth. As a company at the forefront of this transition, Microsoft has a responsibility to help ensure that technology strengthens, rather than strains, the systems and communities on which it depends. This imperative is reshaping the context for our work. 

We are approaching this moment with clarity and conviction. We believe AI can deliver broad societal, economic, and environmental benefits, but innovation at this scale must be matched by responsibility at the same scale. For Microsoft, this means designing, building, and operating infrastructure that is more efficient, more resilient, and more grounded in the realities of the communities where we operate. 

We do not see these dynamics as a reason to step back. We see them as a mandate to lead differently. That requires greater operational rigor, stronger integration across our sustainability priorities, and a sharper focus on durable outcomes for the local communities where we work and the global value chains that make our work possible. It also requires being transparent about where progress is advancing, where it is more difficult, and where new approaches are needed. 

The path forward will not be defined by simple tradeoffs or single solutions. It will depend on how effectively we align innovation with stewardship. The systems we build to support the future must also support the long-term health of the planet and the communities we serve. Our experience makes clear that this is possible, but only with even greater discipline, partnership, and a willingness to learn and adapt as conditions evolve. 

What this moment requires 

Our aim is to build technology that gives more than it uses. Lasting progress depends on how we build it and whether that growth strengthens the places where it takes root.  

This thinking is reflected in our Community First AI Infrastructure approach, which is helping shape a more integrated model for community partnership, responsible operations, and environmental performance as we grow. In this way, sustainability is not separate from growth; it is part of how responsible growth is defined. 

While AI infrastructure is driving demand for energy, water, land, and materials, sustainability solutions are not scaling fast enough to meet demand. This tension is real, and it is also productive. 

It is forcing sharper questions: Where do we need to move faster, invest differently, or rethink our approach? Which assumptions still hold, which ones need to evolve? Five years into this work, we have more operational data, more direct experience, and a clearer view of what measurable planetary progress actually requires. That perspective helps keep us focused on outcomes rather than attached to any single pathway. 

We want to be clear about what this means—and what it does not. It means being more precise about what sustainability requires for Microsoft, and more willing to refine our strategies as conditions change, data improves, and tradeoffs become clearer. It does not mean we are lowering our ambition. 

Progress amid growth 

Our results reflect both progress and pressure. As we scale the physical infrastructure required to power the AI economy, our emissions are shaped by the impact of that growth and the actions we are taking to manage it. 

The visual that follows illustrates this dynamic by comparing our reported emissions with a modeled view of where emissions may have been in the absence of four specific interventions: carbon free electricity, sustainable fuels, XBOX console efficiency, and Surface device decarbonization. While these examples represent only a portion of our emissions reduction efforts, they highlight an important lesson from our work to date: that well-designed, targeted interventions can deliver measurable progress even as demand for infrastructure continues to rise.

In FY25, we matched 100% of our annual global electricity consumption with renewable energy^[2]. Microsoft will continue to push for an expansive focus on adding all forms of carbon-free electricity (CFE) ^[3] to the grids where we operate, complementing and building on our portfolio of renewable energy resources. We recognize that the world’s rising electricity needs require a balanced, all-of-the-above decarbonization strategy to meet global economic growth and environmental goals, and we will continue to support this approach moving forward.

Our total emissions (Scopes 1, 2, and 3) increased 25% year over year, driven primarily by the expansion of our datacenter infrastructure and pausing our use of non-additional, unbundled renewable energy certificates as we prioritize investments that bring net new power to grids. While this decision increases our reported emissions in the near term, it enables us to increase the development of new CFE rather than relying on certificates alone. We believe this change will create more long-term sustainability benefits. Growth-related emissions pressure was expected. The more important signal is where that pressure is concentrated. 

Scope 3 remains the largest share of our footprint overall, but one of the clearest changes this year was the growing contribution of Scope 2, which represents 13% of our total emissions—up from nearly 2% last year. This development highlights how important the energy systems across our supply chain are in shaping environmental outcomes. 

This year’s results also made clear that progress now depends on adapting how we work. 

Water is one of the clearest examples. In FY25, we replenished for the first time more water globally than we withdrew—more than 14 million cubic meters—marking a major milestone on our journey to become water positive. Reaching this point reflects years of work to improve water efficiency, expand replenishment efforts, and scale partnerships around the world. 

We are proud of this achievement but also know that replenishing global volumes is not enough. The next phase of our work is increasingly local. As we move forward, we are placing greater focus on helping restore more water to the watersheds where we operate than we withdraw while strengthening long-term water resilience. We prioritize projects in water-stressed regions that are locally relevant and designed in partnership with communities, delivering benefits not only for water availability, but also for ecosystems, economies, and people. Through this approach, we aim to ensure our growth supports and helps sustain the communities and environments where we operate. 

Transparency remains central to how we work and how we report. Microsoft has eliminated nearly all single-use plastics in our primary product packaging, reducing the share that remained to just 0.07% at the end of calendar year 2025.^[4] But we are not rounding down. We are staying accountable to the work required to eliminate them entirely. 

Across our cloud operations, we achieved 92% reuse and recycling of decommissioned servers and components for the second consecutive year, diverted 90.5% of construction and demolition waste from landfills and incinerators, and expanded our Circular Centers to seven facilities globally. These results also reflect a broader shift toward solutions that have co-benefits—reducing both emissions and resource demand over time. 

Throughout this journey, we have learned that progress in one area often depends on progress in another. Clean energy investments are essential to decarbonization. Water use is linked not only to our operations, but also to the energy systems that power them. And extending hardware life through circular approaches can reduce both emissions and material demand across the value chain. 

That is why our priorities extend beyond tracking progress against individual commitments on water, carbon, waste, and ecosystems as though they move independently. Our experience has made clear that progress does not happen pillar by pillar. Some of the most consequential work ahead will be measured in whether we address system challenges and help build the conditions for long-term progress: more resilient grids, stronger markets for lower-carbon materials, more effective water stewardship, and infrastructure designed and operated with local realities and community priorities in mind. 

For that reason, this year’s report takes a more integrated approach—placing progress against our commitments in the broader context of how those commitments are operationalized across our infrastructure and products. 

What’s next 

We are proud of what we have accomplished, and we remain humbled by the scale of the challenge ahead. Responsibly building the AI future requires clear accountability for what AI demands, candor about real constraints and tradeoffs, and sustained focus on outcomes that are durable and broadly shared. The chapters that follow show how we translate that intent into execution across our physical infrastructure, products, and value chain—where our sustainability commitments become operational reality.

Read the full report: https://aka.ms/SustainabilityReport2026 

[1] The solid line represents Microsoft’s reported greenhouse gas emissions (Scopes 1, 2, and 3) for FY20–FY25, prepared in accordance with GHG Protocol and management’s criteria, and uses a market-based emissions approach. The dotted line represents an illustrative counterfactual scenario of estimated emissions had select, discrete carbon reduction initiatives not been undertaken. These initiatives include energy efficiency improvements for XBOX consoles, renewable energy purchases, sustainable aviation fuel (SAF) and sustainable marine fuel (SMF) certificates, and supply chain decarbonization of Surface devices. The difference
between the two lines is an estimate of emissions avoided through these specific initiatives relative to a scenario without those initiatives occurring. This estimate is directional in nature, does not represent the full scope of Microsoft’s decarbonization efforts, and is not part of our reported greenhouse gas inventory. It should not be interpreted as a comprehensive measure of total emissions reductions or as additive to other carbon reduction or removal claims.

[2] Microsoft defines renewable energy as electricity that comes from sources that are replenished at a rate greater than or equal to their rate of depletion, such as geothermal, wind, solar, hydro, and biomass. To date, Microsoft’s renewable energy target includes two primary categories: renewable energy from contracted projects and grid mix. The first is renewable energy delivered under PPAs or similar long-term contracting mechanisms, generally for new projects where our financial involvement in the project’s development is critical for its success. This category represents more than 90% of the renewable energy applied to achieve our 2025 target. The second category is “grid mix” – renewable energy supported via our standard utility relationships and rates, inclusive of policy programs such as renewable portfolio standards and state and utility decarbonization goals. Our 2025 100% renewable target does not include purchases from short-term, so-called “spot market” renewable energy credits (RECs) sourced from operational clean energy projects.

[3] Microsoft defines carbon-free electricity (CFE) technologies as technologies with zero direct emissions and biogenic technologies with lifecycle emissions equivalent to renewables. CFE technologies include wind; solar; geothermal; sustainable biomass; hydropower; nuclear; fossil fuels with complete carbon capture, utilization, and sequestration; and storage charged with CFE generation.

[4] By weight, as designed, portfolio average. More details can be found in our Environmental Data Fact Sheet.

The post Responsibly building the AI future appeared first on Microsoft On the Issues.

In armed conflict, a simple symbol can save lives. The Red Cross, Red Crescent, and Red Crystal emblems signal that those providing medical care and humanitarian assistance must be protected. 

In cyberspace, there is not yet a widely adopted equivalent, even as hospitals, humanitarian organizations, and relief operations increasingly rely on digital systems to deliver care, coordinate assistance, protect sensitive data, and reach people in crisis. 

Today, the digital systems that support hospitals and humanitarian operations—including communications tools, logistics platforms, patient care systems, cloud services, and the data center infrastructure which underpins them—can be difficult to distinguish from surrounding digital infrastructure. In conflict, that raises the risk of misidentification, spillover, and cascading disruption from cyber operations. As cybersecurity operations become more automated and machine-driven, clear, trustworthy, machine-readable signals become even more important.

That is why Microsoft supports the International Committee of the Red Cross as it launches the next phase of the Digital Emblem initiative today in Geneva. The Digital Emblem is intended to provide a machine-readable way to help identify digital assets that support protected medical and humanitarian functions, so they can be recognized, verified, and avoided in conflict settings.

From principles to operational practice

The Digital Emblem does not create new legal protections, and it does not replace cybersecurity. Instead, it helps to make existing protections under international humanitarian law more actionable in cyberspace. 

For many years, governments, humanitarian actors, civil society, technical experts, and industry have worked to clarify how international law applies in cyberspace. These efforts have reinforced a core principle that civilians, medical services, and humanitarian operations must be respected and protected in armed conflict. But translating that principle into operational reality remains difficult when protected digital assets are not easily identifiable. 

The Digital Emblem can help bridge that gap. If implemented responsibly, a clearer, more consistent, and technically usable signal can support recognition, verification, and respect for protected medical and humanitarian functions in cyberspace. 

This next phase marks an important transition for the Digital Emblem: from concept development toward operationalization, testing, standards, and implementation. 

Over the past several years, the ICRC has worked with states, the Red Cross and Red Crescent Movement, technical experts, standards bodies, academia, and industry to explore whether the protective function of the physical emblems can be translated meaningfully into cyberspace. That work has helped move the Digital Emblem from an important idea to a project with growing legal, technical, and operational foundations. 

The work now is to test how the Digital Emblem can be deployed, discovered, authenticated, and verified in real-world conditions. It also means advancing standards work through bodies such as the Internet Engineering Task Force and the International Telecommunication Union, developing guidance for those who operate protected digital infrastructure, and engaging the actors who will need to recognize and respect the Digital Emblem in practice.

Building on Microsoft’s work to protect civilians in cyberspace

Across our cybersecurity work, we have consistently argued that protecting civilians and critical services in cyberspace requires more than statements of principle. It requires practical standards, technical implementation, trusted partnerships, and cooperation among governments, humanitarian actors, civil society, standards bodies, and industry. 

From our early calls for stronger norms of responsible state behavior in cyberspace, to the launch of the Cybersecurity Tech Accord, Microsoft has advocated for the application of international law and the protection of civilians online. 

Every day, Microsoft works alongside governments and partners to detect, disrupt, and defend against cyberattacks that target critical infrastructure, healthcare, and humanitarian operations. Together, we have seen the importance of real-time visibility, trusted signals, and coordinated defense across public and private actors. This work has underscored a central reality: as civilian and humanitarian services become more digitally dependent, cybersecurity is increasingly connected to humanitarian resilience. 

Microsoft will continue supporting the ICRC with a focus on how our technologies enable this model at scale. That includes exploring how technology can support both sides: enabling humanitarian and medical organizations to signal protected systems and helping defenders recognize and verify those signals in real-world operations.

The role of industry

The ICRC’s leadership is essential to the credibility and neutrality of this effort. But for the Digital Emblem to succeed, it must also work across the broader technology ecosystem, which includes the cloud services and data centers, telecommunications networks, cybersecurity tools, identity systems, and other digital infrastructure on which humanitarian and medical organizations increasingly rely.

Industry, therefore, has an important role to play in helping ensure the Digital Emblem is technically sound, interoperable, and aligned with how defenders operate in practice. That includes supporting standards development, helping test implementation models, and ensuring that any approach reflects both sides of the model: enabling eligible humanitarian and medical organizations to express the signal for relevant assets and helping defenders recognize and verify that signal in operational workflows. 

In today’s fragmented and low-trust geopolitical environment, shared technical standards can reduce ambiguity even where political agreement is difficult. That is why standards-based implementation can help make the Digital Emblem consistent, verifiable, and usable across networks, platforms, and borders.

From launch to implementation 

The launch in Geneva marks an important milestone, but the Digital Emblem’s promise will depend on what happens next. 

The work ahead should focus on clear and concrete outcomes: continued technical testing, progress in standards development bodies, practical implementation guidance, and broader engagement from states, humanitarian actors, technology companies, telecommunications providers, cybersecurity professionals, and operational defenders. 

The call to action is straightforward. Governments should support the Digital Emblem as a mechanism for making protected humanitarian and medical functions more identifiable in cyberspace and promote respect for it in policy and practice. Humanitarian and medical organizations should help test and shape implementation so it reflects operational reality. Standards bodies should continue building the technical foundations for trusted adoption. And technology companies should help translate the Digital Emblem into the tools, systems, and workflows defenders already use. 

Physical emblems made humanitarian protection visible on the battlefield. The Digital Emblem can help make protected humanitarian and medical functions visible, verifiable, and actionable in cyberspace. Turning that promise into practice will require sustained cooperation so that those who care for the wounded, the sick, and civilians can be more easily recognized, respected, and protected in the digital age. 

The post Making humanitarian protection visible in cyberspace: The promise of the Digital Emblem appeared first on Microsoft On the Issues.

In April we released Mewt, our open-source mutation-testing engine that finds the gaps in your test suite. Today we’re expanding it with support for DAML, the language Canton Network applications are written in. Mewt now reads DAML, generates several classes of mutants (including two built for DAML’s authorization primitives), and runs them through your existing test suite to count how many mutants survive. If you want to try it, simply install Mewt from the repository, point a mewt.toml at your project and its test command, and use mewt run.

For a team shipping DAML to production, that count is what a passing test run is actually worth: it puts a number on how much your suite checks, whereas a green run on its own does not.

Why DAML’s coverage reports lie

Test coverage is the most reassuring lie in smart-contract development. Hitting 100% line coverage tells you the test runner walked the code; it does not tell you whether any test would fail if that code stopped doing what it is supposed to. We have been grading test harnesses by how many mutants they kill since at least 2019, and our primer on finding the bugs your tests don’t catch shows how a green suite can still miss the bug that matters.

DAML’s built-in coverage measures execution at the template and choice level: which templates were created and which choices were exercised over the test run. It reports whether each choice was exercised, not what happened inside it. A test that exercises a choice once and asserts nothing about the result reports that choice as covered. The report prints the same green percentage whether the test verifies the outcome or discards it.

How mutation testing works

Instead of asking whether your tests reached the code, mutation testing grades your tests by sabotaging that code. The engine generates mutants, copies of the code that each carry one small deliberate change: a flipped comparison, a removed branch, a dropped party. It then runs your test suite against each one. A mutant that makes the suite fail is caught; a mutant that passes every test survives. Every survivor is a change your tests let through, and each one is either harmless or a potential bug. The harmless ones are equivalent code no test could distinguish or a branch no execution reaches, and you can set those aside. The rest are a to-do list: each one is a specific test you are missing, a case your suite should check but does not, occasionally with a real bug sitting behind the gap. The primer above describes a real audit where a mutation campaign surfaced a high-severity bug that the project’s tests had missed.

Mutation testing forces the unhappy path

A DAML contract encodes rights and obligations between named parties: who holds what, who owes what to whom, and who must authorize each step. A party is not an anonymous address. It represents a real organization or person, and the contract is the rulebook for how those parties interact, including which of them can take which action, what each is allowed to see, and what stays private between them.

Authorization is how that rulebook is enforced: who may take which action. It is also easy to get wrong in ordinary ways, such as a typo in a controller clause, a missing party, an extra one left over from a refactor. Every combination type-checks, so nothing rejects it before it ships. A static analyzer can flag suspicious patterns, but it has no way to know which party should hold which authority on your contract. That knowledge lives in your specification, and for most projects, the only executable form of the specification is the test suite. Happy-path tests supply every signature the contract asks for and confirm the transaction succeeds. They never try the negative case—removing a required signature and checking that the ledger rejects the transaction—so they never actually test whether that signature was required at all. If the tests don’t encode that rule, nothing downstream can recover it. Mutation testing is what tells you whether they do.

A green test run tells you your tests passed today. Mutation testing asks the harder question: would your tests catch a mistake, now or after the next code change? Where the answer is no, you have found a test case worth writing.

What Mewt adds for DAML

Mewt parses every language it supports with a tree-sitter grammar. As of mid-2026, there is no maintained tree-sitter grammar for DAML, so we reused the upstream tree-sitter-haskell grammar. DAML is Haskell-shaped, but its contract constructs (template, choice, controller, and signatory) are not Haskell, and the grammar parses them as error-recovered subtrees. That matters less than it sounds. The common mutations still work on DAML’s ordinary expressions, so Mewt swaps arithmetic and comparison operators, flips Booleans, and removes branches just as it does in any other language, with only small adjustments where DAML’s surface syntax differs (DAML writes /= where most languages write !=). We got most of the value of a from-scratch grammar without building one.

The new engineering went into DAML’s authorization primitives, where the authorization bugs from the previous section live. Mewt adds two DAML-specific mutations:

• Controller party swap (CPS in Mewt’s output): replace one party in a controller clause with another party that is in scope at that site.

• Controller party removal (CPR): drop one party from a multi-party controller list.

Both target the same question: if the set of parties allowed to exercise this choice silently changed, would any test fail? They are a deliberately small starting set aimed at the bug class above, and more DAML-specific mutations are in the pipeline.

Driving a campaign needs no new harness. A short mewt.toml names the files to mutate and the test command (dpm test for a Daml 3 project), and mewt run does the rest, reporting each mutant as caught or surviving. The setup is deliberately small: trying it on your own project costs minutes, and we encourage exactly that.

What a surviving mutant looks like

Picture a conditional payment between a buyer and a seller: the buyer sets money aside for the goods, and paying it out to the seller requires both parties to sign off. The buyer’s signature is the delivery confirmation. In DAML, that policy is one line: the controller line on the Release choice.

template ConditionalPayment
 with
 buyer : Party
 seller : Party
 amount : Decimal
 where
 signatory buyer
 observer seller

 choice Release : ()
 with
 paid : Decimal
 controller buyer, seller
 do
 assert (paid == amount)

A typical happy-path test creates the payment and has both parties approve the release. The actAs buyer <> actAs seller line submits the command with both parties’ authority:

testHappyPath : Script ()
testHappyPath = script do
 buyer <- allocateParty "Buyer"
 seller <- allocateParty "Seller"
 payment <- submit buyer do
 createCmd ConditionalPayment with
 buyer
 seller
 amount = 100.0
 submit (actAs buyer <> actAs seller) do
 exerciseCmd payment Release with paid = 100.0
 pure ()

The test passes, and by the usual measure the suite looks complete: running dpm test with coverage reporting enabled shows full coverage.

$ dpm test --show-coverage --coverage-ignore-choice Archive
testHappyPath: ok, 0 active contracts, 2 transactions.
- Internal templates: 1 defined, 1 (100.0%) created
- Internal template choices: 1 defined, 1 (100.0%) exercised

The --coverage-ignore-choice Archive flag deserves a word. Every DAML template automatically gets an implicit Archive choice. It is not part of the business logic under test, so we exclude it for simplicity. With it included, this one-choice template would report 50% even though the test exercises everything we wrote.

Run Mewt on the project and it generates seven mutants. The test suite catches three of them. Four survive. Here is one of the survivors, shown as the diff Mewt reports:

 choice Release : ()
 with
 paid : Decimal
- controller buyer, seller
+ controller seller
 do
 assert (paid == amount)

Re-run the test suite against this mutant. It still passes, and coverage still reports 100%. The contract claims releasing the buyer’s money requires both parties. The mutant lets the seller release it to themselves without the buyer ever confirming delivery. The tests report green either way. Only a test that tries the forbidden path, the seller acting alone, expecting the ledger to reject it, can tell the two contracts apart. No such test exists, and the mutation score says so. (The other three survivors tell the same story from different angles: the buyer-alone twin of this mutant, and two mutants that weaken the paid == amount check to <= and >=, which survive because the test only ever pays the exact amount.)

Step back, and this is the whole point of the exercise. Your tests are the executable specification of your code. Here the implementation changed, one required approval instead of two, and the specification did not react. That means the expected behavior was underspecified all along: whether both the buyer and the seller have to sign off, or just one of them, was never actually written down anywhere a machine could check. Every controller combination type-checks, and coverage reports 100% for all of them. The only place “both must sign” can exist in checkable form is a test that expects the weakened contract to fail, and writing that test is exactly what the surviving mutant tells you to do.

Limitations and what comes next

Mewt is not magic. Two limits are worth knowing before you run your first campaign: not every survivor is a real gap, and a campaign costs time. The roadmap that follows them is where we are taking the work next.

Equivalent mutants exist: some survivors turn out to be semantically identical to the original program, so no test could ever catch them. Few public DAML codebases on GitHub come with a full test suite, so we are glad OpenZeppelin open-sourced its canton-stablecoin reference implementation. Mewt generated hundreds of mutants for it. We ran the highest-priority ones through the existing test suite, and seven of those survived. Three were equivalent mutants or sat behind a guard that no path reaches, and the other four were genuine missing test cases. None of the survivors we reviewed pointed to a bug. Such a clean result is what you want when you run Mewt on your own code, and triaging them took minutes.

One of those equivalent mutants shows what that means concretely. A helper computed accrued debt:

accrueDebt currentDebt lastAccrual now annualRate =
 if currentDebt == 0.0 || annualRate == 0.0 then currentDebt
 else
 let elapsedYears = ... -- elapsed time as a fraction of a year
 in currentDebt * (1.0 + annualRate * elapsedYears)

Mewt forced the if to always take the else branch. No test failed, and none ever could: when the debt is zero, the formula multiplies by zero and returns zero, and when the rate is zero, it multiplies the debt by one and returns it unchanged. The guard is a shortcut that returns the value the formula already produces, so removing it changes nothing. Mewt suppresses the equivalent mutants it can detect. The rest need a reviewer’s judgment to dismiss.

Campaigns cost time in two places. The machine part: Mewt runs your test suite once per mutant, so the wall-clock cost is roughly the number of mutants times how long one test run takes, plus a rebuild if your project needs one. That is minutes on a small codebase and hours on a large one or a slow suite, so the cadence that works is nightly or weekly rather than per-commit. The human part: someone has to look at the survivors. We are working on that front from several directions at Trail of Bits, including our mutation-testing skill that helps configure campaigns for your project, and Trailmark with its genotoxic triage skill. None of these understand DAML yet, but the direction is clear: given the right harness and tools, the time-consuming parts of a campaign can be handed to AI agents. The effort is modest and the payoff is concrete: each genuine survivor is a specific test you can write, and every test you add makes your suite enforce one more guarantee your contracts are supposed to make.

Also on the roadmap: choice-consumption mutations (consuming vs nonconsuming) sit cleanly on top of the controller-mutation scaffolding and target a bug class Mewt does not yet reach.

Dive in

Install Mewt from the repository, point a mewt.toml at your project and its test command, and mewt run. The quickstart in the README covers the rest. DAML works out of the box. Everything here ran on Daml 3.4 with dpm, but Mewt just drives whatever test command you configure, so Daml 2 projects using the daml assistant work the same way.

Mutation testing complements the rest of your security stack, the type checkers, linters, and property tests you already run, rather than replacing any of it.

If you’re building on Canton, we help teams with security reviews of DAML applications and with the way the code gets built: working directly with your engineers on the development process itself. Contact us.

The AI Economy Institute (AIEI) is launching its third cohort of researchers, advancing our mission to understand the adoption of artificial intelligence across economies, industries, and communities. 

We launched the AI Economy Institute because AI’s economic impact is not predetermined. Though AI is being rapidly adopted, the evidence base for understanding its impact on work, jobs, education, productivity, and opportunity is still too thin. By increasing the scholarship around the AI economy and producing it in a timely and accessible way, we can help ensure that as AI transforms our world, we’re equipping people with the knowledge and tools they need to make decisions and succeed with AI.

Our 2026 AI Economy Institute Cohort

The AI Economy Institute convenes outside experts and researchers to share their perspectives and advance the body of knowledge on topics related to AI, work, and education. Our third global research call centered on understanding how frontier firms are reshaping work and the broader economic landscape.  

Representing a diverse group of institutions worldwide, our cohort brings together subject matter experts and researchers to explore how AI is reshaping the workforce, organizations, and the broader economy. The cohort consists of the following individuals, representing the following institutions:    

• Brian Jabarian, Carnegie Mellon University 
• Caspar David Peter, Erasmus University, Rotterdam, Netherlands 
• Christoph Siemroth, University of Essex, England 
• Daniel Yue, Georgia Institute of Technology 
• Edoardo Maria Acabbi, University of Mannheim, Germany 
• Frank Nagle, Massachusetts Institute of Technology (Advising Fellow and Cohort 2) 
• Friederike Mengel, University of Essex, England; Erasmus University Rotterdam, Germany 
• Gianmarco Ottaviano, Bocconi University, Italy 
• Ilan Strauss, AI Disclosures Project 
• Johannes Wachs, Corvinus University, Budapest, Hungary 
• Luca Henkel, Erasmus University, Rotterdam, Netherlands 
• Luca Mazzone, University of Montreal, Canada 
• Laura Nurski, Centre for European Policy Studies (CEPS), Belgium (Cohort 2) 
• Meeyoung (Mia) Cha, Korea Advanced Institute of Science and Technology (KAIST), South Korea 
• Mustafa Afacan, Mohamed bin Zayed University of Artificial Intelligence (MBZUAI), United Arab Emirates; Sabancı University, Turkey (World Bank Affiliated Senior Fellow) 
• Nataliya Wright, Columbia University 
• Nuriye Melisa Bilgin, Koç University, Turkey 
• Pëllumb Reshidi, Florida State University 
• Pierre-Alexandre Balland, Centre for European Policy Studies (CEPS), Belgium (Advising Fellow and Cohort 2) 
• Salman Khan, Mohamed bin Zayed University of Artificial Intelligence (MBZUAI), United Arab Emirates (World Bank Affiliated Senior Fellow) 
• Serena Booth, Brown University 
• Wesley Rosslyn-Smith, University of Pretoria, South Africa (Advising Fellow) 
• Yingfei Wang, Foster School of Business, University of Washington 

Cohort members will analyze frontier firms to examine both upstream, firm-level transformations and downstream, economy-wide impacts. Researchers will also explore how AI changes job design, skill demands, productivity, and regional economic development.  

AIEI’s first two cohorts explored how AI is reshaping the talent pipeline, from higher education and skills to K-12, community colleges, and early-career pathways, so that we could understand and inform the early changes to the labor market. What we learned from that point of inquiry shifted the focus; this year’s cohort moves further into the economy itself, focusing on frontier firms and how leading organizations are adopting AI, redesigning work, and creating the conditions for productivity, diffusion, and human agency at scale.

Interpreting the frontier: What this means for policy and strategy  

Since its launch, the AI Economy Institute has fielded more than 800 responses to our calls for research proposals. The gap between what AI systems can do and what organizations can actually deploy will shape the pace of adoption. Gains in productivity may come alongside organizational shifts as firms adapt their workflows, teams, and decision-making processes.

At the same time, the expansion of automation raises a parallel question of whether systems are enhancing human learning or displacing it. Underlying all of this is a broader uncertainty about the extent to which AI will diffuse widely across economies or concentrate in a narrow set of firms and regions. 

Cohort 3 moves beyond identifying these tensions and toward generating the empirical evidence needed to navigate them, providing policymakers, firms, and institutions with a clearer basis for decision-making in a rapidly evolving AI economy. 

The post New cohort of AI Economy Institute Fellows to examine frontier AI firms and the transformation of work appeared first on Microsoft On the Issues.

We’re running Patch the Planet, an ongoing collaboration with OpenAI that pairs Trail of Bits engineers directly with more than 30 open-source projects. Its goal is to front-run a serious problem facing open-source maintainers: highly capable models like GPT-5.5-Cyber will soon create a firehose of bug reports, and OSS maintainers are already spread thin. Our plan is to point OpenAI’s latest models at real codebases, find the security bugs first, work with maintainers to patch them, and find ways to decrease the burden on maintainers in the long run.

We’ll publish field reports like this one as the initiative progresses; follow along via the Patch the Planet tag.

The expertise barrier that kept bespoke fuzzing campaigns out of reach for most attackers is gone. We watched GPT-5.5-Cyber build in a single day what would have taken weeks for a skilled security researcher: harnesses across a dozen entrypoints, sanitizer and variant builds, seeds, and multiple findings currently undergoing coordinated disclosure.

This particular instance focused on zlib, a widely used data format and lossless data compression software library. We pointed GPT-5.5-Cyber at the library and drove it through Codex with the /goal command, asking it to find a specific class of bugs that are critically dangerous in compression libraries. We’ll publish the full harness and findings for inspection once the vulnerabilities are patched and a new release is cut.

The lab GPT-5.5-Cyber built in a day

We didn’t tell the model how to find these bugs. The obvious first move is to read the source code, but zlib has been reviewed so thoroughly that there’s little left to find that way. GPT-5.5-Cyber worked that out for itself, judged static review to be a poor use of tokens, and decided the higher value path was to build fuzz tooling to dynamically test the code. Earlier models given the same goal tend to read the code and flag whatever looks suspicious, ultimately leading to mediocre outcomes.

We believe the frontier 5.5-Cyber model combined with the /goal feature is what let it execute end-to-end without hand-holding. /goal forced the objective to live across multiple turns and compactions so the model held scope, and 5.5-Cyber was smart enough to reject weak findings, expand coverage when a line of investigation died, and keep running until it had workable proof-of-concepts backed by sanitizer output.

Over the next several hours, it built the campaign out one piece at a time:

• It used ASan and UBSan builds so memory errors became observable.
• It repurposed existing edge-case tests as guidance for the fuzz seed corpus.
• It wrote C/C++ harnesses across a dozen entrypoints, including inflate, inflateBack, uncompress2, gzFile, MiniZip, puff, blast, infback9, gzjoin, gzappend, and several contrib stream wrappers.
• It used compile-time variant builds (INFLATE_STRICT, BUILDFIXED, PKZIP_BUG_WORKAROUND, etc.) to reach code that the default zlib build hides.

Each of these decisions is routine on its own, but stringing them together in the right order across a dozen entrypoints, without being handed the steps, is a relatively large shift in how capable frontier models are.

While zlib already has fuzzing coverage from its OSS-Fuzz harness, GPT-5.5-Cyber went beyond the default harness shape, which passes random inputs to the gz* APIs. Instead of directly fuzzing the gz* APIs, its most successful harness found bugs in valid gz* states that could only be constructed by operating system backpressure.

Reporting discipline is the hard part

In general, models tend to struggle with deciding when a finding is severe enough to justify escalating it into reporting. Weaker models tend to escalate bugs that cause the program to crash, but are not reachable under real-world conditions. Early on, GPT-5.5-Cyber hit a null callback crash in inflateBack. The crash was real, but reaching it required a caller to set up a state that was extraordinarily unlikely in real-world conditions, so the model logged it as unreachable and moved on. This agent kept going without human intervention and found several higher-impact issues.

That discipline is the whole game. The value of the zlib harness came from automation plus a strict definition of what counted as a reportable finding. Without strong validity rules baked into the goal and a model truly capable of evaluating those rules, the agent will generate mountains of noise with high confidence: invalid uses of the public API, expected parser errors, internal API misuse, etc.

The moat is gone

Setting up a bespoke fuzzing campaign used to mean finding someone who could write harnesses, reason about valid API state, and differentiate between a bug and a crash that can’t happen in practice. This asymmetry kept casual attackers out of the game for most targets.

That moat is mostly gone now, and it shifts the threat model in two directions at the same time. For a skilled researcher, it is a force multiplier: the weeks-long tax on every new target drops to a day or less, so the same person can audit far more code. For a low-skill attacker, the floor rises: the tedious, expertise-heavy work of getting a harness off the ground can now be driven by starting a goal and supervising the loop.

For anyone shipping security-critical code, the practical takeaway is clear. Bespoke fuzzing is no longer a luxury reserved for projects with mature OSS-Fuzz coverage, and it is no longer expensive for the people whom you would rather not have running it. The defensive move is to do it first, with the validity rules that turn agent output into a high-signal source you can act on.

Lessons learned

The fuzzing lab answered the question we came in with and left us a much bigger one. We didn’t ask GPT-5.5-Cyber to build a fuzzing campaign; it decided that was the job and did it. The thing worth watching for now is what else these new models will reach for once you hand them a goal and step back, especially the approaches we would never have thought to ask for before.

That is also why the front-running work being done by Patch the Planet matters. Every new capability that helps us find bugs faster is just as available to an attacker, so the advantage goes to whoever finds the bugs and fixes them first.

Today we’re publishing our first “Public Country-by-Country Report” for our fiscal year 2025, disclosing our taxes in the period from July 1, 2024, to June 30, 2025. It covers the countries and regions included under European Union rules and shows, for each one, our revenue, profit, number of employees, and income tax accrued and paid during the year.  
 
We have provided this kind of information directly to tax authorities for several years under the Organization for Economic Cooperation and Development (OECD) framework. It is now published to support transparency commitments, and we believe it is important to proactively address any questions these disclosures may raise, recognizing that numbers on a spreadsheet rarely tell the full story.
 
Microsoft pays the taxes we owe in every country where we operate. We know there are strong views about whether companies are paying enough, and we believe providing this context leads to a more informed conversation.

Understanding country-by-country reporting

Country-by-country reporting is not widely understood outside tax and accounting circles. Some figures may look surprising at first, but a number that appears low or high in one country does not, on its own, tell the full story. Tax law differs from country to country, and there are two important things to keep in mind when reading the report.  

First, the numbers are prepared using rules that differ from United States or country-specific financial accounting and tax rules, so they may not match other Microsoft information people have seen. For example, this report combines all Microsoft legal entities in a country and follows the reporting rules required by EU regulations. By contrast, local statutory accounts usually cover just one legal entity, follow local accounting rules, and may use a different fiscal year from Microsoft’s.  

Second, accrued tax is what you owe for the year. Tax paid is the amount actually paid during the year. The two can differ because the timing of owing tax and paying tax doesn’t match exactly. 

France is a good example of why a single line can look unusual without context. In FY25, cash tax paid in France reflects a one-time refund of tax overpaid in an earlier year. That makes this year an outlier. In this specific case, accrued tax may be a better reflection of the taxes borne for the fiscal year. Microsoft paid $374 million in tax in France over the prior three years. 

Variations like these are a normal part of how large companies, both domestic and multinational, are taxed across borders, and they reflect an evolving tax landscape as well as a business that continues to change. We comply with every local rule that applies to us, and as those rules change, our reporting will change with them. Microsoft is committed to a tax structure that reflects where our people work, where we invest, and where functions, assets, and risks occur, and this has been a guiding principle. 

How our investments support local economies

We understand that this discussion is not only about what the law requires or what a single tax line shows in a given year. For many people, it is also about a broader question of contribution: how companies support the countries where they do business. That contribution includes the taxes we pay, the capital we invest, the local jobs and infrastructure we support, and the economic activity created through customers and partners. In the S&P, Microsoft ranks second globally in corporate income taxes paid in the last year, with a total of $28.7 billion. In fiscal year 2025, we paid $6.3 billion in income tax in the EU. Importantly, this does not include payroll, VAT, property, and other taxes paid in addition. 

Taken together, our tax payments, capital investments, and partner ecosystem reflect a long-term commitment to the countries where we operate. We opened our first European office in the UK in 1982, followed by France and Germany in 1983, and then expanded into Denmark, Ireland (our largest hub in the region), Italy, Norway, Spain, and Sweden in 1985. Microsoft is now present in all 27 EU Member States and across the broader region. We have worked in these and many other communities for decades, and thousands of our employees call them home.  

From research and development to digital infrastructure and partnerships with local organizations, we are investing in ways that support these economies beyond our direct commercial activity. At our core, we are building tools that help large enterprises, small and medium-sized businesses, institutions, and individuals become more productive and competitive, which strengthens their business and benefits the people they serve. We only do well when our customers do well. In practice, that means helping customers design and manufacture cars better, helping patients get their next appointment sooner, or making it simpler for someone to find that dream job. 

Our investments in digital infrastructure are not only supporting the local digital economy, they are also contributing meaningfully through both taxation and capital expenditure. Across markets, we continue to invest at scale in datacenters and supporting infrastructure, creating value that extends well beyond the technology sector. In the three years to June 30, 2025, our total capital expenditure amounted to $176 billion, and we spent $89.2 billion on research and  development in the markets where we operate. 

Our customers require local industry- and country-specific expertise, and this is where our partner ecosystem plays an important role. Many of these partners are local businesses themselves. A 2024 IDC study on partner profitability showed that for every $1 of Microsoft revenue, partners that provide services generate $8.45, and partners that develop software generate $10.93. While this varies by country and partner segment, it offers another useful lens on how Microsoft’s business contributes to local economic activity. 

Investments in digital infrastructure are not only investments in technology ecosystems, but in national and local economies as well. They support jobs, strengthen supply chains, create opportunities for companies across many sectors, and help build the foundation for growth and economic competitiveness beyond the digital economy. 

That is the broader context for this report. Tax is one important measure of contribution, but it is not the only one. Our investments, partnerships, infrastructure, and long-term presence in countries around the world also reflect a commitment to helping strengthen the economies and communities where we operate, today and for the future.

The post Context on our country-by-country tax footprint appeared first on Microsoft On the Issues.

Post-quantum cryptography is now one pip-install away for the entire Python ecosystem. With funding from the Sovereign Tech Agency, we implemented support for ML-KEM, the NIST-standard key-establishment primitive, and ML-DSA, the NIST-standard digital-signature primitive, in pyca/cryptography.

On June 22, 2026, the White House ordered the U.S. government to accelerate its transition to post-quantum cryptography. The order says large-scale quantum computers, especially in adversarial hands, will threaten widely used cryptographic systems, and that attackers may already be collecting encrypted data now so they can decrypt it later. It also sets concrete migration deadlines: high-value and high-impact federal systems must use post-quantum key establishment by December 31, 2030, and post-quantum digital signatures by December 31, 2031. And even if you don’t care about quantum resistance, that’s not a problem because quantum resistance isn’t the main benefit of post-quantum crypto.

That transition cannot happen only at the policy layer. Every application that signs packages, validates certificates, establishes secure channels, or protects long-lived secrets depends on cryptographic libraries. If those libraries do not expose post-quantum algorithms, the software stack cannot migrate.

Almost every Python program that touches cryptography goes through pyca/cryptography. It’s currently the eleventh most-downloaded package on PyPI, pulling 1.2 billion downloads in the last month alone. The pyca/cryptography package handles the cryptographic operations of projects like Ansible, Certbot (the Let’s Encrypt client), Apache Airflow, paramiko (the Python-only SSH client), and many others. If pyca/cryptography doesn’t ship post-quantum primitives, the Python ecosystem can’t begin to migrate.

Post-quantum support is now one pip install away

As of cryptography>=48, support for post quantum algorithms is just a pip install away. The version 48 release includes our Rust bindings for ML-KEM and ML-DSA, the cross binding API and tests, and support for AWS-LC as a cryptographic backend. It also includes work from pyca/cryptography’s maintainers to support the other cryptographic backends. Sadly, this is not enough for a post-quantum migration drop-in swap. These primitives have different size, performance, and integration tradeoffs than the classical algorithms they replace.

PQ algorithm tradeoffs

Post-quantum primitives keep the same security strength, but they change the size of the data on the wire. Public keys, signatures, and ciphertexts are often 1–2 orders of magnitude larger than the classical values they replace. The operations are also more complex and therefore slower, but on modern hardware they are still imperceptible for regular use, and are likely to get faster with improved hardware and algorithms.

For signatures, here’s how the classical primitive (Ed25519) compares to its post-quantum equivalent (ML-DSA-65):

And for key exchange and encryption, here’s how X25519 compares to its post-quantum equivalent (ML-KEM-768):

If you maintain a protocol or wire format that hardcodes Ed25519-sized signatures or X25519-sized public keys, the post-quantum migration involves more than a primitive swap. The surrounding fields, length prefixes, and chunking assumptions need to grow with it.

Using ML-DSA (FIPS 204): Quantum-resistant signatures

ML-DSA is the lattice-based signature scheme that replaces RSA, ECDSA, and Ed25519. The Python API mirrors the existing asymmetric primitives:

from cryptography.hazmat.primitives.asymmetric import mldsa

private_key = mldsa.MLDSA65PrivateKey.generate()
public_key = private_key.public_key()

signature = private_key.sign(b"message")
public_key.verify(signature, b"message") # raises InvalidSignature on failure

Using ML-KEM (FIPS 203): Key encapsulation for the post-quantum era

ML-KEM is a key encapsulation mechanism (KEM) for establishing shared secrets. The construction is different, though. ML-KEM is a key encapsulation mechanism, not a Diffie-Hellman exchange. Instead of both parties combining key shares to derive a shared secret, one party encapsulates a fresh shared secret to the receiver’s public key, and the receiver decapsulates it with the matching private key. These operations allow both parties to exchange a secret but in a manner fundamentally different from Diffie-Hellman, and resistant to quantum factoring attacks.

from cryptography.hazmat.primitives.asymmetric import mlkem

# Receiver generates a keypair and publishes the public key.
private_key = mlkem.MLKEM768PrivateKey.generate()
public_key = private_key.public_key()

# Sender encapsulates a fresh shared secret to that public key.
shared_secret_sender, ciphertext = public_key.encapsulate()

# Receiver decapsulates the same shared secret from the ciphertext.
shared_secret_receiver = private_key.decapsulate(ciphertext)
assert shared_secret_sender == shared_secret_receiver

The road ahead: SLH-DSA and protocol integration

Two areas are still in progress: a third NIST standard, and the work of integrating these primitives into real protocols.

SLH-DSA

SLH-DSA (FIPS 205) is NIST’s hash-based digital signature standard. Like ML-DSA, it is meant to replace classical signature schemes such as RSA, ECDSA, and Ed25519. Its tradeoff is different: SLH-DSA has very large signatures and slow signing, but it relies only on the security properties of hash functions, which have been studied for decades. That makes it a conservative backstop if future cryptanalysis weakens lattice-based signatures. SLH-DSA is not supported in pyca/cryptography 48, but we’ve started working on it.

Post-quantum in protocols

Primitives are the foundation, but the post-quantum migration will be complete only when protocols use the post-quantum resistant algorithms. You’re unlikely to use PQ algorithms directly in tools like Certbot or Ansible until common protocols add support for them. While well-designed to replace existing implementations, algorithm changes require cautious development, testing, and auditing. We are actively working on helping maintainers integrate PQ algorithms into applications.

Acknowledgments

This work was funded by the Sovereign Tech Agency, whose mission is to support the open-source infrastructure that public digital systems depend on.

We’re also indebted to pyca/cryptography’s maintainers, Paul Kehrer and Alex Gaynor, who offered constant feedback and review throughout the development process, and continue to steward this critical piece of open-source software.

At Microsoft, we are committed to our customers’ fundamental right to privacy. In a world defined by rapid technological change and geopolitical volatility, this commitment has remained constant. It’s rooted in decades of experience building trusted technologies that our customers rely on every day to manage their data. Many of these organizations depend on the ability to move data across the Atlantic, from the EU to the U.S., in a way that protects their privacy. That’s why we support the European Commission in its defense of the EU-U.S. Data Privacy Framework. And that’s why we have formally intervened in the Latombe v. Commission case before the Court of Justice of the European Union. This case puts at stake two principles that are important for Microsoft – the protection of our customers’ privacy and their ability to do business on both sides of the Atlantic.

To intervene in a case before the Court of Justice, a company must apply for permission. In this case, the Court granted our application, finding that Microsoft has a direct and existing interest in its result. Put simply, the outcome of this case will determine whether Microsoft and its enterprise customers may continue to use the EU-U.S. Data Privacy Framework to transfer data to participating U.S. companies, including vital customers and suppliers. This critical legal bridge promotes stability, beneficial trans-Atlantic ties, economic growth, and prosperity, while upholding strong privacy safeguards. The Latombe case seeks to dismantle it. As an intervener, we can now file legal briefs in support of the European Commission, participate in oral hearings, and share our perspective on the importance of upholding a framework that directly benefits the European economy.

Supporting the European Commission’s adequacy decision on the EU-U.S. Data Privacy Framework before the Court of Justice of the European Union

Companies across the globe rely on data flows to manage their people, produce their goods and services, and distribute products to their customers. We understand that data flows trigger questions about differences in legal traditions. They should. And for that reason, the European Commission and the U.S. administration worked diligently, in the decade since the Safe Harbour ruling, to harmonize EU and U.S. law. As a result of that hard work, and as required under the European General Data Protection Regulation (GDPR), the U.S. has now created an independent review court for any complaints regarding U.S. surveillance and implemented other required measures to provide an “adequate” level of data protection that is essentially equivalent to that in the EU.

This equivalence is a key point. The law entitles our customers to privacy on both sides of the Atlantic. This is the principle on which the Data Privacy Framework rests. And our intervention in the Latombe case is just one part of a long history in which we have stood up for that principle in Europe, as well as in the U.S. As far back as 2014, Microsoft challenged the FBI’s secret attempt to use its national security authorities to obtain information about an account that belonged to one of our enterprise customers. After we filed the case, the FBI withdrew its request. In 2016, we sued the U.S. government to challenge its practice of seeking indefinite secrecy orders—i.e., orders that prevented Microsoft from ever notifying its enterprise customers when the government sought their data. As a result of that case, the U.S. Department of Justice changed its policy to place strict limits on the duration of secrecy orders. In the decade since that first constitutional challenge, we’ve launched a series of successful court challenges to ensure that secrecy orders, of any duration, are the exception, not the rule. As a result of our litigation, numerous secrecy orders have been vacated or modified to allow notification to our customers.

We don’t confine our advocacy to courts. We are a steadfast proponent of strong privacy regulation on both sides of the Atlantic. That’s why we are specifically pushing Congress to update the U.S. Electronic Communications Privacy Act to place stricter limits on the use of secrecy orders and ensuring they are subject to meaningful judicial review. This legislative reform is gaining momentum in Congress and will greatly enhance our continued ability to protect our customers’ data.

Stable and trusted data transfers are not an end in themselves. They are a means to enable innovation, economic opportunity, and public services—while upholding the fundamental rights that are at the core of EU and U.S. law. Our intervention in the Latombe case reflects that principled balance and follows a long line of legal actions we have taken to protect our customers.

Looking ahead

At Microsoft, we have long recognized that trust is not a given—it is earned through sustained action, thoughtful design, and a willingness to engage openly with governments, customers, and individuals. Microsoft has consistently advocated for strong, clear, and globally interoperable privacy frameworks, recognizing that trust in technology depends on the strength of the rules that govern it.

Our customers in Europe can rely on us to continuously improve and update our privacy practices as technology and legal standards evolve. In 2018, we were the first major technology company to extend GDPR subject matter rights to all our customers around the world. And recent positive assessments of our privacy compliance by the European Data Protection Supervisor and the Hessian DPA in Germany underscore our continuous commitment to our customers’ fundamental right to privacy.

In support of this work, we’ve updated the Microsoft Privacy Statement to use clearer structure, simplified language, and more precise explanations of our data practices—making it easier to understand what data we collect and how it’s used, without changing our underlying privacy protections or commitments.

The future of technology will be shaped not only by what we build, but by the principles that guide us. By grounding innovation in respect for people and organizations, and strong legal protections, we can help ensure that technology continues to be a force for good.

The post Protecting privacy as a fundamental right while supporting transatlantic data flows appeared first on Microsoft On the Issues.

Microsoft is taking a new approach to fighting cybercrime, targeting the cyberattack supply chain, not just individual services. In a case unsealed today, we are simultaneously targeting two widely used cybercrime tools, Amadey and StealC, after AI-assisted analysis revealed they rely on the same infrastructure.

This action goes after the cybercrime “assembly line,” where coordinated tools drive ransomware, financial fraud, and disruptions to public services. Amadey and StealC are often used alongside each other: Amadey helps attackers gain access to devices, while StealC steals passwords and sensitive information. Together, they form a critical link in the chain. In the first two weeks of May alone, Amadey and StealC were linked to more than 140,000 infected computers globally, highlighting how widely they are used.

Working with Europol and industry partners, we targeted both tools at once. The goal: break the chain. Since the start of the operation, Microsoft has identified more than 18,000 victim computers, severed criminal control of those devices, and is working with telecommunications providers to help protect affected customers globally.

When multiple parts of an operation are disrupted together, attacks are harder to launch, scale, and recover from. The result: fewer disrupted services, fewer opportunities for cybercriminals to profit, and more friction when they try to rebuild.

It’s no longer enough to go after threats one by one. We need to interrupt how the attacks are put together. 

What’s different about this action   

Microsoft has long used civil legal action to disrupt cybercriminal infrastructure and pioneered the innovative use of existing laws, including the Racketeer Influenced and Corrupt Organizations Act (RICO), a US law designed to target organized crime.

What’s new is how we’re combining AI analysis with an expanded use of that law.

Amadey and StealC were developed by separate cybercriminals, but they relied on the same infrastructure. To understand how they worked, investigators used AI, including Copilot, to quickly analyze the malware, asking questions in plain English instead of manually combing through complex code. That helped surface key details, uncover hidden data, and test findings in a fraction of the time, turning what would have taken hours or days into minutes and enabling the team to spot connections faster.

Those insights allowed the legal team to treat both malware families as part of a single conspiracy. Instead of going after each tool separately, as we have done in the past, we used RICO to charge multiple complicit enablers involved across the operation. In total, Microsoft’s Digital Crimes Unit disrupted over 200 command-and-control servers—the systems criminals use to control infected devices, steal data, and keep attacks running.

By targeting tools together, we can disrupt the cybercrime chain more efficiently and more effectively, in a way that better reflects how these networks actually operate today.

Cybercrime now runs like an assembly line 

Cybercrime is no longer a series of isolated attacks—it’s a coordinated system.

Specialized tools handle each step: one gains access, another steals credentials, and others sell or exploit that access for fraud, ransomware, espionage, or other nefarious purposes. Different actors may be involved at each stage, but together they turn access into profit, quickly and at scale.

That structure also creates a point of vulnerability. The people behind these cybercriminal tools may never interact directly, but their tools are designed to work together. If those connections can be identified, multiple stages of an attack can be disrupted at once.

How these attacks play out in the real world 

Most people will never hear the names Amadey or StealC, but they feel the effects. A hospital locked out of critical systems. A city unable to deliver essential services. A small business losing access to accounts overnight. A retiree who lost their life savings.

These attacks don’t happen all at once. They unfold step by step: attackers get in, passwords are stolen, access is reused or sold, and sometimes repurposed for more targeted operations. For example, Microsoft has observed Russian-affiliated actor Secret Blizzard leveraging Amadey infections to deploy custom malware against targets in Ukraine.

By targeting multiple points in that chain at once, we reduce the chance that a single compromise turns into widespread harm. Put simply: fewer attacks succeed and fewer people feel the impact when they do.

No one organization can do this alone 

Actions like this underscore a fundamental reality: we’re successful when we collaborate. No single organization, whether government or industry, has full visibility into how cyber threats operate across borders and sectors. What makes this effort effective is the combination of perspectives and data.

Microsoft had been tracking Amadey due to its impact on customers, working with cybersecurity partners ESET, BitSight, Lumen, and Mitsui Bussan Secure Directions (MBSD) to better understand how it operated. At the same time, Europol’s European Cybercrime Centre (EC3), together with European law enforcement partners including Germany’s Federal Criminal Police Office and the Dutch and Danish National Police, was investigating StealC as part of Operation Endgame, alongside IBM X-Force and Proofpoint.

Bringing those efforts together expanded our collective datasets and made it possible to identify the connections between the two tools and act on them quickly. That shared understanding enabled a coordinated response that went further than any single organization could achieve alone.

This shows why partnerships matter. Industry shares technical insight, government brings visibility, and we need trusted ways to exchange that information. Only by working from the same picture can we stay ahead of attackers, disrupting not just individual tools but also the systems that make cybercrime possible.

Creating sustained pressure on cybercrime  

This work doesn’t end with a single action. Cybercriminals adapt quickly, which is why we continue tracking how these operations evolve and working with partners to disrupt them.

Microsoft’s court-authorized disruption in this case is paired with ongoing efforts to track how cybercriminals rebuild, identify new infrastructure, and work with partners to disrupt the services they rely on to operate. It also includes incorporating the findings from this disruption into initiatives like Microsoft’s Statutory Automated Disruption program, which helps accelerate the removal of malicious domains and infrastructure.

The goal is not just to stop one operation but to slow the system itself—making attacks harder to launch, scale, and recover from. By combining AI-driven insight, legal action, and strong partnerships, we can continue to raise the cost of cybercrime and reduce its impact.

For more than a decade, Microsoft’s Digital Crimes Unit (DCU) has worked to disrupt cybercrime and nation-state threats, filing around 40 cases since 2008 and partnering with law enforcement to take down criminal networks. Learn more about the team’s efforts here.

The post Scaling cybercrime disruption through innovation and AI appeared first on Microsoft On the Issues.

What happens when you clear dozens of Trail of Bits engineers’ schedules, pair them with every open-source maintainer they can contact, and unleash the latest frontier models like GPT-5.5-Cyber on critical open-source targets? Thanks to our partnership with OpenAI and its Daybreak initiative, we can report that the impact is hundreds of discovered bugs, 64 pull requests, and 51 issues filed across 19 projects (with many more still undergoing coordinated disclosure). That was just the first week of Patch the Planet.

Frontier models like GPT-5.5-Cyber are producing a firehose of security findings, and already-stretched maintainers must sift through all of it to separate real vulnerabilities from plausible-sounding false positives. Patch the Planet is different: with our experts orchestrating and triaging findings, we handle the work of fixing and hardening the code alongside the people who maintain it.

The first week of Patch the Planet covered 19 projects across cryptography, networking, language infrastructure, and software supply chain. Among these 19 projects were cURL, NATS, pyca, Sigstore, aiohttp, the Go project, freenginx, Python and python.org, urllib3, PyPI, SimpleX, Valkey, and RustCrypto. Over 30 projects have joined the initiative so far, and we’re rapidly expanding it to include more; if you maintain an open-source project, apply to join!

Anyone can file an issue, flex, and walk away. We showed up with the patches: 37 are already merged, and many more are in flight. These merges go beyond just fixing bugs: we’re adding new tests and fuzzing harnesses, CI security scanning, supply-chain tooling, correctness fixes, and features maintainers had been meaning to get to. The goal of Patch the Planet is to leave essential open-source projects measurably better off.

We brought patches, not just bug reports

We’re reporting public findings on GitHub, including 64 total pull requests. We also filed 51 issues, 19 of which are already closed with a fix. This public tally undercounts the work, since several projects take reports through private channels like HackerOne, GitHub security advisories, mailing lists, and private forks, and most of these have not been released publicly yet.

What’s in those pull requests matters more than the count. At python.org, we added a CI workflow built on zizmor, an open-source GitHub Actions static analyzer, fixed all of the issues it flagged, and integrated it into their CI. In RustCrypto, we contributed correctness fixes to the big-integer library that higher-level cryptography is built on, alongside genuine feature work in review: serde encoding support and HPKE DHKEM suite IDs. Other patches were plain engineering help: storage-accounting and service-restart fixes in SimpleX, a clearer admin-quarantine confirmation in PyPI’s Warehouse, and supply-chain improvements like SBOM sidecars for Python’s Windows artifacts. We will also be upstreaming many testing improvements and new testing campaigns. Arguably, our best contributions are not even bug or security fixes.

Keeping track of all of this is a bot we call Patchy. Patchy monitors every project, posts each new finding and merged patch to our Slack, and, for reasons we consider scientifically sound, reintroduces the common use of goblins, gremlins, and assorted creatures. Here’s Patchy’s description of an issue that has been patched:

When a patch lands, Patchy celebrates with a triumphant PATCHY HAPPY. Making Patchy happy is really what drives us.

A few highlights from the week

The week produced more than we can fit in this post, but here are some quick highlights.

A fuzzing lab built in a day. Given a narrow goal (find remotely exploitable bugs) and no instructions on how, GPT-5.5-Cyber decided that reading the source of one of the most-reviewed C libraries in existence was a poor use of tokens. Instead, it stood up a full fuzzing lab in under a day: sanitizer and variant builds, a seed corpus drawn from existing tests, and harnesses across a dozen entry points. Instead of simply fuzzing exposed APIs, it successfully built a harness that injected operating system backpressure to identify novel issues by reaching previously unexplored buggy states. We estimate all of that effort likely would’ve taken one of our fuzzing experts two to three weeks to do manually. Just as important, it showed judgment about what to test, what to report (and not report), and where to find higher-impact findings. We’ll publish the full details in a standalone field report.

A pipeline for variant testing historical CVEs built in a day. Codex was also adept at building simple but effective pipelines, such as the CVE variant analysis pipeline shown below. Codex’s /goal feature combined with frontier models like GPT-5.5-Cyber for this type of variant analysis produced novel issues with almost exclusively high-signal output.

A release-pipeline improvement at python.org. We reported multiple security issues for python.org, including some issues closing a legacy-API authorization gap. But we’re most proud of the work that produced long-term improvements to python.org’s release infrastructure: the new zizmor CI scanning, tightened release-file and metadata validation, deletion scoping fixed so bulk operations can’t reach beyond their target, and release-tooling patches in review that quote remote command arguments, fail safely on partial uploads, and add SBOM sidecars.

The aiohttp maintainers fixed their issues almost immediately. We privately reported a cluster of issues across aiohttp’s client and server paths, including cookies that could regain broader scope after a save and reload, digest credentials that could answer a challenge from the wrong origin, and resource limits that ran after attacker-controlled buffering rather than before. The maintainers authored and merged all eight fixes within hours, seven of them inside a single five-hour window. We were impressed and appreciate the maintainers’ prompt and collaborative work on these issues!

Differentially testing major cryptographic libraries against each other. Many of our projects implement the same logic, protocols, and algorithms. In particular, multiple projects implement the same cryptographic algorithms and standards like X.509 certificates. Therefore, we used Codex to point these projects at each other, and identify any relevant behavioral differences. This proved to be a high-signal approach that uncovered several issues, including this AES-GCM issue in PyCA and several X.509 issues, which we plan to upstream to x509-limbo.

Finding the bugs is now the easy part

If it wasn’t already clear from the last several months of security news, this week makes one thing clear: the expensive part of security work has moved. Arming Codex with fuzzing campaigns, variant analysis, differential testing, agentic searching, and similar techniques produces real vulnerabilities and compresses weeks or months of manual effort into hours. The advantage is no longer in finding bugs, but everything after: confirming a finding, getting its severity right, writing a patch a maintainer will accept, hardening the surrounding code, making long-term improvements to prevent similar issues in the future, and coordinating a disclosure. That is the work that floods of AI-generated reports threaten to bury.

Guidance for maintainers

If you’re a maintainer managing an unsustainable number of AI-generated bug reports, the core challenges you need to solve are deduplication, false-positive filtering, and severity correction.

Deduplication is the easiest problem to solve technically. Even simple AI-based tools that compare new reports against open issues perform well, especially when grounded in affected code lines. Automating this step eliminates most of the noise.

False-positive filtering and severity correction are harder, but they can be managed. Without explicit guidance, models default to rating everything as critical.

Generic approaches like our fp-check tool help, but only to a point. The best improvements require project-specific documentation, threat models, and severity criteria. PyCA’s security documentation, for example, was dramatically effective at reducing false positives in our bug candidates. Files like AGENTS.md that explicitly tell models which documentation to consult produced the most consistent and effective results. If security researchers are armed with this documentation, especially AGENTS.md for AI-based research, more noise will be filtered out before reaching the maintainers.

What’s next and how to get involved

This was just our first week. Over 30 projects have committed to join Patch the Planet, with a growing waitlist. As more findings clear coordinated disclosure, we’ll publish more results and deeper field reports, including full fuzzing lab details, the variant-analysis and differential-testing pipelines, and the tooling we’re building to help maintainers triage AI-generated reports themselves. Our Patch the Planet gist contains the full public list of our week one output.

If you maintain a critical open-source project and want this kind of help, you can apply to join Patch the Planet.

We're all petrified about missing a critical event or misclassifying an alert, but when we're talking about incident response (IR), there are often hundreds if not thousands of alerts to parse through. It's easy to get caught up with one alert because it feels "too hot" or maybe not spend enough time looking into something that initially seems "too cold."

The post Finding the “Goldilocks” Zone: A Practical Approach to Alert Triage appeared first on Black Hills Information Security, Inc..

Welcome to Issue #162 of Detection Engineering Weekly!

✍️ Musings from the life of Zack:

• I had an excellent long weekend celebrating the 4th of July here in the U.S.! It was a good lead-up to a rather disappointing World Cup loss on Monday :(

• We recently bought a kids’ WiFi landline phone thing so they can call family and chit-chat. Let me tell you: it’s been terrible. The quality/service is poor, and it just feels cheap. So, I’m trying my hand at rolling my own FreePBX server with an upstream trunk provider. I haven’t been this excited about a project in a long time :D will report back once I get it deployed

Detection & Response Happy Hour @ Black Hat

If you are going to be in Vegas during Black Hat, come swing by Tom’s Watch Bar @ the NYNY Casino right on the strip on Tuesday!

I’m running it back after BSides/SFRSA with friends and supporters of the newsletter, Cotool.ai. It was super chill at RSA with no vendor b.s., so escape Mandalay Bay and come talk shop with other practitioners.

Register Now!

💎 Detection Engineering Gem 💎

End-to-end detection validation using coding agents by Kyrre Wahl Kongsgård

This blog is one of the single best deep dives on detection validation I’ve seen in years. It hits a bunch of themes, including types of detection testing and architectural decisions for building and deploying end-to-end tests, and clearly describes an elegant and repeatable agentic loop for this use case. Let’s break it down piece by piece, because there’s a ton here and I highly recommend reading this one if you don’t want to touch any other story in this issue.

Security folks tend to steal concepts from SRE and developers and relabel them with fancier, cooler names, but the underlying principles remain the same. The picture above from Kongsgård shows how we celebrate concepts like testing and “chaos engineering” in security and map them to the security telemetry lifecycle. Regression tests, for example, focus only on verifying that an input (telemetry) produces an output (alert). Synthetic ingestion is an integration test of the ingestion and shaping of telemetry to generate an alert. End-to-end testing looks at the full telemetry → detection → response pipeline.

My favorite themes

Since this post has enough content to fill several posts, I’m going to point out two of my favorite themes so it doesn’t feel like I’m repeating or rewriting Kongsgård’s content.

Lab environment and TTP framework

Booting labs up to run simulations takes a ton of time and effort, especially if you are starting from scratch. The goal is to replicate your environment as closely as possible, but there are always trade-offs in simulation. Some of these tradeoffs include:

• Environment mirroring: A host running in a VPC can help mirror what your endpoints or cloud resources look like, but it won’t be exact. Detonating potentially dangerous tooling inside a production environment can introduce externalities or even real security incidents if you aren’t careful

• Baseline activity: A user, much like an agent, is non-deterministic. The telemetry they generate from normal activity is just as important to model as the malicious traffic itself

• Provisioning discipline: Running a small amount of Atomic or Stratus Red Team tests is manageable from an individual detection engineer’s perspective. If you want to run your whole catalog of detections, you need to start thinking like an SRE or software engineer, as you’ll hit scaling and drift issues with your infrastructure

Kongsgård’s detonation environment has a high level of discipline to address these tradeoffs. The section on the Lab environment uses several DevOps paradigms, such as golden images, configuration management, and deployments via GitHub Action runners. Under the hood, they use Meta’s TTPForge as their adversary simulation framework for execution on detonation hosts. It offers a content-rich, multi-step attack-generation feature set that is adaptable to their agent-harness framework.

Agents as validation drivers and the schema knowledge base

Singular prompt, one-shot agents have their place in implementing agentic systems in security, but they tend to perform poorly as tasks become more heterogeneous. Since the task is end-to-end detection validation with TTP generation, rule tuning, and detonation, a Claude Code or Codex agent would not be sufficient.

The harness is the differentiator for anything agentic security. Remember that! Their agent isn’t improvising an attack; it’s following a plugin that teaches it to write TTPForge YAML files, ship them over SSH to a lab host, run the detonations, and then queries Splunk to see whether telemetry arrived and the detection matched. When a step fails, lifecycle hooks block progress until the agent finds the issue. Here’s the high-level architecture:

My recommendation to all my readers is to design your agentic workflows around single agents that do one thing very well. It’s as if you are extracting one piece of expertise from your brain and encoding it into a prompt to do a single thing. In this particular case, Kongsgård designed two plugins to perform discrete tasks.

• detectionkit builds the TTP definition via TTPForge, writes the detonation test, deploys and runs the detonation. Its singular purpose is to replicate threat actor activity in a common & repeatable lexicon

• splunk is the plugin that performs the validation that the correct telemetry was captured, the search for the rule was performed quickly, and continuously discovers index structure to understand rule performance and drift

Security vendors who sell agentic capabilities typically don’t expose their harnesses at the level of detail shown in this blog. Researchers and open-source enthusiasts are quickly catching up with these vendor-led harnesses, and this truly gives detection teams agency to choose between build and buy.

It’s been easier to admit that I can’t imagine a world without a Claude Code or Codex. The prompt was the star of the show for the first year or so of this coding agent frenzy, but it’s now squarely the quality of the harness that brings detection to the next level.

🔬 State of the Art

Detecting Agentic Threats in Claude: Writing Rules on the Execution Layer by Andrew Byford

This is a Part 2 post from Byford’s previously featured work on writing rules for Anthropic’s Compliance API. The cool part here is that, unlike his last post, which focused on the prompt content itself, this looks at the execution layer of the coding agents. I’ve always interpreted the execution layer as how the agent interacts with the filesystem itself. This presents unique detection challenges because, in my opinion, the impact is the same, such as downloading and executing a binary, but the paths are different, such as malicious skills, reading a malicious prompt, or loading a malicious plugin.

Byford splits the threat categories into five distinct buckets: excessive agency and permissions, supply chain threats, dangerous actions, sensitive information disclosure, and data poisoning. The architecture is clever where the Compliance API is used as an enrichment backdrop during investigations, so you can combine unstructured data from prompts with the structured data generated from Claude hooks:

And here’s the enrichment layer after a SIEM rule fires from the OTel collector:

Much like detection engineers have had to become supply chain security experts in the last two years, I don’t see a world where we also must become AI Coding agent experts in the next year or so. I never considered using prompt and response content generated from coding agents in the Compliance API as additional context for SIEM alerts, so I’m now going to steal that idea and see what I can do at my day job (sorry, Andrew!).

SOC Bench by DeepTempo

Evaluation datasets are critical for understanding model performance. Much like in my analysis of this week’s Gem, one-shot prompts can perform well under very constrained conditions, but without something to measure real-world malicious vs. real-world benign, you should limit your confidence in virtually all agentic security applications.

I found this SOCBench website & corresponding open-source repository, and it reminded me of Cotool’s Research benchmarks with similar datasets. This specific one includes a NetFlow dataset containing both malicious and benign network traffic. It’s also a bit more opinionated about persona benchmarks, ranging from SOC analyst to detection engineer, and includes more architecture, with tool catalogs and playbooks for those personas. Their first benchmark around detecting maliciousness:

Anthropic performed the best but it looks like it cost the most. I find it interesting that OpenAI’s benchmark had the threat analyst perform the best vs the SOC analyst in the other two.

Skills Registry Threat Models by Andrew Nesbitt

Two issues ago, I linked a blog by Aman Khurana that helped demystify the peculiar supply chain architecture behind VSCode extensions. The big takeaway I took from that blog is that not surprisingly, the more security engineers dig into supply chain security, the more they realize how difficult it is to piece together OSS ecosystems to perform effective detection and blocking. Coding agents are built to be autonomous and extensible, just like OSS. The difference lies in the non-deterministic way these agents perform coding tasks, due to intentionally designed boundaries.

In this post, Nesbitt unveils his threat model around coding agent skills. A skill is a bundle of prompts, code, dependencies, and tool permissions. Anytime a skill is used, the skill prompt is injected into the context window, and a set of tools and scripts gets exposed to the coding agent. The more frightening part of the Skills supply chain security is that, instead of a single npm command installing other packages in Node that eventually land a piece of malware, you can have a Skill install packages from virtually any ecosystem, and sometimes those packages are just more prompts.

I don’t think we are truly ready for a large-scale malicious Skill campaign, much like what we’ve seen with the likes of TeamPCP. Nesbitt points out several issues with how Skills are installed, deployed, and managed, and it certainly seems that this ecosystem is in the same stage that npm was in several years ago.

☣️ Threat Landscape

FBI Seizes NetNut Proxy Platform, Popa Botnet by Brian Krebs

The DoJ nabbed another residential proxy platform linked to the Popa Botnet. Krebs post here helps aggregate some of the data published by researchers at Google, Lumen and Spur. The wild part to me is that this proxy platform is linked to an Israeli company, and I’ve always assumed that these networks are owned by non-Western firms who are harder to work with outside of the U.S.’ sphere of influence.

These types of botnets finally figured out how to monetize without DDoSing. Krebs referenced research from Spur that nearly 50% of TV Apps on the LG Smart TV platform add the TV to these botnets, which are then sold as residential proxies.

I found a malware hiding in my tailwindcss config file. by Couch Potato

Super interesting write-up from a developer who encountered a Contagious Interview-style backdoor in their Tailwind configuration. They never figured out how it got there, but the indicators are classic Contagious Interview:

• Targeting developers and backdooring their code

• C2 server communication to an immutable blockchain style API

• Rewriting git history to conceal the compromise

It didn’t necessarily say what the impact was or whether the campaign resulted in data exfiltration. They did find several unknown processes running in their production environment, so likely something happened there. If I had to guess, it was a PwnRequest due to the rewriting of the git history, but that’s about as far as I’ll go before I start placing bets.

Linux Backdoor Targeting iKuai Routers by dmpdump

This is a cool Linux backdoor writeup of a piece of malware that, based on my ~limited research, targets a Chinese-focused router typically deployed to East Asian/Chinese businesses. It’s an ELF binary that impersonates OpenWRT’s libjson_script.so.0. It was hard to ascertain at first, but it certainly is not a shared library and runs in userland. I don’t necessarily know whether the victimology is Chinese firms, which could make this a Western-based piece of malware, but it seems compact and very specifically designed for one router brand, which makes it smell like an APT implant.

ARToken: Inside an EvilTokens affiliate panel targeting Microsoft 365 by Michael Kelley

The TALOS research team uncovered an offshoot of EvilTokens, a device-code phishing-as-a-service kit. Kelley uncovers the initial BEC-style lure and then reverse-engineers the kit to find modern front-end components, such as single-page application lures, and a full backend dashboard written in React. Some of the differentiating features of ARToken Kelley found include keyword searching across victim mailboxes, post-exploitation tooling against victim SharePoint servers, and even collaborative session links for operators working on the same ARToken deployment server.

Lydia Graslie’s Gem from last week helps protect against some of these attacks, especially if you monitor which Microsoft management surfaces emit audit data for device‑code flows and token lifecycles, and treat gaps and schema shifts as first‑class detection problems.

🔗 Open Source

DeepTempo/socbench

SOCBench’s open-source harness for evaluating alert datasets. The current dataset only contains NetFlow telemetry, but it looks like they want to add more. Their harness is the most interesting between playbooks, personas and how they run the evals themselves.

secdev02/EasyTokens

EasyTokens is a device code phishing toolset that emulates device code phishing as a service kit like EvilTokens. This one is more focused on performing the device code phishing attack itself, so you can use this to pivot into cloud and M365 environments.

kernelstub/Nox

Nox is an open-source attack surface scanning tool. There are 300 module plugins across 24 different categories. You can run each module individually or run a full scan that steps across all 24 categories to find everything from exposed credentials, vulnerabilities and OSINT findings.

phishdestroy/shortdot-evidence

Shortdot is a registry operator that hosts seven top-level zones (TLDs) that, according to PhishDestroy, almost exclusively contain fraud, phishing, and malware websites. This repository holds all of their research, enumerating the zones and their phishing website analysis across the seven sketchy-looking TLDs. Their research also includes financial research and how Shortdot charges ICANN fees to operate these zones.

You've watched the demos. Whether it's Claude Cowork, ChatGPT Enterprise, GitHub Copilot, Cursor, or internally developed agents, AI systems are no longer answering questions. They are connecting to enterprise data, invoking tools, making decisions, and executing multi-step workflows across applications without human intervention. The capability is real, and organizations are rapidly moving from experimentation to deployment.

Teams are no longer asking if they should use this, they have accepted agentic tools as the reality. But the board and the infosec team are asking a different question: can this capability be secured and controlled at enterprise scale? Can security teams prevent sensitive company data from being exchanged without oversight?

Anthropic built meaningful access controls into Cowork — role-based permissions, group spend limits, usage analytics and connector restrictions — so the answer is a qualified yes. Those controls handle who can use the tool and what they can connect to, but they don't answer whether a specific action inside a given session is safe. That gap is the one standing between a successful pilot and a successful org-wide rollout.

The Gap That a Demo Doesn’t Expose

The organization’s admin assigns roles, sets spend ceilings per user group and restricts which connectors have access to write to your database. Anthropic's OpenTelemetry support even lets your team pipe session events into your SIEM. These controls cover real ground, but they operate at the permissions level — answering whether a person is authorized to use the tool rather than whether what's happening inside a session is safe.

Consider what that gap looks like in practice. Let’s consider two scenarios. Your finance analyst has full Cowork access and uploads a quarterly forecast containing unannounced acquisition figures. The access controls confirm she is authorized to use the tool, but nothing evaluates whether that information should be exposed to a model. That's an AI data loss prevention risk, and access controls are blind to it.

The risk becomes greater when agents move beyond information retrieval and begin taking actions. Let’s say a scheduled Cowork automation is set up to pull weekly competitor pricing from the web. A target site embeds hidden instructions in its page content. The agent, running unattended, reads them as legitimate commands and begins modifying local files and triggering actions your team never authorized. By the time anyone notices, the agent has already acted.

The first scenario exposes a governance problem because your security team has no visibility into what data is flowing through AI tools across the organization. The second is a runtime security problem as there is nothing evaluating whether an action in progress is safe, regardless of whether the user was authorized to start it. Neither gap is addressed with the predefined controls in Cowork; both need to be solved before you can say yes to Cowork adoption in the whole organization.

Why Traditional Controls Break Down

Traditional enterprise software behaves predictably. Access controls work because administrators can reasonably anticipate what an authorized user or application will do once access is granted. 

AI systems operate differently. Agents combine models, tools, data sources, and reasoning paths dynamically at runtime. An authorized user may start with a simple request, but the resulting chain of actions may evolve in ways that were never explicitly programmed or anticipated. The challenge is no longer controlling who can access a system. The challenge is securing and governing what happens after access has been granted.

The Missing Layer is Runtime Security 

Anthropic's access controls establish who can use Cowork and what they can connect to. But as the examples above show, they don't protect against what happens inside a session: a finance analyst uploading sensitive acquisition data to the model, or a scheduled automation being hijacked by a malicious instruction embedded in a webpage it was directed to visit. What organizations working with Cowork need is a layer that enforces data and security controls and gives complete visibility at runtime across all Cowork agents in the enterprise every interaction boundary.

An AI runtime security layer that sits between your teams and the model providers such as  Anthropic, AWS Bedrock, Google Vertex or any combination, and evaluates risk in every interaction. It inspects every request, every tool call and detects sensitive data like client names, financial projections, internal pricing and contract terms.  It enforces agent identity controls, so every automated action is traceable to a specific workflow and owner. 

Your CISO gets the audit trail and your Infosec team gets the evidence.

The AI Enterprise Needs a Control Plane

The CIO needs the observability for all Cowork activity and costs. An AI control plane allows the CIO to set spending limits per team and use case across every AI tool from a single console. Procurement asks for a quarterly forecast across all AI spend, and you pull it from one place instead of aggregating reports from four different vendor dashboards. If you need to move providers for cost or compliance, the gateway reroutes traffic without disrupting your teams or breaking your workflows.

Claude Cowork may be where organizations begin scaling their AI journey, but it won't be the only AI tool your teams use. Developers will use coding assistants,  business teams will leverage the AI built into SaaS applications and data science teams will deploy custom agents for their workflows. New models, new providers and new workflows will continue to appear.

The challenge isn't just governing one AI application; it’s governing AI activity across the entire AI enterprise.

Everyone looks to secure each tool individually: configure Cowork's controls, configure your coding assistant's controls, configure your internal agents separately. But this approach doesn't scale. This is the sole purpose of the control plane. It sits above individual tools, applications and models and enforces  security policies,  across every AI interaction. 

Prisma AIRS AI Gateway provides that centralised control plane. Organizations that deploy Cowork behind our gateway get runtime security, data protection, agent identity controls, and full visibility, applied consistently, without changing how teams use the tool. The same gateway secures every other AI tool in your environment on the same terms.

Cowork may be where the journey begins, the gateway is what allows it to scale and secure the AI Enterprise.

The post What It Takes to Secure Claude Cowork Across the AI Enterprise appeared first on Palo Alto Networks Blog.

As artificial intelligence (AI) adoption surges and organisations move from the ‘should we?’ phase to the ‘how do we?’ phase, it’s natural to evaluate the likelihood of positive returns on AI investments. That’s always been the case with the onset of each new technology paradigm: C-suite executives, guided by their boards and aided by technical and business teams, remain keenly focused on traditional metrics such as return on investment, shareholder equity, developing and extending competitive advantage, and ensuring superior customer relationships.

This time is different, however. I recently experienced that firsthand when I went to visit a major customer. My contact, a senior decision maker, gave me a pointed piece of advice about how to talk about AI with his boss, the CEO: “Please don’t say anything negative about AI.” The subtext was clear: The company was fully committed to AI and didn’t want any cognitive dissonance to dissuade them from their mission.

It's hard to imagine a CEO taking such an absolutist stance on previous technology waves, such as cloud, bring your own device, or the internet of things. CEOs, board members, and technical leaders would be pragmatic in evaluating the benefits of investments and put mileposts in place to gauge progress – and to determine if and how to proceed.

AI is certainly a different kind of paradigm, though. While no one is casting aside careful evaluation and monitoring of AI investments, the underlying assumption is that we’re stepping on the accelerator. We’re all enthused not only by its potential for transformation and innovation, but also by how this technology can be leveraged for remarkable societal good.

However, while the accelerating momentum toward AI and agentic systems is undeniable, it is vitally important to set aside the fervour around AI and take a sober look at how to deliver safe, secure, and tightly governed systems at enterprise scale. 

Many organisations are underestimating the challenges of AI governance, in large part because they think they’ve been here before. They already have many experiences of ensuring robust cybersecurity and strict governance for new technologies, as they’ve done for remote systems, cloud computing, the internet of things, and more. They already have a corporate commitment to doing governance correctly and a sound governance model. 

But this new era of AI and agentic systems is different. New challenges abound, and AI strategy, build-out, and governance must be in alignment from the start to ensure proper operational, ethical, and regulatory outcomes. 

Our intention with this Peer Insights guide is to raise what we believe are existential issues around governance for this powerful, complex, and unprecedented technology wave. Few technologies have merited the often overused phrase ‘inflection point’ more than AI. The speed of AI adoption is nothing short of breathtaking; however, today’s runaway embrace of AI is far stronger than our current ability to govern it. That’s because AI represents a fundamental shift in how organisations do their business, interact with customers, make vital decisions, and execute their plans. This isn’t just a technology play: It’s a strategy for success and survival for entire industries and our global economy. The stakes have never been higher.

CEOs care so passionately about AI because they see it changing nearly everything we’ve learned and believed to be true about organisational success and failure. CEOs are in their positions for one purpose: to grow the business. AI can do that by transforming their processes and sparking new ideas. When that customer representative forewarned me, I really wasn’t surprised to hear his CEO felt so strongly about AI: Research from BCG indicates that more than 94% of CEOs say they still plan to deploy AI irrespective of demonstrated business value, even if there is a lack of tangible ROI or financial benefits from the start. 

Which brings us to the central role of AI governance. As we all know, there are many fundamental elements to any governance strategy, starting with robust, scalable, and intelligent cybersecurity. Cybersecurity - the foundation of governance - also includes the twin imperatives of accountability (‘rogue AI’ being a real thing, after all) and regulatory compliance.

But good AI governance has to go even further. Operational integrity is key to good governance because so much sensitive and even proprietary data is poured into AI models and accessed through powerful agentic AI systems. Now more than ever, organisations have to be transparent with customers and trading partners about how their AI systems operate, what kind of data is accessed, and how it is protected. And that doesn’t just mean being upfront with customers by telling them when they are interacting with an AI agent. Let’s take a typical retail use case: Imagine you’re on a website looking at clothing, and the agent recommends specific styles of clothing in specific colours. True operational integrity would allow you to discover why and when the agent made those recommendations. Was it based on your prior purchasing history, or on your browsing patterns on a recent web session? AI and agentic governance take the guesswork out of the equation for those interacting with the system and help breed greater confidence and trust.

It's critically important for decision makers to view AI governance holistically, rather than through a series of narrow lenses. For instance, even though cybersecurity is the foundation of good AI governance, it’s a mistake to treat AI governance primarily as a cybersecurity problem. If asked about ownership of AI governance, CEOs cannot and should not reply, “Oh yeah, the CISO has that covered.”

AI governance is fundamentally an enterprise risk problem, which means everyone must be involved in creating, deploying, managing, evaluating, and adjusting AI governance guardrails on a real-time basis. Again, AI is a different kind of risk environment than any we’ve previously encountered. For the most part, organisations are simply not adequately prepared to apply the right level and right type of governance to AI and agentic systems. I’ve spent much of the past 15 years of my career building governance frameworks, and while it has never been easy, we have had the advantage of being able to control many of the variables – such as infrastructure and network access – impacting governance decisions. With AI and agentic, we no longer have that advantage.

To explore the critical and complex issues of AI governance, we’ve enlisted five leading voices to bring their real-world experience to the discussion. Together, our five authors help lay out the new rules of the road for governing AI and agentic systems at scale.

Just as my customer gave me a heads up about the realities of speaking with his boss about AI, I’d like to offer you a heads up about the realities of AI governance challenges before you read this Peer Insights guide. 

1. Visibility is paramount for successful AI governance. As we learned during the growth of trends such as cloud, bring your own device, and remote work, our employees will push the envelope with a do-it-yourself mindset. These tech-savvy and resourceful users are already making rogue AI a reality, so organisations need more visibility than ever into where AI ‘science projects’ and sandboxes are operating without anyone’s knowledge.
2. AI governance must reflect the stunning velocity of change in AI development and deployment. Not only does AI have its own never-imagined rate of change, but the technology is changing everything else faster – product development, supply chains, marketing programmes, and more. AI governance has to evolve just as rapidly. Governance in the AI world must be a living system, constantly evolving with new technology use cases.
3. Trust boundaries are incredibly different and difficult to manage in AI governance. AI represents a new class of identity that simply didn’t exist before. That means AI doesn’t fit neatly into your existing identity management framework, making things like application whitelists and zero trust network access less effective.

Unfortunately, many CEOs, board members, and business executives simply don’t understand the profound importance and complexity of these issues. They may have been heartened by how they integrated generative AI into their technology frameworks and their business processes, but GenAI was pretty familiar territory for CIOs, CTOs, and CISOs. Agentic AI is different for several reasons, including its automation and self-learning capabilities. Don’t be lulled into a false sense of security: Agentic AI is not simply a refresh of GenAI.

As you get ready to dive into the following chapters, rethink how you define governance when applying it to AI systems and agentic AI. Most traditional governance models are imagined, constructed, and deployed as gates, preventing people from doing things or going places they shouldn’t. Instead, think of AI governance as a guardrail to guide and direct people to get the most out of AI without creating problems. With so much excitement and investment around AI, organisations – and their employees – want to get the most out of their AI and agentic systems. We all know people don’t want to hear “no, you can’t do that”, so an effective governance system should use guardrails to drive proper, responsible, and safe usage of the technology.

Finally, as complex as AI and agentic governance are and will continue to be, don’t overthink things in hopes of creating the perfect model – it doesn’t exist. My advice is to start now, even if the model and framework are imperfect, and then bring the business along with you.

We at Palo Alto Networks are excited to give you insights, ideas, and actions you can take away from the chapters of this guide. We encourage you to share what you learn with your colleagues, peers, and team members – and to take prudent steps to build an AI governance model that rewards innovation without allowing your organisation to drift into dangerous waters.

Haider Pasha is VP & Chief Security Officer, EMEA, Palo Alto Networks

The post It Might Feel Like We’ve Been Here Before, But We Haven’t appeared first on Palo Alto Networks Blog.

Vulnerable and outdated software components are one of the most common issues encountered by BHIS during web application penetration tests. The vast majority of web applications use third-party components such as jQuery, Angular, Bootstrap, or countless other libraries.

The post Finding and Addressing Vulnerable and Outdated Web Application Components appeared first on Black Hills Information Security, Inc..

Welcome to Issue #161 of Detection Engineering Weekly!

✍️ Musings from the life of Zack:

• I had an excellent vacation at the beach with my family! We stayed at an Airbnb with a 1-minute walk to the ocean. There’s something about the crashing waves and the smell of salty water that makes me wish I could afford a house there D:

• I am locked in & going to BSides LV/BlackHat/DEFCON! I’ll be posting details for my Detection & Response Happy Hour next week with sign-ups. Mark your calendars for Tuesday, Aug 4 at 5 pm :)

• I opened sponsorship slots up for the summer, so if you’d like to work with me on ad placements or opportunities to work with the Detection Engineering Weekly brand, shoot me an email: techy@detectionengineering.net

• Lastly, I opened a content submission page for folks who want to get their research and blogs in my reading queue. It’s much easier for me to use this then accidentally miss something on social media, Slack or e-mail!

  Submit a blog

💎 Detection Engineering Gem 💎

Control Plane

Where Continuous Access Evaluation Stops Being Continuous

Not every identity attack ends in a stolen token, but increasingly many do. Device-code phishing, adversary-in-the-middle proxies, OAuth consent grants: the front ends look nothing alike, yet they tend to converge on the same prize, a legitimate access or refresh token that Entra issued after a sign-in it had no reason to question. Sometimes that sign-i…

Read more

21 days ago · Lydia Graslie

Defense-in-depth is an overused phrase in security marketing, but it’s one of the few “buzzwords” where the definition matches in marketing-speak with what it means in security operations. At its core, detection & response is a hedge against when security controls fail. Examples of this include someone entering their username, password, and security code on a phishing page, or someone downloading an infostealer binary from an allow-listed domain, such as a CDN, and running it. The important part here is that detection engineers identify the attack paths that threat actors take when those controls fail.

Lydia’s blog (hi Lydia!) is a great example of the nuances of a powerful security control, Entra’s Continuous Access Evaluation (CAE), and how even the perfect implementation of that control can fail. Both infostealers and attacker-in-the-middle phishing pages are regularly stealing access tokens from victims, and when these tokens get into the hands of threat actors, they can use them to pivot into a production Entra environment. Microsoft implemented CAE to help combat long-lived tokens through a challenge/response mechanism to catch stolen tokens:

The idea is that legitimate or malicious access tokens should be evaluated against access policies and controls, and Entra can catch a stolen access token before a threat actor interacts with the target environment. It’s an excellent security control that is now the default for Entra environments, but much like multi-factor authentication, it has its sharp edges:

• There’s a 1-hour expiration window when the issuing client does not have a CAE-enabled auth flow

• Resources that don’t have CAE can still be interacted with, meaning a bypass of a CAE-enabled client against a non-CAE-enabled resource is possible

• IP restrictions can revoke the key quickly, but infostealers and phishing kits help provide geolocation and IP information, which can help bypass this restriction

Lydia provides a helpful coverage map for when each control fails and what you can do to “hedge” against a stolen token. This is where telemetry on hosts and cloud resources, combined with identity telemetry, provides a much stronger defense-in-depth approach when the best security controls fail.

The hedge is telemetry and correlation. If the token is being worked through Outlook or Teams against M365 from a CAE‑capable client, CAE helps detect and respond to malicious access attempts. If it’s a guest identity, a third‑party cloud app, or a tenant that has more lax IP restriction controls, you have a one-hour window to find initial access.

Per Lydia’s guidance, you should log where tokens are actually used, correlate host and cloud activity with identity change events, and build detection and response plays for the points where CAE is bypassed.

🔬 State of the Art

Introducing GuardDog 3.0: A new rules engine, transparent sandboxing, and more by Christophe Tafani-Dereeper and Sebastian Obregoso

~ Note: Datadog is my place of employment, and Christophe & Sebastian are my colleagues! ~

My esteemed research colleagues at Datadog released version 3 of GuardDog, an open-source malicious package analysis tool. I’ve talked about guarddog in this newsletter all the way back to Issue 11 (!), and I’m super proud to see its active development and use here at Datadog. Especially since it started as an internship project!

The unique detection-focused part about GuardDog is its rule system. In previous versions, semgrep was run under the hood as we applied SAST primitives to detect malicious behavior. It worked well until they started to hit scale issues, so, like good threat researchers, the team switched the underlying rule engine to YARA. The team also graduated from atomic detections to implementing a scoring system that provides confidence scores for a package’s maliciousness. The final interesting part is that they created a benchmarking and evaluation dataset from the years of us collecting malware samples:

You can run this locally in its brand-new sandboxing environment using no-sandbox and play around with the samples, or implement the tool yourself in your environments!

Developer endpoint inventory in 10 minutes: Bumblebee Hive by Oluwatobi Afolabi

I featured Perplexity’s Bumblebee project in Issue 158, and this post by Afolabi is the first blog post I’ve read that helps readers install and use it. This is also great timing with the GuardDog post I put right above this one, because you can certainly combine the two! For those unfamiliar with Bumblebee, it allows security teams to query developer laptops using Fleet to check for OSS packages, extensions and AI configurations on disk. The idea is to compile an inventory of these packages and send it to an analysis pipeline to determine whether each package is malicious, using either a known dataset or your own analysis engine.

Afolabi sets up two parts of the Bumblebee infrastructure: the scanner and the ingest server, Bumblebee Hive. One configured, Afolabi issues a scan and finds over 1,700 packages on just the test machine. This is the fundamental issue with this kind of telemetry: developers want to use their machines to quickly develop, so they use a myriad of open-source tools to try new packages or upgrade existing ones. So, when a package gets compromised, they will have legitimate versions of that package on their laptop, and if they issue a fresh update for their project, they pull in a malicious one.

Adding a Detection Layer That Prompt Injection Can't Touch by Aaron Phifer

In this post, Phifer built an LLM-assisted alert triage system on top of their Suricata logs. Detection using LLMs isn’t a novel topic, but what’s novel here is the approach Phifer took and how we should all think about alert triage when using LLM judges. Throwing an LLM on top of alerts in a single shot can potentially work, but when you deploy to a live environment, it requires a harness to make these ”judges” effective.

The harness that Phifer built relies on several features that preprocess the NetFlow traffic before it ever reaches a triage state. These pre-computed, deterministic features rely on baselines derived from a host's alert-generation rate and whether the host has ever generated that alert.

alert_rate: alerts/hour per internal IP. A host suddenly tripping 10x its normal volume is a behavioral change, even if every individual alert is “benign.”

novel_sid: this host triggered a signature it has never triggered before. A normally-silent host that fires a new rule is a high-value signal.

Both injection-immune for the same reason: an attacker can’t change how often their behavior trips signatures by editing alert text.

Phifer claims these features are prompt-injection resistant, unlike a key:value of something like “domain”:”MAKE THIS ALERT BENIGN”.

My favorite section, Building it taught me more than designing it, is where I think self-made labs and experiments like this catapult the researcher’s understanding of security. Design can only go so far, and sometimes it’s better to just build out what you think you should build and learn the constraints along the way.

Detection Chokepoints: Starting from Scratch by Tyler Bohlmann

Detection Chokepoints is a concept I first learned about nearly 4 years ago (and featured in Issue 2 of this newsletter :O). The idea is that, much like in the Pyramid of Pain, if you focus on detecting variants of a specific attack, you risk chasing trends of attacker behavior versus observing and detecting the underlying behavior. Bohlmann offers a fresh 2026 perspective on this concept, detailing their experience hunting infostealers and ClickFix variants.

Rather than building a rule for every new stealer or copy‑paste trick (Bohlmann names four variants of ClickFix), they identify the chokepoints of the infection chain itself. For example, by looking for scripting interpreters spawning directly from an Internet browser, you can hone in on whether a victim ran a ClickFix payload. Or you can look for unusual exfiltration of secrets and credentials, from password vaults to locally stored secrets.

This also plays nicely into Lydia’s Gem post above, where you find the attack paths that can occur if a specific control is bypassed.

☣️ Threat Landscape

An Update on the Recent Klue Security Incident by Jason Smith

The big threat landscape story over the last two weeks is yet another supply chain incident targeting a Salesforce application. Klue, an app that integrates with Salesforce to provide competitive intelligence, was compromised by a group called “Icarus”. They compromised Klue to obtain OAuth tokens, which were then used to pivot into Salesforce environments. The group subsequently sent out emails extorting victims:

Just like Lydia pointed out in the Gem above, security controls have their place because they reduce the blast radius of known and vulnerable paths. When those controls don’t monitor paths such as a Salesforce integration, you need defense-in-depth controls or detection rules to hedge against failures in security controls.

These Recent Insider Threat Allegations by Kyle Hanslovan

There’s been some infosec drama brewing over the last week involving a former Huntress employee. According to the former employee, a current employee of the firm disclosed sensitive investigation information to a threat actor from the DevMan ransomware group. The former employee also alleged that the firm was covering up the incident and failing to disclose its details to the broader public and customers.

I’m not going to link the employee’s social accounts to preserve some level of privacy, but the post here from Huntress’ CEO gives their side of the story. Researchers at Huntress are given some latitude to engage with threat actors to gather threat intelligence and better understand specific criminal operations. According to Hanslovan, the employee disclosed some sensitive details to DevMan about a law enforcement case the researcher was involved in.

You’ll never have the full details in cases like this, but my current take is that Huntress didn’t have the best guardrails in place to prevent a situation like this, and it sounds like they are implementing those exact guardrails after this incident.

Synthesis of Exploitarium Mass Zero-Day Disclosure by Ethan Andrews

This is a write-up of CVEs and detection opportunities from the exploitarium repository dropped last week by the anonymous researcher ‘bikini’. The repository contains over 130 unpatched exploit PoCs across various libraries and technologies, and it looks like 9 CVEs have been assigned since the initial release. I couldn’t verify all 130 PoCs, but the write-up provides a good synopsis of the affected technologies and one or two interesting exploits.

The writeup also says that the bikini actor is related to ShinyHunters, but I don’t really know how they’ve made that connection from the repository and their writeup.

AsyncRAT Family Threat Overview by Aidan Holland

AsyncRAT is a malware family used as a remote access trojan that originated as an open-source tool in 2019. I was not aware of the lineage of AsyncRAT variants, so reading up on how the malware has been cloned, forked, and developed over the last seven years was a fantastic technical detail that Holland includes in this post. The research here demonstrates how you can analyze variants and their source code to create attacker infrastructure-hunting rules for tools like Censys. Across the 40 variants, Holland found 13 live variants deployed across the Internet using Censys data.

🔗 Open Source

aaronphifer/triagewall

Phifer’s triagewall project listed in State of the Art above. It’s set up like a home lab, so you can clone this repository and get the rules and LLM triage features out of the box.

iimp0ster/detection-chokepoints

GitHub repository for Bohlmann’s chokepoints blog listed above. It runs the https://iimp0ster.github.io/detection-chokepoints/ website, which is a lolbins style website to go and view “invariant prerequisites” of certain attack techniques that you can build detections around.
As a BJJ purple belt, I love the bitmap art at the top of the repo :).

badchars/darknet-mcp-server

Self-hosted MCP server that connects services for “darknet” research. It exposes tools for all kinds of services around vulnerability research, breach data lookup, malware analysis, ransomware.live and even hooks into Tor. It’s not darknet-like the dark web, more about threat research, but still useful nonetheless if you want a single prompt to hit all these different OSINT-style tools.

28Zaaky/khaos-c2

Khaos is yet another post-exploitation framework, but the differentiator on this particular one is its heavy use of cloud and CDN services. It has the usual features you see in a C2 agent for Windows: indirect syscalls, patching ETW, and other evasion techniques. Maybe I just like the UI the most :)

Artificial intelligence (AI) is changing the enterprise faster than most security models were built to handle. In just a few years, it has become part of everyday enterprise work. And soon, AI agents will do much more than provide assistance. They will act autonomously across applications, workflows, data stores and infrastructure.

This shift is already changing the security conversation – as it should. When agents can act on behalf of users, systems and business processes, identity is no longer a supporting layer of cybersecurity. It becomes the control plane for deciding who or what can act, what they can access, how much privilege they should have and when that access should be removed. Fragmented tools weren’t built to support this level of real-time visibility and control. It requires a unified identity security platform.

Palo Alto Networks recent acquisition of CyberArk reflects our conviction that identity is a core platform pillar for securing the future of AI. Identity security is now a foundational layer across our portfolio, building on CyberArk's trusted privileged access management (PAM) heritage and extending it to address the complexity of hybrid, cloud-native, and AI-driven environments. It also advances Palo Alto Networks broader platformization strategy, driven by customer demand for integrated, AI-powered security solutions that reduce complexity and close gaps created by disparate point products.

For partners, the launch of Idira™, our next-generation identity security platform, represents a significant opportunity to help customers secure access, privilege and identity risk through a more unified platform approach. More than ever, our customers need knowledgeable, trusted advisers to help them rethink how identity connects to the rest of their security architecture across network security, cloud, security operations (SecOps) and the broader AI-enabled enterprise.

Identity Security is No Longer Human-Centered

Research for our 2026 Identity Security Landscape report found that 96% of organizations have human identities operating with access far beyond what is required for their roles. That finding is unsettling enough, but also consider how modern identity security must account for far more than human users and privileged administrators. It includes machine identities and AI agent identities, ranging from service accounts, workloads and APIs to secrets and certificates and to agents operating across multiple systems.

Our recent report on identity security also notes that there are now roughly 109 machine identities for every human identity. Each identity can carry privilege, create risk and expand the attack surface. That scale makes real-time discovery, governance and control of identities essential. Yet many organizations are still managing privilege in ways that weren’t built for the AI era. When identities can act across systems and attacks can move faster, standing privilege (i.e., always-on access rights granted to users or machines) becomes harder to defend.

The premise of Idira is that every identity within an enterprise is privileged. The platform helps enterprises move from the traditional operating model of human-centered identity architectures and static access tools to embrace one platform that secures every identity – human, machine and AI agent. Idira discovers identities, entitlements and access paths, dynamically applies privileges through just-in-time controls and continuously governs identity lifecycles.

These capabilities become even more crucial as customers work to reduce fragmentation across their security environments. They want better visibility, faster time to value, stronger controls and a simpler way to manage risk across the enterprise. They still need advisory, implementation and managed services expertise, but the conversation is no longer limited to firewalls, privileged access, cloud workloads or SOC operations in isolation. Customers want expert help in connecting these areas into a unified strategy that reflects how their environments actually operate, especially with AI in the mix.

The Identity Security Opportunity for Partners

My message to partners following our launch of Idira is simple but direct: Now is the time to seize this defining moment in identity security. The speed of business is accelerating, as is the speed of attacks. And we know many of our customers around the world are already trying to understand what AI means for their security architecture, operating model and risk posture.

Partners can help lead those conversations with customers. For specialized and regional partners, this might mean expanding the advisory conversation beyond a single domain of cybersecurity. For global systems integrators, it might involve creating a more scalable delivery model by reducing the cost and complexity of stitching together multiple vendor environments. We are also actively welcoming partners into the broader Palo Alto Networks ecosystem, creating new opportunities for identity-focused partners to expand their role across the full platformization strategy.

Across partner types, the identity security opportunity is both strategic and economic. By connecting identity security to the broader Palo Alto Networks platform strategy, partners can expand services offerings, deepen customer relationships and build a stronger model for helping customers reduce complexity, improve visibility, strengthen controls and get to value faster. 

But first, sales teams, technical teams, solution consultants and managed service teams need to understand how Idira fits into the Palo Alto Networks platformization strategy and where identity security connects to customer priorities. That means taking full advantage of the sales demos, AI role plays, technical enablement and other active learning resources in Palo Alto Networks newly evolved NextWave program.

I encourage you to move quickly to build your understanding of Idira’s role in securing human, machine and AI agent identities and the shift from standing privilege to dynamic access. Be prepared to talk with customers about identity security in the context of cloud, network, SASE and SOC transformation, as you can be assured questions will be coming. Also, think about the services and offerings you can build around this opportunity. Identity security assessments, privilege modernization, machine identity protection, AI agent identity readiness and broader platformization road maps can all help customers take practical steps toward strengthening security in the rapidly evolving AI era.

Our partners play a frontline role in driving Palo Alto Networks platformization strategy and enabling our shared success. To help your teams educate customers about AI-related identity risk and how Idira can help them secure every identity in the enterprise, human or not, explore the latest resources, enablement and partner tools available through the NextWave Partner Portal.

Key Takeaways

• With the launch of Idira, identity security became a core pillar of Palo Alto Networks platformization strategy for the AI era.
• Idira helps organizations secure every identity – human, machine and AI agent – with dynamic access, continuous governance and real-time control.
• Partners have a timely opportunity to help customers reduce complexity, improve visibility and connect identity security to broader cloud, network, SASE and SecOps priorities.

The post A Defining Moment in Identity Security appeared first on Palo Alto Networks Blog.

Insufficient egress filtering is a commonly identified vulnerability found during BHIS penetration tests. The insufficient egress filtering finding indicates that network traffic leaving the organization’s environment is not properly restricted.

The post Insufficient Egress Filtering: How Weak Outbound Controls Enable Attacks appeared first on Black Hills Information Security, Inc..