I have worked alongside enterprise technology for more than 30 years and watched AI evolve from a lab experiment into the modern boardroom’s core focus. However, the last few years of implementing AI alongside our customers have delivered our most profound reality checks.

The initial hype has faded, leaving CIOs to drive real enterprise value. Based on my experience implementing Google, OpenAI and Anthropic technologies, here are the fundamental, technology-agnostic lessons every leader must anchor their strategy around.

AI as a leadership multiplier

The most common tactical error we see is treating AI as an isolated technology project. What I have observed among our customers is that true success does not come from organizations that define a standalone “AI strategy,” but rather from those leaders that integrate AI into their business strategy.

When our customers isolate AI and define an AI strategy, it inevitably treats it like a “technological toy” to experiment with. This approach yields fragmented, orphaned initiatives that fail to scale because they are fundamentally disconnected from their core corporate objectives. What I learned is that AI is not the ultimate destination; it is a powerful catalyst. We have replaced “What can AI do for our customers?” with a more strategic question, “How does AI accelerate their existing business goals?”

Think of AI like electricity. No modern corporation designs a standalone “electricity strategy.” Instead, all companies route it invisibly across the entire organization to illuminate offices, power production lines and drive communication. AI must be woven into the enterprise fabric in the exact same way, acting as an underlying utility that supercharges your existing operational model.

Integrating AI into the broader business strategy also dictates how we measure success. It forces a shift away from short-term tech vanity metrics and anchors the technology into a long-term roadmap.

When AI remains trapped within the IT department of our customers, we notice that it is relegated to a mere “software experiment.” To become a true competitive advantage, we observed that AI requires intense cross-functional orchestration. This perspective does not diminish the merit of the technical team; their expertise is fundamental for establishing the architecture, data governance and tools your enterprise requires. However, while IT builds the foundational infrastructure, it lacks the organizational authority to decide what should be built on top of it. Only the CEO or the owner of the company can step in to ensure AI leaves the “toy project” phase and integrates into the DNA of the organization.

The requirement for top-down, executive ownership stems from three critical realities observed in the field:

• Silo-smashing and data collaboration: True enterprise AI is data-hungry and that data lives across disparate business lines, finance, operations, marketing and customer service. Only the CEO possesses the cross-functional authority to demand that data silos be dismantled.
• Cultural transformation and fear mitigation: AI triggers widespread anxiety over job displacement across all industries and hierarchies. When relegated to an “IT project,” resistance spikes as teams view it as a threat to their livelihoods. When I saw the CEO lead this cultural shift directly is when I noticed the best results.
• C-Suite education and strategic alignment: The mandate for AI capability cannot just be delegated downward; the transformation must begin at the very top. I have conducted more than 70 presentations for the Board of Directors and C-Level teams. These people need to be actively educated not on technical code, but on specific business use cases, return on investment (ROI) frameworks and how AI resolves core organizational bottlenecks.

PwC’s data found that only 12% of enterprises have achieved both cost and revenue benefits from AI. Those elite 12% succeeded precisely because their CEOs embedded AI extensively across strategic decision-making and cross-functional workflows. AI is simply too disruptive and too critical to be left exclusively in the hands of technical experts. If AI is not on the CEO’s weekly agenda, it is fundamentally missing from the company’s true strategy.

AI as a new operational framework

Traditional IT systems have operated on strict algorithmic certainty: if you input a specific set of data, the system executes an immutable line of code and guarantees the same, predictable output every single time.

AI completely breaks this paradigm. Because modern AI is built on probabilistic models, it does not execute static formulas; instead, it predicts the most likely correct response based on mathematical probabilities. This means that AI solutions carry an inherent, small percentage of uncertainty and variability. A prompt entered today might yield a slightly different, though contextually valid, output tomorrow.

Executive leadership and organizational cultures must be actively educated to accept and navigate this fundamental shift. Traditional quality assurance frameworks for software are designed for a 100% success rate. Applying this rigid standard to AI will paralyze your initiatives, keeping 80% of your projects trapped eternally in the pilot phase. This happened to us in a food and beverage company in Latin America a couple of years ago. After this experience, we started to include conditions in our contracts that tolerate statistical margins of error and still define the project as a success.

In terms of cost calculation, we had to teach CIOs and business managers to forget the monthly subscription model for AI and learn to manage the primary unit of exchange in modern AI: the token.

To understand AI costs, executives must understand how large language models process data. AI models do not read full words; instead, they break text, images or code down into “pieces” called tokens. As a baseline, every 100 words process as approximately 130 to 140 tokens. Because the major AI providers use the token as their currency, your business is billed dynamically based on the exact volume of tokens consumed by every query submitted (input) and every response generated (output).

Many leaders believe AI costs are fixed due to flat-rate enterprise tiers ($25–$30/user). This is a temporary illusion. These venture-capital-subsidized rates mask true operational costs and come with dynamic usage limits. Modeling long-term ROI on them guarantees a severe budget shock when true consumption pricing takes over.

The solution is not to halt AI adoption; doing so means losing your competitive edge. Instead, the cost per token must cease to be treated as a technical footnote relegated to the IT department. It must be elevated to a core business variable.

Risks in the AI adoption model

Since the beginning of the AI boom, I have seen all our customers making a critical tactical error that could cost them heavily in the medium term: they are focusing only on operational efficiency (reducing costs with AI).

I have observed that an alarmingly high percentage of companies remain trapped in pilot phases focused exclusively on short-term cost reduction. Bain & Company’s global Automation and AI Pathfinder Survey found that the largest share of companies measuring their AI initiatives (exactly 40%) realized cost reductions of 10% or less, heavily missing their internal targets. Our customers are putting too many resources and effort into marginal financial gains and in doing so, they are jeopardizing their most valuable assets: service quality, resilience and customer trust.

Utilizing AI solely to slash headcount or cut operational corners is a dangerous trap that introduces severe field liabilities. A financial service organization in Latin America announced that they saved $1 million in customer support by replacing humans with AI chatbots. However, the mid-term reality revealed a different story: a damaged brand reputation due to AI errors and an influx of frustrated clients fleeing because the automated system cannot handle special cases.

Putting a company on an extreme AI diet might make it look leaner on next quarter’s financial statement, but over-indexing on cost-cutting will ultimately leave the business too weak to compete when market dynamics shift. We are now inviting our customers to change the question from “How much money will AI save us?” to “How will we leverage AI to exponentially increase the long-term value of our enterprise?”

Deploying enterprise AI is a marathon, not a sprint, and the terrain changes with every mile. The organizations that thrive in this next era will be those that transition from fascination to discipline, treating AI not as a magic bullet for immediate savings, but as a core capability that demands rigorous governance, architectural foresight and cultural maturity. Navigating this shift requires moving past the theoretical hype and anchoring decisions in raw, field-tested reality.

As we continue to deploy these technologies across industries, the blueprint for success is being rewritten in real time. Let’s keep this conversation going as we map out the future of business intelligence together.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

I have worked alongside enterprise technology for more than 30 years and watched AI evolve from a lab experiment into the modern boardroom’s core focus. However, the last few years of implementing AI alongside our customers have delivered our most profound reality checks.

The initial hype has faded, leaving CIOs to drive real enterprise value. Based on my experience implementing Google, OpenAI and Anthropic technologies, here are the fundamental, technology-agnostic lessons every leader must anchor their strategy around.

AI as a leadership multiplier

The most common tactical error we see is treating AI as an isolated technology project. What I have observed among our customers is that true success does not come from organizations that define a standalone “AI strategy,” but rather from those leaders that integrate AI into their business strategy.

When our customers isolate AI and define an AI strategy, it inevitably treats it like a “technological toy” to experiment with. This approach yields fragmented, orphaned initiatives that fail to scale because they are fundamentally disconnected from their core corporate objectives. What I learned is that AI is not the ultimate destination; it is a powerful catalyst. We have replaced “What can AI do for our customers?” with a more strategic question, “How does AI accelerate their existing business goals?”

Think of AI like electricity. No modern corporation designs a standalone “electricity strategy.” Instead, all companies route it invisibly across the entire organization to illuminate offices, power production lines and drive communication. AI must be woven into the enterprise fabric in the exact same way, acting as an underlying utility that supercharges your existing operational model.

Integrating AI into the broader business strategy also dictates how we measure success. It forces a shift away from short-term tech vanity metrics and anchors the technology into a long-term roadmap.

When AI remains trapped within the IT department of our customers, we notice that it is relegated to a mere “software experiment.” To become a true competitive advantage, we observed that AI requires intense cross-functional orchestration. This perspective does not diminish the merit of the technical team; their expertise is fundamental for establishing the architecture, data governance and tools your enterprise requires. However, while IT builds the foundational infrastructure, it lacks the organizational authority to decide what should be built on top of it. Only the CEO or the owner of the company can step in to ensure AI leaves the “toy project” phase and integrates into the DNA of the organization.

The requirement for top-down, executive ownership stems from three critical realities observed in the field:

• Silo-smashing and data collaboration: True enterprise AI is data-hungry and that data lives across disparate business lines, finance, operations, marketing and customer service. Only the CEO possesses the cross-functional authority to demand that data silos be dismantled.
• Cultural transformation and fear mitigation: AI triggers widespread anxiety over job displacement across all industries and hierarchies. When relegated to an “IT project,” resistance spikes as teams view it as a threat to their livelihoods. When I saw the CEO lead this cultural shift directly is when I noticed the best results.
• C-Suite education and strategic alignment: The mandate for AI capability cannot just be delegated downward; the transformation must begin at the very top. I have conducted more than 70 presentations for the Board of Directors and C-Level teams. These people need to be actively educated not on technical code, but on specific business use cases, return on investment (ROI) frameworks and how AI resolves core organizational bottlenecks.

PwC’s data found that only 12% of enterprises have achieved both cost and revenue benefits from AI. Those elite 12% succeeded precisely because their CEOs embedded AI extensively across strategic decision-making and cross-functional workflows. AI is simply too disruptive and too critical to be left exclusively in the hands of technical experts. If AI is not on the CEO’s weekly agenda, it is fundamentally missing from the company’s true strategy.

AI as a new operational framework

Traditional IT systems have operated on strict algorithmic certainty: if you input a specific set of data, the system executes an immutable line of code and guarantees the same, predictable output every single time.

AI completely breaks this paradigm. Because modern AI is built on probabilistic models, it does not execute static formulas; instead, it predicts the most likely correct response based on mathematical probabilities. This means that AI solutions carry an inherent, small percentage of uncertainty and variability. A prompt entered today might yield a slightly different, though contextually valid, output tomorrow.

Executive leadership and organizational cultures must be actively educated to accept and navigate this fundamental shift. Traditional quality assurance frameworks for software are designed for a 100% success rate. Applying this rigid standard to AI will paralyze your initiatives, keeping 80% of your projects trapped eternally in the pilot phase. This happened to us in a food and beverage company in Latin America a couple of years ago. After this experience, we started to include conditions in our contracts that tolerate statistical margins of error and still define the project as a success.

In terms of cost calculation, we had to teach CIOs and business managers to forget the monthly subscription model for AI and learn to manage the primary unit of exchange in modern AI: the token.

To understand AI costs, executives must understand how large language models process data. AI models do not read full words; instead, they break text, images or code down into “pieces” called tokens. As a baseline, every 100 words process as approximately 130 to 140 tokens. Because the major AI providers use the token as their currency, your business is billed dynamically based on the exact volume of tokens consumed by every query submitted (input) and every response generated (output).

Many leaders believe AI costs are fixed due to flat-rate enterprise tiers ($25–$30/user). This is a temporary illusion. These venture-capital-subsidized rates mask true operational costs and come with dynamic usage limits. Modeling long-term ROI on them guarantees a severe budget shock when true consumption pricing takes over.

The solution is not to halt AI adoption; doing so means losing your competitive edge. Instead, the cost per token must cease to be treated as a technical footnote relegated to the IT department. It must be elevated to a core business variable.

Risks in the AI adoption model

Since the beginning of the AI boom, I have seen all our customers making a critical tactical error that could cost them heavily in the medium term: they are focusing only on operational efficiency (reducing costs with AI).

I have observed that an alarmingly high percentage of companies remain trapped in pilot phases focused exclusively on short-term cost reduction. Bain & Company’s global Automation and AI Pathfinder Survey found that the largest share of companies measuring their AI initiatives (exactly 40%) realized cost reductions of 10% or less, heavily missing their internal targets. Our customers are putting too many resources and effort into marginal financial gains and in doing so, they are jeopardizing their most valuable assets: service quality, resilience and customer trust.

Utilizing AI solely to slash headcount or cut operational corners is a dangerous trap that introduces severe field liabilities. A financial service organization in Latin America announced that they saved $1 million in customer support by replacing humans with AI chatbots. However, the mid-term reality revealed a different story: a damaged brand reputation due to AI errors and an influx of frustrated clients fleeing because the automated system cannot handle special cases.

Putting a company on an extreme AI diet might make it look leaner on next quarter’s financial statement, but over-indexing on cost-cutting will ultimately leave the business too weak to compete when market dynamics shift. We are now inviting our customers to change the question from “How much money will AI save us?” to “How will we leverage AI to exponentially increase the long-term value of our enterprise?”

Deploying enterprise AI is a marathon, not a sprint, and the terrain changes with every mile. The organizations that thrive in this next era will be those that transition from fascination to discipline, treating AI not as a magic bullet for immediate savings, but as a core capability that demands rigorous governance, architectural foresight and cultural maturity. Navigating this shift requires moving past the theoretical hype and anchoring decisions in raw, field-tested reality.

As we continue to deploy these technologies across industries, the blueprint for success is being rewritten in real time. Let’s keep this conversation going as we map out the future of business intelligence together.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Major AI labs are unleashing forward-deployed engineers (FDEs) to try and grab enterprise customers. Large consultancies are dishing out tokens and assembling armies of consultants — both human and agent — to do the same.

But smaller firms are in the mix now, as well. AI is helping 28Stone Consulting, a New York-based, 230-person technology consultancy for capital markets, punch above its weight against larger rivals in the rush to deliver FDEs.

In this Q&A, Thomas Dolan and Frank Erickson, founders of 28Stone, argue that agentic AI isn’t a one-size-fits-all solution in vertical markets; success takes discipline, deep domain expertise, and human involvement to mitigate risk.

Many enterprises continue to struggle with the use of AI agents, which is consultancies are stepping in to get projects off the ground. 28Stone is among those that have published blueprints and methodologies on the development and delivery of agentic AI workflows with humans in the loop.

Computerworld spoke with both founding partners about why companies are still stumbling with agentic AI rollouts, and what a disciplined delivery process actually looks like.

After 15 years of delivering software for capital markets firms, is ‘AI-first’ a real distinction or just positioning?

Dolan: “We’re not shying away from being AI-forward. What needs to shine through is AI done intelligently — not stuff you get by buying some tokens for somebody on the trading desk. We’re an AI-first firm.”

Erickson: “And it’s temporary. At some point, AI is going to be synonymous with software development.

“The whole idea of an AI SDLC (software development lifecycle) versus an SDLC is going to be one and the same, a lot like cloud computing today. To not include AI in your strategy, you’d look like a COBOL vendor.”

What does agentic AI delivery look like?

Dolan: “We’ve got several AI initiatives delivering a pure agentic approach. We’ve doubled down on the human expertise wrapper in the SDLC. That doesn’t mean sacrificing any of the benefits of the AI models — quite the opposite.

“You don’t achieve anywhere near the same level of value from applying AI without keeping that expertise — industry, functional and technical — throughout the process.”

Where do humans stay in the loop once agents are doing the work?

Dolan: “We’re believers in starting with requirements discovery. Someone who knows the analytical nuances of a good business analyst is critically important; shaping a product owner’s business information through a markup file that can be fed into a BA agent, then treating the output as if it came from a very fast junior BA. Only then is the story complete.

“The developer takes that story, transforms it into the most efficient input, then owns the output, because they’re accountable for that code. A developer should own the code on both the input and output side.

“Your product owner, who knows the business, that’s great. But expecting them to interact with an agent and output enterprise code is ridiculous. It’s not a great plan.“

Why not just put one do-everything person in charge of AI and agents?

Erickson: “Every analyst, programmer or software engineer isn’t a great requirements analyst. And a great domain analyst with some technical background won’t know if the agent’s code is garbage, maintainable, performant.

“It’s unrealistic to expect one individual to have that breadth across domain, software engineering, testing, deployment. Clients ask all the time, and we push back: ‘Great, if you can find that guy, they’re few and far between.’ To deliver at the enterprise level, you need the human expertise, at depth.“

Dolan: “There’s system speed and latency, important in parts of finance. Then there’s speed of delivery, because other areas evolve quickly and time-to-market is critical.

“Our human wrapper may at first pass come across as a little slowed down. Maybe it is. But [Erickson] has a good analogy about one of the dangers of AI: you can end up going really fast in the wrong direction. By the time you look up, you’re way off base and have to backtrack.“

What about AI in your sector do you think is overhyped?

Dolan: “The hype around the ease of use of AI and the democratization of enterprise software delivery — that ‘anybody could do it now, it’s all being done by machines’ — is another idea that could prove costly in the long run.

“This do-it-yourself reaction is dangerous for clients, and for trust in the overall AI benefit, which is real. We compare it to the beginning of offshoring 20, 30 years ago: a golden idea that was going to cure everything. A lot of firms did it thoughtlessly, thinking it’s just labor arbitrage, and it almost inevitably failed. That all-or-nothing mentality missed that offshoring is an amazing way of getting better value for your dollar, but it has to be done thoughtfully, so the delivery process — the thing that ties it all together — stays unsevered.

“We’re seeing that now. I’ve heard, ‘We’ll just push a button, the machine’s building the system.’ The machine is not building the system. It might be writing the code, the story, running the tests.

The system is built by a team of engineers you bring in and trust. My fear is that people will say, ‘We don’t need this vendor or this technology team. I’ve got a product team. They might not be able to code at all, but they know the business,’ and it fails dramatically. 

“Then people say, ‘We played with AI, it’s not ready yet,’ and throw it all away. One of the best things we can do is ensure clients know the benefit is real.“

Erickson: “The hype can be summed up in a single phrase: vibe coding. That has done AI a massive disservice, because there’s a huge difference between vibe coding and enterprise software development, and some of the loudest proponents of AI are too latched on to it. In our industry, the only way to succeed would be a stable of unicorns. It just doesn’t scale. I get perturbed when our people internally refer to AI tooling as vibe coding; if they think that’s what they’re doing, they’re misunderstood.“

When you engage clients at different levels of AI maturity, how do you get them to a understand what works?

Dolan: “95% of our take on an agentic approach is in line with everyone else’s, but that 5% matters, especially in requirements discovery, in who’s giving the requirements and how they’re thought of. It can set you up for dramatic errors, given the speed at which you’re moving.

“There’s a dangerous human tendency we’re seeing among clients to try and cut corners at the start of a project and — in lieu of having deep, expert driven discovery sessions — just summarize what they may want using AI.

“We would hope our clients are collaborative, everyone understanding it’s early days. If a client insists on doing something we feel strongly against, like a product owner completely owning everything right up to code generation, that’s an issue we have to either push back strongly on or step out of the accountability for.“

AI body shops — LLM providers and giant consultancies — are emerging to help enterprises deploy AI. Does that model work?

Dolan: “Whether you’re partnering with an LLM or with an AI-first, generic software provider — ‘Hey, we’re not industry guys, but we know AI delivery’ — you end up, if you’re a bank or a broker-dealer, saying: ‘All right, we know our business, these guys know the AI side of it. What could go wrong? Put us together and we’ll have quality engineering.’

“The problem is what you miss: the know-how of putting industry and technical expertise together and actually delivering financial services systems. The people working at the generic delivery firms, whether an AI-only firm or a body shop somewhere, don’t have that capability.“

Does AI change the economics for smaller consultancies like yours competing against the big firms, and does it cut both ways?

Dolan: “Over our 15 years pre-AI, there were two recurring reasons we’d lose a project. One: ‘We’d love to work with you guys, given your subject matter expertise, but the costs just aren’t there compared to my budgets. I’m being forced to go to a body shop or an [offshore] delivery center.’ The other side of that coin: ‘We love your capabilities, but you’re a firm of 230 people and I need 300, 400 people.’

“AI changes the options for clients. You don’t have to sacrifice the niche vendor who knows your space just because you need a larger team or a cost target. AI levels the playing field and should allow smaller firms to compete with the larger, big-box generic firms, the Accentures of the world.“

Erickson: “It redefines what scale means. You can look at velocity as a measure of your cost to deliver, not a rate card. Scale can’t be defined in terms of headcount anymore. It’s got to be defined in terms of output.

“There’s a threat in it, too. If you’re an Accenture with hundreds of thousands of low-cost software engineers, how do you train all those people? I feel for them. But for us, a couple hundred people with a specific domain focus, it’s a huge opportunity.“

How has the profile of the people you and others hire changed with this agentic process?

Erickson: “You’re still looking for people with strong engineering and design backgrounds, and communication skills, because they interact across the software development lifecycle more than in the past.

“Many take too much joy in typing out perfect code. Sorry, I don’t need you writing for-loops and classes anymore. I need you reviewing them, understanding them, operating at a higher level. That’s a different kind of person: an engineer, not a programmer or a coder. On the [business analyst] side it’s similar: people took great pride in detailed user stories covering every path. Now it’s conversations, prompts, reviewing output — less doing, more interacting.

“More than ever, they have to be interested in the domain. They can’t just be, ‘I want to learn everything there is to know about Java.’ That’s too narrow. They don’t have to be an expert; they have to be interested. In our case, capital markets is a specific niche. The biggest challenge is getting familiar with the tools — finding time, while delivering for customers, to ramp up and make the mistakes you need to without jeopardizing projects.“

What about governance? Who’s keeping AI delivery and its costs under control?

Erickson: “This is evolving rapidly. People aren’t sure how to put governance around this. The most obvious is financial governance. People are starting to get hefty bills. One of our clients spent a million dollars on tokens over the last eight weeks alone. Sticker shock. The token-maxing policies are starting to show their flaws. It’s wild west still: learn on the fly, then figure out what needs to be governed.“

Are CIOs actually opening their wallets? And when they do, what’s the smarter way to invest?

Erickson: “There’s still a lot of caution. Forecasts keep going down on how long something should take. So: ‘I could wait three months and maybe still get it delivered by the same date someone’s promising me now, but for half the price. I’m going to wait and see when equilibrium is met.’ We haven’t seen the wallets open up like crazy — it’s slow adoption.“

Dolan: “One of our clients is looking at it from a productivity-boost perspective: instead of doing the same for less, I can do much more for the same. AI lets clients pull the trigger on things they wouldn’t have in the past — projects that might not have been approved pre-AI, where the costs have come down to a point that’s palatable with the business.“

Erickson: “And that’s the story we’re hoping to hear more of. There isn’t a huge cost anymore to exploring a business opportunity. The time and money that would have gone to a return-on-investment study could be spent on a proof-of-concept with AI, and the project done a few weeks later. Maybe [there’s] a hint of things to come, where decisions start being made quicker. 

“There’s a little fear on our side, though: a lot of tiny little projects is tough for a consulting business.“

Security operations centers (SOCs) have spent years struggling under the weight of growing alert volumes, expanding attack surfaces, and chronic staffing shortages. Now artificial intelligence is adding a new complication: not just more information, but more machine-generated information that must itself be evaluated.

“There is an asymmetry here because you now have to parse through a lot of AI slop to get to, ‘Okay, is this real or not?’” Fernando Montenegro, vice president and practice lead at The Futurum Group, tells CSO.

His observation captures a growing concern among security leaders. AI is helping attackers and defenders move faster, but it is also creating new forms of cognitive burden for the humans tasked with separating signal from noise.

As AI accelerates vulnerability discovery and enables more automated reconnaissance and exploitation, defenders are increasingly responsible for overseeing systems whose outputs can be difficult to interpret or verify. The challenge is not simply more work. It is that the volume, speed, and complexity of that work are increasing simultaneously.

Yet experts who study and advise SOCs reject the idea that collapse is inevitable. Instead, they describe an industry entering a difficult transition that could reshape how security teams operate and how humans and machines share responsibility for defense.

The vulnerability surge is exposing years of security debt

One of the most immediate concerns is the possibility that AI dramatically increases the number of vulnerabilities organizations must identify and remediate.

Chris Crowley, a longtime cybersecurity instructor and SOC expert, argues that organizations are facing the consequences of years of accumulated technology debt.

“A lot of what we’re going to have to account for in the next couple of years is a technology debt of vulnerable software that has been deployed because it’s good enough to solve the problem, but then there are all these latent cyber issues, flaws, vulnerabilities that weren’t discovered prior to deployment,” he tells CSO.

AI-assisted vulnerability discovery has the potential to expose those weaknesses at a pace defenders have never experienced before.

“The compression of work that is being dropped on us is unprecedented,” Crowley says. “We’ve just been ignoring it for decades.”

He does not believe AI will necessarily create entirely new classes of vulnerabilities. Instead, he expects defenders to confront much larger volumes of familiar problems.

“We’re going to have 100 of these simultaneously,” he says, referring to the kinds of high-priority vulnerabilities security teams traditionally handle one at a time.

The AI challenge for many SOCs may be less a novelty problem than a volume problem. Security teams already know how to patch systems, prioritize remediation, and respond to critical exposures. What changes is the scale and speed at which those demands arrive.

Organizations with mature patching, prioritization, escalation, and response processes may struggle but adapt. Organizations that have treated security operations as a bare-minimum compliance function may find themselves overwhelmed.

For CISOs, Crowley says, that means treating “patch now” less as an occasional emergency state and more as a permanent operating posture. As AI accelerates vulnerability discovery, the distinction between routine maintenance and crisis response may continue to blur.

He compares the situation to disaster recovery planning. Organizations that wait until a crisis arrives to establish staffing plans, escalation paths, and remediation processes may discover there is not enough help available.

Cognitive overload may become the defining challenge

While vulnerability discovery receives much of the attention, Montenegro believes security leaders need a broader framework for understanding AI’s impact.

Organizations should think about AI through three lenses, he says: security for AI, AI for security, and security from AI. The first involves protecting AI systems. The second involves using AI to improve defensive operations. The third asks what happens when adversaries use AI against the organization.

For SOCs, all three categories are beginning to overlap.

As AI makes it easier to create reports, assessments, vulnerability submissions, and other operational artifacts, humans remain responsible for determining whether that information is accurate and useful.

“It becomes much easier to generate content,” Montenegro says, “but if you’re going to review that content as a human, the onus on you now is that much larger.”

The result is a new form of cognitive overload. Security professionals may spend increasing amounts of time evaluating machine-generated information instead of conducting higher-value security work.

Organizations can increasingly use AI to summarize reports, evaluate alerts, and assist with investigations, but humans remain responsible for validating the results.

“We’re not at the stage yet where people are comfortable” handing off critical decisions entirely to AI, he says.

That leaves defenders caught between two competing realities: AI is creating more information to process, but AI is also becoming one of the few viable tools for managing that growing workload.

For Montenegro, the principle should be to automate tasks, not roles. AI can absorb repetitive investigative steps, but organizations should be cautious about removing humans from the process entirely.

The risk, he says, is that if organizations hide too much complexity behind automated outputs, analysts may lose opportunities to develop the domain knowledge needed to advance.

“How is that professional who is reacting to those alerts growing as a professional?” he says.

The gap between mature and struggling SOCs may widen

Not every organization will experience the impact of AI in the same way.

John Hubbard, senior cybersecurity consultant and SANS instructor, believes the industry’s response will largely depend on how well organizations have prepared for operational stress before AI arrives at scale.

“I would roughly break security operations teams into two camps,” Hubbard tells CSO. “There are the ones that are definitely struggling, are already overwhelmed. And then some are doing really well.”

The struggling organizations tend to be understaffed, underfunded, undertrained, or dependent on ad hoc processes. Every incident feels different, forcing teams to improvise under pressure.

“Getting hit with something like this can certainly be an accelerant for burnout if they weren’t already experiencing it,” Hubbard says.

By contrast, mature security teams have already invested in processes, training, exercises, and automation. “The teams that are doing a really solid job now are probably not super overwhelmed because they’ve developed the processes and procedures to be ready for this kind of thing,” Hubbard says.

He compares successful SOCs to fire departments. Firefighters cannot predict exactly where the next emergency will occur, but they know how to respond because they have rehearsed those responses repeatedly.

“The teams that kind of can react like a fire department are the ones that are getting it right,” he says.

Those organizations conduct tabletop exercises, adversary emulation exercises, red-team assessments, and incident response drills. As a result, they can absorb additional workload without descending into panic.

Burnout remains the industry’s most difficult problem

Despite widespread concern about AI-enabled attacks, none of the experts view AI solely as a threat. Several argue that AI will become essential for helping defenders cope with the challenges it creates.

Jose-Marie Griffiths, president emerita and former CIO of Dakota State University, believes AI can help security teams sift through overwhelming volumes of information and identify the signals that matter most.

“People who work in SOCs are now seeing overwhelming volumes of data, and they’re getting fatigued,” Griffiths tells CSO.

AI can help automate portions of analysis, validate alerts, and improve visibility into complex environments. But Griffiths cautions that some AI-assisted vulnerability discovery tools are also producing large numbers of false positives.

That matters because false positives do not eliminate work. They create it. As organizations confront escalating volumes of findings, distinguishing genuine risk from erroneous results may become as important as discovering vulnerabilities in the first place.

The experts agree that technology alone will not determine outcomes. People will.

Crowley argues that cybersecurity professionals must recognize that uncertainty is intrinsic to the profession. “We are the group that deals with uncertainty,” he says. “That’s really and truly what cybersecurity is.”

That reality places responsibility on both individuals and organizations. Analysts need mechanisms for managing stress. Teams need to recognize when colleagues are approaching their limits. Managers need to establish healthy escalation practices and realistic expectations.

Hubbard rejects the notion that burnout is inevitable.

“It is not a foregone conclusion that security operations jobs have to be a painful grind that everyone hates,” he says.

He has seen organizations where employees remain engaged for years because leaders actively manage workload, create supportive cultures, and encourage open communication.

That includes making it safe for analysts to admit when they have reached their limits. “If people are unwilling to say, ‘I’m maxed out right now, and I’m going crazy,’ that’s going to be the thing that breaks a lot of teams,” Hubbard says.

Pay alone may not solve the problem. Crowley pointed to SANS/SOC survey findings showing that compensation ranked fourth among retention factors, behind meaningful work, training, and professional development.

The future SOC may look very different

Griffiths believes organizations will need to respond not only with better technology but with structural changes. Traditional tiered SOC models may need to evolve into more collaborative teams with diverse expertise working together in real-time.

“I think we’re going to have to eliminate the hierarchies a little bit and have teams of people with different expertise working together,” she says.

She also argues that organizations should invest in human expertise rather than simply increasing AI consumption. “Buy engineers, not tokens,” she says.

Professional networks and peer support will matter as much as any tool, Griffiths says, because defenders need trusted communities where they can compare notes, share practices, and avoid facing sustained pressure in isolation.

If there is a consensus emerging among experts, it is that AI is exposing weaknesses that already existed.

The staffing shortages, alert fatigue, burnout, and process failures affecting SOCs did not begin with generative AI. AI is simply amplifying them.

At the same time, AI is providing new tools that may help organizations manage those very challenges.

The future SOC may spend less time manually triaging alerts and more time validating automated findings, conducting threat hunting, and making strategic decisions. Human expertise may increasingly be paired with AI systems that act as operational partners.

The transition will not be painless. Some teams will struggle. Some practitioners may leave the field. Others will adapt and thrive.

“In a way,” Griffiths says, “we’re turning the whole SOC inside out.”

Montenegro sees the transition as a cybersecurity version of the Red Queen effect: defenders and attackers must keep running simply to stay in place.

Borrowing from science-fiction author William Gibson, Montenegro offered perhaps the simplest description of the industry’s current moment: “The future is already here. It’s just unevenly distributed.”

For security leaders, that future is arriving in the form of AI-generated vulnerabilities, AI-assisted investigations, and AI-enabled adversaries. The question is no longer whether security operations centers will change. It is whether organizations can adapt quickly enough to keep pace.

Security engineers play a pivotal role in enterprise cybersecurity, because they are the professionals who design, build, and deploy security systems to protect an organization’s data, applications, systems, networks, and other IT components against a variety of cyber threats.

Finding not just qualified security engineers, but the best and brightest available, needs to be a priority for CISOs and others overseeing security at their organizations. That’s especially true with the rapid rise of AI and the threats that brings to the enterprise.

Here are some of the key skills and traits of elite security engineers to look for when hiring — or to acquire in order to uplevel your cybersecurity career.

Acumen with AI-powered tools

These days, AI-related skills are in demand regardless of domain, and this certainly applies to security engineers. There’s a wealth of solutions leveraging AI in the market, tools that engineers can add to their defense arsenal.

“AI is transforming security engineering from reactive alerting to predictive threat detection,” says Praveen Margabandhu, digital engineering anchor at financial services firm Navy Federal Credit Union. “AI-driven anomaly detection now identifies behavioral patterns that indicate fraud or compromise before traditional threshold-based systems would fire. This shifts the security engineer’s role from incident responder to threat model designer.”

AI-powered tools have taken over a large portion of the detection and triage work that used to be the core of a security engineer’s day, says Maruf Ahmed, cofounder and CEO of global tech staffing firm Dexian. “Vulnerability scanning runs on its own now,” he says. “Threat flagging that used to require a team pulling through logs for hours happens in minutes.”

This has freed up capacity on most security teams and changed what the day-to-day work looks like, Ahmed says. “With detection increasingly automated, the engineer’s value sits more in interpreting what gets flagged and deciding what to do about it,” he says.

Keen understanding of emerging and established AI threats

Engineers must also have a thorough understanding of the risks AI presents, including AI-enhanced cyberattacks using large language models (LLMs) to automate and scale highly personalized social engineering attacks, craft sophisticated malware, and generate deepfakes.

Other AI threats they need to be aware of include prompt injections, data and model poisoning, disclosure of sensitive information, model theft, supply chain compromises, and excessive agency.

“The same generative tools that help security teams work faster are available to adversaries, and it shows,” Ahmed says. “Phishing campaigns read better and land more precisely than they did a year ago. Social engineering is harder to catch when the language is polished and tailored to the target, and security engineers are now defending against threats built with the same class of technology they use on the defensive side.”

That has raised the bar for what reliable detection looks like, Ahmed says. “The objective shift I hear most from clients is about trust in their own systems,” he says. “Two years ago, the priority was visibility — making sure you could see across your environment. Most organizations have that now. The harder problem is knowing whether what those tools are telling you holds up under scrutiny and having people on the team who can stand behind those findings in front of a regulator or a board.”

Appreciation of performance and business goals

The best security engineers understand how performance and security intersect, says Margabandhu, who leads performance engineering across Navy Federal Credit Union’s digital banking infrastructure, including real-time fraud detection, identity and access management, and cybersecurity infrastructure resilience.

“A fraud detection system that is secure but too slow to catch transactions in real-time is not secure at all,” Margabandhu says. “Elite engineers optimize for both simultaneously.”

Engineers must be able to put things in business context, Ahmed says. “An engineer who can work across domains, validate AI outputs, and learn new tools fast is valuable. But that value compounds when the person also understands what the organization is trying to protect and why,” he says.

Security engineers who understand the business make better risk decisions, write more effective policies, and generate less friction with the teams around them, Ahmed says. “That is the profile employers are hiring toward right now, and it is where the talent shortage is most pronounced,” he says.

Systems mindset

“One of the biggest misconceptions in cybersecurity hiring is that elite security engineers are defined purely by technical certifications or tool familiarity,” says Juan Mathews Rebello Santos, an independent cybersecurity researcher and ethical hacker.

“Technical skill absolutely matters, but the strongest engineers I’ve worked with consistently share a combination of analytical thinking, operational adaptability, communication ability, and deep systems understanding,” Santos says.

Elite security engineers understand how infrastructure, cloud services, identity systems, applications, APIs, networks, users, and business operations connect, Santos says.

“Modern attacks rarely target a single isolated component anymore,” he says. “Threat actors chain together weaknesses across environments. Engineers who can understand those relationships holistically are significantly more effective at both prevention and incident response.”

Cross-disciplinary fluency and broad stack know-how

Being an elite software engineer today means having a range of technology experience and knowledge. “Organizations want engineers who can work across more of the stack than they used to,” Ahmed says. “A role that might have asked for deep specialization in one area now expects someone who can move between cloud infrastructure, application security, and compliance without needing a handoff at every boundary.”

The attack surface has continued to get wider, and the job descriptions for security engineers has followed suit. “That cross-domain fluency matters because security incidents rarely stay contained in one layer,” Ahmed says. “The engineer who can follow a problem from the network through the application to the data governance framework resolves it faster, with fewer people involved.”

The strongest security engineers bridge infrastructure, application, and business domains, Margabandhu says. “They can speak to a CISO, a developer, and a cloud architect in the same conversation,” he says. “An engineer who can explain what an authentication problem means for fraud exposure moves faster in a room full of executives than one who can only describe it in infrastructure terms. I’ve watched technically brilliant people lose that race repeatedly.”

Having the ability to communicate technical risk clearly to non-technical leadership can mean the difference between success and failure of attacks.

“Many security failures today are not caused by lack of tooling, but by misalignment between technical teams and business decision-makers,” Santos says. “Elite engineers can explain operational risk, prioritization, and security tradeoffs in language executives understand.”

Deep understanding of third-party risk and non-human threats

Threats can come from anywhere, including supply chains and non-human combatants. Third-party cybersecurity risks are on the rise. The 2026 Global CISO Leadership Report by executive search firm Hitch Partners, based on a survey of more than 625 information security executives across the US and Canada, says 43% put third-party risks as the No. 1 priority.

“Most teams are still better at securing what they own than securing what they depend on,” Margabandhu says. “The mental shift from perimeter thinking to dependency thinking is real and not everyone has made it. The engineers who treat every API call, every credentialed vendor, every third-party model as part of their attack surface approach design differently.”

Another growing source of potential threats are not human. Machine identities now outnumber human identities by ratios exceeding 100 to 1 in most enterprise environments, with some sectors closer to 500 to 1, according to the ManageEngine Identity Security Outlook 2026 report.

This includes service accounts, API keys, automation tokens, and AI agents, any one of which can present data governance and security risks.

Many organizations are still managing machine identities through manual processes that weren’t designed for scale, Margabandhu says. “Engineers who understand non-human identity governance are rare and increasingly important. This is not a future problem.”

Willingness to keep learning

Security engineers need to have a desire to never stopped learning.

“That sounds obvious until you work with people who’ve been doing this for 15 years and are still operating from the same threat models they built in 2012,” Margabandhu says. “Security changes fast enough that standing still is the same as going backwards.”

The security engineers who keep up aren’t reading one report a year. “They’re genuinely curious about what attackers are doing right now, this month, and they adjust how they think accordingly,” Margabandhu says. “That quality is harder to hire for than most technical skills, because it’s not on a resume.”

With AI presenting new and more sophisticated threats, keeping up with the latest developments is perhaps more important than ever. “Strong engineers are naturally investigative,” Santos says. “They actively study attack techniques, test assumptions, reverse engineer failures, and continuously adapt their understanding of risk.”

The best security engineers are often the people who remain intellectually uncomfortable because they know the landscape is always evolving, Santos says.

Employers have started paying closer attention to how fast someone can learn, Ahmed says. “The threat landscape and the defensive toolkit are both moving faster than any certification program can track, so hiring managers are probing for adaptability in interviews: how candidates have responded to recent shifts, whether they have picked up unfamiliar platforms on their own, how they work through problems they have not seen before,” he says.

The key ingredient for successful AI deployment is largely becoming the talent available, not the AI tools installed, putting pressure on IT leaders to upskill their workforces.

With AI skills both the highest in demand and the hardest to hire for, many IT leaders and their C-suite colleagues are rolling out comprehensive AI training programs for employees, both for the IT pros who build AI tools and the business users who will use them.

Smart companies will need to invest heavily in upskilling, says Chris Campbell, CIO at DeVry University. “The pace of change is simply too fast to rely solely on external hiring,” he says. “Organizations that develop AI capabilities across their existing workforce will have an advantage over those trying to win a bidding war for a relatively small pool of experts.”

Moreover, the key elements of what leads to a beneficial AI deployment has changed over time, he says.

“Early on, everyone was worried about access to AI tools,” Campbell adds. “Today, the tools are everywhere. What I see organizations struggling with is figuring out how to apply them to real business problems and integrate them into how work actually gets done.”

At DeVry, some of the strongest AI advocates don’t come from traditional AI backgrounds, but from software engineering, business analysis, cybersecurity, project management, and operations, he says.

“They understand the business, know where the friction points are, and can see where AI can create value,” he adds. “Those skills are often more important than deep expertise in a particular model or tool.”

Experienced AI talent is difficult to find, especially when IT leaders seek candidates who have successfully transitioned AI initiatives from experimentation to production.

“I don’t think every company needs to build a large team of AI specialists,” Campbell says. “In many cases, the people best positioned to drive AI adoption are already inside the organization.”

Upskilling for an AI builder culture

Professional services and accounting firm KPMG is addressing its AI talent challenge by providing widespread AI training to employees, says Rema Serafi, vice chairwoman for tax operations there. Many organizations’ major AI problem in 2026 is a lack of talent, not a lack of technology, she adds.

Forty percent of CIOs surveyed for this year’s State of the CIO report cited lack of in-house talent as a top impediment to implementing their AI strategies.

To address this, KPMG has piloted a six-week AI training program, with the goal of enabling all employees to deploy their own AI tools, Serafi says. The program familiarizes employees with Python and other technologies that serve as building blocks for internal AI tools, she says.

KPMG also revamped its team structures to ensure that three categories of employees — AI power users, makers, and builders — work closely together, says Serafi.

“Everyone’s going to have access to our tools, and everyone’s going to be a power user,” she says, “to the extent that those professionals who didn’t come in with AI capabilities, who didn’t come in as engineers or technologists, if they want to learn, we’re going to certify them to build tools as well.”

Deploying sophisticated, best-in-class AI tools without training employees is like buying an F1 racing car but not hiring a professional driver, she says.

“If we don’t have professionals who know how to use it, they’re not going to be able to maximize the benefit of what’s available to them,” Serafi adds.

KPMG commissioned a study with the University of Texas and found that employees who use AI regularly produce higher-quality work and feel less stressed. Employees who are expert users of AI will progress faster in their careers, she suggests. One challenge for training programs, though, is keeping up with how fast AI is evolving.

“The roles are actually changing in a short period of time,” she says. “When you used to see traditional engineers working with AI, now you see professionals who can actually guide, shape, and direct AI in their client work.”

Retraining: ‘The only realistic path forward’

Another fan of comprehensive AI training for employees is Elmer Morales, founder and CEO of agentic AI coding startup koder.com. Finding outside AI talent has become extremely difficult for most companies, he says.

“Retraining isn’t optional anymore,” he says. “It’s the only realistic path forward for most organizations. The external talent market can’t supply what every company simultaneously needs, and waiting for universities to catch up isn’t a strategy.”

Companies that succeed with AI treat upskilling as a core investment, not just an HR initiative, Morales adds.

“The talent gap is the single most concrete ceiling on AI ambition right now,” he says. “Companies can buy the best models, the best infrastructure, and the best tooling, and still produce nothing of value because they don’t have the people who know how to wire it all together into something that actually works in production.”

Morales suggests that IT leaders look to their existing engineering team to build AI deployment talent.

“The engineers already obsessed with this on nights and weekends, who are shipping personal projects and experimenting with new models, those people just need permission, resources, and a real problem to solve,” he says. “The best AI teams I’ve seen weren’t built by recruiting, but by creating the conditions for the right people to step forward.”

Microsoft has been pushing hard to make Visual Studio Code a major way to consume its AI services, mostly in the form of GitHub Copilot. GitHub Copilot’s deep integration with VS Code brings many conveniences — inline autocomplete, for instance — but it’s frustrating for those, like me, who would rather use another model provider, or even a locally hosted LLM, for those functions.

Visual Studio Code 1.122 introduced a new feature, “Use BYOK [Bring Your Own Key] without a GitHub sign-in,” that allows you to “use chat, tools, and MCP servers in air-gapped or restricted environments where GitHub sign-in isn’t possible.” More importantly, it “enables fully offline workflows with local models like Ollama.”

In other words, you can now use locally hosted LLMs for chat, tools, and Model Context Protocol servers inside Visual Studio Code. The one thing you still can’t do is use a local LLM for inline and next-edit suggestions — at least, not without additional tooling.

Choosing a model for BYOK mode

If you want to use a local LLM with VS Code’s bring-your-own-model system, the first thing you need is a way to host the model. VS Code lacks a model-hosting mechanism of its own, although it’s conceivable that a VS Code extension may offer something like that in the future. That said, hosting models is complicated enough that a dedicated app is really needed for the job.

One easy way to host models is via a product like LM Studio, a convenient GUI for standing up, serving, and managing LLMs on one’s own hardware. The model host does not have to be the same system you run VS Code on, either. It can be on a server box you control, or on a cloud instance.

The choice of model is also important. Many models are powerful but won’t run well on commodity hardware because they’re simply too big. A good rule of thumb is to choose a model that fits into existing VRAM, along with the memory needed for a sizable token context (the more, the better). Also, the model should be suited to coding and development work. Some models in this vein that fit comfortably into 8GB VRAM include:

• Gemma4 (effective 2 billion parameters version)
• Qwen3.5 9B
• Codestral 22B v.0.1 (proprietary license)

Setting up BYOK mode in VS Code

Once you have a model up and running, you can integrate it with Visual Studio Code. If you’ve disabled VS Code’s AI features, you will need to turn them on. Make sure the setting chat.disableAIFeatures is turned off. You can find it in Settings | Chat | Miscellaneous.

Third-party language models are managed through Visual Studio Code’s language model list. Press Ctrl-Shift-P and type Manage Language Models to open the list of existing language models.

First you will see a list of the built-in models, which are all externally hosted. To add a new model, select Add Models at the top right and select Custom Endpoint.

You’ll then get a series of prompts:

• Group Name: This is “Custom Endpoint” by default, but you can choose any name you want. The name is strictly for organizing the model list and doesn’t affect things like model recognition or connectivity.
• API Key: If you’ve configured LM Studio to use an API key for serving models, provide it here. If you’re hosting the model locally and you haven’t explicitly set up API keys, you can leave this blank.
• API Type: The options here are Chat Completions, Responses, and Messages. Most of the time you’ll want to use Responses, as it’s the most general-purpose option of the three.

Once you finish providing those answers, you’ll be dropped into a modal editor for a JSON file that holds the details about the endpoint you’re configuring.

You’ll need to provide a few more details by typing them into the labeled fields:

• id: A text field that uniquely identifies this particular entry. The choice of ID is pretty much arbitrary; if you’re using only a single model, the ID could be the model name.
• name: The name of the model that is used to identify it on the model server. In LM Studio, you can get this name by clicking on My Models in the main interface, then selecting the three-dot icon for the model in question and clicking Copy Default Identifier. For Qwen 2.5, for instance, name might be something like qwen2.5-coder-7b-instruct.
• url: The URL to the server’s endpoint. On LM Studio, this defaults to something like http://127.0.0.1:1234/v1. The /v1 at the end is important because that endpoint is used for autodiscovery of models and their capabilities.

The other fields generally don’t need editing. Most models have tool calling functionality. If you know for a fact that the model you’re using doesn’t have vision support, then set vision to false.

Once you have these fields filled in, you can close the modal editor to save the changes. If you reload the Manage Language Models page, you’ll now see your new endpoint:

You should now be able to launch the chat window and use the defined model for conversation and utilities:

One current, and major, limitation of Visual Studio Code’s BYOK functionality is that it only works for chat and utility tasks. It doesn’t allow you to use a local model for inline suggestions or code completions. The only way to take advantage of local models for expanded functionality with VS Code is to use a third-party tool like Continue.

It isn’t clear if Microsoft will eventually lift this restriction. GitHub Copilot integration in VS Code is a large part of how Copilot as a service reaches its target audience. For the time being, you can certainly use third-party and local models for a significant part of your AI-assisted development work in VS Code, and you can close the functionality gap with additional tooling.

For years we’ve heard the frightening prediction that AI will take jobs away from people. It will and it already is, but that doesn’t mean it won’t also create new jobs and skills demands — like every other labor trend driven by technology advances.

Take security operations for example. Historically, security operations centers (SOCs) were built on a three-tier analyst model. Tier 1 analysts were junior personnel, paid to monitor activity and triage alerts. Their job was often described as “eyes-on-glass” as they tried to uncover signals among the noise. Tier 2 analysts specialized in investigating alerts (lots of them) that seemed fishy to the Tier 1 crew. When something was truly suspicious or malicious, they took remediation actions or worked with IT teams and others on incident response. Finally, Tier 3 analysts were the most senior and generally focused on threat hunting and engineering. Beyond hunting, these gurus performed deep forensic investigations, controls tuning, and detection engineering.

Fast forward to 2026 and the AI-SOC (or the agentic SOC, autonomous SOC, human-augmented AI-SOC, etc.) is not only here but also maturing quickly. At last count, there are over 120 vendors claiming to participate in this market.

As of today, AI-SOC capabilities center on autonomous alert triage and basic investigations. When something looks awry — a suspicious login, an EDR alert, etc. — agents call disparate tools to enrich the alert, create a timeline of activities, produce a confidence score, and even suggest steps for remediation. Sounds like an efficient Tier 1 analyst to me.

In the near future, AI-SOCs will delve into Tier 2 analyst tasks with automated remediation. Additionally, agent swarms will have specialized roles for detection, investigations, remediation, and even system tuning. Some vendors also propose agents for threat hunting and continuous posture management.

There’s still a lot of innovation, development, and real-world testing needed, but it’s clear that agents will increasingly perform more of the heavy lifting. So where does that leave humans? Here are a few roles where cybersecurity professional skills will be needed and in high demand.

Security data engineer

AI agents can deliver value only if they have continuous access to the right data. This requires moving beyond basic SIEM parsers and API connectors. Security data engineers must know the ins-and-outs of all the data: threat intelligence, identity and access management (IAM), cloud logs, endpoint/network/application telemetry, business context, third-party access patterns, and so on.

All this data must fit into unified data layers that support multi-modal ingestion. This requires managing massive data pipelines to ensure context-rich, normalized, and high-fidelity logging from a potpourri of assets, cloud infrastructures, SaaS applications, and identity providers.

Ideally, security data engineers will transform today’s data format and API mess into cohesive data layers using standards such as the Open Cybersecurity Schema Framework (OCSF).

AI security agent orchestrators

As agent-based solutions proliferate into swarms, someone has to act as the conductor of the orchestra. This involves an understanding of how to piece together multi-agent systems while defining boundaries and guardrails, establishing memory persistence, and determining which agents can take autonomous actions and which activities still demand a human-in-the-loop.

Aside from technical agentic chops, AI security agent orchestrators will need a keen understanding of business-centric AI applications and workflows, as well as how all this relates to the latest threat intelligence.

AI model trainers

Rather than “set it and forget it,” AI models for security operations demand continuous updating and specific context for each individual organization based on threats, industry, and business processes.

AI model trainers must become adroit with retrieval-augmented generation (RAG) to update models with local threat intelligence, asset criticality maps, new identities, and internal network architectural changes. Trainers must also be experts at fine-tuning datasets to ensure accurate and optimized results.

AI-augmented threat hunters

With AI agents in tow, threat hunting evolves from a sporadic to continuous activity. This means moving beyond cyber threat intelligence (CTI) update triggers such as new indicators of compromise (IoCs) to focus on adversary behavioral knowledge across entire campaigns and TTPs (throughout the MITRE ATT&CK framework).

In the near future, agents do the basic work while AI-augmented threat hunters use their experience to come up with highly sophisticated, creative, and complex attack scenarios that standard detection logic likely misses. Hunters then utilize AI to instantly write complex queries across massive datasets. The goal? Hunt for adversary intentions — sensitive data exfiltration, data encryption, etc. — rather than easy adversary tradecraft such as file hashes or IoCs.

AI-savvy red teaming/penetration tester

As AI cascades across the enterprise, SaaS applications, and third-parties, organizations will need a new breed of red teamers to discover weaknesses and gaps in enterprise AI infrastructure and applications across the software supply chain.

To accomplish this, AI-savvy red teams and penetration testers must possess the skill set and knowledge to circumvent new types of AI-enabled security defenses. Once beyond security controls, red teaming and penetration testing roles move on to attack an enterprise’s internal AI deployments — testing for things such as data poisoning, prompt injection vulnerabilities, and unauthorized access to underlying data stores used for building and fine-tuning various AI-models.

As the saying goes, “AI won’t take your job, but someone who knows how to use AI to their advantage will.” Cybersecurity professionals who follow this logic, invest in their skill sets, and pursue jobs like those described above will flourish professionally, prosper economically, and be extremely valuable to their organizations.

Because generative AI (genAI) tools and services have become so ubiquitous (and popular), the costs of using them are going through the roof — leading to an insatiable appetite for tokens.

Tokens represent a common way to measure and price AI use. Much like letters and words in English, large language models (LLMs) grasp a sentence or query by breaking words into tokens.

With the AI explosion well under way, tokens are now “the fundamental units of data our models process, many representing a problem being solved,” according to Google CEO Sundar Pichai. (Google, by the way, processes about 3.2 quadrillion tokens a month.)

But as the price of all those tokens adds up, business and IT execs are looking for ways to cut costs while keeping corporate productivity up. Uncontrolled token use has already landed one company with an unexpected $500 million AI bill. 

There are a number of ways companies can rein in the price of AI at the model, infrastructure, silicon, and business levels. Here’s a look at how some of those savings might actually be achieved.

Switch to lower-cost models

One way of potentially saving money is by re-routing AI work to a cheaper model, Pichai said. At Google that would Gemini 3.5 Flash. It delivers “frontier-level capabilities at less than half the price of comparable frontier models.

“If companies use a mix of [Gemini 3.5] Flash and other frontier models, they could save a lot of money,” Pichai said.

Those kinds of models provide cheaper tokens, with reasoning that’s good enough for many users — if not as strong as mainstream Gemini 3.5 — to deliver useful results.

“There is sometimes overkill with the [LLMs],” said Deepak Seth, senior director analyst at Gartner. “I don’t always need a large language model which has been trained on the works of Charles Dickens and Shakespeare and Harry Potter.”

Hyperframe Research principal analyst Steven Dickens can’t stop using Amazon’s Quick, which costs $20 a month, for personal tasks. “It is great personal ROI as it has not only made tasks faster, but unlocked tasks I would never have even attempted previously,” Dickens said.

Don’t forget the hardware and software part of the equation

The token crisis isn’t new, said Dheeraj Pandey, CEO of DevRev, who likens what’s going on now in the AI market to the disruptions that emerged with the arrival of cloud computing and virtualization years ago. 

“We let chaos reign and then we had to rein in the chaos,” Pandey said. “The word that people started using was server consolidation and virtualization.”

The answer to the token problem, he said, is the same: “Anything in systems can be solved with caching and indirection.”

DevRev, for example, is building a memory layer between AI agents and primary data sources, such as Salesforce or ERP records; that can cut token load and make data movement more efficient. The layer holds a knowledge graph with answers to common agent questions and runs on cheaper CPUs, avoiding more costly GPU cycles.

Sending agents straight at systems like ServiceNow and Salesforce “will burn a lot more tokens. It’s also not precise. And finally, it’s not safe enough where I can roll it back in case an agent has committed a mistake,” Pandey said.

Network automation firm NetBrains uses a different method: It uses conventional computing to map a network’s layout then feeds only key information to models for planning and reasoning, where AI excels. “So you don’t have to spend all the tokens,” said Netbrains CTO Sang Peng.

Focus on prompt efficiency

Staffing firm ManpowerGroup has found that prompt efficiency can be an effective tool for improving token use, both internally and externally for clients.

For example, users accessing its internal labor-market tool initially needed 10 follow-up questions to drill into a query. A year later, more efficient use of prompts has brought that number down to an average of four, said Max Leaming, head of data science and AI solutions at ManpowerGroup. 

“They’re using fewer tokens and they’re simply more efficient,” he said. “And that in large part has to do with your ability to prompt efficiently.”

Go local

New AI hardware that generates free tokens at home could ease some of the cost crisis.

At GTC Taipei earlier this month, Nvidia and Microsoft unveiled RTX Spark, an agentic AI desktop PC that runs agents and 120-billion-parameter models locally on Windows. The goal is “to deliver unmetered intelligence to every home and every desk with Windows,” Microsoft CEO Satya Nadella said in a statement.

Some companies are looking to reduce cloud AI costs by putting their own hardware in data centers, with vendors such as HPE and Dell providing servers installed in independent facilities. (On-premise AI is gaining ground amid sovereign AI and geopolitical concerns, including the recent conflict in the Middle East, where large data centers were struck with missiles.)

“There are local, region-specific and multiple vendor AI solutions. All of those things can help mitigate the risk. But they’re not going to eliminate it,” said Max Goss, senior director analyst at Gartner.

Use forward-deployed engineers

Reducing token costs is something that may fall to forward-deployed engineers (FDEs) in customer environments, said Taimur Rashid, managing director of AWS’s Generative AI Innovation Center.

“I expect these teams to be able to architect systems that have those cost requirements in mind, whether it’s use a different model or a different use case that doesn’t increase the per-token cost,” Rashid said.

Companies may spend heavily on token consumption, “but if you’re generating revenue, as long as the economics work out, then you’re at peace,” Rashid said.

The use of FDEs is gaining ground as IT decision-makers look to both rollout successful AI deployments while also keeping an eye on costs.

Change the measure of success from tokens to outcomes

Even with the current emphasis on reducing token use to save money, the metrics used to measure AI success are likely to shift, Gartner’s Seth said. At some point, token-based pricing will move more toward an outcome-based model, where the unit of value is outcomes, not fragments of words.

“Some companies are moving towards outcome-based pricing,” Seth said. “When people start realizing the real cost of tokens, then companies will start looking at token efficiency.”

Hot AI companies can’t stop talking about forward-deployed engineers (FDEs), which are now very much in vogue. 

FDEs, in case you haven’t heard, are hired by companies looking (hoping?) to successfully deploy AI tools and services. It’s one of the hotter professions in a world still trying to understand the impact of AI on careers.

So, what exactly are FDEs — are they techy lone rangers like the ones OpenAI, Google and Microsoft are hiring? Turns out it’s not so much about individual engineers who swoop in to design and roll out AI deployments; it’s more about a team of engineers working together at customer sites.

At least, that’s the view at Amazon Web Services (AWS).

In fact, according to Taimur Rashid, managing director of the AWS Generative AI Innovation Center, the FDE concept pre-dates the current generative AI (genAI) gold rush. The same kinds of engineering teams were needed for the earlier machine-learning and cloud eras to help companies with deployments.

Rashid recently talked about how AWS sees FDEs as a profession in a conversation with Computerworld. And he weighed in on the desired job skills the company seeks in this increasingly AI-centric era.

What is an FDE? “We view it as a team. It’s a cross-functional team that has engineers, scientists, strategists, and folks that can piece technology and business together. In some cases, we do have to have security engineers in there, too. 

“I see them as anesthesiologists. They have to prep so many things, monitor things throughout. We see ourselves as a frontier deployment team helping customers adopt all forms of AI, whether it’s genAI, agentic AI, even emerging trends like physical AI. We’re helping these companies become frontier themselves.”

How does an FDE engagement begin, and how is it structured? “Where we see the forward deployed model is when customers come in — for example, we have our executive briefing center in Seattle and in Arlington, VA. When customers share what they’re trying to do, very quickly a customer’s like, “What’s the quickest way I can go and build something with you?” 

“We’ll forward deploy our people in, we’ll embed them in your business and we’ll go through these 45-day sprints that we typically design. Through those successive sprints, we’re building stuff together, we’re proving value, and then they can expand that to a much broader engagement.

Where do FDEs actually sit? Client side, internally, or in-between? “It’s mixed, and it largely depends on what the customer’s preference is. We’ve seen models where the customer has been very adamant that, ‘We want your teams with us in our business.’  In those cases, we forward deploy the majority of the teams on site. 

“We have models where customers are fine with you being wherever you’re based, as long as you’re still embedded virtually. And then there’s a hybrid. We deploy anywhere from five to seven people. Sometimes, the baseline is actually three.”

Will cost savings be the job of an FDE, or someone else on the team? “I expect these teams to be able to architect systems that have those cost requirements in mind, whether it’s use a different model for a different use case that doesn’t increase the per-token cost…or think about ways where you can use semantic caching. I personally think you may have a high spend in token consumption, but if you’re generating revenue, as long as the economics work out, then you’re at peace.”

What challenges have you gone through deploying FDEs in the real world? “One of the challenges worth highlighting is when customers get really excited about us forward deploying resources, what they end up realizing is [that] they’re not set up to absorb that right away. They realize they have to go through … process-related things, security access — all those operational things. 

“One very good example is the Commonwealth Bank of Australia. They said: “Prioritization’s a big thing, and if you forward deploy and you’re 100% dedicated, how do we ensure that our teams are also equally 100% dedicated?’ When you’re sitting in your office, you’re distracted by your day-to-day. So they said, ‘Why don’t we create a neutral ground in Seattle? You fly your people, we’ll fly our people. We’ll give them three weeks of dedicated time so they have no distractions.’”

Have you gone into projects where they want AI but have no security or governance ready? “I’ve been through this before, certainly. We do see customers that have security processes and capabilities, but it’s not as tight as it should be in the age of AI. Governance is the biggest area where customers right now have the biggest gap. I’m talking governance around agents. In the past two months, almost 100% of the conversation around agents is not about capability. It’s all about governance. 

“That is a big area right now where forward deploy teams are helping with governance education, and building the scaffolding for that.”

How does software engineering fit into the FDE model? “One of the greatest learnings is that as we forward deploy resources and get customers to take AI and integrate it into their systems, the knowledge of software engineering is so important. Today, a customer can use one of the Claude models and scan their code base and look at vulnerabilities. 

“The tough part is not assessing those vulnerabilities, it’s remediating [them]. Remediating [them] requires software engineering experience, because you have got to merge code, test it, deploy it. We largely see that the frontier software development teams are smaller and they’re managing agents that are doing various tasks across the software development lifecycle.”

AWS has many models at your scale, open source, closed — it’s more complex than what other AI vendors offer.  How do you nail down the talent? “It’s massive, and when you look at not only scale, it’s the complexity of the stack. We take an approach where we fundamentally do three important things: No. 1, we want to ensure people understand concepts; they have to understand pre-training, post-training, reinforcement, fine-tuning. 

“Secondly, we make sure that our teams are well versed in their first-party services. The third thing is that by design, AWS has always been about choice. We say, ‘Let’s do 80-20 here. What is 20% of those specialties that we need to have, which can cover 80% of what most customers are trying to do?’”

What skills should software developers learn to move into FDE work — the top three or four things? “We look at three categories. First category is entirely functional. Are they more engineering specific? Are they science specific? Are they security specific? Our litmus test is not only knowledge of the function, but the actual hands-on work that they can do with it. Secondly is around domain. I focus on what is their domain understanding across the whole AI lifecycle? The third thing is cultural. We are looking for folks that are okay at dealing with ambiguity, being good at stakeholder management, and having that startup mindset. 

“This AI transformation’s not for the faint of heart.”

There’s a rush for FDEs from OpenAI, Google, and others. What’s different about what you look for? “I don’t know entirely what the others are looking for, but I’ll tell you what we have been looking for in the past. When we hired solution architects, it was about systems level understanding. But what I see more and more is hands-on experience, cultural mindset, all these things are very important. If I had to pick one thing that is going to be very important in the talent that we either upskill or future talent that we hire, it has to be the application of AI towards software engineering and system integration tasks.

You’re upskilling AWS talent as well? “We do. You will see some publications coming out in the next couple of weeks around how do we do this across our software teams and how does that translate to customer-facing roles.”

When it comes to AI deployments, IT leaders are often caught in an awkward middle space, trying to reconcile conflicting directives from senior management with constantly changing AI models, capabilities, and costs; data governance and security needs; and the limitations of their own team.

“Very few real benefits can be attained by simply purchasing an AI product and giving it to employees. Vendors have been overselling that fallacy for the past three years,” said Nader Henein, a Gartner VP analyst.

“The reality is that strong AI value and consistent ROI are almost always a result of deep and intentional integration of AI capabilities into existing workflows. For that you need specialized teams, which do not come cheap, and organizations have been recruiting those teams in a variety of ways,” Heinen said.

Among the options available to IT leaders looking for help with AI deployments are traditional IT consultancies, AI-specific consultancies, and independent contractors. Large enterprises with deep pockets can consider acquiring an AI firm and integrating its technology and expert staff. The use of open source to reduce vendor lock-in is a strategy that can sit on top of those others, an approach that Capital One has used. 

But the option that has been getting the most attention recently is bringing in forward-deployed engineers (FDEs), teams of experts from AI vendors that embed with a customer’s in-house engineers to oversee AI rollouts within the enterprise environment. Both OpenAI and Anthropic have recently announced FDE offerings, for example, and Microsoft is partnering with consulting giant EY in a new FDE program for agentic AI deployments.

Engineering teams employed by AI vendors have key strengths, such as understanding their models better than anyone else, having experience integrating those models into different types of enterprise environments, and knowing about upcoming model capabilities before they’re announced. But they also have the obvious drawback of vendor lock-in. Even if future rollouts are not within their contracted deliverables, those vendor employees could subtly influence a client’s future AI efforts. 

Flavio Villanustre, CISO for LexisNexis Risk Solutions, cautions IT executives to move into FDE programs carefully. 

FDEs “are financially incentivized to grow customers’ use of a vendor’s AI products and to create stickiness with that vendor’s services,” he said. “While FDEs may be a reasonable value-added service by the AI vendor, customers should always find other unbiased expert opinions that can evaluate competitive solutions across multiple vendors.”

This is particularly important at a time when “investor-subsidized AI token business models are starting to show cracks,” Villanustre said. “Also, in the current rapid pace of innovation in this field where AI vendors are constantly leapfrogging each other, retaining the agility to move from one vendor to the next could create significant competitive advantages.”

Analysts, consultants, and other industry experts who spoke with Computerworld about FDEs echoed Villanustre’s caution, citing concerns around hidden costs, confidentiality, observability, and vendor lock-in.

Long-term costs and vendor lock-in

A key issue that IT executives need to consider is how long the FDE teams will be needed. The enterprise will likely need an ongoing series of AI deployments synced with the current AI model(s). If help is needed today, why would that change tomorrow?

Enterprises tend to overlook those longer-term costs, said John Sangyeob Kim, an AI engineer at software development vendor Solidroad.

“Deployment is maybe 20% of the total cost. The other 80% is keeping the system running through model upgrades, data drift, and edge cases that only appear after months in production,” Kim said. “Most contracts price the first part and assume the rest. Deployment isn’t the hard part of enterprise AI anymore. The next eighteen months are.”

And whether it’s intentional or not, FDEs will naturally favor their own product portfolio — it’s what they know best.

“FDEs from model labs are good at making their own models work in your environment. They are less suited for multi-model systems, because their incentive is to keep you inside their ecosystem,” Kim said.

Sanchit Vir Gogia, chief analyst at Greyhound Research, said IT leaders should look at the FDE model as a strategy involving ongoing operational power. 

“Whoever shapes the deployment pattern shapes the enterprise’s future muscle memory. Whoever owns the evaluation layer owns the truth layer. Whoever controls the integration logic controls the dependency map,” Gogia said. “This is why the FDE model matters. It is not just another delivery option. It is the frontier AI vendor moving closer to the customer’s workflow, operating model, and decision architecture.”

That proximity cuts both ways, Gogia noted. “FDEs are embedded inside the customer’s [environment], but they are also connected to the vendor’s commercial center of gravity. Their instinct will be to build around the model family, tooling assumptions, deployment patterns, and product roadmap they know best. This is perfectly natural. It is also precisely why CIOs must be cautious,” he said.

Allowing AI vendor employees an outsized say in enterprise deployment decisions could lock in model vendor dependency, which in turn will fuel high prices that can’t be fought effectively.

“FDEs can accelerate deployment and deepen dependency at the same time,” Gogia said. “Frontier AI vendors are no longer content to sell access to models. They increasingly want to shape how enterprises deploy intelligence. That is a larger prize.”

What happens when the FDE team leaves?

FDE post-departure risks are severe and often underappreciated, according to Justin Greis, CEO of consulting firm Acceligence and former head of the North American cybersecurity practice at McKinsey.

For one thing, the FDE team learns a massive number of operational details from the enterprise deployment. Although NDAs and confidentiality contracts protect any data accessed, they often don’t regulate observed processes and procedures. 

“The learnings are absolutely going to be taken from client to client,” Greis said. “Whoever helps deploy AI will learn far more than what appears in the statement of work. They will learn the real workflows, the undocumented exceptions, the data-quality gaps, the approval bottlenecks, the security workarounds, and the places where the business depends on a few people knowing what to do when the process breaks. That knowledge may be as sensitive and precious as the data itself.”

Another critical but often overlooked issue is how much meaningful control will IT have over the project if and when the FDE team leaves.

“The danger is not using outside help. Most companies will need outside help,” Greis said. “The danger is using outside help in a way that leaves the enterprise less capable and more dependent when the engagement is over.”

It is precisely those operational decisions that IT often neglects, said Solidroad’s Kim.

“The best predictor of success is not the vendor. It is whether one internal engineer truly understands the system before the implementer leaves. What matters is who owns the evaluation loop after the demo,” Kim said.

“What happens to our prompts, scorers, and guardrails when the model version changes? If we paused this engagement tomorrow, what would actually stop working, by design or by accident?” Kim asked. “Where do you want the enterprise’s AI learning, control, and dependency to live after the engagement is over?”

Kim argues that observability — the ability to understand and manage all elements of a complex enterprise environment — is a critical function to which IT often gives insufficient attention. Determining whether the project uses the enterprise’s observability stack or the vendor’s observability stack is crucial.

“If the implementer is using their observability stack, that is fine during the build, but you need a plan to migrate it to something you own before they leave; otherwise the visibility walks out of the door with them,” Kim said. “If they are using yours, that is the best case. It means they are working inside the system your team will operate long-term.”

A major problem crops up when they are using neither the enterprise’s nor the vendor’s observability stack. “Neither means they are building the system without any production observability layer at all, and you inherit a system you cannot see into. The first time something breaks in production, you have no traces, no failure history, and no way to tell whether the issue is a model regression, a data problem, or a code bug,” Kim said.

“If observability was not a priority during the build, evals and regression testing usually weren’t either, so you are inheriting a system you cannot measure and cannot safely change. That’s the worst possible handoff position,” he said.

Weighing the alternatives

While the FDE approach is not new, it is just now beginning a surge in popularity, and there are a finite number of such specialists available. That means not all companies even have the option of using FDEs.

This availability disconnect is especially prominent for non-US deployments, where on-site FDEs are rarer, said Gartner’s Henein. “Where is the development happening? There may not be FDEs available in that region,” he said. 

There are plenty of other places enterprises can turn to for AI help. Ishraq Khan, CEO of coding productivity tool vendor Kodezi, encourages IT executives to consider a wide range of options but notes that all approaches have major drawbacks.

“Traditional consultancies are usually stronger at governance, process, compliance, and organizational coordination. They know how large enterprises operate politically and structurally. The downside is that many move slower and often lack deep frontier AI specialization,” Khan said.

Gogia from Greyhound Research put it more colorfully: Traditional IT consulting firms “know how to get legal, risk, security, finance, HR, and business units into the same room without anybody setting fire to the carpet. For regulated enterprises, that matters,” he said.

Specialized AI consultancies have a different set of strengths, Khan said. “AI-native consultancies move much faster and are often more technically current, but many are still immature operationally. Some can build impressive demos without fully understanding long-term maintainability, governance, or production reliability.”

Greis from Acceligence commented on two other options for bringing in outside AI help. Using an independent contractor “can be great for eval design, architecture reviews, red teaming, agent design, or getting a stalled team unstuck,” he said, but it can increase the risk of “key-person dependency,” where a single external person is the only one who understands the system.

As for purchasing an AI firm and onboarding its employees, a practice known as “acquihiring,” Greis said it can work well when the AI capability and expertise being brought in are truly strategic for the acquiring enterprise. But there is a risk that the acquired team will be smothered by the parent company’s bureaucracy: “You buy a speedboat, bolt it to an aircraft carrier, and then wonder why it stopped moving,” he said.

Finally, an open-source strategy can give companies flexibility and reduce vendor dependence, but “many companies underestimate the operational burden that comes with it,” Kodezi’s Khan said. “Open source only helps if the organization has the internal talent and discipline to maintain it properly.”

Bottom line: enterprises need to define their true objectives before deciding on an approach. Khan offered several key questions for CIOs to consider: “Who owns the deployment after implementation? Can we move providers later without rebuilding everything? What happens if the vendor relationship changes or disappears? Are we optimizing for short-term deployment speed or long-term operational resilience?”

In any scenario where outside firms have direct access to enterprise systems, IT needs to be kept fully in the loop. “The worst outcome is when an enterprise successfully deploys AI but no longer fully understands how its own systems operate underneath,” Khan said.

External help for AI deployments: 6 options

	Pros	Cons
AI vendor FDEs	+  Best expertise on the main model being used	–  Vendor lock-in –  Operational detail leaks
Traditional IT consultancies	+  Best understanding of change management, legacy integration, global rollout, governance, and operating-model redesign	–  Can be too slow, too expensive, or too generic
AI consulting firms	+  More practical AI deployment experience than traditional consultants +  Less vendor lock-in than model-provider FDEs	–  May not sufficiently understand enterprise-grade requirements: security, identity, auditability, compliance, incident response, cost controls, and long-term maintainability
Independent contractors	+  Useful for precision tasks: eval design, architecture reviews, red teaming, agent design, or getting a stalled team unstuck	–  Risk of ‘key-person dependency’
‘Acquihiring’ an AI firm	+  Works when the acquired capability is truly strategic	–  Acquired team can be smothered inside existing bureaucracy
Deploying open-source products	+  Reduces dependency on one model vendor +  Attractive for data sovereignty, control over enterprise systems, cost efficiencies, and regulated environments	–  Enterprise takes on full responsibility for security, patching, evaluation, deployment, monitoring, and lifecycle management

Related reading:

• Here’s one career emerging from the AI shift: ‘forward-deployed engineers’
• The forward-deployed engineer: Why talent, not technology, is the true bottleneck for enterprise AI
• The new AI lock-in

Have you ever watched a military cyber ops team go to work responding to a cyberattack simulation? It’s like that scene from Die Hard 4.0 when all the screens start flashing red and systems start shutting down; however, unlike the movies, where bumbling government IT workers are caught out and panicking, our military actually moves with practiced precision to understand, contain, and mitigate the threat. Everybody understands their roles and any gaps are quickly highlighted and handled. This is because the military treats cyber as a kinetic threat requiring constant mission rehearsal, while the corporate sector is still treating cyber defense as a compliance checkbox, rather than an operational capability. This is untenable in a world where attackers constantly innovate their tactics and techniques to probe and access systems.

Over the past 12 months, we’ve seen just how unprepared different industry sectors have been in the face of major cyber incidents. Early in 2025, retailers and insurance brokers were brought down by the Scattered Spider group, and major manufacturers, including Jaguar Land Rover and Asahi Beer, saw months of downtime following ransomware attacks resulting from supply chain compromises.

More recently, researchers at Cisco revealed that frontier models from OpenAI, Anthropic, Google, xAI, and Amazon have significantly worse risk profiles when pressured in multi-turn attacks, a discovery that revealed attack success rates are considerably higher than those benchmarked in simulated single-prompt attacks. This, combined with recent news that the Google Threat Intelligence Group identified what researchers believe to be the first zero-day exploit created using AI, represents an entirely new stage in the technological arms race.

Those old-fashioned tabletop exercises where, once a year, you’d get everyone from IT to PR in a room for a couple of days and play out various scenarios and then tick that audit box for another 12 months aren’t going to cut it when attackers are probing on a daily basis. The military is using dynamic cyber ranges to test their real tools, people, and processes, in an exact simulation of their unique environment, against real-world threats like the tactics of Scattered Spider. Without real-world testing of your team’s capabilities, you’re not going to be able to go into an incident scenario confident that everyone’s prepared.

So, what can we learn from how the military prepares for cyberattacks in terms of mindset, readiness, and execution?

Military cyber doctrine starts with the assumption that you will be attacked and so prepare as though an attack is inevitable and not hypothetical. Businesses need to shift their mindset from “preventing breaches” to “detail, contain, and recover” and treat incidents as operational events rather than reputational crises. This reduces panic and leads to better decisions under pressure. It’s also critical for business leaders to understand their true vulnerabilities. Reputational and financial harm is typical collateral damage following a cyberattack, but was this the intended outcome? If sensitive data is compromised, are there persistent threats beyond the initial attack? Just as the military examines the secondary and tertiary impacts of risk scenarios in threat modeling, business leaders have to consider what else beyond their reputation and stock price may be compromised when they are attacked.

The military runs constant exercises; simulations, red team and blue team drills, and scenario planning that reflects real adversary behavior. Businesses can exercise that muscle by running regular live cyber simulations and updating based on real-world attacks. Conventional training still has its place, and companies should continue to invest in professional development programs that provide a strong foundational understanding of the most urgent threats facing their business. But, as the military says, “train like you fight.” There is simply no substitute for practical, hands-on training, especially when it comes to high-pressure, time-sensitive scenarios such as large-scale cyberattacks.

This readiness and preparedness training can, and should, extend to AI Agents too. Think about it like an “AI Proving Grounds”. Effectively, a realistic, intelligent environment where organizations can safely train human operators alongside AI agents, test autonomous workflows, and validate how both perform under real adversarial pressure before deployment. Continue to involve all the stakeholders, including executives and comms teams, who are going to be on the front line of customer, investor, and media inquiries should an attack occur. Without realism, readiness is an assumption, not a fact.

In a military cyber incident, everyone knows who decides, who communicates, and who executes, reducing any mid-crisis debate and empowering teams to act without permission to faster contain the incident. This principle is just as relevant in a corporate environment. Individual training is crucial, and operators should be confident acting in isolation, but it’s just as important that everyone in a rapid response team can work effectively with others, under often-intense pressure. This simulated teamwork is another advantage offered by AI Proving Grounds. In the same way that everyone in a military chain of command understands their role and that of their unit, businesses can pre-assign decision makers and define escalation paths before an incident to ensure clarity and calm rather than blind panic.

Finally, attackers are sharing knowledge all the time. Defenders must adopt the same approach. We know that militaries collaborate extensively across allies, agencies, and domains, recognizing that no unit has the full threat picture. Businesses can benefit from this information sharing by participating in ISACs, CERTs, and industry groups, treating threat intel as a collective defense rather than a competitive weakness.

AI Proving Grounds themselves are only part of the solution. Security is cultural, not just procedural. Even the most realistic simulated attack scenario is only useful if structures are in place for stakeholders to learn from it. What didn’t work well? What didn’t go as expected? What are the weakest links in the response chain? These are all questions executives and technical leadership should be comfortable asking themselves, and businesses must adopt cultures of responsibility to identify potential weaknesses beyond technical limitations. Such retrospectives can and should inform rapid-response playbooks to ensure that training is relevant and that weaknesses cannot be exploited in a production environment.

Many of the clients we work with are corporations and enterprises, but AI Proving Grounds have other applications. Recent years have seen coordinated attacks on critical infrastructure such as the nation’s power grid, including the prolonged intrusion by the Volt Typhoon persistent threat actor, which maintained unauthorized access to the operational technology networks of Littleton Electric Light and Water Departments in Massachusetts from February 2024 to November 2024. Such threats can also be simulated in AI Proving Grounds and provide crucial hands-on training opportunities for critical infrastructure providers that, until now, have been challenging to realistically model. With geopolitical tensions rising across the globe, operational readiness has never been more critical.

“Cyber resilience” has become something of a buzzword in itself and I can almost hear the eye rolls just using the phrase, but it is something the military does actively practice. Cyber resilience isn’t about prevention; it means being able to recover from as well as protect against attacks. With AI-powered adversaries scaling their approach to infiltration, extortion, and espionage, attacks are only going to increase and businesses need to be prepared to deal with them as well as prevent them. Continuous training within highly realistic and dynamic environments against real threat examples is the best way to ensure your teams are prepared at a military grade to secure your organization.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

I’ve spent the better part of the last eighteen months in conference rooms with CIOs working through their AI strategy. The conversations all start in the same place — model selection, vendor evaluation, agent frameworks — and they all eventually arrive at the same uncomfortable question.

“Where is this actually going to run?”

The question lands awkwardly because it sounds like it should have been settled years ago. Most enterprises picked their cloud provider somewhere between 2015 and 2020. They standardized on AWS, Azure or GCP, signed multi-year commits, and built their application portfolio accordingly. The cloud strategy was done. So why is it suddenly back on the table?

Because the workload changed underneath it. The cloud strategy that made sense for stateless web applications doesn’t make sense for AI agents and the CIOs figuring this out fastest are the ones rebuilding their architecture around a constraint most of their procurement teams don’t even know exists yet.

The old cloud calculus is broken

For roughly a decade, cloud strategy was about where applications run. You optimized for compute price, developer velocity and managed services. Data was something you moved to where the apps were. This worked because the data-to-compute ratio was small. A typical application request moved kilobytes of structured data between the app and its database.

The architectural pattern that emerged was elegant in its simplicity: applications in one region, data in another, users somewhere else entirely and the network in between papered over the seams. Latency budgets were measured in user-perceptible terms — a 200ms page load was acceptable, a 500ms one was a problem. Cross-region calls were a tax you paid for resilience or for putting compute close to the user.

That entire model assumed the application was the thing doing the work, and the data was the thing being acted upon.

AI agents inverted that assumption.

AI inverted the ratio

Agents don’t just consume data. They live in it.

Memory, context, retrieval, embeddings — the data isn’t an input to the workload. It largely is the workload. An agent reasoning about a customer’s situation is pulling in conversation history, organizational policies, product documentation and structured records on every turn. An agent writing code is pulling in the repository, the architectural decision records, the test suite and the relevant runtime telemetry. An agent doing financial analysis is pulling in market data, internal forecasts, regulatory filings and historical context — and then producing intermediate results that feed back into the next reasoning step.

The data isn’t a thing the workload references occasionally. It’s the substrate the workload is computing on.

And that substrate has gravity.

It has regulatory gravity — sovereignty mandates, residency requirements, sector-specific compliance regimes that say data of a particular type cannot leave a particular jurisdiction. The EU AI Act, HIPAA, financial services regulations across a dozen countries — these aren’t preferences. They’re constraints that determine, before you’ve made any architectural decisions at all, where some of your data is allowed to be.

It has economic gravity — egress fees, GPU-hour pricing differentials, the brute economics of moving terabyte-scale corpora across cloud boundaries. Training data and embedding stores aren’t gigabytes anymore. Moving them isn’t a config change. It’s a project, sometimes a quarter-long one, with a real bill attached.

It has incumbency gravity — the data is where it is, and moving petabytes is not on this year’s roadmap. Most enterprises have data sprawled across systems that were never designed to be portable. The fact that your customer records live in a particular cloud isn’t because someone made a strategic decision in 2026. It’s because they made a strategic decision in 2017 and the data has been accumulating there ever since.

And it has latency gravity — and this is the one that’s quietly rewriting the architecture for everyone.

Wall time is the forcing function

Here’s the math that nobody puts in their slide decks.

A modest agentic loop (retrieve, reason, act, observe) easily does five to ten round trips per task. The agent retrieves relevant context. Reasons about it. Calls a tool. Observes the result. Reasons about that. Retrieves more context. Acts again. Each of those steps touches the data layer, the memory store, the model and back.

Now put 50 milliseconds of cross-region network latency on each hop. That’s 250 to 500 milliseconds of pure network tax on every single agent task, on top of the actual model inference and tool execution. Run that loop a hundred times an hour, across thousands of concurrent agent sessions, and you’re not looking at a minor degradation. You’re looking at the difference between an agent that feels alive and an agent that feels like dial-up.

This is why I keep telling CIOs the same thing in those conference rooms: your data, your memory store, your models and your agent runtime need to be in the same physical datacenter. Period.

Whether that physical datacenter is yours or one of the hyperscalers’ is the actual question worth debating. But they have to be co-located. If you’re spreading these across regions or providers to chase a procurement discount, you’re sabotaging your own AI strategy before it ships.

I want to head off two objections before the comments section gets to them.

“What about agents that legitimately need to span regions? Say, a global customer service agent that needs to retrieve from regional data stores?”

Those aren’t really one agent. They’re a federation of regional agents with a routing layer on top, and the wall-time math applies within each region. The federation is the architecture. Pretending it’s one agent stretched across geographies is how you end up with the dial-up problem.

“What about hyperscaler private connectivity? Direct Connect, ExpressRoute. That gets cross-region latency down to single-digit milliseconds?”

Single-digit milliseconds still compounds across an agentic loop more than it did for human-driven activity. Five hops at 5ms are 25ms of network tax per task, which adds up across millions of tasks.

And private connectivity doesn’t solve the other gravities. It doesn’t make data residency mandates go away. It doesn’t change egress economics for the data itself. It just makes a single dimension of the problem somewhat better.

The constraint is physics, not procurement. You can’t negotiate with the speed of light.

That’s why the cloud market fragmented

Once you accept that agents have to run physically next to their data, memory and models, the recent fragmentation of the AI cloud market starts to make sense.

Sovereign clouds aren’t winning on patriotism. They’re winning where regulatory gravity dominates and the data is already on a particular side of a particular border. Neoclouds aren’t winning on a vibe shift. They’re winning where economic gravity dominates and GPU-hour pricing makes the math work. Private clouds aren’t winning because on-prem is back in fashion. They’re winning where incumbency gravity dominates and the data is already in your datacenter and isn’t going anywhere. Hyperscalers are still winning where developer gravity and managed services dominate, and where the data is already in their object storage from a decade of cloud migration.

These aren’t competing on the old dimensions. They’re each winning in scenarios where a different gravity is the binding constraint.

The right question isn’t which cloud you should pick. It’s which gravity dominates for each workload, and therefore where the whole stack (data, memory, model, agent runtime) needs to be co-located. Some agents will run in three places. Some agents will need to move between them. That’s why deployment flexibility matters more than it ever did when we were just running stateless apps.

What CIOs should actually do this quarter

Stop picking a cloud. Start mapping your agent portfolio against the four gravities and let the architecture fall out of that.

For each AI workload you’re planning to put into production over the next twelve months, work through four questions:

1. Where does the data live, or where is it going to end up? Not where you wish it lived. Where it actually is, or where regulatory or business reality is forcing it to be. This is the answer that constrains everything else.
2. Which gravity is dominant? If regulatory mandates are non-negotiable, that’s your binding constraint. If GPU economics are the issue, that’s your binding constraint. If you have ten petabytes of historical data sitting in a particular cloud and moving it is a multi-year project, that’s your binding constraint.
3. What’s the wall-time budget for the agent loop? If it’s a batch workload, you have flexibility. If it’s a real-time customer-facing agent, you need everything in the same datacenter and you need to design for it from day one.
4. What’s the portability requirement? As model providers compete and pricing shifts, can you move the agent runtime without moving the data? Can you move the data without rewriting the agent? Lock-in used to be denominated in egress fees. Now it’s denominated in token pricing, embedding model compatibility and agent framework portability.

The CIOs who get this wrong won’t lose because they chose the wrong cloud. They’ll lose because they chose a cloud. Singular, monolithic, picked once in 2019 when the right answer was a portfolio architected around the gravities of each workload.

Cloud strategy stopped being a procurement decision the day agents became the workload. It became a physics problem. And the physics doesn’t care which vendor you signed with.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

A malicious npm package posing as a remote user interface for OpenAI Codex exfiltrated developer authentication tokens, after attackers allegedly published code to npm that was not visible in the project’s public GitHub repository.

Researchers at Aikido said the package, called codexui-android, appeared to offer legitimate functionality while collecting authentication tokens and sending them to an external server.

“AI developer tooling is becoming a high-value target precisely because the tokens are powerful and long-lived,” Aikido said. “A stolen Codex refresh_token goes beyond access to a chat interface — it’s persistent, silent access to whatever that account can do.”

Aikido said the incident reflected a broader pattern in which attackers build credible and useful projects as cover for malicious activity.

“The legitimacy is the attack vector,” Aikido said. “As AI tools proliferate and developers reach for productivity shortcuts, expect more of this.”

The case exposes what some security experts describe as a growing blind spot in software supply chain security, where controls often focus on source code rather than the software artifacts ultimately distributed to users.

The incident showed how attackers can use legitimate-looking projects to hide malicious activity, said Sunil Varkey, cybersecurity advisor and a former CISO. “In this case, the npm package looked completely legitimate: it had an active GitHub repository, useful features for OpenAI Codex users, and attracted around 27,000 weekly downloads,” Varkey said. “Yet the malicious code that stole sensitive tokens only appeared in the published version, not in the public source code.”

Varkey said the risk was widened by a companion Android app that automatically pulled and executed the malicious npm package at runtime.

“Most companies have great security tools for their source code, but the build and distribution pipelines are still total blind spots,” said Devashri Datta, a cybersecurity researcher. “If an attacker leaves their public GitHub repository completely clean but injects malware directly into the npm package, standard code audits won’t catch a thing.”

Datta said enterprises should verify both the provenance of software packages and the consistency between published artifacts and their public source code, warning that seemingly benign source code may not accurately reflect what developers ultimately install.

The enterprise risk

For enterprises, the concern is less the package itself than the level of access now attached to AI developer tools.

Aikido said the package stole access tokens, refresh tokens, ID tokens, and account IDs, with the refresh token posing particular risk because it does not expire. According to Sakshi Grover, senior research manager for IDC Asia Pacific Cybersecurity Services, this means a single successful exfiltration translates into persistent, silent access to everything that the account can reach.

Grover pointed to IDC forecasts that by 2028, half of enterprises deploying agentic AI across Asia Pacific excluding Japan will require an AI bill of materials to support continuous vulnerability scanning, license risk management, and compliance assurance. She said the codexui-android incident illustrates why organizations need better visibility into the components used by AI tools and the credentials those tools can access.

“Most organizations still lack a complete inventory of what their AI tools can access, what credentials they inherit, and what external services they interact with,” Grover added. “Most enterprises have not yet applied the same least-privilege and behavioral monitoring disciplines to AI tools that they apply to human identities, and that asymmetry is what attackers are now actively exploiting.”

A malicious npm package posing as a remote user interface for OpenAI Codex exfiltrated developer authentication tokens, after attackers allegedly published code to npm that was not visible in the project’s public GitHub repository.

Researchers at Aikido said the package, called codexui-android, appeared to offer legitimate functionality while collecting authentication tokens and sending them to an external server.

“AI developer tooling is becoming a high-value target precisely because the tokens are powerful and long-lived,” Aikido said. “A stolen Codex refresh_token goes beyond access to a chat interface — it’s persistent, silent access to whatever that account can do.”

Aikido said the incident reflected a broader pattern in which attackers build credible and useful projects as cover for malicious activity.

“The legitimacy is the attack vector,” Aikido said. “As AI tools proliferate and developers reach for productivity shortcuts, expect more of this.”

The case exposes what some security experts describe as a growing blind spot in software supply chain security, where controls often focus on source code rather than the software artifacts ultimately distributed to users.

The incident showed how attackers can use legitimate-looking projects to hide malicious activity, said Sunil Varkey, cybersecurity advisor and a former CISO. “In this case, the npm package looked completely legitimate: it had an active GitHub repository, useful features for OpenAI Codex users, and attracted around 27,000 weekly downloads,” Varkey said. “Yet the malicious code that stole sensitive tokens only appeared in the published version, not in the public source code.”

Varkey said the risk was widened by a companion Android app that automatically pulled and executed the malicious npm package at runtime.

“Most companies have great security tools for their source code, but the build and distribution pipelines are still total blind spots,” said Devashri Datta, a cybersecurity researcher. “If an attacker leaves their public GitHub repository completely clean but injects malware directly into the npm package, standard code audits won’t catch a thing.”

Datta said enterprises should verify both the provenance of software packages and the consistency between published artifacts and their public source code, warning that seemingly benign source code may not accurately reflect what developers ultimately install. The enterprise risk

For enterprises, the concern is less the package itself than the level of access now attached to AI developer tools.

Aikido said the package stole access tokens, refresh tokens, ID tokens, and account IDs, with the refresh token posing particular risk because it does not expire. According to Sakshi Grover, senior research manager for IDC Asia Pacific Cybersecurity Services, this means a single successful exfiltration translates into persistent, silent access to everything that the account can reach.

Grover pointed to IDC forecasts that by 2028, half of enterprises deploying agentic AI across the Asia Pacific, excluding Japan, will require an AI bill of materials to support continuous vulnerability scanning, license risk management, and compliance assurance. She said the codexui-android incident illustrates why organizations need better visibility into the components used by AI tools and the credentials those tools can access.

“Most organizations still lack a complete inventory of what their AI tools can access, what credentials they inherit, and what external services they interact with,” Grover added. “Most enterprises have not yet applied the same least-privilege and behavioral monitoring disciplines to AI tools that they apply to human identities, and that asymmetry is what attackers are now actively exploiting.”

The article originally appeared on CSO.

Tech companies seem to be falling over each other these days in firing people to either replace them with AI or to pay to build AI infrastructure. Wouldn’t it be nice if they at least waited until AI actually worked for business?

On the one hand, top tech businesses such as Amazon, Block, Cisco, Cloudflare, and Meta have all announced that they’re slashing payrolls — either because AI can do the same work as people or they need the cash to build out their AI infrastructure. Isn’t that great? All together, of the 37,638 tech job cuts so far this year, 47.9% — almost half —  can be tracked back to AI. 

On the other hand, despite all the AI hype and hysteria, no one has yet proven that AI is, generally speaking, really all that helpful for businesses. Oh, I know, I know. You did great things with OpenClaw vibe programming. Microsoft’s CEO, Satya Nadella, claims 20% to 30% of the company’s code was written by AI. And Nvidia assures us that 88% of its surveyed customers report AI has increased their revenues. 

But really, what else would they say? “Dear Board, we just blew half a billion bucks on Nvidia GPUs, and we’re losing money hand over fist?” I don’t think so.

The truth is, as an IDC study reports, a mind-boggling 88% of proof-of-concept AI projects never reach production. Lest we forget, MIT’s The GenAI Divide: State of AI in Business 2025 study found that 95% of AI projects fail to deliver measurable P&L impact. 

Now, I have to acknowledge that AI is finally becoming truly helpful in business. As a guy who knows a thing or two about programming, Linus Torvalds, creator of Linux and Git, said at Open Source Summit North America, “I’m personally 100% convinced that AI is changing programming.” He estimates that “AI will increase your productivity by a factor of 10.” 

But is that reason enough to slash make workforce cuts of between 10% to 40%? (Short answer: No. Longer answer: Noooo!)

It’s not just the mass firings. Workers who are either awaiting the axe, or have escaped it for the moment, are miserable. As one Meta employee told The San Francisco Standard, “I tend to cry in the shower,” and, “A lot of my feelings about my job are about the general chaos and not just the layoffs. ” 

So, explain this to me: When everyone knows AI-driven layoffs are coming, exactly how well do you expect them to work? You really think they can give their best? 

Making matters worse, it’s an open secret that IBM, Google, and Meta are having their employees train their AI replacements. As a popular meme puts it, workers are now “building your own coffin.” Is it any wonder that a lot of people — 29% of all employees and 44% among Gen Z workers —  are deliberately sabotaging work when the boss insists they train their AI replacements?

It also sure doesn’t help office morale when the CEO keeps saying AI will replace half of all employees. A particularly egregious example of this was when Standard Chartered CEO Bill Winters proclaimed his bank would slash thousands of jobs and replace “lower-value human capital” with AI.  

He’s since backed off the claim, but come on — we all know he meant it. Just like all the other CEOs who’ve said similar things, between FOMO and the knowledge that AI job news is sure to make the stock price jump, they’re eager to cut headcounts and boast about how successful AI will make them. 

What happens a few quarters down the road? Their attitude today seems to be let  tomorrow take care of tomorrow. I hate to tell them, but that really doesn’t work in the long run. (Not, mind you, that a future much farther ahead than the next quarter seems to matter much anymore to business executives.)

It should. As a recent Deloitte study stated: “Most respondents reported achieving satisfactory ROI on a typical AI use case within two to four years. This is significantly longer than the typical payback period of 7seven to 12 months expected for technology investments. Only 6% reported payback in under a year, and even among the most successful projects, just 13% saw returns within 12 months.” 

AI, in short, is not the miracle cure for what ails businesses that its fans claim. 

Will that stop businesses? I doubt it. While I appreciate that California Gov., Gavin Newsom is trying to bandage the AI job bleedout by mandating studies on subsidizing companies to keep employees rather than replace them with AI, I doubt that will do much to staunch the wound. 

At the Open Source Summit North America, Linux Foundation CEO Jim Zemlin was optimistic about AI and jobs. He pointed out that, thanks to AI becoming  “pretty damn good coders,” the number of open-source projects on GitHub has led to a “surge of new code and projects.” 

Zemlin also believes that while few developers will write code, “engineers will still design, review, secure, and integrate that code.” (He’s referring to what’s becoming  known as forward-deployed engineers.) This, in turn, will supposedly lead to tech job growth. 

I’d feel a lot better about that prediction if I believed the C-suite suits at most companies were capable of truly forward-looking thinking rather than focusing entirely on hiking the stock price by making the next quarter look good through staffing cuts. 

In the long run, sure, AI will make us more productive. But, we’re not there yet. For now, companies need to keep employees happy, not shove AI down their throats — and work out carefully and thoughtfully how AI will really work for business. 

With cloud migration, digital transformation, and now the drive for AI adoption, CIOs face a real imperative to get modernization right.

However, industry research continues to show that modernization projects can fail to deliver the promised benefits and suffer cost overruns, even as the appetite for overhauling legacy technology grows.

CIOs, enterprise technology leaders, and advisors offer advice on some of the most common modernization pitfalls and how to avoid them.

1. Stacking new technologies on top of legacy systems

Experience has taught Bill Pappas, who as EVP and head of global technology and operations has managed IT modernization at 158-year-old company MetLife, that CIOs should avoid “stacking new technologies on top of outdated, overly complex legacy systems”.

“Modernization is not a race to deploy the newest tools; it’s a disciplined effort to create enterprise value,” Pappas says.

In most cases, new technologies, particularly AI, can’t simply be bolted on to the existing infrastructure.

“Instead of driving transformation, organizations end up with expensive solutions that cannot scale or integrate properly. These systems also introduce added security and compliance risks, leaving organizations vulnerable to breaches and regulatory failures,” he says.

CIOs’ starting point should instead be simplification, which includes strengthening data foundations, streamlining legacy systems, and linking IT initiatives with business objectives and customer outcomes.

“By focusing on simplification, security, and strategic alignment, CIOs can unlock transformation without falling into the traps created by outdated technology,” he says.

2. Overlooking cultural and leadership fit

Doug King, CIO of ePlus, cautions CIOs that a siloed approach to modernization risks failure because it overlooks the deeper cultural and leadership shifts needed to move the organization toward a shared vision of transformation.

The risk is that modernization efforts become a series of disconnected projects instead of a cohesive ongoing transformation that benefits the entire organization. “Ignoring alignment risks wasted resources and investments falling short of delivering meaningful business value,” he adds.

His advice to CIOs is to engage cross-functional leaders, clarify decision-making roles, and focus on the business transformation narrative. “CIOs need to make trust-building and organizational alignment core to their strategy, ensuring every team understands the broader vision and is working together toward it,” he says.

Above all, organizations must clearly identify and articulate what they hope to accomplish and remain grounded in why they’re modernizing. “Modernization isn’t a one-time path your organization travels; it’s an ongoing journey,” he says.

3. Treating cloud migration as the finish line

Many organizations declare success once applications are moved to the cloud, but that mindset can stall modernization just as it should accelerate. Andy Tay, global lead for Accenture Cloud First, warns that cloud migration is often mistaken for transformation. “Cloud migration isn’t the finish line; it’s the starting block,” Tay says.

Without ongoing modernization — spanning architecture, data, operating models, and ways of working — cloud platforms can struggle to deliver sustained business value or support AI-driven innovation. “Leading organizations modernize while they migrate and treat cloud as a business enabler, not just an IT project,” he tells CIO.

CIOs should treat cloud as a living platform, continuously improved through automation, security-by-design, cost governance and AI-enabled operations, rather than a one-time migration milestone, says Tay.

4. Repeating cloud mistakes with AI adoption

Organizations — and CIOs — are under intense pressure to move quickly with AI adoption, but speed mustn’t overshadow security, says Blue Mantis CIO Richard Amos.

“The rapid acceleration of AI adoption in the enterprise reminds me of the early days of public cloud transformation,” says Amos.

As with cloud, AI requires a robust approach to safeguarding data, models, and agents.

“The stakes are even higher with agentic AI, which automates complex, knowledge-based workflows, but also significantly expands the attack surface,” he says.

Agentic AI in particular demands rigorous identity and data access management, with agents

treated as first-class digital identities, with least-privilege access that is task-scoped, time-bound, and continuously monitored, according to Amos.

“Anything less creates unnecessary risks. Human validation should also be mandatory for sensitive actions affecting financial, legal, or customer-impacting domains,” he says.

His advice is not to overlook strong data security and privacy controls, especially for regulated industries, such as data obfuscation, encryption, lifecycle management, and clear supplier oversight. Layered prompts, input/output filters, and explicit permission gating before tools or APIs are invoked are recommended to guard against prompt injection and misuse.

Best practice is to align agentic AI with governance and regulatory standards through a cross-functional AI governance office to ensure compliance with existing and emerging regulations.

“Agentic AI delivers transformational potential, but its benefits will only be realized with robust security and governance,” he says.

5. Overlooking a strong foundation of data quality

CIOs often frame modernization as a tech refresh, and focus on new platforms, cloud migrations, and cutting-edge tools, but often overlook the foundation piece: “The quality of your data and how well it’s integrated,” says Conal Gallagher, CIO and CISO of Flexera.

“This becomes a trap because modernization without clean, connected data is bound to fall apart. Poor data governance and fragmented systems create blind spots that undermine analytics, automation, and decision-making,” he says.

The problem is that CIOs assume that upgrading systems automatically improves data integrity, but modernization amplifies complexity when integration isn’t prioritized. “Instead of reducing silos, organizations can end up stacking them higher,” he says.

The uptake of AI, which requires high-quality, integrated data, can escalate the problem, creating flawed insights and eroding trust. “With companies integrating AI at such a rapid pace this year and planning to in the near future, this becomes a much bigger point of contention,” he tells CIO.

Gallagher recommends that CIOs start any modernization initiatives with data governance policies and look at unifying data across vendors and platforms.

Data strategies should be tied to business outcomes to guarantee that usability becomes a core success metric of transformation efforts. “If teams can’t access and trust the data, modernization of ROI will remain elusive,” he adds

Above all, data should be treated as a product that requires a cross-functional approach across core business units, security, and IT.

“Modernization isn’t complete when systems are upgraded; it’s complete when insights are accurate, timely, and actionable,” he says.

6. Disregarding the ‘emotional debt’ of legacy tech

“Everyone loves to talk about technical debt, but they conveniently ignore or avoid the emotional damage that comes with it,” says John Boesen, chief digital information officer at Plan A Technologies.

It’s a script familiar to many: Years of surprise changes, failed projects, and broken promises create a quiet cynicism inside teams.

“We’ve all seen this — leadership announces a big modernization push, but deep down no one believes it, even if no one says it out loud. That doubt is real,” he says.

To lay the groundwork for success, Boesen is a fan of “future postmortems” that may seem counterintuitive as a planning session.

“Bring the team together and write a postmortem dated two years from now, assuming the modernization failed. Then ask, ‘Why did this happen? Who felt the pain? What went wrong?’” he tells CIO. “A future postmortem exposes risks no one brings up in traditional meetings and leads to a far more honest and realistic roadmap.”

7. Not linking modernization to business value

“Even as enterprises pour money into AI, cloud, and automation, the failure rate remains stubbornly high,” says Matthew Guarini, executive director of Technology Business Management Council and former National Grid’s US CIO.

Guarini points to research from McKinsey that 70% of digital transformation initiatives failed to meet their objectives in 2025, despite years of effort and trillions of dollars.

“A major challenge of IT modernization is the difficulty enterprises face in delivering value from their IT investments,” he says.

And with the enterprise technology landscape increasingly complex and the real prospect of failure rates, CEOs and CFOs are wary of making investments, according to Guarini. Instead, CIOs need to connect technology resources to business outcomes such as increased revenue, greater productivity, enhanced innovation, or improved sustainability.

“Pressured to modernize, CIOs must leverage technology to deliver value from their IT investments, but most tech leaders focus disproportionately on the nuts and bolts of their innovations rather than the true goal of modernization: delivering value to customers and employees,” says Guarini.

8. Treating modernization as a big bang replacement

Another path that can lead to failure is assuming modernization must happen all at once. When organizations talk about modernization, they often think in extremes. “When people think about modernization, they often imagine replacing everything at once or maintaining two parallel worlds in conflict,” Boesen says.

Instead, he advocates creating intentional zones where legacy and modern systems work side by side, each with a clear purpose. “This reduces disruption, controls costs, and allows change to happen at a pace the organization can genuinely absorb. It is a more realistic and more human way to handle a process that is usually more complex than it appears,” he says.

Boesen likens IT environments to cities rather than machines. “Some neighborhoods are brand new, others are historic, and there is always some construction happening somewhere,” he says. The challenge for CIOs is not rebuilding everything at once, but deciding which areas to renovate first to create the greatest impact.

“To prioritize this, the path is simple: Listen to the people closest to the problems and give weight to impact. That is how you focus on what really moves the needle,” he says.

There’s no denying the excitement around Model Context Protocol (MCP), an open protocol for connecting AI assistants with external data, tools, and APIs. Since its debut by Anthropic in late 2024, thousands of MCP servers have emerged for devops, cloud, and beyond.

Now that developers have integrated MCP servers into applications, and they have been battle-tested, usage patterns are emerging. For instance, supplying better context for AI is the most commonly cited primary value of using MCP, according to Zuplo’s State of MCP report released in early 2026. The Zuplo report also found that 63% of MCP users adopt MCP servers for accessing data sources such as documentation or knowledge bases.

In software development, context engineering is the act of supplying AI coding agents with relevant data and capabilities to improve the accuracy and relevance of their outputs. It also involves optimizing the breadth of information to guide efficient processing. Such context can include coding style, internal libraries, institutional knowledge, production data, and external data from platforms like Slack, Atlassian, Notion, or GitHub, among others.

“MCPs support context engineering because it creates a standard way for AI systems to connect to various business tools,” says Todd Olson, CEO of Pendo, a product experience platform. “The key benefit is that the agent determines what context it needs based on the question, then uses the appropriate MCP server to fetch that information in real time.”

With the rise in AI-assisted coding, MCP is becoming a doorway for real-time dynamic search and retrieval across various sources, playing an important role in context engineering efforts. As Joey Stout, solutions architect at Spacelift, an infrastructure orchestration platform, puts it, MCP is the “saving grace of vibe coding.”

How MCP boosts context engineering

Using MCP, agents can fetch structured data contextually relevant to the task at hand. According to Edgar Kussberg, group product manager at Sonar, MCP accelerates the knowledge-hunting engineers must routinely perform on a daily basis.

“When an engineer needs to answer a question, they do not rely on memory alone,” says Kussberg. “They navigate code repositories, dashboards, CI systems, documentation, and security reports, pulling information from each system as needed. MCP gives AI agents that same capability.”

Many of the most popular MCP servers retrieve contextual information to improve agentic coding. For example, an MCP server from Context7 provides up-to-date documentation, while another from Filesystem pulls from any directory on a local machine. An MCP server from Sentry accesses production issues and errors, a server from SonarQube exposes security issues, and a server from Multiplayer returns user session data.

The great thing about using MCP for these situations is that it avoids the need to put large code chunks in every prompt. Instead, coding context like relevant methods, dependencies, or recent changes can be called at runtime, says Venugopal Jidigam, head of agentic platform engineering at WaveMaker, an agentic development platform. “The MCP server assembles and returns scoped, structured context, which the model then uses to reason and respond accurately,” he says.

Another common context-gathering example is retrieving institutional knowledge. “Instead of hardcoding that knowledge into the model, the agent uses MCP to retrieve relevant documents or data at runtime,” says Ebrahim Alareqi, principal machine learning engineer at Incorta, a data and analytics platform provider. “This keeps the agent lightweight while still giving it access to enterprise-specific context when needed.”

Others praise MCP for its role in bringing common standards to agentic data retrieval. “MCP provides the plumbing that makes context engineering practical,” says Gil Feig, co-founder and CTO at Merge, an API platform provider. Without standards, teams end up building fragile custom data pipelines that break often, he adds.

Benefits of using MCP for gathering context

AI-assisted coding has some challenges. Most notably is a trust issue. The vast majority of developers don’t trust the output of AI coding agents — 96%, according to Sonar’s 2026 State of Code Developer Survey report. A second challenge is increased time spent reviewing and debugging AI-generated code. A late 2025 StackOverflow survey found nearly half of developers report frustration dealing with AI solutions that are “almost right, but not quite”.

Context engineering, as well as the use of MCP for this purpose, could help overcome many of these challenges. Using MCP servers, engineers can automatically append relevant logs or internal data to their prompts, refining LLM processing considerably to avoid irrelevant outputs.

The end result is improved accuracy. “MCP allows systems to dynamically fetch what the model needs, like APIs, databases, files, or domain knowledge,” says Neeraj Abhyankar, VP of data and AI at R Systems, a digital product engineering company. “This makes prompts leaner, reduces hallucinations, and ensures models operate with task‑relevant context.”

Another huge benefit is better context window management. Using MCP for context engineering can enable more efficient interaction with underlying models. “MCP tools can save you thousands of tokens just by ensuring you’re using the right things,” says Spacelift’s Stout.

Stout specifically highlights the GitHub MCP server. “It can now access specific files directly from GitHub and do GitHub searching and all the bells and whistles you expect when referencing GitHub,” he says. “MCP made retrieval from GitHub a million times better.”

Using MCP also enhances autonomy and scalability across an enterprise. “Teams can stop relying on partial views or anecdotal evidence and instead operate from a shared understanding,” says Pendo’s Olson. This greatly reduces the friction typically involved in stitching tools, building reports, or looping in teammates, he says.

All in all, the experts say the benefits of MCP in context engineering are numerous. Standardizing on MCP affords more focused prompts that generate more explicitly and relevant context, decreasing the likelihood of LLM hallucination and optimizing what the agent acts on. This in turn can lessen the manual review required for validation and debugging, reclaiming some developer time in the process.

Together, these benefits aim to solve many of the core issues inherent in AI-generated code and agentic workflows at large. “MCP shifts AI development from fragile prompt tuning to repeatable engineering,” says WaveMaker’s Jidigam. “The result is consistent behavior, minimal data exposure, and AI systems that can scale.”

To MCP, or not to MCP

Experts agree MCP can go beyond retrieval augmented generation (RAG) to provide more timely and relevant content in a more optimized fashion. “Traditional knowledge bases and RAG pipelines rely on pre-indexed snapshots,” says Sonar’s Kussberg. “In fast-moving environments, this quickly becomes outdated.”

For this reason and others, MCP unlocks all kinds of possibilities for developers. That said, the protocol is not a silver bullet for all use cases. It’s up against competing agentic protocols for some scenarios, and even simple CLI or direct API access for others.

Ballooning portfolios of MCP servers can increase LLM inputs substantially, too, requiring vigilant optimization techniques to avoid hitting token limits. Such strategies include intentionally designing tools, progressive disclosure, automated discovery, and other emerging tactics.

Then, there are MCP-related security concerns. The security model for the MCP protocol itself has matured quite a bit, but it’s incumbent upon implementers to enforce the correct permissions. “MCP, when implemented the right way, lets you enforce policy-driven access controls,” says Merge’s Feig. This should prevent a junior engineer, for instance, from accessing logs they’re not authorized to access, even if the agent has broader permissions, he adds.

To boost confidence using MCP within enterprise development settings, many experts recommend using an MCP registry that houses vetted, governed MCP servers approved for internal use. Other tools and practices, including agent skills, code mode, and emerging specifications for deterministic AI also promise to play a role in establishing context for agents.

Beyond MCP itself, Stout recommends using Claude Code’s tool search feature, which searches for tools without using token windows. He also highlights Sisyphus, an OpenCode-compatible agent for matching models with different tasks, and Plannotator, a plugin for Claude Code and OpenCode that can be used to plan projects, both of which can aid optimization.

Context is king

The pace of MCP development is accelerating. Analysis of 1,400 MCP servers by Bloomberry charted a 232% increase in six months, from August 2025 to February 2026. Interestingly, read operations outpaced write operations two to one, indicating these servers are performing a significant amount of data retrieval.

Looking to the future, context engineering is anticipated to continue cementing itself as a software discipline, while MCP wields the power to transform APIs into engines for agentic reasoning. As Jidigam says, “MCP-like abstractions will become standard infrastructure, much like REST did in earlier eras.”

Others are similarly confident. “In context engineering, MCP becomes the control plane agents use to access context, tools, and actions,” adds Incorta’s Alareqi. “It will be foundational as software becomes increasingly agent-driven.”

The underlying takeaway: MCP already plays a large role in context engineering, and will continue to do so. As the standard interface between AI systems and data, MCP is the primary vessel for dynamic cross-platform context retrieval at run time, allowing engineers to fetch documentation, API references, policies, available actions, and more.

However, this doesn’t mean context engineering has reached its zenith. Looking ahead, context engineering will evolve from fetching information to coordinating it, says Kussberg, combining multiple MCPs along the way. This will require increased discipline in enforcing standards, assessing risks, and validating changes more often, he says.

So, get started with context engineering using MCP, and stay alert to how your MCP servers are impacting LLM token usage and shaping workflows. The difference between context and non-context matters. Because, as they say, context is king.

Microsoft and EY will spend $1 billion on helping their customers adopt AI over the next five years.

The billion will support assisting clients with pioneering AI projects and capability building, said EY’s global Microsoft alliance leader, Paul Clark. Clients will be able to access those resources based on their specific needs, he said.

“We’re intentionally building the EY forward deployed engineer (FDE) capability through close collaboration and training with Microsoft, while maintaining integrated EY-Microsoft teams in the field,” he said in an email. “Clients will continue to experience this as one combined team, bringing together engineering depth and transformation expertise.”

EY has acted as “client zero” in this initiative, embedding AI in all facets of its organization while it validated ways of working with Microsoft’s technologies. After an initial trial of Microsoft Copilot with 150,000 users, it is now rolling it out through Microsoft 365 E7 to all 400,000 staff.

Its combined offering with Microsoft will be fully integrated, with shared governance and accountability across both organizations, it said. Initial services will cover finance, tax, risk, HR and supply chain activities within the financial services, industrials and energy, consumer and retail, government, and health care sectors.

Pain and suffering

The company’s status as client zero is important here, said Greyhound Research Chief Analyst Sanchit Vir Gogia. “It gives EY a proving ground, not just a reference story. The firm can test AI across its own global workforce, professional services processes and regulated client delivery environment before taking the patterns outward. That gives it a sharper commercial proposition: not ‘we understand AI’, but ‘we have suffered through the operating friction before you’. In enterprise technology, lived pain is often more valuable than polished optimism.”

EY is not merely reselling Microsoft’s AI story, he added. “It is positioning itself as the interpreter between Microsoft’s engineering depth and the client’s messy operational reality.”

Technology analyst Carmi Levy said the challenges of scaling AI solutions are monumental, so it makes sense for vendors to bolster their own support capabilities to allow customers to capture maximum value from their AI investment.

“The forward deployed engineer seems like an ideal solution to this vexing problem, a ready-made, vendor-provided, fully trained resource whose sole job is to help customers crack the AI code and turn its potential into realizable gains,” he said. “FDEs can help tune a given agentic system to the organization’s unique requirements and reduce near- and long-term risk by better aligning the vendor’s technologies to the customer’s internal systems.”

Forward-deployed engineers are having a moment, with both Anthropic and OpenAI putting them at the forefront of their AI sales strategies.

But the concept isn’t new, said Matt Kimball, principal analyst at Moor Insights & Strategy. “When I was a state government CIO back in the early 2000s, I leveraged what is now being called an FDE and it reduced a project from weeks to hours,” he said. FDEs should have the domain expertise to be able to “walk into an enterprise and look at all of these moving parts associated with activating AI and develop (and execute) a comprehensive plan of attack,” covering technology, operations, people, and processes, he said.

However, said Bill Wong, research fellow at Info-Tech Research Group, enterprise leaders need to recognize that while they have the option to procure services to accelerate adoption, they must take ultimate responsibility for what’s built by defining, staffing and applying an AI governance program, and adapting it as AI capabilities evolve.

Forward thinking

Gogia said that many CIOs will bring in forward-deployed engineers for perfectly good reasons: scarce skills, urgency, board pressure, messy legacy systems and a widening gap between AI aspiration and operational delivery, but they should not abdicate responsibility to them.

“Use forward-deployed engineers where they create speed, learning and operational discipline. Do not use them as substitutes for internal architecture, governance or accountability,” he said. “Make them teach, make them document, make them transfer capability, make them design for audit, exit, and resilience from day one. If the engagement leaves behind only working software, it has not done enough.”

This article first appeared on CIO.

Microsoft and EY will spend $1 billion on helping their customers adopt AI over the next five years.

The billion will support assisting clients with pioneering AI projects and capability building, said EY’s global Microsoft alliance leader, Paul Clark. Clients will be able to access those resources based on their specific needs, he said.

“We’re intentionally building the EY forward deployed engineer (FDE) capability through close collaboration and training with Microsoft, while maintaining integrated EY-Microsoft teams in the field,” he said in an email. “Clients will continue to experience this as one combined team, bringing together engineering depth and transformation expertise.”

EY has acted as “client zero” in this initiative, embedding AI in all facets of its organization while it validated ways of working with Microsoft’s technologies. After an initial trial of Microsoft Copilot with 150,000 users, it is now rolling it out through Microsoft 365 E7 to all 400,000 staff.

Its combined offering with Microsoft will be fully integrated, with shared governance and accountability across both organizations, it said. Initial services will cover finance, tax, risk, HR and supply chain activities within the financial services, industrials and energy, consumer and retail, government, and health care sectors.

Pain and suffering

The company’s status as client zero is important here, said Greyhound Research Chief Analyst Sanchit Vir Gogia. “It gives EY a proving ground, not just a reference story. The firm can test AI across its own global workforce, professional services processes and regulated client delivery environment before taking the patterns outward. That gives it a sharper commercial proposition: not ‘we understand AI’, but ‘we have suffered through the operating friction before you’. In enterprise technology, lived pain is often more valuable than polished optimism.”

EY is not merely reselling Microsoft’s AI story, he added. “It is positioning itself as the interpreter between Microsoft’s engineering depth and the client’s messy operational reality.”

Technology analyst Carmi Levy said the challenges of scaling AI solutions are monumental, so it makes sense for vendors to bolster their own support capabilities to allow customers to capture maximum value from their AI investment.

“The forward deployed engineer seems like an ideal solution to this vexing problem, a ready-made, vendor-provided, fully trained resource whose sole job is to help customers crack the AI code and turn its potential into realizable gains,” he said. “FDEs can help tune a given agentic system to the organization’s unique requirements and reduce near- and long-term risk by better aligning the vendor’s technologies to the customer’s internal systems.”

Forward-deployed engineers are having a moment, with both Anthropic and OpenAI putting them at the forefront of their AI sales strategies.

But the concept isn’t new, said Matt Kimball, principal analyst at Moor Insights & Strategy. “When I was a state government CIO back in the early 2000s, I leveraged what is now being called an FDE and it reduced a project from weeks to hours,” he said. FDEs should have the domain expertise to be able to “walk into an enterprise and look at all of these moving parts associated with activating AI and develop (and execute) a comprehensive plan of attack,” covering technology, operations, people, and processes, he said.

However, said Bill Wong, research fellow at Info-Tech Research Group, enterprise leaders need to recognize that while they have the option to procure services to accelerate adoption, they must take ultimate responsibility for what’s built by defining, staffing and applying an AI governance program, and adapting it as AI capabilities evolve.

Forward thinking

Gogia said that many CIOs will bring in forward-deployed engineers for perfectly good reasons: scarce skills, urgency, board pressure, messy legacy systems and a widening gap between AI aspiration and operational delivery, but they should not abdicate responsibility to them.

“Use forward-deployed engineers where they create speed, learning and operational discipline. Do not use them as substitutes for internal architecture, governance or accountability,” he said. “Make them teach, make them document, make them transfer capability, make them design for audit, exit, and resilience from day one. If the engagement leaves behind only working software, it has not done enough.”

Google has only one way to measure the phenomenal AI growth it’s seen: in tokens.

The company processes 3.2 quadrillion tokens per month, Google CEO Sundar Pichai said during this week’s I/O keynote, adding, “never imagined I’d say quadrillion…, but here we are.”

Basically, tokens are a unit of measure used by large language models (LLMs) to process data.

Tokens, which have been called the “new oil” fueling the AI revolution, are also a way AI vendors can meter usage and price their services. Enterprises are lusting for tokens, and spending billions of them to grab compute time.

As with oil, the demand for tokens is seemingly insatiable — and it is straining an already short GPU supply, which in turn is increasing the cost of running AI tools.

What exactly is a token?

Similar to the way humans think, LLMs grasp the meaning of a sentence by breaking words down into tokens. Pichai described them as “the fundamental units of data our models process, many representing a problem being solved.”

The fundamental unit could be in the form of a word, a sub-word, or a string of letters, symbols, or phrases. Compound words can be split into multiple tokens.

For example, the prompt “I am running after a car” could generate “run” as one token and “ing” as the second token because it changes the meaning of the sentence. “Car” would be its own token.

“On average, one token is about three-quarters of a word, so 100 words works out to roughly 135 tokens,” said Deepak Seth, senior director analyst at Gartner.

Token prices can vary

Not all tokens are priced the same. An uploaded token to an AI system is cheaper, while downloaded tokens are more expensive. A user, for instance, might pay to upload a resume, then pay even more to download the resume polished by an LLM.

“The upload cost is less expensive than the download cost because the AI has done some work,” explained Max Leaming, head of data science and AI solutions at ManpowerGroup.

Token-based pricing is mainly used for enterprises and power users such as coders. Anthropic’s Claude Code and OpenAI’s Codex are priced in tokens, and Microsoft’s GitHub is adopting a form of token-based pricing starting June 1.

The final AI bill includes the costs of tokens and computing expenses (such as GPU time).

ManpowerGroup pays the token cost to the model provider while compute costs ring up in parallel. (The company uses Microsoft Azure, which offers multiple LLMs, with Snowflake as its database.)

Some LLMs can be smarter and token friendly

Some AI models give better responses, which might represent a more efficient use of a token budget. Pichai said Google’s new Gemini 3.5 Flash — which is priced in tokens — delivers “frontier-level capabilities at less than half the price of comparable frontier models.

“We’ve heard that many companies are already blowing through their annual token budgets…,” Pichai said, arguing that if companies used Flash, “they could save a lot of money. If they shifted 80% of their workloads from other frontier models to 3.5 Flash, they’d save over $1 billion annually.”

Prompt efficiency matters

Using tokens inefficiently is wasteful spending, Gartner’s Seth said. One coder might use up 10,000 tokens to get his or her work done, while another might use only 1,000. But there’s no tool to measure efficiency, Seth said.

“Some companies are moving towards outcome-based pricing because when people start realizing the real cost of tokens, companies will start looking at token efficiency,” Seth said.

With that in mind, ManpowerGroup developed a dashboard that cuts the steps for clients to get data, Leaming said. New users to an internal labor-market data tool initially needed 10 follow-up questions to drill into a query. A year later, those same users averaged four follow-ups.

“They’re using fewer tokens and they’re simply more efficient,” he said. “And that, in large part, has to do with your ability to prompt efficiently.”

But there’s a flip side. AI tools such as Anthropic’s controversial Mythos LLM — which isn’t available publicly yet — might be priced astronomically high, though its superior reasoning could make it more efficient.

“Even though the per-token costs may go up, we may see overall costs go down,” Leaming said.

AI vendors and the ‘drug dealer strategy’

Top AI vendors are spending trillions to build out AI infrastructures, but they’re not charging enough on tokens, Seth said. “I feel like the OpenAIs, the Googles and the Anthropics of the world are following a drug dealer strategy: Get people addicted to AI, and then raise the price of a token,” he said.

AI vendors could also use free tokens as a way to lock in customers, Leaming said. Free tokens from AI vendors could incentivize companies to build processes and workflows around proprietary LLMs and agents. And as if to reinforce the effort, major AI vendors are now sending out engineers to deploy AI models at customer sites.

The engineers, better known as forward-deployed engineers, or FDEs, are more or less hired guns for AI deployments. They focus on helping customers roll out AI projects successfully.

FDEs can study and help set strategies, put battle plans in place, build agentic frameworks, and roll out AI in conjunction with customers’ own domain experts and engineers. They also evaluate AI models, resolve context and reasoning problems, and handle security issues.  

OpenAI, Google, and Microsoft are moving away from LLMs as the product. “Now they want to get inside of the firm and build your infrastructure for you,” Leaming said.

Free tokens, the next worker perk

Tokens are now sometimes offered as a job perk to engineers, Nvidia CEO Jensen Huang has said. Experts compare that to when companies cover cell phone bills for their workers.

Leaming, who said he hasn’t seen instances of that yet, found the idea odd. But if it is happening, much depends on who is offering free tokens.

Employers offering free OpenAI or Microsoft tokens could represent an indirect form of vendor lock-in, he said. “Then I’m incentivized. The more I’m familiar with the product, the more I’m gonna use it.”

Free tokens are also a way to spur the adoption of emerging AI technologies that are not yet safe for work. Many top tech leaders, for example, are exploring the possibilities of OpenClaw — considered a breakthrough AI technology — on their own dime because the technology is considered risky for enterprise environments.

Alex Spinelli, ARM’s senior vice president for AI and developer platforms, is one such person experimenting with OpenClaw at his own cost.

“In my OpenClaw, when I had it configured wrong, I got a bill for $500 in one weekend, and I was like, what the hell happened here? There’s no free lunch. Tokens are expensive,” Spinelli said.

Gartner’s Seth compared the free-token tactic to a cigarette company in India that once gave employees boxes of cigarettes alongside their salaries. “In addition to their salaries, they used to get a couple of boxes of cigarettes. The whole intent was they will…distribute them out and just make them more popular,” he said.

“If you give it to them, they will use it, because now it’s in lieu of money.”

A few months ago, I was reviewing an agentic AI roadmap with the CIO of a Fortune 500 insurer. He pulled up two slides side by side. On the left: A glossy roadmap for a new agentic AI platform — multi-agent orchestration, vector databases, the works. On the right: A 30-year-old loan origination system running on a mainframe his team had been “planning to retire” for the last few years.

“We’re spending $40 million on the left,” he said. “And the agent on the left can’t see anything on the right.”

That, in one sentence, is the architectural lie most enterprises are living with right now.

For the better part of a decade, we’ve split our IT strategy into two budgets: An innovation lab, where shiny things get built, and a maintenance core, where the actual business runs. We promote people for the first column and quietly outsource the second. Then we wonder why our generative AI pilots can’t make it to production.

I’ll say what most CIOs already suspect but won’t put on a slide: Your modernization strategy and your AI strategy are the same strategy. If you’re funding them as separate line items in 2026, you’re already behind.

What I got wrong about “lift and shift”

I’ll admit I was a believer for a long time. In 2022, my team finished a textbook migration off a 20-year-old Oracle Exadata footprint onto a Cloud native solution. Eighteen months, $20M, zero data loss and a 40% reduction in run-rate infrastructure cost. I had the slide ready for the board.

Then our first generative AI pilot landed, and I watched our agent fail to answer questions that the old database — with all its ugly stored procedures — could have answered in a single query. The “modernized” Spanner instance was clean, fast and — without the surrounding semantic layer — couldn’t answer questions the old database could.

The lesson I took away: Legacy systems aren’t technical debt. They’re encoded institutional memory — three decades of edge cases, compliance carve-outs, regional rules and “we tried that in 2007, and it broke everything” wisdom that nobody documented because nobody had to. You can rewrite the code. You can’t rewrite the knowledge.

Which is precisely why agentic AI changes the math. For the first time, we have a technology that doesn’t just tolerate that messy old context — it needs it.

Earlier this year, I spoke on this intersection of agentic cloud strategy and legacy modernization at Google Cloud Next 2026. What follows is the framework I shared for moving beyond the “lift and shift” mentality.

MCP isn’t a protocol. It’s a peace treaty

The Model Context Protocol gets discussed as a technical standard, and that framing undersells it. After watching teams burn quarters writing custom connectors between every model and every data source, I think MCP is closer to a peace treaty between two warring tribes inside the enterprise: The cloud-native engineers and the legacy custodians.

When an agent can pull a customer’s 2003 account history from a mainframe and combine it with a real-time fraud signal without somebody hand-coding the bridge, two things happen. The integration backlog stops growing. And — more importantly — the political wall between the two teams starts to crumble.

I’d argue this is the most under-appreciated CIO opportunity of the next 18 months. Not the agents themselves. The org chart you can finally redraw because the agents made the old separation pointless.

Why I stopped trusting RAG for legacy code

Here’s a take I’ve gotten pushback on: Standard retrieval-augmented generation is the wrong tool for legacy modernization, and we’re using it anyway because it’s familiar.

RAG is brilliant for documents. It’s a disaster for code. A monolithic codebase isn’t a haystack with a needle in it; it’s a tangled fishing net where every knot is connected to seven others. Ask a vanilla RAG system to help you refactor a billing module and it will confidently tell you the change is safe, right up until production goes down on a Tuesday morning.

Andrew Moore, the former head of Google Cloud AI and now co-founder of Lovelace, told CIO recently that “you cannot do safety-critical reasoning for agents purely based on trying to do the same sort of thing you normally do for chatbots.” That maps to my experience exactly. Chatbots can be wrong and embarrassing. Agents can be wrong and expensive.

GraphRAG — building a semantic knowledge graph of how the code actually behaves, not just how it reads — is the only approach I’ve seen that respects the structural reality of these systems. In 2025, I was advising on a mainframe modernization at a health insurer.  The CIO had given me the official application inventory: 47 systems, well-mapped, with named owners. We ran a graph analysis across the actual code and graph surfaced 53 systems.

The six extra weren’t ghosts. They were live, running and integrated — small applications written between 1998 and 2004, each owned by a business unit that had quietly built them, never registered them and treated them as “spreadsheets that happened to run on the mainframe.” One of them was processing about $35M a year in vendor rebates against pricing tables that no one in IT knew existed.

The graph didn’t just find undocumented dependencies. It found undocumented systems. You cannot modernize what you cannot see, and most enterprise application inventories are wrong by an amount that should embarrass us.

The hard part isn’t technical

Everything I’ve described is buildable today. The vendors are there. The protocols exist. The talent, if you know where to look, is hungry.

What’s missing is architectural courage at the CIO level — and I mean that specifically. It is much easier to fund a new AI initiative than to defend a modernization budget. The first gets a press release. The second gets a line item nobody reads. But if you keep funding them separately, you’ll end up with the same outcome I’ve watched at company after company: A sleek agentic layer floating above an integration layer that bleeds margin every quarter, while your competitors who did the unglamorous work compound advantage you can no longer catch.

If I could give CIOs reading this one piece of advice — and I realize this is the kind of thing that’s easy to say and hard to do — it’s this:

Take your top three modernization projects and your top three AI projects. Put them on the same slide. Give them the same executive sponsor. If you can’t, you don’t have a strategy. You have two parallel cost centers waving at each other.

The myth that legacy and innovation are opposites was always wrong. In the agentic era, it’s an unforced error. The question for the next 18 months isn’t whether to modernize. It’s whether you have the architectural clarity — and the political cover — to do it as one program instead of two.

I think most CIOs already know which side of that line they’re on. I’d just rather we stop pretending otherwise.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Cisco has disclosed a max-severity authentication bypass vulnerability affecting its Catalyst SD-WAN Controller and Catalyst SD-WAN Manager platforms, warning that the flaw has already been found to be exploited in the wild.

The disclosure follows an earlier authentication bypass vulnerability that Cisco patched in February. In the latest advisory, the company said the new flaw was identified while investigating the previously disclosed issue.

“A vulnerability in the peering authentication in Cisco Catalyst SD-WAN Controller, formerly SD-WAN vSmart, and Cisco Catalyst SD-WAN Manager, formerly SD-WAN vManage, could allow an unauthenticated, remote attacker to bypass authentication and obtain administrative privileges on an affected system,” Cisco said in an advisory.

The company also confirmed that it became aware of “limited exploitation” of the flaw in May 2026. However, it did not disclose details about the attack or threat actors involved.

The zero-day flaw is now fixed with software updates, and organizations are advised to apply fixes immediately, as there are no workarounds that address this bug.

Attackers craft a connection for admin access

According to Cisco, the vulnerability stems from improper validation during the authentication process used to establish control connections between SD-WAN devices. It said an attacker could exploit the issue remotely by sending crafted control connection requests to a targeted system.

Successful exploitation would allow the attacker to bypass authentication, establish themselves as trusted peers, and obtain administrative privileges to the affected device.

“A successful exploit could allow the attacker to log in to an affected Cisco Catalyst SD-WAN Controller as an internal, high-privileged, non-root user account,” Cisco said. “Using this account, the attacker could access NETCONF, which would then allow the attacker to manipulate network configuration for the SD-WAN fabric.”

The issue, tracked as CVE-2026-20182, received a max-severity rating of CVSS 10.0. The company said that the issue is configuration-independent, meaning vulnerable systems remain exposed regardless of deployment-specific settings.

Cisco credited Stephen Fewer, Senior Principal Security Researcher, and Jonah Burgess, Senior Security Researcher, both of Rapid7, for discovering and reporting the bug.

Active exploitation kicks patching into high gear

Cisco disclosed being aware of exploitation attempts in May, urging customers to upgrade to a fixed release immediately.

Shortly after the disclosure, the flaw was added to the Cybersecurity and Infrastructure Security Agency’s (CISA) known exploited vulnerabilities catalog (KEV). “Adhere to the applicable BOD 22-01 guidance for cloud services or discontinue use of the product if mitigations are not available,” it said.

The US cybersecurity watchdog has given federal executive agencies until May 17th to patch the flaw.

“Customers are advised to upgrade to an appropriate fixed software release,” Fewer and Burgess said in a blog post, citing fixed software releases that address the flaw in versions 20.9 through 26.1.1. “There are no workarounds that address this vulnerability.”

Alongside software fixes, Cisco published operational guidance to help organizations identify potentially malicious control connections.

The advisory instructed admins to review existing control peering relationships, using the “show control connections” command, and validate all connected peers, particularly those associated with SD-WAN Manager systems.

Organizations that suspect compromise are being advised to contact Cisco Technical Assistance Center support and collect diagnostic information from affected devices.

Cisco has disclosed a max-severity authentication bypass vulnerability affecting its Catalyst SD-WAN Controller and Catalyst SD-WAN Manager platforms, warning that the flaw has already been found to be exploited in the wild.

The disclosure follows an earlier authentication bypass vulnerability that Cisco patched in February. In the latest advisory, the company said the new flaw was identified while investigating the previously disclosed issue.

“A vulnerability in the peering authentication in Cisco Catalyst SD-WAN Controller, formerly SD-WAN vSmart, and Cisco Catalyst SD-WAN Manager, formerly SD-WAN vManage, could allow an unauthenticated, remote attacker to bypass authentication and obtain administrative privileges on an affected system,” Cisco said in an advisory.

The company also confirmed that it became aware of “limited exploitation” of the flaw in May 2026. However, it did not disclose details about the attack or threat actors involved.

The zero-day flaw is now fixed with software updates, and organizations are advised to apply fixes immediately, as there are no workarounds that address this bug.

Attackers craft a connection for admin access

According to Cisco, the vulnerability stems from improper validation during the authentication process used to establish control connections between SD-WAN devices. It said an attacker could exploit the issue remotely by sending crafted control connection requests to a targeted system.

Successful exploitation would allow the attacker to bypass authentication, establish themselves as trusted peers, and obtain administrative privileges to the affected device.

“A successful exploit could allow the attacker to log in to an affected Cisco Catalyst SD-WAN Controller as an internal, high-privileged, non-root user account,” Cisco said. “Using this account, the attacker could access NETCONF, which would then allow the attacker to manipulate network configuration for the SD-WAN fabric.”

The issue, tracked as CVE-2026-20182, received a max-severity rating of CVSS 10.0. The company said that the issue is configuration-independent, meaning vulnerable systems remain exposed regardless of deployment-specific settings.

Cisco credited Stephen Fewer, Senior Principal Security Researcher, and Jonah Burgess, Senior Security Researcher, both of Rapid7, for discovering and reporting the bug.

Active exploitation kicks patching into high gear

Cisco disclosed being aware of exploitation attempts in May, urging customers to upgrade to a fixed release immediately.

Shortly after the disclosure, the flaw was added to the Cybersecurity and Infrastructure Security Agency’s (CISA) known exploited vulnerabilities catalog (KEV). “Adhere to the applicable BOD 22-01 guidance for cloud services or discontinue use of the product if mitigations are not available,” it said.

The US cybersecurity watchdog has given federal executive agencies until May 17th to patch the flaw.

“Customers are advised to upgrade to an appropriate fixed software release,” Fewer and Burgess said in a blog post, citing fixed software releases that address the flaw in versions 20.9 through 26.1.1. “There are no workarounds that address this vulnerability.”

Alongside software fixes, Cisco published operational guidance to help organizations identify potentially malicious control connections.

The advisory instructed admins to review existing control peering relationships, using the “show control connections” command, and validate all connected peers, particularly those associated with SD-WAN Manager systems.

Organizations that suspect compromise are being advised to contact Cisco Technical Assistance Center support and collect diagnostic information from affected devices.

The article originally appeared on CSO.

Cisco Systems delivered a blowout Q3 FY2026 performance that surpassed even the most optimistic expectations, posting record revenue of $15.8 billion, up 12% year-over-year, with product revenue surging 17%. The networking giant’s momentum is accelerating across multiple fronts, driven by demand for AI infrastructure, campus modernization, and strategic silicon investments.

Here are five key takeaways from what CEO Chuck Robbins described as a quarter when Cisco’s “technology is more relevant than ever in the AI era.”

1. AI infrastructure orders skyrocket to $9 billion for FY26

Cisco significantly raised its AI infrastructure order expectations for hyperscalers to $9 billion for fiscal year 2026, nearly double the company’s previous $5 billion forecast. The company took in $1.9 billion in AI infrastructure orders from hyperscalers in Q3 alone, with the year-to-date total reaching $5.3 billion before entering the final quarter. (Related story: Cisco announced layoffs along with its Q3 results)

“Given the strong demand, we now expect to take AI infrastructure orders of approximately $9 billion from hyperscalers in FY ’26, 4.5x our FY ’25 total,” Robbins announced on the earnings call. This explosive growth is driven by both Silicon One systems and Acacia coherent pluggable optics. The Acacia business posted its strongest quarter ever, with over $1 billion in orders, and is tracking to grow over 200% year-over-year.

Cisco secured five new hyperscaler design wins in Q3, including the company’s first two wins for Silicon One P200-powered systems for “scale across” use cases. “During Q3, we were awarded two different hyperscalers’ P200 design wins, which is our product that is used for scale across applications,” Robbins said, adding that a third P200 scale-across design win came in early Q4. The company has now shipped over 750,000 400-gig and 40,000 800-gig coherent pluggable optics, which Cisco believes “far exceeds the next largest supplier shipments for both speeds.”

2. Broad-based demand drives 35% order growth

Total product orders grew an impressive 35% year-over-year, with strength across customer segments and geographies. “Overall, total product orders grew 35% year-over-year. Excluding hyperscaler orders, which grew by triple digits, product orders were up 19% year-over-year, demonstrating the continued broad-based demand we see for our technology globally,” Robbins reported.

Enterprise product orders grew 18%, public sector orders jumped 27%, and service provider and cloud orders accelerated 105%. Networking product orders grew more than 50% in Q3, marking the seventh consecutive quarter of double-digit growth for Cisco’s networking portfolio. Campus networking posted record orders, up more than 25% year-over-year, with wireless orders reaching their highest level ever, with 40%+ growth.

CFO Mark Patterson addressed investor concerns about demand pull-forward: “I think that it’s reasonable to assume that there is some level of pull ahead into Q3. I do think it’s very difficult to speculate exactly how much, but we believe it was a very modest amount.” Patterson cited three key data points: price increases accounted for approximately 4-5 points of order acceleration; the Q4 pipeline pull-forward was consistent with historical patterns; and “the pipeline is very healthy, very good year-over-year growth.”

3. Silicon One becomes a massive competitive differentiator

Cisco’s long-term investment in developing its own Silicon One chips is paying enormous dividends, with roughly half of the company’s AI infrastructure revenue coming from Silicon One-based systems. “I’ve said repeatedly on these calls over the last couple of years that as we move to the future, if you don’t have silicon, you’re going to struggle to be relevant to the hyperscalers. And I think that’s what we’re seeing,” Robbins emphasized.

Beyond revenue generation, Silicon One gives Cisco significantly greater control over its supply chain — a critical advantage in a constrained component environment. “The fact that we design our own silicon really gives us greater control end-to-end. I mean, the fact that we’re directly managing wafers, substrates, assembly, and test really gives us much more control over the supply chain,” Patterson explained.

The company has secured silicon supply through the calendar year 2026, with negotiations underway for 2027. While competitors face potential decommits due to supply constraints, Patterson reported: “I just want to reiterate what Chuck said: We did not see any decommits in the quarter.” This strategic control allows Cisco to commit to hyperscalers with confidence, while competitors struggle with dependencies on merchant silicon.

4. Campus modernization cycle just beginning

Cisco is in the early stages of what it believes will be a “multiyear, multibillion-dollar campus refresh opportunity” driven by AI workloads and rising network traffic. “Research conducted recently with around 3,500 technology leaders across global enterprises confirms increased urgency to modernize campus and branch networks,” Robbins said, adding that “with traffic across these networks expected to increase 3x over the next 3 years because of AI, 93% of respondents are accelerating their network modernization plans.”

Wi-Fi 7 adoption is accelerating rapidly, with Robbins reporting “strong double-digit sequential growth in orders for Wi-Fi 7, making up half of the wireless mix in Q3.” Cisco’s Unified Edge solution is gaining traction, as a single enterprise deal secured over 1,200 units, bringing together compute, networking, security, storage, and software to run AI applications at the edge.

The industrial IoT portfolio posted its strongest quarter ever in Q3, marking eight consecutive quarters of double-digit growth. “We expect this demand to continue with the onshoring of manufacturing to the United States and as agentic and physical AI are expected to drive massive increases in network traffic,” Robbins stated. He noted that customers are preparing for “inferencing and agentic applications” where “the network is incredibly important, and moving the bits around with low latency is super important.”

5. Security portfolio turning the corner

After several quarters of challenges, Cisco’s security business is finally showing meaningful improvement, with double-digit order growth in firewalls and continued strength in new products. “In Q3, our core security portfolio, excluding Splunk, saw double-digit order growth across new and refreshed products, with strong double-digit year-over-year growth in firewalls,” Robbins reported.

The company’s new security products, including Secure Access, XDR, Hypershield, and AI Defense, attracted more than 1,000 new customers in Q3, bringing the total to approximately 5,000 since launch. “I think last call, I said we would exit this fiscal year approaching double-digit revenue growth on the traditional organic Cisco security portfolio. And I think we’re heading in that direction, and I feel good about us actually making that happen,” Robbins said.

Cisco is positioning itself for AI-driven security threats through participation in Project Glasswing, Anthropic’s Claude Mythos preview model testing, and OpenAI’s Trusted Access for Cyber program. “AI is accelerating the pace of innovation for security defenders and adversaries, and we are innovating with speed and scale to help create an asymmetrical advantage for defenders,” Robbins said. The company announced major security innovations, including DefenseClaw for safely deploying agents and Zero Trust Access for AI agents, as well as planned acquisitions of Galileo and Astrix for agentic identity and access management.

Recommendations for Cisco customers

• Assess your AI readiness now: With 93% of enterprises accelerating network modernization and campus traffic expected to triple over the next three years, customers should conduct infrastructure assessments immediately to identify bottlenecks and capacity constraints before they become critical. The growing deployment of inferencing and agentic AI applications requires low-latency, high-capacity networking that legacy infrastructure cannot support.
• Prioritize security modernization: The emergence of AI-powered security threats creates significant risk for organizations running unpatched or end-of-support equipment. Customers should audit their infrastructure for technology beyond the end of support and develop migration plans to Cisco’s new security portfolio, including Hypershield, XDR, and AI Defense capabilities.
• Plan campus refresh cycles around Wi-Fi 7 and next-gen switching: With Wi-Fi 7 already accounting for half of Cisco’s wireless mix, and next-generation switching and routing ramping faster than in prior product launches, customers should align campus refresh initiatives with these platforms to maximize performance and longevity. The campus modernization cycle is just beginning, giving early movers a competitive advantage in supporting AI workloads.
• Lock in supply and pricing now: While Cisco’s Silicon One strategy offers better supply chain control than competitors’, memory constraints and component shortages remain industry-wide challenges. Customers with major infrastructure projects should engage Cisco early to secure supply commitments, particularly for AI infrastructure, high-density switching, and advanced optics, where lead times may be longer. The company has implemented pricing actions in response to rising memory costs, making current pricing potentially more favorable than future quotes.
• Explore edge AI and industrial IoT opportunities: Cisco’s Unified Edge solution and industrial IoT portfolio are experiencing exceptional growth as organizations deploy AI applications where data is generated, and decisions are made. Manufacturers and enterprises with distributed operations should evaluate these platforms for edge computing, particularly given U.S. manufacturing onshoring trends and the emergence of agentic and physical AI applications.

For most of my technology career spanning more than two decades, software architecture was primarily seen as a technical discipline — concerned with system design, scalability and integration patterns. Architecture reviews happened after strategy decisions were made, and success was often measured by whether systems operated as per the functional requirements and performed reliably under load.

Architecture operated quietly in the background. It guided structure, while governance lived in policy documents and delivery followed predictable engineering processes.

That model is no longer sufficient. Software development is entering a phase that many enterprises did not fully anticipate. Today, the most important architectural questions are no longer technical alone. They are organizational, operational and increasingly regulatory. As AI becomes embedded across the software development lifecycle, architecture is evolving from system design practice into something far more consequential — the mechanism through which enterprises maintain control, trust and accountability in automated environments. This shift is more visible in regulated industries, where innovation must move quickly but failure is measured not only in downtime, but in regulatory exposure and loss of institutional trust.

From what I’m seeing across enterprise programs today, architecture matters more than ever because software development itself is fundamentally changing. I see a clear pattern emerging where software architecture matters more than ever because it has become the foundation of enterprise control and trust.

The quiet transformation of the software development lifecycle

Unlike past technology revolutions, the AI transformation of software development is not arriving through a single disruptive moment. It is unfolding quietly inside everyday workflows.

Engineers are spending less time writing software from scratch and more time supervising systems to generate, configure and evolve software automatically. Development has moved from construction toward orchestration with the adoption of AI assistants to generate code snippets. Testing frameworks are becoming more automated, and deployment pipelines are making optimization decisions independently.

We are also beginning to see AI agents move beyond assisting developers toward replacing parts of the traditional Integrated Development Environment itself. Tools powered by large language models — such as Anthropic’s Claude — are increasingly capable of reasoning across entire repositories, proposing architectural changes, executing multi-step development tasks and interacting directly with development workflows rather than functioning merely as coding autocomplete tools.

This evolution fundamentally alters the SDLC (Software Development Life Cycle). Development is no longer a sequence of controlled human decisions; it is becoming a collaboration between people, platforms and intelligent systems.

Many organizations still describe this evolution as productivity improvement. I believe that this framing misses the deeper implication where the real transformation is not speed — it is control.

This evolution aligns with the industry’s broader shift toward platform engineering and autonomous delivery models discussed in Thoughtworks Insights, which identifies AI-assisted development as a structural change in how software is produced rather than simply a productivity enhancement.

AI-assisted development introduces a new operating model

AI-assisted software development represents more than automation. In my opinion, it introduces a new operating model where development workflows themselves become intelligent systems. The SDLC transitions from linear execution to continuous adaptation. But autonomy without structure creates risk.

Architecture becomes the mechanism that ensures autonomy operates safely within enterprise intent. The question facing CIOs is no longer how fast we can deliver software. It is how do we trust systems that increasingly build themselves?

In regulated industries, this question carries profound implications. Autonomous development without architectural guardrails can introduce compliance gaps, security risks and operational instability at machine speed.

The leadership challenge: Trust over velocity

For years, technology leadership focused on accelerating delivery. Agile, DevOps and cloud adoption are all optimized for speed. AI makes all three easier to achieve.

When development accelerates faster than governance processes, organizations face a dangerous gap. Software may reach production before enterprises fully understand how it behaves, how decisions were derived or whether architectural standards were followed. I believe that the issue is not that AI produces poor software. The real issue is that enterprise oversight mechanisms were never designed for autonomous development velocity.

The importance of trust in technology systems is now reflected across global initiatives focused on responsible digital transformation. Collaborative efforts such as the Global Trust Challenge highlight the growing recognition that AI innovation must be paired with measurable trust frameworks spanning governance, ethics, security and accountability.

With AI-Assisted software development, I am increasingly seeing that the leadership challenge is no longer delivery velocity — it is to gain trust over what is being delivered. There are various aspects of software development that I see are increasingly becoming a concern for senior leadership, especially in the regulated industry.

• Protection of sensitive data
• Continuous compliance assurance
• Explainability of automated decisions
• Operational resilience amid autonomous change
• Clear accountability when AI-generated systems fail

In regulated industries, trust is inseparable from technology operations. Regulatory compliance, data protection, operational resilience and auditability cannot be retrofitted after software is created. AI compresses development timelines so dramatically that traditional governance checkpoints become ineffective. Manual reviews cannot scale to match machine-generated output.

 The central question for technology leaders is shifting from “How fast can we deliver?” to “Can we trust what is being delivered?”

Architecture as the enterprise control system

Historically, architecture functioned as a blueprint — describing how systems should be built. In AI-driven software development, architecture is evolving from providing blueprints to being the control system. I am increasingly seeing that the role of architecture is shifting to define what AI systems can access, how decisions are validated and how risk is constrained before problems emerge.

Instead of reviewing every implementation, architecture establishes boundaries within which innovation can safely occur. Rather than slowing innovation, architectural governance enables safe autonomy. Developers and AI systems can move faster precisely because constraints are already designed into the environment.

This shift marks the emergence of what I see as the architecture-led enterprise — organizations where architecture aligns innovation, risk management and strategy simultaneously.

Trust will become the real competitive advantage

Over the next decade, AI will make software creation cheaper, faster and more accessible than ever before. Feature velocity will no longer differentiate organizations. It will be how organizations maintain trust. Customers, regulators and partners will favor enterprises that can demonstrate:

• Predictable system behavior
• Transparent decision processes
• Secure handling of data
• Operational resilience
• Responsible AI adoption

One of the most significant changes I observe is that architects are no longer designing only systems — they are designing decision environments.

In AI-assisted development, architects increasingly define:

• Approved architectural patterns that guide AI-generated solutions
• Platform constraints that prevent unsafe implementations
• Reference models that embed regulatory expectations
• Engineering workflows that enforce organizational standards automatically

In my view, the goal shouldn’t be to limit developers from using AI tools. The goal should be to ensure that, regardless of who — or what — produces the software, outcomes remain aligned with enterprise intent.

Architecture becomes the invisible structure shaping thousands of development decisions every day.

The changing role of the CIO and chief architect

AI is redefining technology leadership itself.

Historically, CIOs and chief architects focused on modernization initiatives, platform adoption and delivery performance. AI has been redefining technology leadership. Today, leadership conversations increasingly revolve around institutional trust.

Executives are increasingly asking:

• Can we trust AI-generated code operating in production?
• Do we understand how automated decisions impact customers?
• Are we scaling innovation faster than our ability to govern it?
• Is accountability preserved when development becomes partially autonomous?

These questions elevate architecture into strategic leadership territory. The modern CIO is not merely overseeing technology delivery but stewarding an ecosystem of intelligent systems. Architects, in turn, are evolving from project advisors into organizational designers who shape how technology decisions happen across the enterprise.

Architecture is becoming the connective tissue linking innovation, risk management and business strategy. Enterprises with mature architecture practices are discovering they can adopt AI faster because foundational decisions — security, resilience, integration and governance are already institutionalized. Organizations lacking architectural discipline often slow down despite advanced tooling, constrained by uncertainty, risk concerns or operational fragility.

What differentiates organizations now is how safely they can scale innovation.

Final thoughts

The competitive advantage in AI-driven development is shifting away from feature velocity toward architectural maturity.

Humans, machines and automated processes are all contributing to software delivery. Architecture ensures they operate within shared principles. AI may accelerate how software is built, but architecture determines whether that software can be trusted at scale.

Much of the industry conversation around AI focuses on models, tools and productivity gains. Those elements matter, but they are not the defining challenge for enterprise leaders. The real challenge is governance and trust.

I believe that the organizations that succeed in AI-assisted development will not simply adopt better models or faster tools. They will rethink architecture as a strategic leadership function one that aligns technology execution with enterprise governance, risk management and long-term strategy.

For CIOs navigating AI-driven transformation, architecture is no longer optional. It is what makes innovation sustainable.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

CIOs and other IT leaders are experiencing a make-or-break moment as they face major new expectations in their roles, including the ability to lead change and build AI-ready teams.

IT leadership experts have been talking for years about the need for CIOs to focus on business results, in addition to providing technical expertise and keeping IT systems running. Those expectations remain, with 79% of IT leaders surveyed by Deloitte listing driving business outcomes as their top priority, a change from back-office upkeep to creating enterprise value.

But the 2026 Global Leadership Technology Study from Deloitte, based on surveys of more than 660 senior IT executives, finds new and expanding expectations for CIOs and other IT leaders, including AI and data fluency, change leadership capabilities, and the ability to build AI teams.

To fulfill those growing expectations, IT leaders also face significant headwinds. While 81% of those surveyed say they’re confident in their organization’s ability to deploy and govern AI, 75% also believe their operating models and processes must change within the next 12 to 18 months to drive greater value.

The numbers suggest that CIO ambitions for AI are outpacing capabilities, while they will increasingly be judged on their ability to drive business transformation and successful AI initiatives, says Anjali Shaikh, managing director of Deloitte Consulting and leader of the Deloitte global CIO and US tech executive programs.

“AI is such a CEO- and board-strategic priority,” she says. “They’re looking at the CIO to really help think about everything across the board, from process to talent implications, operating models, and governance risk.”

Shortage of AI experts

Building expert AI teams may be one of the most difficult expectations to meet. About a quarter of IT leaders in Deloitte’s survey named a shortage of skilled talent as a top challenge, just behind data quality and security and privacy concerns. Shaikh was surprised that the percentage of IT leaders concerned about a skills gap was as low as it was. For CIO.com’s 2026 State of the CIO survey, 40% of IT leaders identified a lack of in-house talent as their top challenge in implementing AI strategies during the past year.

Shaikh advises CIOs to look for AI expertise everywhere they can, whether it’s hiring new employees with AI experience, retraining current employees to build AI skills, or partnering with vendors and other providers to bring in outside experts. CIOs should also strengthen relationships with their organizations’ chief HR officers to fill AI needs, she recommends.

IT leaders are now expected to both build AI-ready teams and lead their organizations through the changes needed to embrace AI, Shaikh notes.

“The limiting factor increasingly isn’t whether people are using the technology, it’s shifting from hiring AI specialists to building AI-ready organizations, and I am seeing more and more CIOs get moved into the conversation,” she says. “How are you going to uplevel the organization’s AI fluency?”

Technical expertise is not enough to be a technology leader today, Shaikh says.

“What separates leading organizations and leading CIOs is, can you put a team together that can understand how to redesign work, how to rethink decision-making, and understand what a digital workforce and human workforce looks like together?” she adds.

Evolution always

The CIO’s role is one of constant evolution, adds Matt Ausman, CIO at scanning technology provider Zebra Technologies.

“One thing I’ve realized is a CIO today cannot simply be a technologist,” he says. “We must be a pathfinder, tracing a new path in an uncharted field, guided by experience from past technology shifts like the internet and the cloud. We must also be an evangelist and a C-suite advocate, championing the vision and securing the buy-in necessary for true transformation.”

Ausman’s approach is to focus on a few key priorities: centralizing governance, federating innovation, and measuring value. In addition, CIOs must be collaborators who bring together teams from HR, marketing, sales, engineering, and other business units, he says.

“The outcomes expected from CIOs cannot be created from IT alone,” he says. “Value creation requires people, process, and technology. The people and process transformation largely comes from within the teams of other C-suite leaders.”

At the same time, the CIO and IT organization need an equal seat at the table to help push broader teams through organizational transformations, he says. “That’s a shift that has been occurring for a few years but has been amplified with the focus on AI,” Ausman adds.

The new expectations for CIOs noted in the Deloitte report feel more fundamental than a few expanded responsibilities, says Jean-Philippe Avelange, CIO at managed networking and cloud provider Expereo.

In the past, CIOs were measured on systems delivered and IT uptime, but they’re now evaluated on how technology enables businesses to make different decisions, he says.

“What is changing is the unit of measure,” he says. “That repositions the role from running systems to shaping decisions, from cost center to capability builder. From where I sit, that direction is real, and it is happening regardless of how comfortable any one of us is with it.”

Building capable teams will be one of the hardest mandates for CIOs facing new expectations, and the issue goes beyond a training problem, he adds.

“It is keeping psychological safety intact while the pressure to deploy AI everywhere collides with a very legitimate fear of being replaced,” Avelange says. “Top-down adoption targets like ‘100% of engineers using AI by Q3’ tend to produce compliance gaming more than real outcomes.”

CIOs should focus more on augmenting jobs with AI instead of replacing employees with it, he recommends. IT leaders can improve AI outcomes by giving teams time to experiment, not just access to tools, and measuring velocity, quality, and decision speed instead of use rates, he adds.

“When this is done well, organizations often hire faster because each engineer becomes more valuable,” he says. “When it is not, adoption theater and a quietly cynical team are the more likely outcome.”

The next time someone on your team says, ‘hire an AI engineer,’ stop the conversation.

That title is too vague because it fails to account for critical differences in engineering strengths. Instead, companies need to decide specifically what they need. Is it someone to rapidly prototype AI solutions? Or someone to build the solution that makes it ready for production? Or someone to design the supporting capabilities and infrastructure to scale it? These are all different skills and require different assessments during the hiring process.

But here’s where companies also fall short. Assessing skills is hard and assessments, as we know them, are broken when it comes to AI. They’re misaligned with what AI roles actually demand. That misalignment is what I call the AI assessment gap.

Where the gap lives

Most technical assessments were built for a pre-AI world: Coding proficiency, algorithms, deterministic system design. These are skills tests. They confirm that an engineer can do the work. But they don’t tell you whether that engineer has the technical taste to make the right decisions when building, scaling or deploying AI systems in production.

In conversations with enterprise engineering leaders, we’re hearing that candidates are now running AI agents during live interviews, getting textbook-perfect answers fed to them in real time. If your assessment can be passed by an AI whispering in someone’s ear, it was never testing for the right thing. Skills can be faked or augmented. Taste can’t.

To see what this looks like, consider this scenario: An enterprise needs someone with deep experience in a specific data platform. A candidate passes the data engineering assessment. They get to the client interview, and the hiring manager says: ‘Tell me about a time you had to make a hard tradeoff in designing a streaming architecture.’ The candidate defines every concept involved. They don’t have the taste to explain why one approach would be dramatically better than another for a specific context. They’re out.

This happens because most assessment pipelines only test for skills: Can they code, understand the fundamentals? Nobody is systematically testing for technical taste: Can this person make better-than-default decisions about architecture, tooling and approach? That question only surfaces once someone with real experience asks it. By then, everyone has wasted time and the role is still open.

Traditional job postings compound the problem by filtering for ‘5+ years of AI experience,’ which screens out strong candidates because the category itself is only a few years old. What matters at the AI layer isn’t tenure. It’s the depth and specificity of what someone has built, deployed or scaled in production. Meanwhile, seniority at the foundational role level still matters in the ways it always has: A senior engineer brings architectural judgment that can’t be shortcut. The mistake is applying years-of-experience filters to the AI layers, where the work hasn’t existed long enough for tenure to be a meaningful signal.

One of the most telling signals of a broken assessment process: When stakeholders simultaneously complain that assessments are too hard and too easy. That’s not a calibration problem. It means the assessments aren’t measuring the right things in the first place. They’re testing for skills when they should be testing for taste.

Start with the work, not the title

To close the AI assessment gap, decompose the problem before you assess and decompose the need across the dimensions that actually determine whether someone can do the job. For example:

Dimension	The Question	What It Determines	How You Evaluate
Role	What technical domain does the work live in?	Foundational skills and stack (e.g., backend engineer, Python, PostgreSQL)	Skills assessment: Project-based or simulation-based filter that confirms core engineering competency
Seniority	What level of judgment and autonomy does this work require?	Engineering maturity, depth of technical taste, ability to operate under ambiguity	Experience depth at the role level: Years of practice in the domain, complexity of systems designed and shipped
AI Engagement Pattern	How will this person engage with AI systems?	The specific technical taste required (e.g., Prototyper needs taste for sensing value; Builder needs taste for architecture and integration decisions; Scaler needs taste for performance, governance and risk tradeoffs)	Applied assessments: Not ‘define RAG’ but ‘given this use case, which approach would you choose and why?’ Testing for tradeoff reasoning, not terminology

This decomposition replaces the single job description with a structured picture of what you actually need. It also immediately reveals whether you’re looking for one person or a team. If the project requires rapid prototyping to find value and then a production build, you probably need engineers with different profiles–not one ‘AI engineer’ who’s supposed to do both.

Three things most enterprises get wrong

1. They test for skills when they should test for taste. Most assessments confirm that an engineer can write code and define concepts. They don’t test whether that engineer can make the architectural and tooling decisions that actually determine project success. An engineer who knows what agentic search is and an engineer who knows when agentic search is the right choice for a specific problem are two completely different hires. The first passes your skills test. The second delivers in production.

2. They conflate skills with experience. A skills assessment tells you if someone can do the work. An experience validation tells you if someone has done the work in the specific context the job demands. These require completely different evaluation methods. When companies try to test both with a single instrument, they get the ‘too hard and too easy’ paradox: The assessment is simultaneously screening out competent people and letting through candidates who can’t perform. Seniority and years of experience are meaningful at the role level, where 10 years of backend engineering builds real architectural judgment and compounds technical taste. They’re much less meaningful at the AI engagement layer, where the work itself is only a few years old and depth of hands-on exposure matters more than calendar time.

3. They treat assessment as a snapshot. The traditional model is a one-time gate: Pass or fail, in or out. In an AI world where skills are evolving monthly, that approach breaks down fast. Six months ago, almost nobody was shipping production code with agentic tools like Claude Code. Model Context Protocol, which lets AI systems plug into enterprise tools and data sources, was barely on anyone’s radar. Now enterprises are hiring for these skills specifically. Six months from now, the list will change again.

That means an assessment built in January is already partially stale by June. Companies that treat assessment as a living system, continuously updated by performance signals from real engagements, will consistently field better talent than those running the same tests they built a year ago.

The reskilling imperative

The reality is, there is no way to close this gap through hiring alone. The supply of engineers who already have the technical taste for AI work is a tiny fraction of what the market demands.  For example, since the launch of ChatGPT in 2022, demand for roles that require more analytical, technical or creative work has increased by 20%.

Which means enterprises have to reskill and upskill existing workforces. And without a targeted approach mapped to actual needs, AI upskilling efforts often fail, leaving employees unsupported and initiatives stalled.

This is where the multi-dimensional model pays off beyond hiring. The same framework that powers your talent acquisition also powers your training strategy. Assessment results don’t just filter candidates in or out. They generate a heat map of where your workforce is strong and where it’s thin, across every dimension: Role competency, seniority depth and the specific technical taste required for prototyping, building or scaling AI systems. That heat map becomes your training roadmap.

Most companies skip this entirely and jump straight to ‘let’s buy an AI training program.’ Without that foundation, even the best training program is solving the wrong problem.

Ever ready

In the world of AI, the most critical skill might be knowing that you don’t and can’t possibly know everything. Or even what’s coming next. The roles we need today will look different in six months. The skills taxonomies we build now will need constant revision. The assessments we deploy this quarter will need recalibration by next quarter.

Companies that accept this reality and build nimble, multi-dimensional approaches to talent assessment will find something valuable: The technical taste they need already exists in their workforce, hiding behind outdated job descriptions and misaligned tests. CIOs must actively audit these descriptions to eliminate the traditional experience filters that mask the latent talent already sitting on their teams.  The others will keep posting for ‘AI engineers’ and wondering why nobody who gets hired can actually do the job.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Every CIO I talk to — and I talk to a lot of them — agrees that skills-first hiring makes sense. And with AI now embedded in nearly every stage of the hiring process, from resume screening to candidate matching, many assume the technology will finally make it happen at scale.

It won’t. AI can accelerate hiring decisions, but it can’t fix the underlying systems that power those decisions.

Despite initial progress in removing college degree requirements from job postings, many organizations are still getting it wrong — and AI is giving them new ways to get it wrong faster. Agreeing on a principle isn’t the same as operationalizing one. Even when there’s a skills-first hiring strategy in place, execution fails if IT, HR and business leaders aren’t aligned on outcomes, accountability and measurement. When AI screening tools are layered on top of misaligned systems, the result isn’t smarter hiring; it’s automated bias with a veneer of objectivity.

Why skills-first hiring became a buzzword

The idea of prioritizing skills in hiring decisions isn’t new. Competency-based hiring has been discussed in talent management circles since the 1970s. Over the last two decades, the growing technology skills gap, the explosion of non-traditional learning pathways and the broader recognition of “degree inflation” pushed skills-based hiring into the mainstream. Large employers publicly dropped degree requirements. States followed. Everyone was buzzing about skills-first hiring.

But buzz doesn’t change systems. Data from Indeed showed a decrease in job postings with college degree requirements between 2019 to 2024, but by November 2025, the number swung back up, nearly erasing the gains of the previous five years. 

Meanwhile, the skills that matter most now — prompt engineering, AI tool fluency, the ability to scope and complete AI-augmented projects — are being developed outside traditional degree programs. That makes degrees an even worse proxy for career readiness.

Announcing that an organization is “skills-first” without redesigning the infrastructure that surrounds hiring — job descriptions, applicant screening, recruiter training, interview rubrics and onboarding frameworks — doesn’t change practices. A recent survey by the University of Phoenix found that 69% of hiring decision makers believe there’s still too much focus on college degrees, with little clarity on what they should evaluate instead.

The 3 most common failure points

From my experience in working with CIOs on their entry-level talent pipelines, skills-first initiatives tend to break down in one or more of these places: job descriptions, screening tools and internal skepticism.

First, take job descriptions. Hiring managers tend to default to historical templates — pasting in degree requirements and years-of-experience thresholds that were never validated against actual job performance and are even less relevant with AI in the mix.

Second, screening tools. Nearly 90 percent of companies are using some form of AI to screen candidates, expecting greater efficiency and less bias. But AI screening tools learn from existing hiring data — which, if biased, just means that bias is now automated. Patterns in successful candidates’ backgrounds get baked into future decisions, except now, these decisions appear “data-driven” and neutral instead of more obviously predicated on certain hiring managers’ preference for college graduates.

The third failure point is internal skepticism — and the training gap that feeds it. According to the survey by the University of Phoenix, one in four non-HR managers receives no training before interviewing job candidates, even when the final hiring decision is theirs. Without shared definitions of what “skills-first” means and clear accountability, the initiative collapses under the weight of individual discretion.

What CIOs see that others miss

CIOs are often closer to the consequences of a bad hire than anyone else in the C-suite. When a cybersecurity analyst freezes during an incident response, the CIO gets a front-row view of the damage a skills gap can cause.

CIOs are also watching AI redefine what “qualified” looks like in real time. The engineer who deploys an agentic AI system to automate monitoring, or the analyst who chains multiple AI tools into a custom workflow — these people deliver outsized value, and their qualifications often look nothing like what a traditional job description demands.

And CIOs have a keen understanding of issues with tech talent pipelines. Projects slip while niche technical roles sit open for six months or more, even as candidates from rigorous programs — people with the specific skills for the job — are filtered out.

How successful CIOs operationalize skills-first hiring

Successful CIOs get specific. They work with their teams to define exactly which skills matter for each role — and they validate those definitions against the performance of current, thriving employees.

Should that taxonomy include demonstrated experience with AI tools and platforms: Has the candidate built or deployed an AI agent? Can they work across multiple AI tools? Have they completed projects requiring AI-augmented problem-solving? These concrete, observable skills predict performance far more than a degree ever could.

Second, they establish shared metrics across IT and HR. Organizations that get this right track 90-day performance reviews, first-year retention and promotion velocity alongside traditional recruiting metrics. In its New Collar Program with Sentara Healthcare, TEKsystems worked with company leaders to fill open big data positions through a skills-based cohort model and achieved 80% retention one-year post-training.

Third, these CIOs build direct relationships with employer-aligned training pipelines before a role opens. Bank of America invested nearly $40 million in workforce development initiatives in 2025 alone and partnered with more than 600 nonprofits across the US.

At Per Scholas, our head of IT, Tyrone Washington, makes it clear that while technical skills might get you through the door, it’s “smart skills” — discernment, emotional intelligence, complex problem-solving and agility — that build a career in an AI-driven landscape.

What the data shows

Skills-first hiring, when paired with structured onboarding and development pathways, is not just a talent acquisition strategy — it’s a retention strategy. And higher retention contributes directly to the bottom line, as the fully loaded cost of replacing a technical employee ranges from one to two times their annual salary.

In one employer partnership deploying skills-trained talent, a TEKsystems client came out $238,000 ahead in the first year after accounting for program costs, with a projected annual return of over $1.2 million. IT leaders reported that skills-trained talent becomes productive measurably faster than early-career hires from conventional pipelines.

How CIOs can lead the Shift — even without owning HR

CIOs who are moving the needle are piloting skills-based hiring for one or two roles, tracking outcomes rigorously and using that data to make the case for broader adoption. They’re building external partnerships before they need them. Bank of America, a Per Scholas long-term partner, knows that our graduates are team players, lifelong learners and motivated employees; our graduates’ certifications (through CompTIA and Google) validates that they have the technical know-how.

Every quarter that technical roles sit open has a measurable impact on project delivery, team capacity and competitive positioning. Surfacing these costs — backed by data — is something CIOs are uniquely positioned to do.

The bottom line

Skills-first hiring will remain a well-intentioned abstraction unless CIOs treat it as an operating model — one that reflects how AI is reshaping the skills organizations need.

The candidates who can demonstrate hands-on experience in building and deploying AI agents, integrating multiple AI tools into a workflow or evaluating when AI can help are the ones who will drive value. But they’ll keep getting filtered out unless CIOs get specific about skill definitions, align IT and HR around shared metrics, and build employer-aligned pipelines. Bank of America and TEKsystems didn’t achieve their results by endorsing a principle — they achieved them by building systems.

Luckily, building systems is something that CIOs know how to do well.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Waiting for your vendor to fix a program isn’t a strategy. It’s a cost, accumulating quietly while everyone in the room maintains the fiction that the process is working.

I’ve been in both rooms. The room where the client already knows something is wrong and needs the language and the evidence to act, and the room where the client doesn’t know yet. The program feels manageable, the vendor is professional, the steering committee meetings run on time, and the warning signs are sitting in plain sight waiting for someone to name them.

That second room is the more important one. Because the window to act is still open. And most clients don’t move until it’s started to close.

Warning signs most clients miss appear in design

The earliest signal is rarely a missed milestone or a failed deliverable. It appears in language. When the phrase “path to green” starts appearing in status reports and steering committee decks, the program has already accepted it’s not green. It’s shifted from managing execution to managing the narrative.

Watch what the steering committee is actually doing. If it’s consistently hearing about what happened last month rather than what’s forecast for next month, leadership has been converted from a decision-making body into an audience. The vendor controls the agenda, the framing, and the cadence of what gets surfaced.

The most serious signal is when a program sponsor hears about material issues from their own direct reports that the vendor hasn’t raised in the room. That’s not a communication gap but a calculated decision about what leadership is ready to hear. When that pattern appears in SAP, Oracle, or Salesforce programs, the trust that makes the governance model function has already eroded.

When you see these signals, don’t wait for the next steering committee. Start demanding data that can be independently corroborated. Ask the vendor to forecast, not report. If they can’t tell you where the program will be in 60 days, they’re managing your perception, not your program.

Your master conductor has a conflict of interest you’re not addressing

A pattern I’ve seen consistently across multi-vendor programs involving Accenture, Deloitte, PwC, and others is the master conductor, or program integration coordinator, is quick to name client’s gaps, other vendors’ shortcomings, and third-party dependencies running behind. What they almost never do is name their own firm’s failures with the same directness in the same room.

That’s not a personality issue but a structural conflict. The firm serving as master conductor is delivering against its own statement of work (SOW), and the governance position gives them access to information, reporting authority, and narrative control they’ll use to, consciously or not, protect their own delivery track.

This is why I advise clients to treat the master conductor and program integration coordinator role as structurally separate from the vendor delivery role. That means a, entirely separate firm, an independent integrator with no delivery stake in the outcome. In practice, it’s more often a designated individual or a group within the project management or transformation office carved from one of the existing vendors, reporting directly to the client and accountable to the steering committee, not to their own firm’s engagement leadership.

There’s no true firewall in that model, but there’s a behavioral test. Watch what that role or team does with information that reflects badly on their own firm. Do they surface it or escalate it with the same urgency they bring to client gaps? Do they forecast problems on their own track, or only on everyone else’s?

A master conductor who’ll escalate failures that implicate their own delivery team is doing the job. One who only calls out the client and the other vendors is protecting the engagement.

Before the next SOW is signed, make it structural. Define the master conductor role separately from the delivery role, name the individual or team, set the reporting line directly to the client, and use the behavioral test to determine whether the role is being performed or merely filled.

Waiting isn’t neutral

The financial cost of waiting is more specific than most clients realize. In a multi-vendor environment where two or three system integrators are billing against active SOWs, every month of schedule extension carries a material cost, potentially millions to tens of millions of dollars per firm, not because scope expanded, but because governance didn’t hold the timeline.

The commercial exposure appears even earlier. When scope boundaries are unclear and the integrated plan is unstable, vendors have no reliable baseline to price against. The result is predictable: a significant spread between a time-and-materials estimate and a fixed fee quote for the same scope. That spread is not a pricing difference. It’s the vendor converting your governance uncertainty into their contract protection. The client absorbs it either way.

What makes the waiting feel reasonable is the vendor’s day-to-day team is usually professional and working hard. So the problem is authority and incentive, not effort. The program manager running the engagement can’t authorize additional resources nor commit spend across organizational lines. Their job is to manage the relationship, protect their firm’s margin, and keep the engagement profitable. Fixing your program isn’t the same job.

The window to act is real and short. A senior executive at the vendor can absorb costs, bring new talent, and make commitments the delivery team has no authority to make. But that authority diminishes as the program ages. The more that’s been billed and the more scope has shifted, the harder it is for even a motivated senior executive to make the client whole. Clients who act in design or early build have options that clients who wait until three months before go-live don’t.

The intervention that works is a leadership one

When the signals are clear and the client is ready to act, the intervention that moves the needle isn’t a governance document or a scorecard meeting but a top-to-top conversation between client and vendor senior leadership. This includes execs who aren’t running the day-to-day program but have something personal at stake in the outcome.

That conversation works because it activates a different set of incentives. The vendor’s senior executive, the sector partner and industry leader whose name is on the relationship, needs your program to be referenceable. They don’t want a PR failure on a flagship engagement, nor do they want to explain to their firm’s leadership why a major client program collapsed. They have authority their delivery team doesn’t: power to assign their best resources, ability to absorb costs the SOW or change order doesn’t cover, and they can accelerate staffing decisions and make commitments that change what the program can do. They have skin in the game their team doesn’t.

Also, structure the engagement deliberately. Have senior executives on both sides and new talent brought in as a visible signal of vendor investment. And have a cadence that continues until the data shows the program is back on track, with time-bound accountability on both sides. And have explicit understanding that the relationship itself is under review, not just the program.

This is sustained leadership engagement, not a one-time meeting, and it doesn’t replace the governance model. It enforces it.

The only recovery signal worth trusting

When the top-to-top works, you’ll know it by what the vendor brings back to the table. Not reassurances or a revised plan with optimistic milestone dates, but facts about where they failed, what they’re changing, and, most critically, where the client has performance gaps that also need to close.

A vendor who comes back and accepts blame still manages the relationship. A vendor who says we failed here and here, these are the specific changes we’re making, and you have a gap here we need you to address, that vendor is engaged and mutually accountable. That’s the integrity test.

It runs both ways because program failure almost always does. Slow client decisions. Unavailable business resources. Requirements that shifted after design was locked. A vendor who names those things alongside their own failures isn’t deflecting, they’re investing in an outcome. That’s the signal the recovery is real.

If the executive meeting produces only promises and general commitment, keep the pressure on. Real engagement looks like specific admissions, named resources, and a willingness to hold the mirror up to both sides of the table.

You hold the accountability. Be the human in the middle.

Through all of it, the client holds the ultimate accountability. The master conductor holds the responsibility for execution and integration across the vendor ecosystem. That distinction isn’t administrative. It means the client can’t outsource their judgment, regardless of how rigorous the governance model looks on paper.

Think of it like the vendor can hallucinate. Not out of malice, but because every status report is a curated narrative produced by people whose compensation, future work, and professional reputation depend on how that narrative lands. The program deck isn’t neutral data, it’s information filtered through interests. What’s present tells you something. What’s absent, however, tells you more.

Be the human in the middle. Verify, cross-reference, ask questions the deck didn’t answer, and notice what’s missing as much as what’s there. If the steering committee is only hearing good news, that’s a sign someone is deciding what leadership is ready to hear, not that the program is running well.

Demand forecasts, not status reports. Look for hard evidence that can be independently corroborated. When the vendor names a client performance gap alongside their own, take it seriously. That’s the accountability model working the way it’s supposed to, not a deflection.

The warning signs may not always be apparent, though. The window is open, but won’t stay that way, so waiting isn’t a strategy.

Every SOC analyst has heard it by now: “AI is coming for your job”.

I hear it in conversations with SOC teams. I see it in the hesitation during evaluations. And increasingly, I feel it as a source of resistance — especially from the very people AI is supposed to help.

But the reality is the opposite.

Instead of eliminating the Tier 1 analyst role, AI is elevating it — from a job defined by repetitive tasks to one defined by judgment, oversight and decision-making. In short, it makes them more powerful as SOC commanders.

The work was never the point

To understand what’s changing, we need to be honest about the historical role of Tier 1 analysts.

In a typical SOC, a Tier 1 analyst might spend 20–30 minutes investigating a single phishing alert — pivoting across email logs, endpoint data and threat intelligence tools, validating signals and documenting findings. It’s necessary work, but it’s also highly repetitive and time-consuming.

Modern security operations generate more data than humans can reasonably process. Investigating a single alert often requires pivoting across identity systems, endpoint telemetry, cloud logs and threat intelligence sources. Multiply that by hundreds or thousands of alerts per day, and you have a workload that is fundamentally misaligned with human capacity.

More importantly, SOC analysts are too talented for this kind of non-human work. For years, we’ve accepted this as the cost of doing business. AI changes that equation.

From doing the work to directing it

What agentic AI introduces into the SOC is the ability to delegate.

Instead of analysts manually gathering evidence and stitching together context, AI agents can now autonomously execute investigative steps: Querying systems, correlating signals and building evidence chains in real time. It doesn’t remove the human from the process. It elevates them within it.

The emerging model is one where analysts manage a system of agents — each responsible for a piece of the investigation — rather than performing each step themselves. The human role shifts from operator to orchestrator.

What I consistently hear from security leaders isn’t, “I need my analysts to move faster.” It’s, “I need my analysts to stop collecting data and start making decisions based on it.” Those are fundamentally different problems. And the gap between them is where AI creates the most value.

The rise of the ‘manager of agents’

This is where the Tier 1 role evolves — not disappears.

In this new model, entry-level analysts are effectively managing a swarm of AI agents. They are responsible for reviewing investigations, validating conclusions and ensuring actions align with business context and risk tolerance.

They are not “in the loop” for every step. They are “on the loop” — overseeing outcomes rather than executing tasks.

When analysts are forced to stay in the loop — checking every enrichment, every query, every intermediate step — they become a bottleneck. When they move on the loop, they can operate at scale, reviewing dozens or hundreds of investigations with the right level of oversight.

This is how trust in AI is built: Not by asking humans to verify everything, but by giving them the visibility to verify anything.

Transparency becomes the control plane. Analysts can see exactly what the AI did, how it reached a conclusion and where uncertainty exists. Over time, as accuracy proves out, they naturally increase their level of trust — just as they would with a new colleague joining the team.

Why cybersecurity is different

The fear of job displacement is understandable. In many industries, AI is reducing the need for entry-level roles. Cybersecurity is one of the few domains where AI won’t reduce work. It will expose how much work we’ve been unable to do.

The volume and complexity of threats are increasing faster than teams can scale. Attackers are already using AI to automate reconnaissance, generate code and accelerate exploitation. Defenders don’t have the option to sit this out.

Threat hunting, detection engineering and control optimization have historically been under-resourced because teams were consumed by alert triage. When AI removes that burden, it creates much-needed capacity for analysts to do what they were trained to do. The work doesn’t shrink. The right work finally gets done.

A new baseline for entry-level talent

This shift also changes what we expect from entry-level analysts.

Historically, Tier 1 roles were designed as places where analysts learned by doing repetitive tasks. That model no longer makes sense when those tasks can be automated.

The baseline is moving toward understanding how AI systems operate: Interpreting their outputs, questioning their reasoning and guiding their behavior. Human-centric skills become more important, not less. Curiosity, critical thinking and the ability to connect disparate signals into a coherent narrative — these are the differentiators in an AI-driven SOC.

We’re already seeing organizations rethink how they hire for these roles. There is less emphasis on credentials and more on how someone thinks and solves problems. When AI handles the mechanics, judgment is the job.

Building trust that holds

If the future is so clear, why is there resistance? In most cases, it comes down to trust — and trust must be earned, not assumed.

The deployments I’ve seen fail share a common pattern: Organizations treat AI as a binary shift from no automation to full autonomy. That’s not how security teams work, and it’s not how they should be asked to work.

What works is a progression. Start with limited, high-confidence use cases. Provide full transparency into how the system reaches its conclusions. Let analysts validate outcomes before expanding the scope. And critically, put practitioners in the room. Not implementation consultants or project managers, but people who have run SOC shifts, triaged thousands of alerts and earned credibility the hard way.

This is why, when we deploy, we bring former SOC leads, threat hunters and detection engineers to work directly alongside analyst teams. They’re not there to configure software. They’re there to build trust in the system — because they’ve already earned trust from the people using it. When analysts see that the people helping them deploy this technology have lived the same grind, the conversation changes. It stops being “will this replace me” and starts being “how do I use this well.”

That shift in orientation — from threat to tool — is what separates a successful deployment from one that stalls.

The trust gap isn’t a technology problem. It’s a human one. And it closes the same way trust always closes: Through demonstrated competence, shared context and time.

The future SOC is human-led

The end state here is not an autonomous SOC with no humans involved. It’s a human-led SOC, powered by AI.

AI agents handle the labor-intensive, evidence-gathering aspects of security operations. Humans provide direction, oversight and accountability. Together, they operate at a speed and scale neither could achieve alone. That’s not a theory — it’s what’s happening in production environments today.

Elevation, not elimination

The narrative that AI will eliminate Tier 1 analysts misses the point. The role isn’t going away. It’s being redefined.

The analysts who succeed in this new environment will be those who can manage intelligence systems, interpret complex outputs and make high-quality decisions under uncertainty.

They won’t be replaced. They’ll be promoted.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Keeping up with new technologies, and recalibrating existing ones, can seem almost impossible as they seem to appear every month. But innovation breeds necessity, so knowledge updates within the enterprise are essential to successful reskilling, and CIOs are the pacesetters.

“In our profession, training is a given, like courage in soldiers,” says Gracia Sánchez-Vizcaíno, CIO of Securitas for Iberia and Latin America. “Without continuous training, teams become obsolete.

Disruption is also proportionate to the speed of change, leaving organizations usually a step behind technology. But speed isn’t the only challenge facing IT departments. The range of people themselves who need training has also changed. New technologies have become so intricate in corporate activity that staff training, as well as training of external teams, need to be more targeted.

So seeing which key knowledge areas dominate the concerns of CIOs and training experts helps visualize the scope of this challenge. Sánchez-Vizcaíno is focused on the particular speed of agentic AI. “We need a change in mindset, but also in knowledge,” she says.

Gen AI and cybersecurity are equally front of mind in developing new skills and knowledge, as are data analytics and automation. But the list also includes soft skills like communication, negotiation, and leadership since having critical thinking skills is equally important, says David González, business director of IT permanent recruitment at Hays Spain.

Develop or hire?

The need for staff to be adroit in emerging tech also raises another the question of upskilling internally or hiring externally those already skilled. While the latter can bring benefits, the general consensus among IT leaders is strengthening an established team is more advantageous to yield significant returns.

“Within the technology market, reskilling shouldn’t be an option but an advantage,” González says, adding that it’s not so much about pitting one model against the other, but seeing what each one offers and valuing it on findings. The IT job market is no longer dominated by a kind of recruitment race, however. “Attracting talent is very difficult,” Sánchez-Vizcaíno says, whereas training is another form of compensation that increases commitment, broadens the staff skill base, and reduces dependence on external resources that can be expensive and noncommittal.

“The cost of hiring a new employee can be three times that of a proper reskilling program,” says Magalí Riera, director of the master’s degree in people management, talent, and digital transformation at UNIE University. “Skills development isn’t just a simple corporate wellness option, it’s a vital strategy for staying competitive.”

Similarly, when there’s already a well-oiled, functioning team in place with diverse profiles and talents, it may be more worthwhile to update rather than try to fit new people in. 

“The team gives you something that goes beyond the technological aspect,” adds Álvaro Ontañón, CIO of Merlin Properties. But he, in turn, needs a team to deliver. “For me, within that context, trust is very important,” he says. “Once you have that, if the limitation is technology — unless it’s something very disruptive, requiring starting from scratch, or is expensive and requires hiring — we dedicate time to it.”

What reskilling should look like

Reskilling must be approached from a business perspective, says González, not just a technological one or with generic certifications. And a successful process must begin by understanding what will happen in the short, medium, and long term, promoting key market areas, and providing continuous but applied training.

And while industry experts acknowledge that video-based courses can be useful for routine tasks like safety training, they’re ineffective when it comes to developing new skills. Riera recommends project-based learning and avoiding purely passive learning methods.

Sánchez-Vizcaíno sees it firsthand as well. “The way we share and process information has also changed, and for all of this to work, it’s about moving from theoretical knowledge to adaptable, practical skills,” she says. Learning happens by sharing in Teams channels, talking with colleagues, and even listening to other companies. These are more multidirectional processes, compared to the unidirectional or bidirectional training of the past. “More than ever, it’s about learning by doing,” she adds.

Above all, it’s about creating a supportive and motivating environment, and fostering a fertile ground for learning and acquiring new skills. “If you want to benefit from learning, you must have an affinity for the training you’re going to receive,” Ontañón says. In his team, staff are involved in the preliminary process since if there aren’t interested people, there’s no training. It’s a pragmatic decision that avoids the feeling of seeing a course as a burden, and reinforces the desire to participate. But that’s almost the default state in the IT world, being constantly on the cusp of change, even outside of work hours, and needing to learn. 

Similarly, working with interests and needs in mind helps foster flexibility. “We dedicate a lot of time to this, because it’s what can guarantee its effectiveness,” says Ontañón, adding that it’s not about training for the sake of training, but responding to those concerns.

In a world where information is much more accessible than in the past, there are many more sources of knowledge. “The downside is because there’s so much, you have to find what really interests you and adapt to it,” he says.

Reskilling incorporated in the corporate vision

Equally important in the reskilling processes is monitoring its impact on the workforce. When change occurs, González says, productivity will initially drop before it rises. “Companies that fail are those that demand senior-level performance from the outset,” he says.

An adjustment period has to be factored in, which may even involve temporarily supplementing the workforce with external or temporary staff. “This learning process is a necessity,” Riera adds. “It’s not extra training or a reward for the employee, so it must be part of the work schedule.” She recommends not filling the entire workday with courses, but rather dedicate a small portion of the day to them so as not to hinder daily operations. Also, maintain clear communication with the team about what’s being done, why it’s being done, and what will be gained.

Microsoft plans to integrate Anthropic’s Mythos AI model into its Security Development Lifecycle, a move that suggests advanced generative AI is beginning to play a direct role in how major software vendors identify vulnerabilities and harden code against attack.

The company said it will use Mythos Preview, along with other advanced models, as part of a broader push to strengthen secure coding and vulnerability detection earlier in the software development process.

The announcement comes as Anthropic’s Mythos heightens concerns that advanced AI models could dramatically shrink the time between finding a software flaw and exploiting it. Analysts say Mythos marks a notable leap in AI-driven vulnerability research, with the ability to uncover thousands of serious flaws across major operating systems and browsers.

OpenAI has also entered the space with GPT-5.4-Cyber, a version of its flagship model tailored for defensive cybersecurity work. Keith Prabhu, founder and CEO of Confidis, said a future OpenAI model, which he referred to as “Spud,” could emerge as an even stronger rival.

The move matters beyond Microsoft’s own engineering organization. For enterprise security leaders, it offers a clear sign that frontier AI models are starting to move from experimental use into core cybersecurity workflows.

That could change how software vendors build products and how defenders view the risks and benefits of using the same AI tools attackers may also exploit.

“This marks a seminal turning point in the secure software development lifecycle process,” Prabhu said. “While earlier tools were only capable of static code scanning for vulnerabilities, with AI, there is a possibility of a dynamically learning model which can also perform dynamic vulnerability and even penetration testing in real time.”

Over time, Prabhu said, the pressure to adopt AI-assisted security tools is likely to spread beyond the largest software vendors.

Why Microsoft’s move matters

Neil Shah, vice president for research at Counterpoint Research, said more than 95% of Fortune 500 companies use Microsoft Azure in some capacity, while Azure AI and the Copilot suite are entrenched across about 65% of those companies. Millions of businesses also rely on multiple Microsoft products and cloud services.

“Using Mythos in Microsoft’s Security Development Lifecycle could help strengthen and harden products like Windows, Azure, Microsoft 365, and developer tools,” Shah said. “Every enterprise running those products could benefit from the security improvement without needing direct Mythos access themselves.”

Prabhu noted that Microsoft said it had evaluated Mythos using its open-source benchmark for real-world detection engineering tasks, with results showing substantial improvements over prior models.

“Such a claim coming from Microsoft does suggest that these new AI models are becoming materially better at identifying exploitable flaws than earlier generations,” Prabhu added. “However, as with any AI tool, the strength of the tool lies in its ability to analyze code quickly based on past learning. There is a possibility that it could miss new types of vulnerabilities that only a ‘human-in-the-loop’ could identify.”

Microsoft plans to integrate Anthropic’s Mythos AI model into its Security Development Lifecycle, a move that suggests advanced generative AI is beginning to play a direct role in how major software vendors identify vulnerabilities and harden code against attack.

The company said it will use Mythos Preview, along with other advanced models, as part of a broader push to strengthen secure coding and vulnerability detection earlier in the software development process.

The announcement comes as Anthropic’s Mythos heightens concerns that advanced AI models could dramatically shrink the time between finding a software flaw and exploiting it. Analysts say Mythos marks a notable leap in AI-driven vulnerability research, with the ability to uncover thousands of serious flaws across major operating systems and browsers.

OpenAI has also entered the space with GPT-5.4-Cyber, a version of its flagship model tailored for defensive cybersecurity work. Keith Prabhu, founder and CEO of Confidis, said a future OpenAI model, which he referred to as “Spud,” could emerge as an even stronger rival.

The move matters beyond Microsoft’s own engineering organization. For enterprise security leaders, it offers a clear sign that frontier AI models are starting to move from experimental use into core cybersecurity workflows.

That could change how software vendors build products and how defenders view the risks and benefits of using the same AI tools attackers may also exploit.

“This marks a seminal turning point in the secure software development lifecycle process,” Prabhu said. “While earlier tools were only capable of static code scanning for vulnerabilities, with AI, there is a possibility of a dynamically learning model which can also perform dynamic vulnerability and even penetration testing in real time.”

Over time, Prabhu said, the pressure to adopt AI-assisted security tools is likely to spread beyond the largest software vendors.

Why Microsoft’s move matters

Neil Shah, vice president for research at Counterpoint Research, said more than 95% of Fortune 500 companies use Microsoft Azure in some capacity, while Azure AI and the Copilot suite are entrenched across about 65% of those companies. Millions of businesses also rely on multiple Microsoft products and cloud services.

“Using Mythos in Microsoft’s Security Development Lifecycle could help strengthen and harden products like Windows, Azure, Microsoft 365, and developer tools,” Shah said. “Every enterprise running those products could benefit from the security improvement without needing direct Mythos access themselves.”

Prabhu noted that Microsoft said it had evaluated Mythos using its open-source benchmark for real-world detection engineering tasks, with results showing substantial improvements over prior models.

“Such a claim coming from Microsoft does suggest that these new AI models are becoming materially better at identifying exploitable flaws than earlier generations,” Prabhu added. “However, as with any AI tool, the strength of the tool lies in its ability to analyze code quickly based on past learning. There is a possibility that it could miss new types of vulnerabilities that only a ‘human-in-the-loop’ could identify.”

The article originally appeared in CSO.

Much of the talk around cybersecurity these days revolves around AI and the threat it poses to corporate systems when used by nefarious actors.

But the reality on the ground remains a little more mundane than polymorphic AI malware and criminal masterminds putting machine learning and generative AI to work at scale.

Still, keeping on top of even minor nuances and emerging trends in the techniques cyberattackers are deploying of late can greatly help cyber defenders in their task.

Of note is the fact that attackers are increasingly exploiting identity as a preferred method for infiltrating systems.

While exploiting vulnerabilities also remains an important vector with its own emerging subtleties in practice, phishing, stolen credentials, and social engineering are among the more common root causes of initial attack today, according to threat response experts.

“Identity-related attack techniques such as phishing (41%), stolen credentials (18%), and social engineering (12%) dominating our incident response engagements,” Alexandra Rose, director at the Counter Threat Unit at Sophos, tells CSO.

Rose adds: “Attackers are increasingly looking to leverage weaknesses that can’t be targeted by patching — instead going after the human link in the chain: people.”

Entry points created by expanding hybrid and cloud environments, integrations with AI tooling, and new SaaS apps are also particularly attractive to threat actors, allowing them to infiltrate systems without needing to deploy traditional malware.

“Attackers [are exploiting] trusted tools, identities, and user behaviour rather than relying on technical sophistication” to mount attacks, according to threat intel vendor ReliaQuest’s latest Annual Cyber-Threat Report.

Here, cyber experts quizzed by CSO identify the most prevalent cyberattack techniques being deployed against enterprises today.

Drive-by RMM misuse

Attackers have increasingly been abusing legitimate remote monitoring and management (RMM) tools to camouflage attacks on corporate networks. Designed to help IT teams manage systems remotely, popular RMM tools, such as ConnectWise ScreenConnect, Tactical RMM, and MeshAgent, are often abused by attackers for command-and-control, lateral movement, and ransomware deployment.

Now, trojanized versions of RMM tools are being dropped directly onto hosts, often through drive-by compromise, according to ReliaQuest. ConnectWise ScreenConnect led RMM-related incidents between December 2025 up until the end of February 2026, according to the threat intel vendor.

A separate study by managed detection and response firm Blackpoint found that abuse of legitimate RMM tools represented 30% of incidents handled by the firm.

Network security device hacking

Network edge devices have increasingly drawn attackers’ attention over the past two years, establishing a new battleground where the very devices meant to protect the network have become attractive targets for exploitation.

As a result, flaws in security device, such as SSL VPN systems and other gateways, are among the top initial access vectors for attackers.

SSL VPN compromises, for example, accounted for 33% of identifiable activity, according to Blackpoint.

ClickFix

ClickFix is a social engineering tactic that aims to trick prospective marks into pasting and executing malicious PowerShell commands from fake “fix” prompts.

Because these bogus prompts come from either compromised websites or manipulated search results, the approach bypasses traditional security controls such as email filters or denylists.

ClickFix scams often uses fake CAPTCHA pages as the lure.

The methodology is most frequently used to distribute remote access trojans or infostealers, but attackers have also begun to feature ClickFix in ransomware attacks.

“ClickFix adoption continues to expand across the attacker spectrum, with ransomware operators like LeakNet now using ClickFix lures to run campaigns directly rather than purchasing access from initial access brokers,” according to ReliaQuest.

Identity-based attacks

Attackers are increasingly impersonating legitimate users, machines, or services to gain access to systems, data, or infrastructure. The technique is on the upswing in part due to improved security defenses, according to some experts, and also demonstrates attackers’ interest in targeting authentication mechanisms rather than exploiting software vulnerabilities directly.

“Endpoint detection and response technologies have pushed criminals into stealing credentials — or buying them from thieves — and then using them for authentication as account users,” says Tom Exelby, head of cybersecurity at UK-based cybersecurity services firm Red Helix. “Once they have access, they can augment their privileges through systems such as Microsoft Active Directory and Entra ID.”

Instead of stealing passwords, attackers steal active authentication tokens to bypass multi-factor authentication (MFA) protections.

Attackers are increasingly using OAuth consent phishing and reverse proxy kits to steal session tokens and bypass MFA, adds cloud-native security firm Netskope.

“Attackers targeting Microsoft 365 environments are also adopting adversary-in-the-middle attacks,” Red Helix’s Exelby adds. “They capture credentials, MFA responses, and session cookies by using phishing kits as a proxy between the target and the legitimate authentication service.”

Cybercriminals are using platforms such as the Tycoon 2FA phishing-as-a-service to run adversary-in-the-middle (AiTM) attacks. Many of the victims of this attack vector are “likely to be SMBs with limited cybersecurity resources,” according to Red Helix.

Phishing

Despite a year-over-year decline in the number of people clicking on phishing links, in part due to improved user education, this traditional form of social engineer remains a problem.

According to a recent study by Netskope, 87 out of every 10,000 users click on a phishing link each month. Microsoft remains the brand attackers impersonate most.

Remote and hybrid workforces have given attackers more opportunities for phishing and credential theft, and now the power of AI in facilitating such attacks is becoming a major concern. Cybercriminals have been putting AI to use to develop highly personalized phishing lures, automated reconnaissance, and synthetic voice and deepfake attacks.

Hacking machine identities

The rapid profileration of machine identities is proving to be a wellspring for attackers seeking inroads into corporate systems. Much of this is due to increased use of service accounts, containers, APIs, and the automation of DevOps, but agentic AI, with its promise of autonomous AI activity, is another rising source of concern for security organizations.

“With non-human identities central to infrastructure, attackers are inevitably focusing on compromise of service accounts and API identities, which give them long-lived credentials and a broad range of permissions,” says Red Helix’s Exelby.

Exelby adds: “Machine identities often have weak protection, are notoriously invisible, and poorly managed.”

Managed service providers that hold privileged access to many client’s systems have a magnetic attraction for attackers as a potential route to carry out supply chain attacks. Even a midsize business is likely to have hundreds of SaaS apps and thousands of identities criminals can exploit.

Shai-Hulud: The supply-chain attack evolves

In September 2025, credential-stealing code wormed its way through scores of npm libraries, adding a modern twist to the supply chain attack. What would become known as Shai-Hulud included self-propagation logic that would eventually spread to hundreds of packages by automatically replicating and injecting itself into projects owned by compromised maintainers.

Later versions of the npm supply-chain worm (“Shai-Hulud 2.0”) have expanded into cloud credential theft, making it the most significant new entry in ReliaQuest’s attack technique list since the previous edition last year.

“The self-replicating nature [of the malware] makes containment particularly difficult once it enters a development pipeline,” ReliaQuest warns.

Countermeasures

Defenders should prioritize ClickFix-specific user training, enforce remote monitoring and management (RMM) tool allowlists, and centralize SaaS audit logging, ReliaQuest advises.

Protection against the tide of identity-based attacks requires a shift to layered defenses.

“Layered defences should include phishing-resistant authentication with hardware security keys, FIDO2 password-free approaches or certificate-based methods to reduce credential theft and adversary-in-the-middle attacks,” says Red Helix’s Exelby.

Exelby adds: “Zero trust and least privilege access principles are essential, validating continuously using device posture, user behaviour and network context, along with risk-scoring. Time-bound access for accounts should be part of this.”

Though I reviewed Apple’s recently-introduced MacBook Neo, M5 MacBook Air, and M5 Max MacBook Pro, I didn’t look at Apple’s new displays. But it is noteworthy that even these products open up new opportunities for the company.

That’s because Apple this week gained FDA clearance for the Medical Imaging Calibration feature introduced in the Studio Display XDR. Just as the affordable MacBook Neo opens up a fresh mass market opportunity, this specialized product feature forges space in a new niche. 

Apple opens a new growth market

That niche will only become even more important once specialized AI medical tools to support treatment and diagnosis appear in the radiology space, as such tools inevitably will. (Inevitably? I mean, just look at this December research announcement from the Institute of Cancer Research, which demonstrated that combining artificial intelligence (AI) with state-of-the-art MRI imaging can revolutionize prostate cancer treatment.)

The combination means you don’t need a dedicated radiology workstation costing in excess of $15,000; you need only a Mac and a $2,899 Apple display. 

Once those things are in place, you can select your choice of imaging software — probably something like Visage Imaging 7, OsiriX MD, Falcon MD, or another of the solutions available for Mac. Even better, while privacy and data confidentiality concerns do exist, the Mac you use for this work can also be used for other tasks, like any other Mac. This democratizes access to tools of this kind; gives the medical profession all the Apple advantages around product resilience, TCO, and tech support; cuts budgets; and enables medical tech purchasers to get more for less.

On-device AI, an Apple advantage

Then we get to think about AI, and that’s where Apple’s strategic sensibility seems to be coming into play. I see it like this: it is obvious that AI for medical imaging will need to run on something. And what Apple has done with Apple Silicon, its approach to on-device AI, and this new medical image calibration feature on its displays all mean it now offers a trusted, highly usable, incredibly flexible solution to run future AI-augmented MRI imaging packages. Apple’s processors can simply shrug their way through that kind of work, while its new displays can give radiologists and other medical examiners the precise accuracy they need.

The new display feature also gives Apple an impressive story to tell in the $42.6 billion global market for medical imaging devices. That tale is tempered by Apple’s cast-iron commitment to privacy and the impressive capacity of Apple Silicon to run on-device LLMs. Apple’s introduction of MLX means you can easily imagine medical imaging deployments that rely on a new Studio Display and four Mac minis clustered via a single Thunderbolt 5 cable. Total cost? Not $15,000. 

Apple is cheap

Apple is cheap. That’s not an illusion. Look at the ecosystem. The entry level $599 MacBook Neo shows this, while all the TCO and tech support and security studies I’ve seen across the last decade show that once you begin using these platforms you end up spending a lot less keeping your investments going.

That matters in any business, of course. But when it comes to the kind of industries Medical Imaging Calibration is meant for, that can be life-saving. Who wants urgent surgery to be delayed by an operating system crash or another Crowdstrike-like moment?

There might be problems getting this message through to every medical provider across the planet, but check out Emory University and its Department of Radiology and Imaging Sciences. There, you can peruse a white paper explaining most of the steps radiologists and imaging practices must take to integrate Apple’s displays and systems into their clinical workflows. 

As explained here, the paper praises the CPU/GPU performance of Macs used in the test, which rival or exceed traditional workstations at a fraction of the cost. The white paper also opens a second dimension in medical practice, thanks to visionOS and the capacity to create new workflows that have the headset using new surgical apps from the likes of Stryker and Storz. Add AI to that equation and you can see that Apple has raised a very, very large flag depicting a very large Apple logo on part of the future of medical care. 

Please follow me on Twitter, or join me in the AppleHolic’s bar & grill and Apple Discussions groups on MeWe. Also, now on Mastodon.

When voters in the forthcoming Hungarian election assess the current government, its record on internet security will not be one of its proudest achievements.

An analysis by open source investigation organization Bellingcat has revealed that the passwords for almost 800 Hungarian government email accounts are circulating online, many of them associated with national security. These breaches in security are not down to high-tech attacks but rather are the result of poor email hygiene among government employees. The security leaks were widespread: 12 out of 13 government departments were affected.

Hungarian Prime Minister Viktor Orban’s administration likes to present itself as firm protector of Hungarian borders, resisting foreign interference, but this doesn’t seem to apply to its computing prowess. Among those whose details were revealed were an officer responsible for information security and a counter-terrorism expert.

Bellingcat found that government officials have been using weak passwords such as variations of the word “Password” or the number sequence “1234567, while another simply used his surname.

The Hungarian government is not alone in its laxity.  Earlier this year, Specops found that 6 billion logins had been exposed online and found that number sequences and ‘password’ featured highly in the list of the most compromised logins.

The vulnerabilities inherent in the Hungarian example are a warning to all CSOs that they should be reminding their staff to tighten their security credentials. Many choose simple, short memorable passwords because they’re easy to remember but using a password manager or deploying passkeys will immediately strengthen employees’ ability to protect data.

This article first appeared on CSO.

When voters in the forthcoming Hungarian election assess the current government, its record on internet security will not be one of its proudest achievements.

An analysis by open source investigation organization Bellingcat has revealed that the passwords for almost 800 Hungarian government email accounts are circulating online, many of them associated with national security. These breaches in security are not down to high-tech attacks but rather are the result of poor email hygiene among government employees. The security leaks were widespread: 12 out of 13 government departments were affected.

Hungarian Prime Minister Viktor Orban’s administration likes to present itself as firm protector of Hungarian borders, resisting foreign interference, but this doesn’t seem to apply to its computing prowess. Among those whose details were revealed were an officer responsible for information security and a counter-terrorism expert.

Bellingcat found that government officials have been using weak passwords such as variations of the word “Password” or the number sequence “1234567, while another simply used his surname.

The Hungarian government is not alone in its laxity.  Earlier this year, Specops found that 6 billion logins had been exposed online and found that number sequences and ‘password’ featured highly in the list of the most compromised logins.

The vulnerabilities inherent in the Hungarian example are a warning to all CSOs that they should be reminding their staff to tighten their security credentials. Many choose simple, short memorable passwords because they’re easy to remember but using a password manager or deploying passkeys will immediately strengthen employees’ ability to protect data.

Announced at JavaOne, Project Detroit proposes to break down the walls between Java, Python, and JavaScript. Also in this report: Better ways to instrument your code with Python’s new built-in sampling profiler, another run at using AI locally to rework a Python project, and the question on everyone’s mind right now (surely): What does OpenAI really want with Astral?

Top picks for Python readers on InfoWorld

OpenAI buys Python tools builder Astral
Astral, the maker of uv, ty, and pyx, has a new home under the OpenAI umbrella. Is OpenAI demonstrating its commitment to maintaining tooling in the AI space, or is the purchase more of a power move?

I ran Qwen3.5 locally instead of Claude Code. Here’s what happened
Want to run an LLM on your own hardware for that at-home Claude Code or Copilot experience? You can, but it’ll be a bumpy ride. My takeaway? Maybe don’t let the AI run around unsupervised after dark.

Hands-on with the new sampling profiler in Python 3.15
Among Python 3.15’s best new features is a sampling profiler. See how it works in this guide to using the profiler to instrument your code and find bottlenecks with minimal performance impact.

Project Detroit, bridging Java, Python, JavaScript, moves forward
The once-dead, now-revived Detroit project aims to allow Java’s Foreign Function and Memory API to talk seamlessly to other language runtimes. The vision? More powerful mixing and matching of languages across domains.

More good reads and Python updates elsewhere

The slow collapse of MkDocs
The strange, ongoing saga of how a developer meltdown took out one of the most popular documentation tools for Python—with no clear successor in sight.

Comparing the typing spec conformance of Python type-checking tools
How well do tools like Pyright, Pyrefly, Mypy, Ty, and others conform to Python’s own type annotation specs? The answers range, surprisingly, from “very closely” to “just barely.”

The optimization ladder: All the ways to make Python faster
From replacing the runtime to integrating modules written in C or Rust, here’s an end-to-end rundown of ways to speed up Python for tasks that urgently need performance.

License laundering and the death of ‘clean room’
When someone rewrote a long-unmaintained Python library with an LLM, the original developer broke a decade-plus silence to object. What are the implications for open source?