Four months ago, a front-end engineer on my team looking to make upgrades to a product or feature would have filed a ticket and waited for the infrastructure group to unblock them. They might have lost a day, sometimes a week. Today, that same engineer makes changes themselves. The code is occasionally brittle, but it works, and the end result ships in a fraction of the time it used to take.

That small story is unfolding inside nearly every engineering organization right now. While some celebrate the sudden fact that one person can do the work of five, others are focused entirely on tech industry layoffs. Both perspectives skip the question I find more interesting: What happens to mastery when every engineer can suddenly do everything?

For two decades, we have described strong engineers as T-shaped. The horizontal bar represents breadth, which is a working familiarity across many areas. The vertical bar represents depth, the real command of one domain earned over years. Agent tooling has stretched that horizontal bar wider than ever before. My concern is the vertical bar, which is quietly getting shorter.

Consider what is now possible in a single quarter. With the right agent harness, one engineer can stand up a billing system, a data connector framework, regional and organizational tenancy infrastructure, or a consumption-based pricing implementation. The pull requests pass review. The tests are green. All looks good. But green tests cannot tell you if the person who shipped that work understood why the system needs redundancy in one specific place, where its failure modes are hiding, or which trade-offs the model made silently on their behalf. The pattern recognition that comes from watching systems fail over many years is suddenly weighted differently than it was even 12 months ago. Our industry has not caught up to that shift.

When the interview stops measuring judgment

The first place this surfaces is hiring, a trend that should concern anyone who has built a team. Traditional coding interviews were always an imperfect proxy for engineering judgment, but agent tooling completely obliterates them. If a candidate can produce a working solution in 20 minutes that would have taken two hours a year ago, the exercise no longer measures technical competence. It just measures how well a coder can prompt an agent.

At Thread AI, we have responded by widening what we look at when we interview job candidates. Our process moves across coding exercises, problem decomposition, system architecture, and behavioral components, with the weighting shifting by role. We allow AI assistance only in specific sections because our engineers still need to be able to operate without it. Some of our work happens in secure environments where you cannot lean on an agent to debug for you. What we’re really testing for now is judgment under ambiguity — the ability to notice when an agent’s output is confidently wrong — and the depth to predict where a system will break before it breaks.

Hiring teams that fail to make this shift will fill their rosters with false positives. They will hire people who interview like experts but struggle the first time a system behaves in a way the model did not anticipate. Ultimately, these companies will miss out on top-tier talent, and they won’t discover the misstep until it’s too late.

Confusing velocity with understanding

That brings me to a larger risk: the rise of false expertise as a category of its own. Historically, the reasoning has gone, “I built a proof of concept, therefore I am an expert.” I have watched versions of this appear in technical leadership, in investment decisions, and in policy conversations about AI. It travels well because the artifact looks real. A working demo is highly persuasive, even when the person behind it only half-understands how it functions.

The problem is bigger than one false expert shipping one bad product; an organization can absorb that. The real risk is a generation of consequential decisions being made by people who have confused velocity with understanding. You can already see the cultural scaffolding being built around this with the celebration of the “idea guy,” and the sudden fashion for invoking “taste” as a substitute for knowing how a system actually works. Those of us shaping tooling, hiring norms, and regulations have a narrow window to set better defaults before this pattern hardens into the way the industry operates.

Depth and breadth, held together

This is the path we’ve been walking at Thread AI since before the latest wave of tooling arrived.

To ground this in a specific example: I have spent 15 years building complex systems. I worked at Goldman Sachs through the financial crisis and the early Dodd-Frank infrastructure, moved critical payment systems into the cloud at The New York Times when that ground was still new, and built the system of record for model training and evaluation at Palantir across highly regulated environments in defense, health, and finance. This experience is the superpower that lets me course-correct an agent when it produces confident-but-wrong output.

I felt this sharply not long ago while scoping consumption-based pricing in a single quarter. The agents did an enormous amount of the heavy lifting, and at some point, I realized that my largest contributions to the effort were knowing where the system would fail and steering around it before we got there. I have also seen how organizations have built large teams around efforts like these in the past. Someone earlier in their career or relying purely on AI guidance would not have had that instinct to draw on. That is the part the public conversation keeps missing.

Every engineer at Thread AI, regardless of seniority, is expected to be a builder at heart. Our people own outcomes across compute, data, and the organizational and identity primitives that hold the product together, all without the traditional product-manager and project-manager scaffolding around them. Our model works only because the people in those seats have the depth to know what they do not know, and the breadth to fill the gaps with agents. They use the tooling instead of being used by it.

AI doesn’t replace deep understanding

The core issue facing organizations today is not whether AI will replace engineers. That question has been answered dozens of times this year with varying degrees of nuance, and it has stopped being interesting. The more useful question for anyone running a company is whether we are protecting the people who understand our systems deeply enough to recognize when the machines are wrong.

In our company, the answers have been to move toward explicit end-to-end ownership, and to hire for depth and breadth together rather than treating them as a trade-off. Layoffs dominate the headlines because they are an easy narrative, but they describe a symptom rather than the actual choice in front of us. The real choice is whether we let breadth quietly stand in for mastery, or whether we build organizations that keep human judgment in the loop on purpose.

In an era when software can be generated faster than it can be understood, the companies that hold onto what is human, verifiable, and deeply understood will be the ones still standing when the brittle parts give way.

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.

Yet another AI model has escaped from a cybersecurity test lab: This time, it’s the Chinese company Moonshot’s Kimi K3 model on the run.

Frontier Security spotted that Kimi K3 had found a loophole in the UK AI Safety Institute’s test environment for AI models performing cybersecurity tasks. The news follows similar exploits by models from OpenAI, which attacked Hugging Face, Anthropic, and most recently Meta.

Frontier revealed how the fault came about. AI models are routinely tested to examine how they perform offensive and defensive cybersecurity tasks, typically in isolated test environments or sandboxes that severely limit their internet access. Frontier reported that Kimi K3 model had found a break in the sandbox it was being tested in, enabling it to reach out to the live github.com website and clone the official repository for the benchmark problem it was supposed to be solving, reading the solution directly off the disk rather than solving the problem for itself.

Frontier warned companies testing AI models to be aware of the dangers such loopholes pose and offered some guidelines.

Companies should restrict outbound DNS and HTTPS traffic from AI models to an explicit allowlist and test those controls from inside the same environment available to the model, Frontier said. They should also audit traces for any suspicious activity and not rely solely on final answers. Companies should also treat a model’s score on benchmarks as meaningful only when the model doesn’t have access to reference implementations and other shortcuts.

Frontier also advised testers to be suspicious of unexpectedly high pass rates, as these may reveal a shared environmental flaw.

Perhaps most importantly of all: They should assume agents will find the worst paths to a solution, including probing a test environment for loopholes, and won’t always follow the path that they are expected to.

As Frontier write in its blog: “Models optimize for the objective function (getting the correct flag/answer), not the human intent behind the benchmark. If a network path to the solution exists, a sufficiently capable agent will find it.”

This article first appeared on CSO.

After two decades of cloud architecture consulting, I see an unchanging pattern in enterprise deployments. Organizations approach me with unexpectedly high cloud bills, operational chaos, and architectures that look good on paper but cause headaches in production. The common thread is almost always the same. Fundamental concepts that should be foundational to any cloud deployment are treated as optional or ignored altogether.

I’m not talking about exotic requirements, bleeding-edge technologies, or vendor-specific best practices. Basic engineering principles are somehow getting lost amid the excitement of cloud adoption. I wish I could say it’s rare, but after working with organizations across industries and geographies for years, I can confirm that missing these fundamentals is more common than most people realize. The results are predictable. Bills grow faster than business value, architectures require constant firefighting, and teams are stretched too thin to optimize anything.

The good news? You don’t have to start over, but you do have to go back to basics. Here are three concepts most cloud architects overlook that will make your architecture dramatically more valuable and efficient.

Identifying common ground

When deploying heterogeneous architecture, especially in multicloud environments, organizations must aggressively reduce silos. This means establishing common control planes for security, governance, and operations. You won’t get there by relying on whatever proprietary technology each cloud provider offers out of the box. Each provider wants you locked into their way of managing things. That is fine for simple deployments, but when you are running across multiple clouds and on-premises systems, proprietary control planes introduce redundancy, complexity, and cost.

You need a single control layer that spans your entire environment. Instead of managing 10 different security solutions from 10 different providers, you have one. Instead of separate identity management systems for each cloud, you need one that works everywhere. This eliminates the need to change security parameters in five different consoles, maintain five different skill sets for five different operational models, and reconcile five different governance frameworks. The common control plane ties everything together.

This might sound hard, but it’s not as bad as you think. (I will cover the specific patterns in a future article.) The real issue is that most architects have never been trained to think this way. They were taught to select the best services from each provider rather than abstract away the differences. This fundamental gap costs organizations real money every single day.

Cost observability and optimization

Most architects treat cost visibility and optimization as afterthoughts, things that can be bolted on after the architecture is in place. That backward approach shows up in the results. Without cost observability and optimization baked into your architecture from day one, you cannot understand where your money is going, where waste is accumulating, or where you should make changes to align expenses with delivered value.

The more complex and heterogeneous your environment, the more critical this becomes. You need a unified cost observability layer that spans public and private clouds and your own infrastructure. This is about building a layer that aggregates cost data from everywhere, provides a single source of truth for spending, and delivers the insights needed to actively optimize. Without this, you are flying blind, making decisions based on incomplete data and discovering problems only after the invoice arrives.

Too many organizations fail to gain control of their cloud spending because their billing data is scattered across multiple consoles, with no way to correlate usage across providers. They cannot see which teams, projects, or services are driving costs. They miss opportunities to right-size, consolidate, or eliminate waste. You cannot improve what you cannot measure. Without a common cost observability and optimization layer built into your architecture, you will never achieve the efficiency the cloud was supposed to deliver.

Consider the human element

Here is an uncomfortable truth most architects do not want to discuss: The more complex your architecture is, the broader the range of skills you will need to keep it running. Complexity requires expertise, and expertise requires hiring, training, and retention. If your architecture demands 15 different skill sets to operate, you’d better have a plan for finding and retaining the people with those skills.

I have seen beautifully designed architectures fail because the organization could not meet hiring requirements. They compromised by hiring underqualified individuals, which led to operational failures, security gaps, and mounting technical debt. The architecture itself was sound. The human infrastructure around it was not. This is a solvable problem. It starts with acknowledging that you are not designing for yourself. You are designing for the team that will inherit this system after you have moved on to your next assignment or promotion.

The solution isn’t just simplifying architecture, though that should be a goal. The key is to consider human factors in your design. What skills are required? How can you find and train people? What cultural changes are necessary for effective operation? These questions are essential; ignoring them risks failure.

The simple bottom line

I understand why most cloud architects miss these basic principles. No single course or book brings all of this together in one place. Cloud architecture has become a collection of best practices, vendor recommendations, and conference talking points, rather than a disciplined engineering discipline focused on business value.

As a result, architectures end up optimized in the wrong places, if they are optimized at all. They are expensive to run, difficult to secure, and nearly impossible to operate at scale without constant intervention. The cloud promises efficiency, yet we are not delivering it because we have lost sight of the fundamentals.

It’s time to go back to basics. Commonality, human factors, and cost observability and optimization are the three things that separate architectures that create value from those that create cost. Incorporate these concepts into your architecture and you’ll get ahead of most production systems in use today.

Yet another AI model has escaped from a cybersecurity test lab: This time, it’s the Chinese company Moonshot’s Kimi K3 model on the run.

Frontier Security spotted that Kimi K3 had found a loophole in the UK AI Safety Institute’s test environment for AI models performing cybersecurity tasks. The news follows similar exploits by models from OpenAI, which attacked Hugging Face, Anthropic, and most recently Meta.

Frontier revealed how the fault came about. AI models are routinely tested to examine how they perform offensive and defensive cybersecurity tasks, typically in isolated test environments or sandboxes that severely limit their internet access. Frontier reported that Kimi K3 model had found a break in the sandbox it was being tested in, enabling it to reach out to the live github.com website and clone the official repository for the benchmark problem it was supposed to be solving, reading the solution directly off the disk rather than solving the problem for itself.

Frontier warned companies testing AI models to be aware of the dangers such loopholes pose and offered some guidelines.

Companies should restrict outbound DNS and HTTPS traffic from AI models to an explicit allowlist and test those controls from inside the same environment available to the model, Frontier said. They should also audit traces for any suspicious activity and not rely solely on final answers. Companies should also treat a model’s score on benchmarks as meaningful only when the model doesn’t have access to reference implementations and other shortcuts.

Frontier also advised testers to be suspicious of unexpectedly high pass rates, as these may reveal a shared environmental flaw.

Perhaps most importantly of all: They should assume agents will find the worst paths to a solution, including probing a test environment for loopholes, and won’t always follow the path that they are expected to.

As Frontier write in its blog: “Models optimize for the objective function (getting the correct flag/answer), not the human intent behind the benchmark. If a network path to the solution exists, a sufficiently capable agent will find it.”

It’s no secret that the CIO role is changing in Canadian enterprises. Driving operational performance and increasing efficiency are, of course, still a big part of the job. But CIOs are now expected to do more than cut costs and keep the lights on. Increasingly, boards of directors expect the CIO to play a key role in creating value and enabling their organizations to outperform their rivals. Recent data backs this up. The overwhelming majority (91%) of Canadian technology leaders believe advanced technology will be the primary driver of competitive advantage over the next three years, according to KPMG’s “The 8 execution imperatives for Canadian tech leaders,” a white paper based on the firm’s 2026 Global Tech Report.

The race to capture value from emerging technologies has intensified, leaving little room for organizations that remain on the sidelines. Yet in Canada, just 27% of organizations consider themselves innovators or early adopters, while 72% are fast or slow followers. Nearly all (85%) believe they’ll need to take more risks with emerging technologies just to remain relevant.

The traditional, operational-first mindset among CIOs has become a liability. CIOs are expected to be strategic players, but meeting that expectation requires taking thoughtful, well-considered action across key imperatives.

AI success depends on data

AI is not the only advanced technology that organizations are working to deploy, but it’s certainly garnering the most attention from C-suite executives, boards of directors, and investors. To enable AI at scale, the data foundations enterprises have built over the past decade will be necessary, but they are not sufficient on their own. CIOs must make modernizing the state of enterprise data a top priority.

In most large organizations, data often remains locked inside legacy systems where the system of record is also the system of engagement, and that significantly limits accessibility for AI workloads. Data should be treated as the strategic asset that it has become. The quality, timeliness, and governance of that data vary widely, and reconciling those inconsistencies is one of the most persistent barriers to enterprise-level deployment.

Scaling pilots into enterprise programs also requires closing the gap between AI-native talent, who have the skills to move quickly, and those with deep institutional knowledge, who understand how their organizations work and what they need to achieve. These two groups must work hand in hand. Otherwise, organizations may accelerate toward the wrong goals, which won’t move the business forward.

“The barriers to scaling AI aren’t just technical,” says Sanjay Pathak, partner and national leader, technology strategy and digital transformation services, KPMG Canada. “CIOs need to truly and deeply understand the value chain of what their organizations do. Those who get there will have the imagination, the courage, and the foresight to use AI to transform their organizations.”

Communicating ROI requires the right framing

Beyond scaling, simply communicating the value of AI also poses a significant challenge. Just over half (53%) of Canadian organizations surveyed say they struggle to demonstrate or communicate AI value to stakeholders. Part of the problem is that CIOs are making the wrong argument in the wrong room because they’re framing ROI as a technology metric rather than a business outcome.

“Any CIO who doesn’t truly understand what their business does is missing a beat around how innovation is going to help the organization achieve ROI,” says Pathak. “Understanding how to deploy AI inside your value chain will give you a head start and a competitive advantage in unlocking real business benefits.”

A formal performance measurement framework that tracks customer experience, revenue growth, and employee adoption alongside cost metrics gives CIOs a far more accurate picture of long-term value. Linking funding decisions to those strategic outcomes makes sustained investment easier to justify.

There is also a compliance dimension that often goes unacknowledged in these conversations. CIOs who bring business, technology, and compliance leaders together to design innovative processes that are “compliant by design” from the start are protecting future value as much as they are delivering value today.

“You need to assemble that multi-dimensional cohort of business, technology, risk, and compliance leaders at the same table, envisioning compliance by design,” says Pathak. “The winners in this space are going to be the ones who really think about business ambition holistically and focus on efficient delivery, operations, and compliance.”

Building disciplined innovation governance

An organization’s approach to governance makes an enormous difference in how quickly and confidently it can deploy and take advantage of advanced technologies. As noted above, almost three-quarters (72%) identify as fast or slow followers, and 85% say they need to move more aggressively to embrace new technologies. Canadian organizations aren’t lacking ambition. What they lack are the conditions required to innovate with confidence: clear ownership, defined risk thresholds, and shared accountability between technology, risk, and business teams.

“You can be an innovator, but if your innovation is not directly connected to strategic business ambition and safety guardrails such as risk management, governance, and compliance, you’re creating labware,” says Pathak. “Being an early adopter means you’re comfortable with the technology. To make it truly viable, you must embrace all dimensions of enterprise value.”

Strong governance does not slow innovation down but instead provides a structure that builds confidence and resilience at every level of the organization, from the board to project teams. A tiered governance approach that takes risk into account allows organizations to advance low-risk, incremental improvements and high-reward initiatives in parallel.

Expanding partnerships to accelerate innovation

Innovation isn’t a single-player game, and Canadian organizations know it. Ninety-seven percent of respondents say they plan to expand their external ecosystems. To date, a significant portion of those relationships have been transactional and focused on a specific capability or problem. But savvier organizations are moving toward multi-party innovation, where partners pool capabilities to share both risk and reward. This model requires a different kind of commitment because organizations are betting on a partner’s long-term viability, not just their current capability. Together, they must build the integration and governance infrastructure that makes these ecosystems work for all participants.

“Moving to multi-party innovation ecosystems is an investment in integration and data,” says Pathak. “If you’re going to look at best of breed and stitch those together, what must be true for that to work is the ability for those different ecosystems to integrate and interoperate. And that creates a much stronger need for safety and governance.”

Cybersecurity is another dimension that grows more important with every new partner added to the ecosystem. Security should be proactively built in, not imposed after a breach has already occurred.

“The more ecosystem-based partnerships you have, the more opportunity you create along with the threat you have to deal with,” says Pathak. “You expand the attack surface, and you become more of a target, so governance and cybersecurity must be designed in from the start, not bolted on later.”

Canadian government incentives, including Scientific Research and Experimental Development (SR&ED) tax credits and AI-focused clusters, offer a way to share some of the cost and risk, particularly during periods of economic uncertainty.

By leveraging these funding frameworks alongside robust ecosystem governance, forward-thinking organizations can safely scale their networks to turn shared risks into sustainable competitive advantages.

In closing

For organizations navigating this environment, KPMG Canada emphasizes that the most consequential decisions ahead are not purely, or even mostly, technical. They are about how CIOs choose to lead, partner, measure, and govern in a period that rewards both ambition and discipline in equal measure.

The data points are clear. CIOs who lead with both strategic ambition and disciplined execution will elevate their organizations above their competitors. By paying attention to the quality of their data, aligning technical priorities with critical business goals, and instituting strong governance and cybersecurity, they will set a higher standard for what Canadian competitiveness looks like in the years ahead.

To learn more, read the full whitepaper: The Top 8 Execution Imperatives for Canadian Tech Leaders.

Samsung Electronics has unveiled a trio of next-generation memory technologies aimed at overcoming the performance, power and capacity limitations facing artificial intelligence infrastructure.

The announcements, made at the Future of Memory and Storage (FMS) conference, introduced new concepts for vertically integrated memory along with a breakthrough NAND architecture designed for the AI era.

The three new memory types have one thing that unites them: they all use wafer bonding. Wafer bonding is a semiconductor manufacturing process technique in which two or more completed silicon wafers are permanently joined together to form a single integrated device, the vendor stated.

Instead of fabricating every component on one wafer, manufacturers build different parts separately, then align and bond them with extremely high precision. Think of it as a high-tech Oreo cookie.

Wafer bonding is significant because it represents one of the few remaining ways to continue scaling semiconductor devices after conventional manufacturing techniques begin to hit physical and economic limits. It enables much higher memory density as more memory is squeezed into the same 2D space, according to the company.

It also allows different manufacturing processes to be combined, so wafer bonding lets companies use the optimal manufacturing process for each wafer independently before joining them. Samsung said the new manufacturing technique fabricates the memory cell array and peripheral circuitry separately before bonding them together.

It is already being used now in NAND flash memory for 3D stacking. Rather than spread the memory circuits out, they are stacked on top of each other like stories on a high-rise building. The technique was first introduced in 2014, with 24-layer NAND flash period last year it broke the 300-layer mark.

The centerpiece of the announcement was BV-NAND, or Bonding V-NAND, Samsung’s next-generation flash memory architecture that employs wafer-bonding. The company said the technology enables NAND devices with more than 400 layers while boosting storage density by approximately 58% compared with its current V9 generation, Samsung stated.

The company said the architecture also improves read, write and input/output performance while reducing power consumption, making it better suited for AI servers that increasingly depend on high-capacity flash storage.

Beyond BV-NAND, Samsung outlined two longer-term memory concepts that could radically alter AI system architecture. The first, dubbed zHBM, calls for stacking HBM memory on top of the AI accelerator rather than alongside processors, as is done today.

This shortens the distance data must travel between processor and memory. Samsung said the design could dramatically increase bandwidth while reducing power consumption and thermal resistance.

The company estimates that combining the architecture with wafer-bonding technology could ultimately deliver more than ten times the memory density of conventional HBM5 while tripling energy efficiency and cutting thermal resistance by more than half.

But don’t plan for deployment just yet. zHBM is still a research concept. It illustrates how memory manufacturers are increasingly looking too 3D designs to continue scaling as traditional 2D packaging becomes more difficult.

Samsung also introduced zNAND-O, another conceptual architecture designed to extend three-dimensional memory beyond conventional NAND implementations. Details were scant but Samsung did say zNAND-O was a next-generation high-performance NAND solution built on its V-NAND technology and in development in four- and eight-layer versions.

The technologies reflect how the industry is being driven by AI, and that AI concerns are driving chip development. HBM Has emerged as an important component of AI computation, but very quickly the industry hit limitations in terms of bandwidth and speed. The proposed technologies above reflect Samsung’s attempts to alleviate the bandwidth problem.

It’s no secret that the CIO role is changing in Canadian enterprises. Driving operational performance and increasing efficiency are, of course, still a big part of the job. But CIOs are now expected to do more than cut costs and keep the lights on. Increasingly, boards of directors expect the CIO to play a key role in creating value and enabling their organizations to outperform their rivals. Recent data backs this up. The overwhelming majority (91%) of Canadian technology leaders believe advanced technology will be the primary driver of competitive advantage over the next three years, according to KPMG’s “The 8 execution imperatives for Canadian tech leaders,” a white paper based on the firm’s 2026 Global Tech Report.

The race to capture value from emerging technologies has intensified, leaving little room for organizations that remain on the sidelines. Yet in Canada, just 27% of organizations consider themselves innovators or early adopters, while 72% are fast or slow followers. Nearly all (85%) believe they’ll need to take more risks with emerging technologies just to remain relevant.

The traditional, operational-first mindset among CIOs has become a liability. CIOs are expected to be strategic players, but meeting that expectation requires taking thoughtful, well-considered action across key imperatives.

AI success depends on data

AI is not the only advanced technology that organizations are working to deploy, but it’s certainly garnering the most attention from C-suite executives, boards of directors, and investors. To enable AI at scale, the data foundations enterprises have built over the past decade will be necessary, but they are not sufficient on their own. CIOs must make modernizing the state of enterprise data a top priority.

In most large organizations, data often remains locked inside legacy systems where the system of record is also the system of engagement, and that significantly limits accessibility for AI workloads. Data should be treated as the strategic asset that it has become. The quality, timeliness, and governance of that data vary widely, and reconciling those inconsistencies is one of the most persistent barriers to enterprise-level deployment.

Scaling pilots into enterprise programs also requires closing the gap between AI-native talent, who have the skills to move quickly, and those with deep institutional knowledge, who understand how their organizations work and what they need to achieve. These two groups must work hand in hand. Otherwise, organizations may accelerate toward the wrong goals, which won’t move the business forward.

“The barriers to scaling AI aren’t just technical,” says Sanjay Pathak, partner and national leader, technology strategy and digital transformation services, KPMG Canada. “CIOs need to truly and deeply understand the value chain of what their organizations do. Those who get there will have the imagination, the courage, and the foresight to use AI to transform their organizations.”

Communicating ROI requires the right framing

Beyond scaling, simply communicating the value of AI also poses a significant challenge. Just over half (53%) of Canadian organizations surveyed say they struggle to demonstrate or communicate AI value to stakeholders. Part of the problem is that CIOs are making the wrong argument in the wrong room because they’re framing ROI as a technology metric rather than a business outcome.

“Any CIO who doesn’t truly understand what their business does is missing a beat around how innovation is going to help the organization achieve ROI,” says Pathak. “Understanding how to deploy AI inside your value chain will give you a head start and a competitive advantage in unlocking real business benefits.”

A formal performance measurement framework that tracks customer experience, revenue growth, and employee adoption alongside cost metrics gives CIOs a far more accurate picture of long-term value. Linking funding decisions to those strategic outcomes makes sustained investment easier to justify.

There is also a compliance dimension that often goes unacknowledged in these conversations. CIOs who bring business, technology, and compliance leaders together to design innovative processes that are “compliant by design” from the start are protecting future value as much as they are delivering value today.

“You need to assemble that multi-dimensional cohort of business, technology, risk, and compliance leaders at the same table, envisioning compliance by design,” says Pathak. “The winners in this space are going to be the ones who really think about business ambition holistically and focus on efficient delivery, operations, and compliance.”

Building disciplined innovation governance

An organization’s approach to governance makes an enormous difference in how quickly and confidently it can deploy and take advantage of advanced technologies. As noted above, almost three-quarters (72%) identify as fast or slow followers, and 85% say they need to move more aggressively to embrace new technologies. Canadian organizations aren’t lacking ambition. What they lack are the conditions required to innovate with confidence: clear ownership, defined risk thresholds, and shared accountability between technology, risk, and business teams.

“You can be an innovator, but if your innovation is not directly connected to strategic business ambition and safety guardrails such as risk management, governance, and compliance, you’re creating labware,” says Pathak. “Being an early adopter means you’re comfortable with the technology. To make it truly viable, you must embrace all dimensions of enterprise value.”

Strong governance does not slow innovation down but instead provides a structure that builds confidence and resilience at every level of the organization, from the board to project teams. A tiered governance approach that takes risk into account allows organizations to advance low-risk, incremental improvements and high-reward initiatives in parallel.

Expanding partnerships to accelerate innovation

Innovation isn’t a single-player game, and Canadian organizations know it. Ninety-seven percent of respondents say they plan to expand their external ecosystems. To date, a significant portion of those relationships have been transactional and focused on a specific capability or problem. But savvier organizations are moving toward multi-party innovation, where partners pool capabilities to share both risk and reward. This model requires a different kind of commitment because organizations are betting on a partner’s long-term viability, not just their current capability. Together, they must build the integration and governance infrastructure that makes these ecosystems work for all participants.

“Moving to multi-party innovation ecosystems is an investment in integration and data,” says Pathak. “If you’re going to look at best of breed and stitch those together, what must be true for that to work is the ability for those different ecosystems to integrate and interoperate. And that creates a much stronger need for safety and governance.”

Cybersecurity is another dimension that grows more important with every new partner added to the ecosystem. Security should be proactively built in, not imposed after a breach has already occurred.

“The more ecosystem-based partnerships you have, the more opportunity you create along with the threat you have to deal with,” says Pathak. “You expand the attack surface, and you become more of a target, so governance and cybersecurity must be designed in from the start, not bolted on later.”

Canadian government incentives, including Scientific Research and Experimental Development (SR&ED) tax credits and AI-focused clusters, offer a way to share some of the cost and risk, particularly during periods of economic uncertainty.

By leveraging these funding frameworks alongside robust ecosystem governance, forward-thinking organizations can safely scale their networks to turn shared risks into sustainable competitive advantages.

In closing

For organizations navigating this environment, KPMG Canada emphasizes that the most consequential decisions ahead are not purely, or even mostly, technical. They are about how CIOs choose to lead, partner, measure, and govern in a period that rewards both ambition and discipline in equal measure.

The data points are clear. CIOs who lead with both strategic ambition and disciplined execution will elevate their organizations above their competitors. By paying attention to the quality of their data, aligning technical priorities with critical business goals, and instituting strong governance and cybersecurity, they will set a higher standard for what Canadian competitiveness looks like in the years ahead.

To learn more, read the full whitepaper: The Top 8 Execution Imperatives for Canadian Tech Leaders.

Two years ago, I sat across from a chief financial officer who had just spent forty minutes on a video call authorizing what he believed was a legitimate acquisition payment. The call included his CEO and two board members, all speaking in familiar voices, all making the kind of small unscripted comments that make a meeting feel real. None of them were real. The audio had been cloned from earnings call recordings, and the video was built from conference footage pulled off YouTube.

What gave it away wasn’t a glitch or a blurred hand. It was a pause. The CFO asked about a side conversation from the previous week that only the real CEO would have known, and the voice on the other end hesitated half a second too long before answering. That hesitation stopped a seven-figure transfer.

It also taught me something I have carried into every engagement since. Executive impersonation has moved from a theoretical AI risk category into an active enterprise security problem, and detection and response capability lags materially behind attacker capability.

The detection tooling gap

When clients ask me what to buy first, I tell them to slow down. The tooling landscape for synthetic media is real, but it is not mature, and treating it as solved creates false confidence at exactly the moment confidence gets tested.

Audio and video forensics tools scan a file after the fact for artifacts synthetic generation tends to leave behind. They are genuinely useful in a post-incident review, where there is time to run deeper analysis. They are far less useful in the middle of a live call, where a decision has to get made in seconds rather than hours.

Liveness detection tries to solve that timing problem by checking for signs of life during the interaction itself, rather than analyzing a file afterward. The trouble is that these systems were mostly built for identity verification at onboarding, a single controlled check at a fixed point in time. Retrofitting them into an unplanned executive call is still mostly aspirational, and most vendors will tell you the same thing privately even while marketing otherwise.

The MITRE ATLAS knowledge base, which catalogs real-world adversarial attacks against AI systems, now documents deepfake-based identity verification bypass as an established attack pattern rather than an edge case. That matters for CISOs because it confirms this is not a hypothetical gap security vendors invented to sell tools. It is a documented technique with case studies attached.

What senior executives specifically need, and what the market still doesn’t reliably offer, is verification that works in the moment a request is made rather than after the fact. Until that exists at scale, the tooling has to sit inside a broader protocol rather than stand in for one.

A framework enterprise teams can deploy now

Tooling alone will not close this gap, so the operational framework matters more than any single product. Here is what I put in place with clients, organized around five actions.

1. Verify. Multi-factor human verification for executive-level communications means more than a callback. It means a pre-agreed authentication phrase for the small circle of people who can approve high-sensitivity or high-value actions, changed on a schedule and never guessable from a public LinkedIn bio. It means out-of-band confirmation as a hard requirement, not a courtesy, for any request involving money, credentials or a change to standing instructions. I watched this stop an attack outright. A caller using a cloned voice of an executive asked a colleague for help with a confidential wire. The colleague asked for the agreed phrase, and the line went dead within seconds.
2. Detect. This is not about buying a detection tool. It is about continuously monitoring the executive’s digital identity surface before an attacker even builds the deepfake. That includes tracking domain squatting on the executive’s name, watching for social profile impersonation, and knowing where voice samples are already sitting in public conference recordings and podcast appearances that an attacker could pull from tomorrow. Most security teams monitor the network. Very few monitor the raw material an attacker needs to build a convincing fake in the first place.
3. Respond. When an impersonation attempt is identified or succeeds, the response playbook needs to specify who freezes a transaction, who pulls the call recording before it disappears, and who brings in forensics immediately so there is a documented basis for every decision that follows. It needs a defined escalation path that does not depend on the target believing something is wrong, because most executives will not report a strange call themselves. Build the reporting habit around the transaction, not the suspicion.
4. Train. Executive protection training has to include impersonation awareness now, and not just for the executive. Assistants, chiefs of staff and family office contacts are frequently the actual point of contact an attacker targets, since they often have more standing authority to approve something quickly than the executive expects them to use. This has to be a working habit, not a slide deck people sit through once a year.
5. Integrate. Executive impersonation cannot sit inside a single team’s silo. It needs coordination between security operations, communications, legal and executive protection, because a voice clone built from a podcast appearance does not touch a single system any one of those functions monitors on its own. A CSO Online feature on deepfake defense documented an almost identical wire fraud case and reached a similar conclusion that the organizations recovering fastest were the ones that had already rehearsed the coordination across teams before an incident forced it.

Where the market hasn’t caught up

Even programs built around all five of those actions still run into gaps that no enterprise has fully closed.

The first is the personal exposure gap. Most protocols assume the target is inside a corporate communication channel. Attackers are increasingly working the other direction, reaching family members or personal devices where none of the corporate verification steps apply at all.

The second is the public-facing gap. Livestreams of major corporate events have been hijacked by deepfakes of the company’s own executives, often promoting cryptocurrency scams, with fake feeds sometimes drawing sizeable audiences before takedown. That is not an internal fraud scenario a SOC playbook was built for. It is a brand and platform-level impersonation that needed coordination with a video platform in real time, and almost nobody has that relationship pre-built. The security team needing to reach a platform’s off-hours trust and safety escalation path in the middle of a live event is functionally starting from zero every time, and the incident is often over by the time the right internal owner on the platform side is even identified.

The third is measurement. Very few security teams can currently tell their board how prepared they actually are for this category of risk, because the tabletop exercises that would surface the gaps are still rare. Boards are starting to ask the question anyway, often after reading about another company’s incident rather than their own, and a security leader without a rehearsed answer is at a real disadvantage in that conversation.

Back to that CFO on the video call. What saved him was not a tool. It was a habit, built well before the attack, of treating a hesitation as reason enough to stop. That is still the most reliable control available, and it will remain the most reliable control until the rest of this framework catches up to it.

Enterprises deploying agentic AI may need a new generation of AI servers as conventional GPU-centric infrastructure struggles to efficiently execute multi-step AI workflows, according to researchers from Microsoft Azure and the University of Texas at Austin.

Drawing on production telemetry from Microsoft’s Azure cloud and experiments with representative open-source agent frameworks, the researchers found that AI agents spend far more time coordinating models, tools, and orchestration software than conventional inference systems assume.

Rather than behaving like standalone LLM requests, agentic applications execute as dynamic workflows that repeatedly move work between CPUs, GPUs, and external services, exposing inefficiencies in today’s server designs.

“Our study shows that agentic execution is fundamentally fragmented and heterogeneous,” the researchers wrote in the paper. “Each request expands into a workflow of LLM inferences, tool invocations, and orchestration decisions that repeatedly crosses the CPU-GPU boundary.”

According to the paper, that execution pattern places the CPU on the application’s critical path because orchestration software and tools execute on the host while model inference runs on GPUs.

The researchers said conventional server architectures are poorly matched to those workloads because fragmented execution strands CPU and GPU resources, different host-side software roles have different resource requirements, and multiplexing multiple agents increases coordination overhead.

Production data points to fragmented execution

The researchers said a representative production request alternated between multiple LLM calls, tool discovery, tool execution, and orchestration before completing. In a controlled study using the CORAL framework, a single workload expanded into 580 LLM calls interleaved with 552 tool invocations, causing execution to “ping-pong between the two processors hundreds of times.”

The study also found that host CPU utilization remained low for extended periods before rising sharply during bursts of tool execution, while GPU utilization varied widely depending on workflow composition, leaving some accelerators saturated and others idle.

According to the researchers, the fragmented execution pattern leaves CPUs and GPUs underutilized on average while allowing either processor to become “a transient bottleneck on the workflow’s critical path,” making static resource provisioning inefficient for agentic workloads.

Sanchit Vir Gogia, chief analyst at Greyhound Research, said the findings show enterprises should evaluate agentic AI infrastructure differently from conventional inference deployments.

“Agentic AI is not a bigger chatbot; it is a distributed application with inference embedded inside it,” Gogia said. “The individual ingredients are familiar. The execution graph is new.”

“The GPU remains indispensable, but it no longer owns the entire clock,” he added. “Tool time matched or beat inference time in more than 27 per cent of requests, and average utilisation is beginning to lie to infrastructure teams.”

Researchers propose workflow-aware server design

Based on those findings, the researchers proposed a server architecture, called Agora, that dynamically reallocates CPU and GPU resources, separates scheduling, orchestration, and tool execution into dedicated host roles, and adapts resource allocation to workload behavior.

“Agora dynamically harvests idle CPU cores for co-located throughput work, while protecting agentic tail latency against tool spikes. It also oversubscribes GPU memory by placing more agents on each GPU, prefetching the next agent’s state to hide swap latency,” the researchers wrote in the paper. “To match the machine to the heterogeneous roles, Agora pools cores by role and applies affinity-aware scheduling to restore locality. These techniques substantially improve CPU and GPU utilization and per-server throughput while preserving agent tail latency.”

In their evaluation, the researchers reported that Agora increased host CPU utilization by about 30%, recovered about 95% of a co-located workload’s standalone throughput under low load, freed roughly one-third of GPUs through workload consolidation, increased generation throughput by 82%, and reduced tail latency by 2.5 times.

Gogia said the findings indicate that infrastructure procurement should focus less on individual processors and more on how entire AI workflows execute.

“The CPU is not returning to the throne; the throne itself is disappearing,” he said. “Competitive advantage is moving from the individual processor to the heterogeneous server, rack and runtime operating as one system.” He said organizations should “procure the workflow, not the box,” arguing that workload profiling and scheduling are likely to deliver greater benefits than sizing infrastructure based on model inference alone.

Two years ago, I sat across from a chief financial officer who had just spent forty minutes on a video call authorizing what he believed was a legitimate acquisition payment. The call included his CEO and two board members, all speaking in familiar voices, all making the kind of small unscripted comments that make a meeting feel real. None of them were real. The audio had been cloned from earnings call recordings, and the video was built from conference footage pulled off YouTube.

What gave it away wasn’t a glitch or a blurred hand. It was a pause. The CFO asked about a side conversation from the previous week that only the real CEO would have known, and the voice on the other end hesitated half a second too long before answering. That hesitation stopped a seven-figure transfer.

It also taught me something I have carried into every engagement since. Executive impersonation has moved from a theoretical AI risk category into an active enterprise security problem, and detection and response capability lags materially behind attacker capability.

The detection tooling gap

When clients ask me what to buy first, I tell them to slow down. The tooling landscape for synthetic media is real, but it is not mature, and treating it as solved creates false confidence at exactly the moment confidence gets tested.

Audio and video forensics tools scan a file after the fact for artifacts synthetic generation tends to leave behind. They are genuinely useful in a post-incident review, where there is time to run deeper analysis. They are far less useful in the middle of a live call, where a decision has to get made in seconds rather than hours.

Liveness detection tries to solve that timing problem by checking for signs of life during the interaction itself, rather than analyzing a file afterward. The trouble is that these systems were mostly built for identity verification at onboarding, a single controlled check at a fixed point in time. Retrofitting them into an unplanned executive call is still mostly aspirational, and most vendors will tell you the same thing privately even while marketing otherwise.

The MITRE ATLAS knowledge base, which catalogs real-world adversarial attacks against AI systems, now documents deepfake-based identity verification bypass as an established attack pattern rather than an edge case. That matters for CISOs because it confirms this is not a hypothetical gap security vendors invented to sell tools. It is a documented technique with case studies attached.

What senior executives specifically need, and what the market still doesn’t reliably offer, is verification that works in the moment a request is made rather than after the fact. Until that exists at scale, the tooling has to sit inside a broader protocol rather than stand in for one.

A framework enterprise teams can deploy now

Tooling alone will not close this gap, so the operational framework matters more than any single product. Here is what I put in place with clients, organized around five actions.

1. Verify. Multi-factor human verification for executive-level communications means more than a callback. It means a pre-agreed authentication phrase for the small circle of people who can approve high-sensitivity or high-value actions, changed on a schedule and never guessable from a public LinkedIn bio. It means out-of-band confirmation as a hard requirement, not a courtesy, for any request involving money, credentials or a change to standing instructions. I watched this stop an attack outright. A caller using a cloned voice of an executive asked a colleague for help with a confidential wire. The colleague asked for the agreed phrase, and the line went dead within seconds.
2. Detect. This is not about buying a detection tool. It is about continuously monitoring the executive’s digital identity surface before an attacker even builds the deepfake. That includes tracking domain squatting on the executive’s name, watching for social profile impersonation, and knowing where voice samples are already sitting in public conference recordings and podcast appearances that an attacker could pull from tomorrow. Most security teams monitor the network. Very few monitor the raw material an attacker needs to build a convincing fake in the first place.
3. Respond. When an impersonation attempt is identified or succeeds, the response playbook needs to specify who freezes a transaction, who pulls the call recording before it disappears, and who brings in forensics immediately so there is a documented basis for every decision that follows. It needs a defined escalation path that does not depend on the target believing something is wrong, because most executives will not report a strange call themselves. Build the reporting habit around the transaction, not the suspicion.
4. Train. Executive protection training has to include impersonation awareness now, and not just for the executive. Assistants, chiefs of staff and family office contacts are frequently the actual point of contact an attacker targets, since they often have more standing authority to approve something quickly than the executive expects them to use. This has to be a working habit, not a slide deck people sit through once a year.
5. Integrate. Executive impersonation cannot sit inside a single team’s silo. It needs coordination between security operations, communications, legal and executive protection, because a voice clone built from a podcast appearance does not touch a single system any one of those functions monitors on its own. A CSO Online feature on deepfake defense documented an almost identical wire fraud case and reached a similar conclusion that the organizations recovering fastest were the ones that had already rehearsed the coordination across teams before an incident forced it.

Where the market hasn’t caught up

Even programs built around all five of those actions still run into gaps that no enterprise has fully closed.

The first is the personal exposure gap. Most protocols assume the target is inside a corporate communication channel. Attackers are increasingly working the other direction, reaching family members or personal devices where none of the corporate verification steps apply at all.

The second is the public-facing gap. Livestreams of major corporate events have been hijacked by deepfakes of the company’s own executives, often promoting cryptocurrency scams, with fake feeds sometimes drawing sizeable audiences before takedown. That is not an internal fraud scenario a SOC playbook was built for. It is a brand and platform-level impersonation that needed coordination with a video platform in real time, and almost nobody has that relationship pre-built. The security team needing to reach a platform’s off-hours trust and safety escalation path in the middle of a live event is functionally starting from zero every time, and the incident is often over by the time the right internal owner on the platform side is even identified.

The third is measurement. Very few security teams can currently tell their board how prepared they actually are for this category of risk, because the tabletop exercises that would surface the gaps are still rare. Boards are starting to ask the question anyway, often after reading about another company’s incident rather than their own, and a security leader without a rehearsed answer is at a real disadvantage in that conversation.

Back to that CFO on the video call. What saved him was not a tool. It was a habit, built well before the attack, of treating a hesitation as reason enough to stop. That is still the most reliable control available, and it will remain the most reliable control until the rest of this framework catches up to it.

Als Umgebung für Entwickler hat Microsoft Windows in den letzten Jahren einen Sprung nach vorne gemacht. Mit dem Windows-Subsystem für Linux (WSL) ist es nahtlos möglich, mit Linux unter Windows zu arbeiten – ohne den Mehraufwand, den eine virtuelle Maschine (VM) mit sich bringt. Zudem sind sämtliche gängigen Dev-Tools als native Windows-Versionen verfügbar – und Microsoft hat eine ganze Reihe entsprechender Funktionen auch direkt in sein Betriebssystem integriert.

Für Developer, die besonders schnell mit einer Windows-Maschine entwickeln wollen, hat Microsoft mit der „Windows Developer Config“ sogar so etwas wie eine Schnellspur geschaffen: Diese Sammlung von Powershell-Skripten fungiert als eine Art „Starter Kit“ und unterstützt dabei, Windows-Systeme möglichst schnell und komfortabel als Entwicklungsumgebung einzurichten. 

Wenn Sie hingegen – wie die meisten Entwickler – Wert darauflegen, die Kontrolle zu behalten und Ihr Dev-System selbst einzurichten und zu konfigurieren, ist ein bisschen Vorarbeit nötig. Der Aufwand selbst ist dabei überschaubar, die konkreten Schritte sind jedoch erfolgsentscheidend (und nicht unbedingt offensichtlich).   

Hinweis: Um die nachfolgenden Maßnahmen umzusetzen, sollten Sie auf Ihrem System über Administratorrechte verfügen.

1. WSL installieren

WSL stellt Windows-Benutzern ein vollständiges Linux-System über die Kommandozeile zur Verfügung – was weniger Overhead verursacht als eine VM. Da Software weltweit vor allem unter Linux– oder Unix-ähnlichen Systemen wie macOS entwickelt wird, ist das ein echter Vorteil.

Um WSL zu installieren, öffnen Sie ein Konsolenfenster mit Administratorrechten und nutzen den Befehl:

wsl --install

Die Installation kann einige Zeit in Anspruch nehmen, da das System sowohl die Kernkomponenten für WSL als auch – damit zusammenhängend – eine Linux-Distribution herunterladen muss.

Die Standard-Linux-Distribution in WSL ist Ubuntu 26.04 LTS. Diese erfüllt als Default-Lösung die meisten Anforderungen, die Entwickler an eine Linux-Distribution stellen. Es stehen jedoch auch andere Distributionen zur Verfügung – und es kommen regelmäßig neue hinzu. Sie könnten sogar Ihre eigene, benutzerdefinierte Linux-Distribution für WSL kreieren.

Sobald WSL installiert ist, können Sie über den Befehl wsl –list –online alle verfügbaren Distributionen anzeigen. Um eine davon zu installieren, nutzen Sie den Befehl wsl --install . Die meisten verfügbaren Optionen sind auf unterschiedliche Vorlieben oder spezifische Anforderungen zugeschnitten. Wenn Sie beispielsweise an einem Projekt arbeiten, das Debian als Grundlage voraussetzt, sollten Sie das auch installieren.

WSL-Distributionen werden standardmäßig im AppData-Verzeichnis abgelegt – genauer gesagt unter AppData\Local\Packages\. Wenn Sie die Dateien in ein anderes Verzeichnis oder auf ein anderes Laufwerk verschieben möchten, können Sie das mit dem Befehl wsl --manage --move bewerkstelligen.

Darüber hinaus hat Microsoft Ende Juni 2026 mit WSL-Container (derzeit in der Public Preview) eine wichtige neue Funktion für WSL vorgestellt. Diese ermöglicht es, Linux-Container nativ unter Windows auszuführen.

2. Dev-Drive-Laufwerk konfigurieren

Um Projekte zu speichern, nutzen die meisten Windows-Benutzer standardmäßig ein Verzeichnis auf einem NTFS-Volume – entweder im eigenen Benutzerprofil oder über einen anderen Pfad. Das ist als Default-Option keine schlechte Wahl. Allerdings gibt es bessere Alternativen.

Zum Beispiel „Dev Drive“, ein neuer Laufwerkstyp unter Windows. Dieser nutzt statt NTFS das neuere Dateisystem ReFS („Resilient File System“). Dieses wurde ursprünglich für Windows Server entwickelt und bietet Funktionen, die darauf ausgelegt sind, Softwareentwicklungs-Workloads besser zu bewältigen. Dazu gehören:  

• Copy-on-Write: Projektverzeichnisse können Tausende von Dateien und Dutzende von Unterverzeichnissen enthalten. Kopien von Projekten dieser Art anzufertigen, lässt sich mit ReFS deutlich schneller bewältigen, da das Dateisystem Kopien von Daten erst dann erstellt, wenn diese auch geändert werden. Reine Kopien sind hingegen Links, die auf die Originale verweisen.
• Antivirus-Komfort: Über einen Dev Drive lassen sich die standardmäßigen Beeinträchtigungen durch die nativen Antivirus-Tools von Windows minimieren. Dieses Feature erlaubt es, Entwicklerverzeichnisse manuell von Scan-Vorgängen zu exkludieren.
• Virtuelle Festplatte oder Partition: Dev Drives können als virtuelle Festplattendatei eingerichtet oder direkt auf einer formatierten Partition genutzt werden. Ersteres ist flexibler (unter anderem lässt sich die Größe leichter anpassen), Letzteres möglicherweise performanter.

Zwei Dinge sollten Sie im Zusammenhang mit Dev Drives unbedingt beachten:

1. Dev Drives sind für Projekte gedacht, nicht für Tools: Dort legen Sie Ihre Projekt-Repositories, Build-Artefakte und zwischengespeicherte Dateien ab. Language Runtimes, Compiler oder anderen Toolchain-Utlities sollten hingegen auf regulären NTFS-Volumes gespeichert werden.
2. Low-Level-Tools funktionieren unter Umständen nicht wie beabsichtigt: Dateisystem-Utilities auf Expertenniveau, die Informationen direkt aus den Dateiinformationen auslesen, verhalten sich im Zusammenspiel mit ReFS-Volumes möglicherweise nicht wie vorgesehen. So ist etwa das Speicherplatz-Management-Tool WizTree unter ReFS extrem langsam.

3. WinGet nutzen

Microsoft hat Windows inzwischen auch mit einem offiziellen Package-Management-System ausgestattet – WinGet. Dieses installiert jede Art von Windows-Applikation und bietet zudem ein vollständiges Befehlszeilen-Interface für Interaktion und Automatisierung.    

WinGet wird vom Windows-Software-Ökosystem umfassend unterstützt – die Wahrscheinlichkeit ist also groß, dass es für jedes Windows-Programm, das Sie benötigen, ein WinGet-Paket gibt (dazu gleich mehr).

Um im WinGet-Repository nach einem Paket zu suchen, nutzen Sie diesen Befehl (die Anführungszeichen sind erforderlich, wenn der Name des gesuchten Pakets Leerzeichen enthält – etwa Adobe Acrobat Reader):

winget search "Thing to search for"

Das WinGet-Package zu installieren, geht denkbar simpel von der Hand – und zwar mit:

winget install 

Dabei meint die ID des zu installierenden Pakets – nicht bloß seinen Namen. Im vorgenannten Beispiel (Adobe Acrobat Reader) würden Sie also folgenden Befehl nutzen, um dieses zu installieren:

winget install Adobe.Acrobat.Reader.64-bit

Falls Sie eine ansprechende grafische Benutzeroberfläche suchen, empfiehlt sich ein Blick auf UniGetUI. Dieses Tool verwaltet Packages aus verschiedenen Quellen – etwa WinGet, Scoop, Chocolatey, npm, pip oder Cargo, um nur einige zu nennen.

4. PowerShell für Skripte konfigurieren

Dieser Schritt ist lediglich einmal pro System zu absolvieren, kann jedoch die Entwicklererfahrung von Windows gewaltig steigern: PowerShell sollte entsprechend konfiguriert werden, damit lokale Skripte ausgeführt werden können.   

Um das zu bewerkstelligen, starten Sie PowerShell als Admin und nutzen folgendes Kommando:

set-executionpolicy remotesigned

Zwar verlangt Windows weiterhin, dass alle PowerShell-Skripte, die Sie aus dem Internet herunterladen, signiert sind – das ist jedoch im Grunde ein Edge Case. Alle lokal erstellten Skripte funktionieren nach dieser Maßnahme ohne Weiteres.

5. Weitere Dev-Tools installieren

Wie bereits erwähnt, bietet WinGet schnellen Zugriff auf alle gängigen Tools, die ein entwicklungsorientiertes Windows-System benötigt. Nachfolgend haben wir eine kleine Übersicht der wichtigsten Dev-Tools für Windows inklusive deren WinGet-IDs zusammengestellt, um Ihnen die Installation zu erleichtern.

• Git (Git.Git): Die Windows-Version des populären Versionskontrollsystems ist im Wesentlichen identisch mit der auf anderen Plattformen.
• Visual Studio BuildTools 2022 (Microsoft.VisualStudio.2022.BuildTools): Dieses minimale CLI-Tooling ist erforderlich, um das C/C++-Kompilierungssystem von Visual Studio zu nutzen.
• CMake (Kitware.Cmake): Die plattformübergreifende Build-Lösung wird häufig für größere oder komplexere Projekte benötigt, die C/C++ nutzen.

Dabei ist zu beachten, dass die standardmäßige BuildTools-Installation in der Regel nicht über die Tools verfügt, die für minimale C/C++-Build-Prozesse erforderlich sind. Das beheben Sie mit folgendem Befehl:

winget install -e --id Microsoft.VisualStudio.2022.BuildTools --force --override "--passive --wait --add Microsoft.VisualStudio.Workload.VCTools;includeRecommended"

Alle gängigen Editoren sind ebenfalls als native Windows-Apps über WinGet verfügbar – etwa:

• Microsoft Visual Studio Code (Microsoft.VisualStudioCode),
• GNU Emacs (GNU.Emacs), oder
• Neovim (Neovim.Neovim).

Für die Softwareentwicklung unter Windows optional, aber durchaus nützlich, sind außerdem folgende Werkzeuge:

• CoreUtils for Windows (Microsoft.Coreutils): Ein von Microsoft gepflegtes Open-Source-Projekt, das Dutzende von Linux-Befehlszeilen-Dienstprogrammen auf Windows bringt, beispielsweise cp, grep, find und ls.
• MSYS2 (MSYS2.MSYS2): Eine Tool-Sammlung, um Windows-Binärdateien mit dem GCC-Compiler zu erstellen. Diese bildet im Grunde eine Alternative zum Visual-Studio-Build-Stack auf Basis der Cygwin-Umgebung.
• LLVM (LLVM.LLVM): Auf diesem Compiler-Framework basieren Clang, Rust, Swift und viele andere Projekte. Wenn Sie LLVM als Abhängigkeit verwenden, müssen Sie die spezifische Version installieren, die Ihr Projekt erfordert.
• Docker Desktop (XP8CBJ40XLBWKX): Die Windows-native Version der Docker-Desktop-App.
• Microsoft PowerToys (Microsoft.PowerToys): Diese Sammlung besteht aus über 30 Utilities, die es erheblich vereinfachen, Windows anzupassen. Dazu gehören unter anderem ein Hosts-File-Editor, ein Unlocking-Tool für Dateien (praktisch, um festzustellen, welche Prozesse eine bestimmte Datei sperren) sowie ein Werkzeug, um Text zu extrahieren (praktisch, um Text von beliebigen Stellen auszulesen, einschließlich Bildschirmbereichen, die nicht mit dem Cursor markiert werden können).

(fm)

Dieser Artikel ist im Original bei unserer Schwesterpublikation Infoworld.com erschienen.

Microsoft has released code-testing-generator, an open-source agent for generating unit tests in any programming language, according to the company.

Released July 31, the code-testing-generator agent learns from the user’s repository, then plans, writes, and checks the tests to prove that they work. Currently the agent writes unit tests only. Integration tests, end-to-end tests, browser tests, and performance tests are outside its current scope, Microsoft said.

The agent coordinates test generation using the “research-plan-implement” (RPI) pipeline. First the agent searches the repository for the code that needs tests, detecting the language and test framework and looking for existing tests to guide its work, and finding the correct commands for building and running the tests.

Next the agent chooses the right amount of work from three paths:

• Direct: Read the relevant code, write the tests, and validate the result.
• Single pass: Research and plan once, then implement that plan.
• Iterative: Repeat the cycle to cover a large request or reach a coverage goal.

The agent then plans and writes the tests It starts with simple code and then moves to code with more dependencies, mapping each behavior to a test file. The agent then checks that the generated tests are useful. According to Microsoft, it checks for the following problems before it finishes:

• It considers small code changes that should make the tests fail.
• It looks for weak or missing assertions.
• It checks that every requested scenario has a matching test.
• It builds the full workspace and runs the full test suite.
• It confirms that the repository’s test command can find the new tests.

The code-testing-generator agent is available in the dotnet-test plugin in the dotnet/skills repository on GitHub. The plugin can be used in GitHub Copilot CLI and is also available in Visual Studio Code and VS Code Insiders through plugin support, which is a preview feature.

Vulnerability management isn’t failing because security teams lack visibility. Most organizations already have more findings than they can reasonably address. Yet despite all those findings, many CISOs still struggle to answer a deceptively simple question: Are we actually becoming harder to attack?

That question sits at the center of a growing problem. Security programs have become very good at finding issues, but finding issues and reducing risk are not the same thing. In many organizations, those two concepts have become interchangeable, which is exactly why traditional vulnerability management is beginning to break down.

The underlying assumption behind vulnerability management is straightforward. If you can identify vulnerabilities, prioritize them, and patch them, risk should decrease. That logic worked reasonably well when environments were smaller, infrastructure changed at a slower pace, and vulnerabilities were treated as the primary indicator of risk.

Today’s environments operate differently. Vulnerabilities are rarely encountered in isolation and are often only one component of a broader security problem. The challenge is no longer finding vulnerabilities. The challenge is understanding exposure.

This shift is one reason the Gartner^® Continuous Threat Exposure Management (CTEM) framework has gained traction. At its core, the framework recognizes that understanding risk requires looking beyond individual vulnerabilities and evaluating the broader exposures that attackers can actually exploit.

Why prioritization keeps falling short

The challenge becomes apparent when organizations try to prioritize risk. Traditional vulnerability management evaluates findings individually, often using severity scores as a proxy for risk. Attackers take a different approach. They evaluate how weaknesses connect, what access they provide, and how they can be combined to reach a meaningful objective.

That distinction matters because severity and risk are not the same thing. A critical vulnerability that cannot be reached or exploited may represent very little practical risk. Meanwhile, a lower-severity issue combined with weak credentials, excessive permissions, or a misconfigured identity relationship can create a direct path to sensitive systems and data.

Attackers understand this instinctively. They do not attack vulnerabilities one at a time. They chain weaknesses together, move laterally across environments, escalate privileges, and pursue the path that gets them closest to their objective.

Severity is not risk

One of the biggest reasons vulnerability management efforts struggle today is that severity has become a stand-in for risk. It is easy to understand why. Severity scores provide a standardized way to compare findings, helping teams sort large volumes of vulnerabilities and establish remediation priorities.

A vulnerability only matters if it contributes to an attacker’s ability to achieve an objective, whether that objective is accessing sensitive data, escalating privileges, or moving laterally through an environment. In every case, the question is not, “How severe is this vulnerability?” but rather, “Can this weakness be used as part of a path to something valuable?”

Those are fundamentally different questions. One measures the characteristics of a finding. The other evaluates the opportunity it creates for an attacker. As environments become more interconnected, the gap between those perspectives continues to grow.

Exposure is bigger than vulnerabilities

Visibility tells you what vulnerabilities exist. Exposure tells you how attackers can use them.

That distinction is becoming increasingly important because exposure is broader than a vulnerability. It includes the relationships between weaknesses, identities, permissions, assets, trust relationships, and business systems that create opportunities for attackers.

A vulnerability may contribute to exposure, but it is rarely the entire story. Consider a lower-severity vulnerability that exists on a system with excessive permissions. By itself, neither issue may appear urgent. Together, they may provide a direct path to sensitive data or critical infrastructure.

Now consider an attacker who compromises a low-value system. In a traditional vulnerability management model, the focus remains on the vulnerability that enabled access. In an exposure management model, the focus shifts to what happens next: 

• What can the attacker reach? 
• Which identities can be abused? 
• What permissions can be leveraged? 
• What systems become accessible?

The vulnerability may have enabled the intrusion, but the exposure determines the impact. That is why understanding exposure requires looking beyond individual findings and evaluating how weaknesses interact across the environment.

The same principle applies across cloud environments, identity systems, Active Directory, third-party access, and hybrid environments. Attackers do not compromise organizations because a vulnerability exists. They compromise organizations because multiple conditions create an opportunity to reach something valuable.

That is the definition of exposure.

Why exposure management is replacing vulnerability management

Attackers have already made this shift. The industry is finally catching up.

Vulnerability management helped organizations understand what was broken. Exposure management helps organizations understand what attackers can actually do.

As environments become more interconnected, the goal is no longer to identify every vulnerability. The goal is to understand which combinations of weaknesses create meaningful risk and where action will reduce that risk most effectively.

For CISOs, that changes the conversation.

Instead of asking:

• How many vulnerabilities do we have?
• How quickly are we patching them?

The more important questions become:

• What can an attacker actually reach?
• Which exposures create meaningful business risk?
• What should we fix first?
• Are we becoming harder to attack?

Those are exposure management questions. And as attackers gain new ways to identify and exploit opportunities at machine speed, they are increasingly the questions that matter most.

Explore how organizations are operationalizing exposure management through CTEM by downloading the “Operationalizing CTEM: A Practical Playbook for Continuous Threat Exposure Management.” You’ll learn how leading teams are moving beyond visibility and building programs focused on measurable exposure reduction. 

Cybersecurity is full of frameworks, regulations, and directives that tell organizations what they should do. Zero Trust, NIST, CIS Controls, CMMC, DORA, NIS2, and now Continuous Threat Exposure Management (CTEM) all provide valuable guidance and describe desired outcomes.

The challenge is that most stop at the “what.” They rarely explain the “how.”

That is not a criticism. It is by design. Frameworks establish principles, define expectations, and describe desired outcomes. They are not implementation guides.

As a result, security leaders and practitioners are left figuring out how to translate principles into processes, assign ownership, establish accountability, and measure success. Those decisions often determine whether a framework delivers results or becomes another initiative that never moves beyond good intentions.

The Gartner^® CTEM framework provides a clear vision through its five phases: scope, discover, prioritize, validate, and mobilize. Yet many organizations that understand those phases still struggle to build a CTEM program that consistently produces measurable outcomes.

Understanding CTEM is the easy part

Most security teams do not have a CTEM knowledge problem. Gartner has clearly documented the phases, vendors have built messaging around them, and countless presentations explain how CTEM works. The challenge is that understanding a framework and operating it are two very different things.

The question is not whether the pieces exist, but whether those pieces work together to reduce exposure over time. That is where the gap emerges, because the challenge is not understanding CTEM. It is turning CTEM into a repeatable operating model that consistently produces measurable outcomes.

The industry has focused on the phases

Most CTEM discussions focus on the framework itself: How do we scope? How do we discover? How do we prioritize? How do we validate? How do we mobilize? Those questions help organizations understand the framework, but they can also create the illusion that adopting CTEM is simply a matter of executing the phases.

The organizations making the most progress are focused on a different set of questions:

• Who owns the process?
• How do findings move between teams?
• How do we establish accountability?
• How do we verify that remediation actually reduced exposure?
• How do we measure progress over time?

These are operational questions, and they are often the difference between a CTEM initiative and a CTEM operating model.

Where CTEM programs actually stall

Most CTEM programs do not struggle with visibility. They struggle with execution.

Security teams often discover exposures, while infrastructure, application, cloud, and identity teams are responsible for fixing them. Each team plays an important role, but no single team owns the end-to-end outcome. As a result, exposures often move from team to team while the original context gets diluted. Security understands why the issue matters. The team responsible for fixing it may only see another ticket in a queue.

As findings move across organizational boundaries, priorities compete for attention, ownership becomes fragmented, and validation often becomes inconsistent, leaving organizations uncertain whether risk is actually decreasing.

A team may discover an exposure, prioritize it, validate that it matters, and assign remediation to the right group. But if ownership becomes unclear, remediation is delayed, or nobody verifies the outcome, the program has not reduced exposure in any measurable way.

Moving work through a process is not the same as reducing exposure. That distinction matters because CTEM is not about generating more findings. It is about creating a repeatable system that helps organizations understand what matters, act on it with confidence, and prove that exposure is decreasing over time.

Click here to see what operationalization looks like in practice, and how to fill your CTEM gaps.

Continue the conversation

Understanding CTEM is the easy part. Operationalizing it is where most organizations struggle.

As organizations shift from reactive security to proactive security, they need more than visibility. They need the ability to continuously validate what matters, verify that remediation worked, and prove they are becoming harder to attack over time.

Register for the webinar “From Probability to Proof: The Art of the Possible with Proactive Cybersecurity,” and explore how AI-native proactive security is helping organizations continuously find, fix, and verify exploitable attack paths so they can move beyond assumptions and prove resilience. Also, download the “Operationalizing CTEM: A Practical Playbook for Continuous Threat Exposure Management” playbook for guidance on building a repeatable CTEM operating model.

The updated Cybersecurity Maturity Model Certification (CMMC) represents a critical evolution in the Department of War (DoW) strategy to secure the Defense Industrial Base (DIB). It is more than a regulatory hurdle. It is a direct response to a rapidly changing and increasingly hostile threat landscape faced by the DIB.

Updated CMMC guidance issued in 2025 simplifies the prior framework, focusing on the most essential security practices aligned with National Institute of Standards and Technology (NIST) Special Publication (SP) 800-171. Its fundamental purpose remains unchanged: to protect sensitive, unclassified defense information — specifically Federal Contract Information (FCI) and Controlled Unclassified Information (CUI) — from foreign adversaries.

The updated CMMC phases. Image from https://dodcio.defense.gov/cmmc/About/ 

CMMC implementation phases

The CMMC requirements are being implemented in phases to ease the burden on both organizations and auditors.

• Phase 1 (Nov 10, 2025 – Nov 9, 2026): Focus on self-assessments for Levels 1 and 2
• Beginning Nov 10, 2026: Solicitations will require Level 2 certifications

For thousands of companies across the DIB— from prime contractors to small, specialized machine shops — compliance is not optional. It is the prerequisite for doing business with the DoW. It establishes a standardized, measured approach to cybersecurity across the supply chain.

A shift in adversary strategy

The strategic focus of adversaries has shifted. Rather than launching costly, direct attacks against well-defended prime contractors, they increasingly target the weakest link in the supply chain.

Suppliers and subcontractors often:

• Possess valuable intellectual property, schematics, and operational details
• Operate without the same security resources as larger defense firms

These operational activities create a pathway into the broader ecosystem. A breach at any tier can reverberate across the supply chain, exposing sensitive information and impacting mission outcomes.

The limitations of point-in-time security

The traditional model of cybersecurity compliance has relied on periodic, point-in-time assessments. This approach is fundamentally limited in the context of a dynamic and interconnected supply chain.

Security is not static. A posture that was compliant weeks ago can become vulnerable due to:

• New exploits or zero-day vulnerabilities
• System configuration changes
• Introduction of new technologies or shadow IT

The core issue is straightforward: You are only as secure as your last evaluation. In an environment that is constantly evolving, this model leaves a persistent gap between compliance and actual risk.

Enabling continuous validation

Horizon3.ai’s NodeZero Federal™ enables a more continuous approach to security validation. Unlike traditional penetration testing or vulnerability scanning, NodeZero identifies and validates exploitable weaknesses and demonstrates how they can be chained together.

This provides organizations with the ability to:

• Validate controls regularly: Demonstrate effectiveness on an ongoing basis, not just during audits
• Close the compliance gap: Move beyond documentation to show how controls mitigate real-world risk
• Identify attack paths: Understand how an adversary could move through the environment

This approach supports a more realistic understanding of security posture and risk.

Expanding the scope: From enterprise to ecosystem

Elevating supply chain security for FCI and CUI represents a broader shift in how the DoW approaches risk. The focus is no longer limited to securing individual networks. It extends across the entire DIB ecosystem.

The objective is not only compliance, but:

• Measurable risk reduction
• Greater resilience across interconnected environments
• Assurance of mission continuity

Implications for prime contractors

CMMC reinforces a long-standing reality: The security posture of a prime contractor is directly influenced by the posture of its suppliers.

This introduces cascading risks across the supply chain, particularly where subcontractors process, store, or transmit CUI.

Key implications include:

• Jeopardized prime contractor posture: A security incident at a supplier can impact the prime’s certification.
• Contract ineligibility and business impact: Non-compliance may lead to disqualification from DoW contracts.
• Mission assurance risk: Compromised CUI can affect operational integrity and outcomes

Common sources of compromise

Compromise often originates in predictable areas of the supply chain.

Third-party providers. Managed service providers (MSPs) and vendors supporting multiple organizations can introduce systemic risk. A single compromise can expose multiple environments.

Specialized suppliers. Small and medium-sized organizations may handle sensitive data but lack enterprise-grade security controls.

Interconnected access points. Common weaknesses include:

• Shared credentials
• Weak or misconfigured VPN access
• Federated identity systems without proper segmentation

Example: Assume-breach scenario

In a recent assume-breach test, NodeZero began with access to a single host without credentials. From that starting point, it enumerated domain users and executed a password spray, successfully obtaining a valid domain credential.

That account had local administrator privileges, enabling further actions:

• Deployment of a remote access tool (RAT)
• LSASS access and credential harvesting

This scenario highlights a common issue: controls that are assumed to be in place may not perform as expected in practice.

Why the legacy model does not scale

The legacy model of periodic assessments does not account for the dynamic nature of modern environments.

Risk is introduced through:

• Supply chain changes and new vendors
• Ongoing system reconfigurations
• Expansion of SaaS, APIs, and cloud services
• Gradual degradation of controls over time

As a result, a point-in-time certification can quickly become outdated.

Continuous readiness under CMMC

The updated CMMC guidance emphasizes continuous readiness rather than periodic validation. Self-assessments are expected to be supported by documented, day-to-day evidence of control effectiveness.

This reflects the need to maintain security posture over time, not just demonstrate it at a single point.

Continuous validation as a practical requirement

Moving to continuous validation helps organizations keep pace with:

• Changing threat activity
• Evolving supplier ecosystems
• The need to maintain confidence in control effectiveness

Without this, organizations rely on outdated assumptions about their environment and exposure.

Closing the gap between compliance and security

HORIZON3.ai’s NodeZero® Proactive Security Platform helps bridge the gap between compliance and operational security. By validating controls through real-world attack scenarios, it provides evidence of effectiveness and identifies gaps across both internal environments and critical suppliers.

This enables organizations to treat CMMC not just as a compliance requirement, but as part of an ongoing risk management program.

Final thought

True security posture is not defined by a completed assessment.

It is defined by how systems perform under real conditions, and how quickly organizations can identify and address weaknesses as they emerge. 

Learn more about how Horizon3.ai strengthens supply chain security for CMMC.
Please refer to the full white paper.

For years, cooling has played a supporting role in data center design. Decisions have been driven primarily by compute, storage and networking requirements, while cooling systems quietly ensured everything stayed within safe operating limits. Most enterprise environments operated well within the capabilities of traditional air-cooling that was designed to sustain normal growth. This let organizations focus their attention on capacity, performance and cost of the compute.

That balance is now being disrupted.

Artificial intelligence is reshaping the thermal profile of modern data centers. As organizations roll out more powerful CPUs, GPUs and TPU’s to support AI workloads, heat generation is rising at a pace that many facilities were never built to handle. With AI in the picture, cooling is no longer simply an operational consideration. It is becoming a primary constraint and strategic differentiator on AI infrastructure growth.

The limits of air cooling are becoming clear

Although traditional air cooling continues to support many enterprise workloads effectively, its limitations are becoming increasingly evident as organizations deploy larger AI clusters with increasingly power-hungry CPUs and GPUs, generating heat at levels older data centers were never designed to accommodate.

Racks that once operated at 5–10kW are being replaced by AI systems drawing 60kW or more, with some high-end deployments exceeding 100kW per rack. At the component level, individual GPUs are drawing 700W–1,200W each, placing large amounts of heat into a very small space. This shift represents a step-change in thermal density that conventional air-cooling systems, typically effective only up to around 20–30kW per rack, struggle to handle efficiently.

At these levels, the challenge becomes structural. Air can only do so much. There’s a hard limit to how efficiently it can move heat, and simply increasing airflow or optimising ventilation isn’t enough to keep pace with the rate at which heat is being generated.

The consequence is a growing imbalance between compute capability and cooling capacity. Data centers are being forced to use more energy for cooling, while simultaneously managing higher thermal risk and operational complexity. In some cases, this also introduces performance constraints, as systems throttle workloads to remain within safe operating temperatures.

Because of this, more organizations are turning to liquid cooling — particularly direct-to-chip approaches.

How direct-to-chip cooling is addressing rising heat challenges

The main limitation of air cooling is its relative inefficiency at removing concentrated heat. Direct-to-chip cooling addresses this. Instead of relying on chilled air moving around the room, direct-to-chip systems put cooling exactly where it’s needed, by placing cold plates directly onto high-heat components such as CPUs and GPUs. Coolant flows through these plates, absorbing heat at the source before carrying it away for dissipation via a heat exchange system.

A direct-to-chip cooling system is made of several parts working together. Cold plates absorb heat straight from the chips, while a coolant distribution unit (CDU) manages the temperature, pressure and flow of the liquid. The coolant moves through pipes connected to each rack, carrying heat away from the servers and into the facility’s wider cooling system while sensors monitor temperatures, flow rates and leak detection.

Liquids transfer heat far more efficiently than air, so direct-to-chip cooling allows significantly greater thermal loads to be managed with lower energy overheads. Because heat is removed more directly and effectively at the source, data centers require less power for fans, airflow and chiller operation, reducing overall energy consumption.

In most cases, only the components that generate the most heat are liquid-cooled. The rest of the system continues to rely on familiar air-cooling approaches. That mix is a big part of the appeal. A hybrid cooling approach allows organizations to improve cooling performance where it matters most, without having to redesign their entire environment.

Direct-to-chip isn’t one-size-fits-all

While direct-to-chip is talked about as a single approach, there are actually a few different ways to implement it. Most organizations use single-phase liquid cooling, where the coolant stays in liquid form throughout the process. It’s simple, easy to manage and fits well with existing operational models, which makes it a natural starting point.

But there is also a growing shift towards warm-water cooling. Because water is so effective at absorbing heat, systems don’t need to run at the same low temperatures as traditional air-cooled environments. This can reduce the need for energy-intensive chilling and improve overall efficiency.

In some setups, direct-to-chip cooling is paired with rear-door heat exchangers. These capture any remaining heat as air leaves the rack, helping to push densities even higher without overloading the system.

Ultimately, there isn’t a single “correct” way to approach cooling. The best method depends on the workloads being supported, the constraints of the facility and the organization’s longer-term plans. What’s clear, however, is that flexibility is becoming increasingly important as cooling requirements continue to evolve.

Direct-to-chip vs immersion cooling

As liquid cooling gains traction, direct-to-chip is often compared with immersion cooling. While both approaches address the same fundamental problem — removing significantly higher levels of heat – they do so in very different ways, with different implications for how data centers are designed and operated.

Immersion cooling takes a more radical route by fully submerging servers in dielectric fluid — a liquid that does not conduct electricity or conducts it extremely poorly. From a cooling perspective, it is highly effective and can handle extremely dense, high compute environments. But it comes with trade-offs.

Immersion cooling requires a rethink of how data centers operate. It also demands significant infrastructure shifts, which can make adoption challenging for organizations with established data center models.

Direct-to-chip cooling, on the other hand, offers a more gradual step forward. In general, servers keep their familiar design, and day-to-day maintenance doesn’t change dramatically. Teams can continue working in ways they already understand, making it a more practical step for many organizations.

This practicality makes all the difference. For most organizations, the decision isn’t just about which solution performs best in theory, it’s about what can be deployed, managed and scaled within the realities of existing operations. In that sense, direct-to-chip strikes a balance between performance gains and operational continuity, making it a more accessible starting point for many data centers navigating the shift to higher-density workloads.

Cooling as a competitive advantage

Cooling is no longer simply an operational concern. It is becoming a defining factor in how data centers scale, how efficiently they run and how reliably they perform. As AI workloads push infrastructure to new limits, the ability to manage heat effectively will directly influence how far and how fast organizations can grow.

That shift is also changing who owns the conversation. Decisions that once sat with facilities teams are now firmly on the agenda for CIOs, CTOs and infrastructure leaders. Thermal design, energy efficiency and cooling architecture are no longer niche considerations, they are central to cost control, sustainability targets and overall competitiveness.

At the same time, there is no one correct solution. Air cooling will continue to support many workloads, while immersion cooling will remain relevant for specialised, high-density use cases. Direct-to-chip cooling sits between the two, offering a practical way to handle increasing thermal demands without disrupting established operating models.

For organizations planning the next phase of their infrastructure, cooling can no longer be treated as an afterthought. It needs to be considered alongside compute, storage and networking from the outset.

For years, cooling has played a supporting role in data center design. Decisions have been driven primarily by compute, storage and networking requirements, while cooling systems quietly ensured everything stayed within safe operating limits. Most enterprise environments operated well within the capabilities of traditional air-cooling that was designed to sustain normal growth. This let organizations focus their attention on capacity, performance and cost of the compute.

That balance is now being disrupted.

Artificial intelligence is reshaping the thermal profile of modern data centers. As organizations roll out more powerful CPUs, GPUs and TPU’s to support AI workloads, heat generation is rising at a pace that many facilities were never built to handle. With AI in the picture, cooling is no longer simply an operational consideration. It is becoming a primary constraint and strategic differentiator on AI infrastructure growth.

The limits of air cooling are becoming clear

Although traditional air cooling continues to support many enterprise workloads effectively, its limitations are becoming increasingly evident as organizations deploy larger AI clusters with increasingly power-hungry CPUs and GPUs, generating heat at levels older data centers were never designed to accommodate.

Racks that once operated at 5–10kW are being replaced by AI systems drawing 60kW or more, with some high-end deployments exceeding 100kW per rack. At the component level, individual GPUs are drawing 700W–1,200W each, placing large amounts of heat into a very small space. This shift represents a step-change in thermal density that conventional air-cooling systems, typically effective only up to around 20–30kW per rack, struggle to handle efficiently.

At these levels, the challenge becomes structural. Air can only do so much. There’s a hard limit to how efficiently it can move heat, and simply increasing airflow or optimising ventilation isn’t enough to keep pace with the rate at which heat is being generated.

The consequence is a growing imbalance between compute capability and cooling capacity. Data centers are being forced to use more energy for cooling, while simultaneously managing higher thermal risk and operational complexity. In some cases, this also introduces performance constraints, as systems throttle workloads to remain within safe operating temperatures.

Because of this, more organizations are turning to liquid cooling — particularly direct-to-chip approaches.

How direct-to-chip cooling is addressing rising heat challenges

The main limitation of air cooling is its relative inefficiency at removing concentrated heat. Direct-to-chip cooling addresses this. Instead of relying on chilled air moving around the room, direct-to-chip systems put cooling exactly where it’s needed, by placing cold plates directly onto high-heat components such as CPUs and GPUs. Coolant flows through these plates, absorbing heat at the source before carrying it away for dissipation via a heat exchange system.

A direct-to-chip cooling system is made of several parts working together. Cold plates absorb heat straight from the chips, while a coolant distribution unit (CDU) manages the temperature, pressure and flow of the liquid. The coolant moves through pipes connected to each rack, carrying heat away from the servers and into the facility’s wider cooling system while sensors monitor temperatures, flow rates and leak detection.

Liquids transfer heat far more efficiently than air, so direct-to-chip cooling allows significantly greater thermal loads to be managed with lower energy overheads. Because heat is removed more directly and effectively at the source, data centers require less power for fans, airflow and chiller operation, reducing overall energy consumption.

In most cases, only the components that generate the most heat are liquid-cooled. The rest of the system continues to rely on familiar air-cooling approaches. That mix is a big part of the appeal. A hybrid cooling approach allows organizations to improve cooling performance where it matters most, without having to redesign their entire environment.

Direct-to-chip isn’t one-size-fits-all

While direct-to-chip is talked about as a single approach, there are actually a few different ways to implement it. Most organizations use single-phase liquid cooling, where the coolant stays in liquid form throughout the process. It’s simple, easy to manage and fits well with existing operational models, which makes it a natural starting point.

But there is also a growing shift towards warm-water cooling. Because water is so effective at absorbing heat, systems don’t need to run at the same low temperatures as traditional air-cooled environments. This can reduce the need for energy-intensive chilling and improve overall efficiency.

In some setups, direct-to-chip cooling is paired with rear-door heat exchangers. These capture any remaining heat as air leaves the rack, helping to push densities even higher without overloading the system.

Ultimately, there isn’t a single “correct” way to approach cooling. The best method depends on the workloads being supported, the constraints of the facility and the organization’s longer-term plans. What’s clear, however, is that flexibility is becoming increasingly important as cooling requirements continue to evolve.

Direct-to-chip vs immersion cooling

As liquid cooling gains traction, direct-to-chip is often compared with immersion cooling. While both approaches address the same fundamental problem — removing significantly higher levels of heat – they do so in very different ways, with different implications for how data centers are designed and operated.

Immersion cooling takes a more radical route by fully submerging servers in dielectric fluid — a liquid that does not conduct electricity or conducts it extremely poorly. From a cooling perspective, it is highly effective and can handle extremely dense, high compute environments. But it comes with trade-offs.

Immersion cooling requires a rethink of how data centers operate. It also demands significant infrastructure shifts, which can make adoption challenging for organizations with established data center models.

Direct-to-chip cooling, on the other hand, offers a more gradual step forward. In general, servers keep their familiar design, and day-to-day maintenance doesn’t change dramatically. Teams can continue working in ways they already understand, making it a more practical step for many organizations.

This practicality makes all the difference. For most organizations, the decision isn’t just about which solution performs best in theory, it’s about what can be deployed, managed and scaled within the realities of existing operations. In that sense, direct-to-chip strikes a balance between performance gains and operational continuity, making it a more accessible starting point for many data centers navigating the shift to higher-density workloads.

Cooling as a competitive advantage

Cooling is no longer simply an operational concern. It is becoming a defining factor in how data centers scale, how efficiently they run and how reliably they perform. As AI workloads push infrastructure to new limits, the ability to manage heat effectively will directly influence how far and how fast organizations can grow.

That shift is also changing who owns the conversation. Decisions that once sat with facilities teams are now firmly on the agenda for CIOs, CTOs and infrastructure leaders. Thermal design, energy efficiency and cooling architecture are no longer niche considerations, they are central to cost control, sustainability targets and overall competitiveness.

At the same time, there is no one correct solution. Air cooling will continue to support many workloads, while immersion cooling will remain relevant for specialised, high-density use cases. Direct-to-chip cooling sits between the two, offering a practical way to handle increasing thermal demands without disrupting established operating models.

For organizations planning the next phase of their infrastructure, cooling can no longer be treated as an afterthought. It needs to be considered alongside compute, storage and networking from the outset.

Open the history tab of any epic that has been alive for more than two quarters. Go ahead, pick one. Count the edits. Somewhere around edit 11, the description was rewritten to satisfy a stakeholder who has since changed roles. Around edit 19, the scope was trimmed to protect a date that, in the end, moved anyway. By edit 26 someone renamed the whole thing, and the sentence that explained why the work existed in the first place didn’t survive the paste. 26 edits, several hundred hours of delivery behind them, and nobody left who can say what the money was for.

Nobody deleted that reason on purpose. That’s what makes this so hard to see.

I’ve been shuttling between the people who fund technology work and the teams who deliver it for a couple of decades now, and something has always struck me as odd: the backlog is probably the only important document in the enterprise that gets edited every day and remembers nothing. Contracts have version control and signatures. Financial statements have audit trails. Even architecture, in mature shops, has decision records. But the artifact that actually steers what hundreds of people build week after week? It has a title, a status and a description that mutates until the original intent becomes archaeology.

The most expensive failures I’ve seen were all fast. The teams shipped and shipped, and somewhere along the way the work stopped meaning what everyone assumed it still meant. Nobody slowed down long enough to notice.

One problem, two lenses

Strategy and delivery look at the same work through very different mental models. On one side, leaders talk in outcomes, intent and value; they worry about whether the original justification for the investment still holds months later. On the other side, teams think in iterations, flow and momentum, and they worry about keeping complex programs moving in small, manageable steps. Both lenses are legitimate, and in my experience both sides generally believe they’re the ones doing everything right.

The disagreement between them is never loud. Strategy quietly assumes the logic will remain constant across every sprint and every decision. Delivery quietly assumes the strategic reasoning will naturally update itself based on what gets learned along the way. There’s nothing wrong with either assumption on its own. But in the absence of a structural bridge between them, every program gradually accumulates small half-measures and shifted meanings that nobody registers until it’s too late.

The evidence on how badly intent travels is humbling. Donald Sull and his colleagues, in a multi-year study of strategy execution, found that only half of middle managers can name any of their company’s top five priorities. Those are the managers. Now imagine the epic, eleven edits later.

Let me be fair to agile here, because agile is not the villain. It does exactly what it says on the tin: it helps teams learn quickly and adjust to what they discover, and that speed is a genuine strength. The problem is that organizations blur the line between two kinds of change. Some of it is genuine learning: teams discover real behaviors, markets shift, leaders sharpen their thinking. And some of it is erosion, the slow loss of rationale that nobody actually decided and nobody can trace back to a witting choice. From the outside, the two are indistinguishable. They show up the same way in the tooling: movement in the backlog, shifting priorities, even working software. Only one of them stays anchored to the reason the money was spent.

Most organizations have no instrument for telling these two apart. Which means they’re flying at full speed without knowing whether they’re navigating or just moving.

The pattern we keep seeing

Agile in style, not in substance

The board gets moved every day, stand-ups start on time and retrospectives produce long lists of things to improve. Then you ask why a specific feature exists, what it’s actually meant to change, and the room gets quiet. The rituals persist while the substance underneath them slowly thins out. Teams keep closing tasks, and somewhere along the way they shed the shared sense of purpose that made the tasks worth doing.

Velocity becomes a proxy for value

A smooth sprint demo can hide a deeper problem, because progress toward delivery and progress toward outcomes are two different measurements, and only one of them is on the wall. I’ve seen features that were stable, polished and warmly received in the demo, and that contributed absolutely nothing to the decision they were supposed to improve. The pace was real enough; whether any of it mattered took months to find out. And your delivery metrics can be excellent, genuinely excellent, while every one of these patterns is running underneath them.

This is not a niche affliction, by the way. Pendo analyzed feature usage across hundreds of software products and found that 80% of features are rarely or never used. Built at full velocity, shipped into silence.

Product owners absorb pressure instead of defending logic

The PO is supposed to hold the thread, to protect the reasoning behind the work when everyone else is pushing on it. In practice, many find themselves wedged between demand and delivery, forced into a permanent state of reactive prioritization. Over time they stop challenging requests. Then they stop defending the logic behind decisions. Eventually they stop framing choices around outcomes at all, and the backlog, which should be a strategic instrument, turns into the place where everything gets dumped because nobody has the space left to ask what actually belongs there.

Backlog churn masks strategic drift

Items get revisited, split, recast and reprioritized as everyone works to keep momentum going, and from a distance it can all look like reasonable adaptation. But when the connection to intent is severed, all that motion begins to dissolve into static. Work keeps getting passed around, the board stays busy and the program veers off course without producing a single alarming signal, because busy is what everyone was looking for.

Every quarter is a reset

New OKRs arrive. A fresh wave of leadership messaging follows. Sometimes the team gets reshuffled too. With each round, a little of the shared context that held everything together quietly slips away. Epics get new names, stories get rewritten, priorities rearrange themselves almost by accident. The organization keeps rebooting itself without ever asking what it left behind in the reset.

Taken one at a time, each of these patterns is understandable, even forgivable. Together they produce a program that looks healthy from every angle while it quietly hollows out the meaning behind the work.

Why this keeps happening, and why it’s about to get worse

Big programs tend to assume that intent will simply carry itself forward as the work passes through teams, decisions and iterations. It won’t. Intent doesn’t carry itself. If nobody actively preserves and updates the reasoning, it starts to loosen and fray, quietly and almost politely, one story, one trade-off, one shift in priority at a time.

The structural cause is a speed mismatch that most governance was never designed for. The delivery system evolves in hours; the organization’s memory of why updates in quarters, if at all. In between those two clocks, thousands of micro-decisions reshape what the work means, far faster than anyone captures the reasoning behind them.

Now add what’s happening in 2026. AI agents inside the delivery tooling can already organize, create and edit backlog items on a team’s behalf. Atlassian’s own customers describe agents that generate requirements, break them into epics and stories and take delegated work like a teammate, and these capabilities now ship inside the standard Jira plans that most enterprises already pay for. I’m not against any of this; some of it is genuinely useful. But notice what it means for our problem. Every one of those operations is an edit to a document that has no memory. Backlog amnesia at human speed was survivable. Painful, but survivable, because humans forget slowly. Amnesia at machine speed is a different animal altogether. The ratio of motion to memory, already unhealthy in most organizations, is about to go vertical.

If your backlog can’t remember why an item exists after a human rewrote it a few times, think about what happens when an agent grooms it continuously.

What to do about it

The countermeasures I use are deliberately small. None of them adds a ceremony, a tool, or a governance layer. They simply orient the practices teams already run toward one job: keeping the reasoning alive while the work moves. Together, they form the discipline I call Structural Agile.

• Start with the outcome. Before an epic or major story enters the backlog, three questions, every time: What behavior are we trying to shift? How will we know if that behavior changes? What signals will confirm success after release? If the room can’t answer, the work waits, because items that lack outcome clarity tend to drift first and drift fastest.
• Elevate the PO. Position the product owner as the carrier of outcome logic, with an explicit mandate to preserve rationale, flag trade-offs that erode intent and track deferred items together with the reasoning behind them. And be realistic about the limits, because many POs inherit chaotic backlogs, rotate mid-stream, or simply lack the authority to push back on stakeholders. The rule I give teams is simple: if the PO can’t carry the logic, someone must: a coach prompting context checks, an architect recording the reasoning behind technical trade-offs, an analyst keeping the outcome picture current. Build logic stewardship into the structure. Left to personality, it leaves with the person.
• Anchor epics to why. Every epic carries its rationale as metadata, inside the tool where the work actually lives. Slide decks from last spring don’t count. When a decision reshapes the epic, the rationale gets updated in the same motion; waivers and scope cuts get recorded next to the item they changed. Do this consistently and the backlog stops being a queue of tasks and becomes a living map of intent, one that a new joiner can read on day one, and that survives a challenge from leadership without anyone having to reconstruct history from memory. It cuts both ways, too: the same rationale that protects the team from whiplash protects the business from a backlog that has drifted away from what they actually asked for. Prioritization turns into a conversation about evidence rather than a contest of opinions.
• Rehearse erosion. This is the practice I’d start with, and the one that surprises teams most. Every two or three sprints, run a short, structured session that is not a retrospective and not a risk review. Its purpose is to test the continuity of intent itself: Does the assumed user behavior still make sense? Where might adoption fail even though delivery is technically correct? Which parts of the outcome logic feel fragile, outdated, or untested? A retro examines how the team worked; an erosion rehearsal examines whether the reasoning still holds. You rehearse erosion the same way pilots rehearse emergencies: you hope the drill is wasted, and you run it anyway, because catching drift early is what makes fixing it cheap. In my experience, a single one of these sessions surfaces more strategic risk than a quarter’s worth of status reporting, and it costs the team about half an hour.
• Keep the logic alive. Capture only what prevents strategic amnesia and nothing more: why a feature was removed or reshaped, who approved it and which assumptions should be revisited, and when. Keep it visible where teams already work. If logic lives in Confluence but dies in conversation, it’s already gone.

Start Monday

You don’t need a reorganization or a new framework to begin, and frankly you shouldn’t want one. Three entry points, close to zero overhead. Assign a critical reviewer: one team member whose standing job is to periodically ask whether stories still connect to the intended outcome. Add a one-minute outcome check before major refinements: the behavior targeted, the indicator watched, the signal expected. And run a single erosion rehearsal on your most important program; teams usually surface something real in the first session, long before it would have shown up in any metric.

For readers keeping score: yes, neighboring practices exist, and they’re good ones. Architecture decision records preserve the why behind technical choices, and impact mapping connects deliverables to goals at planning time. I use both. Neither operates continuously, inside the backlog, at the level of the individual item, which happens to be exactly where the forgetting occurs. OKRs don’t solve it either; objectives at altitude are necessary, but teams still need the rationale embedded in the work itself, so they don’t have to keep a separate decoder.

The history tab, revisited

Go back to that epic with the twenty-six edits, and imagine the same history with one difference: each consequential edit carries a line of reasoning, current and human-readable, and every few sprints someone deliberately tested whether that reasoning still held. Same team, same velocity, same tool and a completely different answer when someone finally asks why the work exists.

Velocity tells you how fast the work is moving. Only memory can tell you whether anyone still knows where it’s going.

I’ve published the full discipline behind this approach (the five principles, the roles, the facilitation guides and the objections seasoned practitioners will raise, along with my answers) as a featured paper in PM World Journal. The mechanics are free to steal. The forgetting, at this point, is optional.

Open the history tab of any epic that has been alive for more than two quarters. Go ahead, pick one. Count the edits. Somewhere around edit 11, the description was rewritten to satisfy a stakeholder who has since changed roles. Around edit 19, the scope was trimmed to protect a date that, in the end, moved anyway. By edit 26 someone renamed the whole thing, and the sentence that explained why the work existed in the first place didn’t survive the paste. 26 edits, several hundred hours of delivery behind them, and nobody left who can say what the money was for.

Nobody deleted that reason on purpose. That’s what makes this so hard to see.

I’ve been shuttling between the people who fund technology work and the teams who deliver it for a couple of decades now, and something has always struck me as odd: the backlog is probably the only important document in the enterprise that gets edited every day and remembers nothing. Contracts have version control and signatures. Financial statements have audit trails. Even architecture, in mature shops, has decision records. But the artifact that actually steers what hundreds of people build week after week? It has a title, a status and a description that mutates until the original intent becomes archaeology.

The most expensive failures I’ve seen were all fast. The teams shipped and shipped, and somewhere along the way the work stopped meaning what everyone assumed it still meant. Nobody slowed down long enough to notice.

One problem, two lenses

Strategy and delivery look at the same work through very different mental models. On one side, leaders talk in outcomes, intent and value; they worry about whether the original justification for the investment still holds months later. On the other side, teams think in iterations, flow and momentum, and they worry about keeping complex programs moving in small, manageable steps. Both lenses are legitimate, and in my experience both sides generally believe they’re the ones doing everything right.

The disagreement between them is never loud. Strategy quietly assumes the logic will remain constant across every sprint and every decision. Delivery quietly assumes the strategic reasoning will naturally update itself based on what gets learned along the way. There’s nothing wrong with either assumption on its own. But in the absence of a structural bridge between them, every program gradually accumulates small half-measures and shifted meanings that nobody registers until it’s too late.

The evidence on how badly intent travels is humbling. Donald Sull and his colleagues, in a multi-year study of strategy execution, found that only half of middle managers can name any of their company’s top five priorities. Those are the managers. Now imagine the epic, eleven edits later.

Let me be fair to agile here, because agile is not the villain. It does exactly what it says on the tin: it helps teams learn quickly and adjust to what they discover, and that speed is a genuine strength. The problem is that organizations blur the line between two kinds of change. Some of it is genuine learning: teams discover real behaviors, markets shift, leaders sharpen their thinking. And some of it is erosion, the slow loss of rationale that nobody actually decided and nobody can trace back to a witting choice. From the outside, the two are indistinguishable. They show up the same way in the tooling: movement in the backlog, shifting priorities, even working software. Only one of them stays anchored to the reason the money was spent.

Most organizations have no instrument for telling these two apart. Which means they’re flying at full speed without knowing whether they’re navigating or just moving.

The pattern we keep seeing

Agile in style, not in substance

The board gets moved every day, stand-ups start on time and retrospectives produce long lists of things to improve. Then you ask why a specific feature exists, what it’s actually meant to change, and the room gets quiet. The rituals persist while the substance underneath them slowly thins out. Teams keep closing tasks, and somewhere along the way they shed the shared sense of purpose that made the tasks worth doing.

Velocity becomes a proxy for value

A smooth sprint demo can hide a deeper problem, because progress toward delivery and progress toward outcomes are two different measurements, and only one of them is on the wall. I’ve seen features that were stable, polished and warmly received in the demo, and that contributed absolutely nothing to the decision they were supposed to improve. The pace was real enough; whether any of it mattered took months to find out. And your delivery metrics can be excellent, genuinely excellent, while every one of these patterns is running underneath them.

This is not a niche affliction, by the way. Pendo analyzed feature usage across hundreds of software products and found that 80% of features are rarely or never used. Built at full velocity, shipped into silence.

Product owners absorb pressure instead of defending logic

The PO is supposed to hold the thread, to protect the reasoning behind the work when everyone else is pushing on it. In practice, many find themselves wedged between demand and delivery, forced into a permanent state of reactive prioritization. Over time they stop challenging requests. Then they stop defending the logic behind decisions. Eventually they stop framing choices around outcomes at all, and the backlog, which should be a strategic instrument, turns into the place where everything gets dumped because nobody has the space left to ask what actually belongs there.

Backlog churn masks strategic drift

Items get revisited, split, recast and reprioritized as everyone works to keep momentum going, and from a distance it can all look like reasonable adaptation. But when the connection to intent is severed, all that motion begins to dissolve into static. Work keeps getting passed around, the board stays busy and the program veers off course without producing a single alarming signal, because busy is what everyone was looking for.

Every quarter is a reset

New OKRs arrive. A fresh wave of leadership messaging follows. Sometimes the team gets reshuffled too. With each round, a little of the shared context that held everything together quietly slips away. Epics get new names, stories get rewritten, priorities rearrange themselves almost by accident. The organization keeps rebooting itself without ever asking what it left behind in the reset.

Taken one at a time, each of these patterns is understandable, even forgivable. Together they produce a program that looks healthy from every angle while it quietly hollows out the meaning behind the work.

Why this keeps happening, and why it’s about to get worse

Big programs tend to assume that intent will simply carry itself forward as the work passes through teams, decisions and iterations. It won’t. Intent doesn’t carry itself. If nobody actively preserves and updates the reasoning, it starts to loosen and fray, quietly and almost politely, one story, one trade-off, one shift in priority at a time.

The structural cause is a speed mismatch that most governance was never designed for. The delivery system evolves in hours; the organization’s memory of why updates in quarters, if at all. In between those two clocks, thousands of micro-decisions reshape what the work means, far faster than anyone captures the reasoning behind them.

Now add what’s happening in 2026. AI agents inside the delivery tooling can already organize, create and edit backlog items on a team’s behalf. Atlassian’s own customers describe agents that generate requirements, break them into epics and stories and take delegated work like a teammate, and these capabilities now ship inside the standard Jira plans that most enterprises already pay for. I’m not against any of this; some of it is genuinely useful. But notice what it means for our problem. Every one of those operations is an edit to a document that has no memory. Backlog amnesia at human speed was survivable. Painful, but survivable, because humans forget slowly. Amnesia at machine speed is a different animal altogether. The ratio of motion to memory, already unhealthy in most organizations, is about to go vertical.

If your backlog can’t remember why an item exists after a human rewrote it a few times, think about what happens when an agent grooms it continuously.

What to do about it

The countermeasures I use are deliberately small. None of them adds a ceremony, a tool, or a governance layer. They simply orient the practices teams already run toward one job: keeping the reasoning alive while the work moves. Together, they form the discipline I call Structural Agile.

• Start with the outcome. Before an epic or major story enters the backlog, three questions, every time: What behavior are we trying to shift? How will we know if that behavior changes? What signals will confirm success after release? If the room can’t answer, the work waits, because items that lack outcome clarity tend to drift first and drift fastest.
• Elevate the PO. Position the product owner as the carrier of outcome logic, with an explicit mandate to preserve rationale, flag trade-offs that erode intent and track deferred items together with the reasoning behind them. And be realistic about the limits, because many POs inherit chaotic backlogs, rotate mid-stream, or simply lack the authority to push back on stakeholders. The rule I give teams is simple: if the PO can’t carry the logic, someone must: a coach prompting context checks, an architect recording the reasoning behind technical trade-offs, an analyst keeping the outcome picture current. Build logic stewardship into the structure. Left to personality, it leaves with the person.
• Anchor epics to why. Every epic carries its rationale as metadata, inside the tool where the work actually lives. Slide decks from last spring don’t count. When a decision reshapes the epic, the rationale gets updated in the same motion; waivers and scope cuts get recorded next to the item they changed. Do this consistently and the backlog stops being a queue of tasks and becomes a living map of intent, one that a new joiner can read on day one, and that survives a challenge from leadership without anyone having to reconstruct history from memory. It cuts both ways, too: the same rationale that protects the team from whiplash protects the business from a backlog that has drifted away from what they actually asked for. Prioritization turns into a conversation about evidence rather than a contest of opinions.
• Rehearse erosion. This is the practice I’d start with, and the one that surprises teams most. Every two or three sprints, run a short, structured session that is not a retrospective and not a risk review. Its purpose is to test the continuity of intent itself: Does the assumed user behavior still make sense? Where might adoption fail even though delivery is technically correct? Which parts of the outcome logic feel fragile, outdated, or untested? A retro examines how the team worked; an erosion rehearsal examines whether the reasoning still holds. You rehearse erosion the same way pilots rehearse emergencies: you hope the drill is wasted, and you run it anyway, because catching drift early is what makes fixing it cheap. In my experience, a single one of these sessions surfaces more strategic risk than a quarter’s worth of status reporting, and it costs the team about half an hour.
• Keep the logic alive. Capture only what prevents strategic amnesia and nothing more: why a feature was removed or reshaped, who approved it and which assumptions should be revisited, and when. Keep it visible where teams already work. If logic lives in Confluence but dies in conversation, it’s already gone.

Start Monday

You don’t need a reorganization or a new framework to begin, and frankly you shouldn’t want one. Three entry points, close to zero overhead. Assign a critical reviewer: one team member whose standing job is to periodically ask whether stories still connect to the intended outcome. Add a one-minute outcome check before major refinements: the behavior targeted, the indicator watched, the signal expected. And run a single erosion rehearsal on your most important program; teams usually surface something real in the first session, long before it would have shown up in any metric.

For readers keeping score: yes, neighboring practices exist, and they’re good ones. Architecture decision records preserve the why behind technical choices, and impact mapping connects deliverables to goals at planning time. I use both. Neither operates continuously, inside the backlog, at the level of the individual item, which happens to be exactly where the forgetting occurs. OKRs don’t solve it either; objectives at altitude are necessary, but teams still need the rationale embedded in the work itself, so they don’t have to keep a separate decoder.

The history tab, revisited

Go back to that epic with the twenty-six edits, and imagine the same history with one difference: each consequential edit carries a line of reasoning, current and human-readable, and every few sprints someone deliberately tested whether that reasoning still held. Same team, same velocity, same tool and a completely different answer when someone finally asks why the work exists.

Velocity tells you how fast the work is moving. Only memory can tell you whether anyone still knows where it’s going.

I’ve published the full discipline behind this approach (the five principles, the roles, the facilitation guides and the objections seasoned practitioners will raise, along with my answers) as a featured paper in PM World Journal. The mechanics are free to steal. The forgetting, at this point, is optional.

Microsoft has unveiled a suite of IQ products over the last few months. Work IQ, Fabric IQ, and Foundry IQ build on what Microsoft used to call its “Graphs,” the underlying data architecture that underpins its cloud services. These graphs provided a way to query the data your business uses, treating that data as nodes in a graph database and using the GraphQL API model to extract that data — for example, to pull data related to a specific individual held across the various Microsoft 365 applications.

The IQ suite follows a similar approach, using the same data, but treating it as the sparse vector store needed to provide grounding data for LLM-based applications. By treating the data as a set of embedding vectors, and integrating it with Model Context Protocol (MCP) servers, Microsoft is giving you the necessary tools to tie LLM output to your data, reducing the risk of hallucination and improving accuracy. Using your own data is a key part of delivering effective agents, ensuring they work within your constraints.

Extending IQ to the web

Web IQ, the latest member of the IQ suite, was unveiled at Build 2026. A modernization of the retired Bing Search APIs, Web IQ is an agent-focused web search tool that builds on the massive Bing search index to provide up-to-date general information for use in your applications.

It may seem a little odd to be talking about a web-wide source of grounding data in the context of a suite of tools that exist to improve the accuracy of your AI applications by providing access to your Microsoft-hosted data. However, in many cases you want to link your agent not only to your data but also to related information from the wider world. For example, an agent powering an ecommerce service could use Web IQ and web-based data sources to provide product comparisons. An agent managing stock levels for a product that is weather-sensitive could use Web IQ as a source of weather data, using Bing’s multiple weather feeds and forecasts.

Just as Google Gemini drew on Google Search, Microsoft Copilot began by using Bing search data to provide grounding for consumer chatbots. It’s easy to take a service like Bing and use it with a LLM, as the nearest neighbor search algorithms use semantic vector similarity techniques to find results that look like your query, ranking them according to their proximity to your search terms.

Microsoft has been tuning its search vector index and the underlying technology stack to work with agents, as agents operate much differently than humans searching the web or querying a chatbot. Providing web search capabilities to agents means having to deal with persistent queries, as the agent hunts for the information it needs, refining queries and applying reasoning algorithms to develop the response it needs. LLM inferencing requires quick responses that deliver large amounts of data, working with queries that go far beyond the one-word or two-word requests that are typical of humans.

More than the training weights

Using Web IQ gives you access to up-to-date information, beyond the training data used to build and weight an LLM. Bing’s crawler works within the standards developed by the search engine industry, obeying meta tags and using its own algorithms to crawl regularly updated websites more often. Bing’s crawler ensures that data is both fresh and being used appropriately, with a focus on quality rather than quantity.

Providing access to web data is only part of Web IQ. Microsoft is using Web IQ to host its own models to manage embeddings, ranking, and content extraction, all running on the company’s global hyperscale platform. The intent here is to use only a limited number of models, to keep the system performance high while aiming to deliver accurate results. The Web IQ models are different from those used to deliver search results to humans, as they’re designed to deliver responses that are suitable for LLMs to use for reasoning.

The underlying search system is based on the DiskANN algorithm developed by Microsoft Research, which allows fast search without requiring enormous amounts of in-memory data access. This approach has been extended to manage information retrieval at scale, building on Microsoft’s distributed systems architectures, to support the demands Microsoft is seeing from agent-based systems. At the same time, it must respond to the rapidly changing economics of inference, where token costs now demand the best possible output from the fewest tokens.

To meet those economic demands, the Web IQ platform doesn’t deliver whole documents to querying agents. Whole documents can lead to expensive inference further down the chain, as LLMs process results repeatedly to drive the agent workflow. Instead, Web IQ structures the information retrieved from the underlying search engine data, delivering what Microsoft calls “structured evidence objects” as well as passage-level information from unstructured text documents. This should result in a much higher signal-to-noise ratio than simply querying a search engine, with a focus on delivering information that lets agents work using fewer tokens.

Using Web IQ in your agent code

The API for Web IQ is a standard REST call, delivering a request object to the Web IQ endpoint. Along with your API authorization key, you will send a query, a set of parameters that control the number of results returned, the language and region used, and the maximum size of the responses and the format used. Responses can be returned in text, HTML, or markdown formats, as well as extracted passages that are selected for context. All other options return the full document, so can be more expensive to use. Markdown is an interesting alternative, as it can be used as the basis for giving agents semantic memories.

Results include important contextual and citation information, including web page titles and URLs, as well as data about when the site was last crawled and how stale the underlying information is. This can be used to improve grounding and provide more information that can be included in formatted responses — much in the same way as Bing’s Copilot displays context in the form of footnotes in its responses.

Responses to video searches include text descriptions. If these aren’t provided as part of the original web content, they will be generated by an LLM. The same approach is used for image searches, with both offering the same contextual cues as the web search API. If you don’t care about the type of data being returned, you can choose a “classic search,” which will return text, images, video, and news.

Supporting autonomous agents

Microsoft provides LLM-ready documentation for the Web IQ service, with an llms.txt file and an OpenAPI description. These allow AI tools to discover Web IQ capabilities and include them in workflows as part of autonomous operations, so that agents and other AI applications can implement grounding calls to Web IQ whenever user interactions require them. The API descriptions include errors as well as the structure of a standard 200 response.

As Web IQ is designed for use by modern agent frameworks, the Web IQ API is available through an MCP server. The Web IQ MCP server exposes tools that map to API calls: web, videos, news, and images. They also include a browse option, which lets you pull content from a target URL. The service can be configured with a standard JSON file and requires an API key to control access and manage billing. If your account doesn’t have access to a specific tool, then it won’t be available from inside the MCP server.

If you’re building an agent and you want to evaluate the Web IQ MCP server, it can be added to common coding agents, such as the GitHub Copilot CLI. You can then test it out using familiar tools and generate code that can be dropped into applications via your choice of development tooling. Queries sent to the Web IQ MCP server use the same syntax as REST calls, without having to construct the calls yourself. Working with the MCP server allows you to connect Web IQ to your choice of agent framework, relying on its built-in MCP methods to reduce the code and maintenance overhead.

Web IQ is not for human interactions; Microsoft provides an alternative “Grounding with Bing” service for chatbots. Instead, Web IQ is a tool for agents, providing necessary background information that helps keep results fresh and relevant. It’s easy to use, fast, and, above all, cheap, which makes it an ideal tool for modern inference platforms built around Microsoft Azure’s AI tooling.

Shortly after OpenAI publicly acknowledged the Hugging Face breach on July 21, Reuters journalist Raphael Satter called me for comment on a story which would reveal shocking new details about OpenAI’s “rogue model” incident: The agent hadn’t just slipped its leash for a few hours, as many assumed, but had in fact been wreaking havoc for days without the company’s knowledge.

When I hung up, I immediately called a close friend who has worked inside frontier‑AI labs since before the term even existed. When she heard the timeline, she was stunned. In her view, “If proper industry regulations were in place, those four days would be grounds to terminate OpenAI’s R&D GPU clusters until they get a full independent audit.”

Demystifying the incident

There have been numerous reports that frame OpenAI’s model as a “rogue agent” escaping captivity and “breaking out” of the research lab, with both the BBC and Cloud Security Alliance comparing its actions to the dinosaurs in Jurassic Park.

This framing is narratively compelling and is an easy way to communicate the gravity of the situation to a layperson. However, it undermines OpenAI’s agency both before and throughout the incident and plays into a larger problem due to the evangelizing way the company communicated its actions.

OpenAI, in simplified terms, had been testing two models against a benchmark which scores how well an agent can find and exploit real-world software vulnerabilities. Both models ran with their cyber refusals deliberately reduced, in a sandbox environment meant to be isolated to a single internally hosted proxy. The models targeted Hugging Face, correctly inferring that the AI platform hosted the benchmark’s answer key — in short, “choosing” to cheat on the test they were given to complete the challenge.

Following the breach, Hugging Face’s forensic team found thousands of agent actions in its logs, indicating that the time it took to break into Hugging Face, plus the attack itself, totaled 4 days.

Hugging Face went public about the attack before it even knew that OpenAI was responsible. OpenAI, meanwhile, didn’t realize its own agent was the culprit until Hugging Face’s public disclosure made them check their own logs. In total, it took OpenAI nearly two weeks from its agent’s initial escape to come clean, and only once a rival’s hand had forced the issue.

OpenAI’s “problem child”

From a human perspective, it’s bewildering that out of all paths the OpenAI agent could have taken to beat a standardized security challenge, it chose a ludicrously convoluted approach taking tens of thousands of attempted paths and barreling through set restrictions. However, it was par for the course given one of the model’s track records.

In a post published the day before the Hugging Face disclosure, OpenAI describes one of its models that, unlike older versions that would simply stop at a sandbox restriction, would continue to persist until it found a way around, once even spending an hour hunting a sandbox vulnerability only to post its results to GitHub against explicit instructions. This model is GPT Sol 5.6, the public model involved in the Hugging Face attack.

Long before the Hugging Face incident, GPT Sol 5.6 was already gaining a reputation for breaking rules, taking laughably long to accomplish simple tasks, and being destructive — in one case deleting an AI entrepreneur’s entire Mac contents.

Even during internal testing, the model had been caught killing random processes when it couldn’t find the right virtual machines, lying about checking its work, and using credentials it wasn’t supposed to access. However, it was still given public access by the company.

Profit before safety

CSA’s report states that an OpenAI model escaped a test container in September 2024 for a different evaluation, was contained quietly and “largely celebrated at the time” rather than treated as a warning. The same report calls this kind of escape “the standard, not the exception.” The former head of OpenAI’s “superalignment” safety team resigned in May 2024 and wrote publicly that “safety culture and processes have taken a backseat to shiny products.” It was reported that nearly half of the team working on long-term AI safety had left.

Even the language used by OpenAI in their disclosure reads as more braggadocious than concerned. From OpenAI’s perspective, its failure was in not overseeing the agent’s choices as a whole, as each step taken by the model can remain fairly innocuous-seeming until pieced together. The company does not acknowledge that leaving an agent unsupervised in a testing setting with its safety classifiers off for even one hour, let alone days, is potentially catastrophic to begin with.

Some researchers have argued that the recent incident is fundamentally a decades-old security failure rather than a narrative about a rogue intelligence: the exploit involved an exposed proxy, reused credentials and infrastructure that should have never had a path outward. However, a skilled human attacker given that same door would have needed weeks to achieve a fraction of what the agent did in days.

A symptom of underlying issues

The incident reveals larger issues about the culture of safety at frontier model companies, whose employees are driven to crunch R&D cycles and ignore potential issues until they become active problems. This isn’t unique to OpenAI, either — the UK’s AI Security Institute has reportedly found that every frontier model it has tested cheats on cybersecurity evaluations at least occasionally, and that pre-deployment testing windows have shrunk industrywide from roughly five weeks to as few as five days.

Regulatory bodies have also failed to keep up with or understand the industry’s rapid advancements. The US has no binding legal framework that would have required a different response from OpenAI, as labs are only beholden to voluntary commitments weighed against commercial pressure, and in cases like these, huge security breaches only serve to make the model look extremely smart and powerful.

The US has attempted to create guardrails, but they fail to understand the ecosystem. We can see effects stemming from this lack of understanding in the recent attack: when Hugging Face’s responders needed to analyze what its attacker had done, Anthropic’s models declined the forensic work, citing their own guardrails, and Hugging Face instead ran the analysis on GLM 5.2, an open-weight model from the Beijing company Z.ai. In addition to being an ineffective band-aid, this also drives business outside of the US and therefore outside of its regulatory control. Today, roughly 80 percent of US AI startups now build on Chinese open-source models.

US Representatives have introduced a bill citing this incident by name, requiring killswitch capability and incident reporting, but nothing like it has passed, and no jurisdiction anywhere has demonstrated the insight to regulate evaluation-time behavior in addition to deployment-time behavior. This incident happened entirely during testing, before any release decision, in a stage every proposal currently treats as exempt.

It’s important to note here that AI safety and practices differ from other branches of cybersecurity in that they have to build from a behavioral and psychological framework instead of one based on capability alone.

For example, although Anthropic’s track record is far from spotless, it has invested significantly more energy than others into understanding the unconscious “thought processes” (or “j-space”) of its models to better predict potential transgressions and set up more effective guardrails. What we can learn from these “rogue models” is that their behavior is actually very predictable; we know that when given a goal to accomplish, models will overstep boundaries freely in pursuit of their objective, simply because they have no actual understanding of the way we categorize “acceptable behavior”. In the real world, vulnerability exploitation encourages rule-breaking and disregard for boundaries by design, so why would a model trained to think this way see a test’s rules any differently?

For CSOs and CIOs, the practical implication of this event remains narrow, for now. CSA’s post-mortem offers mostly traditional advice: isolate package proxies and credential stores with a path to the open internet by default, log AI evaluation environments the way you log anything customer-facing, and build incident response around machine speed rather than human speed.

The key risk factor for now is volume, with agents deploying actions at higher numbers than our pipelines are built to catch, and organizations that survive the next iteration of “rogue agents” will be the ones that assume as much beforehand.

When I first started working on enterprise AI security initiatives, I expected the biggest challenges to be technical. I assumed we’d spend most of our time discussing prompt injection, model security, vector databases or the latest LLM vulnerabilities.

I was wrong — or at least incomplete.

The technology certainly matters, but after working with multiple enterprise AI initiatives, I’ve learned that the hardest security problems rarely come from the model itself. They emerge when AI becomes part of real business processes.

An AI assistant doesn’t simply answer questions. In a single workflow, it might pull a customer record from Salesforce, open a ticket in ServiceNow and send an update through Microsoft 365 before anyone has finished reading the summary. Increasingly, it makes decisions before a human even notices, and that shift changes the threat model. Traditional application security assumes software executes deterministic code. AI systems don’t. They reason, adapt and generate outputs that cannot always be predicted in advance, which means many of the controls we’ve relied on for years remain necessary but are no longer sufficient.

What follows is what I keep coming back to in architecture reviews: Not the model vulnerabilities that dominate the headlines, but the quieter failures that show up once an agent is already running.

Identity is only the starting point

One of the first surprises I encountered was how quickly organizations focus on authentication while overlooking runtime behavior. Most enterprise AI projects begin with questions such as “Can the AI access SharePoint?” “Can it connect to ServiceNow?” “Can it connect to GitLab?” or “Can it read Microsoft 365 tools like Outlook, Word, etc.?” Those are important questions, but the more important one is: What should the AI be allowed to do after a specific type of access (for example, read-only access) has been granted?

Identity answers who the agent is. Authorization answers what it may access. Neither answers whether the AI should perform a particular action; in the above case only performs read-only access.

The capability question and the safeguard question are too often answered by different teams on different timelines. Security reviews that focus only on what the AI can access tend to miss the more revealing question of what it is permitted to do once that access exists. I have started treating those two questions as a single design problem, because every gap between them eventually surfaces as an incident.

I remember an architecture review where this became concrete. An employee asked an internal assistant — one built on Microsoft 365 and SharePoint — to summarize several incident reports, and during its reasoning the assistant discovered privileged administrative documentation in a linked site and decided it might also be useful to include those details. Nothing technically failed. The credentials were valid. The permissions were correct. Yet the outcome violated business intent. That moment reframed the conversation for everyone in the room. We realized our threat model had been built for outsiders trying to get in, not for authorized systems acting a little too helpfully. Closing that gap meant designing controls that evaluated behavior in context, not just credentials at the door, and it’s why I’ve come to view runtime governance as one of the defining security challenges of enterprise AI.

Organizations such as the OWASP GenAI Security Project and the NIST AI Risk Management Framework emphasize that AI risks extend well beyond authentication authorizations to include monitoring, governance and continuous oversight throughout execution. CSOonline’s coverage of agentic identity makes the same point: Existing controls weren’t designed for AI agents, and static credentials and standing privileges are no longer sufficient when organizations must rapidly authorize, limit and revoke permissions from autonomous agents, sometimes more than once within a single workflow.

The biggest failures rarely look like cyberattacks

Most security professionals naturally look for malicious activity: Prompt injection, data poisoning, credential theft, model manipulation. Those attacks certainly matter. What I’ve seen more frequently, however, are failures caused by legitimate AI behavior. A Finance, HR, Customer or risk management AI assistant retrieves more documents than necessary because it tries to provide a “better” answer. An autonomous workflow performs five approved actions instead of one. An AI agent continues executing after the user’s original intent has already been satisfied. None of these resemble traditional attacks, yet they may create compliance violations, privacy issues or operational disruption.

One mental model has consistently helped executives understand why this is so dangerous. I ask them to stop thinking about AI as software and instead think about it as hiring thousands of new digital employees, aka AI agents. Every employee receives training, limited access, monitoring, auditing and oversight. AI agents deserve the same treatment.

One deployment I worked on involved multiple specialized AI agents collaborating to complete a single business task. One queried ServiceNow for ticket history, another analyzed documents in SharePoint, a third drafted recommendations and a fourth wrote updates back into Jira. Individually, each agent had relatively limited permissions like read-only and/or write. Collectively, they represented a powerful autonomous workflow. That experience reinforced an important lesson: Security can no longer focus only on individual AI components. It must govern the complete chain of autonomous decision-making. The MITRE ATLAS framework is an excellent way to think about adversarial AI techniques, but equally important is understanding how normal autonomous behavior can unintentionally create business risk.

The most instructive cases I’ve seen involve agents that delegate to other agents. In one review, a frontline support agent had strictly read-only access to Salesforce, but it could hand tasks to a second agent that held write privileges across ServiceNow and the billing platform. When the first agent couldn’t resolve a customer issue within its own scope, it quietly routed the request through the second agent, which updated the case and issued a credit. Nothing was hacked. The credentials were valid, the delegation was technically permitted, and yet a read-only agent had effectively performed write actions it was never meant to perform. That is the defining difference between an assistant and an agent. An assistant answers; an agent enlists other agents, and that escalation path is itself the vulnerability.

That’s why we started asking a different question during architecture reviews. Instead of asking “Can the AI do this?” we asked, “Should the AI still be doing this?” That subtle shift changed many design decisions. It pushed teams to build in stopping conditions, scope checks and confirmation prompts rather than assuming an agent would naturally know when to stop. In one review, simply requiring a human to confirm before an agent crossed from a read-only step into a write action eliminated the majority of the risky paths we had been debating.

Start with governance before autonomy

One pattern I’ve repeatedly observed is that organizations become excited about autonomy long before they’re prepared to govern it. Everyone wants AI agents, but few initially invest in runtime policy enforcement. That sequencing should be reversed. In my experience, successful enterprise AI programs put a few foundations in place before expanding automation: Clear business boundaries that an agent isn’t allowed to cross, least-privilege access for every agent, and human approval at any step that touches sensitive/restricted data/systems, including the production data /systems. Only after those exist does it make sense to widen autonomous decision-making. I’ve watched teams try to shortcut this order, and the result is almost always the same: A promising pilot gets pulled back because no one can confidently explain what the AI did or why.

A big part of that foundation is visibility. Traditional audit logs record actions, but AI systems also need to record reasoning. When an AI agent creates a ticket, updates a configuration or sends an email, investigators should understand why the decision occurred. This doesn’t mean recording every token generated by a large language model. I’ve found more value in capturing three things: The original business request, the systems the agent touched and the decisions it made along the way. Those records become invaluable during investigations, compliance reviews and operational troubleshooting, and they help organizations build trust. Business leaders become far more comfortable adopting AI when they can explain how an important decision was reached. Approaches like Google’s Secure AI Framework reinforce the same idea: AI security has to be measurable, observable and accountable end to end.

One misconception I still encounter is that AI security exists to restrict innovation. In practice, the organizations moving fastest with enterprise AI are often the ones investing most heavily in governance, because executives gain confidence, developers move faster and business units adopt AI more broadly. Done well, security is what makes that speed possible.

Looking back, the most valuable lesson hasn’t been about prompt engineering, model selection or agent frameworks. It’s that secure AI isn’t achieved through one perfect control but through hundreds of small engineering decisions that keep autonomous systems aligned with business intent. As we move from assistants toward fully autonomous agents, that distinction only matters more. The teams I trust to scale AI aren’t the ones with the smartest models. They’re the ones who can answer, for any action an agent took, why it took it — and where it would have stopped.

More evidence is emerging about how AI is becoming part of the day-to-day workflow for cybercriminals, from building and refining tools to managing infrastructure and accelerating vulnerability research.

Drawing on recovered prompt logs, attack tooling, and threat actor conversations, research from Cisco Talos documents how AI is being used to develop malicious code, build fraud infrastructure, and accelerate vulnerability research and exploitation.

The study, released during the Black Hat USA conference, found AI systems guardrails were often ineffective.

Cisco Talos researchers write that threat actors frequently bypass guardrails with basic social engineering claims (“this is authorised testing” or “I’m asking this as part of a capture the flag exercise”) that convince most models to comply.

This duped permissiveness wasn’t specific to a single model or platform. Instead, analysis of prompt logs related to Claude Code, CodeX, Cursor, and Gemini showed this shortcoming was an issue across the board. And when censored models refuse, threat actors simply switch to uncensored alternatives.

Whereas novice cybercriminals continue to produce clunky malware with limited functionality, sophisticated threat groups are increasingly leveraging AI as a development assistant to rapidly build exploits, and some are even deploying it as a system administration tool for managing large-scale attack infrastructure.

Cisco Talos found real-world examples of attackers abusing AI systems to build a bulk-mail validation service processing tens of millions of email records, adapting the React2Shell vulnerability into a credential-harvesting pipeline, developing DDoS infrastructure targeting Android TVs, and supporting cryptocurrency theft operations, among other attacks.

Joseph Rooke, senior director at Recorded Future’s Insikt Group, sees attacker tradecraft evolving away from traditional code-based exploits toward prompt-based manipulation of large language models.

“Targeting weakness in LLMs enables malicious prompts to be embedded in shared text, video, or image files, with the aim of hijacking LLM-based assistants to carry out attacks,” Rooke tells CSO.

Norwegian AI researcher Håkon Måløy recently demonstrated such an attack, which could result in a Copilot worm spreading through Microsoft Word docs. Attackers are also crafting malicious AI instruction files, like CLAUDE.md, to trick agents into exfiltrating data and other tasks on their behalf.

“Malicious prompts will increasingly replace malware as the preferred intrusion method, enabling adversaries to extract sensitive data, override guardrails, or induce harmful actions without breaching traditional defenses,” Rooke says.

Attacking AI through the software supply chain

Separately, research from CrowdStrike shows that adversaries are increasingly targeting AI infrastructure through software supply chain-style attacks.

For example, in March 2026, North Korean cybercrime group Stardust Chollima used stolen maintainer credentials to compromise the Axios npm package and deliver platform-specific variants of their ZshBucket malware.

In June 2026, the same group injected a malicious npm package as a dependency into at least 131 Mastra AI framework packages, indicating that trusted AI building blocks are becoming targets in supply chain attacks.

During 1H 2026, 87% of identified software registry threats involved malicious npm packages. “This indicates adversaries’ preference for JavaScript’s scale, dependency chains, and automatic install scripts to spread downstream risk,” CrowdStrike’s researchers report.

CrowdStrike’s 2026 Threat Hunting Report also reveals how AI is collapsing the window between vulnerability disclosure and active exploitation.

For example, two separate Chinese APT groups exploited critical vulnerabilities within 24 hours of public proof-of-concept (PoC) release. From January through June 2026, 88% of CrowdStrike-observed exploitation of vulnerabilities with a public PoC was conducted within 48 hours of the PoC’s release.

After the React2Shell vulnerability disclosure, CrowdStrike responded to over 800 hunting leads across more than 80 victims in just four days.

Cybercrime group Altered Spider (aka TeamPCP) compromised more than 300 software dependencies in a single day to harvest credentials and pivot into cloud environments.

Authentication systems under attack

The study — based on frontline intelligence from CrowdStrike’s threat hunters and intelligence analysts — also found that trusted authentication has become a favored attack path with, for example, vishing intrusions doubling in 1H 2026. On a related front, cybercrime groups Cordial Spider and Snarky Spider compromised single sign-on (SSO) integrated SaaS applications for data exfiltration.

Recorded Future’s Rooke points out other ways authentication systems are at the front line of AI-based attacks.

“AI-generated deepfake videos and audio are also more likely to be used as part of business email compromise attacks and social engineering,” Rooke tells CSO. “Biometric and identity-verification systems will likely remain vulnerable to spoofing, replay, and cloned credentials, enabling synthetic personas to coerce payments, manipulate employees, and facilitate access handoffs to cyber operators.”

Cloud-focused cybercrime activity surged 171% as adversaries executed credential theft, cryptomining, LLM abuse, and digital financial asset theft, according to CrowdStrike.

How cyber teams should respond

“AI is now embedded in modern adversary operations. It is changing how attacks are planned, executed, and scaled while expanding the attack surface organizations must defend,” says Adam Meyers, head of counter adversary operations at CrowdStrike. “The organizations that succeed will secure AI as aggressively as they adopt it and use AI to defend at the speed of the adversary.”

Comprehensive industry-wide data remains limited because evidence of AI abuse is often difficult to identify via traditional security telemetry. Incidents documented by Cisco Talos and CrowdStrike, however, show how CISOs need to adapt in response to the growing threat.

Cisco Talos urges enterprises to improve detection, prioritization, and their own use of AI platforms and agents to handle the growing volume of alerts and vulnerabilities. “The organisations best equipped to handle the coming deluge of additional vulnerabilities, alerts, and incidents will be the ones that prepare now by deploying their own AI-assisted security capabilities,” according to the report.

“Security teams should assume AI is already embedded in attacker workflows; focus on detecting malicious behavior rather than proving AI involvement; treat LLMs and APIs as privileged, high-risk infrastructure; and strengthen logging, patching, and containment,” says Oliver Simonnet, lead cybersecurity researcher at AI security and governance platform CultureAI.

The race to adopt AI has left many CIOs wrestling with a fundamental question: How do you move faster without introducing unacceptable risk?

Few leaders face that challenge at a higher level than David Burns, CIO of GE Aerospace. Building on the company’s decade of experience applying AI across its business, Burns is helping lead the next phase of the company’s digital transformation by leveraging AI to simplify and automate processes. Burns’ experience shows how AI can accelerate innovation, improve decision-making, and create value for the business and customers while maintaining the trust, safety, and operational rigor expected in the aerospace industry.

In a recent episode of the Tech Whisperers podcast, Burns opened up his playbook for leading organizations through turbulence. In this conversation, edited for length and clarity, he shares more practical lessons for technology leaders who are seeking to move beyond experimentation and scale AI responsibly across the enterprise.

Dan Roberts: You’ve described AI as an accelerator. What exactly is AI accelerating inside GE Aerospace?

David Burns: At GE Aerospace, AI is used across our operations as an accelerator to Flight Deck, our proprietary lean operating model, and is applied to all key aspects of the business — design, manufacture, sales, and services. We identify and solve problems with Flight Deck and use AI to accelerate our problem-solving in ways we can genuinely feel, enabling us to identify issues earlier, solve problems faster for our customers, and improve how work gets done.

For example, we are also using AI in:

Design: While traditional processes for developing engine design concepts take months of manual work, the GE Aerospace Research Center built a proprietary generative AI application capable of producing hundreds of design concepts. As a result, the team produced the hypersonic ramjet engine design concept that met all regulatory requirements more than 90% faster than before, highlighting how AI is possible in engine design to support engineers bringing new technologies to market faster.

Manufacture: Our team in Indianapolis used an AI coding assistant to automate a part quality inspection workflow, reducing 8 hours of manual measurement data entry for complex parts to just 3 seconds while improving data accuracy and inspection consistency. This has improved both the quality and efficiency for clearing parts to build, which helps drive on-time engine deliveries.

Sales: Based on customer feedback that GE Aerospace’s responses for proposals needed to be faster, the sales team utilized a generative AI tool to synthesize data and produce deal proposals. The tool improved customer response time by more than two weeks for the GEnx team through reduced proposal development cycle time and standardized creation of more comprehensive deal proposals.

Service: When LEAP engine rebuilds faced potential turnaround time (TAT) challenges due to material availability at our Maintenance, Repair and Overhaul (MRO) sites, our team in Lafayette, Indiana, applied AI to help reduce delays for customers. Using Daily & Visual Management, they surfaced material flow challenges and their underlying drivers, leading to a new AI solution that leverages data to predict when and where parts are needed faster to reduce delays for our customers with an approximately six-day turnaround time improvement, 16% increase in on-time material orders, and 15% increase in on-time material delivery.

Ultimately, by leveraging AI, Flight Deck helps us eliminate waste and identify and accelerate the most value-added steps for our customers, be it designing a part faster or responding to a customer request faster. And I would underscore that it’s value through the eyes of our customer. How we define value is not what we internally say; it’s how our customers define value, and how we’re working to be more customer-driven.

GE Aerospace has been investing in analytics, machine learning, and digital capabilities for more than a decade. What advantages does that foundation create as you move into the generative AI era?

We’ve built one of the largest AI patent portfolios in the aviation industry through years of investment and supercomputing through digital technologies, and we continue to do work on our core transactional systems and our data foundations, so that way our data is AI-ready. This has allowed us to build our own AI capabilities and strong talent base. For example, the generative AI app we built to create new propulsion systems design was built in house by GE Aerospace scientists at the GE Aerospace Research Center.

At the same time, our knowledge and familiarity with the landscape has allowed us to make connections with tech companies, including one where we’re using agentic AI in a multi-year partnership to predict demand and identify constraints to enhance production readiness in the Defense business.

We were fortunate to have leaders who were very smart to invest in data scientists 10, 15 years ago, and we’re getting to leverage that talent today. The lesson there is that is you always have to be thinking long term when you’re talking about talent, because you may not know exactly how the world will play out, but making sure you have the best athletes on the field to run the race becomes critically important. For us, some of those investments we did around our people is what’s paying off today.

One of the biggest challenges facing CIOs today is balancing innovation with risk management. How do you approach that balance in an industry where safety, reliability, and trust are non-negotiable?

It’s all about risk tolerance. There are certain areas in our business where we don’t have high risk tolerance, and we’re very methodical and cautious about how we deploy technology into those uses and have very stringent processes that we comply consistently with. In areas that are not safety and quality critical, we are more aggressive in looking at how we can use technology to deliver more for our customers and to make our employees more effective. That’s where we strike the balance, and at the end of the day, it’s about making sure we’re never compromising safety or quality in what we do.

As for the process, we start with Flight Deck and focus AI where it can help solve critical challenges for our customers and with the highest impact to customer outcomes, enhancing safety, quality, delivery, and cost, in that order, to solve problems that matter most and keep fleets flying. ​

We have three guiding principles for safe and responsible AI use: 

• Trust: The data-informing AI must be known, trusted, and reliable. 
• Transparent: The AI must be transparent and repeatable, which means we need to know what is informing an AI model’s insights and actions.
• Human: A human must always be in the loop and make the final decision.    

Our culture of discipline also plays an important role. Our business variation is challenging, so one of the core fundamentals of Flight Deck is standard work. It’s embedded into our culture, and it’s the base expectation that we operate with standards that we’re continuously improving.

Many organizations are struggling to move from AI pilots to enterprise-scale value. What lessons have you learned about successfully scaling AI across a large, complex organization?

AI is a tool that strengthens the capabilities of skilled employees; it is not a substitute for their judgment, experience, or accountability. So we focus on testing and validating AI solutions through pilots before scaling, and look for AI applications that meaningfully change how work gets done.

Early on, when we started doing a lot of our generative AI work, we focused on 14 big problems in the business, and we didn’t let ourselves stray all over the place. We also didn’t look at it as a technology solution. We looked at the process and where technology played into the process, and then we embedded AI into those core processes. So now, it’s not a separate thing where you go do AI. It’s embedded in the workflow of how things get done.

That gave us a foundation to learn and grow from that we’ve now applied. We’re not trying to create popcorn AI solutions all over the place. We’re trying to transform our business processes. In some cases, we’re doing good old process improvement, lean process improvement, eliminating waste, not necessarily a technology play. In other places, we’re applying technology that’s helping to lift us up and accelerate value by embedding it into the way work gets done, with a little bit of burning the boats behind you. You’re not able to do it the old way. You’ve got to use the tools. You’ve got to use the technology, because it’s the best-known way of doing it. The technology becomes part of the standard work.

That’s why one of the biggest lessons in scaling AI is that success starts with the core fundamentals and understanding the problem you’re trying to solve. It’s critical to test and validate AI solutions before they are deployed at scale to ensure they improve how work gets done and become embedded in our workflows. If you do not have strong standard work and transparent and reliable data in place, it becomes difficult to move beyond pilot stage and create repeatable value at scale.

Every day brings a new AI announcement, new model, or new prediction about the future. How do you separate what is truly meaningful from what is simply noise, and what advice would you give other leaders trying to do the same?

First and foremost is starting with the problem being solved, not the solution. If you’ve got a hammer that you want to use, everything starts looking like a nail. The most effective use of AI begins with an understanding of the problem that needs to be solved, then determining whether AI is the right tool to address it.

As far as dealing with distractions, and there are a lot of them right now, it’s important to try a lot of things, but very quickly, and then make decisions on which are the bets you want to make and spend more time and more money on and which are the ones you want to pivot away from. We spend a lot of time doing quick experiments with technology and then having the courage to stop something when it’s not working.

What excites you most about the future intersection of AI, engineering, manufacturing, and aerospace? And what should CIOs be doing today to prepare for that future?

Across aviation, AI is already helping to enhance safety, support more efficient operations, strengthen the resilience of global fleets, and improve the overall passenger experience. That includes GE Aerospace. These benefits come from investing not only in technology, but also in people, capacity, and trusted partnerships. 

They also depend on building mature, fully connected data threads through manufacturing and services that will drive higher value across our operations. The challenge will be ensuring that we enable this data thread across our operations to support AI solutions that will be developed and deployed.

The most important thing is to understand that the role of digital technology and information technology is fundamentally going to change. When I came out of university, the only people that knew how to do software coding were computer scientists or information systems majors. We used to frown upon shadow IT, but the reality is, now everyone coming out of college knows how to do some level of software development, and AI tools are only going to make that easier.

What CIOs need to start doing today is prepare for the future. The big questions they need to answer: How are they going to make sure they’ve got the platforms and the data set up in a way to serve a workforce that is capable of doing true citizen development, able to develop their own applications, their own solutions? How do you govern that from a data perspective, from a data privacy perspective, from a cybersecurity perspective, while not stifling but enabling the innovation of all those smart people that we’re hiring?

While many organizations search for shortcuts to AI success, GE Aerospace’s disciplined investment in data, analytics, talent, and operational excellence sets the company apart. Burns’ experience offers a clear lesson for CIOs: Creating the greatest value from AI requires building the capabilities, culture, and foundations that allow AI to amplify what the organization already does exceptionally well. For more from his leadership playbook, tune in to the Tech Whisperers.

The scheduling fallacy and the shift to autonomy

Walk onto almost any manufacturing shop floor, and you will witness the same systemic vulnerability: a brilliantly engineered, multi-million-dollar Advanced Planning and Scheduling (APS) system rendered completely useless by a single delayed delivery truck, an unexpected machine drift or a sudden workforce shortage. Industrial operations do not happen in a sterile room; the moment a perfect plan hits the messy reality of the physical shop floor, real-world variables inevitably shatter it.

This is the scenario (or challenge) that I have been navigating over the past few months and is likely to keep me occupied for the remainder of the year. I began this project believing the scheduling engine was the problem. After months of experimentation, including trying to make LLMs perform optimization, I realized I was solving the wrong problem. The realization that dawned on me was that it wasn’t about a better algorithm; it was about separating mathematical optimization from operational reasoning.

According to the 2026 Gartner Manufacturing Predicts report, factory orchestration is moving rapidly toward a “double helix” model where software-defined enterprise data intricately intertwines with autonomous production orchestration. Gartner also projects that 40% of enterprise applications will feature integrated, task-specific AI agents by the end of 2026 — a massive leap from less than 5% in 2025. For technology leaders, the mandate is clear.

Deconstructing the “reasoning layer”

Let’s first demystify what a “Reasoning Layer” is and what it is not. It is not a Generative AI nor is it a glorified Robotic Process Automation (RPA) script executing static, hardcoded logic. Instead, the Reasoning Layer is a cognitive overlay powered by foundation models. These models have been fine-tuned on operational ontologies, enterprise supply chain strategies and real-time shop-floor data streams. Pretty much everything that happens in your organization and, in many cases, outside as well, as some decisions are impacted by the prevailing external situation.

A reasoning layer continuously answers a complex question: Given this specific disruption, what is the optimal business choice right now?

The dual-engine architecture: Math meets cognition

A common pitfall has been to expect an LLM to handle both. That was the blunder I committed was to assume that a sufficiently trained LLM can get the job done.

The true breakthrough in designing a production-grade scheduling application lies in pairing semantic intelligence with raw mathematical muscle.

To solve this, what I discovered was that you need to split it into two layers. A number-crunching mathematical layer and a qualitative layer. Both working in sync.  

1. The quantitative engine: Global pathfinding, sequence optimization and multi-plant capacity balancing are treated as a highly complex routing problem. Ant Colony Optimization (ACO) algorithm, for example, excels here. It can navigate massive combinatorial data spaces to find optimal/near-optimal scheduling sequences across interdependent lines. A word of caution though: This requires good quality data and lots of it.
2. The qualitative brain (agentic AI): The AI agent serves as the dynamic coordinator. It monitors the operational environment for live telemetry anomalies (such as machine cycle-time drifts or supply chain delays). When an anomaly occurs, the agent evaluates the business impact. Determines whether a re-optimization is required and crucially rewrites the constraints and boundary conditions before triggering the ACO engine.

By using the Agentic Layer to bound the mathematical problem, the system avoids the fatal flaw of traditional advanced planning tools: completely rewriting a global schedule over a minor local exception.

The multi-plant orchestration paradox

When a manufacturing organization expands from a single facility to a distributed, multi-plant network, operational complexity does not scale linearly — it scales exponentially. In theory, a multi-plant footprint should provide an enterprise with built-in resilience, giving leadership the flexibility to shift production loads when disruptions strike. Most manufacturing organizations suffer from the multi-plant orchestration paradox: they possess massive regional capacity but are structurally blind to how to leverage it dynamically.

The root cause of this paradox is the historical legacy corporate silo. If a plant in Chennai faces a sudden logistics bottleneck or a critical machine breakdown, its local team scrambles in isolation. Meanwhile, a sister plant in Pune operates completely unaware that it possesses the excess capacity, specific tooling or material buffers required to absorb the overflow.

By the time information filters up to corporate logistics and decisions are taken, you would have lost precious capacity and time.

Enter MAGS: The rise of agent-to-agent collaboration

To shatter these corporate silos, the reasoning layer must expand past local optimizations and facilitate cross-facility orchestration. This shift is driven by a distinct architectural evolution: Multi-agent generative systems (MAGS). Gartner highlights the rapid acceleration of this trend, predicting that by 2027, one-third of all agentic AI implementations will focus heavily on autonomous agent-to-agent collaboration.

In a MAGS framework, the scheduling agents of individual plants do not operate in a vacuum. Instead, they form an interconnected, distributed network capable of autonomous negotiation. The architectural flow of this cross-facility negotiation occurs across three distinct phases:

• Perception: Local plant agents continuously ingest live IIoT telemetry, tracking real-time machine interdependencies, resource pooling variances and material transit times across physical transport lanes.
• Interpretation: When an anomaly occurs, the local agent instantly evaluates the disruption against localized business constraints.
• Negotiation: Rather than escalating every minor bottleneck to a human director, Plant A’s scheduling agent connects directly to Plant B’s agent over the secure network. The agents cross-negotiate load-balancing options, evaluate transportation lead times and run localized optimization calculations in parallel.

Instead of forcing supply chain teams to manually bridge data gaps during a crisis, the system bypasses legacy functional silos. It presents the COO’s operations team with a pre-validated, end-to-end scheduling solution.

Real-world applications: Grounding autonomy in industrial reality

To understand how this functions in the real world, we must look beyond theoretical multi-agent frameworks and examine how this architecture operates within live factories. The following two case studies—drawn from highly documented, peer-reviewed industrial implementations — demonstrate how multi-agent generative systems (MAGS) actively protect margins and timelines when unexpected disruptions strike.

Case study 1: The discrete architecture (The Festo cyber-physical agent framework)

• The context: This architecture is modeled after the landmark decentralized orchestration frameworks deployed at Festo’s Scharnhausen Technology Plant. Instead of relying on a centralized ERP/MES brain to dictate every move, the facility utilizes cyber-physical systems (CPS) where the physical components and machines operate as an interconnected multi-agent system (MAS).
• The disruption: During a high-volume discrete run of automation components, a critical machining center suffering an unexpected tooling failure, in a traditional centralized setup, would have triggered a cascade of line stoppages.
• The intervention: The affected machine’s resource agent instantly broadcasts its downtime status across the network. The task agents ingest the anomaly and independently query neighboring machining cells. The setup utilizes an underlying ACO routing routine to calculate the most efficient physical path through alternative, under-utilized cells. The Task Agents actively barter for open capacity with these alternative resource agents, dynamically adjusting their own operational sequences.

Case study 2: The process pivot (The TU Dresden battery manufacturing framework)

• The context: This case is drawn directly from a multi-layer agent-based framework engineered for a European lead-acid battery manufacturer in coordination with researchers at TU Dresden. The environment features 31 highly energy-intensive heat-treatment and curing chambers, where localized utility tariff volatility drastically impacts production margins. Continuous chemical process lines cannot simply be shut down without massive material waste and lengthy restart sequences.
• The disruption: A sudden, localized weather event triggers an unpredicted spike in peak-load electricity pricing, threatening to entirely erase the profit margin on a high-volume production run.
• The intervention: To solve this, the plant utilized a multi-layer agent-based framework. An energy-monitoring agent tracking live utility tariff feeds communicated the financial threat directly to the production scheduling agent. Instead of a crude emergency halt, the reasoning layer queried the facility’s computerized maintenance management system (CMMS). The agentic layer identified a mandatory 4-hour preventative maintenance window scheduled for three days later. The agent made an executive operational decision: it pulled that maintenance window forward to occur during the exact hours of peak utility pricing, converting an expensive tariff penalty into required downtime. Simultaneously, lower-level agents representing the individual curing chambers and material pallets recalculated local constraints, instructing the optimization engine to compress and accelerate subsequent production batches during the cheaper, off-peak night shifts.

The business outcome

In both cases, the agents optimized an operational pivot, and optimally utilised production capacity in the former and saved precious cash in the latter.

Governance, trust and the “human-in-the-loop” guardrails

All that seems great and seems like science fiction; it inevitably raises a critical, polarizing question for the C-suite: If the algorithms are making multi-thousand-dollar operational choices in real time, how do we maintain control?

The solution to this executive anxiety is a framework defined as “autonomy within boundaries,” executed through policy-as-code. Under this model, operational leaders stop managing the volatility of daily schedules. Instead, they focus on creating and managing policy boundaries within which the agents are permitted to negotiate and self-heal.

This splits operational exceptions into 2 zones:

• Autonomous execution zone: The multi-agent system has full authority to re-sequence lines, re-route components or shift maintenance windows autonomously, provided the financial & operational impact is under a predefined limit.  
• Expert advisory zone: The moment a proposed optimization breaches either of these metrics, the agent pushes it to an executive dashboard for immediate human intervention, validation and approval.

This dual-layer approach introduces a reliable operational framework to industrial manufacturing: leadership manages strategic intent, while tactical units manage real-time execution.

By establishing clear thresholds, the fear of an algorithmic “runaway train” is entirely mitigated. However, deploying a complete multi-agent governance framework across an entire enterprise footprint cannot happen overnight.

To move this from my serendipitous but compelling discovery to a live, risk-mitigated environment, I need a highly controlled, phased deployment strategy, an actionable roadmap to pilot, test and scale the reasoning layer without disrupting current production baselines.

We often say Industry 4.0 connected machines. I believe Industry 5.0 will connect decisions. The factories that succeed will not simply automate workflows; they will build systems capable of reasoning within clearly defined operational boundaries.

I am therefore not writing a conclusion here. I would probably be back in a few months writing about the outcome of this exercise. Somehow deep-down I suspect it would be less oriented to technology but how the change management progressed. I have a strong feeling that “…operational leaders stop managing the volatility of daily schedules. Instead, they focus on creating and managing policy boundaries …” would be the toughest part of this change.   

The scheduling fallacy and the shift to autonomy

Walk onto almost any manufacturing shop floor, and you will witness the same systemic vulnerability: a brilliantly engineered, multi-million-dollar Advanced Planning and Scheduling (APS) system rendered completely useless by a single delayed delivery truck, an unexpected machine drift or a sudden workforce shortage. Industrial operations do not happen in a sterile room; the moment a perfect plan hits the messy reality of the physical shop floor, real-world variables inevitably shatter it.

This is the scenario (or challenge) that I have been navigating over the past few months and is likely to keep me occupied for the remainder of the year. I began this project believing the scheduling engine was the problem. After months of experimentation, including trying to make LLMs perform optimization, I realized I was solving the wrong problem. The realization that dawned on me was that it wasn’t about a better algorithm; it was about separating mathematical optimization from operational reasoning.

According to the 2026 Gartner Manufacturing Predicts report, factory orchestration is moving rapidly toward a “double helix” model where software-defined enterprise data intricately intertwines with autonomous production orchestration. Gartner also projects that 40% of enterprise applications will feature integrated, task-specific AI agents by the end of 2026 — a massive leap from less than 5% in 2025. For technology leaders, the mandate is clear.

Deconstructing the “reasoning layer”

Let’s first demystify what a “Reasoning Layer” is and what it is not. It is not a Generative AI nor is it a glorified Robotic Process Automation (RPA) script executing static, hardcoded logic. Instead, the Reasoning Layer is a cognitive overlay powered by foundation models. These models have been fine-tuned on operational ontologies, enterprise supply chain strategies and real-time shop-floor data streams. Pretty much everything that happens in your organization and, in many cases, outside as well, as some decisions are impacted by the prevailing external situation.

A reasoning layer continuously answers a complex question: Given this specific disruption, what is the optimal business choice right now?

The dual-engine architecture: Math meets cognition

A common pitfall has been to expect an LLM to handle both. That was the blunder I committed was to assume that a sufficiently trained LLM can get the job done.

The true breakthrough in designing a production-grade scheduling application lies in pairing semantic intelligence with raw mathematical muscle.

To solve this, what I discovered was that you need to split it into two layers. A number-crunching mathematical layer and a qualitative layer. Both working in sync.  

1. The quantitative engine: Global pathfinding, sequence optimization and multi-plant capacity balancing are treated as a highly complex routing problem. Ant Colony Optimization (ACO) algorithm, for example, excels here. It can navigate massive combinatorial data spaces to find optimal/near-optimal scheduling sequences across interdependent lines. A word of caution though: This requires good quality data and lots of it.
2. The qualitative brain (agentic AI): The AI agent serves as the dynamic coordinator. It monitors the operational environment for live telemetry anomalies (such as machine cycle-time drifts or supply chain delays). When an anomaly occurs, the agent evaluates the business impact. Determines whether a re-optimization is required and crucially rewrites the constraints and boundary conditions before triggering the ACO engine.

By using the Agentic Layer to bound the mathematical problem, the system avoids the fatal flaw of traditional advanced planning tools: completely rewriting a global schedule over a minor local exception.

The multi-plant orchestration paradox

When a manufacturing organization expands from a single facility to a distributed, multi-plant network, operational complexity does not scale linearly — it scales exponentially. In theory, a multi-plant footprint should provide an enterprise with built-in resilience, giving leadership the flexibility to shift production loads when disruptions strike. Most manufacturing organizations suffer from the multi-plant orchestration paradox: they possess massive regional capacity but are structurally blind to how to leverage it dynamically.

The root cause of this paradox is the historical legacy corporate silo. If a plant in Chennai faces a sudden logistics bottleneck or a critical machine breakdown, its local team scrambles in isolation. Meanwhile, a sister plant in Pune operates completely unaware that it possesses the excess capacity, specific tooling or material buffers required to absorb the overflow.

By the time information filters up to corporate logistics and decisions are taken, you would have lost precious capacity and time.

Enter MAGS: The rise of agent-to-agent collaboration

To shatter these corporate silos, the reasoning layer must expand past local optimizations and facilitate cross-facility orchestration. This shift is driven by a distinct architectural evolution: Multi-agent generative systems (MAGS). Gartner highlights the rapid acceleration of this trend, predicting that by 2027, one-third of all agentic AI implementations will focus heavily on autonomous agent-to-agent collaboration.

In a MAGS framework, the scheduling agents of individual plants do not operate in a vacuum. Instead, they form an interconnected, distributed network capable of autonomous negotiation. The architectural flow of this cross-facility negotiation occurs across three distinct phases:

• Perception: Local plant agents continuously ingest live IIoT telemetry, tracking real-time machine interdependencies, resource pooling variances and material transit times across physical transport lanes.
• Interpretation: When an anomaly occurs, the local agent instantly evaluates the disruption against localized business constraints.
• Negotiation: Rather than escalating every minor bottleneck to a human director, Plant A’s scheduling agent connects directly to Plant B’s agent over the secure network. The agents cross-negotiate load-balancing options, evaluate transportation lead times and run localized optimization calculations in parallel.

Instead of forcing supply chain teams to manually bridge data gaps during a crisis, the system bypasses legacy functional silos. It presents the COO’s operations team with a pre-validated, end-to-end scheduling solution.

Real-world applications: Grounding autonomy in industrial reality

To understand how this functions in the real world, we must look beyond theoretical multi-agent frameworks and examine how this architecture operates within live factories. The following two case studies—drawn from highly documented, peer-reviewed industrial implementations — demonstrate how multi-agent generative systems (MAGS) actively protect margins and timelines when unexpected disruptions strike.

Case study 1: The discrete architecture (The Festo cyber-physical agent framework)

• The context: This architecture is modeled after the landmark decentralized orchestration frameworks deployed at Festo’s Scharnhausen Technology Plant. Instead of relying on a centralized ERP/MES brain to dictate every move, the facility utilizes cyber-physical systems (CPS) where the physical components and machines operate as an interconnected multi-agent system (MAS).
• The disruption: During a high-volume discrete run of automation components, a critical machining center suffering an unexpected tooling failure, in a traditional centralized setup, would have triggered a cascade of line stoppages.
• The intervention: The affected machine’s resource agent instantly broadcasts its downtime status across the network. The task agents ingest the anomaly and independently query neighboring machining cells. The setup utilizes an underlying ACO routing routine to calculate the most efficient physical path through alternative, under-utilized cells. The Task Agents actively barter for open capacity with these alternative resource agents, dynamically adjusting their own operational sequences.

Case study 2: The process pivot (The TU Dresden battery manufacturing framework)

• The context: This case is drawn directly from a multi-layer agent-based framework engineered for a European lead-acid battery manufacturer in coordination with researchers at TU Dresden. The environment features 31 highly energy-intensive heat-treatment and curing chambers, where localized utility tariff volatility drastically impacts production margins. Continuous chemical process lines cannot simply be shut down without massive material waste and lengthy restart sequences.
• The disruption: A sudden, localized weather event triggers an unpredicted spike in peak-load electricity pricing, threatening to entirely erase the profit margin on a high-volume production run.
• The intervention: To solve this, the plant utilized a multi-layer agent-based framework. An energy-monitoring agent tracking live utility tariff feeds communicated the financial threat directly to the production scheduling agent. Instead of a crude emergency halt, the reasoning layer queried the facility’s computerized maintenance management system (CMMS). The agentic layer identified a mandatory 4-hour preventative maintenance window scheduled for three days later. The agent made an executive operational decision: it pulled that maintenance window forward to occur during the exact hours of peak utility pricing, converting an expensive tariff penalty into required downtime. Simultaneously, lower-level agents representing the individual curing chambers and material pallets recalculated local constraints, instructing the optimization engine to compress and accelerate subsequent production batches during the cheaper, off-peak night shifts.

The business outcome

In both cases, the agents optimized an operational pivot, and optimally utilised production capacity in the former and saved precious cash in the latter.

Governance, trust and the “human-in-the-loop” guardrails

All that seems great and seems like science fiction; it inevitably raises a critical, polarizing question for the C-suite: If the algorithms are making multi-thousand-dollar operational choices in real time, how do we maintain control?

The solution to this executive anxiety is a framework defined as “autonomy within boundaries,” executed through policy-as-code. Under this model, operational leaders stop managing the volatility of daily schedules. Instead, they focus on creating and managing policy boundaries within which the agents are permitted to negotiate and self-heal.

This splits operational exceptions into 2 zones:

• Autonomous execution zone: The multi-agent system has full authority to re-sequence lines, re-route components or shift maintenance windows autonomously, provided the financial & operational impact is under a predefined limit.  
• Expert advisory zone: The moment a proposed optimization breaches either of these metrics, the agent pushes it to an executive dashboard for immediate human intervention, validation and approval.

This dual-layer approach introduces a reliable operational framework to industrial manufacturing: leadership manages strategic intent, while tactical units manage real-time execution.

By establishing clear thresholds, the fear of an algorithmic “runaway train” is entirely mitigated. However, deploying a complete multi-agent governance framework across an entire enterprise footprint cannot happen overnight.

To move this from my serendipitous but compelling discovery to a live, risk-mitigated environment, I need a highly controlled, phased deployment strategy, an actionable roadmap to pilot, test and scale the reasoning layer without disrupting current production baselines.

We often say Industry 4.0 connected machines. I believe Industry 5.0 will connect decisions. The factories that succeed will not simply automate workflows; they will build systems capable of reasoning within clearly defined operational boundaries.

I am therefore not writing a conclusion here. I would probably be back in a few months writing about the outcome of this exercise. Somehow deep-down I suspect it would be less oriented to technology but how the change management progressed. I have a strong feeling that “…operational leaders stop managing the volatility of daily schedules. Instead, they focus on creating and managing policy boundaries …” would be the toughest part of this change.   

The race to adopt AI has left many CIOs wrestling with a fundamental question: How do you move faster without introducing unacceptable risk?

Few leaders face that challenge at a higher level than David Burns, CIO of GE Aerospace. Building on the company’s decade of experience applying AI across its business, Burns is helping lead the next phase of the company’s digital transformation by leveraging AI to simplify and automate processes. Burns’ experience shows how AI can accelerate innovation, improve decision-making, and create value for the business and customers while maintaining the trust, safety, and operational rigor expected in the aerospace industry.

In a recent episode of the Tech Whisperers podcast, Burns opened up his playbook for leading organizations through turbulence. In this conversation, edited for length and clarity, he shares more practical lessons for technology leaders who are seeking to move beyond experimentation and scale AI responsibly across the enterprise.

Dan Roberts: You’ve described AI as an accelerator. What exactly is AI accelerating inside GE Aerospace?

David Burns: At GE Aerospace, AI is used across our operations as an accelerator to Flight Deck, our proprietary lean operating model, and is applied to all key aspects of the business — design, manufacture, sales, and services. We identify and solve problems with Flight Deck and use AI to accelerate our problem-solving in ways we can genuinely feel, enabling us to identify issues earlier, solve problems faster for our customers, and improve how work gets done.

For example, we are also using AI in:

Design: While traditional processes for developing engine design concepts take months of manual work, the GE Aerospace Research Center built a proprietary generative AI application capable of producing hundreds of design concepts. As a result, the team produced the hypersonic ramjet engine design concept that met all regulatory requirements more than 90% faster than before, highlighting how AI is possible in engine design to support engineers bringing new technologies to market faster.

Manufacture: Our team in Indianapolis used an AI coding assistant to automate a part quality inspection workflow, reducing 8 hours of manual measurement data entry for complex parts to just 3 seconds while improving data accuracy and inspection consistency. This has improved both the quality and efficiency for clearing parts to build, which helps drive on-time engine deliveries.

Sales: Based on customer feedback that GE Aerospace’s responses for proposals needed to be faster, the sales team utilized a generative AI tool to synthesize data and produce deal proposals. The tool improved customer response time by more than two weeks for the GEnx team through reduced proposal development cycle time and standardized creation of more comprehensive deal proposals.

Service: When LEAP engine rebuilds faced potential turnaround time (TAT) challenges due to material availability at our Maintenance, Repair and Overhaul (MRO) sites, our team in Lafayette, Indiana, applied AI to help reduce delays for customers. Using Daily & Visual Management, they surfaced material flow challenges and their underlying drivers, leading to a new AI solution that leverages data to predict when and where parts are needed faster to reduce delays for our customers with an approximately six-day turnaround time improvement, 16% increase in on-time material orders, and 15% increase in on-time material delivery.

Ultimately, by leveraging AI, Flight Deck helps us eliminate waste and identify and accelerate the most value-added steps for our customers, be it designing a part faster or responding to a customer request faster. And I would underscore that it’s value through the eyes of our customer. How we define value is not what we internally say; it’s how our customers define value, and how we’re working to be more customer-driven.

GE Aerospace has been investing in analytics, machine learning, and digital capabilities for more than a decade. What advantages does that foundation create as you move into the generative AI era?

We’ve built one of the largest AI patent portfolios in the aviation industry through years of investment and supercomputing through digital technologies, and we continue to do work on our core transactional systems and our data foundations, so that way our data is AI-ready. This has allowed us to build our own AI capabilities and strong talent base. For example, the generative AI app we built to create new propulsion systems design was built in house by GE Aerospace scientists at the GE Aerospace Research Center.

At the same time, our knowledge and familiarity with the landscape has allowed us to make connections with tech companies, including one where we’re using agentic AI in a multi-year partnership to predict demand and identify constraints to enhance production readiness in the Defense business.

We were fortunate to have leaders who were very smart to invest in data scientists 10, 15 years ago, and we’re getting to leverage that talent today. The lesson there is that is you always have to be thinking long term when you’re talking about talent, because you may not know exactly how the world will play out, but making sure you have the best athletes on the field to run the race becomes critically important. For us, some of those investments we did around our people is what’s paying off today.

One of the biggest challenges facing CIOs today is balancing innovation with risk management. How do you approach that balance in an industry where safety, reliability, and trust are non-negotiable?

It’s all about risk tolerance. There are certain areas in our business where we don’t have high risk tolerance, and we’re very methodical and cautious about how we deploy technology into those uses and have very stringent processes that we comply consistently with. In areas that are not safety and quality critical, we are more aggressive in looking at how we can use technology to deliver more for our customers and to make our employees more effective. That’s where we strike the balance, and at the end of the day, it’s about making sure we’re never compromising safety or quality in what we do.

As for the process, we start with Flight Deck and focus AI where it can help solve critical challenges for our customers and with the highest impact to customer outcomes, enhancing safety, quality, delivery, and cost, in that order, to solve problems that matter most and keep fleets flying. ​

We have three guiding principles for safe and responsible AI use: 

• Trust: The data-informing AI must be known, trusted, and reliable. 
• Transparent: The AI must be transparent and repeatable, which means we need to know what is informing an AI model’s insights and actions.
• Human: A human must always be in the loop and make the final decision.    

Our culture of discipline also plays an important role. Our business variation is challenging, so one of the core fundamentals of Flight Deck is standard work. It’s embedded into our culture, and it’s the base expectation that we operate with standards that we’re continuously improving.

Many organizations are struggling to move from AI pilots to enterprise-scale value. What lessons have you learned about successfully scaling AI across a large, complex organization?

AI is a tool that strengthens the capabilities of skilled employees; it is not a substitute for their judgment, experience, or accountability. So we focus on testing and validating AI solutions through pilots before scaling, and look for AI applications that meaningfully change how work gets done.

Early on, when we started doing a lot of our generative AI work, we focused on 14 big problems in the business, and we didn’t let ourselves stray all over the place. We also didn’t look at it as a technology solution. We looked at the process and where technology played into the process, and then we embedded AI into those core processes. So now, it’s not a separate thing where you go do AI. It’s embedded in the workflow of how things get done.

That gave us a foundation to learn and grow from that we’ve now applied. We’re not trying to create popcorn AI solutions all over the place. We’re trying to transform our business processes. In some cases, we’re doing good old process improvement, lean process improvement, eliminating waste, not necessarily a technology play. In other places, we’re applying technology that’s helping to lift us up and accelerate value by embedding it into the way work gets done, with a little bit of burning the boats behind you. You’re not able to do it the old way. You’ve got to use the tools. You’ve got to use the technology, because it’s the best-known way of doing it. The technology becomes part of the standard work.

That’s why one of the biggest lessons in scaling AI is that success starts with the core fundamentals and understanding the problem you’re trying to solve. It’s critical to test and validate AI solutions before they are deployed at scale to ensure they improve how work gets done and become embedded in our workflows. If you do not have strong standard work and transparent and reliable data in place, it becomes difficult to move beyond pilot stage and create repeatable value at scale.

Every day brings a new AI announcement, new model, or new prediction about the future. How do you separate what is truly meaningful from what is simply noise, and what advice would you give other leaders trying to do the same?

First and foremost is starting with the problem being solved, not the solution. If you’ve got a hammer that you want to use, everything starts looking like a nail. The most effective use of AI begins with an understanding of the problem that needs to be solved, then determining whether AI is the right tool to address it.

As far as dealing with distractions, and there are a lot of them right now, it’s important to try a lot of things, but very quickly, and then make decisions on which are the bets you want to make and spend more time and more money on and which are the ones you want to pivot away from. We spend a lot of time doing quick experiments with technology and then having the courage to stop something when it’s not working.

What excites you most about the future intersection of AI, engineering, manufacturing, and aerospace? And what should CIOs be doing today to prepare for that future?

Across aviation, AI is already helping to enhance safety, support more efficient operations, strengthen the resilience of global fleets, and improve the overall passenger experience. That includes GE Aerospace. These benefits come from investing not only in technology, but also in people, capacity, and trusted partnerships. 

They also depend on building mature, fully connected data threads through manufacturing and services that will drive higher value across our operations. The challenge will be ensuring that we enable this data thread across our operations to support AI solutions that will be developed and deployed.

The most important thing is to understand that the role of digital technology and information technology is fundamentally going to change. When I came out of university, the only people that knew how to do software coding were computer scientists or information systems majors. We used to frown upon shadow IT, but the reality is, now everyone coming out of college knows how to do some level of software development, and AI tools are only going to make that easier.

What CIOs need to start doing today is prepare for the future. The big questions they need to answer: How are they going to make sure they’ve got the platforms and the data set up in a way to serve a workforce that is capable of doing true citizen development, able to develop their own applications, their own solutions? How do you govern that from a data perspective, from a data privacy perspective, from a cybersecurity perspective, while not stifling but enabling the innovation of all those smart people that we’re hiring?

While many organizations search for shortcuts to AI success, GE Aerospace’s disciplined investment in data, analytics, talent, and operational excellence sets the company apart. Burns’ experience offers a clear lesson for CIOs: Creating the greatest value from AI requires building the capabilities, culture, and foundations that allow AI to amplify what the organization already does exceptionally well. For more from his leadership playbook, tune in to the Tech Whisperers.

The mainframe remains the system of record for many of the world’s largest organizations and some of their most critical data. As of 2025, 71% of Fortune 500 companies still use mainframes, and nearly 97% of banks worldwide rely on IBM mainframe products.

Yet many security programs continue to treat the mainframe differently from the rest of the enterprise. Many organizations still assume the mainframe is inherently secure.

Mainframes are designed with strong security controls. But strong controls alone are not enough. Like any critical enterprise system, the mainframe requires continuous verification to ensure those controls are working as intended.

Risk can exist anywhere. An overlooked configuration in a z/OS environment can create opportunities for unauthorized access to sensitive systems and data. As the time between vulnerability discovery and exploitation continues to shrink, organizations need greater visibility into risk across the enterprise—including the mainframe.

Myth #1: Mainframes are unbreachable 

Can mainframes be breached? Although mainframes are designed with robust security features, no technology platform is immune to risk. The reality is simple: attackers go where the valuable data is stored.

The mainframe isn’t isolated from the rest of the enterprise. Mainframes routinely process millions of transactions per day, and high-end systems can process over a million transactions per second in certain workloads. Mainframes are estimated to handle a substantial share of the world’s transactional workloads and credit card processing.

As organizations modernize and connect systems across environments, visibility into potential exposure becomes just as important on z/OS as it is everywhere else. Attackers follow opportunity. Wherever valuable data and business-critical assets reside, flaws will attract attention. As organizations adopt hybrid architectures, the number of interconnected systems continues to grow, making identity governance and access assurance increasingly important.

The solution is to treat the mainframe as part of the enterprise attack surface and manage risk there the same way you do everywhere else. Mainframe security requires the same continuous visibility organizations expect across the rest of the enterprise.

Myth #2: Specialized systems are too complex for attackers

How is AI changing vulnerability discovery? In the past, surfacing exposures on the mainframe required deep expertise that relatively few people had. That complexity made these environments harder to analyze.

Recent attention around Mythos, Anthropic’s highly restricted security research model, has sparked debate about AI’s role in cybersecurity. If security flaws become dramatically easier to find, organizations may have less time to identify and remediate weaknesses before others discover them.

The important point isn’t Mythos itself. It’s that identifying exploitable weaknesses is becoming faster, cheaper, and easier.

Organizations can no longer assume that complexity will keep attackers at bay. Mainframe security strategies should account for a future in which gaps are discovered faster than ever before.

That requires greater visibility into the z/OS environment and the risks it may pose. Continuous analysis helps organizations uncover potential weaknesses early, and the sooner security teams can detect security gaps, the more time they have to fix them.

Myth #3: Annual security assessments are sufficient

Why is continuous vulnerability analysis important for mainframe security? Many organizations still rely on periodic configuration assessments, even though today’s threats move much faster than they did when those processes were created. Today’s mainframe environments are constantly evolving, and new weaknesses can emerge between checkpoints long before the next scheduled assessment.

Security teams need ongoing visibility into risk, not occasional snapshots. That’s why continuous vulnerability analysis has become a critical component of modern mainframe management, helping teams identify and remediate weaknesses before they escalate into incidents.

Organizations have long benefited from the security architecture and integrity of mainframe environments. As vulnerability discovery becomes more efficient, maintaining visibility into those environments becomes increasingly important. Rocket Mainframe Security solutions help organizations build continuous visibility across their z/OS environments and act on it early.

For organizations seeking greater visibility across their z/OS environment, Rocket z/Assure Vulnerability Analysis Program (VAP) helps identify weaknesses within authorized programs and supports ongoing remediation efforts. VAP helps security teams identify security gaps in software earlier, reducing risk before they affect critical systems.

What continuous mainframe security requires

• Visibility into sensitivities across the z/OS environment
• Ongoing validation of security controls
• Integration with enterprise risk management processes
• Faster identification and remediation of emerging weaknesses
• Continuous assessment rather than periodic review

The future of mainframe security requires continuous vulnerability analysis

Security weaknesses can exist anywhere in the enterprise, and they are being discovered faster than ever before. Detecting risk is getting easier, and organizations should plan accordingly.

This is where continuous vulnerability analysis becomes essential. Point-in-time assessments provide a snapshot of risk, while continuous risk analysis helps organizations maintain visibility as systems change.

The broader lesson from advanced AI models like Mythos is that vulnerability discovery is accelerating. For organizations that depend on the mainframe, visibility becomes more important as the time between discovery and exploitation shrinks. Organizations that adopt continuous analysis across critical environments will be better positioned to identify and address risk before attackers do.

Learn more here.

The mainframe remains the system of record for many of the world’s largest organizations and some of their most critical data. As of 2025, 71% of Fortune 500 companies still use mainframes, and nearly 97% of banks worldwide rely on IBM mainframe products.

Yet many security programs continue to treat the mainframe differently from the rest of the enterprise. Many organizations still assume the mainframe is inherently secure.

Mainframes are designed with strong security controls. But strong controls alone are not enough. Like any critical enterprise system, the mainframe requires continuous verification to ensure those controls are working as intended.

Risk can exist anywhere. An overlooked configuration in a z/OS environment can create opportunities for unauthorized access to sensitive systems and data. As the time between vulnerability discovery and exploitation continues to shrink, organizations need greater visibility into risk across the enterprise—including the mainframe.

Myth #1: Mainframes are unbreachable 

Can mainframes be breached? Although mainframes are designed with robust security features, no technology platform is immune to risk. The reality is simple: attackers go where the valuable data is stored.

The mainframe isn’t isolated from the rest of the enterprise. Mainframes routinely process millions of transactions per day, and high-end systems can process over a million transactions per second in certain workloads. Mainframes are estimated to handle a substantial share of the world’s transactional workloads and credit card processing.

As organizations modernize and connect systems across environments, visibility into potential exposure becomes just as important on z/OS as it is everywhere else. Attackers follow opportunity. Wherever valuable data and business-critical assets reside, flaws will attract attention. As organizations adopt hybrid architectures, the number of interconnected systems continues to grow, making identity governance and access assurance increasingly important.

The solution is to treat the mainframe as part of the enterprise attack surface and manage risk there the same way you do everywhere else. Mainframe security requires the same continuous visibility organizations expect across the rest of the enterprise.

Myth #2: Specialized systems are too complex for attackers

How is AI changing vulnerability discovery? In the past, surfacing exposures on the mainframe required deep expertise that relatively few people had. That complexity made these environments harder to analyze.

Recent attention around Mythos, Anthropic’s highly restricted security research model, has sparked debate about AI’s role in cybersecurity. If security flaws become dramatically easier to find, organizations may have less time to identify and remediate weaknesses before others discover them.

The important point isn’t Mythos itself. It’s that identifying exploitable weaknesses is becoming faster, cheaper, and easier.

Organizations can no longer assume that complexity will keep attackers at bay. Mainframe security strategies should account for a future in which gaps are discovered faster than ever before.

That requires greater visibility into the z/OS environment and the risks it may pose. Continuous analysis helps organizations uncover potential weaknesses early, and the sooner security teams can detect security gaps, the more time they have to fix them.

Myth #3: Annual security assessments are sufficient

Why is continuous vulnerability analysis important for mainframe security? Many organizations still rely on periodic configuration assessments, even though today’s threats move much faster than they did when those processes were created. Today’s mainframe environments are constantly evolving, and new weaknesses can emerge between checkpoints long before the next scheduled assessment.

Security teams need ongoing visibility into risk, not occasional snapshots. That’s why continuous vulnerability analysis has become a critical component of modern mainframe management, helping teams identify and remediate weaknesses before they escalate into incidents.

Organizations have long benefited from the security architecture and integrity of mainframe environments. As vulnerability discovery becomes more efficient, maintaining visibility into those environments becomes increasingly important. Rocket Mainframe Security solutions help organizations build continuous visibility across their z/OS environments and act on it early.

For organizations seeking greater visibility across their z/OS environment, Rocket z/Assure Vulnerability Analysis Program (VAP) helps identify weaknesses within authorized programs and supports ongoing remediation efforts. VAP helps security teams identify security gaps in software earlier, reducing risk before they affect critical systems.

What continuous mainframe security requires

• Visibility into sensitivities across the z/OS environment
• Ongoing validation of security controls
• Integration with enterprise risk management processes
• Faster identification and remediation of emerging weaknesses
• Continuous assessment rather than periodic review

The future of mainframe security requires continuous vulnerability analysis

Security weaknesses can exist anywhere in the enterprise, and they are being discovered faster than ever before. Detecting risk is getting easier, and organizations should plan accordingly.

This is where continuous vulnerability analysis becomes essential. Point-in-time assessments provide a snapshot of risk, while continuous risk analysis helps organizations maintain visibility as systems change.

The broader lesson from advanced AI models like Mythos is that vulnerability discovery is accelerating. For organizations that depend on the mainframe, visibility becomes more important as the time between discovery and exploitation shrinks. Organizations that adopt continuous analysis across critical environments will be better positioned to identify and address risk before attackers do.

Learn more here.