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.

A cybersecurity startup dangling millions of dollars to acquire zero-day security vulnerabilities in popular software is run by a pair of far-right conspiracy theorists and convicted felons whose most recent ventures included fake intelligence companies and a now-defunct AI-based lobbying platform they operated under assumed names.

The X/Twitter account IRIS C2 (@C2IRIS) has gained more than 4,000 followers since its creation in January 2025, posting frequently about security vulnerabilities, AI and software exploits. IRIS C2 says it is a company in McLean, Va. that sells offensive cybersecurity capabilities.

The IRIS C2 website dangles the possibility of million-dollar payouts for exploits to attract talent.

“Our business model is this,” reads a pinned post on top of the IRIS C2 account on X. “Attract the very best vulnerability researchers and exploit developers in the world to join our company. This mostly revolves around junior engineers with raw talent/extremely high IQ. We don’t care if they have a college degree/industry experience.”

The website linked in that profile — irisc2[.]com — says the company is hiring for a number of open positions, and a recent post on its LinkedIn page enthuses about an overwhelming number of applications from potential employees. The website claims IRIS C2 is in the business of acquiring “zero-day exploits, individual primitives, partial chains, and full capabilities across all major platforms. Payouts range from $10,000 to $7 million depending on target, reliability, and operational value.”

The government contracting portal g2exchange.com reports that irisc2[.]com is operated by a business based in Virginia called Calvexa Group LLC. The “contact” link on the website for Calvexa Group — calvexagroup[.]com — forwards visitors to irisc2[.]com. G2Exchange shows that while Calvexa Group LLC is registered as a federal contractor, it does not appear to be working on any direct government contracts.

A search on the Arlington, Va. address listed in the incorporation records for Calvexa Group LLC finds the property is occupied by Jack Burkman, the 60-year-old founder and managing partner of the lobbying firm Burkman & Associates. When approached with questions about IRIS C2, Burkman referred further inquiries to his longtime associate, 28-year-old Jacob Wohl.

Jack Burkman (left) and Jacob Wohl, at a press conference in August 2020. Image: Wikipedia.

Burkman and Wohl have a storied history of creating fake intelligence companies and using them to spread false claims about and frame public figures, including fabricated sexual assault claims against then FBI director Robert Mueller, and Pete Buttigieg, then mayor of South Bend, Indiana and a Democratic candidate for the presidency. In 2019, Burkman and Wohl held press conferences falsely alleging extramarital affairs by Sen. Elizabeth Warren (D-Mass.) and then-2020 presidential candidate Kamala Harris.

In the wake of the 2020 presidential election, Wohl and Burkman were prosecuted by multiple U.S. states for making thousands of robocalls to residents of battleground states and disseminating false claims about mail-in ballots. They were indicted in Cleveland on 15 felony counts of orchestrating a robocall scheme aimed at suppressing the black vote in Detroit, and were sentenced in late 2025 to probation after their appeals to dismiss the charges were rejected.

In 2022, Wohl and Burkman both pleaded guilty to a single felony charge of telecommunications fraud in Ohio, and sentenced to a fine, probation, and community service. In March 2023, a judge in a New York civil case ruled that Wohl and Burkman had violated federal and state civil rights laws, and the two agreed to pay a $1 million settlement.

In June 2023, the Federal Communications Commission (FCC) imposed a $5.1 million fine against Wohl and Burkman for their robocall campaigns, at the time the largest fine ever sought by the FCC under the Telephone Consumer Protection Act.

Jacob “Jay” Wohl’s GitHub account.

By the age of 17, Wohl had started multiple investment firms, and cultivated the nickname “Wohl of Wall Street” after appearing on Fox News in 2015 to discuss his new hedge funds. In 2017, the Arizona Corporation Commission charged Wohl and his investment funds with 14 counts of securities fraud, and ordered him to pay $35,000 in restitution. In 2019, Wohl pleaded guilty in California to four felony counts of selling unregistered securities and was sentenced to two years of probation.

The market for previously unknown security vulnerabilities has always been populated by a colorful mix of researchers, academics, charlatans, clout-chasers and people actively involved in cybercrime communities. But the market for selling offensive security services to the U.S. government tends to be far more circumspect. Plenty of government contractors recruit vulnerability researchers and pay for the exclusive rights to novel software exploits, yet none of them do so quite as brazenly and openly as IRIS C2.

Recent posts from the Twitter/X account IRISC2 (@c2iris).

Indeed, KrebsOnSecurity was unaware of IRIS C2 until last month, when an attendee at a regional cybersecurity conference shared that Wohl and Calvexa Group were pestering people at the conference about selling their vulnerability research.

In an interview with KrebsOnSecurity, Wohl said Mr. Burkman was not involved in the day-to-day operations of IRIS C2. Wohl shared that IRIS C2 originally began as a penetration testing company, but shifted its focus recently to selling phone-hacking services to the government. Several times throughout the interview, Mr. Wohl mentioned working on federal government contracts, but when pressed for specifics said he was not at liberty to speak publicly about them.

Mr. Wohl said he does not have any formal education or training in computer science or information security, and that most of his knowledge on the matter is self-taught.

“I know more about tech than anyone,” Wohl bragged. “My background has always been extremely technical, and I’ve always been deeply into tech. People know me as someone who is able to create spectacularly exquisite capabilities that would make your head spin.”

Wohl said security researchers bring the company unique vulnerability findings “on a regular basis,” but that in many cases those findings are preliminary and not fully fleshed-out.

“Let’s say someone finds a flaw in a media decoder on a phone,” Wohl said. “A lot of times what we receive is an exploit primitive, where the idea is there but the [execution] needs work. You need that exploit to be stable and reliable, and that’s what we do.”

Wohl claims IRIS C2 has approximately 40 employees, although he said none of them are allowed to list their employment on LinkedIn for operational security reasons. In May, the author of the IRIS C2 account on X said that his girlfriend had no idea what he did for a living. But if IRIS C2 has any other employees, they may be similarly unaware of Mr. Wohl’s history of outright fabrications — or even his real name.

In September 2024, Politico reported that Burkman and Wohl were bragging about big companies supposedly buying services from their now-defunct company LobbyMatic, which claimed to use artificial intelligence to assist in political lobbying efforts. However, Politico found the pair were running the company using pseudonyms, with Wohl reportedly adopting the name “Jay Klein” and Burkman using the moniker “Bill Sanders.” Politico reported that two of the former LobbyMatic employees resigned after learning of their true identities, while other employees only learned after they had left the company.

Update, July 9, 9:44 a.m. ET: Several readers pointed our attention to a March 31 publication from journalist Molly White, which reported that Burkman and Wohl were paid a $300,000 retainer by a Canadian cryptocurrency fraudster wanted by the United States and several other countries for allegedly stealing $65 million from the crypto platforms KyberSwap and Indexed Finance. According to that report, the two were hired to pursue a “presidential pardon to avert a miscarriage of justice” on behalf of the accused hacker, who has not yet been convicted.

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.

The Federal Bureau of Investigation (FBI) said today it worked with industry partners to seize hundreds of domains associated with NetNut, a sprawling residential proxy service operated by the publicly-traded Israeli company Alarum Technologies [NASDAQ: ALAR]. The action comes roughly two weeks after KrebsOnSecurity published findings from multiple security firms connecting NetNut to the Popa botnet, a collection of at least two million devices that have been compromised by malicious software with little or no consent from victims.

The NetNut homepage today was replaced by this seizure banner from the FBI.

On June 19, three different security firms issued similar findings: That NetNut is a residential proxy network which populates a botnet called Popa, and distributes software for devices commonly found in homes, such as smart TVs and streaming boxes. NetNut’s software turns those systems into always-on residential proxy nodes that are rented to others, who predominantly use them to relay abusive and intrusive Internet traffic, such as mass content scraping, advertising fraud, and account takeover activity.

Earlier today, NetNut’s homepage was replaced with a seizure notice from the FBI and the Internal Revenue Service Criminal Investigation division. The seizure notice thanked Google, Lumen, Shadowserver and other industry partners for their help in dismantling hundreds of domains tied to the Popa botnet, which experts say has long been synonymous with NetNut’s residential proxy infrastructure.

In a blog post published today, the Google Threat Intelligence Group (GTIG) said NetNut’s proxy network is widely resold and white-labeled by a number of third-party proxy providers, and that its services are heavily sought out by cybercriminals seeking to obfuscate the source of their malicious traffic. The GTIG said that in a single week during June 2026, they observed 316 distinct clusters of threat actors using suspected NetNut exit nodes, including cybercriminal and espionage groups.

“These bad actors can use NetNut to mask their origin IP address when accessing victim environments, accessing their own infrastructure, and conducting password spray attacks,” Google’s GTIG wrote. “Furthermore, when a consumer device becomes an exit node, unauthorized network traffic passes through it. This means bad actors can access other private devices on the same home network, effectively exposing them to Internet threats.”

Google said it disabled Google accounts and services used by NetNut for malware command and control, and that it shared technical intelligence on NetNut’s software development kits (SDKs) and backend infrastructure with platform providers, law enforcement and research firms. The company also disabled apps known to bundle NetNut’s various SDKs.

Omer Weiss, legal counsel for NetNut parent Alarum Technologies, said the company was aware of the FBI seizure and cooperating with investigators.

“Alarum takes this matter seriously and will fully cooperate with law enforcement to ensure any misuse of its infrastructure is thoroughly investigated and those responsible are held to account,” Weiss said in a written statement.

Benjamin Brundage is founder of the proxy tracking service Synthient, one of the companies that published evidence last month linking the Popa botnet to NetNut and Alarum Technologies. Brundage said the domain seizures appear to have disrupted both the Popa botnet and the NetNut proxy network that rides on top of it.

Brundage said NetNut’s apparent demise is likely to be a great disadvantage for the cybercrime community, which was already reeling from legal actions by Google earlier this year that seized infrastructure for NetNut’s biggest competitor — IPIDEA.

“I think this takedown is going to have a big impact, because NetNut gained significant popularity after the IPIDEA takedown,” he said. “Also NetNut has been incredibly common among resellers, and they were on par with IPIDEA in terms of their daily traffic, quality, size, price per gigabyte, all of it.”

NetNut’s infrastructure, in a nutshell. Image: Black Lotus Labs, Lumen.

The NetNut and Popa botnet takedown may have another added benefit, Brundage said: Lessening the impact of large distributed denial-of-service botnets that have been built on the backs of poorly configured residential proxy services. In January, Synthient revealed how cybercriminals had built the world’s largest DDoS botnet (Kimwolf) by tunneling through IPIDEA proxy connections into the local networks of TV box owners, and infecting other Android-based devices behind the victim’s firewall.

While many of the bigger proxy providers took steps to block this activity, resellers of the major proxy networks have been far slower to respond to the threat, Brundage said.

“In terms of all these TV box devices getting compromised from the proxy network, it will have an impact on the DDoS botnets out there,” he said.

For its part, Google reckons today’s actions have caused “significant degradation to NetNut’s proxy network and its business operations, reducing the available pool of devices for the proxy operator by millions.” But the company warns that proxy networks can rebuild themselves by effectively reselling other proxy services, as IPIDEA has done over the past few months.

“Google has high confidence that many popular residential proxy brands are in fact whitelabeling the NetNut botnet,” the GTIG report concludes. “While we expect this disruption to have a larger ripple effect across the residential proxy ecosystem, observations after the disruption of IPIDEA proved that individual networks can appear resilient. What we have observed is that when faced with the degradation of their own botnet, proxy operators begin buying capacity from their competitors, effectively becoming a reseller. We recognize that creating a lasting disruption in this fluid ecosystem means we must scale our efforts to target the infrastructure of several interconnected providers.”

As KrebsOnSecurity has warned repeatedly, most of the no-name TV streaming boxes for sale on the major e-commerce websites either come pre-installed with residential proxy software, or require the installation of proxy SDKs in order to use the device for its stated purpose (streaming pirated movies, sporting events and TV shows). Google’s advice here is sound: When it comes to TV boxes, stick to name brands from reputable manufacturers, and then be sparing and judicious with any apps you choose to install.

The sketchy TV boxes that are being commandeered by the Popa botnet and other threats all come with or require the user to install unofficial Android operating systems that do not operate within the confines of Google’s Official Play Protect store. Google says consumers can confirm whether or not a device is built with the official Android TV OS and Play Protect certification by following these instructions.

Even people without TV streaming boxes can find their smart TVs enrolled in residential proxy networks, just by installing one of thousands of apps available for download on Samsung and LG smart TVs. In a report released last month, the proxy tracking company Spur found 42 percent of apps available for download via the webOS operating system on LG smart TVs include SDKs that turn one’s television into an always-on residential proxy node. More than a quarter of the apps made for Samsung’s Tizen operating system had similar residential proxy components, Spur found.

Image: Spur.us.

Update, 4:24 p.m. ET: Included a statement shared post-publication from an attorney representing NetNut parent Alarum Technologies.

Update, July 8, 2:34 p.m. ET: The website for Alarum Technologies — alarum[.]io — now also features a seizure notice from the FBI. The company’s stock has taken a beating since the FBI action, and is currently trading at $2.62 a share, a roughly 67 percent decline over the past week.

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.

• Update: base64dump.py Version 0.0.30

• Microsoft’s Coreutils for Windows
• Evil MSI Background: BASE64 Statistical Analysis
• YARA-X 1.18.0 and 1.19.0 Release

This new version adds option –stats. For more details, take a look at SANS Internet Storm Center diary entry “Evil MSI Background: BASE64 Statistical Analysis“.