Algorithm Protection in the Context of Federated Learning

Stay Ahead, Stay ONMINE

Algorithm Protection in the Context of Federated Learning

While working at a biotech company, we aim to advance ML & AI Algorithms to enable, for example, brain lesion segmentation to be executed at the hospital/clinic location where patient data resides, so it is processed in a secure manner. This, in essence, is guaranteed by federated learning mechanisms, which we have adopted in numerous real-world hospital settings. However, when an algorithm is already considered as a company asset, we also need means that protect not only sensitive data, but also secure algorithms in a heterogeneous federated environment. Fig.1 High-level workflow and attack surface. Image by author Most algorithms are assumed to be encapsulated within docker-compatible containers, allowing them to use different libraries and runtimes independently. It is assumed that there is a 3rd party IT administrator who will aim to secure patients’ data and lock the deployment environment, making it inaccessible for algorithm providers. This perspective describes different mechanisms intended to package and protect containerized workloads against theft of intellectual property by a local system administrator. To ensure a comprehensive approach, we will address protection measures across three critical layers: Algorithm code protection: Measures to secure algorithm code, preventing unauthorized access or reverse engineering. Runtime environment: Evaluates risks of administrators accessing confidential data within a containerized system. Deployment environment: Infrastructure safeguards against unauthorized system administrator access. Fig.2 Different layers of protection. Image by author Methodology After analysis of risks, we have identified two protection measures categories: Intellectual property theft and unauthorized distribution: preventing administrator users from accessing, copying, executing the algorithm. Reverse engineering risk reduction: blocking administrator users from analyzing code to uncover and claim ownership. While understanding the subjectivity of this assessment, we have considered both qualitative and quantitative characteristics of all mechanisms. Qualitative assessment Categories mentioned were considered when selecting suitable solution and are considered in summary: Hardware dependency: potential lock-in and scalability challenges in federated systems. Software dependency: reflects maturity and long-term stability Hardware and Software dependency: measures setup complexity, deployment and maintenance effort Cloud dependency: risks of lock-in with a single cloud hypervisor Hospital environment: evaluates technology maturity and requirements heterogeneous hardware setups. Cost: covers for dedicated hardware, implementation and maintenance Quantitative assessment Subjective risk reduction quantitative assessment description: Considering the above methodology and assessment criteria, we came up with a list of mechanisms that have the potential to guarantee the objective. Confidential containers Confidential Containers (CoCo) is an emerging CNCF technology that aims to deliver confidential runtime environments that will run CPU and GPU workloads while protecting the algorithm code and data from the hosting company. CoCo supports multiple TEE, including Intel TDX/SGX and AMD SEV hardware technologies, including extensions of NVidia GPU operators, that use hardware-backed protection of code and data during its execution, preventing scenarios in which a determined and skillful local administrator uses a local debugger to dump the contents of the container memory and has access to both the algorithm and data being processed. Trust is built using cryptographic attestation of runtime environment and code that is executed. It makes sure the code is not tempered with nor read by remote admin. This appears to be a perfect fit for our problem, as the remote data site admin would not be able to access the algorithm code. Unfortunately, the current state of the CoCo software stack, despite continuous efforts, still suffers from security gaps that enable the malicious administrators to issue attestation for themselves and effectively bypass all the other protection mechanisms, rendering all of them effectively useless. Each time the technology gets closer to practical production readiness, a new fundamental security issue is discovered that needs to be addressed. It is worth noting that this community is fairly transparent in communicating gaps. The often and rightfully recognized additional complexity introduced by TEEs and CoCo (specialized hardware, configuration burden, runtime overhead due to encryption) would be justifiable if the technology delivered on its promise of code protection. While TEE seems to be well adopted, CoCo is close but not there yet and based on our experiences the horizon keeps on moving, as new fundamental vulnerabilities are discovered and need to be addressed. In other words, if we had production-ready CoCo, it would have been a solution to our problem. Host-based container image encryption at rest (protection at rest and in transit) This strategy is based on end-to-end protection of container images containing the algorithm. It protects the source code of the algorithm at rest and in transit but does not protect it at runtime, as the container needs to be decrypted prior to the execution. The malicious administrator at the site has direct or indirect access to the decryption key, so he can read container contents just after it is decrypted for the execution time. Another attack scenario is to attach a debugger to the running container image. So host-based container image encryption at rest makes it harder to steal the algorithm from a storage device and in transit due to encryption, but moderately skilled administrators can decrypt and expose the algorithm. In our opinion, the increased practical effort of decrypting the algorithm (time, effort, skillset, infrastructure) from the container by the administrator who has access to the decryption key is too low to be considered as a valid algorithm protection mechanism. Prebaked custom virtual machine In this scenario the algorithm owner is delivering an encrypted virtual machine. The key can be added at boot time from the keyboard by someone else than admin (required at each reboot), from external storage (USB Key, very vulnerable, as anyone with physical access can attach the key storage), or using a remote SSH session (using Dropbear for instance) without allowing local admin to unlock the bootloader and disk. Effective and established technologies such as LUKS can be used to fully encrypt local VM filesystems including bootloader. However, even if the remote key is provided using a boot-level tiny SSH session by someone other than a malicious admin, the runtime is exposed to a hypervisor-level debugger attack, as after boot, the VM memory is decrypted and can be scanned for code and data. Still, this solution, especially with remotely provided keys by the algorithm owner, provides significantly increased algorithm code protection compared to encrypted containers because an attack requires more skills and determination than just decrypting the container image using a decryption key. To prevent memory dump analysis, we considered deploying a prebaked host machine with ssh possessed keys at boot time, this removes any hypervisor level access to memory. As a side note, there are methods to freeze physical memory modules to delay loss of data. Distroless container images Distroless container images are reducing the number of layers and components to a minimum required to run the algorithm. The attack surface is greatly reduced, as there are fewer components prone to vulnerabilities and known attacks. They are also lighter in terms of storage, network transmission, and latency. However, despite these improvements, the algorithm code is not protected at all. Distroless containers are recommended as more secure containers but not the containers that protect the algorithm, as the algorithm is there, container image can be easily mounted and algorithm can be stolen without a significant effort. Being distroless does not address our goal of protecting the algorithm code. Compiled algorithm Most machine learning algorithms are written in Python. This interpreted language makes it really easy not only to execute the algorithm code on other machines and in other environments but also to access source code and be able to modify the algorithm. The potential scenario even enables the party that steals the algorithm code to modify it, let’s say 30% or more of the source code, and claim it’s no longer the original algorithm, and could even make a legal action much harder to provide evidence of intellectual property infringement. Compiled languages, such as C, C++, Rust, when combined with strong compiler optimization (-O3 in the case of C, linker-time optimizations), make the source code not only unavailable as such, but also much harder to reverse engineer source code. Compiler optimizations introduce significant control flow changes, mathematical operations substitutions, function inlining, code restructuring, and difficult stack tracing. This makes it much harder to reverse engineer the code, making it a practically infeasible option in some scenarios, thus it can be considered as a way to increase the cost of reverse engineering attack by orders of magnitude compared to plain Python code. There’s an increased complexity and skill gap, as most of the algorithms are written in Python and would have to be converted to C, C++ or Rust. This option does increase the cost of further development of the algorithm and even modifying it to make a claim of its ownership but it does not prevent the algorithm from being executed outside of the agreed contractual scope. Code obfuscation The established technique of making the code much less readable, harder to understand and develop further can be used to make algorithm evolutions much harder. Unfortunately, it does not prevent the algorithm from being executed outside of contractual scope. Also, the de-obfuscation technologies are getting much better, thanks to advanced language models, lowering the practical effectiveness of code obfuscation. Code obfuscation does increase the practical cost of algorithm reverse engineering, so it’s worth considering as an option combined with other options (for instance, with compiled code and custom VMs). Homomorphic Encryption as code protection mechanism Homomorphic Encryption (HE) is a promised technology aimed at protecting the data, very interesting from secure aggregation strategies of partial results in Federated Learning and analytics scenarios. The aggregation party (with limited trust) can only process encrypted data and perform encrypted aggregations, then it can decrypt aggregated results without being able to decrypt any individual data. Practical applications of HE are limited due to its complexity, performance hits, limited number of supported operations, there’s observable progress (including GPU acceleration for HE) but still it’s a niche and emerging data protection technique. From an algorithm protection goal perspective, HE is not designed, nor can be made to protect the algorithm. So it’s not an algorithm protection mechanism at all. Conclusions Fig.3 Risk reduction scores, Image by author In essence, we described and assessed strategies and technologies to protect algorithm IP and sensitive data in the context of deploying Medical Algorithms and running them in potentially untrusted environments, such as hospitals. What’s visible, the most promising technologies are those that provide a degree of hardware isolation. However those make an algorithm provider completely dependent on the runtime it will be deployed. While compilation and obfuscation do not mitigate completely the risk of intellectual property theft, especially even basic LLM seem to be helpful, those methods, especially when combined, make algorithms very difficult, thus expensive, to use and modify the code. Which would already provide a degree of security. Prebaked host/virtual machines are the most common and adopted methods, extended with features like full disk encryption with keys acquired during boot via SSH, which could make it fairly difficult for local admin to access any data. However, especially pre-baked machines could cause certain compliance concerns at the hospital, and this needs to be assessed prior to establishing a federated network. Key Hardware and Software vendors(Intel, AMD, NVIDIA, Microsoft, RedHat) recognized significant demand and continue to evolve, which gives a promise that training IP-protected algorithms in a federated manner, without disclosing patients’ data, will soon be within reach. However, hardware-supported methods are very sensitive to hospital internal infrastructure, which by nature is quite heterogeneous. Therefore, containerisation provides some promise of portability. Considering this, Confidential Containers technology seems to be a very tempting promise provided by collaborators, while it’s still not fullyproduction-readyy. Certainly combining above mechanisms, code, runtime and infrastructure environment supplemented with proper legal framework decrease residual risks, however no solution provides absolute protection particularly against determined adversaries with privileged access – the combined effect of these measures creates substantial barriers to intellectual property theft. We deeply appreciate and value feedback from the community helping to further steer future efforts to develop sustainable, secure and effective methods for accelerating AI development and deployment. Together, we can tackle these challenges and achieve groundbreaking progress, ensuring robust security and compliance in various contexts. Contributions: The author would like to thank Jacek Chmiel, Peter Fernana Richie, Vitor Gouveia and the Federated Open Science team at Roche for brainstorming, pragmatic solution-oriented thinking, and contributions. Link & Resources Intel Confidential Containers Guide Nvidia blog describing integration with CoCo Confidential Containers Github & Kata Agent Policies Commercial Vendors: Edgeless systems contrast, Redhat & Azure Remote Unlock of LUKS encrypted disk A perfect match to elevate privacy-enhancing healthcare analytics Differential Privacy and Federated Learning for Medical Data

Fig.1 High-level workflow and attack surface. Image by author

Most algorithms are assumed to be encapsulated within docker-compatible containers, allowing them to use different libraries and runtimes independently. It is assumed that there is a 3rd party IT administrator who will aim to secure patients’ data and lock the deployment environment, making it inaccessible for algorithm providers. This perspective describes different mechanisms intended to package and protect containerized workloads against theft of intellectual property by a local system administrator.

To ensure a comprehensive approach, we will address protection measures across three critical layers:

Algorithm code protection: Measures to secure algorithm code, preventing unauthorized access or reverse engineering.
Runtime environment: Evaluates risks of administrators accessing confidential data within a containerized system.
Deployment environment: Infrastructure safeguards against unauthorized system administrator access.

Fig.2 Different layers of protection. Image by author

Methodology

After analysis of risks, we have identified two protection measures categories:

Intellectual property theft and unauthorized distribution: preventing administrator users from accessing, copying, executing the algorithm.
Reverse engineering risk reduction: blocking administrator users from analyzing code to uncover and claim ownership.

While understanding the subjectivity of this assessment, we have considered both qualitative and quantitative characteristics of all mechanisms.

Qualitative assessment

Categories mentioned were considered when selecting suitable solution and are considered in summary:

Hardware dependency: potential lock-in and scalability challenges in federated systems.
Software dependency: reflects maturity and long-term stability
Hardware and Software dependency: measures setup complexity, deployment and maintenance effort
Cloud dependency: risks of lock-in with a single cloud hypervisor
Hospital environment: evaluates technology maturity and requirements heterogeneous hardware setups.
Cost: covers for dedicated hardware, implementation and maintenance

Quantitative assessment

Subjective risk reduction quantitative assessment description:

Considering the above methodology and assessment criteria, we came up with a list of mechanisms that have the potential to guarantee the objective.

Confidential containers

Confidential Containers (CoCo) is an emerging CNCF technology that aims to deliver confidential runtime environments that will run CPU and GPU workloads while protecting the algorithm code and data from the hosting company.

CoCo supports multiple TEE, including Intel TDX/SGX and AMD SEV hardware technologies, including extensions of NVidia GPU operators, that use hardware-backed protection of code and data during its execution, preventing scenarios in which a determined and skillful local administrator uses a local debugger to dump the contents of the container memory and has access to both the algorithm and data being processed.

Trust is built using cryptographic attestation of runtime environment and code that is executed. It makes sure the code is not tempered with nor read by remote admin.

This appears to be a perfect fit for our problem, as the remote data site admin would not be able to access the algorithm code. Unfortunately, the current state of the CoCo software stack, despite continuous efforts, still suffers from security gaps that enable the malicious administrators to issue attestation for themselves and effectively bypass all the other protection mechanisms, rendering all of them effectively useless. Each time the technology gets closer to practical production readiness, a new fundamental security issue is discovered that needs to be addressed. It is worth noting that this community is fairly transparent in communicating gaps.

The often and rightfully recognized additional complexity introduced by TEEs and CoCo (specialized hardware, configuration burden, runtime overhead due to encryption) would be justifiable if the technology delivered on its promise of code protection. While TEE seems to be well adopted, CoCo is close but not there yet and based on our experiences the horizon keeps on moving, as new fundamental vulnerabilities are discovered and need to be addressed.

In other words, if we had production-ready CoCo, it would have been a solution to our problem.

Host-based container image encryption at rest (protection at rest and in transit)

This strategy is based on end-to-end protection of container images containing the algorithm.

It protects the source code of the algorithm at rest and in transit but does not protect it at runtime, as the container needs to be decrypted prior to the execution.

The malicious administrator at the site has direct or indirect access to the decryption key, so he can read container contents just after it is decrypted for the execution time.

Another attack scenario is to attach a debugger to the running container image.

So host-based container image encryption at rest makes it harder to steal the algorithm from a storage device and in transit due to encryption, but moderately skilled administrators can decrypt and expose the algorithm.

In our opinion, the increased practical effort of decrypting the algorithm (time, effort, skillset, infrastructure) from the container by the administrator who has access to the decryption key is too low to be considered as a valid algorithm protection mechanism.

Prebaked custom virtual machine

In this scenario the algorithm owner is delivering an encrypted virtual machine.

The key can be added at boot time from the keyboard by someone else than admin (required at each reboot), from external storage (USB Key, very vulnerable, as anyone with physical access can attach the key storage), or using a remote SSH session (using Dropbear for instance) without allowing local admin to unlock the bootloader and disk.

Effective and established technologies such as LUKS can be used to fully encrypt local VM filesystems including bootloader.

However, even if the remote key is provided using a boot-level tiny SSH session by someone other than a malicious admin, the runtime is exposed to a hypervisor-level debugger attack, as after boot, the VM memory is decrypted and can be scanned for code and data.

Still, this solution, especially with remotely provided keys by the algorithm owner, provides significantly increased algorithm code protection compared to encrypted containers because an attack requires more skills and determination than just decrypting the container image using a decryption key.

To prevent memory dump analysis, we considered deploying a prebaked host machine with ssh possessed keys at boot time, this removes any hypervisor level access to memory. As a side note, there are methods to freeze physical memory modules to delay loss of data.

Distroless container images

Distroless container images are reducing the number of layers and components to a minimum required to run the algorithm.

The attack surface is greatly reduced, as there are fewer components prone to vulnerabilities and known attacks. They are also lighter in terms of storage, network transmission, and latency.

However, despite these improvements, the algorithm code is not protected at all.

Distroless containers are recommended as more secure containers but not the containers that protect the algorithm, as the algorithm is there, container image can be easily mounted and algorithm can be stolen without a significant effort.

Being distroless does not address our goal of protecting the algorithm code.

Compiled algorithm

Most machine learning algorithms are written in Python. This interpreted language makes it really easy not only to execute the algorithm code on other machines and in other environments but also to access source code and be able to modify the algorithm.

The potential scenario even enables the party that steals the algorithm code to modify it, let’s say 30% or more of the source code, and claim it’s no longer the original algorithm, and could even make a legal action much harder to provide evidence of intellectual property infringement.

Compiled languages, such as C, C++, Rust, when combined with strong compiler optimization (-O3 in the case of C, linker-time optimizations), make the source code not only unavailable as such, but also much harder to reverse engineer source code.

Compiler optimizations introduce significant control flow changes, mathematical operations substitutions, function inlining, code restructuring, and difficult stack tracing.

This makes it much harder to reverse engineer the code, making it a practically infeasible option in some scenarios, thus it can be considered as a way to increase the cost of reverse engineering attack by orders of magnitude compared to plain Python code.

There’s an increased complexity and skill gap, as most of the algorithms are written in Python and would have to be converted to C, C++ or Rust.

This option does increase the cost of further development of the algorithm and even modifying it to make a claim of its ownership but it does not prevent the algorithm from being executed outside of the agreed contractual scope.

Code obfuscation

The established technique of making the code much less readable, harder to understand and develop further can be used to make algorithm evolutions much harder.

Unfortunately, it does not prevent the algorithm from being executed outside of contractual scope.

Also, the de-obfuscation technologies are getting much better, thanks to advanced language models, lowering the practical effectiveness of code obfuscation.

Code obfuscation does increase the practical cost of algorithm reverse engineering, so it’s worth considering as an option combined with other options (for instance, with compiled code and custom VMs).

Homomorphic Encryption as code protection mechanism

Homomorphic Encryption (HE) is a promised technology aimed at protecting the data, very interesting from secure aggregation strategies of partial results in Federated Learning and analytics scenarios.

The aggregation party (with limited trust) can only process encrypted data and perform encrypted aggregations, then it can decrypt aggregated results without being able to decrypt any individual data.

Practical applications of HE are limited due to its complexity, performance hits, limited number of supported operations, there’s observable progress (including GPU acceleration for HE) but still it’s a niche and emerging data protection technique.

From an algorithm protection goal perspective, HE is not designed, nor can be made to protect the algorithm. So it’s not an algorithm protection mechanism at all.

Conclusions

Chart — Fig.3 Risk reduction scores, Image by author

In essence, we described and assessed strategies and technologies to protect algorithm IP and sensitive data in the context of deploying Medical Algorithms and running them in potentially untrusted environments, such as hospitals.

What’s visible, the most promising technologies are those that provide a degree of hardware isolation. However those make an algorithm provider completely dependent on the runtime it will be deployed. While compilation and obfuscation do not mitigate completely the risk of intellectual property theft, especially even basic LLM seem to be helpful, those methods, especially when combined, make algorithms very difficult, thus expensive, to use and modify the code. Which would already provide a degree of security.

Prebaked host/virtual machines are the most common and adopted methods, extended with features like full disk encryption with keys acquired during boot via SSH, which could make it fairly difficult for local admin to access any data. However, especially pre-baked machines could cause certain compliance concerns at the hospital, and this needs to be assessed prior to establishing a federated network.

Key Hardware and Software vendors(Intel, AMD, NVIDIA, Microsoft, RedHat) recognized significant demand and continue to evolve, which gives a promise that training IP-protected algorithms in a federated manner, without disclosing patients’ data, will soon be within reach. However, hardware-supported methods are very sensitive to hospital internal infrastructure, which by nature is quite heterogeneous. Therefore, containerisation provides some promise of portability. Considering this, Confidential Containers technology seems to be a very tempting promise provided by collaborators, while it’s still not fullyproduction-readyy.

Certainly combining above mechanisms, code, runtime and infrastructure environment supplemented with proper legal framework decrease residual risks, however no solution provides absolute protection particularly against determined adversaries with privileged access – the combined effect of these measures creates substantial barriers to intellectual property theft.

We deeply appreciate and value feedback from the community helping to further steer future efforts to develop sustainable, secure and effective methods for accelerating AI development and deployment. Together, we can tackle these challenges and achieve groundbreaking progress, ensuring robust security and compliance in various contexts.

Contributions: The author would like to thank Jacek Chmiel, Peter Fernana Richie, Vitor Gouveia and the Federated Open Science team at Roche for brainstorming, pragmatic solution-oriented thinking, and contributions.

Link & Resources

Intel Confidential Containers Guide

Nvidia blog describing integration with CoCo Confidential Containers Github & Kata Agent Policies

Commercial Vendors: Edgeless systems contrast, Redhat & Azure

Remote Unlock of LUKS encrypted disk

A perfect match to elevate privacy-enhancing healthcare analytics

Differential Privacy and Federated Learning for Medical Data

Stay Ahead

Explore More Insights

Stay ahead with more perspectives on cutting-edge power, infrastructure, energy, bitcoin and AI solutions. Explore these articles to uncover strategies and insights shaping the future of industries.

Kyndryl extends Google Cloud partnership for AI-based mainframe modernization

“Many need to integrate mainframe data with the cloud and update applications to meet new security and compliance rules. Providers are using genAI-based code inspection to accelerate the discovery of code changes and modernization of legacy code,” ISG stated. “GenAI can inspect code and explain how it works, reducing and

Google Cloud partners with mLogica to offer mainframe modernization

Other than the partnership with mLogica, Google Cloud also offers a variety of other mainframe migration tools, including Radis and G4 that can be employed to modernize specific applications. Enterprises can also use a combination of migration tools to modernize their mainframe applications. Some of these tools include the Gemini-powered

Red Hat’s AI portfolio evolves to address enterprise deployment challenges

RHEL AI lets companies deploy workloads where they need them, including cloud, on premises, or on the edge, IDC analyst Michele Rosen says. “AI applications need to live as close as possible to their data,” she says. “For security, latency, and what have you. So you want to have a

Ethernet roadmap: AI drives high-speed, efficient Ethernet networks

“While the IEEE P802.3dj project is working toward defining 200G per lane for Ethernet by late 2026, the industry is (loudly) asking for 400G per lane yesterday, if not sooner,” Jones wrote in a recent Ethernet Alliance blog. In a post about Ethernet’s AI evolution, John D’Ambrosia wrote about the

Cnooc Profit Rises on Increased Oil and Gas Drilling Output

Cnooc Ltd. posted higher annual earnings and boosted its dividend, as growth in energy output offset weaker prices. Net income rose to 137.9 billion yuan ($19 billion) in 2024, from 123.9 billion yuan the previous year, China’s largest offshore oil-and-gas driller said in a filing. While that missed expectations of 144.6 billion yuan, and was shy of the record profit in 2022, the full-year dividend rose 12% to HK$1.40 (18 cents). Output expanded to 726.8 million barrels of oil equivalent, from 678 million barrels a year earlier, with overseas growth led by supplies from Guyana. The state-owned company has led Beijing’s efforts to enhance energy security and its operations have now delivered a sixth year of record production. Cnooc’s focus on extraction leaves its earnings heavily dependent on global oil prices, which averaged about 3% less in 2024 on-year. But it also means the company is relatively unaffected by headwinds to demand faced by downstream peers. Earlier this week, China’s biggest top, Sinopec, reported a tumble in profits as the electric-vehicle boom weighs on fuel consumption. At this point, the company will stick to its three-year output targets through to 2027, including a push to increase gas production, Vice Chairman Zhou Xinhuai said at a briefing. Among its overseas interests, Cnooc and Exxon Mobil Corp. have merged their arbitration claims against Chevron Corp.’s proposed takeover of Hess Corp., a deal that would allow the US oil supermajor to enter Guyana’s Stabroek Block. A first tribunal hearing is due in May. PetroChina Co. — the country’s largest oil and gas company, whose operations straddle drilling, refining and retail — reports earnings on Sunday. China’s energy giants are increasingly looking to natural gas to drive growth, although domestic prices have stumbled recently due a slowing economy and plethora of supply options, from domestic fields and gas

Supply Concerns Lift Oil Prices, Trade Tensions Persist

Oil edged higher as signs of tighter near-term supply-and-demand balances overshadowed an intensifying global trade war that threatens to crimp global energy consumption. West Texas Intermediate advanced 0.4% to settle just below $70 a barrel, continuing a three-week rally. A US government report on Wednesday showed the country’s stockpiles shrank by 3.34 million barrels last week to the lowest in a month, helping allay concerns of an oversupplied market. Oil has trended higher since early March as sanctions and tariffs from the Trump administration raise the potential for supply disruption from producers including Iran and Venezuela. Still, the Trump administration’s intensifying trade wars dragged on equities and limited gains for oil as the White House pushed ahead with tariffs on automakers and threatened harsher punishment on the European Union and Canada if they join forces against the US. Major oil traders including Trafigura Group and Gunvor Group are bearish on crude prices over the rest of the year due to rising supply, particularly from outside OPEC+. The producer group is also scheduled to start reviving idled output next month, the first in a series of planned hikes. Oil Prices: WTI for May delivery rose 0.4% to settle at $69.92 a barrel in New York. Brent for May settlement advanced 0.3% to settle at $74.03 a barrel. What do you think? We’d love to hear from you, join the conversation on the Rigzone Energy Network. The Rigzone Energy Network is a new social experience created for you and all energy professionals to Speak Up about our industry, share knowledge, connect with peers and industry insiders and engage in a professional community that will empower your career in energy. MORE FROM THIS AUTHOR Bloomberg

Secretary Wright Acts to Remove Red Tape, Accelerate Mission Execution at America’s National Weapons and Science Labs

SECRETARIAL ORDER FROM: CHRIS WRIGHT, U.S. SECRETARY OF ENERGY SUBJECT: Strengthening National Laboratory Efficiency and Mission Execution The Department of Energy’s National Laboratory system serves as the backbone of the Nation’s scientific enterprise. Founded as part of a strategic national investment in science during and following World War II, the National Laboratories form the most comprehensive research network of its kind. While most of the National Laboratories’ work is driven by the Department’s primary missions in energy innovation, science discovery, nuclear security, and environmental cleanup, they are a national resource and serve the national interest by addressing challenges extending beyond energy and catalyzing research that spans across sectors. As Federally Funded Research and Development Centers (FFRDC) managed through Management and Operating (M&O) contracts, it is imperative that we continually evaluate existing requirements and processes to ensure that the National Laboratories have the necessary authority and flexibility to successfully execute critical missions on behalf of the Department of Energy and the Nation. To that end, I am directing the following actions to be implemented immediately: Revise delegated project authority within DOE Order 413.3B from $50 million to $300 million specific to the National Laboratories managed under M&O contracts. Tailor DOE Order 413.3B to only require DOE independent project reviews at specific critical decision points on projects between $300 million – $1 billion, subject to sustained successful project execution. Capital asset projects with a total project cost of more than $1 billion shall continue to follow the full scope of requirements established in DOE Order 413.3B. Expand the use of the National Nuclear Security Administration’s successful “OSHA-Plus” framework for subcontracted construction projects at the National Laboratories. The framework uses a tailored, graded approach to meet Title 10 Code of Federal Regulations (CFR) Part 851, Worker Safety and Health Program, which increases competition

As offshore wind struggles, is advanced nuclear a viable Plan B for Eastern states?

Leaders of land-constrained, population-dense East Coast states have high hopes for offshore wind as they look toward self-imposed carbon-neutral electricity deadlines as early as 2035. But the Trump administration froze offshore wind leasing on Jan. 20, compounding the industry’s preexisting economic challenges, and the Environmental Protection Agency on March 14 revoked an air quality permit for the troubled 1.5-GW Atlantic Shores project off New Jersey. Though about 4.1 GW of capacity was under construction by last summer, according to the National Renewable Energy Laboratory, the new administration’s hostility raises questions about how much of the 80.5 GW “potential generating capacity” in the pipeline as of 2023 will actually get built. Some Eastern states now appear to be looking for a Plan B, or at least a hedge, in nuclear power, experts told Utility Dive. Last month, several — including New York, Maryland and Virginia — joined the National Association of State Energy Officials’s Advanced Nuclear First Mover Initiative, or ANFMI, which the Clean Air Task Force says will “develop supportive policies, coordinate with private stakeholders, and work toward unique procurement and financing options for nuclear energy projects.” State-level initiatives are proliferating across the region as well, such as a New York nuclear “master plan” and a Maryland bill that could provide direct financial support to nuclear power projects. “There’s been a lot of attention paid to what’s going on at the federal level, but it seems like a lot of the momentum going forward will be in the states,” said Zach Koshgarian, an analyst with the Nuclear Innovation Alliance. Getting the first movers together Formally announced in early February, ANFMI marks a significant step in interstate cooperation on new nuclear development. The 11-state consortium includes Democratic-controlled Eastern Seaboard states, like New York and Maryland; states with mixed political control, like

Northern Lights developers take phase two FID

The developers of Norway’s Northern Lights carbon transport and storage project have taken a final investment decision (FID) on phase two of the development. Shell, alongside its joint venture partners Equinor and TotalEnergies, aim to more than triple Northern Lights’ annual CO2 injection capacity to at least 5 million tonnes per year. This is comparable to more than 10% of the annual CO2 equivalent emissions in Norway. Based in Øygarden, Norway, Northern Lights will transport CO2 from industrial plants across Europe for storage 8,500 feet (2,600m) beneath the seabed in the Norwegian North Sea. It is part of the state-funded “Longship project”. With construction concluded late last year, the first customer injection of CO2 is expected this year from Heidelberg Materials’ cement factory in Brevik. Stockholm Exergi have booked a large volume of the added available capacity in phase two. The second phase represents an investment of $700m (£540m) from the project’s developers. This also includes the award of €131m (£109m) from the Connecting Europe Facility (CEF) funding scheme. Norske Shell managing director Marianne Olsnes said: “The expanded storage capacity of the Northern Lights site provides an attractive offering for European industrial emitters who might otherwise struggle to decarbonise. “Norway possesses a vast amount of CO2 storage capacity and has a highly skilled industry workforce with capability and capacity to build and operate CO2 transport and storage at scale.” In addition to Northern Lights, Shell is a partner in Scotland’s Acorn carbon capture and storage (CCS) project, alongside Storegga, Harbour Energy and North Sea Midstream Partners (NSMP). The developers have warned that the project is at risk due to delays in government support, following Rachel Reeves neglect of the energy industry in her recent Spring Statement. The Acorn project’s backers have called for the government to give firm support to

Shell CEO Says Pursuing Major Deal Risks Being a Distraction

Shell Plc Chief Executive Officer Wael Sawan said the UK energy company will continue to look for potential acquisitions, but warned of the risks inherent in pursuing a major deal. Speaking in a Bloomberg TV interview Tuesday, he declined to answer directly if Shell would consider looking at its rival BP Plc, but said “the bar is high” for any transaction. Sawan said he expects smaller-scale, bolt-on acquisitions when the company does get around to M&A, and that they would likely center around upstream production. “If you’re going to go for a big acquisition, one has to recognize that that can potentially distract,” Sawan said. Shell is always looking at dealmaking prospects in Europe and beyond, he added. It’s about “finding the right time to make the moves in what is a long journey for us.” Sawan spoke from New York Stock Exchange, where earlier he delivered an update to investors on Shell’s strategy. Despite speculation over whether the company might move its share listing across the Atlantic, the idea isn’t currently a live discussion, he said in the interview, reiterating recent comments from Shell on the matter. Shell and BP — which invested significantly in clean energy during the height of the environmental, social and governance movement — have been pushing to close the valuation gap with Exxon Mobil Corp. and Chevron Corp., which stuck with oil and gas. Since Sawan took the helm in 2023, Shell has retreated from its low-carbon strategy, ramped up its natural gas business and sharpened its focus on areas that generate high returns. BP, on the other hand, stuck with its push toward renewables and away from fossil fuels. Investors have made clear they prefer Shell’s approach. The company’s shares are up 17% over the past two years, giving it a market value

Former Arista COO launches NextHop AI for customized networking infrastructure

Sadana argued that unlike traditional networking where an IT person can just plug a cable into a port and it works, AI networking requires intricate, custom solutions. The core challenge is creating highly optimized, efficient networking infrastructure that can support massive AI compute clusters with minimal inefficiencies. How NextHop is looking to change the game for hyperscale networking NextHop AI is working directly alongside its hyperscaler customers to develop and build customized networking solutions. “We are here to build the most efficient AI networking solutions that are out there,” Sadana said. More specifically, Sadana said that NextHop is looking to help hyperscalers in several ways including: Compressing product development cycles: “Companies that are doing things on their own can compress their product development cycle by six to 12 months when they partner with us,” he said. Exploring multiple technological alternatives: Sadana noted that hyperscalers might try and build on their own and will often only be able to explore one or two alternative approaches. With NextHop, Sadana said his company will enable them to explore four to six different alternatives. Achieving incremental efficiency gains: At the massive cloud scale that hyperscalers operate, even an incremental one percent improvement can have an oversized outcome. “You have to make AI clusters as efficient as possible for the world to use all the AI applications at the right cost structure, at the right economics, for this to be successful,” Sadana said. “So we are participating by making that infrastructure layer a lot more efficient for cloud customers, or the hyperscalers, which, in turn, of course, gives the benefits to all of these software companies trying to run AI applications in these cloud companies.” Technical innovations: Beyond traditional networking In terms of what the company is actually building now, NextHop is developing specialized network switches

Microsoft abandons data center projects as OpenAI considers its own, hinting at a market shift

A potential ‘oversupply position’ In a new research note, TD Cowan analysts reportedly said that Microsoft has walked away from new data center projects in the US and Europe, purportedly due to an oversupply of compute clusters that power AI. This follows reports from TD Cowen in February that Microsoft had “cancelled leases in the US totaling a couple of hundred megawatts” of data center capacity. The researchers noted that the company’s pullback was a sign of it “potentially being in an oversupply position,” with demand forecasts lowered. OpenAI, for its part, has reportedly discussed purchasing billions of dollars’ worth of data storage hardware and software to increase its computing power and decrease its reliance on hyperscalers. This fits with its planned Stargate Project, a $500 billion, US President Donald Trump-endorsed initiative to build out its AI infrastructure in the US over the next four years. Based on the easing of exclusivity between the two companies, analysts say these moves aren’t surprising. “When looking at storage in the cloud — especially as it relates to use in AI — it is incredibly expensive,” said Matt Kimball, VP and principal analyst for data center compute and storage at Moor Insights & Strategy. “Those expenses climb even higher as the volume of storage and movement of data grows,” he pointed out. “It is only smart for any business to perform a cost analysis of whether storage is better managed in the cloud or on-prem, and moving forward in a direction that delivers the best performance, best security, and best operational efficiency at the lowest cost.”

PEAK:AIO adds power, density to AI storage server

There is also the fact that many people working with AI are not IT professionals, such as professors, biochemists, scientists, doctors, clinicians, and they don’t have a traditional enterprise department or a data center. “It’s run by people that wouldn’t really know, nor want to know, what storage is,” he said. While the new AI Data Server is a Dell design, PEAK:AIO has worked with Lenovo, Supermicro, and HPE as well as Dell over the past four years, offering to convert their off the shelf storage servers into hyper fast, very AI-specific, cheap, specific storage servers that work with all the protocols at Nvidia, like NVLink, along with NFS and NVMe over Fabric. It also greatly increased storage capacity by going with 61TB drives from Solidigm. SSDs from the major server vendors typically maxed out at 15TB, according to the vendor. PEAK:AIO competes with VAST, WekaIO, NetApp, Pure Storage and many others in the growing AI workload storage arena. PEAK:AIO’s AI Data Server is available now.

SoftBank to buy Ampere for $6.5B, fueling Arm-based server market competition

SoftBank’s announcement suggests Ampere will collaborate with other SBG companies, potentially creating a powerful ecosystem of Arm-based computing solutions. This collaboration could extend to SoftBank’s numerous portfolio companies, including Korean/Japanese web giant LY Corp, ByteDance (TikTok’s parent company), and various AI startups. If SoftBank successfully steers its portfolio companies toward Ampere processors, it could accelerate the shift away from x86 architecture in data centers worldwide. Questions remain about Arm’s server strategy The acquisition, however, raises questions about how SoftBank will balance its investments in both Arm and Ampere, given their potentially competing server CPU strategies. Arm’s recent move to design and sell its own server processors to Meta signaled a major strategic shift that already put it in direct competition with its own customers, including Qualcomm and Nvidia. “In technology licensing where an entity is both provider and competitor, boundaries are typically well-defined without special preferences beyond potential first-mover advantages,” Kawoosa explained. “Arm will likely continue making independent licensing decisions that serve its broader interests rather than favoring Ampere, as the company can’t risk alienating its established high-volume customers.” Industry analysts speculate that SoftBank might position Arm to focus on custom designs for hyperscale customers while allowing Ampere to dominate the market for more standardized server processors. Alternatively, the two companies could be merged or realigned to present a unified strategy against incumbents Intel and AMD. “While Arm currently dominates processor architecture, particularly for energy-efficient designs, the landscape isn’t static,” Kawoosa added. “The semiconductor industry is approaching a potential inflection point, and we may witness fundamental disruptions in the next 3-5 years — similar to how OpenAI transformed the AI landscape. SoftBank appears to be maximizing its Arm investments while preparing for this coming paradigm shift in processor architecture.”

Nvidia, xAI and two energy giants join genAI infrastructure initiative

The new AIP members will “further strengthen the partnership’s technology leadership as the platform seeks to invest in new and expanded AI infrastructure. Nvidia will also continue in its role as a technical advisor to AIP, leveraging its expertise in accelerated computing and AI factories to inform the deployment of next-generation AI data center infrastructure,” the group’s statement said. “Additionally, GE Vernova and NextEra Energy have agreed to collaborate with AIP to accelerate the scaling of critical and diverse energy solutions for AI data centers. GE Vernova will also work with AIP and its partners on supply chain planning and in delivering innovative and high efficiency energy solutions.” The group claimed, without offering any specifics, that it “has attracted significant capital and partner interest since its inception in September 2024, highlighting the growing demand for AI-ready data centers and power solutions.” The statement said the group will try to raise “$30 billion in capital from investors, asset owners, and corporations, which in turn will mobilize up to $100 billion in total investment potential when including debt financing.” Forrester’s Nguyen also noted that the influence of two of the new members — xAI, owned by Elon Musk, along with Nvidia — could easily help with fundraising. Musk “with his connections, he does not make small quiet moves,” Nguyen said. “As for Nvidia, they are the face of AI. Everything they do attracts attention.” Info-Tech’s Bickley said that the astronomical dollars involved in genAI investments is mind-boggling. And yet even more investment is needed — a lot more.

IBM broadens access to Nvidia technology for enterprise AI

The IBM Storage Scale platform will support CAS and now will respond to queries using the extracted and augmented data, speeding up the communications between GPUs and storage using Nvidia BlueField-3 DPUs and Spectrum-X networking, IBM stated. The multimodal document data extraction workflow will also support Nvidia NeMo Retriever microservices. CAS will be embedded in the next update of IBM Fusion, which is planned for the second quarter of this year. Fusion simplifies the deployment and management of AI applications and works with Storage Scale, which will handle high-performance storage support for AI workloads, according to IBM. IBM Cloud instances with Nvidia GPUs In addition to the software news, IBM said its cloud customers can now use Nvidia H200 instances in the IBM Cloud environment. With increased memory bandwidth (1.4x higher than its predecessor) and capacity, the H200 Tensor Core can handle larger datasets, accelerating the training of large AI models and executing complex simulations, with high energy efficiency and low total cost of ownership, according to IBM. In addition, customers can use the power of the H200 to process large volumes of data in real time, enabling more accurate predictive analytics and data-driven decision-making, IBM stated. IBM Consulting capabilities with Nvidia Lastly, IBM Consulting is adding Nvidia Blueprint to its recently introduced AI Integration Service, which offers customers support for developing, building and running AI environments. Nvidia Blueprints offer a suite pre-validated, optimized, and documented reference architectures designed to simplify and accelerate the deployment of complex AI and data center infrastructure, according to Nvidia. The IBM AI Integration service already supports a number of third-party systems, including Oracle, Salesforce, SAP and ServiceNow environments.

Microsoft will invest $80B in AI data centers in fiscal 2025

And Microsoft isn’t the only one that is ramping up its investments into AI-enabled data centers. Rival cloud service providers are all investing in either upgrading or opening new data centers to capture a larger chunk of business from developers and users of large language models (LLMs). In a report published in October 2024, Bloomberg Intelligence estimated that demand for generative AI would push Microsoft, AWS, Google, Oracle, Meta, and Apple would between them devote $200 billion to capex in 2025, up from $110 billion in 2023. Microsoft is one of the biggest spenders, followed closely by Google and AWS, Bloomberg Intelligence said. Its estimate of Microsoft’s capital spending on AI, at $62.4 billion for calendar 2025, is lower than Smith’s claim that the company will invest $80 billion in the fiscal year to June 30, 2025. Both figures, though, are way higher than Microsoft’s 2020 capital expenditure of “just” $17.6 billion. The majority of the increased spending is tied to cloud services and the expansion of AI infrastructure needed to provide compute capacity for OpenAI workloads. Separately, last October Amazon CEO Andy Jassy said his company planned total capex spend of $75 billion in 2024 and even more in 2025, with much of it going to AWS, its cloud computing division.

John Deere unveils more autonomous farm machines to address skill labor shortage

Join our daily and weekly newsletters for the latest updates and exclusive content on industry-leading AI coverage. Learn More Self-driving tractors might be the path to self-driving cars. John Deere has revealed a new line of autonomous machines and tech across agriculture, construction and commercial landscaping. The Moline, Illinois-based John Deere has been in business for 187 years, yet it’s been a regular as a non-tech company showing off technology at the big tech trade show in Las Vegas and is back at CES 2025 with more autonomous tractors and other vehicles. This is not something we usually cover, but John Deere has a lot of data that is interesting in the big picture of tech. The message from the company is that there aren’t enough skilled farm laborers to do the work that its customers need. It’s been a challenge for most of the last two decades, said Jahmy Hindman, CTO at John Deere, in a briefing. Much of the tech will come this fall and after that. He noted that the average farmer in the U.S. is over 58 and works 12 to 18 hours a day to grow food for us. And he said the American Farm Bureau Federation estimates there are roughly 2.4 million farm jobs that need to be filled annually; and the agricultural work force continues to shrink. (This is my hint to the anti-immigration crowd). John Deere’s autonomous 9RX Tractor. Farmers can oversee it using an app. While each of these industries experiences their own set of challenges, a commonality across all is skilled labor availability. In construction, about 80% percent of contractors struggle to find skilled labor. And in commercial landscaping, 86% of landscaping business owners can’t find labor to fill open positions, he said. “They have to figure out how to do

2025 playbook for enterprise AI success, from agents to evals

Join our daily and weekly newsletters for the latest updates and exclusive content on industry-leading AI coverage. Learn More 2025 is poised to be a pivotal year for enterprise AI. The past year has seen rapid innovation, and this year will see the same. This has made it more critical than ever to revisit your AI strategy to stay competitive and create value for your customers. From scaling AI agents to optimizing costs, here are the five critical areas enterprises should prioritize for their AI strategy this year. 1. Agents: the next generation of automation AI agents are no longer theoretical. In 2025, they’re indispensable tools for enterprises looking to streamline operations and enhance customer interactions. Unlike traditional software, agents powered by large language models (LLMs) can make nuanced decisions, navigate complex multi-step tasks, and integrate seamlessly with tools and APIs. At the start of 2024, agents were not ready for prime time, making frustrating mistakes like hallucinating URLs. They started getting better as frontier large language models themselves improved. “Let me put it this way,” said Sam Witteveen, cofounder of Red Dragon, a company that develops agents for companies, and that recently reviewed the 48 agents it built last year. “Interestingly, the ones that we built at the start of the year, a lot of those worked way better at the end of the year just because the models got better.” Witteveen shared this in the video podcast we filmed to discuss these five big trends in detail. Models are getting better and hallucinating less, and they’re also being trained to do agentic tasks. Another feature that the model providers are researching is a way to use the LLM as a judge, and as models get cheaper (something we’ll cover below), companies can use three or more models to

OpenAI’s red teaming innovations define new essentials for security leaders in the AI era

Join our daily and weekly newsletters for the latest updates and exclusive content on industry-leading AI coverage. Learn More OpenAI has taken a more aggressive approach to red teaming than its AI competitors, demonstrating its security teams’ advanced capabilities in two areas: multi-step reinforcement and external red teaming. OpenAI recently released two papers that set a new competitive standard for improving the quality, reliability and safety of AI models in these two techniques and more. The first paper, “OpenAI’s Approach to External Red Teaming for AI Models and Systems,” reports that specialized teams outside the company have proven effective in uncovering vulnerabilities that might otherwise have made it into a released model because in-house testing techniques may have missed them. In the second paper, “Diverse and Effective Red Teaming with Auto-Generated Rewards and Multi-Step Reinforcement Learning,” OpenAI introduces an automated framework that relies on iterative reinforcement learning to generate a broad spectrum of novel, wide-ranging attacks. Going all-in on red teaming pays practical, competitive dividends It’s encouraging to see competitive intensity in red teaming growing among AI companies. When Anthropic released its AI red team guidelines in June of last year, it joined AI providers including Google, Microsoft, Nvidia, OpenAI, and even the U.S.’s National Institute of Standards and Technology (NIST), which all had released red teaming frameworks. Investing heavily in red teaming yields tangible benefits for security leaders in any organization. OpenAI’s paper on external red teaming provides a detailed analysis of how the company strives to create specialized external teams that include cybersecurity and subject matter experts. The goal is to see if knowledgeable external teams can defeat models’ security perimeters and find gaps in their security, biases and controls that prompt-based testing couldn’t find. What makes OpenAI’s recent papers noteworthy is how well they define using human-in-the-middle