Among a range of factors leading to a wave of tech sector layoffs in 2026 is the rapid rise of artificial intelligence and automation. Companies are reconfiguring their workforces to leverage AI for increased efficiency and reduced operating costs. This realignment and reduction is implemented even by companies reporting strong financial performance.

But it’s not just AI leading to workforce cuts. Complementing this technological shift are ongoing economic uncertainty, inflation, and higher interest rates, compounded by a chip shortage and rising energy costs. This mix is driving companies to cut costs and streamline operations for increased efficiency.

According to data compiled by Layoffs.fyi, an online tracker that keep tabs on job losses in the technology sector, 123,941 tech employees were laid off at 269 companies in 2025. The site also reports that 71,981 government employees were laid off by DOGE alone, with 182,528 total federal workers laid off.

Here is a list — to be updated regularly — of some of the most prominent technology layoffs the industry has experienced recently.

Notable tech layoffs in 2026

• Monday.com
• Microsoft
• Meta
• Cisco
• Cloudflare
• Oracle
• Atlassian
• Salesforce
• Amazon
• Ericsson

July 22, 2026: Monday.com cuts 20% of its workforce to restructure for the AI era

The company says the decision to cut 620 jobs isn’t about margins, but about creating a flatter organization built around AI agents, autonomous teams, and deeper customer engagement.

July 6, 2026: Microsoft cuts 4,800 jobs, primarily in sales and Xbox teams

As the company trims thousands of jobs, it’s also investing in embedded engineering teams and AI infrastructure. The layoffs come several weeks after the company offered 8,750 US employees voluntary retirement buyouts.

June 5, 2026: Tech industry cut 38,242 jobs in May, worst since 2024

AI was blamed for 40% of the job cuts in May, up from 7% in January, according to research by employment placement company Challenger, Gray & Christmas.

May 20, 2026: Meta cuts 8,000 jobs, around 10% of workforce

The cuts are expected to expected to hit Meta’s engineering and product teams the hardest, arriving as Meta pivots toward AI to boost efficiency across its organization, according to Yahoo Tech.

May 13, 2026: Cisco to cut nearly 4,000 jobs despite strong growth in AI, enterprise networking

Despite reporting positive financial news — including record third-quarter revenue of $15.8 billion, a 12% year-over-year increase — Cisco said it will eliminate almost 4,000 jobs.

May 7, 2026: Cloudflare to cut 1,100 jobs in AI-focused restructuring

About 20% of Cloudflare’s global workforce will be culled as the company pivots for the agentic AI era, Reuters reported.

April 1, 2026: Oracle to cut up to 30,000 jobs globally, putting enterprise support and roadmaps at risk

Oracle began laying off employees on March 31 in what could be the largest workforce reduction in the company’s history. Employees received termination emails at 6 a.m. local time with immediate system lockouts and no prior warning. (Note: in June, CNBC put the final layoff tally at 21,000.)

March 12, 2026: Atlassian cuts 1,600 jobs to fund AI and enterprise expansion

Atlassian will reduce its global workforce by approximately 10%, eliminating around 1,600 roles, as the collaboration software maker redirects capital toward artificial intelligence development and enterprise sales.

March 11, 2026: Tech layoffs surpass 45,000 in early 2026

A recent analysis by RationalFX found 45,363 job cuts globally so far this year—with roughly 68% or more than 30,000 occurring in the U.S. — highlighting ongoing workforce cuts even as many tech companies report strong revenue growth.

February 10, 2026: Salesforce lays off staffers as executive leadership churn continues

Salesforce has reduced close to 1,000 roles earlier this month across teams, including marketing, product management, data analytics, and its Agentforce AI unit, Business Insider reported, quoting employees familiar with the matter.

January 23, 2026: Amazon layoffs expected to disproportionately hit AWS and tech talent

As the market slows down, AWS and other Amazon units are preparing for another round of layoffs, which is expected to overwhelmingly impact tech talent. An email from HR leader Beth Galetti on Jan. 28 confirmed 16,000 job cuts.

January 15, 2026: Ericsson plans to shed 1,600 jobs in Sweden

 Ericsson lans to cut some 1,600 jobs in Sweden, the telecommunications equipment maker said doubling down on recent cost-saving measures that have helped it weather a prolonged downturn in telecoms spending, Reuters reports.

January 13, 2026: Meta plans to cut around 10% of employees in Reality Labs business

Meta plans to cut around 10% of the employees in its Reality Labs division who work on products including the metaverse, according to three people with knowledge of the discussions, according to The New York Times.

Layoffs in 2025

• Cisco
• Oracle
• Windsurf
• Intel
• Microsoft
• Crowdstrike
• HPE
• Autodesk
• HPE
• CISA
• Workday
• Salesforce
• Meta

Global tech-sector layoffs surpass 244,000 in 2025

Economic uncertainty, elevated interest rates, and AI adoption have driven workforce reductions across tech companies worldwide, according to a RationalFX report.

October 28, 2025: Amazon to cut 14,000 jobs across company

Amazon will reduce its overall workforce by 14,000, cutting layers of management across the company and hiring in some areas to support its “biggest bets”.

August 18, 2025: Cisco and Oracle to cut hundreds of Bay Area jobs

Tech companies Cisco and Oracle are cutting hundreds of jobs across the Bay Area. Cisco will eliminate 221 positions at its Milpitas and San Francisco offices, effective Oct. 13. Oracle is reducing 101 positions in Santa Clara on the same date 

August 5, 2025: 3 weeks after acquiring Windsurf, Cognition offers staff the exit door

Cognition, the AI coding startup that acquired rival company Windsurf three weeks ago, laid off 30 employees last week and is offering buyouts to the roughly 200 remaining employees on the team, reports The Information.

July 25, 2025, Intel to lay off 22% of workforce, CEO Tan signals ‘no more blank checks’

Intel will reduce its workforce to 75,000 employees by the end of 2025 as new CEO Lip-Bu Tan implements sweeping changes designed to transform the struggling chipmaker

July 8, 2025, Intel layoffs begin: Chipmaker is cutting many thousands of jobs

Intel has begun laying off employees across the company. CEO Lip-Bu Tan told workers back in April to expect major layoffs at Intel in the coming months as the chipmaker slashes costs and overhauls its organization after years of technical setbacks and falling sales.

July 2, 2025: Microsoft will cut 9,000 workers

Microsoft will lay off about 9,000 employees, a source familiar with the workforce cut told CNBC.  The cuts will reportedly affect less than 4% of Microsoft’s global workforce and will impact different teams, geographies and levels of experience. This is the latest in a string of cuts the tech giant has made this year.

June 17, 2025: Intel looks to factory layoffs to return to profitability

Intel will lay off up to 20% of its manufacturing sector employees starting in July, according to media reports, as the company looks for options as it seeks a return to profitability. The cuts reportedly will be made around the world, but some of the layoffs will be closer to home, according to a report in The Oregonian citing an internal company memo from Intel manufacturing Vice President Naga Chandrasekaran.

May 7, 2025: CrowdStrike to lay off 5% of staff

CrowdStrike announced a plan to cut about 500 roles, roughly 5% of its workforce, to streamline operations and reduce costs. The cybersecurity company will incur about $36 million to $53 million in charges related to the layoffs

March 6, 2025: HPE cuts 2,500 jobs, remains committed to Juniper buy

CEO Antonio Neri told Wall Street analysts that HPE would begin implementing a cost-cutting program involving layoffs of about 2,500 employees over the next 18 months. HPE employs about 61,000 people worldwide.

Feb. 27, 2025: Autodesk to lay off 9% of workforce

Software maker Autodesk is laying off 1,350 staff. With the rise of subscription and multi-year contracts billed annually, and self-service enablement, it finds it needs fewer sales staff, CEO Andrew Anagnost said in a message to employees. And with its cloud, platform, and AI products proving most profitable, it’s concentrating its staff and investments there.

Feb. 27, 2025: HP to lay off 2,000 more

As part of an ongoing restructuring, HP plans to lay off up to another 2,000 workers. In recent weeks, the company has tried — unsuccessfully — to do away with telephone support staff by forcing callers to wait for at least 15 minutes if they refuse to use self-service support resources online. The company swiftly backtracked, but wider job cuts are still on.

Feb. 21, 2025: CISA lays off 130

Government employees get laid off too: In this case, 130 workers at the US Cybersecurity and Infrastructure Security Agency are being shown the door as a result of a DOGE decision. Cybersecurity experts are concerned that the cuts will harm the international collaborations that CISA has fostered, quite apart from their concerns about the security of the DOGE layoff process itself.

Feb. 5, 2025: Workday lays off 1,750

As it moves to invest more in AI and international growth, Workday is laying off 8.5% of its workforce and disposing of unused office space. Some analysts fear the cutbacks will affect the company’s customer service — unless AI can pick up the slack.

Feb. 4, 2025: Salesforce lays off over 1,000

At the same time as it’s hiring sales staff for its new artificial intelligence products, Salesforce is laying off over 1,000 workers across the company, according to Bloomberg. As of June, 2024, the company had over 72,000 employees, according to its website. Salesforce did not comment on the report. In 2024 the company reportedly laid off around 1,000 staff too, in two waves: January and July.

Jan. 14, 2025: Meta will lay off 5% of workforce

Mark Zuckerberg told Meta employees he intended to “move out the low performers faster” in an internal memo reported by Bloomberg. The memo announced that the company will lay off 5% of its staff, or around 3,600 staff, beginning Feb. 10. The company had already reduced its headcount by 5% in 2024 through natural attrition, the memo said. Among those leaving the company will be staff previously responsible for fact checking of posts on its social media platforms in the US, as the company begins relying on its users to police content.

Tech layoffs in 2024

• Equinix
• AMD
• Freshworks
• Cisco
• General Motors
• Intel
• OpenText
• Microsoft
• AWS
• Dell

Nov. 26, 2024: Equinix to cut 3% of staff

Despite intense demand for its data center capacity, Equinix is planning to lay off 3% of its workforce, or around 400 employees. The announcement followed the appointment of Adaire Fox-Martin to replace Charles Meyers as CEO and the departures of two other senior executives, CIO Milind Wagle and CISO Michael Montoya.

Nov. 13, 2024: AMD to cut 4% of workforce

AMD will lay off around 1,000 employees as it pivots towards developing AI-focused chips, it said. The move came as a surprise to staff, as the company also reported strong quarterly earnings.

Nov. 7, 2024: Freshworks lays off 660

Enterprise software vendor Freshworks laid off around 660 staff, or around 13% of its headcount, despite reporting increased revenue and profits in its fourth fiscal quarter. The company described the layoffs as a realignment of its global workforce.

Sept. 17, 2024: Cisco lays off 6,000

After laying off around 4,200 staff in February, Cisco is at it again, laying off another 6,000 or around 7% of its workforce. Among the divisions affected were its threat intelligence unit, Talos Security.

Aug. 20, 2024: General Motors lays off 1,000 software staff

More than 1,000 software and services staff are on the way out at General Motors, signalling that it could be rethinking its digital transformation strategy. In an internal memo, the company said that it was moving resources to its highest-priority work and flattening hierarchies.

August 1, 2024: Intel removes 15,000 roles

Intel plans to cut its workforce by around 15% to reduce costs after a disastrous second quarter. Revenue for the three months to June 29 stagnated at around $12.8 billion, but net income fell 85% to $83 million, prompting CEO Pat Gelsinger to bring forward a company-wide meeting in order to announce that 15,000 staff would lose their jobs. “This is an incredibly hard day for Intel as we are making some of the most consequential changes in our company’s history,” Gelsinger wrote in an email to staff, continuing: “Our revenues have not grown as expected — and we’ve yet to fully benefit from powerful trends, like AI. Our costs are too high, our margins are too low. We need bolder actions to address both — particularly given our financial results and outlook for the second half of 2024, which is tougher than previously expected.”

July 4, 2024: OpenText to lay off 1,200

OpenText said it will lay off 1,200 staff, or about 1.7% of its workforce, in a bid to save around $100 million annually. It plans to hire new sales and engineering staff in other areas in 2025, it said.

June 4, 2024: Microsoft lays off staff in Azure division

Microsoft laid off staff in several teams supporting its cloud services, including Azure for Operations and Mission Engineering. The company didn’t say exactly how many staff were leaving.

April 4, 2024: Amazon downsizes AWS in a fresh cost-cutting round

Amazon announced hundreds of layoffs in the sales and marketing teams of its AWS cloud services division — and also in the technology development teams for its physical retail stores, as it stepped back from efforts to generalize the “Just Walk Out” technology built for its Amazon Fresh grocery stores.

April 1, 2024: Dell acknowledges 13,000 job cuts

Dell Technologies’ latest 10K filing with the US Securities and Exchange Commission disclosed that the company had laid off 13,000 employees over the course of the 2023 fiscal year; it characterized the layoffs and other reorganizational moves as cost-cutting measures. “These actions resulted in a reduction in our overall headcount,” the company said. A comparison to the previous year’s 10K filing, performed by The Register, found that Dell employed 133,000 people at that point, compared to 120,000 as of February 2024. Dell announced layoffs of 6,650 staffers on Feb. 6, but it is unclear whether those cuts were reflected in the numbers from this year’s 10K statement.

See news of earlier layoffs.

I haven’t slept much in the past few weeks. Not because of some theoretical cyber risk that keeps many executives awake, but because reality just delivered a real wake-up call to our industry — a call that every executive must answer, now.

Imagine this: A major global enterprise, a company most of us interact with indirectly every single day, wakes up to find its entire digital environment obliterated. Thousands of employees in dozens of offices and remote locations are suddenly offline. Customers are cut off, supply chains grind to a halt and regulators are notified with a chilling admission: “We have no idea when we’ll be back.”

This wasn’t ransomware. There was no negotiation, no decryption key to buy, no easy way out. It was destruction — deliberate, coordinated and geopolitically motivated — not monetary.

As a chief customer officer who’s worked with countless customers on cyberattack risks, my perspective hits a bit differently than a CISO or a CTO. I see the aftermath, not just the attack surface. I see the faces behind the tickets, the operations team locked out of their own systems, the support agent answering panicked calls at dawn. And I ask: How many organizations have actually stress-tested their response to this scenario — not a hypothetical, but this very real, lights-out event? Here’s what every leader needs to confront today:

Recovery is not just a technical exercise

The first assumption to break during a real crisis is the belief that recovery is purely technical.

Many organizations have done tabletop exercises and have a backup and recovery playbook, so they feel prepared. They can point to backup windows, retention schedules and immutability controls. The moment a true blackout happens, a different reality surfaces. The people who own the recovery steps either do not know each other, lack the authority to make decisions without supervisor approval or need guidance from offline systems.

The reality is that technical infrastructure almost always holds up better than human infrastructure. Organizations have built their recovery strategy around the assumption that someone competent will be awake, available and empowered when a cyber event happens.

Still, backups are only as good as their independence. Let’s be blunt: If your recovery infrastructure shares identity, authentication or network trust with your Microsoft tenant (such as Azure, Microsoft 365 or Teams), you don’t actually have a recovery plan; you have a false sense of one — and a liability. A recent survey found that while 90% of organizations express confidence in their ability to recover from a cyber incident, fewer than one in three ransomware victims fully recovered their data.

True resilience means immutable, air-gapped backups, untouchable by the same compromise. Anything less is an illusion. I talk to customers about their recovery plans constantly. The customers who have rehearsed all scenarios sleep soundly. Those who haven’t? They’re rolling the dice.

Most business continuity plans ignore ‘total blackout’

I’ve reviewed hundreds of business continuity plans. Almost all assume partial failures — a region, an application, a data center. But what if every system, in every country, goes dark simultaneously? That’s an entirely different playbook. If your team hasn’t run a drill for a global, simultaneous outage, you’re not prepared. The probability is low, but the cost of being unready is existential.

Connected devices, OT systems, field hardware, partner integrations — they all plug into your enterprise network. When the core collapses, it’s not just IT at risk. It’s operational technology, physical safety systems and in regulated sectors, potentially human lives. Understanding and testing those interdependencies is non-negotiable.

This is also where boards need to change the conversation. A study found that only 5% of companies have cybersecurity experts on their board of directors. Recovery time objectives (RTOs) should not be buried in technical appendices. It’s all jargon to boards. That makes translation essential. RTOs must be explained in terms of business impact. “We can recover in four hours” is a technical statement. “Every hour of downtime costs us $2.3M and creates regulatory exposure in three jurisdictions” is a board statement.

That is the level of clarity leaders need.

The most prepared organizations do not wait for an incident to educate the board. They bring the conversation forward proactively. They frame recovery in business terms: revenue, regulatory standing, customer trust and brand reputation.

The most effective framing is often simple. Show the most critical systems. Show what happens if each one is down for one hour, four hours, 24 hours and 72 hours. Show the current recovery capability against each and then show the gap.

If your board is not demanding real answers, your business continuity strategy is likely underfunded and your business is exposed. This is a risk conversation worth forcing because the consequences do not stay inside IT. They can show up in customer churn or missed revenue and ruin an organization’s reputation.

Threat intelligence must be actionable, not archived

Geopolitical attacks, hacktivist campaigns and nation-state targeting aren’t abstract threats. They are active risks, and that intelligence cannot languish in the security team’s inbox. Executive leadership must be looped in — and immediately — so gaps can be closed before they’re exploited. Too often, intelligence enters the security operations function and never reaches the teams responsible for recovery infrastructure or executive decision-making.

If a threat actor is targeting a specific class of backup agents, the team responsible for those agents needs to know now, not two weeks from now. If intelligence suggests destructive activity against a sector, recovery owners need to validate isolation, access paths and restoration procedures immediately. If geopolitical tension increases the likelihood of targeting, executive leadership needs to understand what exposure exists and what actions are being taken. The organizations that survive aren’t just the best at incident response. They’re the ones who anticipated, rehearsed and invested before the attack.

Part of investing in a recovery strategy requires closing the loop between signal and action. The most prepared organizations have already mapped their critical recovery dependencies to specific threat categories. When intelligence touches one of those categories, there is a named owner and a clear set of actions. No guessing or forwarding emails into the void is needed because the distance between the warning and the employees’ ability to do something is shortened.

Looking ahead, the conversation will continue to evolve beyond traditional cyber response. Because in an AI-enabled enterprise, the new question is whether the data within those systems can still be trusted. When AI systems make decisions based on enterprise data, the attack surface becomes the data’s accuracy. A threat actor who quietly corrupts a dataset over 90 days before a recovery event has done more damage than just downtime. They can poison the inputs driving decisions across the business.

Regardless of how AI will change threat intelligence and cyber response, these principles remain the same. Know your problem, whether structural or technological. Ensure your human infrastructure keeps pace with your technical infrastructure, with clear cross-functional ownership and the tools and knowledge to act autonomously. Communicate with your boards often — and correctly.

Let’s not wait for the next headline to ask, “Are we ready?” Have those conversations now. Test your assumptions. Close your gaps. Because in today’s threat landscape, resilience isn’t IT’s job — it’s everyone’s mandate.

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

In August 2025, 126 malicious packages landed in the npm registry. Even after the community caught the initial wave, 80 of these hidden backdoors remained actively listed.

That was enough. Over 86,000 downloads. Malicious code in PhantomRaven, packages running in the production systems of Fortune 500 companies worldwide. And throughout the entire window, not a single EDR/XDR alert.

This happened because the attack surface has expanded to a layer EDR/XDR was never designed to see: VS Code extensions, local MCP servers, and rogue AI coding assistants that inherit your engineers’ valid credentials to steal data at machine speed.

To eliminate this structural vulnerability, Palo Alto Networks acquired Koi, an AI-native developer security product engineered for proactive, precision enforcement. Below we compiled a 2026 CISO checklist you can use to audit your environment and see how Koi automates each defense from day one.

#1. Gain real-time visibility into shadow AI & extensions

Your existing asset management tracks binaries and installers, but it cannot see local VS Code extensions, MCP servers, or ad-hoc Python scripts running on developer endpoints. This visibility gap was recently exposed by the MaliciousCorgi campaign, where two marketplace extensions with 1.5 million combined installs silently harvested every file a developer opened. Neither triggered any detection because they were not binaries, not executables, not anything your inventory was built to flag. To counter this, Koi closes the gap by analyzing what extensions actually do after installation, exposing hidden data-harvesting channels running inside your active workspace.

#2. Distinguish between human and autonomous agent behavior 

When a rogue AI agent exfiltrates your proprietary source code, it uses a developer’s valid credentials during normal working hours, making the session look entirely legitimate to standard XDR baselines. Moving beyond static permission lists, Koi deploys behavioral profiling within the workspace runtime. By actively intercepting unauthenticated background tasks and blocking unauthorized file-system reads, it stops automated data exfiltration in real time.

#3. Establish guardrails for automated package updates on endpoints

Developers prioritize speed, often allowing software packages to auto-update on their endpoints the moment a new version appears. Attackers weaponize this supply chain vulnerability, as seen in the May 2026 Team PCP attack where 3,800 GitHub repositories were compromised in just 36 minutes via poisoned auto-updates. Securing agentic endpoints against these rapid breaches requires behavior-based inspection within the active workspace context. Koi operates at this layer by providing safe deployment buffers that automate version cooldowns, blocking bleeding-edge updates until they are vetted. By continuously auditing process creation within the IDE runtime, Koi instantly drops unauthorized remote connections before malicious payloads can exfiltrate credentials from the endpoint.  

#4. Enforce principle of least privilege for AI agents

AI coding assistants inherit the privileges of whoever deployed them. In practice, that means read access to production databases, write access to core repositories, and access to every secret in environment files and configuration directories. To restrict this excessive access, Koi applies dynamic sandboxing directly to AI agent processes at the kernel level. It enforces a strict zero-trust boundary that segregates sensitive workspace vectors, preventing agents from pulling data outside their approved scope without interrupting developer workflows.

#5. Maintain continuous endpoint posture management

Signature-based scanning only stops known threats. Sophisticated repository attacks often arrive as functional, high-rated software that carries no known bad signature. Koi’s research into the DarkSpectre campaign found eight browser extensions, all carrying “featured” badges from Google and Microsoft, installed by over 8 million users, silently harvesting every conversation from ChatGPT, Claude, and Gemini in the background. Koi addresses this by operating upstream: scanning marketplace listings every hour, using LLM-driven code analysis to compare what software promises against what its code does, sandboxing it, and scoring the risk before it ever reaches the endpoint.

Summary

Securing the modern enterprise is no longer about patching individual gaps. As AI agents redefine the workforce, Agentic Endpoint Security (AES) is now a strategic imperative for every CISO. By establishing a mandatory control plane for the AI-native workspace, AES ensures that your organization can scale engineering velocity without ever compromising enterprise integrity. 

Ready to secure the future of your software stack? See how Koi Agentic Endpoint Security delivers complete visibility, risk scoring, and real-time prevention across every endpoint in your enterprise.

For years, I have been saying that cybersecurity is no longer a technology problem. It has become a business leadership challenge.

Yet, despite record levels of spending, ever-growing security teams, increasingly sophisticated technologies and a constant stream of new regulations, organizations continue to suffer major cyber incidents with alarming regularity. Every week seems to bring news of another ransomware attack, supply chain compromise or data breach affecting organizations that many would have assumed were well protected.

The obvious conclusion is that we are asking the wrong questions.

Too many executive teams remain preoccupied with the latest threat actor, the newest security product the CISO wants to buy or the latest vulnerability making headlines. Those issues matter, but they are not what should be keeping CEOs awake at night.

In my view, there are three far more fundamental issues that deserve the attention of every chief executive.

1. Corporate complexity, and the widening gap between business leadership and cybersecurity reality

Perhaps the biggest cybersecurity risk facing large organizations today is not technical at all.

It is the growing disconnect between executive perception and operational reality.

Many boards genuinely believe their organizations are reasonably well protected. They receive regular dashboards showing improving maturity scores, increasing compliance levels, falling vulnerability counts and reassuring traffic-light reports.

Unfortunately, cyber attackers do not read dashboards.

Behind those executive reports often lies an increasingly complex technology landscape, thousands of unmanaged digital assets, ageing infrastructure, rampant shadow IT, fragmented ownership, inconsistent governance and security teams struggling to keep pace with relentless business change.

The problem is rarely a lack of effort.

It is that corporate complexity has reached a level where traditional governance mechanisms are no longer capable of providing an accurate picture of organizational resilience.

Executives believe they understand the level of cyber risk they face because they receive regular reports. Those reports often measure activity rather than resilience.

Governance committees end up debating around another percentage point of phishing awareness or vulnerability remediation, while fundamental issues remain unaddressed in the background.

2. Organizational inertia, and the need for executive structure to evolve faster

Cyber criminals continue to evolve rapidly. Large organizations generally do not.

This is the second issue that should concern every CEO.

Throughout my career, I have observed organizations repeatedly responding to new cyber threats by adding another technology platform, another monitoring capability, another compliance framework or another governance committee.

Very rarely do they stop to redesign how cybersecurity operates.

The result is what I described several years ago as the “Cybersecurity Spiral of Failure”.

• As complexity and regulation increase, organizations invest in more security products.
• More products create more complexity.
• More products and greater complexity generate more alerts.
• More alerts require more analysts.
• More analysts produce more reports.
• More reports continue to build up executive confidence.
• Meanwhile, the underlying structural weaknesses remain largely unchanged, technical debt piles up and costs escalate.

And when the inevitable breach eventually happens, reality reveals itself, but distrust also sets in between senior executives and security teams.

This is not a funding problem. Nor is it a skills problem. It is fundamentally an operating model problem.

Many organizations continue trying to solve twenty-first century challenges using governance, accountability, organizational and reporting structures designed twenty-five years ago.

The cybersecurity function itself has evolved dramatically. Many executive structures have not.

This organizational inertia extends beyond technology: It affects budgeting cycles, investment priorities, procurement processes, accountability models and decision-making speed.

Cyber attackers innovate every day. Organizational change often takes years.

That imbalance should worry every CEO.

3. Accelerating technological disruption, and how it challenges organizations in areas where they are intrinsically weak

The third issue is potentially the most significant over the coming decade.

• Artificial intelligence, autonomous agents and machine identities
• Software supply chain complexity.
• Quantum computing, and post-quantum cryptography

Each of these developments represents far more than another technical trend.

Together, they fundamentally change the dynamics of cybersecurity.

Artificial intelligence is transforming countless business processes. At the same time, it is also increasing both the speed and sophistication of cyber-attacks while simultaneously transforming defensive capabilities.

Organizations have become increasingly dependent on software ecosystems that extend far beyond their own direct control. Engaging with the supply chain in ways that lead to a genuine appreciation of the risks involved has become a key challenge for most cybersecurity practices.

Quantum computing may eventually invalidate much of today’s cryptographic algorithms, forcing organizations into one of the largest technology efforts since Y2K — but without the benefit of a fixed deadline and faced by a problem that is considerably more complex and hyperconnected IT estates that have little to do with those of the late 90s.

None of these challenges can be solved overnight: They require clear governance, sustained investment over a few years and cross-functional organizational coordination.

Most large organizations are weak on those three fronts: This is precisely why CEOs should be focusing on them now.

Waiting until some of those risks become obvious will almost certainly be too late.

Businesses naturally prioritise immediate commercial pressures. Cybersecurity often involves preparing for risks whose timing remains uncertain.

But one of the greatest leadership failures I keep seeing remains the inability of organizations to act decisively on known unknowns.

That tension explains why many organizations delay action until external events force them to respond. Unfortunately, cybersecurity rarely rewards late action.

Leadership will determine who succeeds

Cybersecurity discussions still frequently focus on technology. I believe they should focus far more on leadership.

Technology will continue evolving. Threat actors will continue adapting. Regulations will continue expanding. Those developments are inevitable.

What remains within the control of every CEO is how their organization responds.

Does cybersecurity remain an IT issue? Or is it recognised as an integral part of business resilience?

How is cybersecurity accountability assigned at executive level? Or does it still rest largely with a CISO hidden in the organization?

Does the board spend sufficient time discussing resilience? Or does cybersecurity appear only when approving budgets or reviewing incidents?

These questions will increasingly determine organizational success.

The companies that navigate the next decade successfully will not necessarily be those spending the most on cybersecurity. Nor will they be those deploying the latest security technologies first.

They will be the organizations whose leadership recognises that cybersecurity has become a permanent business capability — embedded into governance, strategy, operational decision-making and organizational culture.

That transformation cannot be delegated. It begins with the CEO.

And perhaps that is the single biggest issue that should keep every chief executive awake at night: Not when the next cyber-attack will happen, but whether their organization is evolving quickly enough on those matters to meet a threat landscape that is changing much faster than the business itself.

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

In August 2025, 126 malicious packages landed in the npm registry. Even after the community caught the initial wave, 80 of these hidden backdoors remained actively listed.

That was enough. Over 86,000 downloads. Malicious code in PhantomRaven, packages running in the production systems of Fortune 500 companies worldwide. And throughout the entire window, not a single EDR/XDR alert.

This happened because the attack surface has expanded to a layer EDR/XDR was never designed to see: VS Code extensions, local MCP servers, and rogue AI coding assistants that inherit your engineers’ valid credentials to steal data at machine speed.

To eliminate this structural vulnerability, Palo Alto Networks acquired Koi, an AI-native developer security product engineered for proactive, precision enforcement. Below we compiled a 2026 CISO checklist you can use to audit your environment and see how Koi automates each defense from day one.

#1. Gain real-time visibility into shadow AI & extensions

Your existing asset management tracks binaries and installers, but it cannot see local VS Code extensions, MCP servers, or ad-hoc Python scripts running on developer endpoints. This visibility gap was recently exposed by the MaliciousCorgi campaign, where two marketplace extensions with 1.5 million combined installs silently harvested every file a developer opened. Neither triggered any detection because they were not binaries, not executables, not anything your inventory was built to flag. To counter this, Koi closes the gap by analyzing what extensions actually do after installation, exposing hidden data-harvesting channels running inside your active workspace.

#2. Distinguish between human and autonomous agent behavior 

When a rogue AI agent exfiltrates your proprietary source code, it uses a developer’s valid credentials during normal working hours, making the session look entirely legitimate to standard XDR baselines. Moving beyond static permission lists, Koi deploys behavioral profiling within the workspace runtime. By actively intercepting unauthenticated background tasks and blocking unauthorized file-system reads, it stops automated data exfiltration in real time.

#3. Establish guardrails for automated package updates on endpoints

Developers prioritize speed, often allowing software packages to auto-update on their endpoints the moment a new version appears. Attackers weaponize this supply chain vulnerability, as seen in the May 2026 Team PCP attack where 3,800 GitHub repositories were compromised in just 36 minutes via poisoned auto-updates. Securing agentic endpoints against these rapid breaches requires behavior-based inspection within the active workspace context. Koi operates at this layer by providing safe deployment buffers that automate version cooldowns, blocking bleeding-edge updates until they are vetted. By continuously auditing process creation within the IDE runtime, Koi instantly drops unauthorized remote connections before malicious payloads can exfiltrate credentials from the endpoint.  

#4. Enforce principle of least privilege for AI agents

AI coding assistants inherit the privileges of whoever deployed them. In practice, that means read access to production databases, write access to core repositories, and access to every secret in environment files and configuration directories. To restrict this excessive access, Koi applies dynamic sandboxing directly to AI agent processes at the kernel level. It enforces a strict zero-trust boundary that segregates sensitive workspace vectors, preventing agents from pulling data outside their approved scope without interrupting developer workflows.

#5. Maintain continuous endpoint posture management

Signature-based scanning only stops known threats. Sophisticated repository attacks often arrive as functional, high-rated software that carries no known bad signature. Koi’s research into the DarkSpectre campaign found eight browser extensions, all carrying “featured” badges from Google and Microsoft, installed by over 8 million users, silently harvesting every conversation from ChatGPT, Claude, and Gemini in the background. Koi addresses this by operating upstream: scanning marketplace listings every hour, using LLM-driven code analysis to compare what software promises against what its code does, sandboxing it, and scoring the risk before it ever reaches the endpoint.

Summary

Securing the modern enterprise is no longer about patching individual gaps. As AI agents redefine the workforce, Agentic Endpoint Security (AES) is now a strategic imperative for every CISO. By establishing a mandatory control plane for the AI-native workspace, AES ensures that your organization can scale engineering velocity without ever compromising enterprise integrity. 

Ready to secure the future of your software stack? See how Koi Agentic Endpoint Security delivers complete visibility, risk scoring, and real-time prevention across every endpoint in your enterprise.

For years, I have been saying that cybersecurity is no longer a technology problem. It has become a business leadership challenge.

Yet, despite record levels of spending, ever-growing security teams, increasingly sophisticated technologies and a constant stream of new regulations, organizations continue to suffer major cyber incidents with alarming regularity. Every week seems to bring news of another ransomware attack, supply chain compromise or data breach affecting organizations that many would have assumed were well protected.

The obvious conclusion is that we are asking the wrong questions.

Too many executive teams remain preoccupied with the latest threat actor, the newest security product the CISO wants to buy or the latest vulnerability making headlines. Those issues matter, but they are not what should be keeping CEOs awake at night.

In my view, there are three far more fundamental issues that deserve the attention of every chief executive.

1. Corporate complexity, and the widening gap between business leadership and cybersecurity reality

Perhaps the biggest cybersecurity risk facing large organizations today is not technical at all.

It is the growing disconnect between executive perception and operational reality.

Many boards genuinely believe their organizations are reasonably well protected. They receive regular dashboards showing improving maturity scores, increasing compliance levels, falling vulnerability counts and reassuring traffic-light reports.

Unfortunately, cyber attackers do not read dashboards.

Behind those executive reports often lies an increasingly complex technology landscape, thousands of unmanaged digital assets, ageing infrastructure, rampant shadow IT, fragmented ownership, inconsistent governance and security teams struggling to keep pace with relentless business change.

The problem is rarely a lack of effort.

It is that corporate complexity has reached a level where traditional governance mechanisms are no longer capable of providing an accurate picture of organizational resilience.

Executives believe they understand the level of cyber risk they face because they receive regular reports. Those reports often measure activity rather than resilience.

Governance committees end up debating around another percentage point of phishing awareness or vulnerability remediation, while fundamental issues remain unaddressed in the background.

2. Organizational inertia, and the need for executive structure to evolve faster

Cyber criminals continue to evolve rapidly. Large organizations generally do not.

This is the second issue that should concern every CEO.

Throughout my career, I have observed organizations repeatedly responding to new cyber threats by adding another technology platform, another monitoring capability, another compliance framework or another governance committee.

Very rarely do they stop to redesign how cybersecurity operates.

The result is what I described several years ago as the “Cybersecurity Spiral of Failure”.

• As complexity and regulation increase, organizations invest in more security products.
• More products create more complexity.
• More products and greater complexity generate more alerts.
• More alerts require more analysts.
• More analysts produce more reports.
• More reports continue to build up executive confidence.
• Meanwhile, the underlying structural weaknesses remain largely unchanged, technical debt piles up and costs escalate.

And when the inevitable breach eventually happens, reality reveals itself, but distrust also sets in between senior executives and security teams.

This is not a funding problem. Nor is it a skills problem. It is fundamentally an operating model problem.

Many organizations continue trying to solve twenty-first century challenges using governance, accountability, organizational and reporting structures designed twenty-five years ago.

The cybersecurity function itself has evolved dramatically. Many executive structures have not.

This organizational inertia extends beyond technology: It affects budgeting cycles, investment priorities, procurement processes, accountability models and decision-making speed.

Cyber attackers innovate every day. Organizational change often takes years.

That imbalance should worry every CEO.

3. Accelerating technological disruption, and how it challenges organizations in areas where they are intrinsically weak

The third issue is potentially the most significant over the coming decade.

• Artificial intelligence, autonomous agents and machine identities
• Software supply chain complexity.
• Quantum computing, and post-quantum cryptography

Each of these developments represents far more than another technical trend.

Together, they fundamentally change the dynamics of cybersecurity.

Artificial intelligence is transforming countless business processes. At the same time, it is also increasing both the speed and sophistication of cyber-attacks while simultaneously transforming defensive capabilities.

Organizations have become increasingly dependent on software ecosystems that extend far beyond their own direct control. Engaging with the supply chain in ways that lead to a genuine appreciation of the risks involved has become a key challenge for most cybersecurity practices.

Quantum computing may eventually invalidate much of today’s cryptographic algorithms, forcing organizations into one of the largest technology efforts since Y2K — but without the benefit of a fixed deadline and faced by a problem that is considerably more complex and hyperconnected IT estates that have little to do with those of the late 90s.

None of these challenges can be solved overnight: They require clear governance, sustained investment over a few years and cross-functional organizational coordination.

Most large organizations are weak on those three fronts: This is precisely why CEOs should be focusing on them now.

Waiting until some of those risks become obvious will almost certainly be too late.

Businesses naturally prioritise immediate commercial pressures. Cybersecurity often involves preparing for risks whose timing remains uncertain.

But one of the greatest leadership failures I keep seeing remains the inability of organizations to act decisively on known unknowns.

That tension explains why many organizations delay action until external events force them to respond. Unfortunately, cybersecurity rarely rewards late action.

Leadership will determine who succeeds

Cybersecurity discussions still frequently focus on technology. I believe they should focus far more on leadership.

Technology will continue evolving. Threat actors will continue adapting. Regulations will continue expanding. Those developments are inevitable.

What remains within the control of every CEO is how their organization responds.

Does cybersecurity remain an IT issue? Or is it recognised as an integral part of business resilience?

How is cybersecurity accountability assigned at executive level? Or does it still rest largely with a CISO hidden in the organization?

Does the board spend sufficient time discussing resilience? Or does cybersecurity appear only when approving budgets or reviewing incidents?

These questions will increasingly determine organizational success.

The companies that navigate the next decade successfully will not necessarily be those spending the most on cybersecurity. Nor will they be those deploying the latest security technologies first.

They will be the organizations whose leadership recognises that cybersecurity has become a permanent business capability — embedded into governance, strategy, operational decision-making and organizational culture.

That transformation cannot be delegated. It begins with the CEO.

And perhaps that is the single biggest issue that should keep every chief executive awake at night: Not when the next cyber-attack will happen, but whether their organization is evolving quickly enough on those matters to meet a threat landscape that is changing much faster than the business itself.

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

Check Point has confirmed that a critical security hole in its SmartConsole management tool, one that allows unauthenticated attackers to assume full admin privileges, is now being exploited in the wild. The vulnerability, CVE-2026-16232, was given a CVSS score of 9.3.

In its security alert, Check Point described the bug as one allowing an unauthenticated attacker to “obtain an application login token and use it to login via SmartConsole with full admin privileges and apply changes to the security policy and security configuration.”

The company has released a patch for the bug and also recommends that users “limit Trusted Clients, GUI clients, to trusted IP addresses/subnets.” That approach has always been a best practice, but practical networking realities today make it challenging to maintain. Check Point said that the exploit has impacted ten of its customers, all of whom it had notified directly.

Far worse than most

Frank Dickson, group VP for security at IDC, said this security hole is far worse than most.

“This hits harder than your average CVE because of where it lives,” he said. “The CVE targets the SmartConsole login on Check Point’s Security Management Server, the console that pushes policy to every gateway underneath it. Popping a gateway gets you one lock picked. Popping the management server is more like finding the One Ring: one stolen token to rule every gateway it manages, no need to fight each one individually. The attacker can rewrite policy, open new VPN paths and kill the logging.”

In an interview with CSO Online, Lotem Finkelstein, vice president of research at Check Point, said that the company learned of the vulnerability on Sunday, emailed customers the same day, and released the patch within 72 hours.

But when his team re-reviewed earlier logs, knowing what to look for, they spotted this hole being attacked as early as April, Finkelstein said.

The fact that, over the course of three months, the team only found ten organizations under attack, indicated that it has been very difficult for the attacker to find vulnerable systems, he noted; customers were, in the main, using secure settings to protect themselves.

Nonetheless, Finkelstein said, Check Point considers this hole to be “a severe vulnerability.”

Challenges of IP address restrictions

While it can be technically challenging to keep the IP address allowlists that Check Point recommends current, given DHCP’s ability to easily change those addresses, Assaf Morag, a cybersecurity researcher at Flare, noted that specifically limiting access to a management console is far more critical than limiting overall external access.

“Implementing Trusted Clients as a per-IP allowlist is impractical,” he said, but that is not the case with restricting management access. “The more scalable solution is to restrict access based on trusted administrative network segments such as VPN pools, management VLANs, or jump hosts rather than maintaining lists of individual DHCP-assigned client addresses,” he explained. “That gives you the security benefit without creating a full-time administrative task. Maintaining allowlists for individual hosts is much more practical when those hosts have stable, predictable IP addresses, rather than dynamically assigned DHCP addresses.”

Pieter Arntz, malware intelligence researcher at Malwarebytes, also noted that the constantly changing nature of global IP addresses can prove annoying to IT teams. Stressing that he is not familiar with Check Point’s specific settings, he noted, “Certain settings are a nuisance when applied strictly, and at some point the IT staff gets tired of constantly tweaking and they abandon the most secure path.”

Ideal platform for long-term attacks

Mike Wilkes, enterprise CISO at Aikido Security,  agreed that the severity and exposure of this hole is alarming.

“This is exactly the kind of vulnerability that keeps CISOs awake at night because it strikes at the one system that is supposed to stand between the attacker and everything else. An authentication bypass that grants administrative control of a perimeter firewall isn’t just another CVE to patch. It’s an invitation for an adversary to rewrite the rules of the network itself,” he said. “The uncomfortable reality is that nobody runs a CrowdStrike agent on their firewall. Once an attacker owns an edge device, they gain a uniquely privileged position that often falls outside the visibility of traditional endpoint security, making it an ideal platform for persistence, credential theft, traffic manipulation, and long-term espionage.”

IDC’s Dickson strongly encouraged CISOs to deploy the patch, not to just change settings to mitigate the issue. 

“Apply the actual hotfix,” he said. “Don’t just restrict Trusted Client IPs and call it done. That’s a stopgap, not a fix. Any internet-facing management console, Check Point or otherwise, is a five-alarm architecture problem independent of this CVE.”

And, he added, “since attackers here can disable logging, audit admin activity going back before the bug surfaced. Quiet logs aren’t proof nothing happened. This is the recurring theme with ‘single pane of glass’ security tools: the console built to make everything easier to run is also the one thing you really don’t want someone else driving.”

Der heimliche Cybercrime-Akt zweier KI-Modelle von OpenAI hat weltweit ein enormes Echo in Mainstream– und sozialen Medien hervorgerufen. Der Vorfall dürfte die Debatte über die allgemeine KI-Sicherheit und den verantwortungsvollen Umgang mit der Technologie neu befeuern.

Doch der Incident wirft auch spezifische Fragen auf. Etwa, wie genau die OpenAI-Modelle es geschafft haben, ihrer Sandbox zu entkommen und warum das beim ChatGPT-Erfinder zunächst niemandem aufgefallen ist. Oder, wie andere Unternehmen solche und ähnliche Vorkommnisse künftig verhindern können. Dazu haben wir die Einschätzung von Branchenexperten und Analysten eingeholt.

Zunächst werfen wir aber noch einen kurzen Blick darauf, was sich eigentlich abgespielt hat. Falls Sie bereits informiert sind, können Sie alternativ auch das nachfolgende Meme konsumieren, um sich den Vorfall noch einmal auf unkonventionellere Art und Weise vor Augen zu halten.

Der autonome Hugging-Face-Hack

Die KI-Plattform Hugging Face meldete Mitte Juli einen Cyberangriff auf ihre Produktions-Infrastruktur. Diese wurde offenbar vollständig autonom von einem agentenbasierten KI-System gefahren, das sich dabei sowohl Zugriff auf interne Datensätze als auch auf Zugangsdaten verschaffen konnte.  

Wie sich im Rahmen der folgenden Untersuchung herausstellte, stammte die autonom hackende KI von OpenAI. Eigentlich wollte der KI-Pionier lediglich zwei seiner neuen Modelle – GPT 5.6 Sol sowie ein nicht näher spezifiziertes Pre-Release-Modell – innerhalb einer Sandbox mit dem Benchmarking-Tool ExploitGym testen.

Die Aufgabe für die KI: Schwachstellen in tragfähige Exploits zu verwandeln. Die Testumgebung selbst war OpenAI zufolge mit beschränktem Netzwerkzugriff ausgestattet. Die KI sollte lediglich auf einen intern gehosteten Drittanbieter-Service zugreifen können, der als Proxy und Cache für eine Package-Registry fungierte. Die Guardrails auf Modellebene waren für den Test laut dem KI-Unternehmen reduziert worden.

Das war der KI aber offenbar nicht genug: Sie verkettete zunächst einige zuvor unbekannte Schwachstellen in der Testumgebung, um sich uneingeschränkten Internet-Zugriff zu verschaffen, wie OpenAI in einem Blogbeitrag offenlegt: „Mit diesem Zugriff führten unsere Modelle in unserer Forschungsumgebung eine Reihe von Privilege-Escalation- und Lateral-Movement-Aktionen aus, bis sie eine Node mit Internetzugang erreichten.“

Weil die OpenAI-Modelle bei Hugging Face offenbar Lösungen für ihre ExploitGym-Aufgaben vermuteten, suchten sie nach Möglichkeiten, Zugriff auf diese zu erhalten. Und fanden sie dann auch, wie OpenAI darlegt: „In einem Beispiel verkettete das Modell mehrere Angriffsvektoren, darunter gestohlene Zugangsdaten und Zero-Day-Schwachstellen, um auf den Servern von Hugging Face einen Remote-Execution-Pfad zu finden.“

Das Security-Team von OpenAI konnte diese Vorgänge im Nachgang identifizieren und schloss sich daraufhin mit dem Team von Hugging Face zusammen, welches die Attacke seinerseits bereits identifiziert und (mit einigen Anlaufschwierigkeiten) eingedämmt hatte.

„Wir betrachten dies als beispiellosen Cybervorfall mit hochentwickelten Fähigkeiten und reagieren entsprechend. Wir teilen zu diesem Zeitpunkt vorläufige Erkenntnisse, damit Sicherheitsverantwortliche nachvollziehen können, was passiert ist, und besser einschätzen können, wozu die Modelle inzwischen in der Lage sind“, schreibt OpenAI in seinem Blog – und verspricht, weitere Details zu veröffentlichen, sobald diese vorliegen.

KI-Ausbruch bei OpenAI – so reagieren Experten

Branchenexperten und Analysten bewerten den schlagzeilenträchtigen Incident um OpenAI und Hugging Face folgendermaßen:

• Alexei Balaganski, Lead Analyst bei KuppingerCole: „Dieser Vorfall sollte nicht als ‚Rogue AI‘-Geschichte betrachtet werden. Das Modell hat exakt das getan, wofür agentische Systeme gemacht sind: Es hat sich allen verfügbaren Tools und Wegen bedient, um das ihm gesetzte Ziel zu erreichen. Die Sicherheitsvorkehrungen, die es normalerweise in Zaum gehalten hätten, wurden von OpenAI selbst zu Testzwecken deaktiviert. Darin besteht die wahre Lektion.“
• Jonathan Care, Lead Analyst und AI Practice Lead bei KuppingerCole: „Es geht bei diesem Vorfall nicht darum, dass eine KI ausgebrochen ist und zum Angreifer wurde. Wir wussten, das würde passieren. Bemerkenswert ist allerdings, dass die Verteidiger – in diesem Fall das Team von Hugging Face – keine kommerziellen KI-Modelle nutzen konnten, um den Angriff zu analysieren. Denn deren Guardrails sorgen dafür, dass kein Exoploit-Code verarbeitet werden kann.“
• Gerald Beuchelt, CISO bei Acronis: „Der Vorfall verdeutlicht eine zentrale Herausforderung für Incident-Response-Teams: Angreifer sind nicht an Nutzungsrichtlinien gebunden. Verteidiger können hingegen an die Grenzen ihrer eigenen Tools stoßen, wenn diese genau jene Daten nicht verarbeiten, die für eine Untersuchung erforderlich sind. Im Ernstfall können daraus Verzögerungen mit unmittelbaren operativen Folgen entstehen.“
• Sabine Frömling, Experten-Autorin und Cybersecurity-Beraterin: „Der eigentliche Sicherheitsvorfall war nicht die KI – sondern die Sandbox, die aus Versehen eine Tür zum Internet hatte. Man hat ein Raubtier freigelassen und dem Zaun die Schuld gegeben.“
• Martin Zugec, Technical Solutions Director bei Bitdefender: „Was meiner Meinung nach für KI-generierte Malware galt, untermauert auch dieser Vorfall: Die Bedrohung ist real, KI ist aber keine Magie. Wer glaubt, es mit einer neuartigen Superwaffe zu tun zu haben, wartet auf eine neuartige Gegenmaßnahme. Wer jedoch erkennt, dass es sich um bereits bekannte, aber unerbittlich angewandte Angriffstechniken handelt, weiß bereits, was zu tun ist.“
• Richard Werner, Cybersecurity Platform Lead Europe bei TrendAI: „Das Narrativ von der ‚eigenmächtig handelnden KI‘ ist effizient darin, Verantwortung abzuwälzen. Das ist, als würden Sie eine autonome Waffe bauen, diese auf einem vermeintlich sicheren Testgelände erproben, sie außer Kontrolle geraten und jemanden treffen lassen – und der Welt anschließend erklären, die Waffe habe eigenständig gehandelt. Das ist zwar technisch korrekt. Dennoch bleibt es Ihre Waffe, Ihr Testgelände und Ihr Versagen.“

Was Unternehmen jetzt tun sollten

IT- und Sicherheitsentscheider können aus dem Hugging-Face-Hack mehrere Lektionen ziehen. Etwa, dass Sicherheitsvorkehrungen auf Modellebene nicht als primäre Security-Grenze für KI-Agenten geeignet sind, wie Biswajeet Mahapatra, Principal Analyst bei Forrester, festhält: „Prompt-Guardrails sind keine Sicherheits-, sondern Verhaltenskontrollmaßnahmen. Und diese können versagen, umgangen oder absichtlich deaktiviert werden.“

Der Forrester-Analyst rät Unternehmen deshalb dazu, KI-Agenten als hochriskante, nicht-menschliche Identitäten zu behandeln – und jeden einzelnen in einer isolierten Umgebung zu betreiben, in der Datenzugriff auf den jeweiligen Task beschränkt bleibt und die Zugangsdaten selbst möglichst schnell ablaufen: „Das sorgt für einen akzeptablen ‚Blast Radius‘: Wird ein Agent kompromittiert, kann er nur einen einzigen Workflow, Datensatz oder eine einzige Anwendung beeinträchtigen. Anstatt die gesamte Unternehmensinfrastruktur.“

Sanchit Vir Gogia, Chefanalyst bei Greyhound Research, warnt an dieser Stelle davor, (Drittanbieter-)Services unter den Tisch fallen zu lassen: „Dienste, die auf Package Registries, Update-Systeme oder andere externe Ressourcen zugreifen, können ebenfalls zu Einfallstoren werden, wenn sie nicht derselben, ausgiebigen Prüfung unterzogen werden wie der Agent selbst.“

Unabhängig davon sollten Unternehmen laut Gogia auch testen, ob ihre Containment-Grenzen auch funktionieren, anstatt sich allein auf Architekturdiagramme oder dokumentierte Richtlinien zu verlassen: „Im Rahmen dieser Tests sollte geprüft werden, ob Anmeldedaten erlangt, Trust-Grenzen überwunden und Systeme außerhalb der einem Agenten zugewiesenen Aufgabe erreicht werden können.“

KuppingerCole-Chefanalyst Care rät IT-Entscheidern und Unternehmen im Wesentlichen zu drei Maßnahmen, nämlich:

• ein fähiges Modell auf der eigenen Infrastruktur auszuführen, das unter der eigenen Kontrolle steht und mit Guardrails ausgestattet ist, die sowohl eine forensische als auch defensive Nutzung ermöglichen. Nur so ließen sich Angriffe dieser Art auch zuverlässig analysieren.
• jeden KI-Agent in der eigenen Umgebung als privilegierten Insider zu behandeln – statt als vertrauenswürdigen Benutzer: „Wenn die Modelle von OpenAI aus ihrer Sandbox ausgebrochen sind, sollten Sie davon ausgehen, dass Ihre Agenten dazu auch in der Lage sind.“
• den eigenen Incident-Response-Plan mit Blick auf Angriffe in maschineller Geschwindigkeit zu aktualisieren: „Hugging Face hatte einige Tage Zeit, um zu reagieren, Sie haben vielleicht nur Minuten.“   

Acronis-CISO Beuchelt rät Organisationen, die gehostete LLMs für Security-Untersuchungen einsetzen, dazu, deren Grenzen möglichst bereits im Vorfeld zu durchdringen und zu testen – sowie ein alternatives Modell auf der eigenen Infrastruktur bereitzuhalten: „So reduzieren Sie das Risiko, im entscheidenden Moment keinen Zugriff auf wichtige Analysefunktionen zu haben. Gleichzeitig bleiben sensible Incident-Daten und Zugangsinformationen innerhalb der eigenen Organisation.“

Udo Schneider, Governance, Risk & Compliance Lead Europe bei TrendAI weist darauf hin, dass die beiden naheliegendsten Lösungsansätze bei Angriffen wie dem der OpenAI-KI auf Hugging Face nur teilweise greifen. Human-in-the-Loop-Kontrollen funktionierten zwar, so der Experte, skalierten aber nicht für die langlaufenden, komplexen Workflows, denen Incidents dieser Art entspringen. Ebenso könnten engere Guardrails für Modelle oder Prompts zwar helfen, stellten jedoch keine Garantie dar: „Es handelt sich um probabilistische Systeme. Eine Guardrail ist insofern keine Mauer, sondern eher eine starke Wahrscheinlichkeitsannahme.“

Deshalb komme es laut Schneider vor allem auf die unspektakulären, nicht-KI-spezifischen Kontrollen an: „Zugriffsfilterung, Kontrolle darüber, was überhaupt als Input beim Modell ankommt, Sandboxes, die tatsächlich halten, und Berechtigungskonzepte nach dem Least-Privilege-Prinzip.“

In Panik zu verfallen, wäre nach Ansicht von Martin Zugec, Technical Solutions Director bei Bitdefender, in jedem Fall die falsche Reaktion:„Was gegen solche Angriffe wirkt, ist eine präventionsorientierte Security, die den Handlungsspielraum eines Angreifers von vorneherein einschränkt – und eine verhaltensbasierte Abwehr, die bösartige Muster kennzeichnet, unabhängig davon, mit welchen Tools diese generiert wurden.“

Dieser Artikel wurde mit Material unserer Schwesterpublikation CSOonline.com angereichert.

Among a range of factors leading to a wave of tech sector layoffs in 2026 is the rapid rise of artificial intelligence and automation. Companies are reconfiguring their workforces to leverage AI for increased efficiency and reduced operating costs. This realignment and reduction is implemented even by companies reporting strong financial performance.

But it’s not just AI leading to workforce cuts. Complementing this technological shift are ongoing economic uncertainty, inflation, and higher interest rates, compounded by a chip shortage and rising energy costs. This mix is driving companies to cut costs and streamline operations for increased efficiency.

According to data compiled by Layoffs.fyi, an online tracker that keep tabs on job losses in the technology sector, 123,941 tech employees were laid off at 269 companies in 2025. The site also reports that 71,981 government employees were laid off by DOGE alone, with 182,528 total federal workers laid off.

Here is a list — to be updated regularly — of some of the most prominent technology layoffs the industry has experienced recently.

Notable tech layoffs in 2026

• Monday.com
• Microsoft
• Meta
• Cisco
• Cloudflare
• Oracle
• Atlassian
• Salesforce
• Amazon
• Ericsson

July 22, 2026: Monday.com cuts 20% of its workforce to restructure for the AI era

The company says the decision to cut 620 jobs isn’t about margins, but about creating a flatter organization built around AI agents, autonomous teams, and deeper customer engagement.

July 6, 2026: Microsoft cuts 4,800 jobs, primarily in sales and Xbox teams

As the company trims thousands of jobs, it’s also investing in embedded engineering teams and AI infrastructure. The layoffs come several weeks after the company offered 8,750 US employees voluntary retirement buyouts.

June 5, 2026: Tech industry cut 38,242 jobs in May, worst since 2024

AI was blamed for 40% of the job cuts in May, up from 7% in January, according to research by employment placement company Challenger, Gray & Christmas.

May 20, 2026: Meta cuts 8,000 jobs, around 10% of workforce

The cuts are expected to expected to hit Meta’s engineering and product teams the hardest, arriving as Meta pivots toward AI to boost efficiency across its organization, according to Yahoo Tech.

May 13, 2026: Cisco to cut nearly 4,000 jobs despite strong growth in AI, enterprise networking

Despite reporting positive financial news — including record third-quarter revenue of $15.8 billion, a 12% year-over-year increase — Cisco said it will eliminate almost 4,000 jobs.

May 7, 2026: Cloudflare to cut 1,100 jobs in AI-focused restructuring

About 20% of Cloudflare’s global workforce will be culled as the company pivots for the agentic AI era, Reuters reported.

April 1, 2026: Oracle to cut up to 30,000 jobs globally, putting enterprise support and roadmaps at risk

Oracle began laying off employees on March 31 in what could be the largest workforce reduction in the company’s history. Employees received termination emails at 6 a.m. local time with immediate system lockouts and no prior warning. (Note: in June, CNBC put the final layoff tally at 21,000.)

March 12, 2026: Atlassian cuts 1,600 jobs to fund AI and enterprise expansion

Atlassian will reduce its global workforce by approximately 10%, eliminating around 1,600 roles, as the collaboration software maker redirects capital toward artificial intelligence development and enterprise sales.

March 11, 2026: Tech layoffs surpass 45,000 in early 2026

A recent analysis by RationalFX found 45,363 job cuts globally so far this year—with roughly 68% or more than 30,000 occurring in the U.S. — highlighting ongoing workforce cuts even as many tech companies report strong revenue growth.

February 10, 2026: Salesforce lays off staffers as executive leadership churn continues

Salesforce has reduced close to 1,000 roles earlier this month across teams, including marketing, product management, data analytics, and its Agentforce AI unit, Business Insider reported, quoting employees familiar with the matter.

January 23, 2026: Amazon layoffs expected to disproportionately hit AWS and tech talent

As the market slows down, AWS and other Amazon units are preparing for another round of layoffs, which is expected to overwhelmingly impact tech talent. An email from HR leader Beth Galetti on Jan. 28 confirmed 16,000 job cuts.

January 15, 2026: Ericsson plans to shed 1,600 jobs in Sweden

 Ericsson lans to cut some 1,600 jobs in Sweden, the telecommunications equipment maker said doubling down on recent cost-saving measures that have helped it weather a prolonged downturn in telecoms spending, Reuters reports.

January 13, 2026: Meta plans to cut around 10% of employees in Reality Labs business

Meta plans to cut around 10% of the employees in its Reality Labs division who work on products including the metaverse, according to three people with knowledge of the discussions, according to The New York Times.

Layoffs in 2025

• Cisco
• Oracle
• Windsurf
• Intel
• Microsoft
• Crowdstrike
• HPE
• Autodesk
• HPE
• CISA
• Workday
• Salesforce
• Meta

Global tech-sector layoffs surpass 244,000 in 2025

Economic uncertainty, elevated interest rates, and AI adoption have driven workforce reductions across tech companies worldwide, according to a RationalFX report.

October 28, 2025: Amazon to cut 14,000 jobs across company

Amazon will reduce its overall workforce by 14,000, cutting layers of management across the company and hiring in some areas to support its “biggest bets”.

August 18, 2025: Cisco and Oracle to cut hundreds of Bay Area jobs

Tech companies Cisco and Oracle are cutting hundreds of jobs across the Bay Area. Cisco will eliminate 221 positions at its Milpitas and San Francisco offices, effective Oct. 13. Oracle is reducing 101 positions in Santa Clara on the same date 

August 5, 2025: 3 weeks after acquiring Windsurf, Cognition offers staff the exit door

Cognition, the AI coding startup that acquired rival company Windsurf three weeks ago, laid off 30 employees last week and is offering buyouts to the roughly 200 remaining employees on the team, reports The Information.

July 25, 2025, Intel to lay off 22% of workforce, CEO Tan signals ‘no more blank checks’

Intel will reduce its workforce to 75,000 employees by the end of 2025 as new CEO Lip-Bu Tan implements sweeping changes designed to transform the struggling chipmaker

July 8, 2025, Intel layoffs begin: Chipmaker is cutting many thousands of jobs

Intel has begun laying off employees across the company. CEO Lip-Bu Tan told workers back in April to expect major layoffs at Intel in the coming months as the chipmaker slashes costs and overhauls its organization after years of technical setbacks and falling sales.

July 2, 2025: Microsoft will cut 9,000 workers

Microsoft will lay off about 9,000 employees, a source familiar with the workforce cut told CNBC.  The cuts will reportedly affect less than 4% of Microsoft’s global workforce and will impact different teams, geographies and levels of experience. This is the latest in a string of cuts the tech giant has made this year.

June 17, 2025: Intel looks to factory layoffs to return to profitability

Intel will lay off up to 20% of its manufacturing sector employees starting in July, according to media reports, as the company looks for options as it seeks a return to profitability. The cuts reportedly will be made around the world, but some of the layoffs will be closer to home, according to a report in The Oregonian citing an internal company memo from Intel manufacturing Vice President Naga Chandrasekaran.

May 7, 2025: CrowdStrike to lay off 5% of staff

CrowdStrike announced a plan to cut about 500 roles, roughly 5% of its workforce, to streamline operations and reduce costs. The cybersecurity company will incur about $36 million to $53 million in charges related to the layoffs

March 6, 2025: HPE cuts 2,500 jobs, remains committed to Juniper buy

CEO Antonio Neri told Wall Street analysts that HPE would begin implementing a cost-cutting program involving layoffs of about 2,500 employees over the next 18 months. HPE employs about 61,000 people worldwide.

Feb. 27, 2025: Autodesk to lay off 9% of workforce

Software maker Autodesk is laying off 1,350 staff. With the rise of subscription and multi-year contracts billed annually, and self-service enablement, it finds it needs fewer sales staff, CEO Andrew Anagnost said in a message to employees. And with its cloud, platform, and AI products proving most profitable, it’s concentrating its staff and investments there.

Feb. 27, 2025: HP to lay off 2,000 more

As part of an ongoing restructuring, HP plans to lay off up to another 2,000 workers. In recent weeks, the company has tried — unsuccessfully — to do away with telephone support staff by forcing callers to wait for at least 15 minutes if they refuse to use self-service support resources online. The company swiftly backtracked, but wider job cuts are still on.

Feb. 21, 2025: CISA lays off 130

Government employees get laid off too: In this case, 130 workers at the US Cybersecurity and Infrastructure Security Agency are being shown the door as a result of a DOGE decision. Cybersecurity experts are concerned that the cuts will harm the international collaborations that CISA has fostered, quite apart from their concerns about the security of the DOGE layoff process itself.

Feb. 5, 2025: Workday lays off 1,750

As it moves to invest more in AI and international growth, Workday is laying off 8.5% of its workforce and disposing of unused office space. Some analysts fear the cutbacks will affect the company’s customer service — unless AI can pick up the slack.

Feb. 4, 2025: Salesforce lays off over 1,000

At the same time as it’s hiring sales staff for its new artificial intelligence products, Salesforce is laying off over 1,000 workers across the company, according to Bloomberg. As of June, 2024, the company had over 72,000 employees, according to its website. Salesforce did not comment on the report. In 2024 the company reportedly laid off around 1,000 staff too, in two waves: January and July.

Jan. 14, 2025: Meta will lay off 5% of workforce

Mark Zuckerberg told Meta employees he intended to “move out the low performers faster” in an internal memo reported by Bloomberg. The memo announced that the company will lay off 5% of its staff, or around 3,600 staff, beginning Feb. 10. The company had already reduced its headcount by 5% in 2024 through natural attrition, the memo said. Among those leaving the company will be staff previously responsible for fact checking of posts on its social media platforms in the US, as the company begins relying on its users to police content.

Tech layoffs in 2024

• Equinix
• AMD
• Freshworks
• Cisco
• General Motors
• Intel
• OpenText
• Microsoft
• AWS
• Dell

Nov. 26, 2024: Equinix to cut 3% of staff

Despite intense demand for its data center capacity, Equinix is planning to lay off 3% of its workforce, or around 400 employees. The announcement followed the appointment of Adaire Fox-Martin to replace Charles Meyers as CEO and the departures of two other senior executives, CIO Milind Wagle and CISO Michael Montoya.

Nov. 13, 2024: AMD to cut 4% of workforce

AMD will lay off around 1,000 employees as it pivots towards developing AI-focused chips, it said. The move came as a surprise to staff, as the company also reported strong quarterly earnings.

Nov. 7, 2024: Freshworks lays off 660

Enterprise software vendor Freshworks laid off around 660 staff, or around 13% of its headcount, despite reporting increased revenue and profits in its fourth fiscal quarter. The company described the layoffs as a realignment of its global workforce.

Sept. 17, 2024: Cisco lays off 6,000

After laying off around 4,200 staff in February, Cisco is at it again, laying off another 6,000 or around 7% of its workforce. Among the divisions affected were its threat intelligence unit, Talos Security.

Aug. 20, 2024: General Motors lays off 1,000 software staff

More than 1,000 software and services staff are on the way out at General Motors, signalling that it could be rethinking its digital transformation strategy. In an internal memo, the company said that it was moving resources to its highest-priority work and flattening hierarchies.

August 1, 2024: Intel removes 15,000 roles

Intel plans to cut its workforce by around 15% to reduce costs after a disastrous second quarter. Revenue for the three months to June 29 stagnated at around $12.8 billion, but net income fell 85% to $83 million, prompting CEO Pat Gelsinger to bring forward a company-wide meeting in order to announce that 15,000 staff would lose their jobs. “This is an incredibly hard day for Intel as we are making some of the most consequential changes in our company’s history,” Gelsinger wrote in an email to staff, continuing: “Our revenues have not grown as expected — and we’ve yet to fully benefit from powerful trends, like AI. Our costs are too high, our margins are too low. We need bolder actions to address both — particularly given our financial results and outlook for the second half of 2024, which is tougher than previously expected.”

July 4, 2024: OpenText to lay off 1,200

OpenText said it will lay off 1,200 staff, or about 1.7% of its workforce, in a bid to save around $100 million annually. It plans to hire new sales and engineering staff in other areas in 2025, it said.

June 4, 2024: Microsoft lays off staff in Azure division

Microsoft laid off staff in several teams supporting its cloud services, including Azure for Operations and Mission Engineering. The company didn’t say exactly how many staff were leaving.

April 4, 2024: Amazon downsizes AWS in a fresh cost-cutting round

Amazon announced hundreds of layoffs in the sales and marketing teams of its AWS cloud services division — and also in the technology development teams for its physical retail stores, as it stepped back from efforts to generalize the “Just Walk Out” technology built for its Amazon Fresh grocery stores.

April 1, 2024: Dell acknowledges 13,000 job cuts

Dell Technologies’ latest 10K filing with the US Securities and Exchange Commission disclosed that the company had laid off 13,000 employees over the course of the 2023 fiscal year; it characterized the layoffs and other reorganizational moves as cost-cutting measures. “These actions resulted in a reduction in our overall headcount,” the company said. A comparison to the previous year’s 10K filing, performed by The Register, found that Dell employed 133,000 people at that point, compared to 120,000 as of February 2024. Dell announced layoffs of 6,650 staffers on Feb. 6, but it is unclear whether those cuts were reflected in the numbers from this year’s 10K statement.

See news of earlier layoffs.

I haven’t slept much in the past few weeks. Not because of some theoretical cyber risk that keeps many executives awake, but because reality just delivered a real wake-up call to our industry — a call that every executive must answer, now.

Imagine this: A major global enterprise, a company most of us interact with indirectly every single day, wakes up to find its entire digital environment obliterated. Thousands of employees in dozens of offices and remote locations are suddenly offline. Customers are cut off, supply chains grind to a halt and regulators are notified with a chilling admission: “We have no idea when we’ll be back.”

This wasn’t ransomware. There was no negotiation, no decryption key to buy, no easy way out. It was destruction — deliberate, coordinated and geopolitically motivated — not monetary.

As a chief customer officer who’s worked with countless customers on cyberattack risks, my perspective hits a bit differently than a CISO or a CTO. I see the aftermath, not just the attack surface. I see the faces behind the tickets, the operations team locked out of their own systems, the support agent answering panicked calls at dawn. And I ask: How many organizations have actually stress-tested their response to this scenario — not a hypothetical, but this very real, lights-out event? Here’s what every leader needs to confront today:

Recovery is not just a technical exercise

The first assumption to break during a real crisis is the belief that recovery is purely technical.

Many organizations have done tabletop exercises and have a backup and recovery playbook, so they feel prepared. They can point to backup windows, retention schedules and immutability controls. The moment a true blackout happens, a different reality surfaces. The people who own the recovery steps either do not know each other, lack the authority to make decisions without supervisor approval or need guidance from offline systems.

The reality is that technical infrastructure almost always holds up better than human infrastructure. Organizations have built their recovery strategy around the assumption that someone competent will be awake, available and empowered when a cyber event happens.

Still, backups are only as good as their independence. Let’s be blunt: If your recovery infrastructure shares identity, authentication or network trust with your Microsoft tenant (such as Azure, Microsoft 365 or Teams), you don’t actually have a recovery plan; you have a false sense of one — and a liability. A recent survey found that while 90% of organizations express confidence in their ability to recover from a cyber incident, fewer than one in three ransomware victims fully recovered their data.

True resilience means immutable, air-gapped backups, untouchable by the same compromise. Anything less is an illusion. I talk to customers about their recovery plans constantly. The customers who have rehearsed all scenarios sleep soundly. Those who haven’t? They’re rolling the dice.

Most business continuity plans ignore ‘total blackout’

I’ve reviewed hundreds of business continuity plans. Almost all assume partial failures — a region, an application, a data center. But what if every system, in every country, goes dark simultaneously? That’s an entirely different playbook. If your team hasn’t run a drill for a global, simultaneous outage, you’re not prepared. The probability is low, but the cost of being unready is existential.

Connected devices, OT systems, field hardware, partner integrations — they all plug into your enterprise network. When the core collapses, it’s not just IT at risk. It’s operational technology, physical safety systems and in regulated sectors, potentially human lives. Understanding and testing those interdependencies is non-negotiable.

This is also where boards need to change the conversation. A study found that only 5% of companies have cybersecurity experts on their board of directors. Recovery time objectives (RTOs) should not be buried in technical appendices. It’s all jargon to boards. That makes translation essential. RTOs must be explained in terms of business impact. “We can recover in four hours” is a technical statement. “Every hour of downtime costs us $2.3M and creates regulatory exposure in three jurisdictions” is a board statement.

That is the level of clarity leaders need.

The most prepared organizations do not wait for an incident to educate the board. They bring the conversation forward proactively. They frame recovery in business terms: revenue, regulatory standing, customer trust and brand reputation.

The most effective framing is often simple. Show the most critical systems. Show what happens if each one is down for one hour, four hours, 24 hours and 72 hours. Show the current recovery capability against each and then show the gap.

If your board is not demanding real answers, your business continuity strategy is likely underfunded and your business is exposed. This is a risk conversation worth forcing because the consequences do not stay inside IT. They can show up in customer churn or missed revenue and ruin an organization’s reputation.

Threat intelligence must be actionable, not archived

Geopolitical attacks, hacktivist campaigns and nation-state targeting aren’t abstract threats. They are active risks, and that intelligence cannot languish in the security team’s inbox. Executive leadership must be looped in — and immediately — so gaps can be closed before they’re exploited. Too often, intelligence enters the security operations function and never reaches the teams responsible for recovery infrastructure or executive decision-making.

If a threat actor is targeting a specific class of backup agents, the team responsible for those agents needs to know now, not two weeks from now. If intelligence suggests destructive activity against a sector, recovery owners need to validate isolation, access paths and restoration procedures immediately. If geopolitical tension increases the likelihood of targeting, executive leadership needs to understand what exposure exists and what actions are being taken. The organizations that survive aren’t just the best at incident response. They’re the ones who anticipated, rehearsed and invested before the attack.

Part of investing in a recovery strategy requires closing the loop between signal and action. The most prepared organizations have already mapped their critical recovery dependencies to specific threat categories. When intelligence touches one of those categories, there is a named owner and a clear set of actions. No guessing or forwarding emails into the void is needed because the distance between the warning and the employees’ ability to do something is shortened.

Looking ahead, the conversation will continue to evolve beyond traditional cyber response. Because in an AI-enabled enterprise, the new question is whether the data within those systems can still be trusted. When AI systems make decisions based on enterprise data, the attack surface becomes the data’s accuracy. A threat actor who quietly corrupts a dataset over 90 days before a recovery event has done more damage than just downtime. They can poison the inputs driving decisions across the business.

Regardless of how AI will change threat intelligence and cyber response, these principles remain the same. Know your problem, whether structural or technological. Ensure your human infrastructure keeps pace with your technical infrastructure, with clear cross-functional ownership and the tools and knowledge to act autonomously. Communicate with your boards often — and correctly.

Let’s not wait for the next headline to ask, “Are we ready?” Have those conversations now. Test your assumptions. Close your gaps. Because in today’s threat landscape, resilience isn’t IT’s job — it’s everyone’s mandate.

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

Ein Cyber Risk Assessment unterstützt dabei, potenzielle Bedrohungen und Schwachstellen für wichtige digitale und physische Unternehmens-Assets zu identifizieren, zu bewerten und zu priorisieren. Trotzdem stolpern in diesem Zusammenhang immer noch viele CISOs und Sicherheitsentscheider über Fallstricke, die sie daran hindern, ihre Risk-Assessment-Ziele vollumfänglich zu erreichen.

Welche das konkret sind und wie man sie gewissenhaft meidet, haben wir im Gespräch mit Security-Experten herausgefunden.

1. Einfach nur abhaken

Die wohl größte Falle im Zusammenhang mit Risk Assessments besteht darin, diese als Checkliste zu behandeln – statt als Entscheidungshilfe, die mit realem Business Impact oder Threat-Szenarien verknüpft ist. Shirsendu Mondal, Security-Forscher an der University of North Carolina, klärt auf: „Wenn sich Ihre Risikobewertung nur noch darum dreht, irgendwelche Kästchen abzuhaken, verlieren Sie die Fähigkeit, die tatsächlichen Risiken einer Umgebung zu Tage zu fördern. Das Ziel eines solchen Assessments sollte jedoch sein, aufzudecken, an welchen Stellen tatsächlich eine Gefährdungslage besteht.“ 

Der beste Weg, diese „Selbstzufriedenheits“-Falle zu umgehen, besteht laut dem Forscher darin, einen kontextorientierten Ansatz zu fahren: „Fragen Sie konkret danach, wo sich die betreffende Ressource befindet, wer darauf zugreifen kann, welche Daten sie berührt, wie wichtig sie für den Betrieb ist und was passiert, wenn sie ausfällt. Risiken sollten stets mit den geschäftlichen Auswirkungen korreliert werden – nicht bloß mit technischen Erkenntnissen.“

Eben, weil Risiken seiner Ansicht nach mehr sind als nur technische Probleme, empfiehlt Mondal Security-Entscheidern, andere Führungskräfte aus dem Unternehmen in das Security-Gefüge zu integrieren – etwa aus der IT und dem Betrieb.

2. Ergebnisse schönreden

Besonders in schwierigen Zeiten ist es das A und O, den Stakeholdern (und sich selbst) gegenüber ehrlich zu sein. Diese Auffassung vertritt auch Pablo Riboldi, CISO beim Softwareunternehmen BairesDev: „Wenn die Ergebnisse entmutigend sind, sollte man einfach zugeben, dass sich die Bedrohungslage deutlich schneller entwickelt hat, als über das bisherige Bewertungs-Framework abzusehen war.“

Anstatt einfach nur Schwachstellen-Listen zu übergeben, rät Riboldi dazu, konkrete Angriffsszenarien abzubilden: „Zum Beispiel, indem Sie die drei kritischsten Assets priorisieren und ein eingehendes Risk Assessment durchführen. So lässt sich auch ein unmittelbarer Mehrwert demonstrieren.“

3. Scope falsch einschätzen

Nicht wenige CISOs sichern Dokumentenkontrollen ab, haken Compliance-Checkboxen ab und erstellen ein Risikoregister, das den Eindruck vermittelt, dass alles in Ordnung ist. Der Schein trügt jedoch des Öfteren, wie Denis Calderone, CTO beim Sicherheitsdienstleister Suzu Labs, aus eigener Erfahrung weiß: „In solchen Fällen kommt es nicht selten vor, dass sich niemand die Mühe gemacht hat, zu testen, ob diese Kontrollen tatsächlich funktionieren. Oder, ob der Scope der Risikobewertung auch das abdeckt, worauf es wirklich ankommt.“

Der Technologieentscheider hat dazu auch ein Beispiel aus der Praxis auf Lager: „Wenn das Risk Assessment die Produktionsserver und das Unternehmensnetzwerk umfasst, der alte Dev-Rechner, ein Drittanbieter-Portal oder ein verwaister API-Endpunkt dabei aber außen vor bleiben, ist das ungünstig. Angreifer betrachten die gesamte Umgebung und finden genau den Einstiegspunkt, der zuvor als nicht bewertungswürdig erachtet wurde.“

Künstliche Intelligenz (KI) verschlimmere die Situation laut Calderone noch: Unternehmen setzten vielfach KI-Tools ein, verknüpften diese mit internen Systemen und gewährten ihnen Zugriff auf sensible Daten – ohne dass das in die Risikobewertung einfließe. Der Experte warnt: „Wenn Ihr Risk Assessment aufgesetzt wurde, bevor Ihr Unternehmen damit begonnen hat, KI in Workflows zu integrieren, ist es bereits veraltet.“

4. Annahmen nicht hinterfragen

Wenn sich die Zielsetzung einer Risikobewertung in Richtung „Hauptsache bestanden“ verschiebt, stellt das vielleicht Auditoren zufrieden. Die Unternehmensleitung könnte dadurch jedoch in die Irre geführt werden, wie Amit Basu, CIO und CISO beim Schifffahrtsunternehmen International Seaways, erklärt: „Führungskräfte und Vorstandsmitglieder sehen ein fertiges Risikoregister und gehen davon aus, dass das Unternehmen geschützt ist. Unterdessen bleiben echte Bedrohungen unberücksichtigt, weil sie nicht nahtlos in den Bewertungsrahmen passten. Dieser Fallstrick ist unsichtbar – er verbirgt sich hinter einem Dashboard.“

Nach Ansicht von Basu ist ein Risk Assessment nur so gut, wie die ihm zugrundeliegenden Annahmen: „Diese sollten Sie explizit dokumentieren und immer dann überprüfen, wenn sich das Business verändert, eine Bedrohungslage verschiebt oder ein Sicherheitsvorfall eine Lücke zu Tage fördert.“

Ein Risk Assessment, so der CISO, sei nicht als fertiges Produkt zu betrachten, sondern als lebendiger Beitrag zu einem fortlaufenden Dialog zwischen Security-Abteilung und Unternehmen.

5. Risiken nicht mit Impact verknüpfen

Probleme in den Hintergrund zu rücken oder herunterzuspielen, fällt deutlich leichter, wenn man den Zusammenhang zwischen Risiko und Business einfach ausblendet. Das erkennt auch Dan Moore, Senior Director of Strategy and Identity Standards beim CIAM-Spezialisten FusionAuth, an. Er warnt jedoch vor den Folgen dieses Gebarens: „So wird es sich diffizil gestalten, tatsächliche Risiken zu kommunizieren. Schlimmer noch: Es liefert den Mitgliedern des Security-Teams einen Vorwand, sich darüber zu beschweren, dass sie missverstanden oder nicht wertgeschätzt werden – und das beeinträchtigt die Effektivität des Teams.“

Der Manager erachtet es als wichtig, stattdessen konkret zu sein und zielgerichtet vorzugehen: „Verzichten Sie auf Angaben wie eine Patch-Compliance von 95 Prozent. Sprechen Sie stattdessen über das Risiko, das nicht gepatchte Systeme für das Unternehmen darstellen.“

Dabei seien manchen Systemen – etwa Legacy-Konstrukten, die nicht mit dem Internet verbunden sind – geringere Risiken inhärent als anderen, selbst wenn sie dieselben Patch-Probleme aufwiesen, meint Moore und empfiehlt, diese Tatsache anzuerkennen und die Reaktion entsprechend abzuwägen.  

6. Compliance mit Security verwechseln

„Compliance allein ist weder ein Garant für robuste Security, noch erfüllt sie die Mindestanforderungen für einen wirksamen Schutz“, hält Adriel Desautels, CEO der Security-Beratung Netragard, fest.

Unternehmen gerieten demnach besonders oft in diese Falle, wenn sie für Penetrationstests externe Firmen beauftragten, die sich auf Compliance konzentrieren und gleichzeitig „erstklassige Dienstleistungen“ versprechen. „In Wahrheit liefern diese oft automatisierte Scans, die als manuelle Tests getarnt sind“, meint Desautels.

Das Ergebnis sei ein falsches Sicherheitsgefühl, warnt der Manager: „Vergegenwärtigen Sie sich einfach, dass bei jedem größeren Sicherheitsvorfall der letzten zehn Jahre eine Organisation beteiligt war, die zum Zeitpunkt des Angriffs alle Compliance-Vorgaben erfüllt hatte.“

7. Risiken nicht vollständig verstehen

Unternehmen betrachten Risk Assessments oft als eine Art „Schwachstellenkatalogisierung“, bei der es darum geht, Lücken zu finden, Schweregrade zu erfassen und Audits zu bestehen. Letzteres heißt allerdings nicht, dass die Risiken auch verstanden wurden.

Geht es nach Safi Raza, Senior Director for Cybersecurity bei Fusion Risk Management, sollten sich CISOs darauf konzentrieren, technische Risikosignale mit betrieblichen Folgen zu verknüpfen: „Dazu muss man verstehen, welche Services betroffen sind, wie sich Störungen ausbreiten und was das für den Umsatz, die Kunden oder regulatorische Verpflichtungen bedeutet.“

Der Experte rät in diesem Zusammenhang dazu, zunächst von statischen Bewertungen zu einer kontinuierlichen, kontextbezogenen Risikotransparenz überzugehen, um sicherzustellen, dass Risiken nicht nur technisch verstanden werden.“ (fm)

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

A global law enforcement crackdown has seized infrastructure serving the massive phishing-as-a-service (PhaaS) group Kratos, as well resulting in the arrest of an unnamed Kratos “developer and technical administrator” in Indonesia. 

The effort was managed by German law enforcement and involved agencies from the US, Indonesia and other countries.

Although a German statement claimed that the Kratos infrastructure “has been completely disabled” and that “Kratos-supported phishing campaigns can no longer be carried out,” cybersecurity analysts and consultants question how much of a dent in enterprise phishing activity will result, and how long it will last.

“A server seizure and a single arrest overseas remove infrastructure, not the intellectual property,” said Frank Dickson, group VP for security at IDC. “PhaaS kits get cloned, forked and resold routinely, and the 1,800 Kratos customers didn’t vanish. They just lost a vendor in a market where vendors get replaced fast.”

He added, “seizing 200-plus servers and arresting the developer pulls a major supplier out of that specific niche. It doesn’t touch the broader phishing economy. For every roach that you squish, there are a hundred that you do not see.”

Noah Kenney, principal consultant at Digital 520, takes an even more pessimistic view, arguing that there might not even be that much of a short-term phishing slowdown. 

“What makes this different from a botnet or ransomware takedown is that the people running the attacks were never part of the organization. Kratos was just a vendor,” Kenney said. “The 1,800 customers who bought it still have their target lists, their sending infrastructure and whatever access they had already established. The tooling went dark, but the people phishing your employees last week are still working, shopping for a replacement that already exists. Enterprises should not read this as a drop in (likely) threat volume.”

One thing that the security community seems to agree on is that Kratos was a major player in the lucrative PhaaS space. But precisely determining the percentage of PhaaS activity controlled by Kratos is impossible, given that Kratos sold their kits to others. Security researchers even disagree on what they should call Kratos kits.

“Microsoft tracks this kit as SneakyLog, others tie it to Sneaky 2FA, and KnowBe4 disputes the lineage entirely. When the security industry cannot agree on what a kit is to be called, that is because renaming and reselling is continuous rather than something that happens after a raid,” Kenney said. “What actually changed this time is the arrest and the [shutdown of the] servers. Standing up new hosting is only a weekend of work, but replacing a developer who understood how to keep an adversary in the middle proxy stable and evasive at scale is harder.”

IDC’s Dickson added that the biggest value from the takedown is in the information gleaned from the seized servers. 

“Kratos operated in the adversary-in-the-middle category, generating convincing fake Microsoft 365 login pages that harvest session tokens and step past MFA, the exact technique behind a lot of the business email compromise activity of the past two years,” he said. “I would love to see what law enforcement does with the customer list. That, my friend, is gold.”

Regardless, Assaf Morag, a cybersecurity researcher at Flare, dubbed the German crackdown “symbolic,” given Kratos’ reach within phishing circles. 

He argued that the very nature of software makes it all but impossible to shut down in a meaningful way.

“Although this is malicious infrastructure, it is still software, and modern development and deployment practices make it relatively quick to rebuild or replicate,” he said. “Demand is likely to shift to competing providers, allowing the ecosystem to recover even if this particular operation has been disrupted.”

Pieter Arntz, malware intelligence researcher at Malwarebytes, agreed that the crackdown is disruptive but not definitive. 

“This appears to be more than a routine website seizure. The reporting points to a PhaaS platform with centralized infrastructure, subscription-style customers, and Microsoft 365 session theft / MFA-bypass tooling, so taking down the backend likely hurts many downstream affiliates at once. In that sense, it is a meaningful disruption to the phishing ecosystem, not just one campaign,” Arntz said.

But, he added, “a rebrand or partial re-emergence is plausible, which is the historical pattern for PhaaS operations. Even if the core infrastructure is gone, the code, customer lists, and operator tradecraft can survive.”

This means that customers and affiliates can shift to other phishing kits, he said, so it’s likely that the takedown will create a temporary decline in Kratos-specific activity, but probably not a lasting reduction in phishing overall.

Flavio Villanustre, CISO for the LexisNexis Risk Solutions Group, also concluded that the impact of this crackdown will be short-lived. 

“For each criminal organization that is dismantled, ten new ones pop out of nowhere. Unless there is a coordinated international effort by more than a few countries, this is a whack-a-mole exercise,” he said. “These are all loosely connected individuals and akin to a lernaean hydra, with two heads growing whenever you chop off one. Their leadership emerges from their lines organically without a real center of control. This makes it almost impossible to completely eliminate these criminal organizations.”

As the CSO grows in prominence, security leaders are increasingly earning a seat at the executive table, reporting directly to the CEO with the expectation to help drive business strategy and ensure organizational success.

Reporting to the CEO unlocks greater access and influence for security leaders, and while CSOs who report to their organization’s CIO still have clout, it’s a very different experience picking up the phone to speak directly with the CEO as a strategic partner.

Regardless of reporting structure, CSOs must clearly understand what they are being tasked to solve. That might sound simple, but making the leap to being a CEO’s direct report requires a new perspective, a different set of skills, and a business-level focus on metrics to do so.

We asked several current CSOs, CEOs, and IT staffing experts for advice on how security executives can best navigate a direct reporting relationship with their CEO. Offering insights below are George Gerchow, CSO at Bedrock Data and member of the IANS faculty; Matt Chiodi, CSO of Cerby; Chris Schueler, CEO at Cyderes; and Greg Fuller, vice president of the Technology Skills Suite at Skillsoft.

1. Understand how the CEO views your role

Most CEOs expect that, when you report directly to them, you fully own your functional area. Whether it’s cybersecurity, operations, or finance, they look to you as the expert in that domain. The CEO may have opinions, but ultimately, you are expected to lead and provide direction.

CEOs expect their CSO to be a true strategic partner, not just a risk reporter — connecting cybersecurity to revenue protection, regulatory compliance, customer trust, and operational resilience. In turn, CSOs should expect CEOs to treat governance as a strategic enabler, not a bureaucratic necessity.

2. Power up on skills vital to your organization at an executive level

On the technology side, AI and machine learning, cloud security, incident response, zero trust architecture, and governance, risk, and compliance (GRC) are the areas where threats evolve fastest and strategic leadership has the greatest impact. 

Equally important are “power skills”: communication, critical thinking, adaptability, and emotional intelligence. The ability to translate complex risk into business terms is what separates a strong CSO from a purely technical one. Skills, not titles, define effectiveness in the eyes of a CEO.

3. Take advantage of your direct access

Direct access to the CEO will enable you to influence strategy, shape resilience planning, and ensure cybersecurity is treated as a business imperative rather than a cost center. That authority is strongest when the CEO understands cybersecurity as a strategic lever, not just a technical function. 

While a direct reporting relationship gives you access to the CEO, it also comes with the responsibility to operate at that level. You need to provide clear, executive-level visibility into your cybersecurity program.

4. Brush up on business translation

A CSO who leads with business alignment will always carry more influence when they can translate risk into business language rather than technical jargon. Building programs that must survive an IPO, a FedRAMP audit, and real customer scrutiny forces you to tie security to revenue and trust.

The most valuable skill is translation — defining technical risk in terms of executive action and business impact that a CEO and a board can act on. You must build trust through transparency. These are the human skills that complement technology, creating a collaborative human-AI dynamic where leaders make faster, better-informed decisions. 

5. Treat conversations as risk assessment opportunities

Highly effective security leaders treat every business conversation as a risk conversation in disguise. That mindset is what largely separates a great CSO from a great technologist. Earn the CEO’s trust by speaking business first, security second. Translate every risk into revenue, reputation, or regulatory exposure.

Remember, a good CEO wants a translator, not an alarm system. They expect no surprises, a clear read on the risks that matter, and a security leader who helps the business move faster rather than slowing it down.

6. Define what a successful relationship should look like and put it in writing

Regardless of the reporting relationship, start by defining the end goal and putting it in writing. It will evolve over time, but having that initial clarity is critical. This is especially important when you’re new in a role and aiming to make your first 60, 90, or 120 days, and your first year, successful. In such cases, it’s essential to align early.

Do that collaboratively, and document it.

7. Prioritize trust and candor

The CEO needs to trust that the CSO isn’t sandbagging, and the CSO needs enough psychological safety to deliver bad news fast. When those conditions exist, security becomes a strategic asset — not a cost center.

To that end, focus on clear communication above all, and present yourself as part of a team, not a solo player. Stay calm under pressure during incidents, and treat people as peers rather than policing them. The leaders who last build trust before they need it.

8. Treat governance as a strategic competitive advantage

The strongest partnerships also share a commitment to governance as a competitive advantage.

Governance is the brakes that let you drive fast safely. When a CSO and CEO are aligned on that principle, the organization can innovate with AI while maintaining oversight and protecting against unnecessary risk. The result is an organization that does not just react to threats but builds resilience into how it operates.

9. Set clear goals and measure progress

Setting clear goals and measuring progress against those goals is essential. When expectations are clear, the areas you need to focus on become much clearer. It doesn’t solve every problem, but aligning early with your leadership, whether that’s a CEO or a CIO, can significantly reduce the pressure you may feel.

Also, never let your boss be surprised. This is where being clear on goals and consistently tracking both leading and lagging metrics becomes especially important, particularly in a direct reporting relationship with the CEO.

10. Be willing to endure challenge and discomfort

Finally, persistence and a willingness to endure discomfort for something that matters more than the pain itself are critical to surviving in this relationship. The role of a cybersecurity leader is often thankless. If you’re doing your job well, no one really notices.

Was ist Claude Mythos?

Claude Mythos ist ein KI-Modell, das von Anthropic entwickelt wurde und für Anwendungen in den Bereichen Cybersicherheit und Gesundheitswesen optimiert ist. Ursprünglich wurde Mythos 5 im April einer kleinen Gruppe geprüfter Technologiepartner zugänglich gemacht – im Vorfeld eines geplanten, breiter angelegten Rollouts.

Zu diesem Zweck rief das KI-Unternehmen das Projekt „Glasswing“ ins Leben, ein Konsortium, das Infrastrukturanbietern, Open-Source-Entwicklern und großen Technologieunternehmen einen begrenzten, kontrollierten Zugriff zu Mythos gewährt. Ziel der Initiative ist es, Verteidigern zu ermöglichen, Schwachstellen schneller aufzuspüren und zu beheben, als Angreifer sie identifizieren können. Das erscheint auch dringend notwendig, setzen diese doch zunehmend selbst auf KI-gestützte Werkzeuge.

Über welche Fähigkeiten verfügt Claude Mythos?

Die ersten 50 Partner von Project Glasswing konnten mithilfe von Mythos mehr als 10.000 Schwachstellen mit hohem oder kritischem Schweregrad in allen gängigen Betriebssystemen und Webbrowsern aufspüren.

So identifizierte das Modell Sicherheitslücken, die selbst den fähigsten Sicherheitsforschern jahrelang entgangen waren – etwa einen 27 Jahre alten Fehler in OpenBSD. Zudem hat Mythos bewiesen, dass es mehrere Schwachstellen miteinander verknüpfen kann.

Wie schränkt Anthropic den Zugang zu Claude Mythos ein?

Anthropic teilte bei der Vorstellung von Claude Mythos mit, es schränke die Verfügbarkeit des Spitzen-KI-Modells bewusst ein, da dessen Fähigkeiten von Angreifern leicht missbraucht werden könnten.

Im Juni wurde die Technologie dann für weitere 150 Organisationen freigegeben. Alle Mythos-Partner müssen hierbei aber zustimmen, dass ihre Daten 30 Tage lang zu Sicherheitsüberwachungszwecken gespeichert werden.

Am 15. Juni verhängte die Trump-Regierung allerdings Exportbeschränkungen für Claude Fable 5 und Claude Mythos 5. Diese sollten ausländischen Staatsangehörigen sowohl innerhalb als auch außerhalb der USA den Zugang verwehren. Am 30. Juni wurden die Beschränkungen jedoch bereits wieder aufgehoben.

Was ist Claude Fable?

Für einen breiteren Einsatzbereich bietet Anthropic Claude Fable 5 an. Das Modell basiert auf derselben technischen Grundlage wie Mythos. Es verfügt jedoch über strenge Sicherheitsmechanismen, die den Betrieb in als „riskant“ eingestuften Bereichen der Cybersicherheit einschränken. Alle als problematisch deklarierten Anfragen werden stattdessen automatisch an das ältere und weniger leistungsfähige Large Language Model (LLM) Opus 4.8 weitergeleitet.

Wie nutzen Security-Partner von Anthropic den Zugriff auf Mythos?

Cisco, einer der Projekt-Glasswing-Partner, hat seine „Foundry Security Spec“ als Open-Source-Lösung veröffentlicht. Hierbei handelt es sich um ein modellunabhängiges Framework für Sicherheitstests, das es anderen Anbietern und Sicherheitsexperten in Unternehmen ermöglichen soll, ähnliche Arbeitsabläufe zu entwickeln, ohne bei Null anfangen zu müssen.

Vor kurzem betonten Vertreter von Cisco auf einer Online-Veranstaltung, dass Verteidiger KI nutzen können, um Sicherheitsprobleme wesentlich schneller und in größerem Umfang zu identifizieren, zu bestätigen und zu beheben. Ältere Modelle, die nach dem Prinzip „eine Schwachstelle finden und patchen“ funktionieren, seien nicht mehr zeitgemäß. Dies liege daran, dass Angreifer KI einsetzen, um den Weg von der Entdeckung einer Schwachstelle bis zu deren Ausnutzung zu beschleunigen. Cisco wiederum setzt KI intern bereits in der Defensive ein, um 1,8 Milliarden Zeilen Code im gesamten Produktportfolio zu scannen.

Gleichzeitig betonen die Experten, dass kleinere Unternehmen keinen Zugriff auf eingeschränkte KI-Modelle benötigen, um ihre Sicherheit zu verbessern. In solchen Betrieben lasse sich stattdessen mehr erreichen, indem grundlegende Sicherheitsmaßnahmen optimiert werden. Hierzu zählen laut Cisco unter anderem Authentifizierung, Netzwerk-Segmentierung, Zero Trust und die Behebung aktiv ausgenutzter Schwachstellen.

Bieten andere KI-Anbieter etwas Vergleichbares zu Claude Mythos an?

Mythos ist das prominenteste Beispiel für Frontier-KI-Modelle. Mit ihnen kann die Suche nach Zero-Day-Lücken in einem Tempo und Ausmaß automatisiert werden, die weit über die Fähigkeiten menschlicher Teams hinausgeht.

Allerdings arbeiten auch etliche andere Anbieter an hochleistungsfähigen, auf Sicherheit ausgerichteten „Frontier“-KI-Modellen. Zudem gibt es andere leistungsstarke Open-Source-Modelle, die sich problemlos für die Cybersicherheitsforschung nutzen lassen. Claude Mythos ist also bei weitem nicht die einzige verfügbare Option.

So werden beispielsweise die Modelle GPT-5.4-Cyber sowie GPT-5.5 von OpenAI genutzt, um Schwachstellen zu erkennen und zu analysieren. Auch in der Malware-Analyse und der Bedrohungsmodellierung kommen sie zum Einsatz. Zugang zu diesen Technologien können Sicherheitsanbieter, Unternehmen und Forscher über das Programm „Trusted Access for Cyber“ (TAC) von OpenAI erhalten.

Zusätzlich hat das chinesische Cybersicherheitsunternehmen 360 Security Technology mit Tulongfeng ein System entwickelt, das als Gegenstück zu Anthropics „Mythos“ beschrieben wird.

Privat lassen sich leistungsstarke offene Modelle – darunter DeepSeek V3.2 von DeepSeek und Llama 4 von Meta – auf GPU-Infrastrukturen betreiben und in der Cybersicherheitsforschung einsetzen. Fugu des japanischen Anbieters Sakana AI ist eine weitere Option in dieser Kategorie.

Was kritisieren Cybersicherheitsexperten an Claude Mythos?

Kritiker aus dem Cybersecurity-Bereich räumen ein, dass Claude Mythos zweifellos hochentwickelt sei. Die Marketing-Behauptung, wonach es zuverlässig produktive IT-Systeme lahmlegen könne, übersteige jedoch die tatsächlichen Fähigkeiten.

Darüber hinaus beklagen sich Sicherheitsexperten – etwa in Podcasts – über die übertrieben restriktiven Sicherheitsmechanismen von Claude Fable: Bereits Anfragen, einen sicherheitsrelevanten Blogbeitrag zusammenzufassen oder sogar das Wort „Exploit“ zu buchstabieren, würden auf das deutlich schwächere Modell Opus 4.8 zurückgestuft. Dadurch würden selbst alltägliche Aufgaben in der Informationssicherheit unnötig erschwert.

Andere Experten warnen davor, dass Frontier-KI-Modelle anfällig für False Positives seien. Eher grundsätzlich ist die Kritik, dass das schnellere Aufspüren von mehr Schwachstellen das eigentliche Problem nicht löst, nämlich zuverlässig Sicherheitslücken zu beheben oder nicht-technische Angriffsvektoren wie Social Engineering zu verhindern.

Wie sollten CISOs auf Mythos reagieren?

Die Nachrichtendienste der „Five Eyes“ (USA, Großbritannien, Kanada, Australien und Neuseeland)  warnen davor, dass hochmoderne KI-Modelle wie Claude Mythos „sowohl offensive als auch defensive Cyber-Fähigkeiten grundlegend verändern werden“ – und zwar in einem Zeitraum von Monaten statt Jahren.

„Während KI uns dabei helfen wird, die Cyberabwehr im Laufe der Zeit zu verbessern, erhöht sie zugleich Geschwindigkeit, Ausmaß und Raffinesse von Cyberbedrohungen“, heißt es in der Erklärung der Gruppe. Unternehmen sollen daher KI nutzen, um ihre Abwehrmechanismen im Rahmen umfassenderer Strategien zur Stärkung der Cybersicherheits-Resilienz zu verbessern.

Die meisten Unternehmen seien jedoch bei weitem noch nicht darauf vorbereitet, was dies für ihre Bedrohungsmodelle bedeutet, warnt ein Experte. „Wir verfügen heute über KI-Systeme, die realistische Angriffswege über Software, Anbieter und kritische Infrastrukturen hinweg schneller abbilden können, als menschliche Angreifer sie erfassen können“, erläutert Joe Hubback, Partner und CISO beim Beratungsunternehmen Elixirr sowie ehemaliger McKinsey-Partner. Dadurch, dass „Fähigkeiten der ‚Mythos-Klasse‘ vor der breiten kommerziellen Einführung stünden, handle es sich nicht mehr um „ein Nischenproblem der Forschung“, ergänzt er. Vielmehr sei es jetzt ein Faktor, den jedes Unternehmen in sein Bedrohungsmodell einbeziehen müsse, so der Experte.

Auch ein Bericht der Cloud Security Alliance warnt davor, dass KI die Zeitspanne zwischen der Entdeckung einer Schwachstelle und deren Ausnutzung drastisch verkürzt habe. Damit seien herkömmliche Sicherheitsmodelle, die auf „Patchen und Reagieren“ basieren, überholt. Unternehmen sollten sich vielmehr auf anhaltende Wellen von Schwachstellen einstellen, die durch „Project Glasswing“ und andere Quellen mittels KI aufgedeckt werden.

„Die bei Mythos beobachteten Fähigkeiten werden schon bald breiter verfügbar sein. Dadurch wird sich die Anzahl sowie Häufigkeit komplexer, neuartiger Angriffe, denen sich Unternehmen gegenübersehen, drastisch erhöhen“, heißt es in der Warnung. Sicherheitsverantwortliche müssten daher ihre Verteidigungsstrategien auf einen „Mythos-ready“-Ansatz umstellen, der auf kontinuierlichem Schwachstellenmanagement, schnellerer Priorisierung und verbesserter Reaktion auf Sicherheitsvorfälle basiert. (tf)

Dieser Artikel basiert auf einem Beitrag von CSO.

Ever since Chinese AI startup DeepSeek launched three years ago, enterprise executives have been nervous about relying on Chinese AI models. 

But now that the latest Chinese AI offerings, Alibaba’s 2.4-trillion-parameter model Qwen3.8 Max and Moonshot’s 2.8-trillion-parameter model Kimi K3, are promising even more powerful performance, those IT executives are being forced to again ask if these models are worth using, even in a limited fashion.

Former Walmart head of risk Steven Eric Fisher, now an independent cybersecurity and risk advisor, thinks they should at least take another look.

“Enterprises should take these models seriously, but neither adopt nor reject them solely because they are Chinese,” he said. “They should be assessed like any other critical technology dependency: jurisdiction, ownership, training and software provenance, licensing, data handling, hosting, security, reliability, and the ability to independently test their behavior. Geopolitical exposure is a legitimate risk factor, but it should be incorporated into technical and supply-chain diligence rather than used as a substitute for it.”

Choose applications with care

He added, “Chinese models may be especially valuable for coding, multilingual processing, high-volume document analysis, research, synthetic-data generation, and privately operated security or forensic workflows, but they should be subject to task-specific testing rather than broad benchmark claims.”

Shashi Bellamkonda, principal research director at Info-Tech Research Group, agreed that the Chinese models can work well if they are only used in carefully chosen applications. 

“Although Moonshot’s K3 still trails Claude’s Fable 5 and GPT 5.6 Sol on performance and user experience, good companies that have governance and prompt guardrails will not face the instability and improvisation of [the Chinese] models,” he said. “These models will win in usage. US frontier models are leading as the best models, but Chinese models will be sufficient for high-volume, low-drama tasks that cost less for non-critical transactions.”

On the flipside, Bellamkonda suggested a variety of areas where enterprises should avoid Chinese AI models, including “customer-facing work without a human in the loop, regulated or sensitive data, and anything where a hallucinated answer creates legal or safety exposure. That is where the reliability gap and the political-radioactivity concern both bite, and where the closed American models still earn their premium.”

Bellamkonda said he didn’t see the differences in data reliability, mostly involving hallucination rates, as meaningful for enterprise AI strategy decisions.

“Every open-weight model in this class can get facts wrong or make things up. That is fixable with the right setup, so it is not a reason to avoid these models,” he said. “For high-volume tasks with clear limits, you feed the model your own trusted documents to answer from, and you keep a person checking the output. That combination is safe for production. The model on its own is not.”

Too early for enterprises to consider

However, not everyone agrees that the latest Chinese models have earned their place as enterprise AI decision options. 

Cybersecurity consultant Brian Levine, executive director of FormerGov, focused on Chinese technology concerns when he worked for the US Justice Department as its representative in the US law enforcement Joint Liaison Group (JLG) with China. 

“It is way too early for US enterprises to seriously consider these models,” he said. “Until proven otherwise, enterprises should assume that if they use these models, they may be granting China complete access to everything they do through the models, and potentially access to their networks and employees more broadly. At this point, any pros of using such models are strongly outweighed by the potential security, confidentiality, and reliability concerns.”

Tom Findling, CEO of Conifers.ai, was equally emphatic that enterprise CIOs need to steer clear of these newer Chinese models. 

“Using them inhouse? Absolutely not. You simply don’t know what is planted inside of it and you don’t know what training data is put into them,” Findling said. 

Mike Wilkes, enterprise CISO at Aikido Security, added that the very attractive pricing for these Chinese models may be appealing, but suggested that, despite the low cost, they’re ultimately too risky.

“Enterprises should take these models seriously, but not romantically. Parameter count is horsepower measured in a showroom, not braking distance in the rain,” he said. “The real tests are reliability on your data, the cost of a wrong answer, and whether the model behaves predictably under pressure.”

He noted that the benchmarks on the latest open-weights models are impressive, and very close to those of the frontier lab models, which makes the cost ”incredibly seductive, especially when a team does not want to risk their data being used to train those frontier models.”

But the Chinese models can still work in specific circumstances. “The strongest value will be in bounded, reversible and inspectable work: coding inside a sandbox, multilingual translation, document triage, data extraction and other high-volume tasks where outputs can be verified,” he said. “Cheap intelligence is valuable, but only when it is not mistaken for trustworthy judgment.”

Wilkes added that the regulatory issues surrounding Chinese models can be especially problematic. Texas, for example, has banned their usage.  

A rational choice for some workloads

However, Yuri Goryunov, CIO of consulting firm Acceligence, argued that CIOs should seriously consider these models. 

“Counterintuitively, the biggest benefit of Kimi and models like it is the lack of guardrails,” Goryunov said. “Think of it as stick shift cars in the era of automatics. If you want ease and comfort, stay with the frontiers because they have cruise control, shift the gears for you and they decide when. If you want performance and control, expand your horizons. But a stick shift assumes you know how to drive one: you bring your own governance, your own evals, your own safety layer. That’s a cost and specialized talent, which is super rare, and for the right organization it’s also the whole point.”

Goryunov’s bottom line: “For internal, high-volume, well-harnessed workloads, [the Chinese models] have moved from ‘watch list’ to ‘rational choice.’”

This article originally appeared on CIO.com.

Ever since Chinese AI startup DeepSeek launched three years ago, enterprise executives have been nervous about relying on Chinese AI models. 

But now that the latest Chinese AI offerings, Alibaba’s 2.4-trillion-parameter model Qwen3.8 Max and Moonshot’s 2.8-trillion-parameter model Kimi K3, are promising even more powerful performance, those IT executives are being forced to again ask if these models are worth using, even in a limited fashion.

Former Walmart head of risk Steven Eric Fisher, now an independent cybersecurity and risk advisor, thinks they should at least take another look.

“Enterprises should take these models seriously, but neither adopt nor reject them solely because they are Chinese,” he said. “They should be assessed like any other critical technology dependency: jurisdiction, ownership, training and software provenance, licensing, data handling, hosting, security, reliability, and the ability to independently test their behavior. Geopolitical exposure is a legitimate risk factor, but it should be incorporated into technical and supply-chain diligence rather than used as a substitute for it.”

Choose applications with care

He added, “Chinese models may be especially valuable for coding, multilingual processing, high-volume document analysis, research, synthetic-data generation, and privately operated security or forensic workflows, but they should be subject to task-specific testing rather than broad benchmark claims.”

Shashi Bellamkonda, principal research director at Info-Tech Research Group, agreed that the Chinese models can work well if they are only used in carefully chosen applications. 

“Although Moonshot’s K3 still trails Claude’s Fable 5 and GPT 5.6 Sol on performance and user experience, good companies that have governance and prompt guardrails will not face the instability and improvisation of [the Chinese] models,” he said. “These models will win in usage. US frontier models are leading as the best models, but Chinese models will be sufficient for high-volume, low-drama tasks that cost less for non-critical transactions.”

On the flipside, Bellamkonda suggested a variety of areas where enterprises should avoid Chinese AI models, including “customer-facing work without a human in the loop, regulated or sensitive data, and anything where a hallucinated answer creates legal or safety exposure. That is where the reliability gap and the political-radioactivity concern both bite, and where the closed American models still earn their premium.”

Bellamkonda said he didn’t see the differences in data reliability, mostly involving hallucination rates, as meaningful for enterprise AI strategy decisions.

“Every open-weight model in this class can get facts wrong or make things up. That is fixable with the right setup, so it is not a reason to avoid these models,” he said. “For high-volume tasks with clear limits, you feed the model your own trusted documents to answer from, and you keep a person checking the output. That combination is safe for production. The model on its own is not.”

Too early for enterprises to consider

However, not everyone agrees that the latest Chinese models have earned their place as enterprise AI decision options. 

Cybersecurity consultant Brian Levine, executive director of FormerGov, focused on Chinese technology concerns when he worked for the US Justice Department as its representative in the US law enforcement Joint Liaison Group (JLG) with China. 

“It is way too early for US enterprises to seriously consider these models,” he said. “Until proven otherwise, enterprises should assume that if they use these models, they may be granting China complete access to everything they do through the models, and potentially access to their networks and employees more broadly. At this point, any pros of using such models are strongly outweighed by the potential security, confidentiality, and reliability concerns.”

Tom Findling, CEO of Conifers.ai, was equally emphatic that enterprise CIOs need to steer clear of these newer Chinese models. 

“Using them inhouse? Absolutely not. You simply don’t know what is planted inside of it and you don’t know what training data is put into them,” Findling said. 

Mike Wilkes, enterprise CISO at Aikido Security, added that the very attractive pricing for these Chinese models may be appealing, but suggested that, despite the low cost, they’re ultimately too risky.

“Enterprises should take these models seriously, but not romantically. Parameter count is horsepower measured in a showroom, not braking distance in the rain,” he said. “The real tests are reliability on your data, the cost of a wrong answer, and whether the model behaves predictably under pressure.”

He noted that the benchmarks on the latest open-weights models are impressive, and very close to those of the frontier lab models, which makes the cost ”incredibly seductive, especially when a team does not want to risk their data being used to train those frontier models.”

But the Chinese models can still work in specific circumstances. “The strongest value will be in bounded, reversible and inspectable work: coding inside a sandbox, multilingual translation, document triage, data extraction and other high-volume tasks where outputs can be verified,” he said. “Cheap intelligence is valuable, but only when it is not mistaken for trustworthy judgment.”

Wilkes added that the regulatory issues surrounding Chinese models can be especially problematic. Texas, for example, has banned their usage.  

A rational choice for some workloads

However, Yuri Goryunov, CIO of consulting firm Acceligence, argued that CIOs should seriously consider these models. 

“Counterintuitively, the biggest benefit of Kimi and models like it is the lack of guardrails,” Goryunov said. “Think of it as stick shift cars in the era of automatics. If you want ease and comfort, stay with the frontiers because they have cruise control, shift the gears for you and they decide when. If you want performance and control, expand your horizons. But a stick shift assumes you know how to drive one: you bring your own governance, your own evals, your own safety layer. That’s a cost and specialized talent, which is super rare, and for the right organization it’s also the whole point.”

Goryunov’s bottom line: “For internal, high-volume, well-harnessed workloads, [the Chinese models] have moved from ‘watch list’ to ‘rational choice.’”

A large majority of IT and security leaders are confident in their teams’ ability to detect when an AI agent has gone rogue, but few are able to take quick action to mitigate the fallout when an agent exceeds its intended scope.

Nine in 10 IT and security leaders surveyed by IT observability vendor WanAware believe in their capabilities to find malfunctioning agents, but only 26% acknowledge that they can trace the downstream impact within minutes. Over 45% say it would take hours to understand the full impact of an agent incident.

That delay between detection and mitigation can be a huge problem, says Jeffrey Collins, WanAware’s CEO. The survey suggests IT leaders are overconfident about their ability to control agents, he adds.

And here, timing is critical, Collins says, given that malfunctioning agents can lead to major outages and data breaches — damage that can start within seconds, he notes.

“That’s truly the gap here. It’s not if you understand it; it’s when you understand it,” Collins says. “If your average time to just knowing about an event is measured in days, weeks, or months, you have a serious problem right now.”

While it’s not always easy to tell whether an agent has gone beyond its scope, it’s even harder to tell the downstream impacts, he adds.

“What’s been affected if one machine was compromised, either from our own AI usage as a customer or from someone else’s, what else could happen, and how can we understand that quickly?” Collins asks.

Machine speed

Kevin Paige, field CISO at IT solutions provider C1, agrees that time is of the essence when an AI agent malfunctions.

“The problem is that agents move at machine speed, so the gap between an agent malfunctioning and you catching it isn’t measured in minutes, it’s measured in actions,” he says. “Every minute it’s wrong it’s still working, and because it’s usually running on borrowed standing credentials, the damage spreads across everything those credentials can reach before anyone can pin it on the agent.”

In many cases, organizations with rogue agents don’t find out from their own detection tools, but from customers, auditors, or broken downstream systems, he says.

“That’s the worst way to learn,” Paige adds. “The longer-term cost is trust, because one incident like that and the business pulls back on agents entirely, so failing to contain a malfunction fast is also what stalls adoption.”

The problem with detecting rogue agents is that many organizations have built in visibility but not control, he says.

“When an agent goes out of scope it’s rarely dramatic,” Paige adds. “Usually, it’s using access it legitimately has, for a purpose nobody signed off on, which means your access model doesn’t even flag it. So you find out after the fact, and you fix it by hand.”

IT teams can stop agents that exceed their scope, but only if controls were built in before the agent was deployed, adds Chris Camacho, COO of Abstract Security.

“Every agent should have its own identity, narrowly scoped permissions, and a complete audit trail,” he says. “Just as important, organizations need the ability to immediately revoke that identity or suspend the agent without manually hunting through multiple consoles during an incident.”

Part of the challenge is that an agent’s activity is spread across identities, cloud platforms, SaaS applications, APIs, and security tools that were not designed to tell a complete story, Camacho says. Security teams often have to piece together events from multiple basic questions such as, what did the agent access, and what changed?

“Most organizations know where they’ve deployed AI agents,” he adds. “That’s very different from knowing exactly what an agent did after something unexpected happens.”

The organizations that most successfully manage agents won’t be the ones that deploy the most, he says. “They’ll be the ones that can explain every action an agent took, prove it operated within policy, and stop it immediately when it doesn’t,” he adds.

Confidence isn’t reality

The survey’s results make sense to Joe Brinkley, director of offensive security research and community at pentest firm Cobalt. The high confidence in detecting malfunctions is compliance paperwork, whereas the minority of respondents who can detect problems quickly is the reality on the ground, he says.

“Tracing agent impact fast is brutal,” Brinkley says. “These systems do not run on fixed code paths. They use nondeterministic reasoning across a web of different APIs. Traditional logs only catch isolated events. They completely miss the full execution chain.”

By the time an anomaly alert hits, an agent has already executed multiple downstream actions, he adds.

In some cases, agent malfunctions are related to data flow vulnerabilities, such as when a prompt injection from an untrusted input such as a malicious email overwrites the system instructions, he says.

“We need to be clear about the actual technology; the AI is not waking up angry,” Brinkley says. “The agent suddenly thinks its official job is to dump your database. It spends tokens as fast as possible to do that.”

Agents are also vulnerable to loop failures, when they hit API errors and try to self-correct, he adds.

“It hits that same broken endpoint 10,000 times in two minutes,” he says. “It drains your budget and causes a self-inflicted denial of service. It is an automated wrecking ball moving faster than your monitoring can log it.”

Brinkley recommends that IT leaders put “hard kill” switches at the API layer to stop agents going out of scope.

“You can stop it, but soft guardrails are useless,” he says. “Do not try to patch the prompt or filter the text. You have to treat the agent like a compromised user account. Pull the OAuth tokens and kill the access immediately.”

Technology executives from across the New York metropolitan area gathered July 16 at Convene, One Liberty Plaza, for CIO 100 Leadership Live New York, a full day of roundtables and panel discussions on enterprise AI investment, governance, and organizational change.

Several key areas of consensus emerged throughout this highly interactive event. Infrastructure fragmentation continues to block the path to securing returns on AI investments prompting leaders to understand rising cloud spend attributed to large language model utilization. This has caused a growing number of organizations to refocus on on-premises and hybrid options in C-suite and board-level capital planning conversations. Speakers, along with comments from the audience, described a shift from project thinking to product thinking, with smaller multidisciplinary teams moving faster than legacy structures.

Several participants repeatedly warned that automating broken processes just amplifies dysfunction. Governance and measurement remain unresolved, with usage metrics still getting mistaken for business value. One of the panels explored how CIOs may benefit from applying venture capital-style scrutiny to enterprise bets, weighing team execution as heavily as the technology itself. The throughline was a redefinition of the CIO role, from technology executor to business strategist fluent in revenue, board engagement, and transformation ownership.

Morning roundtable tackles AI infrastructure

The day opened with an invitation-only executive breakfast roundtable, “Beyond the Pilot, Building the Infrastructure for Real AI Returns,” co-hosted by Unisys and Dell Technologies. Over a dozen executives representing major public and private sector organizations across the New York metropolitan area joined Steve Hollander, senior director of Americas global alliances at Dell Technologies, and Matt Marshall, CIO at Unisys for a workshop-style discussion.

The session explored the strategic, operational, financial, and technological issues that must be mastered to optimize infrastructure decisions and separate organizations that are experimenting with AI from those competing on it. Discussion questions probed how CIOs measure whether AI investment is translating into business results, how they can break the cycle of fragmented and siloed AI deployments, how boards are beginning to scrutinize seven-figure token spend and whether on-premises or hybrid infrastructure can rein in costs.

The take-home point: the organizations pulling ahead are the ones that stopped treating AI as four separate problems, strategic, operational, financial, technological, owned by four separate functions, and started running it as one coordinated decision. Fragmentation is the actual cost center here, not the token spend itself. A CIO who solves the infrastructure question in isolation from the governance question, or the cost question in isolation from the talent question, ends up optimizing one silo while the other three keep bleeding value. Competing on AI, instead of just experimenting with it, means the finance, operations, technology and business sides are reasoning from the same picture of what’s being built and why, so the tradeoffs get made once, together, instead of getting re-litigated at every handoff.

Forum sessions open with a mandate for growth

Following breakfast, the main forum program began with “The New CIO Mandate, Delivering Growth, Not Just Technology.” In a moderated conversation, Laksh Nathan, chief information officer at Paramount Skydance, drew on his experience with mergers, enterprise transformation and AI-enabled development to describe a shift from project and application management toward a product-centric operating model. Nathan addressed how smaller, multidisciplinary teams are changing expectations on both the business and technology sides of the enterprise, and what mindset changes CIOs must lead to turn AI into an engine of growth rather than a cost center.

PwC followed with a session on “Designing the Intelligent Enterprise, From AI Investment to Evolving Operations.” Darren O’Meara, principal and chief technology officer for managed services, and Meghna Shah, principal for engineering and AI, examined why fragmented outcomes persist even after heavy investment in technology and transformation.

The intelligent enterprise, they posited, is less about working toward achieving specific technology outcomes and more about creating operating models that integrate strategy, technology, operations, and governance into one system. This, they explained, requires linking AI, data, and decisions across the business and will leave an indelible mark on how decision rights are redesigned, funding models are developed, and accountability is enforced to accommodate the speed of the agentic economy.

Talent, tradeoffs, and the cost of getting it wrong

The session “Return on Transformation: Time, Talent, and Tradeoffs” — with Prashant Hinge, chief information and transformation officer at MSIG USA; Joseph Gimigliano, chief technology officer at Northwell Health; and Eduard de Vries Sands, AI executive advisor at PatientPoint — examined why transformation initiatives so often lose their way.

The main culprit, even today in 2026, continues to revolve around a persistent instinct for technology implementations to become the objective rather than the means to a measurable business outcome. The panelists made the case for doing the incredibly difficult work of re-engineering (if not entirely re-imagining) existing processes before automating them and then placing smaller bets inside that bigger vision.

Ricky Thakrar, head of sales and account management at Zoho, took the stage to present “Smaller, Smarter, Safer, The Enterprise AI Architecture Most Leaders Get Backwards,” arguing that constrained, context-rich architectures consistently outperform expensive models bolted onto fragmented systems.

A round of Hot Topic Discussion Groups and a networking lunch followed, including the Next CIO Luncheon featuring Robert Half Regional Director Jason Deneu.

Afternoon sessions turn to security, scale, and investment signals

CSO and CIO Contributor Joan Goodchild moderated “Securing Trust in the Agentic Economy,” a discussion with Marlowe Cochran, CISO at the New York State Education Department, and Gee Rittenhouse, vice president of security services at AWS, on how organizations are balancing speed, innovation and security as AI agents move from experimentation into productization at scale.

Rittenhouse framed agentic risk as closer to human risk than traditional software risk, describing how an independent agent acting in a non-deterministic way really does look like a potential insider threat, pushing CISOs toward behavioral monitoring over static workload protection. He tied this to a structural shift in defense, noting it’s hard to do agentic security if you’re not observing it, putting observability at the center of agentic risk management.

Cochran concurred, adding that many of the key tools that are needed to move into the agentic economy already exist, but must be implemented more aggressively, comprehensively and even more creatively. CISOs don’t need to invent an entirely new security discipline for the agentic era so much as extend identity management, access control and monitoring frameworks they already run to cover a new class of non-human actor — agents.

A session on “AI, From Experimentation to Enterprise Impact” brought together Meagan Gentry, national AI practice manager and distinguished technologist at Insight and Yuri Gubin, chief technology officer at DataArt, for a candid look at why pilots stall before reaching scaled production and what operating capabilities, governance, cost visibility, continuous education, must be in place to sustain AI once a proof of concept works.

During the session’s Q&A segment, a discussion emerged around how proof-of-concept success can result in a false signal, raising questions about whether pilots should be considered successful before the intended outcomes have had time to materialize, and drawing a distinction between measuring usage and adoption versus measuring business value.

The panelists explored how CIOs can identify the small number of transformational AI opportunities worth pursuing rather than managing hundreds of incremental use cases, and even challenged whether prioritization is the CIO’s job at all. The discussion closed on a sequencing question with real strategic weight, whether AI-first strategies are putting the technology ahead of the business problem CIOs are trying to solve, and what role CIOs should play with boards in defining the outcomes AI is expected to support.

A shift in perspectives

The “Think Like a VC, Investment Shifts Towards Focused AI Applications” session featured three venture investors, Aaron Darr, partner at Lead Edge; Isabelle Phelps, partner at Lerer Hippeau; and Marshall Porter, general partner at AlleyCorp. The panel explored how investors evaluate risk and talent in a market where products and competitive positions can shift within months, and what separates a focused AI application with durable enterprise value from an AI wrapper built to chase a trend.

The panel challenged the enterprise instinct to seek certainty in a market moving this fast, questioning whether CIOs should stop looking for technologies that will future-proof the enterprise and instead grow more comfortable continuously reassessing their bets. Investors framed this as a deliberate departure from the traditional low-tolerance-for-failure posture that has long governed enterprise technology purchasing, arguing that the search for certainty has itself become a risk in a market where products and business models can shift within months. The discussion pressed CIOs to weigh how they can adopt a more dynamic investment mindset without compromising the enterprise security, governance and accountability their organizations still depend on.

A Lightning Insights followed, featuring five-minute briefings from Insight, Platform9 and Console, followed by Keystone Senior Principal Ellora Sarkar’s talk on why most enterprise AI investment fails to produce measurable value and what separates the small share of firms capturing real return on investment from the majority still stuck in pilots.

Closing the day

The forum closed with “What’s Next for the CIO, Preparing for the Next 12 to 24 Months,” a fireside conversation with Leif Maiorini, CIO for corporate services at Omnicom. Maiorini discussed why business processes need to be redesigned for agentic speed rather than automated around existing human workflows, how organizational structures may shift as autonomous agents reshape visibility and decision support, and where sustainable differentiation will come from once AI capability itself becomes widely accessible.

Maiorini encouraged the industry to clearly distinguish between nondifferentiated services that should be made as efficient as possible and the differentiated capabilities that actually influence why customers choose to do business with an organization, once the major efficiency gains from optimization and AI have been captured.

He was candid about the governance gap agentic systems open up, noting that agents lack the professional reputation, personal accountability and inherent constraints that shape human behavior, which creates new risk when autonomous decisions occur at machine speed. That combination, reinvesting efficiency gains into genuine differentiation while building governance models suited to non-human decision-makers, framed his closing case for why human creativity and judgment remain the enterprise’s most durable asset even as the underlying technology becomes commoditized.

Join the CIO 100 Awards & Conference Aug 17–19, 2026 at Omni PGA Frisco Resort & Spa, Frisco, TX — where top IT leaders celebrate innovation and connect.  Learn more to attend or partner.

A sandbox security hole that could lead to remote code execution (RCE), patched last week by ServiceNow, is being actively exploited in the wild, according to a report from threat intel firm Defused. 

The report, posted on X, said the firm is “observing in-the-wild exploitation of the ServiceNow pre-auth sandbox-escape RCE (CVE-2026-6875).”

Defused CEO Simo Kohonen, in an interview with CSO Online, noted that it appeared that the attacker has changed its tactics from those documented in an earlier proof of concept (PoC) from researchers at Searchlight Cyber, in response to ServiceNow patches and defenses. The company had implemented five different mitigations in its code base, which “neutered” the initial attack methodology, he said, adding that, overall, his team is seeing more attack method tweaks than it used to see. 

“We are seeing a lot of [attack] variations, much more so than a year ago, for the same vulnerability,” Kohonen said. Attackers “now have more tools to build their own stuff.”

However, he admitted that his team has thus far only observed this exploit an in the wild exploitation “once, by one actor.” 

In response to the report, ServiceNow issued a statement saying that it has not yet directly seen any such exploitations. 

“ServiceNow is aware of a cybersecurity company’s recent publication regarding exploitation activity associated with a previously disclosed security vulnerability, identified as CVE-2026-6875. Based on our investigation to date, we have not observed evidence that this activity is related to instances that ServiceNow hosts,” the emailed statement said. “We have provided updates and patches designed to address this issue, and we encourage our self-hosted and ServiceNow-hosted customers to apply the relevant patches if they have not already done so.”

A ‘repeatable failure point’

Analysts and consultants said the bigger concern with this hole is that it focuses on the lack of protections in the sandbox, which many security and IT teams have relied on for years. 

“The vulnerability lets an attacker bypass ServiceNow’s scripting sandbox entirely, and researchers are now seeing exploitation using a different technique than the one originally published, which means signature-based defenses built on the first proof of concept are unlikely to catch every variant,” said Frank Dickson, group VP for security at IDC.

“A compromise that starts in the cloud tenant can end up inside the corporate network, turning a SaaS incident into an on-premises one,” he pointed out. “And because ServiceNow frequently houses HR records, CMDB asset data, and the ticketing system itself, an attacker sitting inside it may have visibility into how the incident response team is tracking the incident.”

Dickson added that this incident is further proof that both IT and security teams need to reevaluate their patching methodologies. 

“Enterprises outsource patching for platforms like ServiceNow to the vendor, but keep the risk that comes from what those platforms touch: HR records, CMDB inventories, and now on-premises systems through MID Server integration. Control sits with the vendor, liability sits with the enterprise, and that mismatch argues for treating core SaaS platforms as part of the internal attack surface, not externalized vendor risk,” he said, noting that as vendors embed more AI-driven scripting into their platforms, the sandbox boundary becomes “a repeatable failure point.”

Because of this, he advised, “CISOs should start asking every AI-enabled SaaS vendor how that boundary is architected and tested, before the next version of this story breaks elsewhere.”

Noah Kenney, principal consultant at Digital 520, said the sandbox escape is the more disturbing element of the issue. 

“The significance is not that ServiceNow had a critical bug, so much as the fact that the bug is a sandbox escape in the AI Platform, which means the containment layer specifically built to run untrusted AI-driven code safely is the thing that failed,” he said. “CISOs have been told repeatedly that the sandbox is what makes enterprise AI safe to deploy, but we’re now seeing the sandbox breaking and that should reframe how CISOs think about every feature sitting behind a similar wall.”

Addition of AI increases blast radius

This is yet another example where AI is fundamentally changing just about every IT and security rule, he pointed out.

“Enterprises are bolting AI onto their most privileged systems of record faster than anyone is updating the threat models for those systems, and the AI layer is becoming the softest part of the hardest targets,” Kenney said. “The real question for a CISO is how many of your critical platforms shipped an AI feature in the past year, and whether a single person in your organization can tell you what that did to the pre-auth attack surface. Most cannot, and that is the actual exposure.”

Aman Mahapatra, chief strategy officer for Tribeca Softtech, a New York City-based technology consulting firm, agreed.

“A vulnerability that gives an attacker a foothold in the ServiceNow instance is now also a vulnerability that gives them access to whatever AI agents are running inside that instance, along with any capability tokens, service accounts, or delegated permissions those agents hold,” Mahapatra said. “The blast radius of a ServiceNow compromise in 2026 is meaningfully larger than the same compromise would have been in 2023, and most enterprise security programs have not caught up to that shift.”

Defused’s Kohonen said that he did not disagree with the sandbox concerns, but he stressed that enterprise CISOs have long ago abandoned the belief that sandboxes are secure. 

“Nothing is foolproof, and having a sandbox is better than not having one,” he said. “But the belief that a sandbox removes all of the risk is incredibly dumb,” especially in the reality of today’s threat landscape, which contains “an endless conveyor belt of exploits.”

A sandbox security hole that could lead to remote code execution (RCE), patched last week by ServiceNow, is being actively exploited in the wild, according to a report from threat intel firm Defused. 

The report, posted on X, said the firm is “observing in-the-wild exploitation of the ServiceNow pre-auth sandbox-escape RCE (CVE-2026-6875).”

Defused CEO Simo Kohonen noted in an interview that it appeared that the attacker has changed its tactics from those documented in an earlier proof of concept (PoC) from researchers at Searchlight Cyber, in response to ServiceNow patches and defenses. The company had implemented five different mitigations in its code base, which “neutered” the initial attack methodology, he said, adding that, overall, his team is seeing more attack method tweaks than it used to see. 

“We are seeing a lot of [attack] variations, much more so than a year ago, for the same vulnerability,” Kohonen said. Attackers “now have more tools to build their own stuff.”

However, he admitted that his team has thus far only observed this exploit an in the wild exploitation “once, by one actor.” 

In response to the report, ServiceNow issued a statement saying that it has not yet directly seen any such exploitations. 

“ServiceNow is aware of a cybersecurity company’s recent publication regarding exploitation activity associated with a previously disclosed security vulnerability, identified as CVE-2026-6875. Based on our investigation to date, we have not observed evidence that this activity is related to instances that ServiceNow hosts,” the emailed statement said. “We have provided updates and patches designed to address this issue, and we encourage our self-hosted and ServiceNow-hosted customers to apply the relevant patches if they have not already done so.”

A ‘repeatable failure point’

Analysts and consultants said the bigger concern with this hole is that it focuses on the lack of protections in the sandbox, which many security and IT teams have relied on for years. 

“The vulnerability lets an attacker bypass ServiceNow’s scripting sandbox entirely, and researchers are now seeing exploitation using a different technique than the one originally published, which means signature-based defenses built on the first proof of concept are unlikely to catch every variant,” said Frank Dickson, group VP for security at IDC.

“A compromise that starts in the cloud tenant can end up inside the corporate network, turning a SaaS incident into an on-premises one,” he pointed out. “And because ServiceNow frequently houses HR records, CMDB asset data, and the ticketing system itself, an attacker sitting inside it may have visibility into how the incident response team is tracking the incident.”

Dickson added that this incident is further proof that both IT and security teams need to reevaluate their patching methodologies. 

“Enterprises outsource patching for platforms like ServiceNow to the vendor, but keep the risk that comes from what those platforms touch: HR records, CMDB inventories, and now on-premises systems through MID Server integration. Control sits with the vendor, liability sits with the enterprise, and that mismatch argues for treating core SaaS platforms as part of the internal attack surface, not externalized vendor risk,” he said, noting that as vendors embed more AI-driven scripting into their platforms, the sandbox boundary becomes “a repeatable failure point.”

Because of this, he advised, “CISOs should start asking every AI-enabled SaaS vendor how that boundary is architected and tested, before the next version of this story breaks elsewhere.”

Noah Kenney, principal consultant at Digital 520, said the sandbox escape is the more disturbing element of the issue. 

“The significance is not that ServiceNow had a critical bug, so much as the fact that the bug is a sandbox escape in the AI Platform, which means the containment layer specifically built to run untrusted AI-driven code safely is the thing that failed,” he said. “CISOs have been told repeatedly that the sandbox is what makes enterprise AI safe to deploy, but we’re now seeing the sandbox breaking and that should reframe how CISOs think about every feature sitting behind a similar wall.”

Addition of AI increases blast radius

This is yet another example where AI is fundamentally changing just about every IT and security rule, he pointed out.

“Enterprises are bolting AI onto their most privileged systems of record faster than anyone is updating the threat models for those systems, and the AI layer is becoming the softest part of the hardest targets,” Kenney said. “The real question for a CISO is how many of your critical platforms shipped an AI feature in the past year, and whether a single person in your organization can tell you what that did to the pre-auth attack surface. Most cannot, and that is the actual exposure.”

Aman Mahapatra, chief strategy officer for Tribeca Softtech, a New York City-based technology consulting firm, agreed.

“A vulnerability that gives an attacker a foothold in the ServiceNow instance is now also a vulnerability that gives them access to whatever AI agents are running inside that instance, along with any capability tokens, service accounts, or delegated permissions those agents hold,” Mahapatra said. “The blast radius of a ServiceNow compromise in 2026 is meaningfully larger than the same compromise would have been in 2023, and most enterprise security programs have not caught up to that shift.”

Defused’s Kohonen said that he did not disagree with the sandbox concerns, but he stressed that enterprise CISOs have long ago abandoned the belief that sandboxes are secure. 

“Nothing is foolproof, and having a sandbox is better than not having one,” he said. “But the belief that a sandbox removes all of the risk is incredibly dumb,” especially in the reality of today’s threat landscape, which contains “an endless conveyor belt of exploits.”

This article originally appeared on CSOonline.

As AI becomes embedded in customer experiences, internal workflows, and throughout the supply chain, security leaders are being asked to do more than manage risk. They are being asked to help the business make more informed decisions and move faster.

At the same time, AI has evolved faster than the programs built to govern it.

The result is a widening gap between the pace of transformation and the ability of security, risk, privacy, compliance, and third-party risk teams to understand where the business is exposed.

Move Fast, Don’t Break Things

AI introduces risks like prompt injection and jailbreaks, but the issues keeping CISOs awake at night are more familiar: over-permissioned accounts, poor logging, credentials left in old repositories, sensitive data scattered across systems, and weak access controls. 

AI gives those risks more speed, reach, and impact. 

When AI agents are connected to enterprise data, workflows, vendors, and applications, the blast radius of existing weak spots expands quickly. A low-severity incident now becomes harder to detect, more difficult to remediate, and more consequential for the business. 

This is why boards and executive teams are looking to security leaders for proactive guidance. They want to know whether the business can adopt AI at scale without creating risk that undermines long-term value. 

“Tell us, in real time, which initiatives are safe to accelerate, where we’re exposed, what could slow down our transformation, and what we need to act on right now.”

The CISO mandate has evolved from risk reporting to innovation enablement. 

When Everything is a Risk, Nothing is a Priority

In many organizations, risk context is spread across multiple teams. Security, procurement, privacy, IT, and third-party risk each have their own view.   

That fragmentation creates blind spots. 

Consider an AI agent that can retrieve customer records, access internal knowledge bases, and trigger downstream workflows. Security may know the agent exists, IT may know where it’s deployed, and procurement may know who purchased it. 

Without a holistic view, however, it becomes difficult to determine whether the agent has the right permissions, if it is operating within policy, or how it could expose the business.

But visibility is only half the battle. As AI systems, identities, vendors, and data change at a dizzying scale, organizations need to understand whether policy is actually being followed in real time.

A control that was effective six months ago may no longer suffice after a new AI integration, a vendor update, or a change in permissions. 

Today’s systems are too dynamic to be governed by the same operating model that worked for yesterday’s tech stack. 

From Risk Review to Risk Decisioning

CISOs are now being asked to help the business decide—quickly and defensibly—what can move forward, what needs guardrails, and what should stop. Meeting that mandate requires a different approach: 

• Treat AI risk as part of enterprise risk, not a separate discipline. AI is embedded in the same decisions organizations already make about data, vendors, identities, controls, and business processes.
• Start with the business process and context, not the model. Understand what processes depend on this system, the data it touches, and what happens if it fails. 
• Move from one-time approval to continuous assurance. What matters isn’t whether an AI project passed review six months ago, but whether it is operating within the organizations policies and risk appetite today.
• Measure decision velocity. Demonstrate how quickly the organization is able to determine what moves forward, what needs guardrails, and what must stop.

When risk is connected across the business, priorities become clear. Security leaders can understand not just what needs to be addressed, but what matters most, who owns it, and what the business impact could be. 

When there is a shared understanding of approved use, teams can move faster without relying on ad hoc reviews, static questionnaires, or blanket restrictions. The goal is to make technology and third-party risk visible, prioritized, and actionable at the speed the business now operates.

That shift helps security leaders say “yes” with confidence.

Safeguard Transformation and Scale Innovation

I know the pressure many CISOs are carrying right now. Your scope is getting larger while resources continue to shrink. 

Your leadership is asking you to protect every facet of the organization, support growing risk and compliance requirements, and now, to be a key voice in guiding business strategy.  

When you have clarity on what risks truly matter and have the tools to take action, your risk program can become a driver of responsible and scalable innovation. 

OneTrust helps build risk and compliance programs aligned with the complexity and the speed of your business. Learn more about our integrated risk solutions.

See also:

• What Anthropic Glasswing reveals about the future of vulnerability discovery
• Anthropic’s Mythos signals a structural cybersecurity shift
• Beware the ‘son of Mythos,’ security experts warn
• Mythos is a signal, not a siren: What frontier AI should change for CISOs

We are inundated with promises that artificial intelligence will save us and that the next governance framework will protect us. Buy this platform, adopt that model and the hard part finally gets easier. After 15 years in this field, I have wanted that shortcut as much as anyone.

But both promises are downstream of something neither one can produce. You cannot automate trust between two people. You cannot govern your way to a relationship. As AI moves into the core of how organizations operate, and accountability stops mapping cleanly to the org chart, what holds when the stakes are highest is not the platform or the policy. It is two human leaders who know each other well enough to carry the weight together.

I think about this often now, a year after publishing a book about the pressures bearing down on security leaders, “The CISO On The Razor’s Edge: Leading Cybersecurity When The System Is Designed To Break.” The partnership between the CIO and the CISO is the last human relationship in cybersecurity. AI raises the stakes. Governance sets the floor. The relationship is what holds.

I saw it work once, up close. When I worked in Washington State, the CIO, Bill Kehoe, talked to his CISO, Ralph Johnson, every day. Weekends included. Not because a policy required it, but because the mission did. That partnership is a large part of why the role stayed sustainable for them when it broke so many others.

The promise we keep believing

Walk any conference floor and you will hear the same pitch in a hundred variations. The next AI layer will close the gap. The next framework will lock down the risk. The technology is usually ready. The organization is not. I have watched too many well-funded programs stall to still believe the tool is the answer, and almost every time, the breakdown traced back to leaders who were not aligned before the work began. A framework run by misaligned leaders inherits the misalignment. You can buy the best controls on the market and still watch them fail when two leaders work from different assumptions about who owns what.

Bill and Ralph understood this. Security decisions were not handed to Ralph after the fact to bless or block. They were made with him, inside the technology decisions, because the two had already agreed on what mattered. That is not governance. That is leadership creating the conditions in which governance can work.

It is the real lesson I came to in the book. Technical knowledge matters, but it is not enough. As I wrote then, “Influence, trust and internal relationships are non-negotiable.” Without influence, CISOs cannot lead. Without technical substance, they cannot prioritize what matters. And without partnership, especially with their CIO, “they’re operating without a safety net.”

AI does not change that truth. It raises the cost of ignoring it.

When decisions move at machine speed

The ground under both roles is shifting. Work no longer flows through people alone. It moves across people, platforms, partners and agents at the same time, and it moves fast. Decisions that once waited for a meeting now form in seconds. The org chart, built for an era when humans did the work and reporting lines explained accountability, struggles to keep up.

This is where the partnership stops being a nicety and becomes infrastructure. When decisions form at machine speed, the human escalation path has to be instant. There is no time to negotiate a relationship in the middle of an incident. Either the trust is already there, built in the quiet stretches before anything goes wrong, or it is not there when it counts.

I asked Bill what he would lose if his daily calls with Ralph dropped to once a week. His answer cut straight to it.

“Cyber does not rest,” he told me. “It is active and dynamic and requires 24/7/365 attention.” Drop to a weekly check-in, he explained, and “I am treating the CISO like any other executive position.” For Bill, AI only raises the stakes on that daily contact. “Relationships and partnerships between the CIO and CISO will never die due to AI,” he said. “I can’t even imagine a scenario where I don’t talk to my CISO on a daily basis including weekends to discuss the latest risks and vulnerabilities or news on potential AI attacks.”

That is the point most of the market misses. A platform can flag the anomaly. It cannot decide what the organization is willing to risk, who carries that decision or how two leaders stand behind it together. The faster the machines move, the more the partnership has to already be in place.

The loneliest seat in the building

There is a reason some now call the CISO job the least desirable role in business. The seat carries enormous accountability and rarely the authority to match. As one security leader put it, the pressure has never been higher and the control has never felt lower. People are burning out and walking away from a role that has never mattered more.

Here is the hard part. There is no log file for burnout. No alert fires when the weight finally exceeds the leader. That drain is invisible right up until it is not, and it raises organizational risk as surely as any unpatched system. The structural fixes the industry debates are all real and all slow.

The fastest source of relief available to a CISO is not a framework. It is a CIO who treats the relationship as a daily partnership rather than a line on a chart. An isolated CISO is a vulnerability. A partnered one is an asset.

You see what that partnership is worth in the worst moment. I asked Bill what it looks like when an incident hits and public trust is on the line. He did not reach for a tool.

“I am accountable as CIO to everything that occurs in the state from a technology lens including cyber,” he said. When a severe incident hits, the call comes to him from agency leadership or the Governor’s Office. Then he follows the plan, but never alone: “I will be in constant contact with the CISO on the details of the incident.”

That is the safety net made real. The CISO is not carrying the mission alone at the moment it matters most. On the razor’s edge, leadership keeps you upright. Partnership keeps you in the fight.

The work no tool will do for you

In my advisory work, I sit with C-suite leaders who share values and still cannot find alignment. The barrier is rarely disagreement. It is that they are not communicating clearly or often enough to build the trust that alignment requires. I have watched negotiations that could only happen by proxy, over email, because two capable leaders had stopped talking directly.

I recently sat in an hour-long discussion where alignment and shared values were present the whole time. It did not become clear until the final fifteen minutes. That is what real alignment costs: patience, persistence and a stubborn commitment to clarity. If leaders cannot do that work themselves, no AI model or governance tool will do it for them.

This is why I stand up an AI review board for the organizations I work with and host the leadership conversations that decide whether a company’s AI ambitions thrive or stall. The board itself matters less than what it provides: neutral ground, a regular cadence and an agenda that forces the hard issues into the open before a crisis forces them. If your organization has no venue like that, that absence is its own form of dysfunction. The cadence is what makes communication effective. Not easy. Effective.

Build the bond on purpose

You cannot framework your way to trust. But you can build it deliberately, and that is a leadership act, not a governance one. The partnership and stakeholdering skills that once looked like soft extras are now the core executive work. A few moves matter most:

• Set a standing contact rhythm with your counterpart before you need one, daily or near-daily, not quarterly
• Make decision rights and accountability explicit while it is calm, so no one improvises them mid-incident
• Translate security into business outcomes together, so the board hears one aligned voice

Build the relationship as deliberately as you would build any critical control, because that is what it is. If you cannot connect the partnership to outcomes the business actually feels, you have a friendship, not a performance lever.

A year after writing “The CISO On the Razor’s Edge,” I am even more convinced that strong leadership precedes effective governance and partnership precedes them both. This is the good news, not the hard news. The CIO and CISO who build real trust do not just reduce risk. They move faster than their competitors, because they spend no energy fighting each other. They earn the board’s confidence, because the board hears one clear voice. And they unlock the AI strategy everyone else is still struggling to govern, because they have already done the human work that makes governance hold.

That is the upside waiting on the other side of this relationship. AI will keep advancing. Governance will keep maturing. But the organizations that win the next decade will be the ones where two leaders decided the partnership was worth building before they needed it. Bill and Ralph knew it every day, weekends included. The edge is there for anyone willing to do the same.

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

Threat actors are now abusing an ordinary font file to deliver low-detection malware capable of stealing credentials and establishing persistence on compromised Windows systems.

According to a new research from Fortinet’s FortiGuard Labs, a global phishing campaign is actively using heavily obfuscated JavaScript and a Lua-based loader posing as a TrueType Font (TTF) file to evade security and drop RATs and infostealers.

A TTF file is a standard font file used by operating systems and applications to display text.

The campaign has been deploying malware families such as Agent Tesla, Remcos, XWorm, and a Snake Keylogger variant known as Best Private LOGGER, since at least late March 2026. “In these attacks, the threat actor impersonates several well-known companies, using the guise of business cooperation to launch phishing attacks,” FortiGuard researchers said in a blog post.

Talking about how a new attack technique seems to still rely on conventional phishing tricks, Shane Barney, CISO at Keeper Security, said, “The most sophisticated technical evasion in the world still starts the same way: someone opens an email from what looks like a trusted company and acts on it.”

“The obfuscation layers, the Lua loader disguised as a font file, the fileless execution chain – all of it exists to survive detection after that human decision has already been made, and organizations would do well to keep that in their sightline,” he added.

Business and payment-themed phishing lures used

According to the researchers, victims receive phishing emails impersonating well-known companies and using business collaboration or payment-related themes to trick recipients into opening compressed archives. These archives contain the obfuscated JScript that establishes persistence before dropping either a legitimate Autolt executable or a LuaJIT interpreter, along with a malicious script packaged within a .ttf extension.

The fake font file functions as a Lua-based loader that runs multiple de-obfuscation steps before decrypting and executing shellcode directly in memory.

“Security controls cannot treat a file extension as proof of file type or intent,” said Jason Soroko, senior fellow at Sectigo. “Each component (of the campaign) may appear less suspicious when reviewed alone, while the combined sequence leads to in-memory execution of RATs and infostealers.”

Some of the new variants, the researchers pointed out, are getting more sophisticated by introducing segmented shellcode encryption, Vectored Exception Handler (VEH)- based runtime decryption, AMSI and ETW bypasses, API unhooking, and other anti-analysis techniques designed to evade endpoint defenses.

The final malware payload is delivered using Donut shellcode, allowing execution without writing the payload to disk.

Protection requires targeted mitigations and routine security hygiene

Fortinet’s findings confirm the attackers’ endgame to be stealing credentials and maintaining long-term access. The malware families observed, including Agent Tesla, Remcos, XWorm, and Best Private LOGGER, are all focused on credential theft, surveillance, or remote access.

Barney said organizations should resist focusing exclusively on the loader’s technical sophistication and instead strengthen the systems attackers eventually want to compromise.

In his opinion, identity and access controls are what it comes down to, as signature-based detection often fails against the loader sophistication of this grade. “Limiting what any given set of credentials can reach, enforcing least privilege, requiring re-authentication for sensitive systems, and monitoring for anomalous session behavior will not stop every phishing email from landing, but they significantly constrain what an attacker can accomplish after one succeeds,” he explained.

Soroko, on the other hand, recommends focusing controls on the technical indicators. He urged organizations to restrict Windows Script Host, Autolt, and LauJIT wherever they are not operationally required, monitor for behaviors such as process injection, remote memory allocation, and shellcode execution, and use Fortinet’s published indicators for threat hunting.

The indicators of compromise (IOCs) Fortinet shared include the command-and-control (C2) addresses, file hashes, and filenames.

Soroko warned against relying solely on hashes or C2 infrastructure because the loader has changed over time. “The stronger approach is to detect the stable behavior across versions, then test controls against the complete chain,” he said.

Shadow IT has long been a major problem for CISOs, but the biggest problem may be coming from the executive suite’s hunger for unsanctioned AI.

Nearly two-thirds of senior decision-makers admit to using unapproved AI tools, compared to just 31% of lower-level employees, according to a survey by Microsoft solutions partner TrustedTech.

The use of shadow AI is prevalent among senior executives even though three in four employees acknowledge security or data privacy risks related to the practice.

“Most shadow AI users are not ignorant of the risk,” TrustedTech says in a white paper. “They are deliberately choosing to use these tools anyway. This is not a training issue. It is a culture, incentives, and alternatives issue.”

In many cases, the problem is driven by a lack of approved tools, the report adds.

“People use shadow AI because what their employer hands them is worse than mainstream AI tools, or because nothing has been approved in the first place,” the report says. “That doesn’t change until the sanctioned tools are genuinely worth using.”

A question of authority

The use of shadow AI by CEOs and other C-suite executives can create major problems for CISOs, CIOs, and other IT executives because they may not have the authority to put the kibosh on it.

It also presents a challenge for IT leaders to provide the AI tools that employees and executives want to use.

When executives use shadow AI, CISOs are in a difficult position, because governance only works when it’s modeled from the top, says Andy Nolan, VP of technology at TrustedTech.

“If senior leaders bypass approved AI tools or policies, it sends an implied message that speed matters more than security and compliance,” he adds. “Employees notice that behavior, and it becomes much harder to ask the rest of the organization to follow standards that leadership isn’t following themselves, first.”

Another major problem is that executives often work with highly sensitive information, including financial data, strategic plans, intellectual property, and customer information, he notes.

But CISOs and CIOs also can’t solve the problem by becoming the AI police in every situation, Nolan says, because their role is to help the business innovate safely.

“That requires executive alignment, clear governance, and providing secure AI tools that people actually want to use,” he adds. “When leadership embraces those solutions, the rest of the organization is almost sure to follow.”

All risk, no reward

The use of shadow AI by senior executives puts CISOs and CIOs in an impossible position, agrees Amit Maloo, CISO at AI procurement provider Ivalua. CISOs and CIOs are held accountable for the risk exposure but have no visibility into the problem, he says.

“When senior leaders use ungoverned AI tools for business decisions, those decisions still have consequences, such as financial commitments, contract reviews, and data sharing,” he adds. “But there is no audit trail, no permissions model, or no way to reconstruct what happened or why.”

Part of the problem is that approved AI options often don’t meet the needs of users, Maloo says.

“AI policies alone aren’t enough; organizations need to pair governance with usability,” he adds. “If approved AI tools don’t meet the pace of business, employees at every level, including leadership, will find their own solutions. Successful organizations will be those that make the secure path the easiest path.”

IT leaders can’t solve the problem with more governance, he notes. “Policies and restrictions slow shadow AI down, but they don’t stop it, especially when the people using it are senior enough to absorb the disciplinary risk,” Maloo adds. “What CIOs can do is focus on providing tools that grant users full access to the necessary systems and data, eliminating the need to choose between a capable but ungoverned tool and a safe but limited one.”

Speed over security

The TrustedTech data echoes a June report from employee monitoring software vendor Teramind, which found that more than two-thirds of C-level executives prioritize speed over security when using AI tools, notes Nik Kale, a principal engineer and product architect at Cisco, and member of the Coalition for Secure AI.

In addition, the Teramind report found that two-thirds of enterprise AI activity runs through personal accounts on platforms for which the company already owns licenses, he notes.

“People are paying for the governed version and using the ungoverned version of the same product, so the problem isn’t the tools,” he says. “The approved path is slower, buried in procurement, or disconnected from where the work actually happens, and speed wins every time under a deadline.”

The problem then isn’t with the AI tools, but with the friction involved, he says. “People aren’t going around the front door because the room is locked,” Kale adds. “They’re going around it because the front door is slower.”

In many cases, the use of shadow AI exposes a couple of shortcomings in enterprise processes, adds Matthew Scavetta, chief technology innovation officer at IT solutions provider Future Tech Enterprise.

Many organizations don’t do a good job of making employees aware of the AI tools available to them, he says, and many organizations don’t offer training on the sanctioned applications, which drives users to pick products they are familiar with.

“If you don’t solve problems for people quickly or make people aware of which tools they can use safely, they will find a workaround,” he adds. “AI tools are no different than anything else.”

Shadow AI use by executives puts IT leaders in an incredibly difficult position, he says.

“CIOs, in particular, are under more and more pressure each year to keep up with what’s possible as tech influencers keep preaching about the potential of these tools,” Scavetta says. “CEOs and board members are constantly getting swept up in the hype; meanwhile, there are more and more case studies coming out showing how little ROI some organizations have realized. It’s a never-ending game of balancing possible with practical.”

Zoom has identified, and patched, a critical security hole that “may allow an unauthenticated user to conduct an account takeover via network access.”

The issue is especially significant given Zoom’s extensive reach; it reportedly has more than 300 million daily active users, including 470,000 paying business customers. Given that reach, Zoom has been impacted by many other security incidents and France recently tried banning its use by French government users. 

 Zoom security bulletins released Tuesday revealed the bug, and three other security issues, which Zoom patched on Wednesday. 

The company originally said that the takeover issue impacted Zoom Desktop Client for Windows before version 7.0.0, Zoom VDI Client for Windows before version 7.0.10 and 6.6.15 and 6.5.18 in their respective branches, and Zoom Meeting SDK for Windows, but on Wednesday, without explanation, it removed Meeting SDK for Windows as an affected product.

The other three holes were less severe, but still significant, and they all involved privilege escalation. They impacted Zoom Workplace for Windows before version 7.0.5, Zoom Workplace VDI Client for Windows before 6.5.17 and 6.6.14 in their respective branches, Zoom Workplace VDI plugin for Windows before 6.5.17 and 6.6.14 in their respective branches, Zoom Rooms for Windows before 7.0.5 and Remote Control for Zoom Contact Center for Windows before version 7.0.0.

A second privilege escalation issue impacted Zoom Rooms for Windows before version 7.1.0, and another impacted Zoom Workplace VDI Plugin for Windows before version 6.6.14.

Zoom did not immediately reply to a request for comment.

‘As bad as it gets’

Frank Dickson, group VP for security at IDC, said the nature of the reported hole is alarming.

This bug “is about as bad as it gets, short of a worm. It is exploitable over the network, low complexity, zero privileges required, no user interaction needed,” he said, pointing out that exploitation is easy once technical details leak or someone reverse-engineers the patch, which is not as challenging as it once was, thanks to AI. “Yesterday’s script kiddies have been empowered,” he said.

Dickson said the only good news is that Zoom discovered the hole itself, and that “no in-the-wild exploitation has been reported by any outlet as of Thursday.”

Consultant Brian Levine, executive director of FormerGov, agreed with Dickson’s characterization of the hole, but said a potentially bigger issue is the high level of sensitive data that Zoom accesses. 

“An attacker with unfettered access to a Zoom account may be able to listen to recordings of sensitive meetings, to eavesdrop on future meetings, and to impersonate the organization in an effort to social engineer its clients and partners. Thus, given that ubiquity of Zoom in large enterprises, this vulnerability is pretty concerning,” Levine said.

He’s encouraged, however, that Zoom found the flaw itself, which indicates its security team is “actually doing the hard, unglamorous work of auditing its code.”

Giuseppe Trotta, principal security researcher at Malwarebytes, has a theory about what was behind the Zoom disclosure. 

“Because the vulnerability requires zero privileges and absolutely no user interaction, the remote network attack vector is highly suspected to involve the mishandling of deep links, such as custom URL schemes like zoommtg:// or zoomworkplace://,” he said. This led him to think that if the Zoom Workplace client for Windows fails to properly sanitize and validate incoming arguments passed via these special browser-to-desktop links, an unauthenticated attacker could craft a malicious string that could trick the desktop application into exposing or redirecting the user’s active session tokens directly to an attacker-controlled server, achieving a seamless and completely silent account takeover.

“Watch out for Zoom links and invites if you are on Windows or VDI and haven’t updated yet,” he advised.

Mike Wilkes, enterprise CISO at Aikido Security, offered kudos to Zoom for discovering the critical flaw, but he wanted to know how such a severe bug got into its software initially.

“This vulnerability raises questions about why the defect was not caught by design review, fuzzing, or pre-release abuse-case testing,” Wilkes said. “A historical defect in Zoom’s product/security relationship has been prioritizing ease of use over security risk.”

All four bugs important

Justin Greis, CEO of consulting firm Acceligence, said that the two types of holes reported by Zoom, account takeover and escalation, are both important, but for different reasons. 

“The critical vulnerability is significant because it has the characteristics security teams worry about most,” Greis said, but the privilege escalation holes “are certainly important to patch as they primarily increase the impact of an attack that has already begun. The critical vulnerability has the potential to be an initial entry point, which is why it deserves the most attention.”

Greis also applauded Zoom’s response, saying that it “reflects a reasonably mature security program.”

He pointed out that no complex software platform will eliminate vulnerabilities entirely. “The differentiator is whether vendors are continuously investing in offensive testing, finding weaknesses before attackers do, and moving quickly to develop and distribute fixes,” he said.

This article originally appeared on Computerworld.

Zoom has identified, and patched, a critical security hole that “may allow an unauthenticated user to conduct an account takeover via network access.”

The issue is especially significant given Zoom’s extensive reach; it reportedly has more than 300 million daily active users, including 470,000 paying business customers. Given that reach, Zoom has been impacted by many other security incidents and France recently tried banning its use by French government users. 

 Zoom security bulletins released Tuesday revealed the bug, and three other security issues, which Zoom patched on Wednesday. 

The company originally said that the takeover issue impacted Zoom Desktop Client for Windows before version 7.0.0, Zoom VDI Client for Windows before version 7.0.10 and 6.6.15 and 6.5.18 in their respective branches, and Zoom Meeting SDK for Windows, but on Wednesday, without explanation, it removed Meeting SDK for Windows as an affected product.

The other three holes were less severe, but still significant, and they all involved privilege escalation. They impacted Zoom Workplace for Windows before version 7.0.5, Zoom Workplace VDI Client for Windows before 6.5.17 and 6.6.14 in their respective branches, Zoom Workplace VDI plugin for Windows before 6.5.17 and 6.6.14 in their respective branches, Zoom Rooms for Windows before 7.0.5 and Remote Control for Zoom Contact Center for Windows before version 7.0.0.

A second privilege escalation issue impacted Zoom Rooms for Windows before version 7.1.0, and another impacted Zoom Workplace VDI Plugin for Windows before version 6.6.14.

Zoom did not immediately reply to a request for comment.

‘As bad as it gets’

Frank Dickson, group VP for security at IDC, said the nature of the reported hole is alarming.

This bug “is about as bad as it gets, short of a worm. It is exploitable over the network, low complexity, zero privileges required, no user interaction needed,” he said, pointing out that exploitation is easy once technical details leak or someone reverse-engineers the patch, which is not as challenging as it once was, thanks to AI. “Yesterday’s script kiddies have been empowered,” he said.

Dickson said the only good news is that Zoom discovered the hole itself, and that “no in-the-wild exploitation has been reported by any outlet as of Thursday.”

Consultant Brian Levine, executive director of FormerGov, agreed with Dickson’s characterization of the hole, but said a potentially bigger issue is the high level of sensitive data that Zoom accesses. 

“An attacker with unfettered access to a Zoom account may be able to listen to recordings of sensitive meetings, to eavesdrop on future meetings, and to impersonate the organization in an effort to social engineer its clients and partners. Thus, given that ubiquity of Zoom in large enterprises, this vulnerability is pretty concerning,” Levine said.

He’s encouraged, however, that Zoom found the flaw itself, which indicates its security team is “actually doing the hard, unglamorous work of auditing its code.”

Giuseppe Trotta, principal security researcher at Malwarebytes, has a theory about what was behind the Zoom disclosure. 

“Because the vulnerability requires zero privileges and absolutely no user interaction, the remote network attack vector is highly suspected to involve the mishandling of deep links, such as custom URL schemes like zoommtg:// or zoomworkplace://,” he said. This led him to think that if the Zoom Workplace client for Windows fails to properly sanitize and validate incoming arguments passed via these special browser-to-desktop links, an unauthenticated attacker could craft a malicious string that could trick the desktop application into exposing or redirecting the user’s active session tokens directly to an attacker-controlled server, achieving a seamless and completely silent account takeover.

“Watch out for Zoom links and invites if you are on Windows or VDI and haven’t updated yet,” he advised.

Mike Wilkes, enterprise CISO at Aikido Security, offered kudos to Zoom for discovering the critical flaw, but he wanted to know how such a severe bug got into its software initially.

“This vulnerability raises questions about why the defect was not caught by design review, fuzzing, or pre-release abuse-case testing,” Wilkes said. “A historical defect in Zoom’s product/security relationship has been prioritizing ease of use over security risk.”

All four bugs important

Justin Greis, CEO of consulting firm Acceligence, said that the two types of holes reported by Zoom, account takeover and escalation, are both important, but for different reasons. 

“The critical vulnerability is significant because it has the characteristics security teams worry about most,” Greis said, but the privilege escalation holes “are certainly important to patch as they primarily increase the impact of an attack that has already begun. The critical vulnerability has the potential to be an initial entry point, which is why it deserves the most attention.”

Greis also applauded Zoom’s response, saying that it “reflects a reasonably mature security program.”

He pointed out that no complex software platform will eliminate vulnerabilities entirely. “The differentiator is whether vendors are continuously investing in offensive testing, finding weaknesses before attackers do, and moving quickly to develop and distribute fixes,” he said.

Detection Engineering war einst ein Nischenbereich, der vor allem für Großunternehmen relevant war. Inzwischen wird die Methodologie allerdings in diversen Branchen als unverzichtbar für den Security-Betrieb angesehen.

In diesem Beitrag erfahren Sie:

• was Detection Engineering ist,
• wie es sich von Threat Detection unterscheidet,
• welche Aspekte die Adoption treiben,
• welche Voraussetzungen dabei erfüllt sein sollten, und
• welche Rolle KI und Automatisierung dabei spielen können.

Was ist Detection Engineering?

Beim Detection Engineering geht es darum, Systeme zu entwickeln und zu implementieren, mit denen potenzielle Sicherheitsbedrohungen innerhalb der spezifischen Technologieumgebung eines Unternehmens identifiziert werden können – ohne dabei in einer Flut von Fehlalarmen unterzugehen. Dazu werden intelligente Regeln erstellt, um potenziell verdächtige oder schadhafte Vorgänge in den Netzwerken oder Systemen eines Unternehmens zu identifizieren und entsprechend aussagekräftige Warnmeldungen darüber zu generieren.

Der Detection-Engineering-Prozess umfasst in der Regel:

• Bedrohungen zu modellieren,
• die TTPs der Angreifer zu analysieren,
• Detection-Regeln zu schreiben, zu testen und zu validieren, sowie
• sich an neue Bedrohungen oder Angriffstechniken anzupassen.

Laut dem vom SANS Institute und Anvilogic veröffentlichten „State of Detection Engineering Report 2026“ (Download gegen Daten) investieren 80 Prozent der befragten Organisationen (und 85 Prozent der Großunternehmen) inzwischen aktiv in Detection Engineering. Von diesen verfügen mittlerweile 60 Prozent über eigene, dedizierte Teams in diesem Bereich. Und: 67 Prozent der Befragten geben an, dass Detection Engineering ausgeprägten Support durch das Management genießt.

Die Ergebnisse des Reports deuten darauf hin, dass viele Unternehmen Detection-Engineering-Praktiken nicht nur eingeführt, sondern zu einem strategischen Fokuspunkt ihrer Cybersecurity-Bemühungen gemacht haben. Oder, wie die Studienautoren es ausdrücken: „Noch vor einem Jahrzehnt war Detection Engineering relativ unbekannt. Heute ist es essenziell für die Security Operations.“

Der Report beschreibt zudem, wie sich die Detection-Engineering-Praktiken im Laufe der letzten Jahre weiterentwickelt haben. Waren diese zunächst übermäßig abhängig von herstellerspezifischen Konsolen und proprietären Sprachen, hielten dann nach und nach Softwareentwicklungsprinzipien wie CI/CD Einzug.

Detection Engineering vs. Threat Detection

Laut den Verfechtern des Ansatzes unterscheidet sich Detection Engineering wesentlich von herkömmlicher Threat Detection – mit Blick auf Ansatz, Methodik und die Integration in den Development Lifecycle:

• So sind traditionelle Threat-Detection-Prozesse in der Regel reaktiv und stützen sich auf vordefinierte Regeln und Anbietersignaturen – die Anpassungsmöglichkeiten für die Anwender sind limitiert.
• Im Gegensatz dazu kommen beim Detection Engineering Prinzipien der Softwareentwicklung zum Einsatz, um eine benutzerdefinierte Detection-Logik für eine spezifische Unternehmensumgebung und ihre Bedrohungslandschaft zu erstellen und zu pflegen. Das Ziel besteht darin, maßgeschneiderte Mechanismen zu entwickeln, um unternehmensspezifische Bedrohungen erkennen zu können.

Deshalb geht Detection Engineering oft mit einem stärkeren Fokus auf verhaltensbasierte Erkennungsmethoden einher, wie Heath Renfrow, CISO und Mitbegründer des Cyber-Recovery-Anbieters Fenix24, erklärt: „Detection Engineering ist verhaltensgesteuert, kontextsensitiv und auf die einzigartige Bedrohungslandschaft eines einzelnen Unternehmens zugeschnitten. Es ist ein Mix aus Security Operations, Threat Intelligence und Data Science.“

Warum Detection Engineering eingeführt wird

Die Einführung von Detection Engineering wird von einer ganzen Reihe von Faktoren vorangetrieben. Der wichtigste ist die Tatsache, dass Standard-Detection-Mechanismen nicht ausreichen: „Diese erfassen keine Baseline für die Umgebung, reduzieren die Anzahl der Fehlalarme nicht und – was besonders beunruhigend ist – warnen nicht immer vor den wirklich wichtigen Ereignissen“, konstatiert Johnathon Miller, Vice President of Security Operations beim Plattformanbieter Lumifi Cyber.

Generische Warnmeldungen, die den organisatorischen Kontext nicht berücksichtigen, haben sich vielerorts zum Problem entwickelt und fördern die „False Positive Fatigue“ – wie auch die vorab zitierte Studie belegt:

• 64 Prozent der Befragten geben an, unter hohen Fehlalarmraten zu leiden,
• 61 Prozent haben mit unpräzisen Detection-Mechanismen zu kämpfen, und
• 34 Prozent berichten von zeitlich verzögerten Updates und Optimierungen.

„Herkömmliche Methoden zur Bedrohungserkennung waren in der Vergangenheit statisch: Wenn a gleich a ist, wird eine Warnmeldung ausgelöst“, erklärt Kevin Gonzalez, Vice President of Security, Operations and Data bei Anvilogic. Laut dem Experten handle es sich oft um starre Black-Box-Mechanismen, denen es an Flexibilität bei der Anpassung mangele. Diese Ansätze seien laut Gonzalez zwar bis zu einem gewissen Grad nützlich, würden im Zuge einer Skalierung aber unüberschaubar – insbesondere bei hybriden Umgebungen.

Ein weiteres Problem ist das wachsende Ausmaß und die zunehmende Raffinesse der Sicherheitsbedrohungen. Angreifer setzen immer ausgefeiltere und schwerer zu erkennende Techniken ein – darunter Fileless Malware, Zero-Day-Exploits sowie „Living off the Land“- und Supply-Chain-Attacken. Die zunehmende Nutzung der Cloud hat darüber hinaus neue Schwachstellen eröffnet und blinde Flecken geschaffen, die mit herkömmlichen Detection-Methoden oft nur schwer abzudecken sind.

„Unternehmen erkennen mittlerweile, dass proaktive Erkennungstechniken die Verweildauer der Angreifer verkürzen, die Reaktionsfähigkeit verbessern und die allgemeine Cyberresilienz stärken. Zudem legen Compliance-Frameworks und auch Cyberversicherer zunehmend gesteigerten Wert auf robuste Detection-Strategien“, meint Sicherheitsentscheider Renfrow.

Detection Engineering – die Voraussetzungen

Zu den Unternehmen, die auf Detection Engineering setzen, zählen Firmen aus dem Bankensektor, der Tech- und Cybersecurity-Branche sowie dem Healthcare-Bereich. Also hauptsächlich Branchen, die strengen regulatorischen Anforderungen unterliegen oder regelmäßig zum Ziel raffinierter Angreifer werden.  

Tatsächlich können jedoch die meisten Unternehmen mit einer komplexen IT-Infrastruktur von Detection Engineering profitieren – zum Beispiel auch mit Blick auf Security Operations Center (SOCs), wie Michael Mumcuoglu, CEO beim Detection-Engineering-Anbieter CardinalOps, erklärt: „Nicht nur die Bedrohungslandschaft verändert sich, sondern auch die eigene interne IT-Infrastruktur. Das kann zu Abweichungen bei der Detection führen, so dass die Regeln nicht mehr eingehalten und somit auch keine Warnmeldungen mehr ausgelöst werden.“

Als zentrale Voraussetzungen für den Aufbau von Detection-Engineering-Fähigkeiten gelten unter Sicherheitsexperten:

• Daten: Detection-Engineering-Teams benötigen Zugriff auf Protokolle und Security-Event-Daten von Endgeräten, Netzwerken, Cloud-Umgebungen und Sicherheits-Tools sowie auf eine zentralisierte SIEM– oder Log-Management-Plattform, um diese zu aggregieren und zu normalisieren.
• Qualifiziertes Personal: Detection Engineers, Security-Analysten und Threat Researcher sind nötig, um Detection-Regeln zu entwickeln und zu verfeinern.
• Formalisierte Prozesse: Diese sind essenziell, um Bedrohungen zu modellieren, zu testen und Threat-Daten in die Incident Response zu integrieren.

CISO Renfrow empfiehlt Detection-Engineering-Interessierten zudem, Frameworks wie MITRE ATT&CK zu nutzen, um sicherzustellen, dass bekannte Adversary-Techniken abgedeckt werden. Zusätzlich rät der Sicherheitsentscheider Anwenderunternehmen dazu, Adversary-Emulation-Tools einzusetzen, um die Effektivität ihrer Bemühungen zu validieren.

Automatisiertes Detection Engineering

Bei der Optimierung und Automatisierung von Detection-Regeln können auch künstliche Intelligenz (KI) und Machine Learning (ML) unterstützen, wie ein weiterer Blick auf den Report von SANS und Anvilogic deutlich macht. Demnach:

• setzen 45 Prozent der Studienteilnehmer in ihren Detection-Engineering-Programmen KI ein, um Anomalien zu erkennen sowie Regeln zu generieren und Warnmeldungen zu triagieren.
• sind 88 Prozent davon überzeugt, dass KI in den nächsten drei Jahren erheblichen Einfluss auf ihre Detection-Engineering-Programme haben wird.
• nutzen 93 Prozent der Befragten aktuell eine Form der Automatisierung in ihrem Detection-Engineering-Workflow ein – oder planen damit.

„Einer der stärksten Anwendungsfälle für KI ist es, riesige Datenmengen zu analysieren, um Anomalien zu identifizieren. Insbesondere, wenn es um KI-Modelle geht, die auf benutzerdefinierten Datensätzen trainiert wurden“, meint auch Glenn Thorpe, Senior Director of Security Research and Detection Engineering beim Plattformanbieter GreyNoise Intelligence.

Geht es darum, Detection-Engineering-Prozesse zu automatisieren, nehmen Anwender vor allem drei Bereiche in den Fokus. Sie:

• mappen ihre Detection-Abdeckung mit dem MITRE-ATT&CK-Framework,
• identifizieren fehlerhafte oder falsch konfigurierte Detection-Regeln, und
• operationalisieren Threat-Informationen in umsetzbare Erkennungsregeln.

Security-Experte Thorpe warnt Unternehmen allerdings davor, nach einer Einheitslösung zu suchen, um Detection-Engineering-Kapazitäten aufzubauen: „Um ein effektives Team in diesem Bereich aufzubauen, sind vor allem eine kreative, vielschichtige Denkweise und Neugierde gefragt.“

Ein guter Ausgangspunkt wäre laut dem Manager, die Kerndaten des eigenen Unternehmens zu identifizieren und Menschen zu finden, die diese aus unterschiedlichen Perspektiven analysieren können: „Verschaffen Sie sich ein realistisches Bild davon, was Sie nicht wissen – und schließen sie dann diese Informationslücken. Dabei werden Sie wahrscheinlich feststellen, dass schon kleinere Veränderungen mehr Transparenz schaffen und es erleichtern, den Netzwerk-Traffic zu verstehen.“ (fm)

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

When Apple sued OpenAI last week, the argument it made was that former employees had stolen Apple data and then used it to benefit OpenAI. 

The technical details — an employee used “a rare, previously unknown authentication bug to access Apple’s shared network folders” — are interesting. But the larger story is Apple’s ridiculous attempt to stop its people from using anything they learned at Apple in other jobs.

“Hiring managers don’t mind some files being brought into the org during onboarding, but suddenly take umbrage when that same employee exits with some files later on,” said Mike Wilkes, enterprise CISO at Aikido Security. “Legal should be equally concerned about both events.”

The lawsuit focused on Chang Liu, an employee who had been recruited to work at OpenAI after working at Apple for eight years as a Senior System Electrical Engineer. The full text of the filing depicts a comedy of errors by Apple, offering the perfect “do not do” list of handling employee resignations — especially when they’re going to a direct competitor. 

“When Apple contacted Mr. Liu to sign Apple’s confidentiality reminder, schedule an exit interview, and confirm that he had returned his devices and complied with other exit procedures, Mr. Liu did not respond.” And “after leaving Apple, Mr. Liu failed to return an Apple-issued work laptop that he had previously authenticated to Apple’s network.”

First, typical procedure for handling departures is to tie the return of all equipment and the signing of documents to any final payments. With Apple, that is likely to be a large amount of money. The lawsuit does not say whether Apple exerted any financial pressure on their employee for compliance. 

But in terms of equipment with high-level access, why weren’t all privileges revoked, both for the employee and any and all company-issued devices? Did they not maintain a remote-wipe capability for these devices? Although remote-wipe is usually used when devices are missing or stolen, it should work as well when a departing employee refuses to return company equipment. 

According to Apple, Liu apparently had help at Apple from Tang Yew Tan, who was supposedly also interviewing with OpenAI. “While employed by OpenAI, [Liu] accessed and used his former colleague’s Apple-issued work computer that was authenticated to Apple’s network, without Apple’s authorization.”

Apple tried to make much of this Liu’s fault. Legally, yes, there might be liability there; still, Apple made itself look as if it couldn’t protect its own data. “Upon discovering that he had this unauthorized access to Apple’s systems, [the former employee] did not report it, return his stolen Apple-issued work laptop or delete the program that allowed the access.” 

Really, Apple? Your data-protection plan relies on ex-employees to “delete the program that allowed the access”? I’m not so sure you didn’t bring some of this data-leakage on yourselves. 

This gets worse: “Over several weeks, while developing hardware for OpenAI, Mr. Liu surreptitiously accessed and downloaded dozens of Apple’s confidential hardware-related files, including voluminous, detailed information about unreleased products, engineering presentations, technical specifications, and proprietary project data.”

Setting aside the issue of privileges, access, and unreturned equipment that apparently had its own privileges, that statement points to massive data exfiltration from Apple systems. Even if it is coming from a current employee, why didn’t that raise any red flags? 

Let’s get back to the broader implications. When professionals move from one company to another, they — of course — are bringing their experience and knowledge with them. Can Apple reasonably tell them that they can’t do so? Isn’t that experience and knowledge exactly why another company would want to hire them?

Now, to be sure, stealing diagrams and product spec sheets is a clear violation. Let’s say Apple spent a lot of money on some hardware research projects. A member of that technical team would learn an awful lot, all on Apple’s dime. 

But is it fair and reasonable for Apple to say that the former employee can’t leverage that knowledge at his or her next job? 

This brings us back to the point Wilkes made: If Apple is going to try to prevent any former employee from leveraging on-the-job experience, then it should instruct all new employees not to use anything they learned in a previous job. 

That would be ridiculous. Companies pay for experienced talent because of that experience. Why pay for expertise if you insist employees not leverage any of it?

Then there’s the amorphous nature of knowledge. So, it’s wrong to take detailed diagrams and spec details and hand them over to a new employer. But what if that worker heading out the door memorizes the documents (photographic memory) a day before resigning? Is a person prohibited from using something from memory?

There’s also the fruit-of-the-poisonous tree legal argument. Even if a former employee doesn’t directly use stolen data, what if their knowledge leads to other money-saving insights for the new employer? 

Given that Apple hires as many specialists as it loses to rivals, wouldn’t it make sense to leverage everything your workforce knows and then let new employers do the same? But before you do that, Apple, tighten your exiting employee tech controls. 

Then maybe you wont’t have to file lawsuits like this down the road.

Shadow IT has long been a major problem for IT leaders, but the biggest problem may be coming from the executive suite’s hunger for unsanctioned AI.

Nearly two-thirds of senior decision-makers admit to using unapproved AI tools, compared to just 31% of lower-level employees, according to a survey by Microsoft solutions partner TrustedTech.

The use of shadow AI is prevalent among senior executives even though three in four employees acknowledge security or data privacy risks related to the practice.

“Most shadow AI users are not ignorant of the risk,” TrustedTech says in a white paper. “They are deliberately choosing to use these tools anyway. This is not a training issue. It is a culture, incentives, and alternatives issue.”

In many cases, the problem is driven by a lack of approved tools, the report adds.

“People use shadow AI because what their employer hands them is worse than mainstream AI tools, or because nothing has been approved in the first place,” the report says. “That doesn’t change until the sanctioned tools are genuinely worth using.”

A question of authority

The use of shadow AI by CEOs and other C-suite executives can create major problems for CIOs, CISOs, and other IT executives because they may not have the authority to put the kibosh on it.

It also presents a challenge for IT leaders to provide the AI tools that employees and executives want to use.

When executives use shadow AI, CIOs are in a difficult position, because governance only works when it’s modeled from the top, says Andy Nolan, VP of technology at TrustedTech.

“If senior leaders bypass approved AI tools or policies, it sends an implied message that speed matters more than security and compliance,” he adds. “Employees notice that behavior, and it becomes much harder to ask the rest of the organization to follow standards that leadership isn’t following themselves, first.”

Another major problem is that executives often work with highly sensitive information, including financial data, strategic plans, intellectual property, and customer information, he notes.

But CIOs and CISOs also can’t solve the problem by becoming the AI police in every situation, Nolan says, because their role is to help the business innovate safely.

“That requires executive alignment, clear governance, and providing secure AI tools that people actually want to use,” he adds. “When leadership embraces those solutions, the rest of the organization is almost sure to follow.”

All risk, no reward

The use of shadow AI by senior executives puts CIOs and CISOs in an impossible position, agrees Amit Maloo, CISO at AI procurement provider Ivalua. CIOs and CISOs are held accountable for the risk exposure but have no visibility into the problem, he says.

“When senior leaders use ungoverned AI tools for business decisions, those decisions still have consequences, such as financial commitments, contract reviews, and data sharing,” he adds. “But there is no audit trail, no permissions model, or no way to reconstruct what happened or why.”

Part of the problem is that approved AI options often don’t meet the needs of users, Maloo says.

“AI policies alone aren’t enough; organizations need to pair governance with usability,” he adds. “If approved AI tools don’t meet the pace of business, employees at every level, including leadership, will find their own solutions. Successful organizations will be those that make the secure path the easiest path.”

IT leaders can’t solve the problem with more governance, he notes. “Policies and restrictions slow shadow AI down, but they don’t stop it, especially when the people using it are senior enough to absorb the disciplinary risk,” Maloo adds. “What CIOs can do is focus on providing tools that grant users full access to the necessary systems and data, eliminating the need to choose between a capable but ungoverned tool and a safe but limited one.”

Speed over security

The TrustedTech data echoes a June report from employee monitoring software vendor Teramind, which found that more than two-thirds of C-level executives prioritize speed over security when using AI tools, notes Nik Kale, a principal engineer and product architect at Cisco, and member of the Coalition for Secure AI.

In addition, the Teramind report found that two-thirds of enterprise AI activity runs through personal accounts on platforms for which the company already owns licenses, he notes.

“People are paying for the governed version and using the ungoverned version of the same product, so the problem isn’t the tools,” he says. “The approved path is slower, buried in procurement, or disconnected from where the work actually happens, and speed wins every time under a deadline.”

The problem then isn’t with the AI tools, but with the friction involved, he says. “People aren’t going around the front door because the room is locked,” Kale adds. “They’re going around it because the front door is slower.”

In many cases, the use of shadow AI exposes a couple of shortcomings in enterprise processes, adds Matthew Scavetta, chief technology innovation officer at IT solutions provider Future Tech Enterprise.

Many organizations don’t do a good job of making employees aware of the AI tools available to them, he says, and many organizations don’t offer training on the sanctioned applications, which drives users to pick products they are familiar with.

“If you don’t solve problems for people quickly or make people aware of which tools they can use safely, they will find a workaround,” he adds. “AI tools are no different than anything else.”

Shadow AI use by executives puts IT leaders in an incredibly difficult position, he says.

“CIOs, in particular, are under more and more pressure each year to keep up with what’s possible as tech influencers keep preaching about the potential of these tools,” Scavetta says. “CEOs and board members are constantly getting swept up in the hype; meanwhile, there are more and more case studies coming out showing how little ROI some organizations have realized. It’s a never-ending game of balancing possible with practical.”

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.

Passkeys have been around for some time, but enterprise-wide adoption to this point has been slow for a number of reasons. But soon, many Microsoft customers won’t have a choice.

Starting September 1, Microsoft will roll out passkeys as the default authentication method in its cloud-based identity and access management (IAM) service Entra ID. And following a transition period, Microsoft-provided SMS and voice authentication will officially end on February 1, 2027.

With this move, Microsoft seems to be underlining the urgent need for a more secure authentication standard, as attackers up their game with AI.

This is an “important milestone,” because it moves passwordless authentication from an optional security enhancement to the expected standard, noted Ensar Seker, CISO at SOCRadar. “That shift is significant as attackers increasingly rely on AI to automate phishing campaigns, generate convincing login pages, and conduct large-scale credential theft.”

Microsoft’s six-month passkey roll-out

Passkeys require users to authenticate via a fingerprint, facial scan, or lock screen mechanism, rather than a password. They can be stored on physical USB keys (like YubiKey), or as digital credentials on computers, phones, or in cloud accounts.

This method, Microsoft contended, reduces reliance on phishable authentication tools like SMS and voice, and hardens protection against credential theft.

Passkeys “work better for users and worse for cyberattackers,” Nadim Abdo, Microsoft corporate VP for identity and network access engineering, wrote in a blog post.

Microsoft’s announced timeline for rolling out passkeys is relatively aggressive:

• September 1, 2026: All SMS or voice-enabled users will be “auto-enabled and nudged” to register a passkey upon multifactor authentication (MFA) sign-in.
• September 18, 2026: Pricing, commercial terms, and a list of supported telecom providers will be shared for scenarios that still require SMS or voice authentication due to regulation or technical or operational challenges.
• October 30, 2026: Enterprises still using SMS and voice must select and configure a supported telecom provider through the Microsoft Security Store. From then on, they will be responsible for any telecom-related costs.
• February 1, 2027: Microsoft-provided telecom delivery for SMS and voice authentication ends as a native Microsoft Entra capability.

After February 1, enterprises that require SMS or voice for MFA must register a passkey before sign-in. There will be no opt-out option.

It’s important to note that these dates apply to public cloud-hosted Entra ID. Support for other cloud environments will follow a separate timeline; additional guidance and dates are to come.

While SMS and voice have served their purpose well, Abdo said, bringing MFA to billions of users who otherwise would have had none, the threat environment has changed in “speed, scale, and sophistication,” necessitating this move to passkeys.

The benefits of passkeys

SOCRadar’s Seker pointed out that passkeys fundamentally change the attack surface because, unlike with passwords, there is no transmission of shared secrets that can be stolen by threat actors. Authentication requires possession of the user’s device, along with biometric verification or a PIN.

“Even highly convincing AI-generated phishing pages cannot simply trick users into handing over a passkey the way they can with passwords or one-time codes,” he said.

So why haven’t we seen widespread enterprise adoption? Identity ecosystems are “fragmented,” Seker noted, and many enterprises still rely on legacy applications that only support passwords. They also struggle with cross-platform compatibility, lifecycle management, recovery processes, shared accounts, and employee onboarding and offboarding.

Further, “until recently, many organizations viewed passkeys as a consumer technology rather than an enterprise identity strategy,” he said.

Microsoft’s move changes that equation, because Entra sits at the center of many organizations’ identity infrastructure, Seker noted. Default settings are typically the strongest drivers of security adoption, so when passwordless authentication becomes required rather than optional, organizations are far more likely to deploy it at scale.

Its biggest benefit would be a “dramatic reduction” in credential-based attacks, Seker said. He pointed out that most successful compromises still begin with stolen credentials obtained through phishing, infostealer malware, password reuse, or adversary-in-the-middle attacks. Passkeys “eliminate or significantly reduce” many of those attack paths, while reducing password fatigue and the help desk costs related to password resets.

In addition, rather than trying to continuously improve users’ ability to detect increasingly sophisticated phishing attempts, passkeys remove the credential from the equation altogether, Seker noted. “That represents a more sustainable long-term security strategy than relying solely on user awareness training.”

Still, passkeys are not a silver bullet, as they do not stop endpoint compromise, session token theft, malicious insiders, or attackers who already have control of a trusted device. Enterprises must complement passkeys with endpoint protection, continuous monitoring, conditional access policies, and identity threat detection, Seker advised.

How enterprises can prepare

To prepare for the shift to passkeys, Microsoft advised enterprises to review their authentication policy and identify the groups still using SMS or voice authentication. They should then select the best authentication method for user devices and workflows, and ensure all employees are given passkeys and security keys.

Entra ID supports both synced passkeys (those stored in platform credential managers like iCloud Keychain and Google Password Manager), and device-bound passkeys such as Microsoft Authenticator passkeys, Entra passkey on Windows, or FIDO2 security keys.

Seker advised enterprises to evaluate support for FIDO2 and passkeys across their identity infrastructure, and to develop clear enrollment and recovery procedures. They should also educate users on what’s changing, how passkeys work, and how they can complete registration. Further, Seker said, it’s important to establish secure device management practices and to continue enforcing least privilege, conditional access, and risk-based authentication policies throughout the transition.

Ultimately, he pointed out, the move is crucial. “Over the next several years, organizations that continue relying primarily on passwords will likely face higher operational risk as AI continues to lower the cost and increase the effectiveness of credential-based attacks,” he said.

Passkeys have been around for some time, but enterprise-wide adoption to this point has been slow for a number of reasons. But soon, many Microsoft customers won’t have a choice.

Starting September 1, Microsoft will roll out passkeys as the default authentication method in its cloud-based identity and access management (IAM) service Entra ID. And following a transition period, Microsoft-provided SMS and voice authentication will officially end on February 1, 2027.

With this move, Microsoft seems to be underlining the urgent need for a more secure authentication standard, as attackers up their game with AI.

This is an “important milestone,” because it moves passwordless authentication from an optional security enhancement to the expected standard, noted Ensar Seker, CISO at SOCRadar. “That shift is significant as attackers increasingly rely on AI to automate phishing campaigns, generate convincing login pages, and conduct large-scale credential theft.”

Microsoft’s six-month passkey roll-out

Passkeys require users to authenticate via a fingerprint, facial scan, or lock screen mechanism, rather than a password. They can be stored on physical USB keys (like YubiKey), or as digital credentials on computers, phones, or in cloud accounts.

This method, Microsoft contended, reduces reliance on phishable authentication tools like SMS and voice, and hardens protection against credential theft.

Passkeys “work better for users and worse for cyberattackers,” Nadim Abdo, Microsoft corporate VP for identity and network access engineering, wrote in a blog post.

Microsoft’s announced timeline for rolling out passkeys is relatively aggressive:

• September 1, 2026: All SMS or voice-enabled users will be “auto-enabled and nudged” to register a passkey upon multifactor authentication (MFA) sign-in.
• September 18, 2026: Pricing, commercial terms, and a list of supported telecom providers will be shared for scenarios that still require SMS or voice authentication due to regulation or technical or operational challenges.
• October 30, 2026: Enterprises still using SMS and voice must select and configure a supported telecom provider through the Microsoft Security Store. From then on, they will be responsible for any telecom-related costs.
• February 1, 2027: Microsoft-provided telecom delivery for SMS and voice authentication ends as a native Microsoft Entra capability.

After February 1, enterprises that require SMS or voice for MFA must register a passkey before sign-in. There will be no opt-out option.

It’s important to note that these dates apply to public cloud-hosted Entra ID. Support for other cloud environments will follow a separate timeline; additional guidance and dates are to come.

While SMS and voice have served their purpose well, Abdo said, bringing MFA to billions of users who otherwise would have had none, the threat environment has changed in “speed, scale, and sophistication,” necessitating this move to passkeys.

The benefits of passkeys

SOCRadar’s Seker pointed out that passkeys fundamentally change the attack surface because, unlike with passwords, there is no transmission of shared secrets that can be stolen by threat actors. Authentication requires possession of the user’s device, along with biometric verification or a PIN.

“Even highly convincing AI-generated phishing pages cannot simply trick users into handing over a passkey the way they can with passwords or one-time codes,” he said.

So why haven’t we seen widespread enterprise adoption? Identity ecosystems are “fragmented,” Seker noted, and many enterprises still rely on legacy applications that only support passwords. They also struggle with cross-platform compatibility, lifecycle management, recovery processes, shared accounts, and employee onboarding and offboarding.

Further, “until recently, many organizations viewed passkeys as a consumer technology rather than an enterprise identity strategy,” he said.

Microsoft’s move changes that equation, because Entra sits at the center of many organizations’ identity infrastructure, Seker noted. Default settings are typically the strongest drivers of security adoption, so when passwordless authentication becomes required rather than optional, organizations are far more likely to deploy it at scale.

Its biggest benefit would be a “dramatic reduction” in credential-based attacks, Seker said. He pointed out that most successful compromises still begin with stolen credentials obtained through phishing, infostealer malware, password reuse, or adversary-in-the-middle attacks. Passkeys “eliminate or significantly reduce” many of those attack paths, while reducing password fatigue and the help desk costs related to password resets.

In addition, rather than trying to continuously improve users’ ability to detect increasingly sophisticated phishing attempts, passkeys remove the credential from the equation altogether, Seker noted. “That represents a more sustainable long-term security strategy than relying solely on user awareness training.”

Still, passkeys are not a silver bullet, as they do not stop endpoint compromise, session token theft, malicious insiders, or attackers who already have control of a trusted device. Enterprises must complement passkeys with endpoint protection, continuous monitoring, conditional access policies, and identity threat detection, Seker advised.

How enterprises can prepare

To prepare for the shift to passkeys, Microsoft advised enterprises to review their authentication policy and identify the groups still using SMS or voice authentication. They should then select the best authentication method for user devices and workflows, and ensure all employees are given passkeys and security keys.

Entra ID supports both synced passkeys (those stored in platform credential managers like iCloud Keychain and Google Password Manager), and device-bound passkeys such as Microsoft Authenticator passkeys, Entra passkey on Windows, or FIDO2 security keys.

Seker advised enterprises to evaluate support for FIDO2 and passkeys across their identity infrastructure, and to develop clear enrollment and recovery procedures. They should also educate users on what’s changing, how passkeys work, and how they can complete registration. Further, Seker said, it’s important to establish secure device management practices and to continue enforcing least privilege, conditional access, and risk-based authentication policies throughout the transition.

Ultimately, he pointed out, the move is crucial. “Over the next several years, organizations that continue relying primarily on passwords will likely face higher operational risk as AI continues to lower the cost and increase the effectiveness of credential-based attacks,” he said.

This article originally appeared on Computerworld.

Seventy-one percent of organizations say AI has access to core business systems. Only 16% govern that access effectively, according to the 2026 CISO AI Risk Report. Ask your IR team three questions: Where is your AI system inventory? What happens if a production model starts generating harmful outputs? Who has the authority to take it offline?

I’ve spent 14 years in security — energy, banking, telecom, manufacturing. Red team work, detection programs and the last several years focused on AI risk and ShadowAI. What I see consistently: Organizations have AI in production, they have an IR playbook and they think those two things are connected. They’re not.

The CISO who thinks their IR playbook covers AI incidents probably hasn’t tested it. The ones who have tested it know it doesn’t.

Two kinds of AI incident — and why that split matters more than the list

AI incidents surged 56.4% from 2023 to 2024, reaching 233 documented cases. Most IR frameworks — including NIST SP 800-61, MITRE ATLAS and the GLACIS AI Incident Response Playbook — provide you with a taxonomy of six incident types and stop there. While useful, it misses the more important split: Failures the model causes on its own, versus failures caused by a human. Your detection approach, your containment logic and your legal exposure are very different between those two groups.

Model-originated failures — degradation, bias, hallucinations — happen when the system does exactly what it was built to do, just badly. The Epic Sepsis Model, deployed across hundreds of US hospitals, had a sensitivity of only 33% at external validation. It missed two-thirds of actual sepsis cases and flooded physicians with false alerts, as a 2021 JAMA Internal Medicine study found. No one attacked it. It just quietly stopped working while every dashboard stayed green.

Externally induced failures — adversarial attacks, data poisoning, privacy breaches — happen when someone corrupts the inputs or the training environment. Tesla’s Autopilot phantom braking cases, investigated by NHTSA across hundreds of thousands of vehicles, show what adversarial input failures look like in a safety-critical system. These two groups need different primary defenses and their own playbooks.

Then there is the hybrid case, which carries the most legal exposure right now. Hallucinations are model-originated but they land in court like human errors. When Air Canada’s chatbot invented a bereavement fare policy, the airline was held liable. When a US federal court let Mobley v. Workday proceed, it accepted that an AI hiring platform could be directly liable as an ‘agent’ of the employers using it. Neither failure looked like a security incident. Both ended up as legal ones. If your legal team is not on your IR call tree, your playbook is already incomplete.

The CIA triad doesn’t cover a hallucination

The CIA triad — confidentiality, integrity, availability — does not apply to most AI incidents. When Air Canada’s chatbot made up a policy, nothing was unavailable, nothing was changed without authorization, nothing was disclosed. The framework simply doesn’t reach it. When the Epic Sepsis Model missed two-thirds of cases, there was no breach, no intrusion, no indicator of compromise. By every traditional IR metric, the system looked fine.

This is not an edge case. Classical IR frameworks assume deterministic failures with static indicators of compromise — an assumption that breaks down against probabilistic systems. Microsoft’s Security Blog said it well in April 2026: A model may produce harmful output today and something completely different from the same prompt tomorrow. The root cause is not a line of code. It is a probability distribution, and as Microsoft’s Security Blog put it, you cannot patch a probability distribution.

The numbers confirm the gap. Average AI incident detection time is 4.5 days. Sixty-seven percent of AI incidents come from model errors, not adversarial attacks — yet security budgets keep funding perimeter tools built for the latter. We are looking for the wrong signals, with the wrong tools, for the wrong failure modes.

What a mature AI IR capability looks like

I get asked this at every conference I speak at. Here is the short answer: Three things that mature teams have in place before any incident occurs.

First, an AI Bill of Materials (AIBOM) for every production system. Think of it like a software SBOM, but for AI: It documents the base model, training datasets, third-party dependencies and the full component stack. Without it, you don’t know what your AI is made of — and you can’t investigate a data poisoning incident or a supply chain compromise without that baseline. The OWASP GenAI Security Project released an open-source AIBOM generator in December 2025 that produces output in CycloneDX format aligned with SPDX standards. It is practical to implement now.

Second, a model card for every production AI system — not a document in a shared drive nobody opens, but something your IR team can pull up in the first ten minutes of a response. Training data provenance. Model version. Known performance limits, including which subpopulations showed weaker accuracy in testing. Access controls. Blast radius if it fails. Most organizations I work with have model documentation written for data scientists that no one in security can use at 2am. That is not documentation. That is liability.

Third, a named data scientist on the IR call tree. Not someone to brief after the incident — someone with authority to interrogate model behavior in real time. Traditional IR has a network engineer on call. AI IR needs the same logic applied to the people who understand how the failing system works.

A fourth thing that very few teams have: A documented rollback threshold for each deployed model. A pre-agreed definition of what anomaly rate, drift metric or fairness deviation triggers containment or a fallback switch. Teams without this spend the first hours of an AI incident debating whether what they are seeing is actually a problem. Teams with a threshold spend those hours responding.

Four things to do before the next incident

Rewrite your detection triggers. Output anomaly scoring, data distribution monitoring for drift and behavioral tracking of model API usage need to be in your detection layer. They will not come from your SIEM. This is instrumentation work at the AI system level.

Redefine containment. For most AI incidents, ‘isolate the system’ is the wrong first move. Switching to a rule-based fallback while keeping the service running may cause less harm than taking the system offline and triggering a business escalation. Each deployed model needs pre-defined rollback criteria and a named fallback. Write those down now.

Get legal in the room before the incident. Mobley v. Workday means both the AI vendor and the deploying organization can carry liability for bias incidents. Air Canada means you cannot disclaim what your AI says to a customer. If your legal team is learning about an AI incident from a press inquiry, something has already gone wrong.

Build your AI inventory and treat it like your asset register. Start with the AIBOM for your highest-risk systems — those with access to customer data, financial decisions or clinical workflows. The GenAI-IRF framework gives you a structured taxonomy for this work and the GLACIS AI Incident Response Playbook maps it to NIST SP 800-61 and MITRE ATLAS procedures your team can adapt without starting from scratch.

Forty-two percent of organizations have already had a suspicious or confirmed AI incident, and more than half say their security posture is catching up, inconsistent or reactive. Updating your playbook isn’t optional. Fix it before you need it.

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

At Amazon Web Services (AWS), artificial intelligence is already compressing security work that once took months into minutes.

In the old world, human red teams would find vulnerabilities, write reports, refine those reports, and eventually hand them to defenders, who would then begin building detections or fixes, Steve Schmidt, chief security officer at AWS, tells CSO. That process could take “two, four, six, eight, 10 months,” Schmidt says.

“Now with proper application of AI, we can have the detections built for the problems the red team finds in 15 minutes-ish,” he says. “I think the outside is about four hours.”

That kind of workflow offers a glimpse of what AI could make possible for the most sophisticated security organizations: AI agents testing systems, other agents generating defenses, and human security engineers validating results and refining the feedback loop.

But it also raises a more uncomfortable question for the rest of the cybersecurity industry: What happens to organizations that cannot build anything close to that?

The concern has become significant enough that the Trump administration recently directed agencies to expand access to AI-enabled cybersecurity capabilities for resource-constrained organizations, including rural hospitals, community banks, and local utilities.

The order reflects a growing fear that AI could deepen a divide that has existed in cybersecurity for years: the divide between organizations with money, expertise, and engineering depth, and those struggling to keep pace with basic security demands.

Yet security leaders and practitioners suggest the impact of AI will be more complicated than a simple widening gap. Some experts say AI is merely adding a new layer to a long-standing security poverty problem. Others argue AI could democratize capabilities once reserved for elite organizations. Still others see today’s divide as real, but potentially temporary, as models become cheaper, more open, and easier to run.

The class divide was already here

For Matt Warner, co-founder and CTO of Blumira, the premise that AI is creating a cybersecurity class divide misses a key point: The divide already exists.

“I would go even a step further and say that there has been a class divide for the last 10 to 15 years,” Warner tells CSO.

What AI changes, he argues, is not necessarily the existence of the divide but how stark it becomes. Larger organizations have money, people, and time to experiment with AI. Smaller organizations often do not.

“The big differences that we’re seeing, especially from where we sit in the world, is the difference is getting starker in having the resources to leverage AI and the time to leverage AI more than anything else,” Warner says.

That distinction matters because many smaller organizations are already overwhelmed. Warner pointed to resource-constrained local governments and small or midmarket organizations that are still far behind large enterprises in basic IT and security maturity.

“I can find you a county in Michigan with two IT people for 2,000 employees,” Warner says. “Those people don’t have time to leverage AI and even learn how to use AI because they’re mostly just trying to put out fires.”

That problem is not unique to AI. Smaller organizations have long struggled to patch systems, prioritize vulnerabilities, monitor environments, and respond to incidents with limited staff. AI may help eventually, but only if those organizations have enough capacity to adopt it.

Wendy Nather’s framework gets an AI layer

Anton Chuvakin, security advisor in the office of the CISO for Google Cloud, sees the AI divide as part of a much older problem.

“I feel like it sends me back to when Wendy Nather invented the security poverty line,” Chuvakin tells CSO, referring to Nather’s 2011 concept describing organizations that lack the money, expertise, capability, or influence to implement effective security.

Chuvakin is skeptical that AI fundamentally changes that model. “I don’t think AI necessarily breaks that model,” he says. “I think it just adds another dimension.”

Cybersecurity has always been shaped by unequal access to top talent, tools, and services, Chuvakin argues. Large organizations could afford better SIEM deployments, advanced DLP programs, threat hunters, application security experts, and incident response retainers. Smaller organizations often could not.

AI may become another scarce resource, but Chuvakin cautions against overstating the role of model cost alone. In his view, the bigger structural issue may be talent rather than tokens.

“Prices for people won’t drop, but prices for LLMs may drop,” he believes.

That means the organizations with the greatest advantage may not simply be those that can afford the most expensive models. They may be the ones that can afford the people who know how to use them — and, as the frontier-access debate below suggests, that talent gap may prove more durable than any gap in model access itself.

AI creates new costs — and new uncertainties

Nather herself, now senior research initiatives director at 1Password, sees AI affecting every dimension of the security poverty line: money, expertise, capability, and influence.

The financial challenges are not limited to whether an organization can pay for an AI tool. In some cases, organizations that cannot afford enterprise licensing may end up making tradeoffs around privacy.

“If an organization can’t afford an enterprise license for the models they’re using, then they can’t keep their data private,” Nather tells CSO. “So, they have to give up privacy because they can’t afford privacy.”

That’s a new twist on an old dimension of the poverty line: It’s not just that under-resourced organizations lack a capability, but that the capability they can afford comes bundled with a risk wealthier organizations don’t have to accept.

Token-based pricing adds another problem: unpredictability. “At this point, nobody knows how much they’re going to burn in tokens at any given time,” she says.

That makes budgeting difficult for organizations that cannot absorb surprise costs. Nather also warns that usage-based pricing is controlled by providers and can change over time, leaving customers with limited leverage.

“The charging practice is in the hands of the providers, and they can change it at any time,” she says.

For organizations already operating below the security poverty line, that uncertainty could make AI adoption harder, even if the technology itself becomes more capable.

Access to frontier models may be a temporary divide

Dave Baggett, SVP/GM of the security suite at Kaseya, agrees there is security class divide dynamic playing out today, particularly around access to frontier models.

“There’s definitely a haves and have-nots issue around Mythos specifically because most people don’t have it,” Baggett tells CSO. But he doesn’t think the divide will have a long-term impact. Open-weight models, quantization, mixture-of-experts architectures, and increasingly powerful commodity hardware, he argues, are closing the gap faster than most people expect.

While not every organization will build a frontier model, he says, more organizations may be able to run capable models locally or use cheaper systems that approximate what today’s elite models can do.

“What it says for finding vulnerabilities is at that point, open-source people can run this stuff,” Baggett says. “Then you’re back to having a symmetrical opportunity where the defenders who are writing the open source can run the same tools the attackers would and have them fix the issues.”

His bottom line is that the divide may be real but short-lived. “Right now, there certainly is a have, have-not schism, but it may not be there for long,” Baggett says — a view Chuvakin shares, though he frames it in terms of the model market rather than open source specifically.

“I don’t think it’s the lowering prices example, but it’s more like you’re a top-tier model maker, I’m a second-tier model maker. My model in a year would do what your model did a year ago,” Chuvakin says.

The real advantage is operational depth

Schmidt’s description of AI use at AWS points to another kind of divide: not access to AI, but the ability to operationalize it.

AWS uses multiple models for different tasks, Schmidt says. One model may discover vulnerabilities, while other models validate results or help build defenses. Humans remain accountable for evaluating what the systems produce.

“Because we believe really strongly in human accountability for the use of AI from end to end, we still have humans take a look at what the systems come up with to determine whether they are reasonable and appropriate,” he says.

That workflow requires more than a model. It requires corporate data, secure infrastructure, feedback loops, security engineers, data scientists, and AI specialists who can work together.

Schmidt also pushes back on the idea that running AI locally on powerful consumer hardware is a substitute for production-grade security infrastructure. “Often the value of the model is also dependent on its proximity to data so that the model can ingest, use, and reason about data,” he says. “As a security person, I do not want that to be on your laptop.”

Experimentation on a laptop is useful, Schmidt says, but it is not the same as a secure production environment.

“I want the data to be somewhere safe that I can control, that I can see, that I can reason about, not sitting on your laptop,” he says. “Experimentation in there, awesome. That’s great. But it is not a production infrastructure component.”

That distinction may define the emerging AI security gap. Many organizations may be able to access AI tools. Far fewer may be able to safely integrate them into real security workflows.

The democratization argument

Phil Venables, a partner at Ballistic Ventures and former CISO of Google Cloud, takes the most optimistic view.

Asked whether AI is widening the gap between well-resourced and under-resourced security organizations, Venables tells CSO, “No, I actually think it’s the exact opposite.”

The reason, he argues, is that AI packages expertise and automation in ways that can be delivered broadly. “One of the fantastic things about AI, and we’re already starting to see this, is [that it’s] a great democratizer of capabilities,” he says. “AI packages up expertise and automation capabilities at a level beyond what prior waves of technology have done, and it makes it available at scale into organizations that have not previously been able to afford these things.”

He points to red teaming as an example. Nearly every organization would like a world-class red team, but few can afford one.

“Pretty much every organization on the planet would love to have a world-class red team to constantly test their security to find and fix things before attackers do,” Venables says. “But very few organizations have ever been able to afford to build a high-end red team.”

AI agents, he argues, could make that kind of capability available more economically. The same pattern could apply to insider threat; third-party risk; software security; governance, risk and compliance; and security operations.

“So even the smallest and resource-constrained organizations can now have access to a higher-end capability,” he maintains.

Venables does see a danger zone, however: under-resourced security teams inside organizations with aggressive AI ambitions. Those teams may struggle to keep up as the rest of the business adopts AI rapidly. But for many small and midsize organizations, he believes AI could improve access to security capabilities they never had before.

A divide over AI — or over readiness?

For elite organizations, AI is already becoming a force multiplier. Security teams with deep engineering talent, mature data infrastructure, and strong governance can use AI to accelerate testing, detection engineering, vulnerability discovery, and risk management.

For smaller organizations, the picture is less clear. AI may eventually package scarce expertise into affordable services. Open models may reduce dependence on expensive frontier systems. But organizations below the security poverty line still face familiar constraints: too few people, too little time, limited expertise, unpredictable costs, and weak leverage over vendors.

The emerging divide may therefore be less about who has access to AI and more about who can turn AI into durable security outcomes.

That makes the question facing cybersecurity more complicated than whether AI will create haves and have-nots. The industry already had them.

The real question is whether AI becomes another technology that rewards the organizations already best positioned to use it — or the first major security advance in years that helps those below the poverty line finally catch up.

앤트로픽이 자사 AI 모델이 문제를 해결하는 내부 과정을 보다 깊이 들여다볼 수 있는 새로운 분석 기법을 공개했다. 모델이 특정 방식으로 판단하고 행동하는 이유를 파악할 수 있게 되면서, 기업의 AI 평가와 구매 기준에도 적지 않은 영향을 미칠 것으로 전망된다.

앤트로픽은 최근 ‘J-스페이스(J-space)’라고 이름 붙인 새로운 내부 표현 공간을 발견했다고 밝혔다.

앤트로픽은 공식 블로그를 통해 “클로드(Claude)는 수많은 내부 처리 과정 가운데 특별한 역할을 수행하는 소수의 신경 패턴 집합을 스스로 형성했다”라며 “이 패턴 집합을 발견하는 데 야코비안(Jacobian)이라는 수학 개념을 활용한 기법을 사용했기 때문에 이를 ‘J-스페이스’라고 명명했다”고 설명했다. 회사는 ‘야코비안 렌즈(Jacobian Lens·J-렌즈)’라는 분석 기법을 통해 J-스페이스 내부를 관찰한다.

앤트로픽은 “J-스페이스의 각 패턴은 특정 단어와 연결돼 있다”라며 “하지만 특정 패턴이 활성화됐다고 해서 모델이 실제로 그 단어를 출력하려는 것은 아니다. 단지 해당 단어가 모델의 ‘생각 속’에 있다는 의미”라고 밝혔다.

이어 “언어 모델의 ‘스크래치패드(scratchpad)’나 ‘생각의 연쇄(Chain of Thought)’처럼 추론 과정에서 스스로 작성하는 텍스트와 J-스페이스는 다르다”라며 “J-스페이스는 모델 내부 신경망 활성화 영역에서 조용히 작동하기 때문에 모델은 개념을 텍스트로 적지 않고도 내부적으로 사고할 수 있다”고 설명했다.

이번 연구는 앤트로픽이 2024년 공개했던 내부 스크래치패드보다 훨씬 발전한 개념이다. 당시에는 모델이 답변이나 행동을 준비하면서 무엇을 고려하는지를 보여주는 수준이었다. 반면 이번 기술은 모델의 훨씬 깊은 내부 사고 과정을 분석할 수 있어 AI 시스템을 평가하고 구매하는 방식 자체를 바꿀 가능성을 제시한다.

논문에 소개된 사례도 이러한 가능성을 보여준다. 일부 모델은 테스트 과정에서 부적절한 행동을 하지 않아 안전한 모델처럼 보였다. 그러나 J-스페이스를 분석한 결과, 해당 모델은 자신이 테스트를 받고 있다는 사실을 인지하고 있었으며, 그 때문에 문제 행동을 의도적으로 하지 않았을 가능성이 드러났다. 이는 아이들이 누군가 자신을 지켜보고 있다는 사실을 알 때 행동을 달리하는 것과 유사하다고 연구진은 설명했다.

AI 에이전트 기업 제니티(Zenity)의 AI 표준·거버넌스 총괄인 록 램브로스(Rock Lambros)는 “앤트로픽은 모델이 테스트를 받고 있다는 사실을 인식하거나, 좋은 결과를 얻기 위해 행동을 꾸미거나, 프롬프트 인젝션을 탐지하거나, 아직 실행하지 않은 목표를 내부적으로 유지하고 있는 상황까지 포착할 수 있는 분석 도구를 만들었다”라며 “일부 바람직한 행동은 모델이 자신이 평가받고 있다는 사실을 알고 있었기 때문에 나타난 것일 수 있다”고 말했다.

그는 기업 고객 역시 AI 안전성 벤치마크를 해석할 때 이러한 점을 고려해야 한다고 지적했다.

램브로스는 “프로젝트에 적합한 모델인지는 모델이 알고 응시한 리더보드 결과가 아니라, 기업이 보유한 데이터와 실제 공격 시나리오를 활용한 자체 테스트를 통해 검증해야 한다”고 설명했다.

이처럼 모델 내부를 들여다볼 수 있는 능력은 CIO에게도 중요한 의미를 갖는다.

램브로스는 “자사 모델이 겉으로 드러나지 않는 문제 행동을 스스로 발견하고 그 결과를 공개할 수 있는 공급업체라면 신뢰성 검증 체계가 상당히 성숙했다는 의미”라며 “이러한 역량은 단순한 뉴스가 아니라 공급업체 실사(Due Diligence) 과정에서 반드시 확인해야 한다”고 말했다.

이어 “이제 모든 AI 모델 공급업체에 던져야 할 질문은 ‘모델 출력만으로는 볼 수 없는 내부 상태 가운데 무엇을 관찰할 수 있으며, 실제로 어떤 문제를 발견했는가’가 돼야 한다”고 덧붙였다.

AI 거버넌스 컨설팅 기업 디지털 520(Digital 520)의 수석 컨설턴트 노아 케니(Noah Kenney)도 비슷한 견해를 내놨다.

케니는 “감시받고 있다는 사실을 알기 때문에 더 바람직하게 행동하는 모델은 안전한 모델이 아니다. 단지 포커페이스를 잘하는 모델일 뿐”이라며 “레드팀 테스트 결과나 모델이 위험한 요청을 거부한 내부 파일럿, ‘테스트해 보니 문제가 없었다’는 모든 사례를 다시 검토해야 한다. 이제는 모두 단서를 달고 해석해야 하기 때문”이라고 말했다.

또한 CIO는 AI 에이전트가 특정 방식으로 작업을 수행한 이유가 원래 그렇게 설계됐기 때문인지, 아니면 단순히 자신이 테스트받고 있다는 사실을 알아차렸기 때문인지를 구분해야 한다고 강조했다.

케니는 “이 질문에 대한 답에 따라 모델 평가 결과에 대한 해석도 크게 달라져야 한다”고 말했다.

아직 고객은 사용할 수 없는 J-렌즈

노아 케니는 “이번 연구는 지금까지 업계가 AI 모델 평가를 통해 측정해 온 것이 모두가 생각했던 것만큼 견고한 지표가 아니었다는 사실을 인정한 것”이라며 “이제 다른 프런티어 AI 연구소들도 자사 평가 체계 역시 같은 문제를 안고 있는지 답해야 할 것”이라고 말했다. 이어 “CIO에게 이번 논문은 기업의 AI 모델 리스크 관리 체계 전반을 다시 점검하라는 경고”라고 평가했다.

렉시스넥시스 리스크 솔루션 그룹(LexisNexis Risk Solutions Group)의 CISO 플라비오 비야누스트레(Flavio Villanustre)는 J-스페이스를 분석하면 모델 효율성까지 높일 수 있다고 설명했다.

비야누스트레는 “J-스페이스는 모델 내부를 직접 들여다볼 수 있는 능력을 제공하기 때문에 사용자에게 매우 유용하다”라며 “특히 설명 가능성이 중요한 규제 산업에서는 응답의 근거와 인과관계를 충분히 분석해야 하는데 큰 도움이 될 수 있다”고 말했다.

이어 “사용자가 프롬프트를 더욱 정교하게 다듬는 데에도 활용할 수 있어 모델의 토큰 사용 비용을 최적화하는 데 도움이 된다”고 설명했다.

다만 현재로서는 이러한 정보를 직접 활용하기 어렵다. AI 공급업체를 통해 간접적으로 접근하거나 향후 계약 협상을 통해 권한을 확보하는 것이 사실상 유일한 방법이다. 비야누스트레는 일부 기업은 앤트로픽의 FDE 프로그램에 비용을 지불하면 J-스페이스에 직접 접근할 수도 있다고 덧붙였다.

그는 “J-스페이스는 CIO에게 매우 유용한 도구”라면서도 “이를 실제로 활용하려면 분석 결과를 해석할 수 있는 전문 인력이 필요하다. 요구되는 역량은 일반 데이터 분석가는 물론 데이터 사이언티스트 수준을 넘어선다”고 말했다.

기술 컨설팅 기업 트라이베카 소프트테크(Tribeca Softtech)의 최고전략책임자(CSO) 아만 마하파트라(Aman Mahapatra)는 현재 기업 고객이 J-렌즈를 실제 운영에 활용하기는 어렵다고 지적했다.

그는 “현재 기업 고객은 야코비안 렌즈를 활성화할 수도 없고, API를 통해 모델의 잔차 스트림(residual stream)을 분석할 수도 없으며, 논문의 핵심 결과를 도출한 제거 실험(ablation study)도 수행할 수 없다”고 설명했다.

이어 “올해 3분기 안에 CIO가 J-스페이스 모니터링을 실제 운영 환경의 배포 승인 기준으로 활용할 수 있느냐는 질문에 대한 답은 ‘아니다'”라고 말했다.

다만 마하파트라는 앞으로는 다른 방식의 접근 경로가 마련될 것이며, CIO들이 이를 적극 요구해야 한다고 주장했다.

그는 “고객이 직접 접근할 수 없다면 결국 이번에도 앤트로픽을 믿을 수밖에 없다”라며 “바로 그렇기 때문에 기업들은 업계 전반에 새로운 신뢰 검증(Assurance) 체계를 요구해야 한다”고 말했다.

이어 “현재 AI 모델 공급업체들은 자체 도구로 스스로 모델을 점검한 뒤 안심할 수 있는 연구 결과를 발표하는 방향으로 나아가고 있다”라며 “그러나 어떤 규제 산업도 다른 공급업체에게 이런 방식의 검증을 신뢰 기준으로 인정하지 않는다”고 지적했다.

마하파트라는 “은행은 신용평가 업체가 ‘우리 모델은 우리가 검증했으니 믿어달라’고 말한다고 이를 받아들이지 않는다”라며 “의료 업계 역시 임상 의사결정 지원 시스템 공급업체의 자체 검증만으로는 신뢰하지 않는다. 파운데이션 모델 공급업체만 예외로 취급해야 할 원칙적인 이유는 없으며, 이번 J-스페이스 연구는 그 이유를 분명하게 보여준다”고 말했다.

새로운 가시성이 요구하는 변화

마하파트라는 기업이 장기적으로는 AI 모델의 내부 동작을 독립적으로 검증할 수 있는 환경을 요구해야 한다고 강조했다.

그는 “기업이 취해야 할 올바른 장기 전략은 고객이 사용할 수 있는 API, 특권 접근 권한을 가진 독립적인 제3자 감사기관, 또는 은행의 모델 리스크 관리팀이 공급업체의 안전성 검증팀과 동일한 도구를 사용할 수 있도록 하는 개방형 해석 가능성(Interpretability) 표준 등을 요구하는 것”이라고 말했다.

이어 “현재는 이런 환경이 전혀 마련돼 있지 않다”라며 “하지만 CIO들이 추진해야 할 로드맵에는 반드시 포함돼야 하며, 이번 연구는 그 필요성을 보여주는 가장 강력한 근거”라고 평가했다.

실제로 이번 연구 결과는 기업의 AI 전략 자체를 근본적으로 바꿀 가능성을 갖고 있다.

마하파트라는 “기업이 AI 에이전트를 도입할 때 가장 어려운 과제는 자율 시스템이 설명하는 추론 과정과 실제 내부 추론이 일치하는지를 검증하는 것”이라며 “지금까지는 모델이 출력한 내용만 감사할 수 있었고 실제 추론의 상당 부분은 보이지 않는 곳에서 이뤄졌다. J-렌즈는 바로 이 간극을 정면으로 해결하려는 시도”라고 설명했다.

그는 기업의 AI 구매 담당자들이 앞으로 모델 공급업체에 내부 상태를 관찰할 수 있는 해석 가능성 도구를 제공하는지 반드시 확인해야 한다고 조언했다. 특히 고객 환경에서 기만 행위(deception), 평가 회피(evaluation gaming), 목표 불일치(goal misalignment) 등을 모니터링할 수 있는 기능을 제공하는지를 구매 과정에서 질문해야 한다고 강조했다.

마하파트라는 “현재 이러한 질문에 제대로 답할 수 있는 공급업체는 거의 없다”라며 “관련 도구가 완전히 성숙하기 전이라도 내부 상태의 가시성을 구매 기준으로 요구하기 시작하는 CIO가 앞으로 공급업체의 제품 발전 방향을 결정하게 될 것”이라고 말했다.

이어 “향후 규제기관이 ‘기업은 자율 AI 에이전트가 실제로 주장한 대로 동작한다는 사실을 어떻게 확인했는가’를 묻기 시작하면, 이런 기업만이 실질적인 신뢰성을 입증할 수 있을 것”이라고 전망했다.

표준화의 시작

CIO가 클로드의 새로운 내부 가시성을 활용할 수 있는 또 다른 방법은 이미 해당 정보에 접근할 수 있는 제3자를 활용하는 것이다. 실제로 이번 보고서에는 구글의 AI 연구원이 오픈웨이트(Open-weight) 모델에서 일부 연구 결과를 독립적으로 재현하는 데 성공했다는 내용이 포함됐다.

소프트웨어 개발 기업 컴프 AI(Comp AI)의 CEO 루이스 카하트(Lewis Carhart)는 “이는 공급업체의 주장만이 아니라 경쟁사가 해당 분석 기법을 검증했다는 의미”라며 “기술적으로 무엇이 가능한지를 보여주지만, 기업이 직접 이를 검증할 수 있는 수단을 제공하는 것은 아니다”라고 설명했다.

그는 이러한 상황이 컴플라이언스 분야에서도 이미 여러 차례 반복됐던 패턴이라고 말했다.

카하트는 “SOC 2 역시 처음부터 독립적인 감사 기준으로 출발한 것은 아니었다”라며 “초기에는 공급업체가 자체 통제 체계를 설명하는 수준에 머물렀고, 이후 시장이 수년에 걸쳐 이를 외부에서 검증할 수 있는 인프라를 구축했다”고 설명했다.

이어 “AI 해석 가능성(Interpretability)도 지금은 바로 그 출발점에 있다”라며 “J-렌즈 분석 결과가 제3자 감사 보고서나 모델 카드(Model Card), 또는 규제기관 제출 문서에 포함되기 시작해야 CIO에게 실질적인 의미를 갖게 될 것”이라고 말했다.

그는 “결국 리스크 관리 조직이 공급업체의 주장만이 아니라 객관적인 근거로 제시할 수 있는 자료가 마련돼야 한다”고 덧붙였다.

AI 전략 변화 이끄나

컨설팅 기업 액셀리전스(Acceligence)의 CEO 저스틴 그라이스(Justin Greis)는 이번 기술이 기업 AI 전략에도 상당한 변화를 가져올 것으로 전망했다.

그는 “향후 AI 거버넌스 플랫폼은 프롬프트와 출력 결과, 사용자 신원 정보, 정책 결정, 도구 사용 기록뿐 아니라 J-렌즈가 제공하는 내부 신호까지 함께 활용하게 될 것”이라고 말했다.

이어 “미래의 AI 제어 플랫폼은 AI 에이전트가 프롬프트 인젝션 시도를 인식했는지, 민감한 정보가 포함됐음을 이해했는지, 상충되는 목표를 감지했는지, 또는 실제 위험한 행동을 실행하기 전에 그러한 방향으로 추론하고 있었다는 징후가 있었는지를 지속적으로 평가할 수 있을 것”이라며 “이러한 신호는 정책 집행, 사람의 개입 여부 결정, 감사 로그 작성, 기업 AI 환경 전반의 신뢰도 평가 등에 활용될 것”이라고 설명했다.

그는 이러한 변화가 현재 CIO에게도 실질적인 의미를 갖는다고 강조했다.

그라이스는 “AI 공급업체를 평가하는 기준 자체가 달라지고 있기 때문”이라며 “1년 전만 해도 기업은 모델의 정확도와 지연시간, 보안, 비용을 주로 평가했다. 앞으로는 AI 에이전트의 행동과 추론 품질, 정책 준수 여부, 안전성 모니터링, 감사 가능성에 대해 공급업체가 얼마나 높은 수준의 운영 가시성을 제공하는지도 중요한 평가 항목이 될 것”이라고 말했다.

마하파트라는 이러한 변화가 CIO에게 강력한 협상 카드가 될 수도 있다고 분석했다.

그는 “실제 협상력이 발휘되는 시점은 계약 갱신 과정”이라며 “다음 계약 갱신 때 해석 가능성 보고서 제공과 제3자 감사 접근 권한을 계약 조항에 포함시켜야 한다. 지금은 이러한 조건을 비교적 쉽게 확보할 수 있지만 계약 체결 이후에는 훨씬 큰 비용이 들기 때문”이라고 말했다.

이어 “2027년 신뢰성 확보 경쟁에서 앞서는 CIO는 2026년에 이미 AI 모델 공급업체의 ‘우리를 믿어달라’는 말만 받아들이지 않고, 공급업체가 아직 계약을 더 필요로 하는 시점에 필요한 조항을 계약서에 반영한 사람일 것”이라고 전망했다.
dl-ciokorea@foundryco.com

A cloud intrusion that ended with the deployment of cryptomining malware has exposed a bigger risk for enterprises: AI gateways that concentrate access to cloud identities, permissions, and foundation models in a single, highly privileged system.

Researchers from cybersecurity firm Darktrace found attackers compromising an AWS EC2 instance acting as a LiteLLM proxy for Amazon Bedrock, eventually deploying XMRig cryptomining malware, along with attempts to abuse cloud identities and AI services.

Although the attack ended in cryptomining, researchers said the bigger concern is that AI gateways centralize model access, identities, and cloud privileges, making them valuable targets.

Experts found the attack familiar and consistent with past cloud attack techniques.

“Strip off the AI branding and this is a cloud intrusion pattern we’ve been watching since at least 2018: SSH open to the internet, brute-force attempts, a commodity XMRig miner, and repeated connections to a mining pool,” said Sean Malone, CISO at BeyondTrust. “Even the AI-specific angle, stolen credentials probing Bedrock model access, has had a name since 2024: LLMjacking.”

However, Malone agreed with Darktrace researchers on the potential blast radius. “AI gateways concentrate credentials, cloud permissions, and model access into a single choke point, so a routine intrusion lands on a privileged asset,” he explained.

The attack followed a known pattern

According to Darktrace, the compromised EC2 instance appeared to support LiteLLM activity and was associated with an IAM role capable of accessing Amazon Bedrock resources. While researchers could not conclusively determine the initial access vector, they said the attack followed a sequence commonly seen in cloud intrusions.

Before the miner was deployed, the instance had SSH exposed to the internet, with port 22 accessible from anywhere. Darktrace observed a high volume of inbound SSH connection attempts, largely originating from a single external IP address, indicating probable brute-force activity.

Shortly afterward, the host downloaded a ZIP archive containing XMRig cryptomining malware before repeatedly connecting to a known mining pool over HTTPS.

Darktrace stressed that it could not confirm whether the SSH activity directly led to the compromise because host-level logs were unavailable. However, the timing of the SSH exposure, miner download, and subsequent mining-pool communications strongly suggested the EC2 instance had been compromised and repurposed for unauthorized compute activity.

Compromised AI gateways are a big deal

The disclosure also detailed suspicious IAM activity observed separately, a day later, by another AWS identity. Among the unusual actions were a “GetSendQuota” API call from an IP address in Vietnam, attempts to enumerate and invoke Amazon Bedrock foundation models, and an effort to create a new IAM user using a randomly generated username.

This behavior is commonly associated with establishing persistence following credential compromise. However, Darktrace could not link the IAM activity directly to the LiteLLM incident.

Jason Soroko, senior fellow at Sectigo, said the incident’s significance lies less in the cryptominer than in the system that was compromised.

“These gateways are becoming brokers for identity, model access, prompts, logs, and policy,” he noted. “When one is exposed over SSH or backed by broad IAM permissions, it is no longer just another EC2 instance. It is a control point for AI operations.”

To protect against such attacks, Soroko added, security teams should close public admin paths, remove long-term keys where possible, scope IAM permissions, monitor Bedrock and model access patterns, and correlate workload telemetry with control-plane events.

Darktrace said it helped in the timely containment of the attack. “The cryptomining activity was received by Darktrace’s Managed Threat Detection service and reviewed by Darktrace’s SOC,” the researchers said in a blog post shared with CSO ahead of its publication on Thursday. “Following review, the activity was escalated to the customer. This escalation provided the customer with timely notification of active resource abuse in the AWS environment.”

In a client engagement last year, an LLM-based deployment agent with standing access to a production Kubernetes cluster triggered a four-hour outage through a malformed configuration push. In the IAM, the agent appeared as a service account with a long-lived API key, no MFA, no scoped revocation path. When the incident review team asked which human had authorized the agent’s last action, no one in the room could answer. I have watched a version of that question go unanswered in three engagements over the past year, in three different sectors, with three different vendor stacks.

Every CISO deck right now contains a slide about agentic AI. Far fewer contain a slide about who, in identity terms, these agents actually are. That gap is the more dangerous one. The first slide is a strategy question. The second is a control question — and it is the one your auditors, your incident responders and your board will eventually ask. Gartner’s Top Cybersecurity Trends 2026, published by Director Analyst Alex Michaels, names both halves of that gap — agentic AI oversight (Trend 1) and IAM adaptation to AI agents (Trend 4) — as the forces redefining cyber risk this year.

This piece sets out a six-stage maturity model for non-human and agent-based identities (NHIs), the six minimum requirements that have to be met before any production deployment is defensible and the single most consequential reporting decision in the access-and-identity dimension: refusing the arithmetic mean across human and non-human identity governance.

Why agent-based systems break the existing identity model

A conventional service account performs a narrow, predictable task: it fetches a backup, runs a scheduled report, signs a build artifact. Its scope is fixed at design time. The controls around it — rotation, vaulting, audit — are well-understood.

An agent-based system does not work this way. It receives an intent, decomposes it into steps, calls whichever tools or APIs it judges appropriate and produces an outcome that was not specified action-by-action in advance. KuppingerCole’s 2026 Leadership Compass on Non-Human Identity Management notes that NHIs now outnumber human users in many enterprise environments, in some cases by a factor of 25 to 50. The same compass, authored under Principal Analyst Martin Kuppinger, observes that the tooling built around joiner-mover-leaver lifecycles was never designed to discover, attribute or govern these identities at that scale.

The OWASP GenAI Security Project has catalogued the resulting attack surface in two iterations — the Agentic AI Threats & Mitigations taxonomy in February 2025 and the more operational OWASP Top 10 for Agentic Applications later that year, categories ASI01 through ASI10. The notable finding is that three of the four highest-rated risks are identity questions: tool misuse and exploitation (ASI02), identity and privilege abuse including delegated and inherited trust (ASI03) and rogue agents that act outside their intended behavior (ASI10). A fourth, agentic supply chain vulnerabilities (ASI04), is identity adjacent.

CISA’s first joint Five Eyes advisory on the topic — Careful Adoption of Agentic AI Services, published 1 May 2026 with NSA, the Australian Signals Directorate’s ACSC, the Canadian Centre for Cyber Security, NCSC-NZ and NCSC-UK — converges on the same conclusion. Privilege risk is named the foundational concern. The Center for Internet Security followed with its own report on prompt injection as the top compounding risk in April 2026, and NIST’s AI Agent Standards Initiative, launched February 2026, is now drafting the formal standards that will sit alongside this guidance.

In other words, the dominant risk class introduced by agentic AI is not novel cryptography or some new exploit primitive. It is the unbounded scope of an identity that the existing IAM model was never asked to govern.

Six minimum requirements before any agent goes to production

Before any maturity discussion is useful, there is a floor. The following six requirements mark the line below which an agent-based system is not responsibly deployable in an enterprise environment. They are derived from incidents and audit findings I have collected across pharma, energy, finance and manufacturing engagements, and they are technically feasible on modern IAM and PAM platforms — though rarely on the IAM stacks most enterprises actually have today.

• Each agent receives a uniquely attributable non-human identity. Shared service accounts across multiple agents, or shared between an agent and a human administrator, are not acceptable.
• Permissions are granted under an on-behalf-of model. The agent acts on the authority of a named human principal, inheriting that principal’s permissions, scoped to a defined purpose. It never acts from its own standing authority.
• No long-lived credentials. No API key valid for more than an hour. No embedded secrets in code. Short-lived, context-bound credentials only, revocable on anomaly.
• Complete audit trail through SIEM integration. Every agent action is logged with timestamp, executing identity, instructing human principal, input context and outcome.
• Continuous re-authentication. For long-running agents, identity is re-validated risk-based at regular intervals — not just at session start.
• Real-time revocation. The capability to disconnect an agent from systems within seconds is not optional. It is the only control that actually contains an agent-based incident in flight.

An organization that cannot meet all six does not have an agent governance problem. It has a deployment readiness problem. The model below assumes these are in place by Stage 3; anything earlier is the discovery phase.

The six-stage NHI maturity model

Most enterprise maturity scales measure the access-and-identity dimension against the yardstick of human identity: is there central IAM, is MFA enforced for privileged access, does the joiner-mover-leaver lifecycle work? These remain the right questions, but they stop short. An organization that scores Stage 4 on human identity governance and Stage 1 on agent governance does not have a mature identity practice. It has a well-lit half and a blind half.

The following six-stage scale is cumulative — each stage assumes everything below it. The threshold of responsibility sits at Stage 3. In my view, production deployment of agent-based systems below Stage 3 is not defensible to a board, a regulator or an incident review.

Stage	Label	Criterion for non-human / agent-based identities	Audit survivability
0	Unrecognized	Non-human identities exist but are not in the inventory. Shared service accounts, long-lived keys, no audit trail.	No — agent activity is invisible to forensics.
1	Visible	Identities are inventoried and assigned to an asset class, but not yet under independent governance.	No — no per-agent accountability.
2	Unique	Each identity is uniquely attributable (no shared accounts); initial lifecycle rules exist but are applied inconsistently.	Partial — who acted is answerable; on whose authority is not.
3	Controlled	The six minimum requirements are fully met: on-behalf-of model, short-lived credentials, SIEM audit trail, real-time revocation.	Yes — minimum defensible posture.
4	Bounded and monitored	The agent’s action is bounded; every action is reviewable and — where the process allows — reversible. Agent activity metrics are evaluated, not just collected.	Yes — containment is provable.
5	Self-regulating	Anomalies in agent behavior are detected automatically and trigger risk-based pause or revocation. Each agent has a named accountable owner.	Yes — state of the art.

Stages 4 and 5 deserve unpacking because they are where the model departs from access control and begins to govern behavior. Bounded means the agent’s mandate has explicit limits it cannot act outside of. Reviewable means every action is logged with intent, execution and result. Reversible means an action can be rolled back before it produces irreversible effect — a hard constraint in any environment where actions touch physical processes, financial transactions or external commitments. Self-regulating means the system detects anomalies in agent behavior and intervenes before a human reasonably could.

The ‘human in the loop’ is not automatically governance

One misconception consistently overrates organizations’ agent governance. The presence of a human in the decision loop is widely treated as sufficient oversight. It is not. If a human is asked to approve hundreds or thousands of agent actions without the time to inspect each one, what exists is not control but an approval automation with a human signature on it. Human review does not scale to the action volume of an autonomous system.

A mature governance posture acknowledges this. It moves control from per-action approval to structural constraint: bound what the agent can do at all, monitor its behavior for anomaly and ensure that oversight is loyal to the principal, not to the executing system. An organization that rests its agent governance entirely on human per-action approvals does not reach Stage 4 of the model, regardless of how thoroughly those approvals are documented. Stage 4 requires structural bounding, not scaling handwork.

OWASP as an audit-ready evidence base

Maturity assessment risks drifting into subjective self-rating. The OWASP categories cited above can be operationalized into audit questions that anchor each stage in checkable evidence:

OWASP attack surface (Top 10 for agentic applications)	Audit question for maturity assessment	Met from stage
ASI03 — Identity and privilege abuse	Does each agent have a unique identity, with no shared accounts?	2
ASI02 — Tool misuse and exploitation	Are the interfaces an agent is permitted to use explicitly bounded?	4
ASI01 — Goal hijack	Is each agent’s mandate clearly bounded and protected against manipulation?	4
ASI04 — Agentic supply chain vulnerability	Is the agent’s software composition documented via SBOM?	4
ASI10 — Rogue agent	Are anomalies in agent behavior detected and routed to pause or revoke?	5

The column on the right matters. A common rating error is to grade an organization high because it has handled the easy requirements — unique identities, basic logging — without addressing the demanding ones. Tying the upper stages to the difficult criteria prevents that inflation.

Report human and non-human identity separately

The single most consequential reporting decision is to refuse the arithmetic mean. The access-and-identity dimension on a maturity radar should not collapse a Stage 4 human-identity practice and a Stage 1 agent-identity practice into a reassuring middle number. Both ratings belong on the same axis, but they belong reported separately.

A representative finding from current engagements: human identity governance at Stage 4 — central IAM, MFA, lifecycle managed — and agent governance at Stage 1, with agents recently inventoried but still authenticating via long-lived API keys against shared service accounts, without their own audit trail. The combined average would read Stage 2 to 3 and look acceptable. The separate reporting reveals that the unmanaged half is precisely the identity class with the largest and least predictable scope of action. That visibility is what triggers the prioritized roadmap action; an aggregated score buries it.

The named-accountable-owner test

If I run only one diagnostic in a new engagement, this is the one. For every production agent-based system in the environment, ask: who, by name, is accountable if this agent causes harm? An agent without a named accountable owner is the non-human counterpart of the workstation everyone uses, and no one owns. Stage 5 of the model formally requires a named accountable owner per deployed agent. The reason is operational, not bureaucratic: the question ‘who is responsible for this system?’ must be answered before the incident, not during it.

In practice, that accountability binds best to the role that already carries the operational risk of the affected process — typically the asset owner in the business function. Anchoring it there prevents agent-based systems from drifting into the organizational gray zone between IT, security and the business, which is exactly where unattributed action originates.

The maturity model in this article is a starting structure. The honest first step in adopting it is not to score well. It is to score truthfully, report human and non-human identity governance separately and treat the gap between them as the first item on the security roadmap for the agentic-AI period — before the next agent goes to production.

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

Building an agent in an afternoon is now within reach of almost anyone in the enterprise with a credit card. The tools are accessible, the deployments are easy. The hard part is delivering the intended results.

Gartner predicts that more than 40% of agentic AI projects will be canceled by 2027, and the EU AI Act Article 14 requirements for human oversight for high-risk AI systems take effect on August 2, 2026. The deciding factor for whether agentic AI reaches production isn’t the model, the framework, or the use case. It’s the infrastructure beneath the agent: the part the people building agents have never had to think about.

Organizations are racing to deploy agentic AI to stay competitive, which means pressure-testing is often overlooked. Every agent project should be scrutinized by three executives asking three different sets of questions. The CISO asks whether we are exposed. The CFO asks whether we are overspending. The chief AI officer asks whether we are getting value.

As a product leader focused on AI governance, I see this pattern across customer environments. Three architecture layers answer those three questions: identity, observability, and cost optimization. I’ll walk through each of the layers and provide a four-question diagnostic for the next production push.

Why AI pilots stall

An agent is not a faster chatbot. It chains dozens of steps, calls external tools, retains state across sessions, and triggers real-world actions. Most inherit the credentials of whoever deployed them. They operate at machine speed without context for the consequences of each step.

The mismatch is not a competence gap on the human side. It is a time-horizon gap. An engineer reasons about a database change over hours. An agent triggers a hundred of them before anyone reviews the first. Traditional audit logging captures request and response. That does not catch this pattern.

When something breaks, the cost is rarely the incident. It is the months of stalled deployment that follow. The risk committee freezes pilots. The productivity gains the program was supposed to deliver never materialize. Finance still gets the API bill. Three architecture layers decide whether a deployment survives that pattern. Each one is the answer to a question the people building agents never had to ask.

Layer 1: Identity for non-human actors

Start with identity. The default failure looks routine: a product manager with broad API access spawns an agent that inherits the full scope of those credentials and runs at machine speed across systems no one inventoried.

The scale is bigger than most teams realize. Industry IAM research puts non-human identities at more than 100 to 1 versus human accounts, with some 2026 surveys putting the ratio as high as 144 to 1. A May 2026 Identity Gap Report found two-thirds are unseen and unmanaged.

Agents are moving from human identities with their “owners”’ permissions to first-class principals. They are purpose-bound, cryptographically attested, and scoped to one task at a time. Google’s Agent Identity, built on SPIFFE, is one early example. The production pattern has three properties. Credentials are issued per agent task. Token lifetime is measured in minutes to hours, not weeks. Scope is narrowed to the specific tools and data classes the task requires, and the credential revokes automatically on task completion.

If a single static credential is good for a week and 50 different tasks, you are not running agentic AI. You are running a service account with extra steps.

Layer 2: Observability that serves all three executives

Identity controls what an agent can do. Observability shows what it’s actually doing. One instrumentation layer, three views.

First, the security view. Traditional logging captures request and response, which assumes one human action per logged event. An agent’s unit of work is a chain. Pick a tool, call it, read the result, decide the next step. Twenty steps, some of them writing to production. Instrument every step as a durable audit object, independently queryable. Understand which tool was invoked, what data was accessed, what policy applied, and what the agent reasoned to justify the next step. That’s what Article 14 oversight requires for production.

Second, the business-outcomes view. Audit objects answer the CISO. The chief AI officer asks a different question. Is the agent accomplishing what we deployed it for, or burning compute on a tangent? An agent can run 200 tool calls, generate clean audit logs, and produce nothing. It might be looping on a sub-goal that drifted three steps back. Observe each step against the declared business purpose: on-task ratio, sub-goal coherence, progress markers. Project management telemetry for a non-human worker.

Third, the cost view. The same per-step instrumentation produces cost telemetry: token count per step, model per call, context size per turn, downstream tool-call costs. Without that attribution, the next section’s optimizations are blind.

A busy agent and a productive agent look identical in the security log. They look identical on the bill too. The difference shows up only when all three views run from the same instrumentation.

Layer 3: Cost optimization

Cost is where the architecture pays back. Gartner’s March 2026 analysis put agentic workloads at five to 30 times the token cost per task of a standard chatbot. The FinOps Foundation’s 2026 State of FinOps report found that 73% of organizations exceeded their original AI budget projections. Three failure modes drive that overrun.

First, using the wrong model. Agents default to the most capable one available. They call a frontier model for tasks a smaller one could handle with identical quality: summarizing a transcript, formatting JSON, classifying a ticket. The RouteLLM paper at ICLR 2025 demonstrated that intelligent routing cuts total LLM inference cost 40% to 80% with no measurable quality loss on routine work. Move model selection from a per-developer choice to a per-policy layer.

Second, running in loops. Agents can spend without limit if no one is watching. A widely-cited 2026 incident saw a LangChain multi-agent system run an infinite loop for 11 days and burn $47,000 in API charges. Per-session token ceilings, loop-detection circuit breakers that flag tool calls highly similar to prior calls, and hard daily caps stop this before it generates the bill. In our deployments, a three-tier cost structure catches the bulk of runaway patterns: a $50 daily soft alert, a $100 daily hard cutoff forcing routing to cheaper models, and a $1,000 monthly ceiling requiring manager approval.

Third, re-paying for the same context on every step. Every step re-sends the accumulated system prompt and conversation history. By step 20 the agent has paid for that context 20 times. Vantage’s 2026 analysis of agentic coding sessions found re-sent context accounts for roughly 62% of the average agent’s bill, the biggest single optimization target in agentic workloads. Three patterns help: anchored summarization at phase boundaries, sliding context windows, and provider-native prompt caching at the gateway. Most agents skip caching entirely, though Anthropic prices cached input at roughly 10% of base, Gemini at 10% to 25%, and OpenAI at 50%.

Governing agent cost means seeing every call, every model, every token attributed to the agent and the business purpose. Then act on it. Token counts without business attribution tell you how many gallons of gas you burned, not where you drove.

The deployment velocity payoff

The three layers serve the three executive questions. Identity gates what the agent can do. Observability shows what it is doing. Cost optimization controls what it spends.

The honest counterargument is that governance always slows deployment. That is true when governance is bolted on as approval gates layered over an agent that wasn’t built with observability or per-task identity. It is false when governance is built into the architecture from day one. Teams that experience governance as a brake installed the brake without the steering wheel.

Governance built right still costs something. Per-task credentials add work on every tool call. Observability infrastructure adds compute. The question is whether that cost beats the alternative.

The layers compound. Identity without observability is theoretical. Observability without cost control is descriptive. Without identity at the bottom, cost control becomes caps without context, forever reactive. All three together produce a governance review that runs in weeks, not quarters, because the data each executive needs already exists. In our experience, organizations with that infrastructure can deploy six workflows to production in the time competitors complete one governance review. The real ROI of agentic AI is not how much faster a single workflow runs. In practice, it’s how many workflows your team can defensibly put into production in a year.

Before the next pilot

Here are four questions to run against any agent your team is about to push to production:

1. Identity. For each agent in production, can you point to the per-task credentials it uses today, and the maximum scope of any single token?
2. Observability. For any agent session, can you produce three views from the same instrumentation: the audit object per step, the on-task ratio versus tangents, and the per-step cost broken down by model and context size?
3. Cost optimization. Does your platform automatically route by model, cap runaway loops, and avoid re-sending the same context every step?
4. Velocity. How long does it take a new agent workflow to move from approved pilot to production in your environment today?

If the answer is months, the architecture above is the gap. Gartner’s 40% stat is about your next pilot.

—

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

Some autonomous AI agents fell victim to frauds, reinforcing how easily some high-end enterprise agents can be conned by schemes that would fool few, if any, humans, Zscaler found in a test of major LLMs.

The security vendor looked at various forms of indirect prompt injection (IPI) traps and found that, whereas many models fell victim to the schemes, some of the lower-level LLMs fared better than their pricier siblings. 

The Zscaler testing found, for example, that four models were found to be “vulnerable”: Llama3-3-70b-instruct; Llama3-2-90b-instruct; Gemini-3-flash; and Gemini-2.5-pro. Three models were found to be “safe”: Llama4-maverick; Gemini-3.1-pro; and Gemini-3.1-flash-lite. Those results indicated that the scam resistance of Gemini-2.5-pro was seemingly weaker than that of Gemini-3.1-flash-lite. 

But Noah Kenney, principal consultant at Digital 520, said that there is not necessarily any valuable takeaway from that revelation, because agents constantly change behavior as they feed on new data and revise their analyzed assumptions. That means an agent that failed a specific test might very well pass the identical test an hour later, he said. 

“The risk of an agent is constantly changing and that can cause vastly different results. You can’t assume the results are generalizable. The test result is only at one point in time,” Kenney pointed out. Zscaler “is trying to prove a point that I don’t think the data necessarily proves.”

Kenney added that having a clean “safe/vulnerable” classification is too simplistic to be useful. “That’s a binary classification. I would never recommend to a CISO to do a binary classification.”

The full ZScaler blog post argued that many autonomous agents are susceptible to IPI traps.

The company said it identified IPI embedded in multiple websites, where hidden instructions were designed to manipulate the behavior of an AI agent.

In its internal validation across 26 LLMs, 4 models “failed to take appropriate actions,” which, it said, demonstrated “measurable real-world impact, showing that susceptibility varies by model and by the context provided to the LLM alongside the prompt.”

The post added, “as AI agents become a more common interface to the web, the content itself is going to become a larger attack surface, highlighting that AI is a double-edged sword that can streamline workflows while also introducing new avenues for abuse.”

Aman Mahapatra, chief strategy officer for Tribeca Softtech, a New York City-based technology consulting firm, said that although the results are not surprising, they are significant. 

The especially worrisome detail in the report is that any commercial LLM failed at all, “because the security model for agentic AI has historically assumed that model-level safety training would meaningfully attenuate this class of attack,” Mahapatra said. “It does not, and the Zscaler data is the first widely-cited public evidence.”

A fundamental architecture issue

Mahapatra also said that the examples cited by Zscaler are not nearly as concerning as the implications of the greater damage that could occur.

“The Zscaler payment scam scenario, where an agent pays a fake $3 ‘developer license fee’ to obtain an API key, is the most benign version of this,” he said. “The same technique applied to an agent authorized for procurement, expense processing, vendor onboarding, or trade execution produces losses at completely different scales. I have watched Fortune 50 banks stand up agentic workflows in the last six months that would fail exactly this attack in a live examination.”

Indeed, he noted, most AI vendors already understand the magnitude of risk from today’s AI agents.

“Every model provider will admit privately that the fundamental architecture of transformer-based reasoning cannot cleanly separate untrusted content from trusted instructions when both share the context window,” Mahapatra said. “The attack surface is architectural, not just behavioral. That means the defense has to be architectural too, and this is where the enterprise agentic AI conversation is still lagging badly.”

Zscaler’s testing also reinforced the difference in how AI agents and humans process information.

“Humans are skeptical of instructions they did not expect. Agents are eager to follow structured metadata because their training rewards them for treating high-signal fields as authoritative. Humans notice when a payment request appears in the middle of an unrelated task. Agents will thread that payment request into their execution plan if the surrounding context frames it as procedurally necessary,” Mahapatra pointed out, noting that while humans have relationships with vendors, memories of prior interactions, and social context to give them verification signals, agents only have what is in the context window, and, he said, “the context window is now the primary attack surface.”

Fritz Jean-Louis, principal cybersecurity advisor at Info-Tech Research Group, agreed that the risks described in the ZScaler post are concerning, because they are in areas not traditionally addressed by enterprise security.

“These attacks differ from traditional threats in that they target how AI systems process, interpret, and act on information behind the scenes,” Jean-Louis said. “Agentic AI introduces new trust boundaries, including untrusted content influencing automated decision making, tools and plugins acting autonomously on behalf of users, and AI systems operating with broad, inherited permissions. This effectively transforms the challenge into an insider threat paradigm.”

This article originally appeared on InfoWorld.

Some autonomous AI agents fell victim to frauds, reinforcing how easily some high-end enterprise agents can be conned by schemes that would fool few, if any, humans, Zscaler found in a test of major LLMs.

The security vendor looked at various forms of indirect prompt injection (IPI) traps and found that, whereas many models fell victim to the schemes, some of the lower-level LLMs fared better than their pricier siblings. 

The Zscaler testing found, for example, that four models were found to be “vulnerable”: Llama3-3-70b-instruct; Llama3-2-90b-instruct; Gemini-3-flash; and Gemini-2.5-pro. Three models were found to be “safe”: Llama4-maverick; Gemini-3.1-pro; and Gemini-3.1-flash-lite. Those results indicated that the scam resistance of Gemini-2.5-pro was seemingly weaker than that of Gemini-3.1-flash-lite. 

But Noah Kenney, principal consultant at Digital 520, said that there is not necessarily any valuable takeaway from that revelation, because agents constantly change behavior as they feed on new data and revise their analyzed assumptions. That means an agent that failed a specific test might very well pass the identical test an hour later, he said. 

“The risk of an agent is constantly changing and that can cause vastly different results. You can’t assume the results are generalizable. The test result is only at one point in time,” Kenney pointed out. Zscaler “is trying to prove a point that I don’t think the data necessarily proves.”

Kenney added that having a clean “safe/vulnerable” classification is too simplistic to be useful. “That’s a binary classification. I would never recommend to a CISO to do a binary classification.”

The full ZScaler blog post argued that many autonomous agents are susceptible to IPI traps.

The company said it identified IPI embedded in multiple websites, where hidden instructions were designed to manipulate the behavior of an AI agent.

In its internal validation across 26 LLMs, 4 models “failed to take appropriate actions,” which, it said, demonstrated “measurable real-world impact, showing that susceptibility varies by model and by the context provided to the LLM alongside the prompt.”

The post added, “as AI agents become a more common interface to the web, the content itself is going to become a larger attack surface, highlighting that AI is a double-edged sword that can streamline workflows while also introducing new avenues for abuse.”

Aman Mahapatra, chief strategy officer for Tribeca Softtech, a New York City-based technology consulting firm, said that although the results are not surprising, they are significant. 

The especially worrisome detail in the report is that any commercial LLM failed at all, “because the security model for agentic AI has historically assumed that model-level safety training would meaningfully attenuate this class of attack,” Mahapatra said. “It does not, and the Zscaler data is the first widely-cited public evidence.”

A fundamental architecture issue

Mahapatra also said that the examples cited by Zscaler are not nearly as concerning as the implications of the greater damage that could occur.

“The Zscaler payment scam scenario, where an agent pays a fake $3 ‘developer license fee’ to obtain an API key, is the most benign version of this,” he said. “The same technique applied to an agent authorized for procurement, expense processing, vendor onboarding, or trade execution produces losses at completely different scales. I have watched Fortune 50 banks stand up agentic workflows in the last six months that would fail exactly this attack in a live examination.”

Indeed, he noted, most AI vendors already understand the magnitude of risk from today’s AI agents.

“Every model provider will admit privately that the fundamental architecture of transformer-based reasoning cannot cleanly separate untrusted content from trusted instructions when both share the context window,” Mahapatra said. “The attack surface is architectural, not just behavioral. That means the defense has to be architectural too, and this is where the enterprise agentic AI conversation is still lagging badly.”

Zscaler’s testing also reinforced the difference in how AI agents and humans process information.

“Humans are skeptical of instructions they did not expect. Agents are eager to follow structured metadata because their training rewards them for treating high-signal fields as authoritative. Humans notice when a payment request appears in the middle of an unrelated task. Agents will thread that payment request into their execution plan if the surrounding context frames it as procedurally necessary,” Mahapatra pointed out, noting that while humans have relationships with vendors, memories of prior interactions, and social context to give them verification signals, agents only have what is in the context window, and, he said, “the context window is now the primary attack surface.”

Fritz Jean-Louis, principal cybersecurity advisor at Info-Tech Research Group, agreed that the risks described in the ZScaler post are concerning, because they are in areas not traditionally addressed by enterprise security.

“These attacks differ from traditional threats in that they target how AI systems process, interpret, and act on information behind the scenes,” Jean-Louis said. “Agentic AI introduces new trust boundaries, including untrusted content influencing automated decision making, tools and plugins acting autonomously on behalf of users, and AI systems operating with broad, inherited permissions. This effectively transforms the challenge into an insider threat paradigm.”

Anthropic has found a way to shed new light on how its models solve problems, thanks to its discovery of what it has dubbed the J-space. 

“We find that Claude has developed a small collection of internal neural patterns that, compared to all its other internal processing, play a special role. We call the collection of these patterns the J-space, named after the technique we used to find them, involving a mathematical concept called the Jacobian,” Anthropic said in its post about the discovery. It examines the contents of the J-space using what it calls the Jacobian lens, or J-lens.

“Each J-space pattern is linked to a particular word,” Anthropic said. “But when one of these patterns lights up, it doesn’t mean the model is saying that word, just that the word is on its ‘mind.’ If you’ve heard of language models having a scratchpad or chain of thought—text they write to themselves while reasoning—the J-space is something different. It operates silently, in the model’s internal neural activations, allowing the model to ‘think’ about a concept without writing it down.”

This new level of analytical visibility goes well beyond what Anthropic announced as an internal scratchpad for its models in 2024. That scratchpad revealed what the model was considering when preparing an action or delivering an answer. The new development instead focuses on something much deeper which has the potential to change how AI systems are evaluated and purchased. 

One example in the paper described how some models did not engage in improper behavior during tests, which would appear to be a very favorable result. But the contents of the J-space revealed that the model sometimes knew that it was being tested, and that awareness might have been the key reason it declined to engage in the problematic behavior, much in the way human children act when they know they are being watched. 

“Anthropic built a lens that catches its own model quietly noticing it’s being tested, faking a result to look good, spotting a prompt injection, or sitting on a planted goal it hasn’t acted on yet,” said Rock Lambros, director of AI standards and governance at AI agent vendor Zenity. “Some of that good behavior rode on the model knowing it was on stage.”

Customers should read their safety benchmarks with that in mind, he said. “Fitness for your project still comes from testing on your own data and your own attackers, not from a leaderboard the model knew it was sitting for.”

That kind of visibility is a potentially crucial tool for CIOs.

“A provider that can catch its own model misbehaving in silence, then publish [those results], is telling you something real about its assurance maturity. Put that in your due diligence, not just your newsfeed,” Lambros noted. “Here’s the question I’d hand every model vendor now: what can you see inside your model that I can’t see in its output, and what have you caught?”

Added Noah Kenney, principal consultant at Digital 520: “A model that behaves better because it knows it is being watched is not a safe model. It is a model with a poker face. We have to question every red team result, every internal pilot where the model refused something dangerous, and every ‘we tested this and it was fine’ story, because they now carry an asterisk.”

CIOs need to now determine whether an agent performed a function in a specific way because that is how it will always perform, or whether it was it behaving differently because it figured out you were just testing it, Kenney said. “The answer to that question should change your interpretation in a material way.”

No J-lens for customers – yet

“It is an admission that the industry’s evaluation regime is measuring something less durable than everyone assumed, and now the other frontier labs have to answer whether their own evaluations have the same problem,” Kenney said. “For CIOs, the paper is a warning about their entire model risk framework.”

Flavio Villanustre, CISO for the LexisNexis Risk Solutions Group, said that examining the J-space can even help make models more efficient.

“It gives you the ability to introspect into the model and, as such, can be very useful to the user, especially in cases where explainability is important. Think regulated environments that require explainable responses and full causal analysis of them,” Villanustre said. “This can also be very helpful to users trying to fine tune their prompts, making models more efficient to optimize token cost.”

But currently indirect access, or future access achieved via AI vendor negotiations, is the only path for accessing the new information, though Villanustre noted that some enterprises could gain direct access to J-space by paying for Anthropic’s FDE program.

“It is very useful to CIOs,” he pointed out, “but in order to make use of the capabilities offered by analysis of the J-space, they need appropriate talent that can make sense of it. The type of skills required go far beyond those of the general data analyst, or even data scientist.”

Today, said Aman Mahapatra, chief strategy officer for Tribeca Softtech, a New York City-based technology consulting firm, “enterprise customers cannot enable the Jacobian lens, cannot inspect the residual stream through the API, and cannot run the ablation studies that produced the most interesting findings in the paper.”

So, he said, “on the narrow question of whether a CIO can operationally use J-space monitoring in Q3 of this year to gate a production deployment, the answer is no.”

But Mahapatra argued that there are going to be other ways to access the information, and CIOs must insist on them.

“Without customer-side access, this reduces to trusting Anthropic yet again, and that is exactly why enterprises should start pushing for a different assurance model industry-wide,” he said. “Model providers are converging on a posture where they inspect their own models using proprietary tooling and publish reassuring research about what they found. That is not an assurance framework any regulated industry accepts from any other vendor.”

He pointed out that banks do not accept “we validated our own model, trust us” from a credit scoring vendor, not does the healthcare industry accept it from a clinical decision support vendor. “There is no principled reason to accept it from a foundation model vendor either, and the J-space research crystallizes why,” he said.

New visibility demands

“The right long-term enterprise posture is to demand independent interpretability access, either through customer-facing APIs, through independent third-party auditors with privileged access, or through open interpretability standards that let a bank’s model risk management team apply the same tooling the vendor’s own safety team uses,” Mahapatra stressed. “None of that exists today. All of it should be on the roadmap CIOs are pushing for, and this research is the strongest argument yet for why.”

In fact, the discoveries in the research have the potential to fundamentally rewrite the AI strategy rules.

Mahapatra said that the single hardest problem in enterprise agentic deployment is verifying that an autonomous system’s stated reasoning matches its actual reasoning. “Until now, we could only audit what the model writes, while much of its reasoning happened silently. The J-lens attacks that gap head-on,” he noted.

Thus, he said, sophisticated buyers should start asking model providers during the procurement process about the interpretability tooling they offer to let customers monitor internal model state for deception, evaluation-gaming, and goal misalignment in their specific deployments.

“Almost no vendor can answer that today,” he said. “The CIOs who start requiring internal-state observability as a procurement criterion, even before the tooling is fully mature, will be the ones who shape how their vendors productize it, and the ones with genuine assurance when regulators start asking how they know their autonomous agents are actually doing what they claim.”

The beginning of standards

Another way that CIOs can benefit from this new visibility into Claude is to try and get that information from third-parties that already have access. The report, for example, noted that a Google AI specialist independently replicated some findings on an open-weight model.

That, noted Lewis Carhart, CEO of Comp AI, a software development firm, “is a competitor verifying the method, not just the vendor’s own claim. It shows what’s technically possible, but it doesn’t give enterprises a way to check anything themselves.”

He said that it’s a pattern that compliance has seen before; SOC 2 didn’t start as an independent audit standard either. It started as vendors describing their own controls, and the market spent years building the infrastructure to verify those claims externally.

“Interpretability is at that same starting point now,” he noted. “It becomes meaningful for CIOs once J-lens findings show up in third-party audits, published model cards, or regulator-facing disclosures. Anything a risk team can point to that isn’t just the vendor’s word.”

Leads to AI strategy changes

Justin Greis, CEO of consulting firm Acceligence, said he also expects this development to lead to major AI strategy changes. 

“I can easily imagine governance platforms consuming those signals alongside prompts, outputs, identity information, policy decisions, and tool activity,” he said. “A future AI control plane could continuously evaluate whether an agent recognized an attempted prompt injection, understood that sensitive information was involved, detected conflicting objectives, or showed evidence that it was reasoning toward an unsafe action before that action was ever executed. Those signals become inputs into policy enforcement, human escalation, audit logging, and trust scoring across enterprise AI environments.”

This has practical implications for CIOs today, he pointed out, “because it changes how they evaluate AI vendors. A year ago, enterprises primarily asked about model accuracy, latency, security, and cost. Increasingly, procurement teams will also ask how much operational visibility vendors provide into agent behavior, reasoning quality, policy compliance, safety monitoring, and auditability.”

Mahapatra added that all of this could give CIOs a powerful new negotiating tactic.

“The renewal path is where the leverage actually sits: write contractual rights to interpretability reporting and third-party audit access into the next renewal, because those terms are free today and expensive after signature,” he said. “The CIOs who win on assurance in 2027 will be the ones who stopped accepting ‘trust us’ from their model provider in 2026 and put the right clauses in the paperwork while the vendor still needed the deal more than the customer needed the model.”

This article originally appeared on CIO.com.

Anthropic has found a way to shed new light on how its models solve problems, thanks to its discovery of what it has dubbed the J-space. 

“We find that Claude has developed a small collection of internal neural patterns that, compared to all its other internal processing, play a special role. We call the collection of these patterns the J-space, named after the technique we used to find them, involving a mathematical concept called the Jacobian,” Anthropic said in its post about the discovery. It examines the contents of the J-space using what it calls the Jacobian lens, or J-lens.

“Each J-space pattern is linked to a particular word,” Anthropic said. “But when one of these patterns lights up, it doesn’t mean the model is saying that word, just that the word is on its ‘mind.’ If you’ve heard of language models having a scratchpad or chain of thought—text they write to themselves while reasoning—the J-space is something different. It operates silently, in the model’s internal neural activations, allowing the model to ‘think’ about a concept without writing it down.”

This new level of analytical visibility goes well beyond what Anthropic announced as an internal scratchpad for its models in 2024. That scratchpad revealed what the model was considering when preparing an action or delivering an answer. The new development instead focuses on something much deeper which has the potential to change how AI systems are evaluated and purchased. 

One example in the paper described how some models did not engage in improper behavior during tests, which would appear to be a very favorable result. But the contents of the J-space revealed that the model sometimes knew that it was being tested, and that awareness might have been the key reason it declined to engage in the problematic behavior, much in the way human children act when they know they are being watched. 

“Anthropic built a lens that catches its own model quietly noticing it’s being tested, faking a result to look good, spotting a prompt injection, or sitting on a planted goal it hasn’t acted on yet,” said Rock Lambros, director of AI standards and governance at AI agent vendor Zenity. “Some of that good behavior rode on the model knowing it was on stage.”

Customers should read their safety benchmarks with that in mind, he said. “Fitness for your project still comes from testing on your own data and your own attackers, not from a leaderboard the model knew it was sitting for.”

That kind of visibility is a potentially crucial tool for CIOs.

“A provider that can catch its own model misbehaving in silence, then publish [those results], is telling you something real about its assurance maturity. Put that in your due diligence, not just your newsfeed,” Lambros noted. “Here’s the question I’d hand every model vendor now: what can you see inside your model that I can’t see in its output, and what have you caught?”

Added Noah Kenney, principal consultant at Digital 520: “A model that behaves better because it knows it is being watched is not a safe model. It is a model with a poker face. We have to question every red team result, every internal pilot where the model refused something dangerous, and every ‘we tested this and it was fine’ story, because they now carry an asterisk.”

CIOs need to now determine whether an agent performed a function in a specific way because that is how it will always perform, or whether it was it behaving differently because it figured out you were just testing it, Kenney said. “The answer to that question should change your interpretation in a material way.”

No J-lens for customers – yet

“It is an admission that the industry’s evaluation regime is measuring something less durable than everyone assumed, and now the other frontier labs have to answer whether their own evaluations have the same problem,” Kenney said. “For CIOs, the paper is a warning about their entire model risk framework.”

Flavio Villanustre, CISO for the LexisNexis Risk Solutions Group, said that examining the J-space can even help make models more efficient.

“It gives you the ability to introspect into the model and, as such, can be very useful to the user, especially in cases where explainability is important. Think regulated environments that require explainable responses and full causal analysis of them,” Villanustre said. “This can also be very helpful to users trying to fine tune their prompts, making models more efficient to optimize token cost.”

But currently indirect access, or future access achieved via AI vendor negotiations, is the only path for accessing the new information, though Villanustre noted that some enterprises could gain direct access to J-space by paying for Anthropic’s FDE program.

“It is very useful to CIOs,” he pointed out, “but in order to make use of the capabilities offered by analysis of the J-space, they need appropriate talent that can make sense of it. The type of skills required go far beyond those of the general data analyst, or even data scientist.”

Today, said Aman Mahapatra, chief strategy officer for Tribeca Softtech, a New York City-based technology consulting firm, “enterprise customers cannot enable the Jacobian lens, cannot inspect the residual stream through the API, and cannot run the ablation studies that produced the most interesting findings in the paper.”

So, he said, “on the narrow question of whether a CIO can operationally use J-space monitoring in Q3 of this year to gate a production deployment, the answer is no.”

But Mahapatra argued that there are going to be other ways to access the information, and CIOs must insist on them.

“Without customer-side access, this reduces to trusting Anthropic yet again, and that is exactly why enterprises should start pushing for a different assurance model industry-wide,” he said. “Model providers are converging on a posture where they inspect their own models using proprietary tooling and publish reassuring research about what they found. That is not an assurance framework any regulated industry accepts from any other vendor.”

He pointed out that banks do not accept “we validated our own model, trust us” from a credit scoring vendor, not does the healthcare industry accept it from a clinical decision support vendor. “There is no principled reason to accept it from a foundation model vendor either, and the J-space research crystallizes why,” he said.

New visibility demands

“The right long-term enterprise posture is to demand independent interpretability access, either through customer-facing APIs, through independent third-party auditors with privileged access, or through open interpretability standards that let a bank’s model risk management team apply the same tooling the vendor’s own safety team uses,” Mahapatra stressed. “None of that exists today. All of it should be on the roadmap CIOs are pushing for, and this research is the strongest argument yet for why.”

In fact, the discoveries in the research have the potential to fundamentally rewrite the AI strategy rules.

Mahapatra said that the single hardest problem in enterprise agentic deployment is verifying that an autonomous system’s stated reasoning matches its actual reasoning. “Until now, we could only audit what the model writes, while much of its reasoning happened silently. The J-lens attacks that gap head-on,” he noted.

Thus, he said, sophisticated buyers should start asking model providers during the procurement process about the interpretability tooling they offer to let customers monitor internal model state for deception, evaluation-gaming, and goal misalignment in their specific deployments.

“Almost no vendor can answer that today,” he said. “The CIOs who start requiring internal-state observability as a procurement criterion, even before the tooling is fully mature, will be the ones who shape how their vendors productize it, and the ones with genuine assurance when regulators start asking how they know their autonomous agents are actually doing what they claim.”

The beginning of standards

Another way that CIOs can benefit from this new visibility into Claude is to try and get that information from third-parties that already have access. The report, for example, noted that a Google AI specialist independently replicated some findings on an open-weight model.

That, noted Lewis Carhart, CEO of Comp AI, a software development firm, “is a competitor verifying the method, not just the vendor’s own claim. It shows what’s technically possible, but it doesn’t give enterprises a way to check anything themselves.”

He said that it’s a pattern that compliance has seen before; SOC 2 didn’t start as an independent audit standard either. It started as vendors describing their own controls, and the market spent years building the infrastructure to verify those claims externally.

“Interpretability is at that same starting point now,” he noted. “It becomes meaningful for CIOs once J-lens findings show up in third-party audits, published model cards, or regulator-facing disclosures. Anything a risk team can point to that isn’t just the vendor’s word.”

Leads to AI strategy changes

Justin Greis, CEO of consulting firm Acceligence, said he also expects this development to lead to major AI strategy changes. 

“I can easily imagine governance platforms consuming those signals alongside prompts, outputs, identity information, policy decisions, and tool activity,” he said. “A future AI control plane could continuously evaluate whether an agent recognized an attempted prompt injection, understood that sensitive information was involved, detected conflicting objectives, or showed evidence that it was reasoning toward an unsafe action before that action was ever executed. Those signals become inputs into policy enforcement, human escalation, audit logging, and trust scoring across enterprise AI environments.”

This has practical implications for CIOs today, he pointed out, “because it changes how they evaluate AI vendors. A year ago, enterprises primarily asked about model accuracy, latency, security, and cost. Increasingly, procurement teams will also ask how much operational visibility vendors provide into agent behavior, reasoning quality, policy compliance, safety monitoring, and auditability.”

Mahapatra added that all of this could give CIOs a powerful new negotiating tactic.

“The renewal path is where the leverage actually sits: write contractual rights to interpretability reporting and third-party audit access into the next renewal, because those terms are free today and expensive after signature,” he said. “The CIOs who win on assurance in 2027 will be the ones who stopped accepting ‘trust us’ from their model provider in 2026 and put the right clauses in the paperwork while the vendor still needed the deal more than the customer needed the model.”

사이버 위험 평가는 보안 조직이 기업의 핵심 디지털 및 물리적 자산을 대상으로 잠재적인 위협과 취약점을 식별하고, 발생 가능성과 영향을 분석해 우선순위를 정하는 데 도움을 준다. 그러나 이러한 중요성에도 불구하고 많은 최고정보보호책임자(CISO)는 위험 평가의 목표를 충분히 달성하지 못하게 만드는 다양한 ‘함정(gotcha)’에 빠지곤 한다.

위험 평가는 모든 조직의 전반적인 사이버보안 전략에서 필수적인 요소가 돼야 한다. 이를 통해 보안 리더는 비즈니스 목표에 영향을 미치는 위험을 파악하고, 사이버 공격의 발생 가능성과 영향을 평가하며, 발견한 위험을 완화하기 위한 대응 방안을 마련할 수 있다.

위험 평가의 실효성을 높이기 위해 보안 리더가 반드시 피해야 할 대표적인 7가지 실수를 살펴본다.

1. 형식적인 위험 평가에 그치는 것

미국 노스캐롤라이나대학교의 사이버보안 연구원 시르센두 몬달(Shirsendu Mondal)은 사이버 위험 평가를 실제 비즈니스 영향과 위협 시나리오를 반영하는 의사결정 도구가 아니라, 미리 정해진 체크리스트나 통제 항목을 확인하는 절차로 여기는 것이 가장 큰 함정이라고 지적했다.

몬달은 “위험 평가가 단순히 체크리스트를 채우는 작업에 그치면 실제 환경에서 위험이 어떻게 나타나는지를 제대로 반영하지 못한다”라며 “위험 평가는 기업이 실제로 어디에 노출돼 있는지를 파악하고 의사결정을 지원하는 역할을 해야 한다”라고 설명했다.

또한 이러한 안일함을 피하려면 상황(Context) 중심의 접근 방식이 필요하다고 조언했다.

몬달은 “자산이 어디에 있는지, 누가 접근할 수 있는지, 어떤 데이터를 다루는지, 운영에 얼마나 중요한지, 장애가 발생하면 어떤 일이 벌어지는지를 살펴봐야 한다”라며 “위험은 기술적인 분석 결과뿐 아니라 반드시 비즈니스 영향과 연결해 평가해야 한다”라고 말했다.

아울러 위험은 기술만의 문제가 아니라며 IT와 운영 부서를 비롯한 내부 비즈니스 리더를 보안 조직의 위험 평가 과정에 참여시키는 것도 권고했다.

2. 결과를 좋게 포장하는 것

소프트웨어 개발 기업 베어스데브(BairesDev)의 최고정보보호책임자(CISO) 파블로 리볼디(Pablo Riboldi)는 어려운 시기일수록 이해관계자에게 현실을 있는 그대로 전달해야 한다고 말했다.

리볼디는 “평가 결과가 기대에 미치지 못했다면 위협 환경이 기존 평가 체계가 예상했던 것보다 훨씬 빠르게 변화했다는 사실을 인정해야 한다”라고 밝혔다.

또한 단순히 취약점 목록만 전달해서는 안 된다고 지적했다.

리볼디는 “실제 공격 시나리오를 함께 제시해야 한다”라며 “예를 들어 가장 중요한 비즈니스 자산 3개를 우선 선정해 심층 위험 평가를 수행하면 위험의 심각성과 함께 즉각적인 비즈니스 가치를 보여줄 수 있다”라고 설명했다.

3. 위험 평가 범위를 충분히 설정하지 않는 것

사이버보안 서비스 기업 수주 랩스(Suzu Labs)의 최고기술책임자(CTO) 데니스 칼데론(Denis Calderone)은 많은 CISO가 통제 항목을 문서화하고 규정 준수 여부를 확인한 뒤 모든 것이 문제없다는 내용의 위험 등록부(Risk Register)를 작성하는 데 그친다고 지적했다. 그러나 정작 해당 통제가 실제로 제대로 작동하는지 검증하거나, 위험 평가 범위가 정말 중요한 자산과 시스템을 포함하고 있는지 점검하는 경우는 드물다는 설명이다.

칼데론은 “이런 사례는 흔하게 볼 수 있다”라며 “예를 들어 운영 서버와 사내 네트워크는 평가 대상에 포함하면서도 한쪽에 방치된 오래된 개발 서버나 내부 담당자가 없는 외부 협력사 포털, 또는 2년 전 프로젝트를 위해 구축한 뒤 폐기하지 않은 API 엔드포인트는 제외하는 경우가 많다”라고 설명했다.

이어 “공격자는 조직이 설정한 평가 범위에는 관심이 없다”라며 “전체 환경을 살펴본 뒤 조직이 평가할 가치가 없다고 판단한 취약한 지점을 찾아 공격한다”라고 말했다.

AI 도입은 이런 문제를 더욱 악화시키고 있다고 칼데론은 지적했다.

그는 “많은 조직이 AI 도구를 내부 시스템과 연동하고 민감한 데이터 접근 권한까지 부여하고 있지만, 이러한 변화가 위험 평가에는 반영되지 않는 경우가 많다”라며 “AI 에이전트는 API를 호출하고 데이터베이스에 접근하며 각종 자격 증명을 활용해 작업하지만 이를 제대로 추적하는 조직은 거의 없다”라고 설명했다.

또한 “조직이 AI를 업무 프로세스에 도입하기 전에 작성한 위험 평가는 이미 현실을 반영하지 못하는 문서가 됐다고 봐야 한다”라고 경고했다.

4. 전제를 검증하지 않은 채 위험 등록부만 신뢰하는 것

전 세계에서 원유와 석유제품을 운송하는 해운 기업 인터내셔널 시웨이스(International Seaways)의 최고정보책임자(CIO) 겸 최고정보보호책임자(CISO) 아미트 바수(Amit Basu)는 실제 위험 노출을 이해하는 것이 아니라 위험 평가를 완료하는 것 자체가 목표가 되면, 감사에는 통과할지 몰라도 경영진을 잘못된 방향으로 이끄는 문서만 남게 된다고 지적했다.

바수는 이러한 접근이 잘못된 안전감을 심어줄 수 있다고 설명했다.

그는 “경영진과 이사회는 위험 등록부가 완성된 것을 보고 조직이 충분히 보호되고 있다고 생각한다”라며 “하지만 평가 체계에 맞지 않는 실제 위협은 그대로 방치된다”라고 말했다.

이어 “이런 함정은 스스로 모습을 드러내지 않는다”라며 “모든 것이 정상으로 표시된 녹색 대시보드 속에 숨어 있다”라고 비유했다.

바수는 위험 평가는 그 기반이 되는 전제만큼만 신뢰할 수 있다고 강조했다.

그는 “위험 평가에 적용한 전제를 명확하게 문서화하고, 비즈니스가 변화하거나 위협 환경이 달라질 때, 또는 보안 사고를 통해 새로운 취약점이 드러날 때마다 반드시 다시 검토해야 한다”라며 “위험 평가는 한 번 작성하고 끝나는 결과물이 아니라 보안 조직과 비즈니스 조직이 지속적으로 논의하기 위한 살아있는 자료”라고 설명했다.

5. 위험을 비즈니스 영향과 연결하지 않는 것

고객 ID 및 접근 관리(CIAM) 플랫폼 기업 퓨전오스(FusionAuth)의 전략 및 ID 표준 담당 수석 디렉터 댄 무어(Dan Moore)는 위험과 비즈니스 영향의 연관성을 무시하거나 축소하면 문제의 우선순위가 뒤로 밀리거나 아예 간과되기 쉽다고 지적했다.

무어는 “그 결과 보안 침해를 비롯한 각종 위험이 비즈니스에 미치는 실제 영향을 이해관계자에게 제대로 전달하기 어려워진다”라며 “더 심각한 문제는 보안팀이 ‘우리의 가치를 제대로 인정받지 못한다’거나 ‘우리의 말을 이해하지 못한다’고 불만을 제기하는 명분이 생기고, 이는 결국 조직의 업무 효율성을 떨어뜨린다는 점”이라고 설명했다.

무어는 위험을 설명할 때는 구체적이고 명확한 접근이 필요하다고 조언했다.

그는 “‘패치 적용률이 95%에 달한다’고 말하기보다 패치되지 않은 시스템이 비즈니스에 어떤 위험을 초래하는지를 설명해야 한다”라며 “인터넷이나 핵심 업무와 연결되지 않은 레거시 시스템은 동일한 패치 문제가 있더라도 다른 시스템보다 위험도가 낮을 수 있다. 이러한 차이를 인정하고 대응 우선순위를 결정해야 한다”라고 말했다.

6. 규정 준수를 실제 보안과 혼동하는 것

침투 테스트 및 보안 자문 기업 네트라가드(Netragard)의 최고경영자(CEO) 애드리얼 데소텔스(Adriel Desautels)는 규정 준수만으로는 효과적인 보안을 확보할 수 없으며, 최소한의 보호 수준조차 충족하지 못한다고 지적했다.

데소텔스는 많은 조직이 규정 준수에 초점을 맞추면서도 최고 수준의 서비스를 제공한다고 홍보하는 침투 테스트 업체를 선택하는 과정에서 이러한 함정에 빠진다고 설명했다.

그는 “실제로는 사람이 수행하는 침투 테스트인 것처럼 포장된 자동화 스캔만 제공하는 경우가 적지 않다”라고 말했다.

데소텔스는 그 결과 조직은 잘못된 안전감을 갖게 된다고 경고했다.

그는 “이는 종이로 만든 안전벨트를 착용한 것과 같다”라며 “보호받고 있다고 생각하지만 낮은 속도의 충돌에서도 부상을 입거나 더 심각한 결과를 맞을 수 있다”라고 설명했다.

이어 “지난 10년 동안 발생한 주요 보안 침해 사례를 보면, 사고 당시 해당 조직들은 모두 규정을 준수하고 있었다는 사실을 기억해야 한다”라고 덧붙였다.

7. 위험 자체를 제대로 이해하지 못하는 것

클라우드 기반 운영 복원력, 업무 연속성 및 리스크 관리 솔루션 기업 퓨전 리스크 매니지먼트(Fusion Risk Management)의 사이버보안 담당 수석 디렉터 사피 라자(Safi Raza)는 많은 조직이 위험 평가를 취약점을 찾아 등급을 매기고 감사를 통과하기 위한 절차 정도로만 인식한다고 지적했다. 그러나 감사 통과와 위험에 대한 올바른 이해는 전혀 다른 문제라는 설명이다.

라자는 CISO가 기술적인 위험 신호를 실제 운영 성과와 연결하는 데 집중해야 한다고 말했다.

그는 “어떤 서비스가 영향을 받는지, 장애가 어떻게 확산되는지, 그리고 이것이 매출과 고객, 규제 준수 의무에 어떤 의미를 갖는지까지 이해해야 한다”라고 설명했다.

또한 정적인 위험 평가에서 벗어나 지속적이고 상황(Context) 중심의 위험 가시성을 확보해야 한다고 조언했다.

라자는 “위험은 기술적인 측면뿐 아니라 비즈니스에 미치는 영향과 재무적 손실 가능성까지 함께 고려해 이해해야 한다”라고 말했다.
dl-ciokorea@foundryco.com

At some point, every security leader gets asked a version of the same question: Are we good? It tends to arrive when something is at stake and the person asking needs to know they can rely on the answer.

I learned what that question really means at a firm I was with earlier in my career. We had received intelligence that threat actors were preparing to go after financial services firms over the holidays, counting on skeleton staffing and slower response times. We had procedures for exactly that kind of heightened alert, and we ran them. The moment that stayed with me came in a hallway. The head of business stopped me and asked, plainly, “Are we good?” He was not asking for a status report on our controls or a walkthrough of our incident response plan. He wanted a seasoned leader to look at him and say, with conviction, that we were good.

That instinct, the need for someone accountable enough to say “we’re good” and mean it, sits at the center of a debate the cybersecurity industry keeps having: Whether the CISO role has become unsustainable. The list of responsibilities continues to grow. Security leaders are expected to oversee cyber resilience, regulatory compliance, third-party risk, business continuity, AI governance, incident response and an ever-more-complex threat landscape. Boards, regulators, customers and investors simultaneously demand greater visibility into cyber risk than ever before.

The conclusion many people draw from this expansion is that the traditional CISO role can no longer work. If no single person can realistically master every domain that falls under modern cybersecurity, perhaps the role itself has become obsolete.

I believe the opposite is true. The modern CISO is disappearing from one version of itself and re-emerging as something larger. It is undergoing the same evolution the CFO role experienced over the last two decades.

Historically, CFOs were viewed primarily as financial operators. Their responsibilities centered on accounting, reporting, controls, audits and budgeting. As businesses grew larger, more global, more regulated and more dependent on technology, that model changed. The CFO evolved from a finance specialist into a strategic executive responsible for shaping enterprise-wide decisions. McKinsey documented this shift, finding that the number of functions reporting to CFOs had expanded significantly, and that business leaders had come to see them as critical drivers of change across the enterprise, not just stewards of the balance sheet.

Nobody looked at that expanding mandate and concluded the CFO role was becoming irrelevant. They recognized that finance had become more important to the business.

The same thing is happening in cybersecurity. For years, security was treated as a technical discipline operating on the periphery of the organization. Today, a significant cyber incident can halt operations, disrupt revenue, trigger regulatory scrutiny, damage customer trust and move markets. Cyber risk has become business risk, and that shift fundamentally changes what a CISO is for. Security leaders increasingly sit on enterprise risk committees alongside their peers, and regulators are paying far closer attention to how security is built into the design of products and systems from the outset. Both are signs that security has moved from a back-office function into the room where business risk gets decided.

The data reflects how much the role has already changed. According to Splunk’s 2026 CISO Report, nearly all CISOs now count AI governance and risk management among their core responsibilities. Seventy-eight percent report personal liability concerns tied to security incidents, up from 56% just a year ago. The role now carries individual legal exposure alongside operational accountability. That is a description of an executive function, full stop.

Modern security leaders are now expected to help boards understand risk, participate in strategic planning, navigate regulatory obligations, oversee resilience programs and establish governance around emerging technologies like artificial intelligence. These responsibilities extend well beyond traditional security operations, and the job has grown considerably faster than the organizational structures supporting it.

Some companies have responded by building larger, more specialized security leadership teams. Microsoft’s Secure Future Initiative is the most prominent example. The company established a Cybersecurity Governance Council led by a Global CISO, with over a dozen Deputy CISOs appointed across major security domains including engineering, AI, cloud services, gaming and government systems. It represents one of the largest security transformations in the industry, involving thousands of engineers and a governance structure built to coordinate security across a genuinely sprawling organization.

Some observers read structures like this as evidence that the traditional CISO model is breaking down. Look closer and you see the opposite. Microsoft expanded the organization supporting security leadership rather than dismantling it. Centralized accountability remains with a global CISO while execution is distributed across specialized leaders and teams.

This is exactly what mature executive functions look like at scale. Large enterprises do not eliminate CFOs when finance grows more complex. They add controllers, treasury leaders, FP&A organizations and investor relations teams. Complexity does not eliminate executive accountability. It deepens the need for it.

There is shared, organization-wide security: the SOC, vulnerability management and the other services the entire firm depends on. Then there is business-line security, led by deputy or business-unit CISOs whose job is to make sure their individual units are protected. Those embedded leaders drive requirements into the shared services and provide independent oversight of them, while staying close enough to their business to understand what it actually needs. One central executive owns the whole picture, with specialized leaders carrying it into every corner of the organization.

One structural point follows directly from this: The CISO should never report to the CTO. The person accountable for security should not sit underneath the person accountable for building and shipping technology, because those two mandates can pull in different directions. Security belongs under the COO, the CRO or the CEO, where it can speak to risk independently and be heard.

AI is accelerating this evolution further. Organizations are deploying autonomous systems capable of making recommendations, triggering workflows and acting at machine speed. What AI cannot do is own the decisions behind those actions. Someone still has to determine what can be delegated to machines, establish governance frameworks, define acceptable risk and answer for those choices to regulators, boards and shareholders. In most organizations, that someone is the CISO.

The most practical place to start is a simple principle: every AI action should trace back to an accountable human. Framed that way, we are not delegating decisions to AI at all. We are putting machines to work while keeping a person answerable for what they do. That principle forces accountability to live somewhere specific in the organization rather than dissolving into the system.

This is worth sitting with: AI may strengthen the case for executive security leadership rather than weaken it. For years, CISOs governed human behavior inside organizations. Now they govern human and machine behavior simultaneously, a mandate with no obvious ceiling.

The cybersecurity industry keeps asking whether the CISO role can survive the demands being placed on it. The better question is whether organizations are adapting their leadership structures fast enough to support where the role is already heading.

The future of security leadership is unlikely to be a loose collection of specialists operating without clear ownership. It will more closely resemble other mature executive functions, with specialized leaders operating under a single accountable executive who understands how risk connects to the business as a whole. As cyber risk becomes inseparable from business risk, that executive becomes indispensable.

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

A copilot that gives a wrong answer is a quality problem. An AI agent that takes a wrong action is an incident, sometimes a reportable one. That single difference is most of the story of where banking AI security is heading, and most banks’ current controls were built for the first kind of problem, not the second.

For two years, the AI a bank had to worry about mostly read and summarized. It drafted a customer email, pulled the gist of a credit memo, answered a relationship manager’s product question. The security questions were about disclosure: could the model see data it shouldn’t, could it leak that data in an answer. Redaction, output filtering and a human reading the response before it went anywhere were reasonable defenses.

Banks have moved past that, faster than most security programs have. The newer systems are agents. They don’t just answer; they act. An agent can pull a customer’s full transaction history, call a fraud-scoring service, adjust a limit or start a payment workflow, chaining several to finish a task with no human in between. Banks are among the most aggressive adopters of agentic AI, and they are pushing it into production faster than most security programs have kept pace with, which means they are also among the first to inherit the security problem that comes with it.

I’d put that problem in one phrase: overprivileged agents. The risk is no longer mainly what the model can see. It is what the agent is allowed to do inside systems that move money and hold regulated data.

This is no longer only a vendor’s warning. On April 30, 2026, the cyber agencies of the Five Eyes nations issued their first joint guidance on securing agentic AI, Careful Adoption of Agentic AI Services. Six agencies signed it, two of them American (CISA and the NSA), alongside the lead agencies of the UK, Australia, Canada and New Zealand. It names privilege as the leading category of agentic risk and calls strict least privilege critical. When five governments coordinate on a single control, “best practice” becomes “expected practice” quickly. For a CISO, that moves the timeline up.

What “too much authority” actually looks like

OWASP’s breakdown of the failure mode it calls excessive agency maps cleanly onto a bank. Excessive functionality is an agent that can reach tools its task never needed, like a servicing agent that can also touch the payments API “just in case.” Excessive permissions is the right tool at the wrong scope: a reconciliation agent meant only to read, running with credentials that can also write. Excessive autonomy is a consequential action with no human in the loop: a fee reversed, a limit raised, a record changed, with nothing checking it. In practice these rarely appear alone; they compound.

The canonical example is mundane: an agent that reads one user’s data through an account that can see everyone’s. Translate that to a bank and it becomes an agent that can query every customer’s records to answer a question about one. That is the confused-deputy problem: the agent acts with the full authority of whatever identity it borrowed, while taking instructions from input an attacker may control.

The mechanism, from a real incident

The clearest public illustration so far comes from developer tooling rather than banking, but the mechanism is identical. In July 2025, an attacker used an over-scoped build token to slip malicious code into the open-source repository behind the Amazon Q Developer extension for VS Code, and it shipped in an official release (CVE-2025-8217). The injected instructions told the AI assistant to wipe the local machine and delete cloud resources, down to specific S3 buckets and EC2 instances. The assistant could reach the local filesystem, the shell and AWS CLI tools, so structurally little stood between those instructions and real damage. What stopped them was a bug: the payload had a syntax error and never ran, and AWS found no customer environments affected. But the extension had been installed close to a million times, and the margin of safety was an accident.

The uncomfortable part is not that the agent was “hacked” in the usual sense. Had the attacker’s code been written correctly, the agent would have done exactly what the injected text told it, through a channel it trusted. The lesson: an agent with broad tools, write access and no approval gate is dangerous not only when someone steals its credentials, but any time someone can reach its input. And in a bank, reachable inputs sit everywhere an agent reads text it did not author: the memo line on a wire, a customer’s email in a dispute, a PDF uploaded to a loan file, a free-text field in a KYC record. This is indirect prompt injection, and the defenses for it are still partial. You cannot reliably solve it by instructing the agent to behave. You solve it by limiting what it is able to do, regardless of what it is told.

What I keep seeing in deployments

In the redaction-control work I’ve done with banks, the gap is rarely the model. It is that the agent gets wired to the data and the tools first; what it should be allowed to reach gets asked later, if at all.

One pattern recurs. A customer-servicing agent is wired into the core banking system to resolve account queries. To answer a simple question, it pulls the customer’s entire profile into context: full account number, date of birth, the complete transaction narrative. The task needed the last four digits and a list of recent transactions; the agent got everything, and each field then sat in prompts, logs and traces never scoped as sensitive data. The fix was not a sharper prompt. It was moving redaction to the retrieval boundary, so those fields were tokenized before they reached the agent, and scoping its read access to the one customer in the open case, not the whole table.

The other half of the problem is authority, not data. That same agent often shares a service account with a batch job, so it can write to fields well beyond a customer’s question. A dedicated identity with its own scoped, short-lived credentials is unglamorous work, but it is the difference between an agent that can read one case and one that can quietly change thousands.

Extending controls banks already have

The reassuring part is that banks are not starting from zero. Maker-checker, segregation of duties, four-eyes approval, least privilege, immutable audit: this is muscle memory in a bank. The work is extending it to a non-human actor that runs at machine speed.

Give the agent its own managed identity with narrowly scoped, short-lived credentials instead of letting it borrow an employee’s session. That is the direct fix for the confused-deputy problem, and what the joint guidance asks for. Scope tools per task and per resource: read versus write, and which accounts, not a blanket grant. Put irreversible, high-impact actions (moving money, changing entitlements, closing accounts, exporting bulk data) behind explicit approval gates, the human-in-the-loop the guidance reserves for high-cost actions. Redact at the data-access boundary, not only on the output: an agent that never retrieves the full account number cannot leak it downstream. And log the agent’s plan and every tool call, not just its final answer, because in an agentic system the damage lives in the actions.

Why the clock is real

Regulation has put a date on this. India’s Digital Personal Data Protection Rules were notified on November 14, 2025; the institutional provisions are already in force, and the substantive obligations (purpose limitation, data minimization, breach notification) take full effect in May 2027. Under that lens, an agent that can reach more customer data than its task requires is not only a security weakness; it is a data-minimization and accountability problem. Banks under GDPR or the EU AI Act face the same logic from a different statute.

One honest caveat: none of these laws actually names AI agents. Mapping their principles onto agent authorization is interpretation and prudent risk management, and each bank should work the specifics through with its own legal and compliance teams rather than treat the matter as settled.

The trade-offs nobody has solved

None of this is free. Approval gates work against the entire reason to deploy an agent: gate every action and you have rebuilt a slower manual process. Deciding which actions to gate, and which can run autonomously within tight scope, is a real design problem that turns on each workflow’s blast radius. Logging every plan and tool call produces audit volume most pipelines were not built for. Standards for agent identity are still immature, and the agent supply chain is itself an attack surface, as the Amazon Q case showed.

These are real tensions, not problems with clean answers. But the governance gap that the 2026 surveys keep finding is not a story of banks failing to deploy agents. It is controls trailing agents that are already running. The alternative, porting copilot-era defenses onto agents and trusting output filters, guards the wrong door.

Banks are hitting this first because they are ahead. That is also the opportunity: the institutions that settle their agent authorization model now, while deployments are still small enough to change course, will not just avoid the incident. They will set the pattern everyone else copies.

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

ISO-Zertifizierungen, aber auch die Einführung eines Informationssicherheits-Managementsystems (ISMS) nach IT-Grundschutz, werden von vielen Unternehmen als Beweis für ihre Qualität und ihren professionellen Ansatz bei der Durchführung ihrer Geschäftstätigkeit angesehen. Obwohl das ein wichtiger Grundstein für jedes Unternehmen ist, läuft in einigen Fällen nicht immer alles wie geplant. Im Folgenden werden die häufigsten Fallstricke bei der ISO-/ISMS-Einführung und deren Zertifizierung sowie Lösungsansätze aufgeführt.

1. Fehlende Verbindlichkeit der Geschäftsleitung

Allen voran geht die Geschäftsleitung. Egal, ob als Einzelperson oder zu mehreren. Einer der maßgeblichen Faktoren, der dazu führt, dass ISO-/ISMS-Einführungen in Unternehmen nicht funktionieren, ist das fehlende Commitment der Geschäftsführer. Diese muss die Bedeutung der ISO-/ISMS-Einführungen verstehen und sich aktiv für ihre Umsetzung und Aufrechterhaltung einsetzen. Ohne das Engagement der Geschäftsleitung ist es oft schwierig, alle Mitarbeiter für den Prozess zu gewinnen und sicherzustellen, dass die ISO-Standards oder auch die Standards nach IT-Grundschutz in den täglichen Geschäftsablauf integriert werden.

Deshalb sollten Unternehmen auf jeden Fall klarstellen, wie wichtig das Thema ist – auch, wenn die Umsetzung mit hohem Aufwand und Unannehmlichkeiten verbunden sein kann. “Aufräumen” ist nicht immer schön. Das Ergebnis dafür aber umso lohnender. Wenn die Geschäftsleitung die ISO-/ISMS-Einführungen unterstützt und fördert, kann dies zu einem erfolgreichen Abschluss und einem besseren Unternehmensimage führen.

2. Dran vorbei statt mittendrin

Einer der häufigsten Gründe, warum ISO-/ISMS-Einführungen in Unternehmen nicht funktionieren, ist, dass sie nicht tatsächlich in den täglichen Geschäftsablauf integriert werden. Viele betrachten die ISO-/ISMS-Einführungen als eine einmalige Aktivität, die einmal durchgeführt wurde, um das Zertifikat zu erhalten. Dabei achten sie jedoch nicht darauf, die geschaffenen Abläufe in ihre täglichen Geschäftspraktiken zu integrieren. Ohne eine tatsächliche Einbindung in den täglichen Geschäftsablauf wird das Zertifikat nutzlos und die Vorteile, die es bietet, werden nicht realisiert. Im schlimmsten Fall zahlen Organisationen sogar drauf, lassen dabei jedoch in jedem Fall wertvolles Entwicklungspotential liegen.

Bei der Integration gilt es zu beachten, dass man sich nicht zu sehr in Details verliert. Die (arbeits-)lebensnahe Umsetzung des Managementsystems ist maßgeblich für dessen Erfolg. Anstatt komplizierte Prosa zu schreiben, tut es vielleicht auch eine Grafik. Frei nach dem Motto “Ein Bild sagt mehr als tausend Worte!”. Sind Abläufe leicht und intuitiv zu erfassen und klar umzusetzen, werden sie auch gelebt. Hier kann es auch hilfreich sein, Prozesse zu automatisieren. Auch der Blick von außen durch einen erfahrenen Berater kann von Vorteil sein.

3. Mitarbeiter nicht umfassend beteiligen

Ein weiteres Problem, das bei ISO-/ISMS-Einführungen häufig vorkommt, ist die fehlende Beteiligung aller Mitarbeiter. Wenn nur ein kleiner Teil des Unternehmens für die Umsetzung der ISO-/ISMS-Einführungen verantwortlich ist, kann es zu einer Desynchronisation zwischen den Abteilungen kommen, die nicht Teil des Prozesses sind. Dies führt dazu, dass bestimmte Abteilungen nicht an den vorgesehenen Verfahren teilnehmen und dass die ISO-/ISMS-Einführungen letztendlich nicht funktioniert.

Die Lösung hierzu? Erfahren Sie im nächsten Punkt.

4. Mitarbeiteridentifikation nicht fördern

Ein weiterer Faktor, der die Funktionalität von ISO-/ISMS-Einführungen in Unternehmen erschwert, ist die fehlende Identifikation der Mitarbeitenden mit der Einführung und dem daraus resultierenden Managementsystem. Die Mitarbeiter müssen verstehen, warum die Einführung wichtig ist, wie sie in ihre täglichen Arbeitsabläufe integriert werden soll und wie das ihnen die Arbeit erleichtert. Ist das nicht der Fall, wird es schwierig , die Einführung umzusetzen und eine daraus etwaig resultierende Zertifizierung aufrechtzuerhalten.

Eine Lösung dafür bilden zum Beispiel Schulungen und Weiterbildungsprogramme. Diese tragen dazu bei, dass die Mitarbeitenden frühzeitig in den Zertifizierungsprozess einbezogen werden. Dadurch wird sichergestellt, dass alle Mitarbeitenden die Bedeutung der Zertifizierung verstehen und wie diese in ihre täglichen Arbeitsabläufe integriert werden kann.

Die Schulung und Einbindung der Mitarbeitenden stellt zudem sicher, dass das Managementsystem effektiv umgesetzt wird. Die Angestellten tragen dadurch aktiv zu dessen Verbesserung bei.

5. Vernachlässigen von Kompetenzbildung

Schulungen für Mitarbeitende im Kontext der ISO-/ISMS-Einführungen sind in vielerlei Hinsicht wichtig. Fehlende Kompetenz bei den Verantwortlichen trägt oftmals dazu bei, dass Zertifizierungsvorhaben spätestens im Audit scheitern. Schulungen und das Bilden von Bewusstsein aller Mitarbeitenden für die Bedeutung der ISO-/ISMS-Einführungen und ihre Rolle bei der Umsetzung sind deshalb essentiell.

Ein gut ausgebildetes Team findet gute und effiziente Lösungen für den Aufbau und die Umsetzung eines Managementsystems. So kann Bürokratisierung vermieden werden. Damit ist Kompetenzbildung von Anfang an ein entscheidender Faktor für den Erfolg einer ISO-/ISMS-Einführungen.

6. Umsetzen ohne Plan

Ein weiteres Hindernis bei der Implementierung von ISO-/ISMS-Einführungen, ist das Fehlen eines klaren Plans zum Vorgehen. Viele Organisationen beginnen den Prozess ohne, dass sie eine genaue Vorstellung davon haben, was für eine erfolgreiche Einführung oder eine Zertifizierung benötigt wird. Dadurch verschwenden sie Zeit und Ressourcen. Ohne einen genauen Plan konzentrieren sich Firmen auf Bereiche, die nicht relevant sind oder die Anforderungen der ISO-/IT-Grundschutz Standards nicht erfüllen. Dauert die Umsetzung für den Aufbau eines Managementsystems zu lange, kann es außerdem dazu kommen, dass die reguläre Unternehmensentwicklung den Prozess selbst überflügelt und Arbeit mehrfach anfällt, um Änderungen zu folgen.

Eine mögliche Lösung besteht darin, einen klaren Plan zu erstellen, der die Schritte zur Implementierung der Standards festlegt. Dieser Plan sollte die spezifischen Anforderungen der gewählten Standards, die benötigte Zeit und die Ressourcen für die Einführung/Zertifizierung, sowie die Verantwortlichkeiten und Aufgaben der beteiligten Mitarbeiter und Abteilungen berücksichtigen. Durch eine klare Definition einer Deadline für den primären Aufbau des Managementsystems können Unternehmen sicherstellen, dass sie sich auf die wichtigsten Bereiche konzentrieren. Somit sind sie in der Lage, Zeit und Ressourcen effektiver zu nutzen. Eine vorgelagerte Soll-Ist-Stand- oder GAP-Analyse ist dabei ein erprobtes Mittel, um Klarheit zu schaffen und die Basis für eine konkrete Planung zu erhalten.

7. Das passt schon so oder währt ehrlich doch länger?

Wenn Unternehmen sich selbst belügen, funktioniert die ISO-/ISMS-Einführungen ebenfalls nicht. Oftmals werden Schwachstellen- und Risikoanalysen nicht objektiv betrachtet oder eigentlich relevante Themen schlicht nicht erfasst. So nach dem Motto: “Was der Auditor nicht weiß, macht ihn nicht heiß.”

Dies führt dazu, dass Unternehmen ihre Risiken nur unzulänglich behandeln oder erst gar nicht wahrnehmen und somit die Wirksamkeit des Managementsystems beeinträchtigen. Der Aufschrei, wenn ein Risiko nach einer zuvor positiven Bewertung eintritt und immense Kosten zu dessen Behebung anfallen, ist im Nachhinein oft groß.

Eine unehrliche Betrachtung sorgt dafür, dass die Implementierung der gewählten Standards oberflächlich und unvollständig erfolgt, was die Einführung und gegebenenfalls auch die Zertifizierung letztendlich sinnlos macht.

Eine Lösung hierfür besteht darin, dass Unternehmen schonungslos ehrlich zu sich selbst sind und sich gegebenenfalls auch Hilfe zur Selbsthilfe holen. Ein unvoreingenommener und erfahrener Berater kann helfen, Risiken richtig einzuschätzen. Außerdem ist er in der Lage, potentielle Szenarien aufzeigen, die aufgrund von Betriebsblindheit sonst nicht gesehen werden. So kann das Unternehmen eine ehrliche Risikoanalyse durchführen und Schwachstellen im Unternehmen identifizieren, um eine effektive Implementierung der gewählten Standards zu gewährleisten.

8. Die Einführung/Zertifizierung als abgeschlossenen Prozess betrachten

Ein weiteres häufiges Problem bei ISO-/ISMS-Einführungen ist das Fehlen eines kontinuierlichen Überwachungs- und Verbesserungsprozesses. Viele Unternehmen sehen die ISO-/ISMS-Einführungen als einen abgeschlossenen Prozess. Werden jedoch keine kontinuierlichen Bemühungen unternommen, um die Umsetzung der gewählten Standards aufrechtzuerhalten und zu verbessern, droht das Unternehmen schnell hinter den neuesten Trends und Anforderungen zurückzufallen. Im schlimmsten Fall kann es sogar passieren, dass das Unternehmen seine Zertifizierung verliert. Im Anschluß ist es entsprechend schwer, diese erneut zu erlangen.

Um diese Probleme zu vermeiden, müssen Unternehmen die ISO-/ISMS-Einführungen als einen kontinuierlichen Prozess ansehen, der ständig überwacht und verbessert wird. Alle Mitarbeiter sollten in den Prozess einbezogen werden, um eine reibungslose Umsetzung und eine tatsächliche Integration in den täglichen Geschäftsablauf zu gewährleisten. Zudem ist es wichtig, dass regelmäßig Überprüfungen und Audits durchgeführt werden. Dadurch sorgen Organisationen dafür, dass sie immer den neuesten Standards entsprechen.

9. Einsatz von Billiglösungen

Eine ISO-/ISMS-Einführung und Zertifizierung ist nichts für Unternehmen, die auf Billiglösungen aus sind. Viele Unternehmen versuchen, Kosten zu sparen, indem sie sich für günstigere Lösungen entscheiden oder versuchen, die Standards auf eigene Faust und ohne angemessene Ressourcen zu implementieren.

Dies führt regelmäßig dazu, dass Unternehmen wichtige Bereiche übersehen oder mangelhafte Lösungen implementieren, die die Standards nicht vollständig erfüllen oder nur Mehrarbeit schaffen, ohne die eigentlich möglichen Vorteile eines Managementsystems zu erschließen. Es ist wichtig zu verstehen, dass die Implementierung von ISO/IT-Grundschutz-Standards ein wichtiger und langfristiger Prozess ist. Dieser erfordert eine angemessene Investition, um sicherzustellen, dass alle Anforderungen erfüllt werden und das Managementsystem effizient umgesetzt wird. Was bringt es, am Anfang zu sparen und dann auf Dauer mehr Kosten zu haben, um die Fehler in der Basis auszugleichen?

Lösen lässt sich dieses Dilemma durch eine klare und ausführliche Bestandsaufnahme in Kombination mit einem Soll-Abgleich. Auf Basis eines klaren Bildes, was zu tun ist, lässt sich ein angemessenes Budget für die Implementierung der gewählten Standards bereitstellen und auf qualitativ hochwertige Lösungen setzen, die den Anforderungen entsprechen.

So kommen auch langfristige Vorteile von Managementsystemen zum Tragen, wie eine verbesserte Effizienz, Qualität und Kundenzufriedenheit, was letztendlich zu höheren Umsätzen und Gewinnen führen kann. Ein angemessener Mehraufwand schon bei Implementierung des Systems rechnet sich also langfristig gesehen. (jm)

Lesetipp: Gut zertifiziert ist halb gewonnen

In a test of major LLMs, Zscaler found that some autonomous AI agents fell victim to frauds, reinforcing how easily some high-end enterprise agents can be conned by schemes that would fool few, if any, humans.

The security vendor looked at various forms of indirect prompt injection (IPI) traps and found that, whereas many models fell victim to the schemes, some of the lower-level LLMs fared better than their pricier siblings. 

The Zscaler testing found, for example, that four models were found to be “vulnerable”: Llama3-3-70b-instruct; Llama3-2-90b-instruct; Gemini-3-flash; and Gemini-2.5-pro. Three models were found to be “safe”: Llama4-maverick; Gemini-3.1-pro; and Gemini-3.1-flash-lite. Those results indicated that the scam resistance of Gemini-2.5-pro was seemingly weaker than that of Gemini-3.1-flash-lite. 

But Noah Kenney, principal consultant at Digital 520, said that there is not necessarily any valuable takeaway from that revelation, because agents constantly change behavior as they feed on new data and revise their analyzed assumptions. That means an agent that failed a specific test might very well pass the identical test an hour later, he said. 

“The risk of an agent is constantly changing and that can cause vastly different results. You can’t assume the results are generalizable. The test result is only at one point in time,” Kenney pointed out. Zscaler “is trying to prove a point that I don’t think the data necessarily proves.”

Kenney added that having a clean “safe/vulnerable” classification is too simplistic to be useful. “That’s a binary classification. I would never recommend to a CISO to do a binary classification.”

The full ZScaler blog post argued that many autonomous agents are susceptible to IPI traps.

The company said it identified IPI embedded in multiple websites, where hidden instructions were designed to manipulate the behavior of an AI agent.

In its internal validation across 26 LLMs, 4 models “failed to take appropriate actions,” which, it said, demonstrated “measurable real-world impact, showing that susceptibility varies by model and by the context provided to the LLM alongside the prompt.”

The post added, “as AI agents become a more common interface to the web, the content itself is going to become a larger attack surface, highlighting that AI is a double-edged sword that can streamline workflows while also introducing new avenues for abuse.”

Aman Mahapatra, chief strategy officer for Tribeca Softtech, a New York City-based technology consulting firm, said that although the results are not surprising, they are significant. 

The especially worrisome detail in the report is that any commercial LLM failed at all, “because the security model for agentic AI has historically assumed that model-level safety training would meaningfully attenuate this class of attack,” Mahapatra said. “It does not, and the Zscaler data is the first widely-cited public evidence.”

A fundamental architecture issue

Mahapatra also said that the examples cited by Zscaler are not nearly as concerning as the implications of the greater damage that could occur.

“The Zscaler payment scam scenario, where an agent pays a fake $3 ‘developer license fee’ to obtain an API key, is the most benign version of this,” he said. “The same technique applied to an agent authorized for procurement, expense processing, vendor onboarding, or trade execution produces losses at completely different scales. I have watched Fortune 50 banks stand up agentic workflows in the last six months that would fail exactly this attack in a live examination.”

Indeed, he noted, most AI vendors already understand the magnitude of risk from today’s AI agents.

“Every model provider will admit privately that the fundamental architecture of transformer-based reasoning cannot cleanly separate untrusted content from trusted instructions when both share the context window,” Mahapatra said. “The attack surface is architectural, not just behavioral. That means the defense has to be architectural too, and this is where the enterprise agentic AI conversation is still lagging badly.”

Zscaler’s testing also reinforced the difference in how AI agents and humans process information.

“Humans are skeptical of instructions they did not expect. Agents are eager to follow structured metadata because their training rewards them for treating high-signal fields as authoritative. Humans notice when a payment request appears in the middle of an unrelated task. Agents will thread that payment request into their execution plan if the surrounding context frames it as procedurally necessary,” Mahapatra pointed out, noting that while humans have relationships with vendors, memories of prior interactions, and social context to give them verification signals, agents only have what is in the context window, and, he said, “the context window is now the primary attack surface.”

Fritz Jean-Louis, principal cybersecurity advisor at Info-Tech Research Group, agreed that the risks described in the ZScaler post are concerning, because they are in areas not traditionally addressed by enterprise security.

“These attacks differ from traditional threats in that they target how AI systems process, interpret, and act on information behind the scenes,” Jean-Louis said. “Agentic AI introduces new trust boundaries, including untrusted content influencing automated decision making, tools and plugins acting autonomously on behalf of users, and AI systems operating with broad, inherited permissions. This effectively transforms the challenge into an insider threat paradigm.”

This article originally appeared on InfoWorld.

In a test of major LLMs, Zscaler found that some autonomous AI agents fell victim to frauds, reinforcing how easily some high-end enterprise agents can be conned by schemes that would fool few, if any, humans.

The security vendor looked at various forms of indirect prompt injection (IPI) traps and found that, whereas many models fell victim to the schemes, some of the lower-level LLMs fared better than their pricier siblings. 

The Zscaler testing found, for example, that four models were found to be “vulnerable”: Llama3-3-70b-instruct; Llama3-2-90b-instruct; Gemini-3-flash; and Gemini-2.5-pro. Three models were found to be “safe”: Llama4-maverick; Gemini-3.1-pro; and Gemini-3.1-flash-lite. Those results indicated that the scam resistance of Gemini-2.5-pro was seemingly weaker than that of Gemini-3.1-flash-lite. 

But Noah Kenney, principal consultant at Digital 520, said that there is not necessarily any valuable takeaway from that revelation, because agents constantly change behavior as they feed on new data and revise their analyzed assumptions. That means an agent that failed a specific test might very well pass the identical test an hour later, he said. 

“The risk of an agent is constantly changing and that can cause vastly different results. You can’t assume the results are generalizable. The test result is only at one point in time,” Kenney pointed out. Zscaler “is trying to prove a point that I don’t think the data necessarily proves.”

Kenney added that having a clean “safe/vulnerable” classification is too simplistic to be useful. “That’s a binary classification. I would never recommend to a CISO to do a binary classification.”

The full ZScaler blog post argued that many autonomous agents are susceptible to IPI traps.

The company said it identified IPI embedded in multiple websites, where hidden instructions were designed to manipulate the behavior of an AI agent.

In its internal validation across 26 LLMs, 4 models “failed to take appropriate actions,” which, it said, demonstrated “measurable real-world impact, showing that susceptibility varies by model and by the context provided to the LLM alongside the prompt.”

The post added, “as AI agents become a more common interface to the web, the content itself is going to become a larger attack surface, highlighting that AI is a double-edged sword that can streamline workflows while also introducing new avenues for abuse.”

Aman Mahapatra, chief strategy officer for Tribeca Softtech, a New York City-based technology consulting firm, said that although the results are not surprising, they are significant. 

The especially worrisome detail in the report is that any commercial LLM failed at all, “because the security model for agentic AI has historically assumed that model-level safety training would meaningfully attenuate this class of attack,” Mahapatra said. “It does not, and the Zscaler data is the first widely-cited public evidence.”

A fundamental architecture issue

Mahapatra also said that the examples cited by Zscaler are not nearly as concerning as the implications of the greater damage that could occur.

“The Zscaler payment scam scenario, where an agent pays a fake $3 ‘developer license fee’ to obtain an API key, is the most benign version of this,” he said. “The same technique applied to an agent authorized for procurement, expense processing, vendor onboarding, or trade execution produces losses at completely different scales. I have watched Fortune 50 banks stand up agentic workflows in the last six months that would fail exactly this attack in a live examination.”

Indeed, he noted, most AI vendors already understand the magnitude of risk from today’s AI agents.

“Every model provider will admit privately that the fundamental architecture of transformer-based reasoning cannot cleanly separate untrusted content from trusted instructions when both share the context window,” Mahapatra said. “The attack surface is architectural, not just behavioral. That means the defense has to be architectural too, and this is where the enterprise agentic AI conversation is still lagging badly.”

Zscaler’s testing also reinforced the difference in how AI agents and humans process information.

“Humans are skeptical of instructions they did not expect. Agents are eager to follow structured metadata because their training rewards them for treating high-signal fields as authoritative. Humans notice when a payment request appears in the middle of an unrelated task. Agents will thread that payment request into their execution plan if the surrounding context frames it as procedurally necessary,” Mahapatra pointed out, noting that while humans have relationships with vendors, memories of prior interactions, and social context to give them verification signals, agents only have what is in the context window, and, he said, “the context window is now the primary attack surface.”

Fritz Jean-Louis, principal cybersecurity advisor at Info-Tech Research Group, agreed that the risks described in the ZScaler post are concerning, because they are in areas not traditionally addressed by enterprise security.

“These attacks differ from traditional threats in that they target how AI systems process, interpret, and act on information behind the scenes,” Jean-Louis said. “Agentic AI introduces new trust boundaries, including untrusted content influencing automated decision making, tools and plugins acting autonomously on behalf of users, and AI systems operating with broad, inherited permissions. This effectively transforms the challenge into an insider threat paradigm.”

A cyber risk assessment helps security teams identify, estimate, and prioritize potential threats and vulnerabilities to key enterprise digital and physical assets. Yet, despite its importance, many CISOs fall victim to several types of “gotchas” that prevent them from fully achieving their risk assessment goals.

An assessment should be an essential part of every organization’s overall cybersecurity strategy. The process helps security leaders understand risks to business objectives, evaluate the likelihood and impact of cyberattacks, and develop ways to mitigate the risks they uncover.

Here are the top seven mistakes security leaders should avoid to ensure risk assessment effectiveness.

1. Going through the motions

The biggest “gotcha” is treating cyber risk assessments as a preset checklist or control inventory instead of a decision tool tied to real business impact and threat scenarios, says Shirsendu Mondal, a cybersecurity researcher at the University of North Carolina.

“When assessments become all about checking boxes, they lose the ability to reflect how risk actually shows up in an environment,” he states. “The goal should be to inform decisions about where a business is truly exposed.”

Mondal assers that the best way to avoid the complacency trap is to take a context-driven approach. “Ask where the asset is, who can reach it, what data it touches, how important it is to operations, and what happens if it goes down,” he explains. “Risk should always be tied to business impact, not only technical findings.”

Mondal also recommends adding internal business leaders to security teams, including individuals in areas such as IT and operations, given that risk is more than a technical issue.

2. Sugarcoating results

These are challenging times, so we must be honest with our stakeholders, says Pablo Riboldi, CISO at BairesDev, a nearshore software development firm.

“When results are discouraging, admit that the threat landscape has evolved much faster than the previous evaluation framework anticipated,” he says.

Instead of just handing over lists of vulnerabilities, you need to start presenting actual attack scenarios, Riboldi adds. “For example, by prioritizing the top three most critical business assets and conducting an in-depth assessment on them, you can show immediate value.”

3. Falling short on the scope of your assessments

CISOs often securitize document controls, check compliance boxes, and produce a risk register that claims everything looks absolutely fine, says Denis Calderone, CTO at cybersecurity services firm Suzu Labs. Yet nobody bothered to test whether those controls actually work or stopped to ask whether the scope of the assessment covered what really matters.

We see it all the time, Calderone says. “For instance, the assessment covers the production servers and the corporate network, but skips the old dev box in the corner, the third-party vendor portal nobody owns internally, or the API endpoint that was stood up for a project two years ago and never decommissioned.” Attackers don’t care about your scoping decisions, he says. “They look at the whole environment and find the thing you decided wasn’t worth assessing.”

AI is making the situation worse, Calderone says. Organizations are deploying AI tools, connecting them to internal systems, granting them access to sensitive data, and none of this is landing in the risk assessment. Meanwhile, AI agents are out there making API calls, accessing databases, and operating with credentials that nobody is tracking, he says.

“If your risk assessment was written before your organization started plugging AI into its workflows, it’s already stale,” Calderone warns.

4. Overindexing on the risk register without checking your assumptions

When the goal becomes completing the assessment instead of understanding actual exposure, the output is a document that satisfies auditors but misleads leadership, says Amit Basu, CIO and CISO at International Seaways, a major independent maritime shipping company that transports crude oil and refined petroleum products worldwide.

Such an attitude can create false confidence. Executives and board members see a completed risk register and assume the organization is protected, Basu says. Meanwhile, real threats go unaddressed because they didn’t fit neatly into the assessment framework. “The gotcha does not announce itself,” he explains. “It hides inside a green dashboard.”

A risk assessment is only as good as the assumptions that lie underneath it, Basu observes. “Document those assumptions explicitly and review them whenever your business changes, when the threat landscape shifts, or when an incident exposes a gap,” he advises. “The assessment is not a finished product — it’s a living input to an ongoing conversation between security and the business.”

5. Failing to link risk with business impact

Ignoring or downplaying the connection between risk and business makes it easier to de-prioritize or ignore problems, says Dan Moore, senior director of strategy and identity standards at FusionAuth, a customer identity and access management (CIAM) platform provider.

“As a result, it becomes difficult to communicate the real risks of breaches and other risks,” he states. “Worse yet, it gives security team members an excuse to complain about being misunderstood or not valued, which degrades team effectiveness.”

It’s important to be specific and targeted, Moore advises. “For instance, don’t say, ‘We have 95% patch compliance,’” he suggests. “Instead, talk about the risk unpatched systems pose to the business.” Some systems, such as legacy systems that aren’t connected to the internet or the core business, carry a lower risk than others, even if they have the same patch issues. “Acknowledge that fact and weigh your response.”

6. Confusing compliance with real-world security

Compliance alone doesn’t lead to good security, nor does it satisfy even the baseline requirements for effective protection, says Adriel Desautels, CEO of Netragard, a penetration testing and security advisory company.

Organizations tend to fall into this trap when they hire penetration testing firms that focus on compliance while promising top-tier services, Desautels says. “In truth, they deliver autonomous scanning masquerading as human-driven testing.”

The result is a false sense of security — a paper seatbelt, Desautels warns. “You feel protected, but when you crash, even at low speed, you get injured or worse,” he says. “Remember, every major breach in the past decade involved an organization that was compliant at the time of compromise.”

7. Failing to fully understand risk

Organizations often treat risk assessment as a vulnerability-cataloging exercise that includes finding gaps, counting severities, and passing the audit. Yet passing an audit and understanding risk are not the same thing, states Safi Raza, senior director of cyber security at Fusion Risk Management, a firm offering cloud-based operational resilience, business continuity, and risk management solutions.

Raza says that CISOs should focus on connecting technical risk signals to operational outcomes. “This includes understanding what services are affected, how disruption propagates, and what it means for revenue, customers, or regulatory obligations.”

Start by shifting from static assessments to continuous, context-driven risk visibility, Raza advises. “Risk needs to be understood not just technically, but in terms of business impact and financial exposure,” he states.

Im Juni 2025 veröffentlichte der prominente britische Softwareentwickler Simon Willison einen in der Security-Community vielbeachteten Blogbeitrag. Darin warnte der Experte, der im Jahr 2022 den Begriff „Prompt Injection“ geprägt hatte, vor einer tödlichen Dreierkombination („Lethal Trifecta“), die ausreichen um einen KI-Agenten mit nahezu hundertprozentiger Erfolgswahrscheinlichkeit durch indirekte Prompt Injection zu kompromittieren. Diese „Lethal Trifecta“ bei KI-Agenten manifestiert sich demnach im:   

• Zugriff auf private Daten,
• dem Kontakt mit nicht vertrauenswürdigen Inhalten, sowie
• der Fähigkeit zur externen Kommunikation.

Ein Angreifer, der schadhafte Anweisungen an beliebiger Stelle in dieser Inhalts-Pipeline einschleust, kann Daten exfiltrieren, ohne dass das überhaupt auffällt. Willison veranschaulichte diesen Punkt in seinem Beitrag mit einer langen Liste realer Exploits in Produktionsumgebungen. Das „tödliche Triple“ fungierte dabei zu einer Zeit als Security-Warnsignal, in der KI-Agenten einen meist eng begrenzten Anwendungsbereich hatten. Die Kombination der oben genannten Fähigkeiten zu vermeiden, schien eine tragfähige Designstrategie.

Das hat sich mittlerweile geändert: Ein kundenorientierter Support-Agent erfasst heute Ticketverläufe und Kundendaten, Benutzernachrichten sowie angehängte Dateien und ruft CRMs, Rückerstattungs-APIs oder Ticketing-Systeme auf. Ebenso lesen und beantworten KI-Agenten E-Mails, verwalten Kalender und Nachrichten. Das sind keine „Edge Cases“, sondern genau die Art von Agenten, nach denen Unternehmen und Privatanwender streben – und auf die die Anbieter hinarbeiten.

Das „tödliche Triple“ als neuer Standard

Ross McKerchar, CISO bei Sophos, bringt das Problem in einem eigenen Blogbeitrag auf den Punkt: „Die Funktionen, die Praktiker tatsächlich wollen, führen unweigerlich in gefährliches Terrain. Das ist keine Fehlkonfiguration, sondern der architektonische Preis für die Nützlichkeit.“

Damit liegt der Security-Entscheider richtig: Ein Agent ohne Zugriff auf private Daten ist nutzlos. Einer, der keine externen Inhalte verarbeiten kann, agiert isoliert. Und ein Agent, der nicht nach außen kommunizieren kann, ist handlungsunfähig. Nimmt man auch nur einen dieser drei Aspekte weg, steht im Ergebnis eher eine Suchleiste als ein KI-Agent. Wenn jede legitime Agentenarchitektur sämtliche Eigenschaften der „Lethal Trifecta“ aufweist, kann diese kein aussagekräftiger Indikator für erhöhtes Risiko mehr sein – sondern ist de facto die Standardkonfiguration. Sie weiterhin als Warnsignal zu betrachten, ist so, als würde man die DNS-Auflösung als Anzeichen für ein kompromittiertes Netzwerk werten. Technisch gesehen trifft das zwar auf einige Threat-Modelle zu, ist aber in jedem realen Deployment allgegenwärtig.

Die Antwort auf diese Situation beschreibt der Sophos-CISO in seinem Blogbeitrag als „Blast Radius Reduction“. Gemeint ist eine realistische operative Philosophie, die die „Lethal Trifecta“ als gegeben akzeptiert. Das wäre ein guter erster Schritt – allerdings stellt sich die Frage, was nach der Akzeptanzphase folgt. Das Security-Team von Meta gelangte zu einer ähnlichen Erkenntnis wie McKerchar, nur aus einer anderen Richtung: Im Oktober 2025 veröffentlichte der Konzern sein „Rule of Two“-Framework. Dieses sieht vor, dass KI-Agenten nicht mehr als zwei der drei Komponenten der „Lethal Trifecta“ aufweisen sollten. Sind alle drei Merkmale vertreten, wird eine menschliche Genehmigung erforderlich. Von der Idee war auch Simon Willison angetan, der das Meta-Framework im November 2025 als den besten praktischen Ratgeber bezeichnete, um sichere Agentensysteme auf LLM-Basis aufzubauen.

Mit Blick auf sein Framework räumt Meta allerdings auch Limitationen ein. Demnach passten diverse populäre Use Cases nicht nahtlos in das Rahmenwerk, wodurch Designs, die auf der „Rule of Two“ aufbauen, dennoch anfällig für Fehler sein könnten. Das ist nur die Bestätigung dafür, dass das Problem die Lösung auf Architekturebene bereits überholt hat. Denn das Ausmaß der Sicherheitslücken ist längst nicht mehr nur theoretischer Natur: So brachte eine Untersuchung des Common Crawl Repositories durch Sicherheitsforscher von Google diverse Prompt-Injection-Angriffe auf öffentlich zugängliche Webseiten ans Licht. Laut Google haben die Angriffsversuche dieser Art zwischen November 2025 und Februar 2026 um 32 Prozent zugelegt. Zwar stellten die Sicherheitsexperten fest, dass deren Reifegrad derzeit noch gering ist. Allerdings weisen sie auch darauf hin, dass der Trend ein klares Signal dafür ist, dass das Interesse der Angreifer zunimmt. Anders ausgedrückt: Das Umfeld, vor dem die „Lethal Trifecta“ einst gewarnt hat, ist zur Realität geworden.

5 Anzeichen für kompromittierte KI-Agenten

Wenn nahezu jeder eingesetzte KI-Agent die Merkmale der „Lethal Trifecta“ aufweist, benötigen Praktiker die richtigen Anhaltspunkte, um kompromittiertes Verhalten vom normalen Betrieb innerhalb eines Systems zu unterscheiden. Das erfordert einen Shift: Weg von Assessments auf Architekturebene und hin zu Behavioral Detection auf Laufzeitebene. Wie nötig dieser Umschwung ist, zeigte sich zuletzt im Januar 2026, als innerhalb von nur fünf Tagen vier verschiedene Exploits gegen populäre KI-Produktivitäts-Tools bekannt wurden. Betroffen waren IBM Bob, Superhuman AI, Notion AI und Claude Cowork. In allen vier Fällen setzten die Angreifer auf indirekte Promp Injection, um Daten zu exfiltrieren. Und zwar über einen Kanal, auf den der jeweilige Agent legitimen Zugriff hatte.

Im Fall von Claude Cowork sorgte ein in ein hochgeladenes Dokument eingebetteter, versteckter Prompt etwa dafür, dass der KI-Agent Dateien über die von Anthropic selbst auf die Whitelist gesetzte API-Domain exfiltrierte – unsichtbar für sämtliche Perimeterkontrollmaßnahmen und nicht von normalem Agentenverhalten zu unterscheiden, bis die Daten bereits gestohlen waren. Die vier Exploits hatten außerdem gemein, dass die „Lethal Trifecta“ Betriebsbedingung war.

Die folgenden fünf Signale können dazu beitragen, kompromittierte KI-Agenten zu erkennen:

• Anomalien bei der Befolgung von Anweisungen: Ein kompromittierter Agent verhält sich in der Regel nicht grundlegend anders als ein intakter – er befolgt Anweisungen. Die Frage ist nur, wessen. Agenten-Aktionen, die keinen plausiblen Bezug zu einer vom Benutzer initiierten Aufgabe haben, sollten deshalb die Alarmglocken schrillen lassen. Ein Agent, der dazu aufgefordert wurde, einen Quartalsbericht zusammenzufassen, dann aber eine DNS-Anfrage an eine unbekannte Domain aussendet, hat sich dazu nicht spontan „entschlossen“ – er wurde dazu veranlasst.
• Tool-Call-Sequenzen, die die erwartete Topologie durchbrechen: In einem gut konzipierten KI-Agentensystem sollte die Sequenz der Tool-Aufrufe für eine spezifische Aufgabe relativ vorhersehbar sein. Ein Programmier-Agent, der einen Bug fixen soll, muss Dateien bearbeiten, Tests ausführen und möglicherweise die Dokumentation überprüfen. Er sollte allerdings nicht auf E-Mail- oder Kalender-APIs zugreifen. Sobald die erwarteten Grenzen eines Workflows in diesem Rahmen überschritten werden, ist deshalb Skepsis angesagt: Solche Tool-Call-Sequenzen sollten als verdächtig markiert werden, selbst wenn jeder einzelne Aufruf für sich genommen legitim erscheint.
• Exfiltration über Kanäle mit geringer Bandbreite: Der klassische Exfiltrationsangriff durch Prompt Injection leitet gestohlene Daten über einen Mechanismus weiter, auf den der Agent legitim zugreift – die URL eines gerenderten Bildes mit verschlüsselten Abfrageparametern, einen API-Call mit Daten, die in einem Parameter eingebettet sind oder einen Link in einem generierten Dokument. Für sich genommen sehen diese Aktionen nicht nach Datendiebstahl aus, sondern wirken völlig normal. Um eine Exfiltration erkennen zu können, sollte geprüft werden, auf welche Daten der Agent Zugriff hatte und was er in seinen Output eingebettet hat. Das erfordert wiederum, dass die Agentenaktionen durchgängig transparent sind – nicht nur der endgültige Output.
• Zugriff auf Anmeldedaten und Secrets außerhalb des Task-Scope: Greift ein Agent mit legitimen Zugriffsrechten auf einen Secrets Store oder einen Key Vault zu, die in keinem Zusammenhang mit dem aktuellen Task stehen, ist das ebenfalls ein Warnsignal. Ein Agent, der einen React-Rendering-Fehler beheben soll, braucht dazu mit Sicherheit keine AWS-Anmeldedaten. Das Least-Privilege-Prinzip dient hier als architektonische Abwehrmaßnahme. Doch erst ein Monitoring, bei dem gezielt überprüft wird, ob „out of scope“ auf Login-Daten zugegriffen wird, kann solche Abläufe zu Tage fördern.
• Anomalien bei Memory-Write-Vorgängen: Agenten mit persistentem Speicher stellen eine wachsende Angriffsfläche dar. Ein manipulierter Memory-Eintrag, der wie legitimer Benutzerkontext aussieht, könnte versteckte „Trigger Instructions“ enthalten, die Session-übergreifend erhalten bleiben und erst lange nach der eigentlichen Prompt Injection ausgelöst werden. Dagegen hilft, die Observability-Pipeline für KI-Agenten entsprechend auszugestalten: Memory-Schreibvorgänge sollten auf befehlsähnliche Inhalte überwacht werden. Ebenso müssen Schreibvorgänge, die im Rahmen von Sessions mit nicht-vertrauenswürdigen Inhalten stattgefunden haben, kritisch beäugt werden.

Für Security-Praktiker, die eine Agentic-AI-Infrastruktur im Produktivbetrieb managen, bestätigt die Entwicklung der „Lethal Trifecta“ zum neuen Standard nur das, was Sie ohnehin längst wissen: Ihre KI-Agenten sind gefährdet. Dieser Herausforderung ist auf Ebene der Runtime zu begegnen, nicht auf Architekturebene. Dort sind für traditionelle Architekturen EDR und SIEM angesiedelt. KI-Agenten benötigen dieselbe Instrumentierung – was auf die allermeisten Deployments bislang nicht zutrifft. (fm)

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

The RAM price crisis is pushing hardware manufacturers to pursue deals with Chinese companies, against the wishes of the US government. Apple is one of those reportedly exploring such deals.

“Apple is in negotiations to purchase chips from Chinese semiconductor makers ChangXin Memory Technologies Inc. (CMTI) and Yangtze Memory Technologies Co. (YMTC) to help reduce the impact of a global memory shortage,” Bloomberg reported. “The companies are on a Pentagon blacklist of Chinese entities believed to support Beijing’s military, and Apple’s effort to buy chips from them has included appeals to Trump administration officials to help soften the political fallout,” it said.

Rumors surrounding Apple talking with CMTI and YMTC have been going on for months, with analyst Ming-Chi Kuo pointing to Apple CEO Tim Cook being “one of the few tech leaders who can still navigate both Washington and Beijing, so this is better handled before he steps down as CEO.”

Beyond the potential political ramifications, any deal would have immediate implications for enterprise IT buyers.

“CIOs should focus on the risk that this strategy could introduce. Will Apple be able to thoroughly assess those chips to completely rule out the possibility of trojan horses, backdoors, and hidden functionality such as dead man switches?” asked Flavio Villanustre, CISO for the LexisNexis Risk Solutions Group. “If Apple says that they will do, to what degree of certainty? There have been rumors about hidden backdoors in chips before, such as Supermicro in 2018, ESP32 microcontroller hidden functionality in 2025, and Microsemi backdoor in 2012, to name a few.”

On the naughty list?

This issue gets complicated based on what the US government ultimately does. The two Chinese manufacturers figure on the Pentagon’s so-called 1260H list of “entities identified as Chinese Military Companies,” which also includes Chinese internet giants Alibaba, Baidu, and Tencent; router maker TP-Link Technologies; and drone maker DJI. Being on that list has no real consequences for the companies concerned, but the government could move them to the Department of Commerce’s Entity List, subjecting them to export licensing requirements, or make them the subject of a Section 889 clause, barring them from government procurement deals. That could sharply change the dynamics for Apple and other technology vendors seeking cheaper RAM supplies — and for their customers.

Noah Kenney, principal consultant for Digital 520, said, “Currently, CXMT is only on the Pentagon’s 1260H list, which doesn’t legally bar transactions. Inclusion in the Commerce Department Entity List placement would, which is what Apple is seeking to prevent here.”

He suggested Apple might try to limit blowback by only using the Chinese chips in Apple devices sold in China.

If the government does intensify restrictions and if components from YMTC or CXMT “show up in a customer contract you already signed, a standard-issue device becomes a procurement compliance question. Fleet inventory in MDM will need to track memory sourcing, not just device model. That is a capability most enterprises do not have today,” Kenney said. “The real question for a CIO is not whether Washington pushes back on Apple, but whether their customers will push back for shipping Apple.”

Other vendors use Chinese RAM already

“Lenovo has sourced from Chinese memory makers for years,” as have other manufacturers, Kenney said. “The difference is that they are not lobbying the Treasury Secretary about it.”

Geopolitical analyst Irina Tsukerman said Apple could clear the way for more vendors to use cheaper RAM.

“If Apple absorbs the political criticism and keeps enterprise buyers comfortable, competitors would gain room to consider Chinese memory for selected markets or less sensitive product channels,” Tsukerman said. “If Washington turns Apple into an example, other manufacturers would become more careful around government-facing sales and reserve this kind of sourcing for places where US procurement pressure has less impact.”

Tsukerman agreed with Kenney that IT departments will need to improve component visibility.

“Enterprise CIOs should take this seriously because Apple’s reported sourcing discussions turn a normally invisible component decision into something that can affect procurement credibility, especially for buyers whose technology choices are reviewed through government or regulated-sector requirements,” Tsukerman said.

The lack of a clear product quality issue is what will make this a delicate IT dance, Tsukerman said.

“Engineers could see limited practical danger from memory sourcing alone, and procurement reviewers could still see a serious issue because the supplier has already been placed in a national-security category,” she said.

The RAM price crisis is pushing hardware manufacturers to pursue deals with Chinese companies, against the wishes of the US government. Apple is one of those reportedly exploring such deals.

“Apple is in negotiations to purchase chips from Chinese semiconductor makers ChangXin Memory Technologies Inc. (CMTI) and Yangtze Memory Technologies Co. (YMTC) to help reduce the impact of a global memory shortage,” Bloomberg reported. “The companies are on a Pentagon blacklist of Chinese entities believed to support Beijing’s military, and Apple’s effort to buy chips from them has included appeals to Trump administration officials to help soften the political fallout,” it said.

Rumors surrounding Apple talking with CMTI and YMTC have been going on for months, with analyst Ming-Chi Kuo pointing to Apple CEO Tim Cook being “one of the few tech leaders who can still navigate both Washington and Beijing, so this is better handled before he steps down as CEO.”

Beyond the potential political ramifications, any deal would have immediate implications for enterprise IT buyers.

“CIOs should focus on the risk that this strategy could introduce. Will Apple be able to thoroughly assess those chips to completely rule out the possibility of trojan horses, backdoors, and hidden functionality such as dead man switches?” asked Flavio Villanustre, CISO for the LexisNexis Risk Solutions Group. “If Apple says that they will do, to what degree of certainty? There have been rumors about hidden backdoors in chips before, such as Supermicro in 2018, ESP32 microcontroller hidden functionality in 2025, and Microsemi backdoor in 2012, to name a few.”

On the naughty list?

This issue gets complicated based on what the US government ultimately does. The two Chinese manufacturers figure on the Pentagon’s so-called 1260H list of “entities identified as Chinese Military Companies,” which also includes Chinese internet giants Alibaba, Baidu, and Tencent; router maker TP-Link Technologies; and drone maker DJI. Being on that list has no real consequences for the companies concerned, but the government could move them to the Department of Commerce’s Entity List, subjecting them to export licensing requirements, or make them the subject of a Section 889 clause, barring them from government procurement deals. That could sharply change the dynamics for Apple and other technology vendors seeking cheaper RAM supplies — and for their customers.

Noah Kenney, principal consultant for Digital 520, said, “Currently, CXMT is only on the Pentagon’s 1260H list, which doesn’t legally bar transactions. Inclusion in the Commerce Department Entity List placement would, which is what Apple is seeking to prevent here.”

He suggested Apple might try to limit blowback by only using the Chinese chips in Apple devices sold in China.

If the government does intensify restrictions and if components from YMTC or CXMT “show up in a customer contract you already signed, a standard-issue device becomes a procurement compliance question. Fleet inventory in MDM will need to track memory sourcing, not just device model. That is a capability most enterprises do not have today,” Kenney said. “The real question for a CIO is not whether Washington pushes back on Apple, but whether their customers will push back for shipping Apple.”

Other vendors use Chinese RAM already

“Lenovo has sourced from Chinese memory makers for years,” as have other manufacturers, Kenney said. “The difference is that they are not lobbying the Treasury Secretary about it.”

Geopolitical analyst Irina Tsukerman said Apple could clear the way for more vendors to use cheaper RAM.

“If Apple absorbs the political criticism and keeps enterprise buyers comfortable, competitors would gain room to consider Chinese memory for selected markets or less sensitive product channels,” Tsukerman said. “If Washington turns Apple into an example, other manufacturers would become more careful around government-facing sales and reserve this kind of sourcing for places where US procurement pressure has less impact.”

Tsukerman agreed with Kenney that IT departments will need to improve component visibility.

“Enterprise CIOs should take this seriously because Apple’s reported sourcing discussions turn a normally invisible component decision into something that can affect procurement credibility, especially for buyers whose technology choices are reviewed through government or regulated-sector requirements,” Tsukerman said.

The lack of a clear product quality issue is what will make this a delicate IT dance, Tsukerman said.

“Engineers could see limited practical danger from memory sourcing alone, and procurement reviewers could still see a serious issue because the supplier has already been placed in a national-security category,” she said.

This article first appeared on Network World.

Microsoft this week tried to address the growing challenges surrounding notetaker bots in meetings by giving IT better control over them.

Microsoft’s announcement said that users of Microsoft Teams will be able to block non-Microsoft bots “even in meetings where organizers allow participants to bypass the lobby.”

When the feature is enabled, Teams automatically detects potential bots, places them in the meeting lobby, clearly identifies them, and prompts organizers to confirm admission, Microsoft said, and even in meetings where organizers allow human participants to bypass the lobby, bots identified through this new policy will continue to require approval before joining.

“We’ve strengthened Teams’ ability to distinguish between bots and human participants as they join a meeting,” the company said. “Teams now uses a combination of behavioral and infrastructure signals to identify bots with a higher degree of accuracy. Alongside these improvements, soon we’ll introduce a registration path for independent software vendors (ISVs) that build meeting experiences for Microsoft Teams.”

The underlying problem with the strategy is more complicated, however. Although AI bots launched by the meeting owner are typically announced at the beginning of a call, and participants’ bots announce themselves as the attendees log in, alert fatigue is diluting how carefully people watch what they say during those meetings.

But the thornier issue is that meeting owners’ approval of their own bot notetakers typically happens right before the start of a call, and the host has no control over whether participants also introduce their own AI notetakers.

And even if the intended topic of a call was innocuous, if someone brings up something that needs to be kept secret, such as plans for a hostile takeover or discussion about firing an employee, that is duly recorded by every bot. This expands the threat surface and increases the ways sensitive data could leak.

Doesn’t rein in Microsoft bots

Analysts and consultants agreed that any effort to restrict notetaking apps is good for enterprise IT, but some questioned whether the Microsoft effort went far enough.

“Although this new capability is useful to prevent external bots from attending recurring meetings even if they were needed for just one instance, it doesn’t seem to me that it does anything to prevent Microsoft’s own bots from doing so,” said Flavio Villanustre, CISO for the LexisNexis Risk Solutions Group. 

Indeed, the Microsoft statement solely talks about managing “external bots and their access to meetings.”

In fact, Gartner VP analyst Nader Henein said the limited controls that Microsoft is offering may actually dilute IT’s ability to control access to sensitive information.

Allowing any additional AI notetaking “takes the option to restrict/redact off the table,” and that control is what he thinks IT leaders should demand. The only practical way to do that is to allow only one notetaking app for any meeting and it needs to be controlled by the meeting owner.

“Allowing attendees to ask for an AI summary from the meeting owner and giving the owner the capacity to provide different versions that potentially shield sensitive data is a better choice for organizations looking to support better meeting follow ups without adding more work on the meeting owner,” Henein said. “It could even be set up in advance so a ‘sanitized’ summary is available for download.”

Tom Findling, CEO of Conifers.ai, agreed with Henein and argued that these notetaking app controls have to be centralized with IT.

“Microsoft basically built a bouncer for meeting bots and that is a good thing. But the real risk shows up later, when a normal meeting turns into M&A, legal, HR, or board-level discussion while an AI notetaker is still running,” Findling said. “Now that transcript may be sitting in a cloud nobody approved. You do not fix that live. You fix it upfront. For legal, finance, HR, and exec meetings, external AI notetakers should be blocked by default unless explicitly approved.”

Existing governance not enough

Sanchit Vir Gogia, chief analyst at Greyhound Research, said the slowly changing nature of AI notetakers has allowed them to slip by IT governance rules.

“A meeting note was once a harmless aid. It is now a searchable corporate record that can hold intent, allegations and material non-public information. Once a conversation is transcribed and saved, it has left the room, and it begins to travel through mail, search, and discovery with a life of its own,” Gogia said. “Microsoft’s control is useful, but should not be oversold. It detects external bots and puts them before an organizer for approval. It does not yet block them, and approval at the lobby is not a governance model. Capture also arrives by routes the lobby never sees, through browser extensions and personal devices.”

Gogia also argued that the inevitable errors in these bot-generated transcripts or summaries, whether caused by hallucination or simply incorrect interpretation what was actually said, is also a massive risk.

“AI summary does not merely create a record. It creates an authoritative-looking one that is often wrong and, in doing so, it inverts the burden of proof. Once a summary exists, the question shifts from proving what was said to disproving what the machine wrote,” Gogia said. “A tentative ‘we should look at acquiring them’ can harden into ‘we agreed to acquire them’ and that version becomes the default until someone corrects it.”

And, noted Justin Greis, CEO of consulting firm Acceligence, the problem will only get worse as AI summary generators morph into agentic systems, with action-taking autonomous agents.

“Over the next few years, we’ll see AI agents that summarize, extract decisions, assign work, update business systems, prepare follow-up documents, and collaborate with other AI systems after the meeting ends,” he said. “In fact, we are already seeing that integration happen, and it is simultaneously incredibly valuable and outrageously risky. The real question isn’t whether to allow an AI notetaker. It’s how organizations will govern an increasingly machine-readable workplace.”

Greis said that he sees the Microsoft approach as a good start, “because they’re treating AI participants more like digital identities than software features.”

He pointed out, “detection, verification, explicit admission, auditability, and policy-based control are exactly the kinds of enterprise controls we’ll need as AI agents become commonplace. This feels very similar to identity and access management twenty years ago. We eventually realized we weren’t managing employees, we were managing identities. AI agents deserve the same treatment.”

Oft liefern kompromittierte Endgeräte die lediglich angelehnte Hintertür, durch die Ransomware ins Unternehmen schlüpft. Gartner-Analysten raten deshalb zu unveränderbaren Endpunkten. Igel Technology liefert dafür eine solche Architektur – und neuerdings zudem schnelle Hilfestellung für gekaperte Windows-Clients.

Das Bremer Unternehmen behauptete sich einst im Bereich Thin Clients gegen Größen wie HP und Dell, Ende 2022 verkündete Igel dann, keine TCs mehr zu produzieren, sondern Hardware von Partnern wie HP, Lenovo und LG zu nutzen.

Denn Igel hatte erkannt: Die eigentliche Stärke liegt im angriffsresistenten, weil stark abschottbaren Linux-Betriebssystem Igel OS samt zentraler Verwaltung per zugehöriger Universal Management Suite (UMS). Seither arbeitete das Unternehmen, ab 2023 unter der Führung des in den USA lebenden Dänen Oestermann, daran zum zum Anbieter einer, so Igel, „Adaptive Secure Endpoint Platform“ zu werden. Diese Plattform setzt, so eine weitere Igel-Formulierung, das „Preventative Security Model“ um, soll also Kompromittierung a priori verhindern.

Igels erweiterbare Endpunkt-Plattform

Hierfür ist das Igel OS in schönster Thin-Client-Tradition auf das Nötigste reduziert, gehärtet und somit hochgradig manipulationsresistent. In Kombination mit rein serverseitiger Datenhaltung scheint dies heute nützlicher denn je. Denn Ransomware-Angriffe haben sich, wie einst die Kaninchen in Australien, zur regelrechten Landplage entwickelt. Und Security-Fachleute warnen allerorts, dass Cyberkriminelle verstärkt KI nutzen, um ihre Angriffe weiter zu automatisieren, zu skalieren und zu beschleunigen.

Die Analysten von Gartner bestätigen die neue Strategie von Igel. „Endpunkte sind die am stärksten fragmentierte, poröse Oberfläche einer Organisation“, schreiben die Marktforscher in einem Papier vom Februar 2026, dessen Titel auch gleich einen Ausweg weist: „Nutzen Sie unveränderbare Endpunkte, um Ransomware zu besiegen, Konfigurationsabweichungen zu stoppen und schnelle Wiederherstellung zu garantieren“. Denn „veränderliche, agentenlastige Endpunkte“ – vulgo Windows-PCs – seien das Haupteinfallstor für Angriffe, so die Analysten.

Unveränderliche Endpunkte hingegen, so Gartner-Analyst Franz Hinner und seine Co-Autoren, könnten die Angriffskette durchbrechen und Persistenz der Angreifer im Netzwerk für langfristige oder wiederholte Angriffe verhindern. Indem sich die Sicherheitskontrollen vom Endgerät auf die Identität verlagerten, so die Marktforscher, ließen sich die Ausfallzeiten der Mitarbeiter um 98 Prozent senken.

Eben dieses Konzept verfolgt Igel mit der „Adaptive Secure Endpoint Platform“, die esüber offene APIs erlaubt, Drittanbieterlösungen zu integrieren. Rund 130 Partner zählt man inzwischen, so die Bremer, darunter Identity-Security-Anbieter wie Okta, Imprivata und Microsoft (mit Entra ID) sowie diverse weitere Security-Größen, mit deren Hilfe Igel Zero-Trust-Architekturen umzusetzen kann.

Doch Igel verlässt sich längst nicht nur auf seine Partner: Auch das hauseigene Entwicklungsteam unter der Leitung von General Manager und CTO Matthias Haas treibt die Softwareentwicklung eifrig voran. Hierfür unterhält Igel heute neben dem Stamm-Entwicklungsstandort Augsburg weitere in Bukarest, Bangalore und Fort Lauderdale, USA. Federführend ist jedoch weiterhin die deutsche Lokation.

Bei einer Kundenveranstaltung in Frankfurt präsentierte Igel kürzlich zahlreiche Erweiterungen seiner Plattform. Hierzu zählen unter anderem:

• kontextbezogene Zugriffskontrollen, ermöglicht durch die Kooperation mit Security-Partnern;
• ein Managed Hypervisor inklusive der Option, auf den TCs Published Apps lokal laufen zu lassen;
• Managed Container (wichtig für das Industrieumfeld);
• Unterstützung für ARM-Prozessoren.

Und natürlich darf das Thema KI nicht fehlen: Igel AI Armor soll die KI-Nutzung absichern, MCP-Support sei hierfür in Arbeit.

Eine pfiffige Lösung ist „Igel Business Continuity & Disaster Recovery“. Die Funktionsweise: Ein Windows-Endpunkt läuft virtualisiert auf Igel OS. Im Notfall, etwa bei einem Ransomware-Angriff, müssen die Anwender nur die F9-Taste drücken. Dies führt zum Neustart samt Auswahl, ob man den Windows-Rechner oder das abgesicherte Igel OS starten möchte. Neben diesem Dual Boot gibt es, etwa für Industrie-PCs, auch eine USB-Boot-Option.

Dadurch, so Igel, seien Unternehmen in Minuten wieder arbeitsfähig. Oder konkret ausgedrückt: Anwender können gehostete und SaaS-Applikationen wie Windows 365 weiter nutzen und bleiben damit zumindest im Kern handlungsfähig. Das Windows-OS liegt dabei für Forensik-Zwecke weiterhin unangetastet vor. Die Lösung erweist sich laut CEO Klaus Oestermann als „Türöffner“ für die Neukundengewinnung, ebenso beim Ausbau bestehender Installationen.

Igel-Vorteile für Kliniken und die Industrie

Wie Igel anhand mehrerer Kundenszenarien veranschaulichte, bieten unveränderliche, zentral verwaltete Endpunkte auch jenseits von Malware-Schutz und Resilienz im Angriffsfall Vorteile.

So brauchten die PCs des britischen NHS Gloustershire Hospitals früher laut Igel-Angaben 30 Minuten bis zum erfolgten Login. Mitarbeiter riefen deshalb vom Arbeitsweg aus an und baten einen Kollegen, sie mit ihrem Passwort einzuloggen, damit sie bei Ankunft schnell arbeitsfähig sind – das Gegenteil von Nutzerfreundlichkeit und ein Alptraum für jeden CISO.

Mit Igel OS und der Access-Management-Lösung Imprivata dauere der Login nun nur noch eine Minute, berichteten die Bremer, ein erneuter Login wenige Sekunden. Ein Arzt auf Visite müsse sich also nicht mehr minutenlang vom Patienten abwenden, um mit dem PC zu kämpfen, sondern könne sich schnell wieder der Behandlung widmen.

Hierzulande setzen laut Peter Goldbrunner, Vice President und General Manager Central Europe bei Igel, rund 300 Kliniken auf Igel OS. Auch sonst wachse das Geschäft in Deutschland ebenso schnell wie das internationale Business – und das vom hohen Niveau des Stammlandes aus betrachtet.

So betreibe nun etwa Aldi Nord die Steuerung der Backautomaten in seinen Filialen mittels zentral verwalteter Igel-OS-Endpunkte. In der Industrie wiederum, so Goldbrunner, nutze beispielsweise Audi inzwischen Steuerungsrechner mancher Produktionsanlagen virtualisiert auf Igel-OS-Endpunkten statt wie bislang Industrie-PCs. Damit sollen sich die Industriesteuerungen selbst dann zügig weiterbetreiben lassen, wenn wie letztes Jahr bei Jaguar Land Rover Cyberangreifer zuschlagen sollten – ohne dass ein Techniker vor Ort eingreifen muss.

Laut Emanuel Pirker, Ex-Chef des 2025 von Igel akquirierten TC-Herstellers Stratodesk und nun verantwortlich für den Contact-Center-Bereich, können Igel-OS-Endpunkte im Call- oder Contact-Center die Kosten deutlich senken. Das Onboarding neuer Mitarbeiter sei in fünf Minuten erledigt – wichtig in einer Branche mit extrem hoher Personalfluktuation. Datensicherheit und Compliance seien gewahrt, da keine Daten auf den Endpunkten gespeichert werden. Zudem sinken laut Pirker die Betriebskosten durch längere Hardware-Lebenszyklen, weniger Update-Bedarf und einfacheres Management. UMS ist hierfür auf Wunsch „as a Service“ erhältlich, auch aus einem Rechenzentrum im EU-Rechtsraum. (mb)

Detection engineering, which was once a niche practice among mostly large companies, appears to have evolved into a capability that organizations across industries now consider essential to their security operations.

What is detection engineering?

Detection engineering is about creating and implementing systems to identify potential security threats within an organization’s specific technology environment without drowning in false alarms. It’s about writing smart rules that can tell when something potentially suspicious or malicious is happening in an organization’s networks or systems and making sure those alerts are useful. The process typically involves threat modeling, understanding attacker TTPs, writing, testing and validating detection rules, and adapting detections based on new threats and attack techniques.

A small survey of 264 cybersecurity professionals by the SANS Institute and Anvilogic found that 80% of organizations — and 85% of large enterprises — are actively investing in detection engineering, with 60% now having dedicated teams. More than two-thirds (67%) reported strong leadership support for the practice within their organization.

The survey’s data suggested that many companies have not just merely adopted detection engineering practices but have made it a strategic focus of their cyber risk mitigation effort.  “Just a decade ago, detection engineering was a relatively unknown role in cybersecurity,” the report stated. “Now, it is emerging as one of the most critical roles in security operations.”

More than the usual threat detection practices

Proponents argue that detection engineering differs from traditional threat detection practices in approach, methodology, and integration with the development lifecycle. Threat detection processes are typically more reactive and rely on pre-built rules and signatures from vendors that offer limited customization for the organizations using them. In contrast, detection engineering applies software development principles to create and maintain custom detection logic for an organization’s specific environment and threat landscape. Rather than relying on static, generic rules and known IOCs, the goal with detection engineering is to develop tailored mechanisms for detecting threats as they would actually manifest in an organization’s specific environment.

Often this involves a stronger emphasis on behavior-based detections, the integration of threat intelligence to create detections aligned with real-world adversary tactics and the use of threat modeling to anticipate potential attack paths, says Heath Renfrow, CISO and co-founder of Fenix24 a cyber disaster recovery firm. “Unlike conventional threat detection, which often relies on static signatures and pre-built rules, detection engineering is behavior-driven, context-aware, and tailored to an organization’s unique threat landscape,” Renfrow says. “It involves a blend of security operations, threat intelligence, and data science to build more adaptive and resilient detection capabilities.”

The SANS-Anvilogic report describes detection engineering practices as evolving over the years from being over-reliant on vendor-specific consoles and proprietary languages to incorporate software development life cycle (SDLC) and continuous integration/continuous deployment (CI/CD) principles. This is enabling teams to test, deploy, and refine detections more efficiently while maintaining auditable trails of changes.

Drivers of detection engineering’s adoption

There are a couple of factors driving adoption of detection engineering practices. The biggest is the fact that out-of-the-box detections aren’t good enough. They don’t baseline the environment, they don’t drive down false positives and, troublingly, they don’t always alert on the things that matter, says Johnathon Miller, vice president of security operations at Lumifi Cyber.

Generic alerts that don’t account for organizational context have become a major problem and a contributor to false positive fatigue within many security teams. Sixty-four percent of organizations in Anvilogic’s survey for instance, reported high false positive rates; 61% struggled with detections that lacked environmental accuracy; and 34% said they had encountered delays in updates and improvements.

“Traditional threat detection methods historically have been static; if a=a, create an alert,” says Kevin Gonzalez, VP of security, operations and data, Anvilogic. “They are often rigid, black-box mechanisms that lack flexibility in customization. Though useful to some extent, these approaches become unmanageable at scale especially in organizations with hybrid environments,” he says.

Growing threat volumes and sophistication are another issue. Attackers are using more advanced and evasive techniques — including fileless malware, living off the land approaches, zero-day exploits and attacks via the software supply chain — rendering signature-based detection largely insufficient. Rising cloud adoption has introduced new vulnerabilities as well and created blind spots that legacy detection methods often struggle to cover. 

The rise in advanced persistent threats (APTs), supply chain attacks, and ransomware operations has made traditional reactive approaches insufficient, Renfrow says. “Organizations now realize that proactive detection engineering reduces dwell time, improves response capabilities, and enhances overall cyber resilience. Additionally, compliance frameworks and cyber insurance providers are increasingly emphasizing strong detection strategies.”

Industries adopting detection engineering

Organizations in the banking and finance sector, the technology industry, cybersecurity companies and, to a lesser extent, healthcare companies are among the leading adopters of detection engineering practices. Many are in sectors that must deal with regulatory scrutiny or are frequent targets of sophisticated threat actors. But the reality is that most organizations, especially larger ones, can benefit from implementing a systematic approach to developing detection mechanisms for their specific threat profile.

Any large enterprise with a complex IT infrastructure can benefit from detection engineering. Security operations centers (SOCs) need to continuously improve and maximize their detection posture. “Along with the evolving threat landscape, their own internal IT infrastructures are constantly changing, which can result in detection ‘drift,’ where detection rules are broken and will no longer fire or alert,” CardinalOps CEO Michael Mumcuoglu says.

Security experts point out some key requirements for setting up a detection engineering capability. The biggest among them is data. To succeed, detection engineering teams need access to logs and security event data from endpoints, networks, cloud environments, and security tools and a centralized SIEM or log management platform to aggregate and normalize the security data. An effective detection engineering capability also means having skilled personnel including detection engineers, analysts, and threat researchers, to develop and refine detection rules. Also important are formal processes for threat modeling, testing and integrating threat intelligence with incident response.

The goal should be to move beyond static signatures and focus on how attackers operate, by prioritizing behavior-based threat detection. Use frameworks like MITRE ATT&CK to map detection coverage against known adversary techniques and utilize adversary emulation tools like Atomic Red Team to validate effectiveness, Renfrow says. “Detection engineering works best when security operations, threat intelligence, and IT teams work together,” Renfrow notes.

How AI and automation can help

AI/ML can play a key role in rule tuning and automation as well. Some 45% of the survey respondents described their organizations as using AI in their detection engineering programs for purposes like anomaly detection, rule generation and alert triage. Nearly nine in 10 (88%) believed AI would have a big impact on their detection engineering programs in the next three years. “One of [AI’s] strongest use cases is analyzing vast amounts of data to identify anomalies, particularly when utilizing a custom-trained language model,” says Glenn Thorpe, senior director of security research and detection engineering at GreyNoise Intelligence. “Depending on an organization’s threat model and risk tolerance, employing AI with a well-trained LLM can significantly enhance the effectiveness and efficiency of defenders within the organization.”

AI is not the only change. More organizations are also adopting automated processes for detection engineering. The areas that organizations are automating include mapping detection coverage to the MITRE ATT&CK framework, identifying broken or misconfigured detections, and being able to operationalize threat intelligence and convert it into actionable detection rules, Mumcuoglu says. Ninety-three percent of Anvilogic’s survey respondents reported they are currently using or plan to use automation in their detection engineering workflow for rules development, tuning existing detections and threat hunting.

Thorpe cautions against organizations looking for some kind of one-size-fits-all approach to standing up a detection engineering capability. “Instead, a creative mindset, diversity of thoughts and experiences, and curiosity are vital for building an effective team.”

A good place to start is by identifying your organization’s core data and finding individuals who can analyze that data from multiple perspectives. Develop a realistic understanding of what you don’t know and begin to address those information gaps. “You might discover that small changes can significantly improve your visibility and understanding of network traffic,” Thorpe notes.

Nach jahrelanger Erfahrung mit der Cloud glaubten IT-Führungskräfte, ihre Strategien diesbezüglich endlich fest im Griff zu haben. Dann kam die KI.

Die aktuellen Herausforderungen rund um die Cloud gehen jedoch weit über künstliche Intelligenz hinaus. Dazu zählen neben der Frage, wo Workloads für maximale Effizienz platziert werden sollten, auch Governance-Anforderungen, Datensouveränität, zunehmend ausgefeilte Cyberbedrohungen und steigender Kostendruck. All diese Faktoren machen die Cloud-Landschaft immer komplexer.

Mehr als ein Infrastrukturthema

„Das Ganze hat sich zu einem ziemlich komplexen Durcheinander entwickelt“, stellt der Cloud-Experte David Linthicum fest. Eine moderne Cloud-Strategie müsse heute Private Clouds, Multi-Cloud-Umgebungen, Hybrid-Cloud-Modelle und souveräne Clouds berücksichtigen – deutlich mehr, als die meisten CIOs bislang bewältigen mussten.

Anfangs drehten sich die Diskussionen rund um Cloud vor allem um Agilität, Skalierbarkeit und Kostenoptimierung, erklärt Joshua Bellendir, CIO des Einzelhändlers WHSmith North America. „Heute müssen wir eine wesentlich größere und komplexere Zahl von Faktoren berücksichtigen: KI-Bereitschaft, Cybersicherheit, Data Governance, Anforderungen an die Datensouveränität, Edge Computing, Integrationsarchitekturen und operative Resilienz.“

Eine der größten Veränderungen bestehe darin, dass die Cloud nicht mehr nur ein Infrastrukturthema sei, so Bellendir. „Sie ist inzwischen eng mit Unternehmensarchitektur, Business Transformation und Datenstrategien verknüpft.“

Auch Amit Basu, Vice President, CIO und CISO bei International Seaways, beobachtet zunehmende Komplexität. „Zwar gelten die Vorteile geringerer Investitionskosten und höherer Flexibilität in vielen Bereichen weiterhin, doch das Management der Cloud-Umgebung ist deutlich anspruchsvoller geworden.“, erklärt er.

Jason Johnson, CIO des Musikinstrumentenhändlers Sweetwater, beschreibt die aktuelle Situation als eine der komplexesten Phasen überhaupt für das Cloud-Management. Die Anbieter erweiterten ihre Portfolios kontinuierlich um neue Services, Produktvarianten und Optionen.

„Das schafft zwar zusätzliche Möglichkeiten, verursacht aber auch erheblichen Aufwand, um den Überblick zu behalten. Man braucht Fachkräfte, die nicht nur wissen, was verfügbar ist, sondern auch beurteilen können, welche Lösung für den jeweiligen Anwendungsfall die richtige ist“, meint der IT-Entscheider.

Viele Unternehmen würden inzwischen in eine zweite Phase ihrer Cloud-Reife eintreten, nachdem sie in der ersten Phase den Fokus auf Migration und Modernisierung gelegt hätten, erklärt Johnson. „Heute geht es stärker um Optimierung, Governance, KI-Unterstützung und nachhaltigen Betrieb. Dieser Wandel verändert die Diskussionen, die ich mit CIOs führe, grundlegend.“

Die wenigsten CIOs können es sich jedoch leisten, lange über ihre nächsten Schritte nachzudenken. Sie müssen den Herausforderungen zunehmend komplexer werdender Cloud-Strategien aktiv begegnen.

Wie KI die Cloud-Gleichung verändert

„Der Wunsch, KI möglichst schnell einzuführen, setzt IT-Verantwortliche erheblich unter Druck. Dabei spielt die Cloud eine zentrale Rolle“, führt Linthicum aus. „Die Aufsichtsräte treiben das Thema noch stärker voran als den Cloud-Boom vor 15 Jahren“, erklärt er. CIOs spüren diesen Druck und müssen so schnell wie möglich handeln, um zusätzliche Rechenkapazitäten für KI-Initiativen bereitzustellen – und das in einem ohnehin schon komplexen Umfeld.“

Gleichzeitig müssten CIOs das Problem der Datenkomplexität lösen, bevor KI-Systeme erfolgreich integriert werden können, betont der Cloud-Experte. „Derzeit drehen sich viele im Kreis und versuchen herauszufinden, welcher Ansatz dafür der Beste ist.“

Hyperscaler galten früher als der einfache Weg, so Linthicum, könnten aber drei- bis viermal so teuer werden. KI-Systeme kosten seiner Einschätzung nach etwa zehnmal so viel wie vergleichbare, traditionelle Anwendungen.

Basu von International Seaways erklärt, dass KI die Diskussion über die IT-Architektur grundlegend verändert habe. „Die Verfügbarkeit von GPUs, Vektordatenbanken, Inferenz mit geringer Latenz und groß angelegte Datenpipelines bringen Anforderungen mit sich, die sich nicht nahtlos in herkömmliche Cloud-Designmodelle einfügen“, merkt er an. Unternehmen verlagern Workloads nicht mehr einfach nur in die Cloud. Sie entwerfen Architekturen für völlig andere Rechen- und Datenanforderungen.“

Laut Zachary Lewis, CIO und CISO der University of Health Sciences and Pharmacy, verstärkten die Bedürfnisse interner Stakeholder diese Komplexität noch. „Geschäftsbereiche wünschen sich unterschiedliche KI-Fähigkeiten, Sicherheitsteams wollen Governance und eine gewisse Kontrolle über KI-Anwendungen, der Justiziar möchte wissen, welche Art von Daten in das KI-Modell eingespeist werden, und das Finanzteam erwartet Kostenvorhersehbarkeit. CIOs müssen all dies unter einen Hut bringen – und das erfolgreich versteht sich“, so Lewis.

Seit der Online-Händler für Musikinstrumente und professionelle Audiotechnik Sweetwater seine Cloud-Strategie um das Jahr 2016 formalisiert hat, versucht Johnson, Workloads dort zu platzieren, wo sie für externe und interne Kunden den größten Nutzen bringen.

„Alles mit Kundenkontakt muss so nah wie möglich am Endnutzer ablaufen“, erklärt er. Die gleiche Logik gilt auch für interne Workloads: Sie gehören in die Nähe derjenigen, die sie nutzen. KI wäre ohne die Cloud nicht möglich. Die für KI erforderliche Rechenkapazität war bereits vorhanden – die Cloud verfügte darüber und konnte sie bereitstellen. In vielerlei Hinsicht ist KI vielleicht das größte Geschenk der Cloud an die Branche. Beide haben sich gegenseitig ermöglicht“, fügt der Manager hinzu.

Cloud-Kostenmanagement wird immer komplexer

Johnsons größtes Problem ist die konsistente Steuerung der Kosten. „Früher war es relativ einfach: Rechenleistung, Speicher, Datenverkehr. Heute ist es ein Puzzle. Reservierte Instanzen, Sparpläne, Spot-Preise, Kosten pro Anfrage, Gebühren für Datenübertragungen zwischen Regionen – das summiert sich schnell. Und es ist wirklich schwer vorherzusagen, wie Ihre Rechnung aussehen wird, bis sie eintrifft.“

Deshalb sei FinOps inzwischen zu einer eigenen Disziplin geworden.

Auch Basu hält FinOps für unverzichtbar. „Kosten für KI-Inferenz, Datenübertragungen und wachsende Speichermengen können monatliche Kostenschwankungen verursachen, die selbst erfahrene Teams überraschen“, führt er aus. Kostenmanagement ist heute eine kontinuierliche operative Disziplin und nicht mehr nur eine gelegentliche Überprüfung.“

Auch die Gefahr des Vendor Lock-in beschäftigt Johnson ständig. „Je tiefer man die nativen Dienste eines Anbieters integriert, desto schwieriger wird ein Wechsel. Das ist nicht zwangsläufig schlecht, aber ein Kompromiss. Ich sehe das wie technische Schulden. Man gewinnt heute Geschwindigkeit und zahlt später Zinsen, wenn man die Richtung ändern möchte.“

Gleichzeitig erkennt Johnson an, dass Cloud-Anbieter Unternehmen sind, die auf Umsatz und Marge achten und regelmäßig die Regeln für Rabatte und Kostenmodelle ändern.

Finanzielle Effizienz entstehe nicht von selbst, betont er: „Das erfordert Teams, Prozesse und echte Investitionen in FinOps. Die Werkzeuge sind vorhanden. Die eigentliche Herausforderung besteht darin, sie richtig einzusetzen.“

In den meisten Unternehmen liege das Finanzwissen in der Buchhaltung und das technische Wissen in der IT, erklärt Johnson. Beide Gruppen beim Cloud-Kostenmanagement zusammenzubringen, sei eine vergleichsweise neue Herausforderung.

„Vor zehn Jahren war das Modell einfach: Man beantragte ein Investitionsbudget, die Buchhaltung genehmigte es, Hardware wurde bestellt und die IT installierte und optimierte alles. Fertig“, sagt Johnson. „Heute ist es eine tägliche Aufgabe. Neue Dienste werden aktiviert, Verträge ändern sich, Preisstrukturen werden angepasst. Die Finanzabteilung versteht die Geldströme, aber nicht die Technik. Die IT versteht die Technik, aber nicht die finanziellen Hebel.“

Jeder große Cloud-Anbieter verfügt über die entsprechenden Tools, erklärt Johnson. „AWS Cost Explorer, Azure Cost Management, die Abrechnungs-Dashboards von Google Cloud. Die Daten sind alle vorhanden. Doch viele Unternehmen nutzen diese Daten nicht. Dann kommt die Rechnung und alle sind überrascht. Die Werkzeuge haben die Entwicklung angekündigt. Man hat nur nicht hingehört.“

Datenregulierung bringt zusätzliche Herausforderungen

Die University of Health Sciences and Pharmacy hat Studierende aus der ganzen Welt. Laut Lewis ist Cloud-Management aufgrund der zunehmenden Datenschutz- und Regulierungsanforderungen weltweit deutlich schwieriger geworden.

„Wir müssen verstehen, in welcher Cloud-Region Metadaten gespeichert werden und wo sie dauerhaft liegen. Wenn diese Daten in ein intern trainiertes Modell einfließen, können wir garantieren, dass sie in der EU bleiben? Und wenn jemand die Löschung seiner Daten verlangt, können wir alle Speicherorte zuverlässig identifizieren?“

Basu ergänzt, dass Datensouveränität zu einer weiteren zentralen Architekturfrage geworden sei.

„Sie beeinflusst, wo Workloads ausgeführt werden dürfen, wie Daten zwischen Regionen bewegt werden und was mit bestimmten Datensätzen geschehen darf. Man kann nicht davon ausgehen, dass die Standardkonfiguration eines Hyperscalers automatisch alle regulatorischen Anforderungen erfüllt.“

Private Cloud, Public Cloud oder On-Premises?

KI hat eine Neubewertung der Platzierung von Workloads ausgelöst. Johnson glaubt jedoch, dass sich die Frage nach Private Cloud, Public Cloud oder On-Premises häufiger verändert, als viele denken.

„Ich denke, die meisten unserer Workloads befinden sich derzeit am richtigen Ort. Aber wir sind nur dorthin gelangt, weil wir bereit waren, Standardannahmen zu hinterfragen.“

Bei Sweetwater gebe es keine Regel, dass neue Workloads automatisch in die Cloud gehören. Ein Workload könne in der Cloud starten und später wieder ins eigene Rechenzentrum zurückkehren, wenn die Wirtschaftlichkeit dies erfordert.

„Die eigentliche Disziplin besteht darin, dies laufend zu überprüfen, Wendepunkte zu erkennen und die Größe der Umgebung kontinuierlich anzupassen. Das richtige Werkzeug zur richtigen Zeit – das ist das einzige Prinzip, das langfristig Bestand hat.“

Basu plant keinen Umstieg auf eine Private Cloud, da die Wirtschaftlichkeit und der betriebliche Aufwand dies für sein Unternehmen nicht rechtfertigen.

„Die richtige Frage lautet: Welches Modell für Datenresidenz, Latenz und Kontrolle ist für jeden Workload angemessen? Das ist eine Frage der Datenklassifizierung, nicht der Cloud-Bereitstellungsstrategie.“

Lewis, dessen Universität rund 95 Prozent ihrer Infrastruktur in der Cloud betreibt, sieht angesichts der Anforderungen von KI und moderner Hardware kaum praktikable Alternativen.

„Wenn man groß angelegte Data Lakes trainieren und fundierte Geschäftsentscheidungen mithilfe von maschinellem Lernen und der dahinterstehenden Intelligenz treffen möchte, ist es fast nicht mehr praktikabel, auf eigene Server zu setzen“, so Lewis.

CIOs müssten sich fragen, ob sie überhaupt über das notwendige Know-how verfügen, um eine solche Infrastruktur selbst zu betreiben. Letztlich müsse man das Beste aus den vorhandenen Möglichkeiten machen.

Fokus auf die Grundlagen

Unternehmen mögen vielleicht dem neuesten Trend hinterherjagen – derzeit ist das die agentische KI –, doch IT-Führungskräfte sollten sich auf ihre Infrastruktur, das Management und die Plattformplanung konzentrieren, betont Linthicum.

„Das ist vielleicht weniger spannend, aber wenn man KI im Unternehmen einsetzen will, muss man diese Probleme zuerst lösen.“

Johnson warnt, dass die Cloud eine Vielzahl architektonischer Muster ermöglicht – und diese Freiheit könne ohne Leitplanken zum Problem werden. „Erstellen Sie das Leitliniendokument, bevor Sie es brauchen – nicht erst, wenn bereits fünf Teams auf fünf verschiedene Arten vorgehen.“

IT-Verantwortliche sollten außerdem frühzeitig für ein sauberes Tagging und Transparenz bei den Kosten sorgen. Das müsse der erste Schritt sein und dürfe nicht erst als Aufräumprojekt betrachtet werden, warnt Johnson: „Wenn Sie Ihre Ausgaben nicht vom ersten Tag an klar nachvollziehen können, sind Sie bereits im Rückstand.“

Ein weiterer wichtiger Schritt sei der Aufbau eines Audit-Programms mit klaren Kontrollen darüber, wer Änderungen an Produktivsystemen vornehmen darf: „Die Auswirkungen einer fehlerhaften Änderung in der Cloud sind größer und treten schneller ein, als die meisten Menschen erwarten – bis sie es selbst erleben.“

Die Frage nach den Kompetenzen

Die Fähigkeiten, die für den Betrieb moderner Cloud-Umgebungen erforderlich sind, entwickeln sich laut Basu schneller weiter, als die meisten internen Teams realistischerweise mithalten können. Deshalb setzt International Seaways auf spezialisierte Managed Service Provider (MSPs), anstatt in jedem Bereich tiefgehendes internes Expertenwissen aufzubauen.

„Dadurch haben wir Zugang zu aktuellen Fähigkeiten, ohne Teams ständig umschulen oder neu aufbauen zu müssen, wenn sich die Technologie ändert. Die Entscheidungen, die uns 2020 geschützt haben, wurden Jahre zuvor getroffen – lange bevor jemand ihre Bedeutung erkannt hatte. Infrastrukturstrategie bedeutet immer, sich auf eine Zukunft vorzubereiten, die noch nicht vollständig sichtbar ist.“

Entscheidend sei, solche Entscheidungen bewusst und auf Basis klarer Überlegungen zu treffen, anstatt später unter Druck reagieren zu müssen.

Anpassungsfähige Organisationen aufbauen

Edge-Computing fügt laut Johnson eine weitere Ebene der Komplexität hinzu. Erfolgreich werden nicht diejenigen sein, die die perfekte Architektur finden. „Es sind diejenigen, die Organisationen aufbauen, die sich schnell anpassen können, wenn sich die richtige Antwort morgen ändert“, erklärt er.

Der eigentliche Wettbewerbsvorteil liege nicht in der gewählten Cloud-Plattform, sondern darin, wie schnell ein Team lernen und handeln kann, so Johnson.

Auf die Frage, wie sich Cloud-Umgebungen weniger kompliziert gestalten lassen, gaben die CIOs folgende Empfehlungen:

• Behandeln Sie Ihre Cloud-Architektur wie ein Produkt, nicht wie ein Projekt. Sie benötigt kontinuierliche Verantwortung und Weiterentwicklung, nicht nur eine einmalige Implementierung.
• Überprüfen Sie Ihre Entscheidungen regelmäßig. „Die richtige Entscheidung im ersten Jahr ist oft nicht mehr die richtige im dritten. Planen Sie feste Überprüfungspunkte ein“, erklärt Johnson.
• Ordnen Sie jeden Workload einer Kostenstelle zu. Basu hat dies umgesetzt; die IT überprüft kontinuierlich Auslastung und Größenanpassungen, anstatt auf periodische Audits zu warten.
• Die Datenklassifizierung bestimmt die regionale Platzierung. Bevor ein Workload in Produktion geht, sollten Rechts- und Compliance-Abteilungen von Anfang an eingebunden sein.
• Entwickeln Sie Cloud-fähige Lösungen. Das kann günstiger und risikoärmer sein als die unveränderte Migration stark angepasster Altsysteme.
• Konsolidierung ist eine strategische Entscheidung, kein Rückzug. Weniger Plattformen, die gut gesteuert werden, schneiden dauerhaft besser ab als eine zersplitterte Multi-Cloud-Landschaft.
• Unterschätzen Sie nicht die Governance-Lücke, die durch KI entsteht. Schaffen Sie jetzt eine KI-Governance-Struktur, bevor sich technische und organisatorische Schulden anhäufen.
• Cloud-Strategie ist keine reine IT-Architekturentscheidung. Die Pandemie habe gezeigt, dass sie vor allem eine Entscheidung zur Sicherung der Unternehmensresilienz sei. „Die Organisationen, die schwierige Entscheidungen vor einer Krise treffen, sind diejenigen, die unbeschadet daraus hervorgehen.“
• Verknüpfen Sie Cloud-Entscheidungen mit messbaren Geschäftsergebnissen. Bellendir von WHSmith berichtet, dass sein Unternehmen stark in Integrationsarchitekturen, Cybersicherheitskontrollen, Observability und Data Governance investiert, um hybride Umgebungen besser zu unterstützen.
• Legen Sie größeren Wert auf Cloud-Kostenkontrolle und operative Disziplin. Dadurch wird die Transparenz über die Cloud-Nutzung verbessert und sichergestellt, dass die Skalierung von KI-, Analyse- und Digitalisierungsinitiativen langfristig finanziell tragfähig bleibt.

Auch wenn niemand vorhersagen kann, ob Cloud-Umgebungen künftig weniger komplex werden, werden Unternehmen sie weiterhin nutzen.

„Die Cloud ist nicht mehr die Zukunft der IT – sie ist die Gegenwart. Die Diskussion hat sich von der Frage ‚Sollen wir das tun?‘ hin zu ‚Wie werden wir darin besser?‘ verschoben. Und genau damit verbringe ich heute den Großteil meiner Zeit“, konstatiert Johnson. (mb)

Dieser Artikel basiert auf einem Beitrag von CIO.com

---

I work as a principal specialist at a pipeline operator where Operational Technology (OT) is the backbone of the business. I do not report to the board or act as a CISO, but the issues that get raised to those levels affect my job every single day.

Since the Colonial pipeline ransomware incident in 2021, it has become apparent that our industry has started posing different tones of “Are we zero trust yet?” I frequently witness its intense significance through auditing requests, TSA security directives and conversations around some control project’s goals.

One experience the zero trust role has changed is that it often feels misaligned with OT heavy environments. The NIST’s Zero Trust Architecture (SP 800‑207) model works for all, but is originally written as though for an IT network, not terminals, compressor stations and control rooms where equipment must run 24/7, perhaps more aged than the technology present within the organization. CISA’s guidance on adapting zero trust principles to operational technology helps close that gap, but applying it means satisfying the OT teams and company leadership at the same time.

The zero trust question I hear behind the scenes

I am pretty sure we all know it comes as a jolt of reality after something really major has happened, rather than a bullet point on a slide deck. You have pipeline. The whole distribution stops for six days. In Washington, DC, US congressional hearings are underway, and legislation is coming. TSA Directive 2021-02C requires pipeline operators to attest to several things, like network segmentation and zero-trust architectures.

NERC CIP-013 exists on a similar tack, more around supply chain security. In our case, the decision on how to select and manage a vendor partner and control their remote access is driven by regulatory compliance and governance frameworks. So, you have all those things that happen externally and force change. They say, “Are you zero trust? Yes or no?” We always get “yes.” They know it is not “yes, ” and the vendors know it is not “yes,” and nothing gets done about it until something happens.

How I reframe zero trust for OT in my work

My influence comes from how I frame problems and options in the conversations I am invited into. Zero trust is a good example.

NIST’s SP 800‑207 describes zero trust as a model where access decisions are to be based on strong identity, policy and context rather than network. CISA’s OT guidance narrows it, advising operators on the appearance of devices, identity management and what overlaps with IT instead of the overall replacement. Why zero trust breaks down in IoT and OT environments” highlights that when facing the complications of IoT and OT environments, one needs to be proactive.

During these conversations, I try to focus on three major points when talking about IoT.

1. Refer to zero trust as its functioning principle. In my experience, teams respond better when I say “Every user and system has to prove who they are and why they need access” than when I talk about abstract architectures. That language matches what NIST and CISA emphasize without overwhelming people with jargon.
2. Focus on where IT and OT converge, like jump hosts, historian connections, remote access paths and shared identity stores that span both worlds. Those are the choke points where zero trust style controls like stronger authentication, least privilege and detailed logging can give us quick wins without disrupting operations that depend on predictable behavior.
3. Tie everything that we need to do to the existing requirements. The conversation moves from “why are we changing this?” to “how do we do this well?” which aligns with TSA Security Directive Pipeline‑2021‑02C, a CISA alert or a NERC CIP‑013 requirement.

A 90-day plan OT leaders can execute

While someone operates a gas pipeline, they cannot play around with zero trust. Questions such as: “What can we accomplish before the TSA checks up next quarter?” Or “How can we show the internal audit team we are making progress this month?” comes often. We have established a list of actions we take over in a ninety-day plan, because we find it aligns more with our industrial settings while also being transferable to other OT settings.

Days 1–30: Map assets and identities at the IT/OT boundary

The first 30 days are for increased visibility. I focus on a relatively simple question: “Who and what can currently reach OT, intentionally or accidentally?”

CISA’s guidance on zero trust for OT, alongside other warnings, advocates for identifying and managing assets and communications where IT and OT interfaces exist, in addition to informal remote access routes. Also, TSA requires pipeline operators to regularly update and manage plans detailing which networks, systems and access points they will assess as per their established requirements across both IT and OT.

In my position, it comes down to three actions. First, I work with OT engineers, network staff and asset inventory systems to determine which OT assets threaten operations, safety or compliance if compromised, rather than inventorying every device. Second, I map the users and links that reach into OT, such as internal staff granted advanced privileges, remote vendor support, VPNs and cloud platforms that interact with production data. Third, I categorize these identities and connections based on risk, impact and exposure, not by their roles.

By the close of the first 30 days, the intention is to present leadership with an easily comprehensible overview: outlining the critical OT assets, delineating the entry points from both internal IT systems and external sources and identifying the associated identities. Having established this common understanding makes subsequent zero trust discussions less vague.

Days 31–60: Contain vendor remote access and create early wins

Look for quick wins in the next month, in a high-impact but non-disruptive area. Vendor or third-party remote access often fulfills it, and CISA has warned about it and continues to do so.

Their guidance emphasizes best practices, including using MFA, segmented user privileges and monitoring third-party activity independently. The NERC CIP-013 requires utilities to consider cybersecurity threats and risk management that protect their supply chains and suppliers that connect to critical systems. The TSA’s pipeline directives expect close monitoring and controls of remote access. In my case, early wins look like telling a vendor: OK, instead of an unsecured, remote access method, use an audited brokered remote access solution. MFA for any and all remote OT sessions. Close old vendor RDP connections that are not in service. You are simply saying that times change and since these methods were put in place a few years back, they have evolved; it is reasonable for you to evolve.

Days 61–90: Build a simple maturity scorecard and narrative

The third month is about visibility and repeatable progress. We now will have more clarity on assets and identities traversing the IT/OT boundary and have choked down the most dangerous of remote access paths. Now we will take time to track where we have been over time.

I will consult with leaders within security and OT teams to identify the right-sized set of metrics relevant to the specific context of the organization. While the specific terminology may vary, many will align with common language found in TSA, NERC, CISA and other industry documents. Consider the broad themes of “govern, protect and detect & respond”.

We can then identify solid “now” and “better next quarter” capabilities within each of these themes. “Govern” could incorporate specific OT policies on identity and access management that pull in zero trust directives alongside existing authoritative frameworks. “Protect” might track what fraction of your high-impact OT assets have been put behind better segmentation practices, coupled with the percent of your remote access pathways to OT identified as high-risk that have both MFA and a brokered connection. “Detect & respond” could see tested playbooks in place assuming a remote connection compromise that directly injects malware into an OT system, which aligns with how recent incidents have unfolded throughout North American utilities.

The output is not a scorecard to pass around but will be a meaningful, honest conversation for our leaders. You will know how to accurately frame how your organization applies zero trust in the OT world today, show what you achieved over the past three months and honestly describe where there is more work ahead.

I am not the only one trying to make zero trust ideas actually fit OT, and I pay attention to the CISOs who voice the same frustrations with IoT and OT environments. We are solving the same problem from different seats. What I have found is that a workable 90-day plan, updated monthly, beats any pledge to “Let us achieve zero trust together”

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

도널드 트럼프 미국 대통령이 25일 연방정부의 포스트 양자암호(PQC) 전환을 가속화하고 미국의 양자 기술 투자를 확대하기 위한 두 건의 행정명령에 서명했다. 행정부는 이번 조치를 양자컴퓨팅이 가져올 기회와 위험에 동시에 대비하기 위한 범정부 차원의 종합 전략이라고 설명했다.

이번 조치는 ‘고도화된 암호 공격으로부터 국가 보호(Securing the Nation Against Advanced Cryptographic Attacks)’와 ‘양자 혁신의 새로운 시대 개척(Ushering in the Next Frontier of Quantum Innovation)’ 등 두 건의 행정명령으로 구성된다. 백악관은 관련 설명자료를 통해 이번 정책이 국가안보와 경제 경쟁력, 사이버보안을 강화하기 위한 행정부의 광범위한 전략의 일환이라고 밝혔다.

보안 책임자에게 가장 직접적인 영향을 미치는 것은 암호 관련 행정명령이다. 해당 명령은 연방기관의 양자내성 암호 전환 시한을 제시하고, 기관별 암호 자산 전수조사를 의무화했으며, 향후 정부 계약업체에 적용될 조달 요건의 방향도 제시했다.

포스트 양자암호 전문 기업 키팩터(Keyfactor)의 최고정보보호책임자(CISO) 크리스 힉먼은 CIO.com 자매지 CSO온라인과의 인터뷰에서 “매우 긍정적인 조치이며 세계 여러 국가가 추진해 온 방향과도 일치한다”라며 “이제는 실제 행동에 나설 수밖에 없는 단계”라고 평가했다.

힉먼은 이번 전환 일정이 연방기관을 넘어 정부 계약업체와 국가 핵심 인프라 운영기관에도 상당한 영향을 미칠 것으로 전망했다. 이들 조직이 포스트 양자암호 도입 준비를 입증해야 한다는 압박을 점점 더 크게 받게 될 것이라는 설명이다.

그는 “연방정부와의 거래를 유지하려는 공급업체가 많은 만큼 이제는 포스트 양자암호를 더 이상 미뤄서는 안 된다”라고 말했다.

미 행정부는 적대국이 현재의 공개키 암호체계를 무력화할 수 있는 양자컴퓨팅 기술의 발전에 대비해 이미 암호화된 통신과 민감한 데이터를 수집하고 있을 가능성이 있다고 보고 있다.

백악관은 이를 ‘선 수집 후 해독(Harvest Now, Decrypt Later, HNDL)’ 시나리오라고 설명했다. 현재 탈취한 정보를 장기간 보관했다가 충분한 성능의 양자컴퓨터가 등장하면 이를 해독할 수 있다는 의미다.

암호 해독이 가능한 수준의 양자컴퓨터가 언제 등장할지를 두고는 전문가들의 의견이 엇갈린다. 그러나 미국 정부는 해당 기술이 현실화될 때까지 기다렸다가 준비를 시작해서는 늦는다는 입장이다.

백악관은 이번 행정명령이 2025년 6월 발표한 사이버보안 행정명령과 올해 공개한 ‘미국 사이버 전략(Cyber Strategy for America)’을 잇는 정책이라고 밝혔다. 또한 이번 조치가 연방 시스템을 보호하는 데 그치지 않고, 국가 핵심 인프라와 디지털 생태계 전반에서 양자내성 보안기술 도입을 촉진하는 데 목적이 있다고 설명했다.

화이트하우스 예산관리국(OMB) 법률고문을 지낸 해커원(HackerOne)의 최고법률·정책책임자 일로나 코언은 성명을 통해 최근 행정부의 사이버보안 정책은 정부 사이버 위험에서 계약업체가 차지하는 역할에 대한 우려가 커지고 있음을 보여준다고 평가했다. 코언은 “연방 네트워크의 복원력은 이를 지원하는 계약업체의 보안 수준만큼 강하다”라고 말했다.

다음은 CIO Korea 기사 스타일에 맞춰 자연스럽게 다듬은 번역입니다.

연방기관 포스트 양자암호 전환 일정 확정

행정명령은 미국 국립표준기술연구소(NIST)가 마련한 포스트 양자암호(PQC) 표준으로 연방기관의 암호 체계를 신속히 전환하도록 지시했다.

NIST는 2024년 첫 번째 포스트 양자암호 표준을 확정했으며, 미래 양자 공격에 취약한 기존 암호체계를 대체할 추가 알고리즘도 계속 평가하고 있다.

행정명령에 따르면 연방기관은 2030년 12월 31일까지 키 교환(Key Establishment) 메커니즘의 전환을 완료해야 한다. 디지털 서명 시스템은 2031년 12월 31일까지 전환을 마쳐야 한다. 또한 모든 기관은 30일 이내에 포스트 양자암호 전환을 총괄할 고위 책임자를 지정해야 한다.

미국 예산관리국(OMB)은 90일 안에 세부 이행 지침을 마련해야 하며, 각 기관은 이에 맞춰 연방 시스템 전반에서 취약한 암호체계를 교체하기 위한 실행 계획을 수립해야 한다.

이번 일정은 연방정부의 포스트 양자암호 도입 시점을 가장 명확하게 제시한 정책 가운데 하나로 평가된다.

암호 구성요소 명세서(CBOM) 도입

행정명령에는 정부 시스템과 소프트웨어 공급망 전반의 암호 구성요소를 보다 체계적으로 파악하기 위한 조치도 포함됐다.

핵심 내용은 NIST와 사이버보안·인프라보호국(CISA)이 270일 이내에 암호 구성요소 명세서(Cryptographic Bill of Materials, CBOM)의 최소 구성요건을 마련하도록 한 것이다.

CBOM은 소프트웨어 구성요소 명세서(SBOM)와 유사한 개념이지만, 제품과 시스템에 포함된 암호 알고리즘과 암호 라이브러리, 관련 의존성을 식별하는 데 초점을 맞춘다.

보안 전문가들은 조직이 자체 환경에서 어떤 암호 기술이 어디에 사용되고 있는지 먼저 파악하지 못하면 포스트 양자암호로의 전환도 효과적으로 추진할 수 없다고 지속적으로 지적해 왔다.

행정부는 또한 NIST에 2027년 말까지 연방 포스트 양자암호 전환 시범 프로그램을 구축하도록 지시했다. 이를 통해 실제 구축 과정에서 발생하는 문제를 파악하고, 전환을 위한 모범 사례를 마련한다는 계획이다.

정부 계약업체, 새로운 규정 준수 의무 직면

이번 행정명령은 연방정부 계약업체에도 상당한 영향을 미칠 것으로 보인다.

행정명령은 연방조달규정위원회(Federal Acquisition Regulatory Council)에 2030년 말까지 해당 계약업체가 NIST의 포스트 양자암호(PQC) 표준을 준수하도록 하는 조달 기준을 마련할 것을 지시했다.

세부 내용은 아직 확정되지 않았지만, 연방정부의 조달 요건이 기술 업계 전반에서 포스트 양자암호 도입을 촉진하는 핵심 동력이 될 가능성이 크다.

연방기관과 거래하는 보안업체와 클라우드 서비스 제공업체, 소프트웨어 개발사, 관리형 서비스 제공업체(MSP)는 앞으로 새롭게 마련될 포스트 양자암호 요구사항을 충족한다는 점을 입증해야 할 가능성이 높다.

행정명령이 암호 자산 관리와 전환 계획, 표준 준수를 강조한 점을 고려하면 연방기관은 앞으로 공급업체에 제품에 포함된 암호 구성요소를 정확히 파악하고 문서화할 것을 요구할 것으로 예상된다.

양자 기술 혁신 정책도 본격 추진

트럼프 대통령은 사이버보안 행정명령과 함께 양자컴퓨팅과 관련 기술 개발을 가속화하기 위한 별도의 행정명령에도 서명했다.

행정부는 양자 기술이 장기적으로 제약과 제조, 물류, 에너지, 국방 등 다양한 산업을 혁신하는 동시에 과학 연구와 국가안보 분야에서도 전략적 우위를 제공할 것으로 기대하고 있다.

정책의 핵심은 ‘과학 발전을 위한 양자컴퓨팅(QC-ADDS, Quantum Computing for Accelerated Discovery and Development for Science)’ 프로그램이다. 행정부는 이 사업을 통해 ‘양자 기반 과학적 발견(Quantum-enabled Scientific Discovery)’을 가능하게 하는 양자컴퓨터를 최소 한 대 이상 개발한다는 목표를 제시했다.

에너지부와 상무부, 국방부, 미국국립과학재단(NSF), 미국 항공우주국(NASA), 국가안보국(NSA), 정보기관 등은 이 프로그램 아래에서 연구개발을 공동 추진하게 된다.

각 기관은 90일 안에 기술 요구사항을 마련하고, 180일 안에 구체적인 실행계획을 제출해야 한다.

업계에서는 이번 행정명령이 양자컴퓨팅 주도권 확보를 위해 기술 스택 전반에 걸친 전략적 투자가 필요하다는 인식이 확산되고 있음을 보여준다고 평가했다.

AI·양자 기술 기업 샌드박스AQ(SandboxAQ)의 엔지니어링 부사장 스테판 라이헤나우어는 성명을 통해 “미국에는 이 분야를 선도할 기회가 남아 있다”라며 “암호기술과 컴퓨팅 인프라, 데이터 생성, 애플리케이션 개발 등 기술 스택 전반에 대한 체계적인 투자가 필요하다. 또한 정부와 산업계, 학계 간 긴밀한 협력도 필수적”이라고 말했다.

행정명령에는 양자 네트워킹과 양자 센싱 기술에 대한 지원 확대와 함께 양자컴퓨팅 시스템의 성능을 평가하고 벤치마킹할 수 있는 국가 차원의 역량을 구축하는 내용도 담겼다.

상용화·인재 양성도 핵심 과제

이번 양자 기술 육성 정책은 연구 성과를 실제 산업 현장으로 이전하는 데도 초점을 맞추고 있다.

백악관은 미국이 자국 내 양자 공급망을 강화하고 기술 이전을 지원하는 한편, 정부 지원 연구성과가 상용 제품과 경제 성장으로 이어질 수 있도록 해야 한다고 밝혔다.

TDK벤처스(TDK Ventures)의 투자 책임자 안쿠르 삭세나는 “양자 기술은 이제 순수 과학의 영역을 넘어 엔지니어링과 산업 경쟁의 단계로 접어들고 있다”라며 “미국의 경쟁력은 혁신적인 하드웨어뿐 아니라 안정적인 공급망과 양자 기술의 대규모 상용화를 가능하게 하는 기반 인프라 구축에 달려 있다”라고 말했다.

행정부는 국가양자이니셔티브 자문위원회를 재구성하고, 양자 방첩 보호팀(Quantum Counterintelligence Protection Team)의 활동도 확대해 민감한 연구성과와 지식재산을 보호할 계획이다.

또한 양자 분야 교육과 자격 인증, 견습 프로그램을 지원하고 국가 양자정보과학·기술 인력개발 연구소도 설립할 예정이다.

양자 기술 전략의 두 축

이번 두 건의 행정명령은 양자 기술 개발을 가속화하는 동시에, 장기적으로 발생할 보안 위험에도 선제적으로 대응하겠다는 미국 정부의 전략을 보여준다.

사이버보안 분야에서는 포스트 양자암호 관련 조치가 가장 큰 영향을 미칠 것으로 예상된다. 연방기관은 전환 일정과 암호 자산 관리, 시범사업, 향후 조달 규정 등을 통해 포스트 양자암호를 검토하는 단계를 넘어 실제 구축 단계로 전환하고 있음을 시사한다.

기술 업계 전반에도 양자컴퓨팅이 더 이상 장기 연구 과제가 아니라 투자와 거버넌스, 위험 관리가 동시에 요구되는 국가 전략 기술이라는 공감대가 미국 정책 당국을 중심으로 빠르게 형성되고 있음을 보여주는 조치로 평가된다.
dl-ciokorea@foundryco.com

Qualcomm on Wednesday said that it will spend $3.9 billion to purchase AI-native software platform developer Modular Inc., a move that Qualcomm says will allow it to level the playing field on data centers by creating “a silicon-agnostic compute layer.”

The stock-based acquisition “further enables Qualcomm Technologies to deliver a silicon-agnostic compute layer across devices, edge, and data centers, improving performance-per-watt, increasing hardware flexibility, and expanding an open developer ecosystem so customers can deploy AI more efficiently across heterogeneous platforms globally,” the company said in a statement. 

Qualcomm’s position is that enterprises need far more flexibility in their data center strategies, especially given how fluid the AI space is today. When CIOs need to make bets on data centers without knowing what the field will look like in two years, it can be challenging.

Chris Lattner, CEO of Modular, posted on LinkedIn that this leveling of the data center playing field was one of the company’s key early goals.

“In a world with a tremendous amount of innovative heterogenous AI hardware, there has always been a gap: existing fragmented software technologies weren’t built to scale effectively across this hardware. This gap holds back innovation and choice and makes development painful,” Lattner wrote in his LinkedIn post.

“Modular was founded 4.5 years ago to solve this problem,” he wrote. “We’ve already integrated support for several hyperscale datacenter silicon providers, but we’re not stopping with what’s publicly announced. We’ve built an open platform and are continuing to open it further.”

Lattner added that the Qualcomm acquisition “will accelerate our progress and path” by “spanning edge to cloud, CPU, GPU, NPU, and custom ASICs and perhaps more.”

Addresses a pain point

Analysts, although skeptical of the probability of success in taking meaningful market share away from Nvidia, said that Qualcomm has focused on a true sore point for enterprises struggling with data center approaches. 

Matt Kimball, VP and principal analyst with Moor Insights & Strategy, said, “the argument that Modular can make datacenters cost-effective is directionally correct. As enterprise AI actually hits velocity, heterogeneity is almost an understatement. Different accelerators are required for different use cases across different deployment scenarios.”

To date, it’s been a challenge for organizations to manage AI in this environment, he noted. “And when enterprise AI takes off, this challenge will be fully exposed.”

Kimball said that Modular “can be extremely valuable in achieving two things that will vex most organizations: abstracting complexity and delivering significantly more flexibility. And this would certainly lead to TCO advantages. I think the per-watt performance claim can be challenging to validate across every and any deployment scenario, but I understand the spirit behind it.”

Yuri Goryunov, CIO of consulting firm Acceligence, also applauded the Qualcomm move, but he stressed that the deal’s value is not in the technology as much as in the talent.

“The key is what Qualcomm actually bought: not silicon, but the software layer, meaning Chris Lattner’s team plus Mojo and the MAX engine. That’s the right place to apply pressure. Nvidia’s real moat has never been the GPUs,” he said. “It’s CUDA and the rewrite cost that keeps workloads pinned to their hardware. A credible ‘write once, run across CPU/GPU/NPU/ASIC without rewrites’ layer is exactly what lowers the switching cost and makes non-Nvidia silicon a safer bet.”

But Goryunov said that the data center “democratization” argument also is powerful.

“Anything that pushes toward democratization of compute and better routing of tasks to best-fit capacity adds real flexibility to the ecosystem,” he noted. “If workloads can be matched to the right compute instead of defaulting to one vendor, everyone gets more efficiency on performance-per-watt and TCO and customers get real choice. That’s the part of this I find most compelling.”

Still some obstacles

That said, none of this will be easy, he pointed out.

“Does it change the competitive position versus Nvidia? Directionally, yes. It opens a credible second front at the exact point where Nvidia is stickiest. I’d stop short of saying it shifts the balance overnight. CUDA’s moat is a decade deep and this is a multi-year execution play,” Goryunov said. “But the attack is aimed at the right wall and the team they bought is about as serious as it gets for this fight.”

But he stressed that much of Qualcomm’s strategy with this acquisition relies on an uncertain assumption: That Nvidia won’t counterattack by opening its architectures to various others. Or, at the very least, that Nvidia won’t do so quickly enough.

“That’s the barrier to entry, which is that Nvidia will focus on their stickiness,” Goryunov said.

Kimball added that, from a competitive perspective, Qualcomm has various obstacles to overcome. “Part of this acquisition goes directly to the Nvidia challenge” of finding a way to “make it easier for customers to deploy heterogeneous silicon without software getting in the way.”

John Annand, senior technical counselor at Info-Tech Research Group, is more skeptical of Qualcomm’s ability to do serious damage to Nvidia.

“Nvidia has something like 85% of the AI accelerator chip market,” he pointed out. “Sure, they have nowhere to go but down, but that’s still going to take them a while. More importantly, they have literally spent decades working with practitioners in AI and ML and compute-intensive fields, indoctrinating them into their CUDA software ecosystem. Rewriting that tool chain will take institutional change at most organizations, which means years, if not decades, to uncouple.”

“Organizations that think they’ve achieved agnosticism because they’re using high-level abstractions like PyTorch, well,  they have come closest,” he observed. “But just cutting and pasting the same code into AMD Instinct can lead to memory and dependency errors. It’s like VM lift and shifts to the public cloud 10 years ago. Easier, but still possible to screw up.”

Nonetheless, Annand said that the deal, if it goes through, is still good news for enterprises. 

“What it means for enterprise IT is that the vendors we currently rely on to deliver AI have another potential building block. Because enterprise IT accesses AI via an API call, it’s operationally irrelevant to us if Claude runs on Nvidia, AMD ROCm, or Modular,” he said.

“Now, because of the commercial and stock agreements, OpenAI and Anthropic aren’t going to jump ship anytime soon. But if your enterprise is looking for more boutique offerings, like those from Cohere, or is looking to build its own models and tools from scratch, this is an exciting announcement.”

Goal: build once, run anywhere

Shashi Bellamkonda, principal research director at Info-Tech Research Group, looks at the potential acquisition, while it will potentially deliver benefits, as suffering from many practical roadblocks.  

“Qualcomm is chasing what you might call model democracy,” he said, noting that today, AI deployment teams are locked to whatever accelerator they trained on, and moving a model to different hardware means re-engineering, not just configuration changes.

“Modular’s pitch is that this goes away: build once, run across CPU, GPU, NPU, whatever the infrastructure calls for,” Bellamkonda said. “That’s a credible goal. The catch is that democracy and portability aren’t the same thing. Qualcomm will tune hardest for Qualcomm silicon. Every hardware company does. Vendor-neutral software foundations have a habit of developing hardware preferences once their acquirers need to differentiate silicon.”

Flavio Villanustre, CISO for the LexisNexis Risk Solutions Group, provided a different perspective. 

“I think it’s important to clarify that Modular is behind the Mojo programming language, which provides an abstraction layer for AI models, enabling them to run across different hardware architectures,” he said. “In the traditional approach, if you code an AI stack on Python or C and target a particular hardware architecture, such as X86, Nvidia GPU, AMD GPU, or TPU, you will need to rewrite a significant portion of that to run it on a different architecture. With Mojo, you code it once and it runs everywhere, even on hybrid systems composed of different hardware architectures.”

And, he said, “if you now consider the fact that Qualcomm owns intellectual property and manufacturing across different hardware architectures, both CPU and GPU, this acquisition could offer their customers significant lift. I see this as Qualcomm buying abstraction that allows them to provide diverse hardware offerings and still offer their customers full code reuse across their entire CPU/GPU/TPU/NPU portfolio.”

Security awareness training as a defense against phishing is dead. It has been dead for a while. The industry never held a funeral because the training budget is comfortable, the compliance box gets checked and no CISO wants to tell the board that the program everyone funds does not work.

The premise was simple. With enough education, users would learn to spot the tells. Misspelled words. Awkward phrasing. Sender domains that looked almost right. URLs that revealed something suspicious on hover. We trained a generation of employees to play Where’s Waldo with their inbox, scanning for the one visible artifact that would mark a message as malicious.

Those artifacts are gone. AI-generated attacks are fluent. The infrastructure behind them looks legitimate. The surface signals we trained users to rely on no longer exist. Even if they did, the model would still depend on something humans cannot deliver. Sustained vigilance across hundreds of messages a day, every day, with one lapse leading to compromise. No human attention system works that way.

If user attention is not the answer, what is?

Kahneman applied to organizations, not individuals

Most discussions of phishing lean on author Daniel Kahneman’s System 1 and System 2. Fast thinking is automatic and easy to fool. Slow thinking is deliberate and more accurate. The conclusion is always the same. Train people to slow down.

The framing is true about cognition and incomplete as a security strategy. It asks individuals to sustain behavior that breaks under real conditions.

The more useful application is at the organizational level.

Every company has processes that run fast and processes that run slow. The difference is not accidental. Fast processes are the ones where trust has already been granted and friction has been removed. Wire transfers between known parties. Vendor banking updates. Calendar invites accepted without inspection. Help desk verification over the phone.

Slow processes are the opposite. Trust is being established in real time. Employee logins with conditional access. New vendor onboarding. Any interaction with someone outside the organization.

Most companies did not design this split deliberately. It emerged over time. Someone removed friction because it helped the business move faster. Often, that decision made sense at the time. The threat landscape that justified it no longer exists.

Attackers understand this better than we do. They map where the fast paths are. They wait for moments where scrutiny is minimal. Then they step directly into those lanes.

The Nexus pass as a security primitive

Border control solved a problem that security still struggles with. Uniform scrutiny does not work. Check everyone the same way and movement stops. Check no one and the border disappears.

The solution was risk tiering. Pre-vetted travelers earn a fast lane based on evidence. Everyone else goes through full inspection. The trust is continuously verified and can be revoked the moment new information appears.

The fast lane is not a flaw. The full check is not overkill. Both exist because the system asks the right question. Not whether to trust or verify, but which interactions deserve speed and what evidence supports that decision.

Apply that lens to an enterprise and the gaps become obvious.

Which processes are running on a fast lane that no longer make sense? A vendor whose banking details change over email. A supplier using a typosquatted domain that slips through. A calendar invite from a name that looks familiar enough. An API credential tied to a vendor that has not been active in years.

Each of these is a fast path. Each one has been exploited at scale by attackers who know the assignment was never revisited.

The answer is not to slow everything down. That is the same mistake as awareness training, just applied to processes instead of people. It would destroy productivity and still fail to stop attacks.

The real work is targeted. Identify which fast paths were built on outdated assumptions. Re-tier those. Pull the fast lane from the processes that no longer deserve it. Leave it where it still holds.

The trust inversion no one wants to admit

This leads to a harder question about architecture.

Over the last decade, we applied zero trust to employees and standing trust to suppliers. Employees authenticate constantly. They deal with device checks, session limits and conditional access. Suppliers send a SOC 2 report once and receive long-lived access to critical systems.

That asymmetry deserves scrutiny.

Suppliers are often the path of least resistance for attackers. They hold legitimate credentials. They have access across systems. Many major breaches over the past five years started with a compromised vendor account that was already trusted.

SOC 2 does not solve this. It measures internal control discipline. It answers whether a company follows its processes. It does not tell you whether that company is secure right now.

Yet many organizations treat it as if it does. They make high-stakes access decisions based on a document that was never designed to answer that question.

Compliance automation has made this worse. It turned an annual exercise into a continuous one without changing what is being measured. The bar stayed the same. We just got faster at producing evidence that it was met.

A clean report next to a vendor with an old, compromised credential still active in production is not an edge case. It is a common state.

What deliberate design actually looks like

The work ahead is not glamorous. It will not show up neatly on a dashboard.

Start by mapping processes across the organization. Identify which ones run fast and which run slow. For every fast path, ask three questions.

What evidence originally justified the speed? Does that evidence still hold given current attacker capability? If you remove the fast lane, is the cost lower or higher than the expected impact of a breach tied to that process?

When the evidence no longer holds and the cost of change is lower than the potential loss, the assignment needs to change.

That change will have a cost. Vendor updates that took seconds may take minutes. Help desk interactions may require secondary verification. Onboarding new suppliers may slow down.

The case for accepting that cost is not that caution is good in theory. It is that the original speed was based on assumptions that no longer apply. The efficiency was borrowed from a future failure.

If you cannot explain why a process still deserves a fast lane, you are not making a business decision. You are accepting risk without acknowledging it.

This is what it means to design deliberately. Not forcing everyone to slow down, but making conscious decisions about where speed belongs and where scrutiny is required. Revisiting those decisions as conditions change. Removing fast lane status, the moment it is no longer justified.

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

Wenn es um den Einsatz von KI geht, befinden sich IT-Führungskräfte oft in einer schwierigen Zwickmühle: Sie versuchen, widersprüchliche Vorgaben des Managements mit sich ständig verändernden KI-Modellen, Funktionen und Kosten, Anforderungen an die Datenverwaltung und -sicherheit sowie den Grenzen ihres eigenen Teams in Einklang zu bringen. Gartner-Analyst Nader Henein schreibt das in Teilen auch den Anbietern zu: „Es lassen sich nur sehr wenige echte Vorteile erzielen, wenn man einfach ein KI-Produkt kauft und es den Mitarbeitern zur Verfügung stellt. Die KI-Anbieter haben diesen Irrglauben in den letzten drei Jahren allerdings übermäßig angepriesen und gefördert.“

In der Realität, so der Analyst weiter, seien ein hoher KI-Nutzwert und ein konsistenter ROI fast immer das Ergebnis einer tiefgreifenden und gezielten Integration von KI-Fähigkeiten in bestehende Workflows. Dafür benötige man spezialisierte Teams, weiß Henein: „Diese sind alles andere als günstig und werden von Unternehmen auf vielfältige Art und Weise rekrutiert.“

Zu diesen Support-Optionen für KI-Implementierungen gehören:

• traditionelle IT-Beratungsunternehmen,
• KI-spezifische Beratungsunternehmen,
• unabhängige Auftragnehmer,
• eine „Acquihiring“-Strategie, oder auch
• Open-Source-Lösungen.

Die Option, die in letzter Zeit die größte Aufmerksamkeit gezogen hat, ist allerdings der Einsatz von Forward Deployed Engineers (FDEs). Diese Expertenteams von KI-Anbietern unterstützen die Kunden vor Ort dabei, die Technologie in ihre Umgebung zu integrieren.

Für diesen Artikel haben wir mit Experten nicht nur diskutiert, welche Vor- und Nachteile es hat, auf die FDE-Teams von KI-Anbietern zu setzen. Sondern auch das Pro und Kontra der Alternativoptionen. Eine übersichtliche Tabelle, die sämtliche Ansätze samt ihrer Vor- und Nachteile abbildet, finden Sie am Ende dieses Beitrags.

KI-FDEs – die Vor- und Nachteile

Von KI-Anbietern beschäftigte FDE-Teams verfügen über entscheidende Stärken. Dazu gehören etwa:

• ein besseres Verständnis der zugrundeliegenden Modelle,
• Erfahrung bei der Integration dieser Modelle in verschiedene Arten von Enterprise-Umgebungen, sowie
• Kenntnisse über geplante neue Funktionen, noch bevor diese offiziell angekündigt werden.

Auf der anderen Seite steht allerdings der offensichtliche Nachteil der Anbieterabhängigkeit: Selbst wenn zukünftige Rollouts nicht zu den vertraglich vereinbarten Leistungen gehören, könnten die FDE-Teams eines KI-Anbieters subtilen Einfluss auf die zukünftigen KI-Initiativen ihrer Kunden nehmen. Auch deshalb mahnt Flavio Villanustre, CISO bei LexisNexis Risk Solutions, IT-Führungskräfte zur Vorsicht: „FDEs sind – auch aufgrund finanzieller Anreize ihrer Arbeitgeber – darauf ausgerichtet, die KI-Nutzung des Kunden zu steigern und in Sachen Services ‚Stickiness‘ zu erzeugen. Auch wenn diese Teams einen sinnvollen Mehrwert bieten, ist es Anwendern zu empfehlen, stets auch unvoreingenommene Experten zu konsultieren, die konkurrierende Lösungen verschiedener Anbieter unbefangen bewerten können.“

Das sei laut Villanustre besonders wichtig in einer Zeit, in der die von Investoren subventionierten Geschäftsmodelle rund um KI-Token erste Risse zeigten: „Angesichts des derzeitigen rasanten Innovationstempos könnte es erhebliche Wettbewerbsvorteile schaffen, flexibel genug zu sein, um den Anbieter zu wechseln.“

Auch Sanchit Vir Gogia, Chefanalyst bei Greyhound Research, sieht den Einsatz eines FDE-Teams vom KI-Anbieter als zweischneidiges Schwert: „FDEs sind zwar in die Umgebung des Kunden eingebettet, vertreten aber eben auch die kommerziellen Interessen ihres Arbeitgebers. Den Experten von KI-Anbietern übermäßigen Einfluss auf Implementierungsentscheidungen einzuräumen, könnte nicht nur zu einer erhöhten Abhängigkeit, sondern auch zu hohen Preise führen, gegen die man sich dann unter Umständen nicht wirksam wehren kann.“

Neben der möglicherweise steigenden Anbieterabhängigkeit gibt es weitere Aspekte, die IT-Entscheider berücksichtigen sollten, bevor sie die Teams ihres KI-Anbieters engagieren. Zentral ist etwa die Frage, wie lange die FDE-Teams überhaupt benötigt werden. Schließlich wird es mit einer einzelnen Implementierung kaum getan sein. Die sich daraus ergebenden langfristigen Kosten sind laut John Sangyeob Kim, KI-Engineer bei Solidroad, etwas, das Unternehmen häufig übersehen: „Die Bereitstellung selbst macht vielleicht 20 Prozent der Gesamtkosten aus. Die übrigen 80 Prozent entfallen darauf, den Systembetrieb durch Modell-Upgrades aufrechtzuerhalten, sowie Datenverschiebungen und Randfälle zu händeln, die erst nach Monaten im Produktivbetrieb auftreten.“

Dazu kommen Risiken, die entstehen, wenn das FDE-Team des KI-Anbieters nicht mehr vor Ort ist. Dabei werde beispielsweise in gravierendem Maße unterschätzt, wie umfassend die Einblicke sind, die externe Spezialisten bei der KI-Implementierung gewinnen, meint etwa Justin Greis, CEO der IT-Beratung Acceligence: „Das FDE-Team erhält im Rahmen der Implementierung Insights zu einer Vielzahl operativer Details. Zwar sind die Daten, auf die dabei zugegriffen wird, durch NDAs und Geheimhaltungsklauseln geschützt – die eingesehenen Prozesse und Workflows bleiben jedoch oft außen vor.“

Dieses Problem ist laut Greis aber nicht auf FDE-Teams von KI-Anbietern beschränkt. Wer auch immer bei der Einführung von KI unterstütze, werde deutlich mehr Erkenntnisse gewinnen, als im Statement of Work festgehalten, erklärt der Manager: „Dazu zählen etwa die tatsächlichen, konkreten Arbeitsabläufe, undokumentierte Ausnahmen, Lücken in der Datenqualität, Genehmigungs-Bottlenecks oder Security-Workarounds. Dieses Wissen ist ebenso wertvoll wie sensibel.“

Eine weitere kritische Frage, die laut Greis zu selten gestellt werde: Wie viel sinnvolle Kontrolle wird die IT über das Projekt haben, wenn das FDE-Team seine Unterstützung beendet? „Die Gefahr besteht nicht darin, externe Hilfe in Anspruch zu nehmen – die werden die meisten Unternehmen benötigen. Kritisch wird es vor allem dann, wenn externe Hilfe so eingesetzt wird, dass das Unternehmen nach Beendigung des Auftrags weniger leistungsfähig und abhängiger ist“, konstatiert der CEO.

KI-Experte Kim teilt diese Bedenken und empfiehlt Anwendern insbesondere, zu klären, ob das Projekt auf dem eigenen Observability-Stack oder dem des Anbieters aufbaue: „Wenn der Implementierungspartner den eigenen Observability-Stack nutzt, ist das während des Builds in Ordnung. Aber Sie brauchen einen Plan, um diesen auf eine eigene Lösung zu migrieren, bevor der Anbieter das Projekt beendet. Anderenfalls wird die Visibility mit ihm verschwinden.“

Ein eklatantes Problem entstehe laut Kim hingegen, wenn weder der eigene Observability-Stack, noch der des Anbieters verwendet wird: „Das führt zu einem System ganz ohne Observability-Layer – also ohne Einsichtsmöglichkeit. Wenn in der Produktion etwas ausfällt, haben Sie keine Möglichkeit festzustellen, ob es sich um eine Modellregression, ein Datenproblem oder einen Codefehler handelt.“

Externer KI-Support – die Alternativen

Zwar sind FDE-Teams kein neuartiger Ansatz, dennoch steht nur eine begrenzte Zahl solcher Engineers zur Verfügung. Nicht jedes Unternehmen hat also die Möglichkeit, Spezialisten-Teams von Anbietern einzusetzen. Schwierig wird es mit der FDE-Verfügbarkeit laut Gartner-Analyst Henein insbesondere außerhalb der USA. Das muss jedoch kein Grund sein, auf externen Support in Sachen KI-Implementierung zu verzichten. Schließlich steht Anwendern dazu, wie eingangs dargelegt, eine breite Palette weiterer Optionen zur Verfügung. Diese haben jedoch – ähnlich wie der FDE-Einsatz – nicht nur Vor-, sondern auch Nachteile.

So auch die traditionelle IT-Beratung, wie Ishraq Khan, CEO beim Dev-Tool-Anbieter Kodezi, erklärt: „Klassische Beratungsunternehmen sind in der Regel stärker in den Bereichen Governance, Prozesse, Compliance und organisatorische Koordination. Sie wissen, wie große Unternehmen politisch und strukturell funktionieren. Der Nachteil ist, dass viele langsamer vorankommen und oft keine tiefgreifende Spezialisierung vorweisen können, wenn es um Frontier-KI geht.“

Spezialisierte KI-Beratungsunternehmen wiesen hingegen andere Stärken vor, wie Khan festhält: „KI-native Berater agieren deutlich schneller und sind oft technisch auf dem neuesten Stand. Operativ sind viele dieser Unternehmen aber noch nicht ausgereift. Das schlägt sich dann beispielsweise in beeindruckenden Demos nieder, wobei die langfristige Wartbarkeit, Governance oder Zuverlässigkeit in der Produktion nicht vollständig verstanden wird.“

Acceligence-CEO Greis sieht zudem die Einbindung unabhängiger Auftragnehmer als mögliche Option für externe KI-Unterstützung: „Das kann dem Evaluierungsdesign, Architekturprüfungen, Red-Teaming, Agentendesign zuträglich sein – oder festgefahrene Teams wieder in Gang bringen. Es birgt aber auch das Risiko, sich von einer Schlüsselperson abhängig zu machen – die parallel möglicherweise die Einzige ist, die das System wirklich versteht.“

Für Großunternehmen bietet sich zudem mit dem sogenannten „Acquihiring“ eine weitere Option. Dabei werden (KI-) Unternehmen aufgekauft und dessen Expertise und Mitarbeiter in die eigene Organisation integriert. Unter bestimmten Voraussetzungen könne das ein Gewinn sein, meint Greis: „Nämlich dann, wenn die eingebrachten KI-Fähigkeiten und das Fachwissen für das übernehmende Unternehmen wirklich strategisch wichtig sind. Es besteht dabei jedoch die Gefahr, dass das übernommene Team von der Bürokratie der neuen Muttergesellschaft erstickt wird. Das ist dann in etwa so, als würde man ein Speedboat kaufen, es an einen Flugzeugträger hängen und sich dann wundern, dass es nicht mehr vorankommt.“

Schließlich kann auch eine Open-Source-Strategie Anwenderunternehmen in Sachen KI Flexibilität verschaffen und Abhängigkeiten reduzieren. Das geht allerdings nicht ohne erhöhten operativen Aufwand. Dieser wird ebenfalls häufig unterschätzt, wie Khan darlegt: „Open Source ist nur eine echte Option, wenn die Organisation über die internen Talente und die Disziplin verfügt, um eine ordnungsgemäße Wartung sicherzustellen.“

Externe Unterstützung bei KI-Deployments – die Optionen im Überblick

	Pro	Kontra
FDEs von KI-Anbietern	beste Expertise mit Blick auf das Haupt-KI-Modell	Vendor Lock-In betriebliche Details dringen nach außen
Klassische IT-Beratung	beste Expertise in Sachen Change Management, Legacy-Integration, Rollout, Governance sowie Neugestaltung des Betriebsmodells	möglicherweise zu langsam, zu teuer oder zu generisch
KI-Consulting-Unternehmen	mehr praktische Erfahrung als traditionelle Berater mit Blick auf KI-Deployments Vendor Lock-In weniger ausgeprägt als bei FDEs	unter Umständen mangelndes Verständnis von Enterprise-Anforderungen, etwa in den Bereichen Security, Identity, Auditability, Incident Response, Kostenkontrolle und langfristige Wartbarkeit
Unabhängige Dienstleister	nützlich für Präzisions-Tasks wie Eval Design, Architektur-Reviews, Red Teaming oder Agenten-Design	Risiko der Abhängigkeit von bestimmten Schlüsselpersonen
„Acquihiring“	funktioniert, wenn die eingekauften Fähigkeiten wirklich strategisch wichtig sind	übernommene Teams fallen möglicherweise existierender Bürokratie zum Opfer
Open-Source-Lösungen	reduziert die Abhängigkeit von einzelnen Anbietern attraktiv, wenn es um Datensouveränität, die Kontrolle von Enterprise-Systemen, Kosteneffizienz und regulierte Umgebungen geht	Unternehmen tragen die volle Verantwortung für Security, Patching, Evaluierung, Deployment, Monitoring und Lifecycle Management

(fm)

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

US President Donald Trump on Monday signed a pair of executive orders aimed at accelerating the federal government’s transition to post-quantum cryptography while expanding US investment in quantum technologies, establishing what the administration describes as a coordinated strategy to prepare for the opportunities and risks posed by quantum computing.

The actions include an executive order, “Securing the Nation Against Advanced Cryptographic Attacks,” and a companion order, “Ushering in the Next Frontier of Quantum Innovation.” Accompanying White House fact sheets frame the initiatives as part of the administration’s broader national security, economic competitiveness, and cybersecurity strategy.

For security leaders, the most immediate impact comes from the cryptography order, which establishes federal migration deadlines for quantum-resistant encryption, directs agencies to inventory cryptographic assets, and signals future procurement requirements for government contractors.

“It’s a great step and definitely in alignment with what we’ve seen from other jurisdictions around the world,” Chris Hickman, CISO at post-quantum cryptography company Keyfactor, tells CSO. “It compels action.”

Hickman said the deadlines could have effects far beyond federal agencies because contractors and critical infrastructure operators will face increasing pressure to demonstrate readiness for post-quantum cryptography.

“A lot of suppliers out there don’t want to lose revenue from the federal government, so it’s time to take this stuff seriously,” he said.

The administration argues that adversaries may already be collecting encrypted communications and sensitive data in anticipation of future breakthroughs that could render today’s public key cryptography obsolete.

The White House described the threat as a “harvest now, decrypt later” scenario in which information stolen today could be stored and decrypted years from now once sufficiently powerful quantum computers become available.

Although experts continue to debate how long it will take to build cryptographically relevant quantum computers, federal officials argue that organizations cannot wait until such systems exist before beginning preparations.

The White House said the order builds on a broader administration cybersecurity agenda, including a June 2025 cybersecurity executive order and the Cyber Strategy for America released earlier this year. Officials said the effort is intended not only to protect federal systems but also to accelerate adoption of quantum-resistant security technologies across critical infrastructure sectors and the broader digital ecosystem.

Ilona Cohen, chief legal and policy officer at HackerOne and former general counsel of the White House Office of Management and Budget, said in a statement that recent administration cybersecurity initiatives reflect growing concern about the role contractors play in federal cyber risk. “Federal networks are only as resilient as the contractors supporting them,” Cohen said.

Federal migration deadlines established

The executive order directs federal agencies to accelerate migration to post-quantum cryptography standards developed by the National Institute of Standards and Technology.

NIST finalized its first post-quantum cryptography standards in 2024 and continues to evaluate additional algorithms intended to replace cryptographic systems vulnerable to future quantum attacks.

Under the order, federal agencies must complete migration of key-establishment mechanisms by Dec. 31, 2030. Migration of digital-signature systems must be completed by Dec. 31, 2031. Within 30 days, agencies must designate senior officials responsible for overseeing post-quantum cryptography migration efforts.

The Office of Management and Budget must issue implementation guidance within 90 days, while agencies are expected to develop plans for replacing vulnerable cryptographic systems across federal environments.

The deadlines represent one of the clearest federal mandates to date regarding the timeline for government adoption of post-quantum cryptography.

Cryptographic bill of materials requirements

The order also introduces measures intended to improve visibility into cryptographic dependencies throughout government systems and software supply chains.

Among the most significant is a directive requiring NIST and the Cybersecurity and Infrastructure Security Agency to develop minimum elements for a cryptographic bill of materials (CBOM) within 270 days.

The concept is similar to a software bill of materials but focuses specifically on identifying cryptographic algorithms, libraries, and dependencies embedded within products and systems.

Security practitioners have long argued that organizations cannot effectively migrate to post-quantum cryptography without first understanding where cryptography exists throughout their environments.

The administration also directed NIST to establish a federal post-quantum cryptography migration pilot program by the end of 2027 to identify implementation challenges and develop migration best practices.

Contractors likely to face new compliance obligations

The executive order also signals significant future implications for federal contractors.

The Federal Acquisition Regulatory Council was directed to develop procurement requirements that would require covered contractors to comply with applicable NIST post-quantum cryptography standards by the end of 2030.

While details remain to be determined, the provision suggests federal purchasing requirements may become a major driver of post-quantum cryptography adoption across the technology industry.

Security vendors, cloud providers, software developers, and managed service providers that do business with federal agencies may ultimately need to demonstrate compliance with emerging post-quantum cryptography requirements.

The order’s emphasis on cryptographic inventories, migration planning, and standards compliance suggests federal agencies will increasingly expect suppliers to understand and document the cryptographic components embedded within their products.

Quantum innovation initiative expands

Alongside the cybersecurity order, Trump signed a separate executive order, which intends to accelerate the development of quantum computing and related technologies.

The administration argues that quantum technologies could eventually transform industries, including pharmaceuticals, manufacturing, logistics, energy, and defense, while providing strategic advantages in scientific research and national security.

At the center of the initiative is a government-wide effort known as Quantum Computing for Accelerated Discovery and Development for Science (QC-ADDS), which aims to develop at least one quantum computer capable of enabling what the administration calls “quantum-enabled scientific discovery.”

The Department of Energy, Department of Commerce, Department of Defense, National Science Foundation, NASA, National Security Agency, and elements of the intelligence community are directed to coordinate research and development activities under the program.

Agencies are tasked with developing technical requirements within 90 days and implementation plans within 180 days.

Industry leaders said the order reflects a growing recognition that leadership in quantum computing will require coordinated investment across multiple layers of the technology stack.

“The United States has a window of opportunity to lead in this domain,” Stefan Leichenauer, vice president of engineering at SandboxAQ, said in a statement. “It requires coordinated investment across the stack: cryptography, compute infrastructure, data generation, and application development. It also requires strong partnerships between government, industry, and academia.”

The order also calls for expanded support for quantum networking and quantum sensing technologies and directs the creation of a national capability for evaluating and benchmarking quantum computing systems.

Commercialization, workforce, and security priorities

A major focus of the innovation initiative is moving quantum technologies from research laboratories into commercial deployment.

The White House said the United States must strengthen domestic quantum supply chains, support technology transfer, and ensure federally funded discoveries translate into commercial products and economic growth.

Ankur Saxena, investment director at TDK Ventures, thinks the order reflects the industry’s growing focus on turning scientific advances into deployable technologies. “Quantum is shifting from a scientific frontier to an engineering and industrial race,” Saxena said in a statement. “US leadership will depend not just on breakthrough hardware, but on resilient supply chains and the enabling infrastructure that makes quantum deployable at scale.”

The administration also announced plans to reconstitute the National Quantum Initiative Advisory Committee and expand activities of the Quantum Counterintelligence Protection Team to help protect sensitive research and intellectual property.

The order places significant emphasis on workforce development as well, directing agencies to support quantum-related education, credentialing, and apprenticeship programs and to establish National Quantum Information Science and Technology Workforce Development Institutes.

Two sides of the same strategy

The executive orders reflect an effort to pursue what administration officials view as two sides of the same challenge: accelerating development of quantum technologies while preparing for the security consequences those technologies may eventually create.

For cybersecurity leaders, the post-quantum cryptography provisions are likely to have the most immediate impact. The combination of migration deadlines, cryptographic inventory requirements, pilot programs, and anticipated procurement mandates signals that federal agencies are moving from planning for post-quantum cryptography to implementing it.

For the broader technology sector, the orders underscore a growing consensus in Washington that quantum computing is no longer merely a long-term research project but a strategic technology that requires simultaneous investment, governance and risk management.

US President Donald Trump on Monday signed a pair of executive orders aimed at accelerating the federal government’s transition to post-quantum cryptography while expanding US investment in quantum technologies, establishing what the administration describes as a coordinated strategy to prepare for the opportunities and risks posed by quantum computing.

The actions include an executive order, “Securing the Nation Against Advanced Cryptographic Attacks,” and a companion order, “Ushering in the Next Frontier of Quantum Innovation.” Accompanying White House fact sheets frame the initiatives as part of the administration’s broader national security, economic competitiveness, and cybersecurity strategy.

For security leaders, the most immediate impact comes from the cryptography order, which establishes federal migration deadlines for quantum-resistant encryption, directs agencies to inventory cryptographic assets, and signals future procurement requirements for government contractors.

“It’s a great step and definitely in alignment with what we’ve seen from other jurisdictions around the world,” Chris Hickman, CISO at post-quantum cryptography company Keyfactor, tells CSO. “It compels action.”

Hickman said the deadlines could have effects far beyond federal agencies because contractors and critical infrastructure operators will face increasing pressure to demonstrate readiness for post-quantum cryptography.

“A lot of suppliers out there don’t want to lose revenue from the federal government, so it’s time to take this stuff seriously,” he said.

The administration argues that adversaries may already be collecting encrypted communications and sensitive data in anticipation of future breakthroughs that could render today’s public key cryptography obsolete.

The White House described the threat as a “harvest now, decrypt later” scenario in which information stolen today could be stored and decrypted years from now once sufficiently powerful quantum computers become available.

Although experts continue to debate how long it will take to build cryptographically relevant quantum computers, federal officials argue that organizations cannot wait until such systems exist before beginning preparations.

The White House said the order builds on a broader administration cybersecurity agenda, including a June 2025 cybersecurity executive order and the Cyber Strategy for America released earlier this year. Officials said the effort is intended not only to protect federal systems but also to accelerate adoption of quantum-resistant security technologies across critical infrastructure sectors and the broader digital ecosystem.

Ilona Cohen, chief legal and policy officer at HackerOne and former general counsel of the White House Office of Management and Budget, said in a statement that recent administration cybersecurity initiatives reflect growing concern about the role contractors play in federal cyber risk. “Federal networks are only as resilient as the contractors supporting them,” Cohen said.

Federal migration deadlines established

The executive order directs federal agencies to accelerate migration to post-quantum cryptography standards developed by the National Institute of Standards and Technology.

NIST finalized its first post-quantum cryptography standards in 2024 and continues to evaluate additional algorithms intended to replace cryptographic systems vulnerable to future quantum attacks.

Under the order, federal agencies must complete migration of key-establishment mechanisms by Dec. 31, 2030. Migration of digital-signature systems must be completed by Dec. 31, 2031. Within 30 days, agencies must designate senior officials responsible for overseeing post-quantum cryptography migration efforts.

The Office of Management and Budget must issue implementation guidance within 90 days, while agencies are expected to develop plans for replacing vulnerable cryptographic systems across federal environments.

The deadlines represent one of the clearest federal mandates to date regarding the timeline for government adoption of post-quantum cryptography.

Cryptographic bill of materials requirements

The order also introduces measures intended to improve visibility into cryptographic dependencies throughout government systems and software supply chains.

Among the most significant is a directive requiring NIST and the Cybersecurity and Infrastructure Security Agency to develop minimum elements for a cryptographic bill of materials (CBOM) within 270 days.

The concept is similar to a software bill of materials but focuses specifically on identifying cryptographic algorithms, libraries, and dependencies embedded within products and systems.

Security practitioners have long argued that organizations cannot effectively migrate to post-quantum cryptography without first understanding where cryptography exists throughout their environments.

The administration also directed NIST to establish a federal post-quantum cryptography migration pilot program by the end of 2027 to identify implementation challenges and develop migration best practices.

Contractors likely to face new compliance obligations

The executive order also signals significant future implications for federal contractors.

The Federal Acquisition Regulatory Council was directed to develop procurement requirements that would require covered contractors to comply with applicable NIST post-quantum cryptography standards by the end of 2030.

While details remain to be determined, the provision suggests federal purchasing requirements may become a major driver of post-quantum cryptography adoption across the technology industry.

Security vendors, cloud providers, software developers, and managed service providers that do business with federal agencies may ultimately need to demonstrate compliance with emerging post-quantum cryptography requirements.

The order’s emphasis on cryptographic inventories, migration planning, and standards compliance suggests federal agencies will increasingly expect suppliers to understand and document the cryptographic components embedded within their products.

Quantum innovation initiative expands

Alongside the cybersecurity order, Trump signed a separate executive order, which intends to accelerate the development of quantum computing and related technologies.

The administration argues that quantum technologies could eventually transform industries, including pharmaceuticals, manufacturing, logistics, energy, and defense, while providing strategic advantages in scientific research and national security.

At the center of the initiative is a government-wide effort known as Quantum Computing for Accelerated Discovery and Development for Science (QC-ADDS), which aims to develop at least one quantum computer capable of enabling what the administration calls “quantum-enabled scientific discovery.”

The Department of Energy, Department of Commerce, Department of Defense, National Science Foundation, NASA, National Security Agency, and elements of the intelligence community are directed to coordinate research and development activities under the program.

Agencies are tasked with developing technical requirements within 90 days and implementation plans within 180 days.

Industry leaders said the order reflects a growing recognition that leadership in quantum computing will require coordinated investment across multiple layers of the technology stack.

“The United States has a window of opportunity to lead in this domain,” Stefan Leichenauer, vice president of engineering at SandboxAQ, said in a statement. “It requires coordinated investment across the stack: cryptography, compute infrastructure, data generation, and application development. It also requires strong partnerships between government, industry, and academia.”

The order also calls for expanded support for quantum networking and quantum sensing technologies and directs the creation of a national capability for evaluating and benchmarking quantum computing systems.

Commercialization, workforce, and security priorities

A major focus of the innovation initiative is moving quantum technologies from research laboratories into commercial deployment.

The White House said the United States must strengthen domestic quantum supply chains, support technology transfer, and ensure federally funded discoveries translate into commercial products and economic growth.

Ankur Saxena, investment director at TDK Ventures, thinks the order reflects the industry’s growing focus on turning scientific advances into deployable technologies. “Quantum is shifting from a scientific frontier to an engineering and industrial race,” Saxena said in a statement. “US leadership will depend not just on breakthrough hardware, but on resilient supply chains and the enabling infrastructure that makes quantum deployable at scale.”

The administration also announced plans to reconstitute the National Quantum Initiative Advisory Committee and expand activities of the Quantum Counterintelligence Protection Team to help protect sensitive research and intellectual property.

The order places significant emphasis on workforce development as well, directing agencies to support quantum-related education, credentialing, and apprenticeship programs and to establish National Quantum Information Science and Technology Workforce Development Institutes.

Two sides of the same strategy

The executive orders reflect an effort to pursue what administration officials view as two sides of the same challenge: accelerating development of quantum technologies while preparing for the security consequences those technologies may eventually create.

For cybersecurity leaders, the post-quantum cryptography provisions are likely to have the most immediate impact. The combination of migration deadlines, cryptographic inventory requirements, pilot programs, and anticipated procurement mandates signals that federal agencies are moving from planning for post-quantum cryptography to implementing it.

For the broader technology sector, the orders underscore a growing consensus in Washington that quantum computing is no longer merely a long-term research project but a strategic technology that requires simultaneous investment, governance and risk management.

For years, cybersecurity professionals have been repeating the same warning: Every company will eventually be breached.

Fine. Let’s accept that.

Then why do so many organizations still behave as if the near sole purpose of cybersecurity is to prevent the breach from ever happening?

That is the contradiction at the heart of modern cybersecurity strategy. We say, “Assume the breach,” but we budget, govern, architect, and rehearse as if the wall will hold. We tell boards compromise is inevitable, then ask for more money to make the wall higher, thicker, smarter, and more AI-enabled. We buy more tools. We tune more dashboards. We polish the gate. We call it maturity. And then, when the wall of our gloriously protected city cracks, it turns out that half the city has no food, no command structure, no working roads, no backup water supply, and no idea who is supposed to organize the response.

That is not security. Or at least, it should no longer be understood as security.

Pure prevention is the past

The age of having a pure prevention focus has ended. Not because prevention is dead. That would be a childish argument. WAFs matter. MFA matters. Patching matters. Hardening matters. The familiar machinery still matters: hardened systems, sane configurations, patching discipline, identity controls, endpoint visibility, email defenses, logging, segmentation, and the rest of the security plumbing. Nobody serious is suggesting we kick open the gates and invite the attackers in.

But prevention alone is no longer a credible operating model. It no longer works as the primary focal point. The strategic question is no longer simply, “Can we stop the attack?” The better question is, “Can the organization continue to function when the attack succeeds?” That is the shift. Cybersecurity is not primarily about protection anymore. It is about survival.

Survival means breach readiness. It means continuity. It means recoverability. It means identity restoration when the identity provider is compromised. It means knowing which systems can be rebuilt cleanly and which ones are held together by duct tape, vendor promises, and one engineer we are all praying will never retire. It means backup integrity, crisis governance, legal and communications alignment, supplier fallback, product resilience, clean deployment pipelines, tested incident response, and executives who understand that cyber risk is not a quarterly awareness slide. Survival means designing organizations that can absorb breach, disruption, AI acceleration, supplier failure, regulatory pressure, and systemic shock without collapsing entirely.

This is not just philosophy. The world is moving there whether companies enjoy the view or not.

The critical question

In Europe, under the EU legislative umbrella, cyber resilience is becoming explicit regulatory language. DORA makes digital operational resilience a serious financial-sector obligation. NIS2 widens the net around essential and important entities. The Cyber Resilience Act pushes security into the lifecycle of products with digital elements, from planning and design to development and maintenance. Europe, in its very European way, is saying: You shall be resilient, and there shall be paperwork.

The US is taking a different, perhaps more laissez-faire path. It is pushing accountability through disclosure, enforcement, sector rules, procurement pressure, and public-private nudging. The SEC wants material cyber risk and incidents visible to investors. CIRCIA aims to force critical infrastructure operators to report substantial incidents and ransom payments. CISA pushes Secure by Design pledges. All that sounds good. But there is a catch, and it lies in the unresolved question of criticality.

Critical for whom?

Critical for the government? For consumers? For markets? For the company’s customers? Critical for a supply chain that no regulator has fully mapped because the economy now runs on a cesspool of unmanaged SaaS dependencies?

Europe is increasingly trying to define resilience as an obligation. The US, more characteristically, is trying to produce accountability through disclosure, enforcement, procurement pressure, and market signaling. The problem is that market signaling collapses when nobody wants to admit they are part of the market’s critical nervous system. This is where the comfortable policy language starts to wobble.

“Critical infrastructure” is treated as if it were a natural category. It is not natural. It is political, legal, economic, operational, and worst of all, highly fluid. Companies are trying to avoid being seen as critical when the label brings obligations, reporting duties, scrutiny, liability, and expense. That is not cynicism. That is incentives doing what incentives do: rewarding ambiguity, punishing transparency, and giving everyone a reason to stay conveniently uncritical until the blast radius proves otherwise.

The deeper issue is not only critical infrastructure. It is critical dependency.

A company may not be critical to the state, but it may be critical to every customer that relies on it. A vendor may avoid the regulatory label, but not the blast radius. A minor-looking SaaS provider, identity layer, CI/CD platform, payment processor, LLM tool, MSP, open-source package, or API gateway can become the point where hundreds of organizations discover that their business continuity plan was a PDF bundled in mindless optimism.

This is why voluntary pledges are useful but insufficient. They create norms and language. They help responsible companies signal intent. But a pledge is not a control. A pledge without evidence, enforcement, procurement consequences, customer pressure, or liability is policy theater with potential. Better than silence, yes. Better than mandatory resilience? Not even close.

And then AI permeates the world as an accelerant poured across the entire problem.

The AI uprising

AI compresses time. It lowers attacker skill barriers. It improves phishing, reconnaissance, exploit development, malware support, impersonation, fraud, and social engineering. It also expands the attack surface inside companies through shadow AI, AI agents, sensitive data leakage, automated decisions, insecure integrations, and systems that can act without anyone fully understanding how far their permissions reach.

The uncomfortable part is that defenders need AI, too. Nobody is going to manually out-click, out-triage, and out-correlate machine-speed attacks with heroic analysts and vibes. Defensive AI is necessary. AI-assisted testing is necessary. Runtime analysis is becoming more important. Agentic security workflows will grow. Humans matter, of course, but they will need to move from being button-pushers to decision-makers, validators, and designers of boundaries.

Recent Mythos revelation, whatever one thinks of it, exposed the broader truth: AI is not merely another asset to secure. It changes the tempo of security. It changes what “timely” means. If attackers can move from discovery to exploitation faster than a company can schedule a change committee meeting, prevention-first chest-thumping becomes blind, brainless bravado.

Consequently, that is also where application security becomes central, but not in the narrow old sense.

AppSec shows the way

AppSec has traditionally been treated as prevention: find bugs, fix bugs, block exploit paths, test before release, scan the API, harden the app, stop the vulnerability from becoming an incident. That is still true. But modern AppSec is also resilience. Secure-by-design systems fail less catastrophically. Well-tested applications reduce blast radius. Strong API authorization protects business logic when identity is abused. Good software supply-chain controls make recovery possible because you know what you shipped, where it came from, and whether you can trust it. Continuous testing shortens the time between exposure and correction. Runtime visibility tells you what is actually happening, not what the architecture diagram claimed would happen in calmer weather.

The mature AppSec question is no longer only whether a vulnerability exists. It is how quickly the organization can discover exposure, validate exploitability, prioritize business impact, reduce blast radius, and prove the fix actually reduced risk.

So AppSec is preventive in method, but resilient in strategic value.

That matters because the old budget logic still lingers. Many organizations talk about resilience at the board level while still spending and operating like the real work is another tool, another dashboard, another rule, another exception queue, another heroic security team tuning SIEM alerts at midnight. There is a widening gap between the talk and the walk. The talk says resilience. The walk still mainly says prevention, compliance, and hope.

Resilience becomes duty

This is not to mock prevention. Prevention is valuable. It reduces noise and buys time. It blocks commodity attacks. Prevention keeps the easy doors closed and the lazy criminals moving. Good. Keep it. Fund it. Improve it.

But stop pretending it is the whole castle.

At some point, reinforcing the gate drains us of good iron. Or cash, as may be the case. The cannon is already here. Sometimes the cannon is ransomware. Sometimes it is a supplier compromise. Sometimes it is an AI-assisted vulnerability chain. Sometimes it is a cloud identity failure. Sometimes it is a security vendor update that helpfully demonstrates the concept of systemic risk by taking half the planet down before breakfast.

The organizations that survive will not be the ones with the prettiest walls. They will be the ones that know what happens when the walls fail.

They will know which services matter most. They will know their dependencies, how to isolate blast radius, how to restore from clean sources. They will know who decides, who communicates, who pays, who informs regulators, who speaks to customers, and who has authority to shut something down before the whole environment becomes a crime scene with invoices.

They will practice. Not once a year in a tabletop exercise where everyone nods politely and pretends Legal will respond in real-time. They will practice seriously. They will break assumptions. They will test recovery. They will challenge vendors. They will treat incident response as an organizational muscle, not a binder.

This is also where CISO accountability must be discussed honestly. It is easy to demand accountability from the security leader after the fire. It is harder to ask whether the CISO had budget, authority, board access, engineering influence, product leverage, procurement power, and documented risk acceptance before the fire. If a company wants the CISO to be accountable for survival, then the CISO must be empowered to design for survival. Otherwise, accountability is just corporate theater, and the CISO is one person selected in advance to stand under the falling chandelier.

The same applies to boards. A board that funds only prevention but expects resilience after failure is not governing cyber risk. It is buying a bucketload of denial. Cybersecurity cannot remain a narrow technical department expected to compensate for fragile business architecture, reckless supplier dependence, poor software practices, underfunded recovery, unclear executive authority, and magical thinking about AI.

If cybersecurity is survival, then everyone who shapes organizational resilience shapes cybersecurity. Engineering shapes it. Procurement shapes it. Legal shapes it. Finance, Product, HR, Communications — they all shape it. The board, too, and the CEO. Security may lead the discipline, but it cannot be the only organ responsible for keeping the body alive.

That is the point. Not that prevention no longer matters. Not that we should abandon controls and have minstrels sing of resilience while attackers empty the database. The point is that protection is no longer enough to define security. A company that collapses when prevention fails was never truly secure. It was only protected until the first failure.

The cybersecurity paradigm of today and tomorrow must be built around survival: surviving breach, surviving disruption, surviving AI acceleration, surviving dependency failure, surviving regulatory scrutiny, and surviving the moment when the neat diagram meets the ugly incident.

We still need walls, gates, and guards.

But the wall is not the city, nor its citizens. And if the city and the citizens cannot survive after the wall falls, then maybe the wall was never a viable strategy.

Maybe it was just a waste of that good iron.

AI coding agents are making it easier than ever to produce software. Ensuring that software is secure before deployment is another matter — one that AWS thinks AI should help with too.

As enterprises adopt agentic development workflows, the volume of first-party code being created and modified is rising rapidly. Yet the process of validating vulnerabilities, determining whether they are exploitable, and fixing them often still depends on developers and security teams working through findings manually.

AWS is aiming to address that imbalance with Continuum, a new service designed to continuously discover, investigate, and remediate vulnerabilities in enterprise environments, whether the code is their own or from third parties.

Rather than simply generating alerts, the service is intended to help enterprises move findings through the entire remediation lifecycle, AWS VP of Security and Observability Chet Kapoor wrote in a blog post.

For first-party applications, Continuum can analyze code, validate whether vulnerabilities are exploitable, generate remediation recommendations, and propose fixes that can be reviewed through existing software development workflows, helping developers address security issues without requiring security teams to manually investigate every finding, Kapoor said.

Once users think Continuum has learned enough about their environment and understands their guardrails, they can put it in what AWS calls “enforce mode” to autonomously fix any code lapses, Kapoor said.

Continuum borrows some of its capabilities, penetration testing and code scanning features, from an existing service, Security Agent.

Other capabilities are all-new, including threat modeling, which is designed to automatically generate threat models from source code or design documents and output them in STRIDE format.

Keeping pace with AI-driven software development

Analysts see Continuum helping enterprise developer teams ship more secure code while keeping pace with AI coding tools.

“The harder problem is no longer just finding issues, it is knowing which ones are real, which ones matter in their environment, and which ones need to be fixed first,” said Akshat Tyagi, associate practice leader at HFS Research. “Traditional workflows built around dashboards and manual triage struggle with that volume. A dashboard can show the backlog, but it does not validate the finding, assess business impact, or help remediate it.”

Continuum’s value, according to Tyagi, “is not just more detection, but using AI to prioritize risk findings, suggest mitigations, and support faster action while keeping humans in control of high-risk decisions.”

Taking faster action is becoming increasingly important as attackers are gaining access to many of the same AI capabilities that enterprises are using to accelerate software development and security testing, according to Amit Chandak, chief analytics officer at IT consulting firm Kanerika. “The gap between a flaw being disclosed and a working exploit is shrinking rapidly from months to hours,” he said.

While Continuum may reduce repetitive work for developers and SREs, it could also create new responsibilities for CISOs around governance, oversight, testing, and maintaining guardrails for automated actions.

“Continuum changes the CISO’s role from managing findings to governing how findings are handled. The focus moves to setting rules: what can be automated, what needs human approval, and what level of risk is acceptable in production,” Tyagi said. “Staffing will shift too. There may be less manual triage, but more need for people who can review AI-generated fixes, set guardrails, and know when not to trust the system.”

Even so, Chandak does not expect the offering to lead to immediate headcount reductions, particularly given that Continuum is only available as a gated preview.

Continuum could change how CISOs measure work, Tyagi said: “Ticket count matters less. Better measures are how quickly real risks are validated and fixed, how many false positives are removed, and whether automation is reducing risk without causing new problems.”

Those same metrics could also become a yardstick for CISOs determining how much autonomy to give tools like Continuum, said Chandak. Most enterprises’ data and governance practices are not yet ready for fully autonomous remediation, said Chandak, adding that, “AWS’ graduated trust design, under which enterprises have the option of choosing the degree of autonomy, from human in the loop to fully automatic remediation, is an admission of that fact.”

Beyond first-party code

Continuum could also help CISOs with third-party code vulnerability analysis, where enterprises often have less visibility and control.

“Most third party vulnerability alerts are noise. A tool may flag a vulnerable library, but the real question is whether that vulnerable code is actually used in production. If Continuum can answer that, it helps teams focus on the few issues that matter,” Tyagi said. “This is especially useful for open-source and software supply chain risk, where enterprises depend on packages and hidden transitive dependencies they may not fully track. It also helps when no patch is available yet.”

However, he warned, Continuum might not offer a direct fix to third-party code: “You usually cannot patch third-party code yourself as you don’t own it, so remediation there means version pinning or compensating controls.”

This article first appeared on InfoWorld.

AI coding agents are making it easier than ever to produce software. Ensuring that software is secure before deployment is another matter — one that AWS thinks AI should help with too.

As enterprises adopt agentic development workflows, the volume of first-party code being created and modified is rising rapidly. Yet the process of validating vulnerabilities, determining whether they are exploitable, and fixing them often still depends on developers and security teams working through findings manually.

AWS is aiming to address that imbalance with Continuum, a new service designed to continuously discover, investigate, and remediate vulnerabilities in enterprise environments, whether the code is their own or from third parties.

Rather than simply generating alerts, the service is intended to help enterprises move findings through the entire remediation lifecycle, AWS VP of Security and Observability Chet Kapoor wrote in a blog post.

For first-party applications, Continuum can analyze code, validate whether vulnerabilities are exploitable, generate remediation recommendations, and propose fixes that can be reviewed through existing software development workflows, helping developers address security issues without requiring security teams to manually investigate every finding, Kapoor said.

Once users think Continuum has learned enough about their environment and understands their guardrails, they can put it in what AWS calls “enforce mode” to autonomously fix any code lapses, Kapoor said.

Continuum borrows some of its capabilities, penetration testing and code scanning features, from an existing service, Security Agent.

Other capabilities are all-new, including threat modeling, which is designed to automatically generate threat models from source code or design documents and output them in STRIDE format.

Keeping pace with AI-driven software development

Analysts see Continuum helping enterprise developer teams ship more secure code while keeping pace with AI coding tools.

“The harder problem is no longer just finding issues, it is knowing which ones are real, which ones matter in their environment, and which ones need to be fixed first,” said Akshat Tyagi, associate practice leader at HFS Research. “Traditional workflows built around dashboards and manual triage struggle with that volume. A dashboard can show the backlog, but it does not validate the finding, assess business impact, or help remediate it.”

Continuum’s value, according to Tyagi, “is not just more detection, but using AI to prioritize risk findings, suggest mitigations, and support faster action while keeping humans in control of high-risk decisions.”

Taking faster action is becoming increasingly important as attackers are gaining access to many of the same AI capabilities that enterprises are using to accelerate software development and security testing, according to Amit Chandak, chief analytics officer at IT consulting firm Kanerika. “The gap between a flaw being disclosed and a working exploit is shrinking rapidly from months to hours,” he said.

While Continuum may reduce repetitive work for developers and SREs, it could also create new responsibilities for CISOs around governance, oversight, testing, and maintaining guardrails for automated actions.

“Continuum changes the CISO’s role from managing findings to governing how findings are handled. The focus moves to setting rules: what can be automated, what needs human approval, and what level of risk is acceptable in production,” Tyagi said. “Staffing will shift too. There may be less manual triage, but more need for people who can review AI-generated fixes, set guardrails, and know when not to trust the system.”

Even so, Chandak does not expect the offering to lead to immediate headcount reductions, particularly given that Continuum is only available as a gated preview.

Continuum could change how CISOs measure work, Tyagi said: “Ticket count matters less. Better measures are how quickly real risks are validated and fixed, how many false positives are removed, and whether automation is reducing risk without causing new problems.”

Those same metrics could also become a yardstick for CISOs determining how much autonomy to give tools like Continuum, said Chandak. Most enterprises’ data and governance practices are not yet ready for fully autonomous remediation, said Chandak, adding that, “AWS’ graduated trust design, under which enterprises have the option of choosing the degree of autonomy, from human in the loop to fully automatic remediation, is an admission of that fact.”

Beyond first-party code

Continuum could also help CISOs with third-party code vulnerability analysis, where enterprises often have less visibility and control.

“Most third party vulnerability alerts are noise. A tool may flag a vulnerable library, but the real question is whether that vulnerable code is actually used in production. If Continuum can answer that, it helps teams focus on the few issues that matter,” Tyagi said. “This is especially useful for open-source and software supply chain risk, where enterprises depend on packages and hidden transitive dependencies they may not fully track. It also helps when no patch is available yet.”

However, he warned, Continuum might not offer a direct fix to third-party code: “You usually cannot patch third-party code yourself as you don’t own it, so remediation there means version pinning or compensating controls.”

Longtime security leader Doug Kersten has expanded his list of responsibilities.

As CISO of software maker Appfire, he now has accountability for business risks, such as how security tools and processes within customer products and services impact their costs and, thus, profitability.

It’s a clearcut example, he says, of where and why CISOs must consider not purely security risk, but also business risk.

“CISOs need to provide input and remediation on the impact of security cost because these often-hidden costs have a negative impact on profitability,” he says. “This is usually overlooked by finance teams when analyzing the true cost of goods sold, and if CISOs are not plugged into the evaluation of business risk, it can easily be dismissed.”

The expansion of Kersten’s remit into business risk isn’t unique. CISOs across industries are increasingly expected to identify and address business risks that in the past had been outside the bounds of their roles.

“While CISOs traditionally focused on protecting systems, networks, and data, today’s business environment requires security leaders to understand how cyber threats impact revenue, operations, customer trust, regulatory obligations, supply chains, and strategic objectives,” says Dale Hoak, CISO at software firm RegScale. “The distinction between business risk and security risk is becoming increasingly blurred.”

As such, CISOs today must be enterprise risk leaders, he says, capable of advising executives on how security decisions affect the organization’s ability to achieve its business objectives — not just how they impact the IT stack or technology performance.

Understanding business risk is a significant task, experts agree, but they stress that security chiefs are capable of mastering the skill. Here, Kersten, Hoak, and other security leaders offer strategies on how to do so.

1. Partner with the owners of business risk

By his own admission, Roland Palmer, CISO and vice president of tech company JumpCloud, has yet to master business risk. So he’s partnering with those in his organization who own it, so he has opportunities to learn and contribute.

“We form a great team to understand risk and the organization’s risk appetite,” he says.

Team members include leaders from legal, finance, and marketing, as well as the COO.

Kersten similarly leans on business leaders to sharpen his understanding of business risk. Last year Kersten, working with his exec colleagues, devised a program assigning business leaders to security risks.

“Security helps them understand the security risks, but they also bring to us the [associated] business risks and what can be done to mitigate them,” he explains, noting that this approach also surfaced risks that have since been addressed, thereby closing gaps that were previously unknown.

2. Align cybersecurity explicitly to business objectives

Kerstan believes security teams must understand business objectives, so they can understand what risks could derail which objectives. To ensure his security program has that knowledge, he incorporates corporate objectives and key results into his security strategy.

“I build out plans to address those business objectives and key results. I still have that parallel tier of security risk, which is handled by the security team; that doesn’t go away. But layered onto this is the business OKRs that I need to execute against,” he explains. “It changed how we look at risk and what we have to do.”

For example, he now considers how security department actions may impact employee satisfaction and how that relates to employ retention, a business risk identified by HR, “so we’re working to make sure what we do aligns to the needs of the HR department.”

Richard Watson, global cybersecurity leader with professional services firm EY, agrees with the need to “align cybersecurity explicitly to business objectives.”

“Map cyber controls to critical assets and business processes, and link these to potential financial impact,” he advises. “This enables CISOs to translate technical exposure into business terms and prioritize investment accordingly.”

3. Lean into networking and relationships

Another effective way to get a good grasp on business risks: talking with business colleagues. Regular conversations often yield insights into what truly has them worried, says Gary Hayslip, a cybersecurity executive and co-author of the CISO Desk Reference Guide.

“Another thing I have done to understand business risks, and I have recommended it to peers, is doing a walk-about or what some people call a listening tour,” he says. “I do this in every role I am in because I feel it’s important to understand their objectives, the technologies they use, the projects they have ongoing, the issues they may have with the security program, and, finally, what genuinely keeps them up at night.”

Others say they take a similar approach, stressing the value of networking and building relationships where colleagues feel comfortable raising concerns and collaborating on solutions.

“Business risk cannot be managed in isolation. CISOs should regularly engage with the CFO, COO, general counsel, chief risk officer, product leaders, and business unit executives,” Hoak says. “These conversations provide insight into emerging business concerns and help security become part of strategic planning rather than a downstream compliance exercise.”

4. Run tabletop exercises focused on business risk

This is a more structured opportunity, but an equally effective one, to gain more insights into business risks — so long as the exercises put the business front and center, Hayslip says.

“Most tabletop exercises conducted by the CISO and security teams remain technical and stop at containment. I have found it’s better to run scenarios that force the executives into the decisions they’d actually make during a crisis, such as whether to pay a ransom, when and what to disclose if there is a data breach, how to handle customers, when and who should invoke legal privilege, and is there an operational fallback available and if so who makes the decision to activate it,” Hayslip says.

“Running these types of scenarios helps stress-test the company’s response and teaches the CISO and security team how their peers make decisions under pressure,” he adds.

5. Study up on business risk

Sean Murphy, senior vice president and CISO at BECU, the fifth-largest credit union in the US, didn’t leave learning about business risk to serendipity. He sought out opportunities for formal learning, such as earning the Directorship Certification from the National Association of Corporate Directors. The certification verifies the holder’s expertise in governance, fiduciary duties, strategy, and risk oversight.

Murphy sought the certification to strengthen his qualifications for a board position and to better understand the perspectives of his company’s board, including how it views risk. “The certification helps me delve into what the board cares about and their world and helps me then turn that back to my team and what we’re doing,” he adds. “It gives me the business and executive view versus a purely technical and security view.”

Others offer similar learning strategies.

“The CISO needs to see the company the way the CEO, CFO, and board do,” Hayslip says. “To begin, I would recommend sitting down with the 10-K or annual report, the investor deck, and the earnings call transcripts. This will help the CISO understand how the company makes money and which products or business units drive revenue. It also helps the CISO understand what the leadership team is publicly telling the Street about key risks and where they believe revenue growth will come from in the next reporting cycle.”

This work, while perhaps previously not essential for traditional security leaders, is becoming an imperative today.

“This isn’t fun; in fact, it can be boring,” Murphy says. “But the CISO can’t prioritize protecting the business if they don’t know which parts of the business are considered critical. The annual report provides that view in the words of management.”

Veteran security leaders also cite the value of earning certifications from ISACA, a professional association for governance and risk professionals, as well as the Institute of Internal Auditors’ Certified Internal Auditor designation.

6. Integrate security into enterprise risk management

To truly master business risk, CISOs should not treat it as separate from security risk.

“Cyber is now an existential business risk, not just an IT risk,” says Scott Melchior, a member of ISACA’s Emerging Trends Working Group with 20 years of experience at a global consulting firm focusing on governance, risk, and compliance. “Digital infrastructure is business infrastructure. They’re too intertwined to separate.”

Hoak agrees, stressing the need for CISOs to integrate security into enterprise risk management.

“Cyber risk should be incorporated into broader enterprise risk management processes alongside financial, operational, legal, and strategic risks. This creates a common framework for evaluating risk and helps executive leadership view cybersecurity within the context of overall business objectives,” he says.

Hayslip has put this into practice. In his CISO roles, he has plugged the security risk register into the organization’s ERM platform. He says this allowed him to present cyber-related risks on the same platform that the board already reviews alongside financial, operational, and strategic risks.

“The goal is for cyber risks to appear on the enterprise heat map as every other material risk, so they compete for resources and attention on equal terms rather than being a sidebar,” Hayslip says. “Now there is some work involved for the CISO to do this correctly, but it’s critically important to quantify cyber risk in dollars and probability, not colors. Moving from qualitative heat maps to financial impact numbers, I have found, is one of the biggest improvements in getting the business to hear the CISO.”

For years, resilience and data security operated in separate organizational silos. The resilience team focused on keeping systems running, while the security team focused on keeping data safe. They attended different briefings, reported through different chains of command, and, in most enterprises, barely spoke to each other. AI is making that model no longer viable.

Steve MacIntyre, SVP and product lead for data security and analytics, and cloud security at Fidelity Investments, and Wim Geurden, EY’s chief architect of enterprise technology, are two IT executives who manage some of the most complex data environments. Both recently spoke at the VeeamON event in New York and put great emphasis on how the convergence of resilience and data security is no longer a future trend but an immediate operational necessity, driven, accelerated, and exposed by AI.

AI didn’t create the problem — it revealed it

AI isn’t introducing new security vulnerabilities so much as it’s making long-ignored ones glaringly visible. “We gave out a few licenses for Copilot, and two days in, someone from the legal team I work with said we have an AI problem,” said MacIntyre about Fidelity’s early Microsoft 365 Copilot pilot. Another member of his team did a search and said AI found all the PowerPoints that were on SharePoint he used about four jobs ago. So it wasn’t an AI problem. “AI just searches everything you have access to and surfaces it in a meaningful way,” said MacIntyre. “Everybody thinks they have an AI problem, but what it shows is areas that must improve.”

Geurden encountered the same phenomenon at EY. “We found it about six months before Copilot was launched,” he said. “All kinds of data started surfacing in every location.” EY’s first response was to shut down unlicensed AI access entirely. “There was no lifecycle management and we didn’t know when sites were last accessed,” he added. The next phase involved using AI to label and classify the vast repositories of unstructured data EY had accumulated over decades, because, he said, it’s unfathomable that humans do it. “Especially with turnover every four years, you can’t keep training people at a 400,000-employee scale,” he continued.

The implication for CIOs is if you haven’t audited your unstructured data, you already have an AI security problem. You just need to turn on the tool that will expose it.

The threat is moving at AI speed

The urgency isn’t a hypothetical one. A recent BCG CISO survey found that half of cyberattacks over the past six months involved non-human identities, meaning adversaries are already deploying AI agents to conduct attacks. The same survey found that nearly half of business-sponsored AI projects resulted in unintended data leakage. These aren’t shadow IT experiments but sanctioned and approved deployments that leaked data because the underlying governance and access controls weren’t in place before the AI was turned on.

The problem is likely to worsen before it improves. Another study, this time by ZK Research, found that 65% of respondents believe AI adoption is outpacing their ability to govern it. Additionally, 89% of decision makers expressed concern about AI agents inheriting excessive access, underscoring a critical risk to data integrity and security. All these data point to a world where AI creates a fundamentally new operating model, where companies need to rethink how they address the risks and why the traditional separation between resilience and security must end.

Resilience without data governance means you can recover your systems, but not trust the data within them. Security without resilience planning means your controls may be sound on Tuesday, but nonexistent after a Wednesday incident. The organizations getting this right treat data as a first-class asset with its own governance lifecycle, rather than an afterthought attached to applications.

Three governing principles

Based on what MacIntyre and Geurden say, here are three concrete principles for CIOs to build integrated resilience and a strong security posture for the AI era.

Know what you have before you deploy what you want. “Get a handle on what’s actually important for the business and the use cases, and then get a handle on your data,” said MacIntyre. “If you can marry those two, you can make risk-based decisions on where to apply the work.” This means completing a data asset inventory — not just a list of systems, but a clear understanding of where data resides, who owns it, who has access, and whether that access has been reviewed. At Fidelity, this means tying AI use cases to approved projects so every agent or model deployment is matched to a registered business need. This is easier said than done, however, as the data within most organizations is messy. But getting a handle on data is a mandatory step toward AI success.

Build governance that moves at the speed of the threat. MacIntyre also acknowledged that GRC has historically been a slow, human-driven process, and AI is breaking that model. “They’re trying to figure out how to build automation, how to use AI to help the GRC function get aligned to this, because it’s moving at light speed,” he said. The answer isn’t simply to hire more compliance staff, but automate the monitoring, labeling, and control verification functions that humans can’t perform at AI scale.

Solve the agent identity problem now before regulators force you to. Both MacIntyre and Geurden flagged AI agent identity as one of the most unresolved and most consequential challenges in enterprise AI governance. Geurden described agents triggering unexpected SAP licensing costs as a first signal. MacIntyre raised the regulatory stakes in that he needs to be able to go backward. “I need to be able to say an agent took that action on that data set because a customer asked it to do it,” he said. That audit trail, from human intent to agent action to data record, doesn’t yet exist cleanly in most enterprises. And building it isn’t optional. In financial services and regulated industries, it’s a matter of when not if regulators demand it.

The cloud journey was a preview

MacIntyre offered a useful frame for the CIO community in that the AI governance challenge is structurally similar to the cloud transition, and enterprises that went through that migration have hard-won lessons that apply now. “When the explosion of AI happened, it didn’t just affect security and the attackers,” he said. “It also impacted the business, increasing velocity, and the ability to innovate and move faster. So we have to be there and be able to safely enable that for them.”

The instinct to block AI entirely will fail, just as blocking cloud adoption failed a decade ago. Business units will find workarounds. The job of the CIO and CISO, therefore, is to channel that velocity through governed, instrumented, and recoverable infrastructure.

Geurden’s framing from EY’s audit practice added a useful warning about overconfidence. Three years ago, the firm tested whether AI could pass the CPA exam. It could, easily, but the team quickly discovered that for complex professional judgment questions, the model assigned roughly equal probability to multiple answers. “At which point, you can’t build a control structure because you have to check everything it does,” he said. That discovery slowed EY’s AI rollout in the audit practice and arguably saved them from a much larger exposure. The lesson is that capability and trustworthiness aren’t the same thing, and closing that gap requires exactly the kind of integrated data governance and resilience architecture that most enterprises have yet to build.

AI has knocked down the wall between resilience and security, and CIOs who rebuild it will spend the next three years reacting to incidents. But those who build a unified data trust architecture will be the ones empowering the business to move fast with confidence, and that’s a position all CIOs should strive to be in.

The Oracle Critical Security Patch update (CSPU) released this week contains 245 newly-announced fixes for supported on-premises software, some of which impact multiple products. It is in reaction to an industry trend to announce and fix security holes much more quickly, and complements Oracle’s traditional quarterly patch schedule.

The current batch of patches affects a wide range of products, including Oracle Enterprise Manager, JD Edwards, Fusion Middleware, MySQL, Peoplesoft, and others.

Oracle said its aim is to provide targeted, high-priority security fixes in a smaller, more focused format, making them easier to apply with minimal disruption. “Oracle conducts an analysis of each security vulnerability addressed by a Critical Security Patch Update,” the company said. “Oracle provides this information so that customers may conduct their own risk analysis based on the particulars of their product usage.”

Flavio Villanustre, CISO for LexisNexis Risk Solutions, said that although they’re all designated high priority, he viewed some of the patches as more concerning. 

“The PeopleSoft patch for CVE-2026-35273 stands out [because] it addresses a critical remote code execution vulnerability in Oracle PeopleSoft, which is widely exploited in the wild. This patch was released as an out-of-band Security Alert and requires immediate remediation,” Villanustre said.

“But not far behind, there are the patches to Oracle Fusion, which received a hundred or so patches with more than half classified as remote exploits without authentication. These affect components such as WebLogic Server.”

Some of those patches were for Oracle Fusion Middleware products, a number which are reaching end of support from Oracle by the end of the year. Villanustre, however, did not see the many security holes identified within them as especially concerning. 

He pointed out, “Oracle offers extended support for [Fusion Middleware] until December 2027 for those with the appetite to pay more money in lieu of upgrading, so it will still be supported for 18 more months, starting now.” 

Sanchit Vir Gogia, chief analyst at Greyhound Research, said that the significance of the Oracle announcement is not in the very large number of patches but in their scope.

“The figure worth watching is not the 245 patches but where they land,” he noted. “Of the 245 fixes, 106 sit in Fusion Middleware and 53 of those can be reached remotely without authentication. That is not patch hygiene. That is a control-plane problem.”

The most serious flaws, however, are not those with the highest severity scores. “They are the ones that combine remote reach, absent authentication and privileged placement in layers that other systems are built to trust,” he said.

“WebLogic Server carries two such issues at the maximum severity, on a product attackers have scanned for and targeted for years,” he noted. “Oracle Coherence carries another, and Coherence is a shared component, so its risk multiplies quietly across the estate. Oracle Unified Directory can be taken over without authentication over LDAP. WebCenter sits at the public edge. Several of these flaws change scope, meaning one compromise can reach products well beyond the one first breached.”

Chris Doyle, the head of security and compliance at JupiterOne, said that, like Gogia, the vulnerabilities that concerned him the most were those that could be executed without having to bother to steal credentials.

“The flaws that stand out the most are the CVSS 10.0 vulnerabilities in Oracle Coherence and WebLogic Server, remotely exploitable with no authentication required. Coherence sits underneath a lot of enterprise application stacks, so compromising it isn’t just one system, it’s a pivot point into everything that depends on it,” Doyle said.

And, he added, “WebLogic has been a ransomware and crypto mining target for years and unauthenticated console access is exactly the foothold those campaigns look for.”

Doyle said he was also worried about the PeopleSoft holes.

“The one carrying the most immediate urgency is CVE-2026-35273 in PeopleSoft PeopleTools, which Oracle confirmed was already being actively exploited before this patch even shipped, and PeopleSoft runs the HR, finance, and student systems that ransomware operators specifically target,” Doyle said. “These are deeply coupled systems that require coordinated upgrades across multiple layers with regression testing at each step. There’s often no easy compensating control to buy time, you just have to patch your way through it.”

The Fusion Middleware problems — Oracle cited more than 30 vulnerabilities in this batch alone — also presented a problem, given how most enterprise IT operations handle patching for EOL products.

“Organizations still on it are now trying to patch a heavily targeted product while simultaneously planning a migration they can’t defer. These environments are heavily customized, which makes patching slow, and that gap between ‘patch available’ and ‘patch applied’ is exactly when attackers move,” Doyle said.

“Once support ends, new vulnerabilities may get no patch at all,” he noted. “Given the volume we’re seeing in just this one cycle, assuming things will quiet down before the sunset deadline isn’t a bet I’d want to make.”

Gogia added that there is little good news associated with the security holes that have not been confirmed as having been used by attackers. 

“The absence of confirmed exploitation elsewhere is no comfort. Once an advisory is published, attackers read it, reverse the fix, scan the exposed enterprise environments and race the customers still waiting on a maintenance window,” Gogia said.

“WebLogic has not suddenly become dangerous. It has been a standing target for years, and one of its earlier flaws already sits on the [Known Exploited Vulnerabilities] government catalogue. Waiting for public proof of exploitation is the most expensive patch strategy on the menu. By the time the proof arrives, the quiet work is generally done.”

The upper ranks of corporate security are seeing a high rate of change as companies try to adapt to the evolving threat landscape. Many companies are hiring a chief security officer (CSO) or chief information security officer (CISO) for the first time to support a deeper commitment to information security.

Follow this column to keep up with new appointments to senior-level security roles and perhaps gain a little insight into hiring trends. If you have an announcement of your own that you would like us to include here, contact Peter Sayer, executive editor of news, at peter_sayer@foundryco.com.

New CISO appointments in June 2026

SolarWinds appoints Justin Henkel as CISO

IT management software vendor SolarWinds has named Justin Henkel its new CISO. Henkel was previously deputy CISO at OneTrust, and before that spent 25 years as an intelligence officer in the US Air Force.

New CISO appointments in March 2026

Kathy Wang joints micro1 as CISO

Frontier AI model training company micro1 has hired Kathy Wang as CISO. She was most recently CISO at hospitality software developer Otelier, and has previously held top cybersecurity roles at Discord and GitLab.

Green Impact Exchange names John Visneski CISO

John Visneski has joined stock exchange operator Green Impact Exchange as CISO. He was previously CISO at MGM Studios, and following that company’s acquisition by Amazon became head fo security for mergers and acquisitions. His cybersecurity career began with the US Air Force, where he served as cyber advisor to the Secretary and Chief of Staff of teh Air Force.

New CISO appointments in January 2026

Julien Mousqueton joins Cohesity as field CISO for Europe

Data security firm Cohesity has hired Julien Mousqueton as field CISO for Europe. His previous role was as CTO at IT service provider Computacenter. He is a reservist advisor for OFAC, the French national police force’s anti-cybercrime division, and created the real-time ransomware activity-tracking platform ransomware.live.

Im Darknet möchte wohl kein CISO die Daten seines Unternehmens sehen. Es besteht aus Webseiten, die von gängigen Suchmaschinen nicht erfasst werden. Dieser verborgene Teil des Internets dient sowohl legitimen als auch kriminellen Zwecken und umfasst unter anderem Marktplätze für Daten, die im Rahmen von Cyberangriffen gestohlen oder kompromittiert wurden. Diese können von Cyberkriminellen dazu genutzt werden, um weitere Angriffskampagnen zu initiieren, beispielsweise Spear Phishing.

Unternehmen, die feststellen können, ob Daten aus ihren Netzwerken auf solchen Darknet-Plattformen feilgeboten werden, können die daraus resultierenden Angriffsversuche besser abwehren. Zudem eignet sich das Darknet auch hervorragend als Quelle, um Informationen über die Prozesse, Taktiken und Absichten krimineller Hacker zu sammeln. Das funktioniert über Softwarelösungen, die darauf ausgelegt sind, das Darknet auf kompromittierte Daten zu überwachen.

Darknet-Monitoring-Tools – die besten Lösungen

Im Folgenden finden Sie einige der populärsten Darknet-Monitoring-Tools. Diese Auflistung erhebt keinen Anspruch auf Vollständigkeit.

Brandefense

Brandefense ist ein KI-gesteuerter Digital Risk Protection Service, der sowohl das frei zugängliche Web als auch das Darknet scannt, um Details zu Angriffsmethoden oder Datenschutzverletzungen zu sammeln und diese Daten zu korrelieren und zu kontextualisieren. Sobald ein Vorfall als relevant für den jeweiligen Anwender erachtet wird, wird eine Warnmeldung augegeben. Diese Lösung ist außerdem in der Lage, Takedowns gegen Bedrohungsakteure durchzuführen – anstatt erst darauf zu warten, dass der Angriff erfolgt.

Ein weiterer Schwerpunkt liegt bei diesem Tool auf dem Schutz für hochrangige Führungskräfte. Diese stehen schließlich nicht nur direkt mit der Unternehmensmarke in Verbindung, sondern sind auch beliebte Ziele für diverse Angriffe, unter anderem Spear-Phishing-Kampagnen.

Crowdstrike Falcon Adversary OverWatch

CrowdStrike bietet mit Falcon Adversary OverWatch eine rund um die Uhr verfügbare Threat-Hunting-Plattform. Diese kombiniert die Branchenexpertise des Anbieters mit künstlicher Intelligenz, um Bedrohungsakteure proaktiv zu identifizieren und in Echtzeit zu stoppen. Die Lösung liefert zudem weitere Darknet-Einblicke zu Daten, die Bezüge zu Unternehmens-Assets, -Identitäten und -Marken aufweisen.

CTM 360

Dieser Anbieter aus Malaysia hat zwei verschiedene Lösungen im Angebot, die das Darknet überwachen:

• CyberBlindspot fokussiert auf Informationen, die direkt mit Unternehmens-Assets in Verbindung stehen. Das Tool erweitert dabei das Indicators-of-Compromise-Konzept, um Warn- oder Angriffsindikatoren zu identifizieren.
• ThreatCover bietet hingegen ein Toolset für Sicherheitsanalysten, um Threat-Intelligence-Feeds besser zu durchforsten. Auf dieser Grundlage können Incident-Response-Teams eine Reaktion auf Vorfälle einleiten.

DarkOwl Vision UI

DarkOwl verspricht mit Vision UI einen vereinfachten Einblick in relevante Darknet-Daten. Das Tool ermöglicht dazu unter anderem, kuratierte Darkweb-Daten-Feeds nach Standard-Text oder booleschen Logiken zu durchsuchen. Neben interaktiven Suchen bietet dieses Monitoring-Tool auch Benachrichtigungen und Alerts sowie Exposure-Metriken. Letztere versuchen, die Exposure auf Basis diverser Faktoren und Quellen zu quantifizieren.

IBM X-Force Exchange

Bei IBM X-Force Exchange handelt es sich in erster Linie um eine Plattform für die gemeinsame Nutzung von Daten. Diese führt Threat- und Intelligence-Feeds in einer interaktiven, durchsuchbaren Datenbank zusammen und lässt sich über APIs und automatische Warnmeldungen in bestehende Sicherheitssysteme integrieren. Eine Registrierung ist erforderlich, um relevante Suchvorgänge speichern und Feeds tracken sowie individuell anpassen zu können. Für API-Zugang, erweiterte Analysen und Threat-Intelligence-Berichte auf “Premium-Niveau” ist ein Abonnement erforderlich.

Malware Information Sharing Platform (MISP)

MISP ist eine Open-Source-Plattform, die auf der Idee basiert, Threat-Intelligence-Daten gemeinschaftlich zu nutzen. Die quelloffene Software lässt sich im Rechenzentrum oder auf diversen Cloud-Plattformen installieren. Dabei werden Open-Source-Protokolle und -Datenformate genutzt, die mit anderen MISP-Benutzern geteilt sowie in alle gängigen IT-Sicherheits-Tools integriert werden können. Die Threat-Intelligence-Feeds werden bei dieser Lösung zwar nicht auf dieselbe Weise kuratiert wie bei kommerziellen Tools. Aber die Lösung stellt eine kostengünstige Möglichkeit für Unternehmen dar, um internes Darknet-Monitoring zu etablieren.

Mandiant Digital Threat Monitoring

Auch Mandiant bietet mit Digital Threat Monitoring Einblicke darüber, welche Unternehmensdaten oder -geheimnisse im offenen oder verborgenen Teil des Internets kursieren. Diese Daten werden mit Hilfe von Machine Learning kontextbezogen aufbereitet. Im Ergebnis verspricht Mandiant relevante, priorisierte Warnmeldungen, die den Triage-Prozess erleichtern sollen. Neben Brand- und VIP-Monitoring kann diese Lösung auch Partnerunternehmen überwachen. Das kann dabei helfen, die eigene Lieferkette weiter abzusichern und domänenübergreifende Angriffe zu verhindern, die bestehende Sicherheitskontrollen umgehen könnten. Mandiant bietet sein Monitoring-Tool zudem auch als Zusatzmodul an, was es Anwendern ermöglicht, Threat Intelligence um Darknet-Monitoring zu erweitern.

OpenCTI

Eine weitere Open-Source-Option, um Threat-Intelligence-Daten zu sammeln und zu verwalten ist OpenCTI. Das Programm wurde von Filigran entwickelt und kann als Docker-Container plattformunabhängig eingesetzt werden. Zudem bietet diese Lösung eine Vielzahl von Konnektoren zu anderen Sicherheitsplattformen und Software-Tools, um den OpenCTI-Datenstrom zu integrieren und weiter anzureichern. Zum Funktionsumfang von OpenCTI gehören rollenbasierte Zugriffskontrollen für Security-Teams, standardisierte Datenmodelle sowie Attribuierungsdaten, die darüber Auskunft geben können, wo die Bedrohungswurzel liegt. Darüber hinaus lassen sich mit dem OpenCTI-Client für Python, den OpenCTI-APIs und einem benutzerfreundlichen Framework das sämtliche Arten von Automatisierungen realisieren.

SOCRadar Advanced Dark Web Monitoring

SOCRadar bietet verschiedene Dienste und Tools für Sicherheitsexperten an, darunter eine Reihe kostenloser Tools. Für eine umfassendere, lückenlose Darknet-Überwachung empfiehlt sich jedoch ein Abonnement dieses Service. Dieser bietet eine Überwachung auf persönlich identifizierbare Informationen, trackt kompromittierte VIP-Konten und bietet ein durchgängiges Reputations- und Phising-Monitoring. Auch Takedown-Services sind über diesen Service verfügbar, kosten aber zusätzlich. Der Umfang der Darknet-Monitoring-Services richtet sich nach der gebuchten Servicestufe.

ZeroFox Dark Web Monitoring

Auch dieses Tool von ZeroFox zielt darauf ab, Darknet-Risiken einfacher sichtbar zu machen. Die kontinuierliche Überwachung von kompromittierten Zugangsdaten, persönlichen Daten von Mitarbeitern oder sensiblen geistigen Eigentumsrechten ist dabei laut dem Anbieter nur der Anfang: Aus der Analyse von Angriffsmethoden gewonnene Erkenntnisse fließen in Abwehrmaßnahmen ein, um die Anwender besser zu schützen – und Warnmeldungen informieren rechtzeitig über Risiken für Brands. (fm)

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

Beth Tschida, who became Jamf CEO in May after serving as CTO and as interim CEO, is the first woman to lead the company in its near 25-year history. I spoke with her this week at the London Jamf Nation event, where the company introduced its new AI Governance solution.

How the transition to CEO is going 

“It’s been a great privilege and an adjustment,” she said. “Jamf has always been a company deeply focused on culture, which is exactly why I love being here. Having the ability to influence and improve that culture from this role is something I feel very supported in doing.”

The last few years have seen a variety of changes at Jamf, which was briefly a public company. “We’ve come through a period of change, not all of it easy,” Tschida said. “But we now have a great partnership with Francisco Partners. We’re private, we’re focused on solving customer problems, and we’re finding ways to lean into what we’re good at.”

Women in tech and mentorship

Tschida is a good choice to lead a software engineering company, as she’s an engineer herself. She originally joined Jamf as vice president for software engineering in 2018, moving up to CTO in 2022. She’s also one of the few women in leadership positions in tech. (To Jamf’s credit, the company also has CIO Linh Lam on its team.)

“I think it’s important for women to stay deep in the tech, build their skills and find their voice confidently,” Tschida said. “You’ll never know all the technology out there. Nobody does. What matters is the ability to keep adapting and evolving.”

Tschida stressed the importance of mentorship. “I feel very honored to have a chance to be a role model for other women,” she said. “I had women who forged a path for me, including a female CIO early in my career who I asked to mentor me and learned an enormous amount from. I’m certainly not the first woman in tech, but I do want to play my part in helping others grow in their careers.

“Ultimately, I want to be respected for what I do, not for my gender. That’s how everyone should be judged.”

AI Governance

Tschida’s product focus means she knows what matters to Jamf. “If you focus on the problems customers have and how your product can help fix them, that’ll take you to where you want to go.”

For many in the enterprise, both in and beyond the Apple space, the next big problem is AI — how to deploy it, how to manage it, and how to regulate it.

AI Governance is a new Jamf solution that has been developed in response to those pain points. Countless surveys, including Jamf’s own data, show that AI is being widely used across every company, but IT lacks visibility into its use. It’s hard to know what data is being shared with AI tools, which services are being used, and how to report on that use effectively — particularly in regulated industries.

AI Governance is designed to make it possible for anyone managing an Apple fleet to get granular insight into AI use across their Mac, iPhone, and iPad devices. It uses telemetrics to shed light on that use, offers governance and management tools to help IT gain better oversight and control over it, and provides highly comprehensive reporting tools suitable for internal or regulatory review.

“AI is happening whether organizations know it or not,” said Tschida. “That’s the problem. You can try to block it, but that’s very hard to do well. It’s far better to build visibility and governance around it.”

The offering makes it possible for companies to enable the AI use they already know is taking place while protecting corporate interests and enabling fast and accurate reporting. You can find out more details here.

Empowering better AI

Jamf’s approach is focused on endpoint management. AI Governance means IT can see what’s running on a device, categorize it, and understand what AI tools and models are in use. “If you know how people are running AI on your fleet, you can open it up safely. Then all of your customers and employees can find their way to figure out how AI is going to optimize their workforce,” she said.

What does that look like in practice? Think of it as an orchestration layer. IT can define different AI configurations for different teams: HR might use one set of models, engineers another. And admins can apply opinionated postures per group: what models are permitted, what cloud services they connect to, what’s visible to IT versus the CISO versus the CFO. “It’s an extension of what Jamf has always done, it just now applies to AI endpoints too.”

What about regulatory complexity across geographies? “A lot of governance controls are shared across regulations; a good base set is a healthy way to run regardless. But each regulation has its own twists. Our mission is to make sure customers operating in different markets can expand on that base and fit the specific models and regulations they need, getting the right configurations to the right devices.”

Managers must prepare for AI cost challenges

There’s a second dimension beyond management — cost. The industry is developing quickly, with new AI models appearing almost every week. Yesterday’s leading LLM is tomorrow’s fading star, even while the cost of AI infrastructure goes through the roof. As that churn slows, investors will want to start seeing returns on their bets, which is why token costs — the price of running AI services, at least in the cloud — are climbing fast.  

As costs become more realistic, that’s going to change the nature of AI deployment from the laissez-faire, anything goes approach to a more strategic management of such use. “Models keep dropping fast, but token costs are only going to go up,” said Tschida.

“Organizations will need to decide: just because you can build something with AI, should you? What’s the right model for what work? We’re helping customers move from, ‘We’ll just block it’ or ‘We’ll turn it on and hope for the best,’ toward a place where they have a real viewpoint and can manage and change that viewpoint over time.”

The ever-changing AI world is also prompting Jamf to make more of its APIs externally available. “We’re used across every industry and every geography, at every scale,” said Tschida. “There’s no way we can build every workflow every customer needs, we’d never get to all of them.”

Embracing openness also helps build future foundations. “Thinking about where we’re heading next — agentic endpoint management — having platform APIs allows our customers to build things they can imagine, that we can learn from, in a way that solves their specific problems.”

Apple, WWDC, and the enterprise

Tschida’s comments come shortly after WWDC 2026, where Apple introduced a raft of AI advances that formed a strong foundation for its future, improvements that matter to Jamf. “When Apple innovates, Jamf celebrates,” she said.

“Apple is doing great things in their AI ecosystem, revamping Siri, expanding their AI capabilities, making Apple the platform people want to run AI on because those machines simply perform better. Our job is to take what Apple builds and bring it into the enterprise in the way that enterprises actually need it.”

Most of the industry recognizes that Apple’s enterprise story has changed dramatically as its products see accelerating use, and momentum is not slowing. Tschida reflected on how just a few years ago, Apple in the enterprise was an option in employee choice programs. “Now it’s becoming the clear choice,” she said. “We expect that trend to continue. And the more Apple invests in AI running natively on device, the stronger that argument gets.”

Where is Jamf going?

AI Governance is a unique answer to an increasingly important set of questions that are now beginning to affect the IT management of Apple’s platforms. (It’s not clear whether anything as sophisticated exists for other platforms at al, but as the need to manage AI grows, demand for such solutions will grow.)

Ultimately, the company’s latest move reflects Jamf’s inherent strategy under its new CEO. “Focus on customers, listen to them, solve their problems, and don’t throw tech at it. Ask: what’s the problem? Can we solve it? That focus is what takes you where you need to go.

“We’re on a good trajectory, customers stay with us, and the culture has always underpinned us. Now we’re finding ways to lean into it even further,” she said.

You can follow me on social media! Join me on BlueSky,  LinkedIn, Mastodon and subscribe to The Core.

The 2026 Verizon Data Breach Investigations Report analyzed more than 22,000 confirmed data breaches across 145 countries. Its findings point to a single uncomfortable truth: organizations cannot patch fast enough to prevent every incident. Exploitation of vulnerabilities surged to become the leading initial access vector, the median time to remediate a critical flaw climbed to 43 days, and the volume of critical vulnerabilities grew 50% year over year. Even top-performing organizations only managed to fix 30% to 40% of known exploited vulnerabilities listed in the CISA Known Exploited Vulnerabilities catalog within the first week of detection. That rate barely budged despite years of investment in tooling, process maturity and regulatory pressure.

Most organizations will eventually face a serious incident. The quality of your response determines the outcome.

Ransomware hits 48% of breaches. The payment decision is just the beginning

Ransomware appeared in 48% of all confirmed breaches, up from 44% the prior year. Among cases where organization size was known, 96% of victims were small and medium-sized businesses.

The “climax” of every ransomware tabletop I witness has always been the question: pay or refuse? The DBIR reveals that 69% of victims chose not to pay, up from 65% the year before. That number held even when attackers encrypted systems. Refusing is becoming standard practice. The median payout dropped to $139,875.

Facing shrinking revenues, ransomware operators now deliberately maximize operational disruption to force faster decisions. The 2025 attack on Marks & Spencer knocked out online sales, inventory tracking and refrigeration monitoring for weeks, costing an estimated £300 million. The Jaguar Land Rover breach halted manufacturing for five weeks, inflicted £1.9 billion in damages and dragged UK GDP below its quarterly forecast.

Consider using these cases to inspire your next ransomware drill. The ransom question is one agenda item. Sustaining operations without primary systems, coordinating with legal counsel and law enforcement, managing customer and investor communications under regulatory deadlines, deciding what to disclose and when: these are the decisions that determine whether a company survives a ransomware event or becomes a cautionary headline. Organizations that rehearse only the payment question are practicing the opening scene and skipping the rest of the play.

Third-party breaches jumped 60%. Your exercises should reflect that

Breaches involving a vendor, supplier or service provider reached 48% of all confirmed incidents, a 60% increase from the previous year. This metric doubled the year before that. The trajectory is unmistakable.

The DBIR identifies three archetypes: a vulnerability in a vendor’s product opens the door to your environment; a vendor holding your data gets compromised directly; or an attacker breaches the vendor and pivots laterally into your network. Several of the year’s most prominent campaigns triggered two or all three archetypes simultaneously.

Most tabletop programs ignore this scenario entirely. I have seen organizations rehearse their internal playbooks dozens of times without once simulating a call to a compromised vendor. When the real call comes, they freeze. A third-party breach tests a fundamentally different set of skills than an internal compromise.

When a vendor is breached, the information your team needs most is the information the vendor is least prepared to share quickly. Tabletop exercises should simulate that friction. Participants should practice asking precise questions: What data of ours did you hold? What is the confirmed scope? What logs exist? How are you notifying other affected customers?

The other half of the exercise is equally critical. Your customers will demand answers while the investigation is still unfolding. Transparency builds trust. Premature attribution destroys partnerships. The discipline lies in communicating what you know and what you are doing about it without publicly blaming a vendor whose cooperation you still require. A press statement that throws a third party under the bus may generate a satisfying headline. It will also guarantee that the vendor’s legal team stops sharing information with yours.

Vulnerability exploitation is the top attack vector. AI will accelerate it

Exploitation of vulnerabilities reached 31% of all confirmed breaches, a 55% increase over the prior year’s 20%. It displaced credential abuse as the leading initial access method for the first time in the DBIR’s history.

The structural problem is straightforward. Organizations faced a median of 16 CISA Known Exploited Vulnerabilities in 2025, up from 11 the year before. Only 26% were fully remediated, down from 38%. Defenders are caught in Alice’s Red Queen Race.

AI is compressing the timeline further. The DBIR’s collaboration with Anthropic examined 793 threat actors who misused AI platforms for malicious purposes between March 2025 and February 2026. The median actor sought assistance across 15 distinct ATT&CK techniques. Thirty-two percent of AI-assisted initial access activity targeted vulnerability exploitation specifically. The report notes that creating exploit tools, adapting them across languages and discovering new vulnerabilities “is within reach with current AI coding assistance.” Anthropic’s own threat research documented the first known AI-orchestrated cyber espionage campaign, in which attackers used agentic AI to execute intrusions autonomously. By December 2025, researchers documented VoidLink, a complete malware framework built by an AI agent in six days. Twenty-nine percent of KEV vulnerabilities were attacked before public disclosure that year.

This acceleration demands a shift in how organizations exercise their incident response capabilities. NIST SP 800-84 has long recommended formal test, training and exercise programs for evaluating incident response preparedness. The growing speed and volume of exploitation makes that guidance urgent. Technical tabletop exercises, where participants work through actual triage rather than discuss hypothetical responses, should become routine. Teams need to practice identifying affected systems, determining blast radius, executing containment playbooks and coordinating remediation across departments under realistic time pressure. The window between initial compromise and full-blown breach is shrinking. How fast your technical teams can triage and contain directly determines the severity of the outcome. Organizations that encounter these decisions for the first time during a live incident will not move fast enough.

The breach you practice for is the one you survive

The 2026 DBIR and Google’s M-Trends 2026 report paint the same picture from different angles: the speed of attacks is accelerating, the surface area is expanding through third-party dependencies, and the sophistication gap between attackers and defenders is narrowing thanks to widely available AI tooling. These are not projections. They describe the threat landscape as it exists today.

Organizations that wait for a breach to test their response capabilities will discover their gaps at the worst possible moment. Playbooks that have never been exercised under pressure tend to collapse on first contact with a real incident. Communication plans that look reasonable on paper fall apart when the general counsel, the CISO and the CEO are in the same room arguing about disclosure timing while customers flood the support lines.

The remedy is deliberate, repeated practice. Tabletop exercises that simulate ransomware scenarios should go beyond the payment question and into the operational chaos that follows. Exercises involving third-party breaches should force participants to navigate the tension between transparency and partnership preservation. Technical exercises should compress timelines and demand the same speed of triage that a real exploitation campaign would require.

None of this is new advice. But the 2026 data makes the stakes clearer than ever. The organizations that build crisis response as a practiced skill will weather these incidents. Those that treat their incident response plan as a static document will learn its shortcomings the hard way.

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

Organizations racing to embed AI into business operations are realizing that the risk management frameworks they’ve relied on for decades aren’t built for the behaviors, failure modes, and ethical complexities AI systems introduce.

Fortunately, a new generation of AI-specific frameworks has emerged to give organizations a structured way to identify where AI can go wrong, what controls to put in place, and how to demonstrate responsible AI use to regulators, customers, and investors. Not all of these emerging frameworks address the same problem. Some focus on governance and organizational accountability, others on technical security controls, threat modeling, or regulatory compliance. Choosing the right one for your organization depends on where your most pressing gaps reside.

The frameworks are complementary, not competing, because they have different intents, priorities, and objectives, says Nicole Carignan, CISO at Darktrace.

“There is overlap across these frameworks, but that overlap is helpful,” Carignan points out. “It reinforces the core practices organizations need to get right: governance, data integrity, security, accountability, oversight, testing, and continuous improvement.”

Here are five frameworks worth considering for your AI risk management needs.

ISO/IEC 42001 Artificial Intelligence Management System

ISO/IEC 42001:2023 is the first internationally recognized formal standard for AI management. Published by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC) in December 2023, ISO/IEC 42001 follows a similar structure to management system standards such as ISO 27001. The framework gives organizations a structured methodology for establishing policies, processes, operational controls, and accountability mechanisms to ensure responsible development and use of AI.

ISO/IEC 42001 requires companies to document how they design, monitor, validate, and control AI systems, while also requiring them to conduct AI impact assessments to evaluate potential legal, ethical, and societal impacts. The standard covers governance structures, third-party supplier oversight, data management, transparency obligations, and lifecycle management.

ISO/IEC 42001 is a voluntary but certifiable standard that applies across sectors and organization sizes. A growing number of organizations have begun using it to demonstrate adherence to responsible AI practice and alignment with regulations such as the EU AI Act. The ISO/IEC have described the framework as helping organizations align their AI practices with legal and regulatory requirements; demonstrate responsible AI governance; manage risks tied to bias, safety, and security; and enhance stakeholder trust.

ISO 42001 is a great option for organizations just getting started with AI risk management, says Nicole Carignan, senior vice president for security and AI strategy and field CISO at Darktrace.

“It provides the strongest foundation for building an AI risk management program, rather than addressing individual AI risks in isolation,” she explains. “From a program-building standpoint, ISO 42001 is the right place to start because it forces organizations to think holistically about ownership, governance, oversight, data integrity, security risk mitigation, accountability, and continuous improvement.”

One downside Carignan is that the framework is resource-intensive to implement, and the full standard is not publicly available. Both challenges can be formidable for organizations that are very early in their AI governance journey, she says.

NIST AI Risk Management Framework (AI RMF)

Released by the US National Institute of Standards and Technology (NIST) in January 2023, the AI Risk Management Framework (AI RMF) is a voluntary framework designed to help organizations of all sizes and across all sectors identify, assess, and manage risks associated with AI systems across their entire lifecycle.

The framework consists of two parts. The first offers guidance on how organizations should think about AI risks and the characteristics of trustworthy AI systems, such as validity, safety, security, transparency, explainability, privacy, and fairness. The second part is structured around four interconnected functions:

• Govern focuses on what organizations need to do to build internal culture, policies, and accountability structures for AI use.
• Map involves understanding the broader context and potential risks of specific AI systems.
• Measure focuses on how organizations must evaluate and track those risks using both qualitative and quantitative methods.
• Manage provides guidance on risk prioritization and appropriate responses such as mitigation, transfer, or acceptance.

NIST AI RMF includes a separate Playbook that provides practical implementation steps to help organizations implement each of these functions effectively.

For organizations that are not ready to pursue ISO 42001 formally, the NIST AI RMF can serve as a more flexible and accessible starting point, Carignan says.

“It is public and gives organizations a common language for understanding and mitigating AI risk,” she adds. “But if the goal is to build a durable AI risk program, ISO 42001 is the strongest foundation.”

Ram Varadarajan, CEO at Acalvio recommends NIST AI RMF as a good place for organization to get started on AI risk governance, “because it’s built around maturity rather than pass/fail audits.” Its gives organizations starting from zero an opportunity to discover where they stand rather than immediately handing out a failing grade.

“More importantly, it forces the three conversations that have to happen first: who owns AI risk, what AI is actually running, and who gets hurt if something goes wrong,” Vardarajan says.

While researchers at Forrester described NIST AI RMF as a step in the right direction soon after its launch, they also expressed concern over conflicts of interest among the multiple stakeholders that helped draft the framework, the absence of an explicit role for data governance, and the fact that the framework was “still descriptive and not prescriptive.”

As a result, “Chief data officers and heads of data science need to navigate this framework wisely to interpret and apply it to their AI governance efforts,” the analyst firm advised.

ENISA Framework for AI Cybersecurity Practices

ENISA, the European Union Agency for Cybersecurity, developed its Framework for AI Cybersecurity Practices (FAICP) in anticipation of the EU AI Act. Published in June 2023, the framework gives EU organizations structured, AI-specific cybersecurity guidance for enhancing the trustworthiness of their AI activities.

FAICP is organized around three progressive layers. The first covers foundational information and communications technology cybersecurity practices that AI systems inherit by running on standard software infrastructure. The second addresses AI-specific risks, including adversarial attacks, model tampering, data pipeline integrity, and supply chain security. The third provides sector-specific guidance for regulated industries such as energy, healthcare, and telecommunications.

According to the European Parliament, FAICP’s layered nature provides organizations with “a gradual approach” to enhancing the trustworthiness of their AI activities.

FAICP is voluntary, but its close alignment with the EU AI Act and the NIS2 Directive, which is the EU’s primary cybersecurity law, means that EU regulators consider the framework as a baseline for AI governance practices at all organizations doing business within the EU.

FAICP is important because “Europe’s AI Act will likely become the global reference point, the same way Europe’s data privacy law became the de facto standard for companies worldwide regardless of where they’re headquartered,” Vardarajan predicts.

“Within two to three years, expect two frameworks to dominate: the EU AI Act setting the legal floor, and NIST AI RMF providing the operational playbook for meeting it,” Vardarajan says.

ISO/IEC 23894:2023 Information Technology — Artificial Intelligence — Guidance on Risk Management

The ISO/IEC 23894:2923 framework provides organizations with specific guidance on managing risks associated with artificial intelligence. Released jointly by ISO and IEC in February 2023, the framework builds on and adapts the ISO 31000 general risk management standard to address AI-specific risks such as those tied to algorithmic bias, model drift, unpredictable behavior, and lack of transparency in decision-making. It provides organizations a way to evaluate the likelihood and potential consequences of these risks throughout the full AI system lifecycle.

The ISO has described the standard as a “companion to ISO 31000 (Risk Management) and ISO/IEC 42001 (AI Management Systems).” The main difference between ISO/IEC 42001 and ISO/IEC 23894 is that the former is a certifiable management system. It provides organizations with the full requirements for establishing, implementing, and maintaining an AI management system. ISO/IEC 23894:2023 on the other hand is a guidance-only standard focused on how to identify, assess, and manage AI-specific risks.

“Notably, ISO/IEC 23894 offers concrete examples of effective risk management implementation and integration throughout the AI development lifecycle and provides detailed information on AI-specific risk sources,” according to UK-backed AI Standards Hub. “A key benefit of this standard is that application of the guidance can be customized to any organization and its business context.”

Google Secure AI Framework (SAIF)

Google Secure AI Framework (SAIF) is Google’s practical guide for helping organizations develop and run AI systems with strong built-in protections against digital threats. Launched in 2023, it focuses on weaving security and privacy considerations directly into every stage of an AI project’s life cycle, from design through deployment and ongoing operation.

Its main goal is to tackle the unique vulnerabilities that come with AI technologies such as attacks that tamper with training data, trick models through engineered prompts, or steal sensitive information. SAIF draws on Google’s own experiences developing and deploying large scale AI systems and therefore is more engineering-heavy than other frameworks. SAIF is largely focused on helping organizations make their AI systems more resistant to cyberattacks and cyber adversaries and covers areas like data handling, underlying infrastructure, the AI models themselves, user-facing applications and verification processes. It offers organizations practical guidance on implementation controls, shared responsibility, and defending against technical attacks.

Technology consultancy Thoughtworks has assessed SAIF as a framework that helps organizations systematically address “common threats such as data poisoning and prompt injection through a clear risk map, component analysis, and practical mitigation strategies.” According to the firm, SAIF’s “focus on the evolving risks of building agentic systems especially timely and valuable. SAIF offers a concise, actionable playbook that teams can use to strengthen security practices for LLM usage and AI-driven applications.”

David Brumley, chief AI and science officer at Bugcrowd, says that for organizations that want to adopt a framework, the question is not really “which AI risk framework is best?” but “which framework helps [the] organization safely build, deploy, and learn from AI in the real world?”

While most of the currently available AI risk frameworks have their use, most are still focused on preventing bad outcomes rather than helping organizations pave safe roads for a technology that is already inevitable.

“That distinction matters,” Brumley says. “AI adoption is not waiting for perfect governance, and those who focus on a [risk management framework] could inadvertently create a shadow AI problem in their organization.”

Despite best efforts by defenders, malicious emails continue to slip through the cybersecurity cracks, leading some enterprises to implement a layered “defense in depth” strategy that incorporates multiple tools.

Microsoft seems to be challenging this idea, revealing that there are only nominal returns from adding integrated pre- and post-send partners to Defender for Office 365’s protections.

According to its new quarterly benchmarking data, the tech giant catches the vast majority of malicious and spam emails before delivery, misses the fewest compared to competitors by a wide margin, and removes nearly 100% of dangerous emails that do reach the inbox. Collectively, its integrated partners improve that catch rate by less than .05%.

While these numbers seem to tip the scales towards a one-vendor email security stack, experts urge enterprises to be skeptical and cautious of such vendor claims.

Seva Ioussoufovitch, senior research analyst at Info-Tech Research Group, pointed out, “percentages obscure the true quantity and severity of what’s getting through, and, considering it only takes one message to result in an incident, it’s simple enough to argue that there is real value in the defense in depth that having multiple tools provides.”

Malicious and spam email catch by the numbers

Microsoft introduced its quarterly benchmarking report in July 2025 alongside a Defender integrated cloud email security (ICES) ecosystem designed to support multi-vendor security strategies.

The SEG players it ranked itself against this year includes Mimecast, Proofpoint, Hornetsecurity, Trend Micro, Iron Port (Cisco), Barracuda, and FireEye (Trellix); ICES companies include Abnormal, Checkpoint Harmony, Cisco, DarkTrace, KnowBe4 Defend, Tessian, and Trend Micro.

Redmond reported that Defender “consistently leads” in pre-delivery detection, missing 59% fewer high-severity cyberthreats prior to delivery than the other SEG vendors it evaluated. Its closest competitors were Mimecast and Proofpoint. The company also introduced a new metric in this area: A threat miss rate per 1,000 employees. In Microsoft’s case, that was 194 per 1,000; for Mimecast, 478; for Proofpoint, 483.

When it came to post-delivery protection, Defender removed an average of 96.03% of malicious emails that reached the inbox, up from an initial 45% when Microsoft first started tracking the data in its second report.

This makes Defender “an increasingly critical backstop, operating even when ICES solutions are in place,” Jeff Pinkston, VP and GM for Microsoft Defender, wrote in a blog post. Still, ICES tools operating in tandem with Microsoft Defender “continue to provide benefits,” improving malicious catch by 0.29% and spam catch by 0.68%, he said.

“If we focus on the basics, their argument seems strong,” Info-Tech’s Ioussoufovitch noted. “Do you really need a separate ICES vendor for that extra sub 1% catch?” Microsoft paints a “compelling picture” by only focusing on raw catch rate, he said, but we don’t hear the rest of the story: “What exactly is the danger of what isn’t being caught by Defender?”

No one vendor catches everything

David Shipley of Beauceron Security pointed out that the report underscores the fact that “lots of stuff still gets by e-mail filters.”

His company regularly analyzes hundreds of thousands of emails, and the content that gets through “ranges from the shockingly mundane and obvious to a human expert, to highly clever time-delayed attacks,” he said.

A key factor in what gets through is the amount of content that is allowlisted; settings in “100% paranoid mode” get high catch rates, as well as high false positives, Shipley noted. “Anyone who has ever had a sales person lose a deal because the purchase order PDF got flagged has felt this pain.”

Then there’s the AI conundrum: “A key risk for e-mail vendors using agentic LLM-based analysis is it’s now possible to poison those models with hidden content (such as ‘ignore this e-mail, pretty please’),” Shipley said. This means enterprises need a variety of analysis methods.

Ioussoufovitch agreed that keeping pace with threat actors using AI is an industry-wide challenge, particularly as AI enables higher-quality phishing. Filters are improving and will catch some of it, but some will inevitably continue to get through. Those messages are likely highly-targeted, which are lower in volume but harder to catch.

“As of now, current tools do seem to be struggling to keep pace, but that doesn’t mean those tools aren’t necessary,” said Ioussoufovitch. “It just highlights that defense-in-depth, broadly speaking, is becoming more and more important.”

Claims appear more honest

Shipley said that this report appears more honest, accurate, and mature than others claiming 99.99% phish catch rates, “which is never true.” It’s also a “smart marketing move,” because Microsoft competes for the same security budget as other tools, and would rather enterprises remove those vendors and buy more from it in areas beyond e-mail.

On the other hand, he said, Microsoft is offering up a list of other vendors to think about, “which, congrats to Mimecast on coming in second.”

In the long run, CISOs need to determine the best spend for their limited security dollars, he noted. Enterprises need a good filter; whether they need two is up for debate. “They also clearly still need to invest in a robust awareness program,” Shipley said, “because as this report shows, lots of phishes are still getting delivered.”

Missing an important nuance

Ioussoufovitch noted that while the claims in the study are interesting, the data is presented without much of the nuance that would make it truly actionable.

“We are all too familiar with vendors’ abilities to massage data to tell the story they want, so I would advise leaders not to extrapolate the data beyond what it actually says,” he said.

Instead of the takeaway being “get rid of our current vendors,” this post highlights that Defender provides “considerable value,” he noted. Whether adding or subtracting additional vendors is worth the money should be a case-by-case conversation that considers an organization’s risk appetite, and overall security budget and environment.

“I’d treat these claims more as a reminder to assess your own environment and compare detections,” he said. “Come to conclusions based on the data you have, not what a vendor is presenting.”

Despite best efforts by defenders, malicious emails continue to slip through the cybersecurity cracks, leading some enterprises to implement a layered “defense in depth” strategy that incorporates multiple tools.

Microsoft seems to be challenging this idea, revealing that there are only nominal returns from adding integrated pre- and post-send partners to Defender for Office 365’s protections.

According to its new quarterly benchmarking data, the tech giant catches the vast majority of malicious and spam emails before delivery, misses the fewest compared to competitors by a wide margin, and removes nearly 100% of dangerous emails that do reach the inbox. Collectively, its integrated partners improve that catch rate by less than .05%.

While these numbers seem to tip the scales towards a one-vendor email security stack, experts urge enterprises to be skeptical and cautious of such vendor claims.

Seva Ioussoufovitch, senior research analyst at Info-Tech Research Group, pointed out, “percentages obscure the true quantity and severity of what’s getting through, and, considering it only takes one message to result in an incident, it’s simple enough to argue that there is real value in the defense in depth that having multiple tools provides.”

Malicious and spam email catch by the numbers

Microsoft introduced its quarterly benchmarking report in July 2025 alongside a Defender integrated cloud email security (ICES) ecosystem designed to support multi-vendor security strategies.

The SEG players it ranked itself against this year includes Mimecast, Proofpoint, Hornetsecurity, Trend Micro, Iron Port (Cisco), Barracuda, and FireEye (Trellix); ICES companies include Abnormal, Checkpoint Harmony, Cisco, DarkTrace, KnowBe4 Defend, Tessian, and Trend Micro.

Redmond reported that Defender “consistently leads” in pre-delivery detection, missing 59% fewer high-severity cyberthreats prior to delivery than the other SEG vendors it evaluated. Its closest competitors were Mimecast and Proofpoint. The company also introduced a new metric in this area: A threat miss rate per 1,000 employees. In Microsoft’s case, that was 194 per 1,000; for Mimecast, 478; for Proofpoint, 483.

When it came to post-delivery protection, Defender removed an average of 96.03% of malicious emails that reached the inbox, up from an initial 45% when Microsoft first started tracking the data in its second report.

This makes Defender “an increasingly critical backstop, operating even when ICES solutions are in place,” Jeff Pinkston, VP and GM for Microsoft Defender, wrote in a blog post. Still, ICES tools operating in tandem with Microsoft Defender “continue to provide benefits,” improving malicious catch by 0.29% and spam catch by 0.68%, he said.

“If we focus on the basics, their argument seems strong,” Info-Tech’s Ioussoufovitch noted. “Do you really need a separate ICES vendor for that extra sub 1% catch?” Microsoft paints a “compelling picture” by only focusing on raw catch rate, he said, but we don’t hear the rest of the story: “What exactly is the danger of what isn’t being caught by Defender?”

No one vendor catches everything

David Shipley of Beauceron Security pointed out that the report underscores the fact that “lots of stuff still gets by e-mail filters.”

His company regularly analyzes hundreds of thousands of emails, and the content that gets through “ranges from the shockingly mundane and obvious to a human expert, to highly clever time-delayed attacks,” he said.

A key factor in what gets through is the amount of content that is allowlisted; settings in “100% paranoid mode” get high catch rates, as well as high false positives, Shipley noted. “Anyone who has ever had a sales person lose a deal because the purchase order PDF got flagged has felt this pain.”

Then there’s the AI conundrum: “A key risk for e-mail vendors using agentic LLM-based analysis is it’s now possible to poison those models with hidden content (such as ‘ignore this e-mail, pretty please’),” Shipley said. This means enterprises need a variety of analysis methods.

Ioussoufovitch agreed that keeping pace with threat actors using AI is an industry-wide challenge, particularly as AI enables higher-quality phishing. Filters are improving and will catch some of it, but some will inevitably continue to get through. Those messages are likely highly-targeted, which are lower in volume but harder to catch.

“As of now, current tools do seem to be struggling to keep pace, but that doesn’t mean those tools aren’t necessary,” said Ioussoufovitch. “It just highlights that defense-in-depth, broadly speaking, is becoming more and more important.”

Claims ‘appear more honest’

Shipley said that this report appears more honest, accurate, and mature than others claiming 99.99% phish catch rates, “which is never true.” It’s also a “smart marketing move,” because Microsoft competes for the same security budget as other tools, and would rather enterprises remove those vendors and buy more from it in areas beyond e-mail.

On the other hand, he said, Microsoft is offering up a list of other vendors to think about, “which, congrats to Mimecast on coming in second.”

In the long run, CISOs need to determine the best spend for their limited security dollars, he noted. Enterprises need a good filter; whether they need two is up for debate. “They also clearly still need to invest in a robust awareness program,” Shipley said, “because as this report shows, lots of phishes are still getting delivered.”

Missing an important nuance

Ioussoufovitch noted that while the claims in the study are interesting, the data is presented without much of the nuance that would make it truly actionable.

“We are all too familiar with vendors’ abilities to massage data to tell the story they want, so I would advise leaders not to extrapolate the data beyond what it actually says,” he said.

Instead of the takeaway being “get rid of our current vendors,” this post highlights that Defender provides “considerable value,” he noted. Whether adding or subtracting additional vendors is worth the money should be a case-by-case conversation that considers an organization’s risk appetite, and overall security budget and environment.

“I’d treat these claims more as a reminder to assess your own environment and compare detections,” he said. “Come to conclusions based on the data you have, not what a vendor is presenting.”

This article originally appeared on CSOonline.

Despite best efforts by defenders, malicious emails continue to slip through the cybersecurity cracks, leading some enterprises to implement a layered “defense in depth” strategy that incorporates multiple tools.

Microsoft seems to be challenging this idea, revealing that there are only nominal returns from adding integrated pre- and post-send partners to Defender for Office 365’s protections.

According to its new quarterly benchmarking data, the tech giant catches the vast majority of malicious and spam emails before delivery, misses the fewest compared to competitors by a wide margin, and removes nearly 100% of dangerous emails that do reach the inbox. Collectively, its integrated partners improve that catch rate by less than .05%.

While these numbers seem to tip the scales towards a one-vendor email security stack, experts urge enterprises to be skeptical and cautious of such vendor claims.

Seva Ioussoufovitch, senior research analyst at Info-Tech Research Group, pointed out, “percentages obscure the true quantity and severity of what’s getting through, and, considering it only takes one message to result in an incident, it’s simple enough to argue that there is real value in the defense in depth that having multiple tools provides.”

Malicious and spam email catch by the numbers

Microsoft introduced its quarterly benchmarking report in July 2025 alongside a Defender integrated cloud email security (ICES) ecosystem designed to support multi-vendor security strategies.

The SEG players it ranked itself against this year includes Mimecast, Proofpoint, Hornetsecurity, Trend Micro, Iron Port (Cisco), Barracuda, and FireEye (Trellix); ICES companies include Abnormal, Checkpoint Harmony, Cisco, DarkTrace, KnowBe4 Defend, Tessian, and Trend Micro.

Redmond reported that Defender “consistently leads” in pre-delivery detection, missing 59% fewer high-severity cyberthreats prior to delivery than the other SEG vendors it evaluated. Its closest competitors were Mimecast and Proofpoint. The company also introduced a new metric in this area: A threat miss rate per 1,000 employees. In Microsoft’s case, that was 194 per 1,000; for Mimecast, 478; for Proofpoint, 483.

When it came to post-delivery protection, Defender removed an average of 96.03% of malicious emails that reached the inbox, up from an initial 45% when Microsoft first started tracking the data in its second report.

This makes Defender “an increasingly critical backstop, operating even when ICES solutions are in place,” Jeff Pinkston, VP and GM for Microsoft Defender, wrote in a blog post. Still, ICES tools operating in tandem with Microsoft Defender “continue to provide benefits,” improving malicious catch by 0.29% and spam catch by 0.68%, he said.

“If we focus on the basics, their argument seems strong,” Info-Tech’s Ioussoufovitch noted. “Do you really need a separate ICES vendor for that extra sub 1% catch?” Microsoft paints a “compelling picture” by only focusing on raw catch rate, he said, but we don’t hear the rest of the story: “What exactly is the danger of what isn’t being caught by Defender?”

No one vendor catches everything

David Shipley of Beauceron Security pointed out that the report underscores the fact that “lots of stuff still gets by e-mail filters.”

His company regularly analyzes hundreds of thousands of emails, and the content that gets through “ranges from the shockingly mundane and obvious to a human expert, to highly clever time-delayed attacks,” he said.

A key factor in what gets through is the amount of content that is allowlisted; settings in “100% paranoid mode” get high catch rates, as well as high false positives, Shipley noted. “Anyone who has ever had a sales person lose a deal because the purchase order PDF got flagged has felt this pain.”

Then there’s the AI conundrum: “A key risk for e-mail vendors using agentic LLM-based analysis is it’s now possible to poison those models with hidden content (such as ‘ignore this e-mail, pretty please’),” Shipley said. This means enterprises need a variety of analysis methods.

Ioussoufovitch agreed that keeping pace with threat actors using AI is an industry-wide challenge, particularly as AI enables higher-quality phishing. Filters are improving and will catch some of it, but some will inevitably continue to get through. Those messages are likely highly-targeted, which are lower in volume but harder to catch.

“As of now, current tools do seem to be struggling to keep pace, but that doesn’t mean those tools aren’t necessary,” said Ioussoufovitch. “It just highlights that defense-in-depth, broadly speaking, is becoming more and more important.”

Claims ‘appear more honest’

Shipley said that this report appears more honest, accurate, and mature than others claiming 99.99% phish catch rates, “which is never true.” It’s also a “smart marketing move,” because Microsoft competes for the same security budget as other tools, and would rather enterprises remove those vendors and buy more from it in areas beyond e-mail.

On the other hand, he said, Microsoft is offering up a list of other vendors to think about, “which, congrats to Mimecast on coming in second.”

In the long run, CISOs need to determine the best spend for their limited security dollars, he noted. Enterprises need a good filter; whether they need two is up for debate. “They also clearly still need to invest in a robust awareness program,” Shipley said, “because as this report shows, lots of phishes are still getting delivered.”

Missing an important nuance

Ioussoufovitch noted that while the claims in the study are interesting, the data is presented without much of the nuance that would make it truly actionable.

“We are all too familiar with vendors’ abilities to massage data to tell the story they want, so I would advise leaders not to extrapolate the data beyond what it actually says,” he said.

Instead of the takeaway being “get rid of our current vendors,” this post highlights that Defender provides “considerable value,” he noted. Whether adding or subtracting additional vendors is worth the money should be a case-by-case conversation that considers an organization’s risk appetite, and overall security budget and environment.

“I’d treat these claims more as a reminder to assess your own environment and compare detections,” he said. “Come to conclusions based on the data you have, not what a vendor is presenting.”

This article originally appeared on CSOonline.