As security operations teams now use large language models (LLMs) and autonomous AI agents into their daily work, a new frontier is emerging: attackers deliberately manipulating AI agents. Prompt injection attacks—where an attacker hides malicious instructions that cause an AI agent to ignore its safety rules—pose a serious risk to enterprises. These attacks continue to grow in size and scale.  

Snyk’s security audit of the Agent Skills ecosystem, which includes Anthropic’s Claude, Vercel, and others, that 36% of all skills contained at least one critical-level security issue, including malware distribution, prompt injection attacks, and exposed secrets.

In June, researchers at Mozilla tested a prompt injection attack on Claude using indirect prompt injection—a technique that embeds malicious instructions in external content the AI agent processes. In this proof-of-concept, attackers took over developers’ systems by hiding indirect prompts in normal-looking repositories. When Claude Code executed them, the agent spawned a reverse shell.

AI agents often connect to more sensitive data than human employees do., A successful prompt injection can lead to catastrophic data loss or unauthorized system actions. Defending against prompt injection attacks requires multiple layers of protection. Security teams must monitor agent behavior for anomalies and prepare for agent containment, forensic preservation, and system remediation. Because AI agents execute tasks at machine speed, human responses must be able to match that pace.

The architecture of trust: Protocols and no “black box”

AI-native workflows need governed access rather than “black-box” autonomy. Modern governance frameworks use standardized protocols like the Model Context Protocol (MCP) to provide secure communication between AI clients and data sources. Visibility and transparency in agentic AI workflows matter, especially in cybersecurity. Autonomous agents perform complex tool executions and use independent logic, so they must show how they reached their decisions to meet regulatory requirements. Agents without transparency post serious risks: obscured reasoning can trigger unpredictable tool interactions, bypass governance controls, and create uncontrolled defensive gaps.

Implementing these protocols matters:

• Bounded Tenant Awareness: In a stable agentic AI architecture, multi-tenancy scales well. But if an AI tenant misbehaves, the entire system can fail. Bounded tenant awareness isolates any misbehaving AI agent to prevent cross-tenant contamination or data leakage.
• Strict Access Controls: By controlling connections to the platform, organizations can stop “ignore previous instructions” style bypasses. Maintain tight control over what the AI can see and do within a workflow.
• Standardized Telemetry: All telemetry must remain consistent and audit-ready. Even if an AI interaction is attempts to break rules, the underlying data movement gets tracked against established frameworks like MITRE ATT&CK and NIST.

Detecting the aftermath: UEBA and NDR as safeguards

A robust, unified SecOps platform can detect anomalous behavior even after prompt injection tricks an AI agent. Prompt injections often serve to steal credentials theft or extract data. When detected it’s important to act quickly. In agentic AI systems, misbehavior can escalate privileges, manipulate memory layers, create unauthorized identities, or alter shared reasoning components. Containment must be automatic and enforced at identity, authentication, and authorization layers.

These safeguards include:

• User and Entity Behavioral Analytics (UEBA): Identity-focused correlation and behavioral baselines to identify anomalous user activity or privilege escalation. If a compromised AI agent acts outside of its normal operational parameters, UEBA flags it in real-time and alerts a human security analyst.
• Network Detection and Response (NDR): Combining network traffic analytics with endpoint and cloud telemetry, NDR can identify data exfiltration or policy violations from a successful prompt injection.
• Multi-Layer AI Filtering: AI filters reduce raw alerts into high-fidelity incidents, cutting noise by up to 90%. This keeps the signals of an AI-driven attack from disappearing in a busy SOC.

Humans remain the strongest defense against AI agent social engineering. The human security analyst is still the one who makes the final decision. While AI handles triage and correlation, humans retain final control over response actions.

Moving beyond reactive guardrails

The traditional SOC model was never designed to handle machine-speed, AI-driven attacks. A human-augmented autonomous SOC approach moves from reactive alert handling to a proactive, verdict-first model. By combining a transparent, governed AI access with robust UEBA and NDR, organizations keep the SOC secure, transparent, and resilient as social engineering methods target machines.

The post Why transparent AI agents matter more than you think appeared first on CyberScoop.

Last week, the FBI and EPA issued a joint alert that should concern anyone who drinks water in America–which is to say, everyone. Since July 27, water and wastewater utilities in at least seven states have reported cyberattacks against internet-facing programmable logic controllers (PLCs), the small industrial computers that run pumps, valves, and treatment equipment. Some of these attacks degraded operations. Utilities reported pressure loss and flooding, several systems reverted to manual control, and one Minnesota community declaring a local state of emergency.

Nothing about these attacks required sophisticated methods. The attackers didn’t use zero-day exploits or novel malware. They found controllers exposed to the public internet, many of them so old that they stopped receiving security patches years ago. They logged in, changed IP addresses and passwords, and locked operators out of their own equipment. In at least one case, they modified the ladder logic controlling industrial equipment. These were not Hollywood-style hacks. The controllers sat exposed and undefended.

If this feels familiar, it should. In late 2023, attackers compromised controllers at water utilities across several states, including the widely reported incident in Aliquippa, Pennsylvania. The federal government issued guidance then, too. One of the crucial differences between then and now is that attackers have grown in ambition. They’ve moved from defacing screens to disrupting operations across dozens of systems at once, exploiting the fact that third-party integrators often deploy the same vulnerable configuration across many small utilities. 

The uncomfortable truth is that this was preventable. The reason it wasn’t stopped is more structural than technical. The United States has roughly 50,000 community water systems. Most are small, publicly funded, and run by operators whose primary job is keeping water safe and flowing. Cybersecurity ranks far below that, if it ranks at all. The devices in question are often a decade or more old and replacing them takes capital these utilities don’t have. Rules governing water cybersecurity remain mostly voluntary. Attackers understand these economics perfectly. We should too, yet these attacks keep happening.

 But inaction is a choice. The defenses that work here cost little and require no exotic technology. The FBI and EPA guidance is sound, and every water and wastewater organization should act on it this week, not later. Here’s how:

• Get controllers off the public internet. No PLC should be reachable from the outside world. Remote access should go through a secure gateway that mediates, monitors, and logs every connection. That includes cellular modems, which are the overlooked entry point in nearly every audit.
• Fix passwords. Default and shared credentials are still the most common way in. Strong, unique passwords are the cheapest security control available.
• Restrict communication between devices. Firewall rules and access control lists should allow only expected communication between known control system devices. Block traffic from hosting providers and other sources that have no business touching a water plant.
• Lock the logic. Keep physical and software key switches in the run position except during authorized updates. This prevents unauthorized changes to configuration and firmware.
• Practice running manually. The utilities that survived these attacks best were the those that switched to manual operations quickly. That skill requires constant practice.
• Verify, don’t assume. Nearly every utility believes its PLCs aren’t internet-exposed, right up until an inventory proves otherwise. You can’t protect what you can’t see. Most operators are surprised by what a complete asset inventory reveals: forgotten modems, integrator-installed remote access, devices nobody knew were still online.

Every attack like this follows the same pattern. Attackers change configurations, reset passwords, and modify project files. Every one of those actions creates a signal on the network before operations degrade. In this most recent case, one victim only noticed ladder logic discrepancies across multiple sites. Catching intrusions shouldn’t depend on a sharp-eyed engineer having a good day. Continuous monitoring of OT environments exists to turn those signals into alerts within minutes instead of days. That difference is the difference between an incident report and a boil-water notice.

Water systems have the least margin for error and, too often, the fewest resources to defend themselves. The FBI and EPA have told us plainly what’s happening and what to do about it. The attackers are betting we won’t follow through. For the third time in three years, they’re testing that bet.

Let’s finally prove them wrong.

The post The water sector just got it’s wake-up call. Again. appeared first on CyberScoop.

Zero-knowledge proofs could let infrastructure operators answer key security questions without handing over the sensitive data behind their answers.

Imagine a major software flaw is discovered in equipment used across pipelines, power plants and telecom networks. The government needs to know as fast as possible which companies are exposed. But answering that question may require firms to share software inventories, network diagrams and vulnerability scans, which could become attack roadmaps for attackers if compromised. A lesser-known cryptographic concept could help solve this problem. The method, known as zero-knowledge proofs, allows companies prove a vulnerability exists without disclosing how their systems work or other proprietary information.

For more than a decade, Washington has tried to address companies’ concerns about sharing cybersecurity data. Congress has provided legal protections, and agencies have created information-sharing programs. Those efforts have helped companies exchange signs of an attack, incident reports, and defensive advice. But they’ve done much less to get companies to share data on vulnerabilities and security controls before an incident occurs.

The data that would help the most is what companies are least willing to share. A vulnerability scan can show which devices are connected, which software is running, how systems are configured and where defenses are weak. If unintentionally exposed, it would be a terrific guide for adversaries.

Another problem: Once sensitive data leaves a company, it can be stolen, subpoenaed, passed to another agency or used in a regulatory proceeding the company never expected. Industry is constantly asked to reduce security risk by creating more elsewhere.

Zero-knowledge proofs could reduce the need to disclose the underlying sensitive data. The idea is simple, even if the math is not: a company can prove that an agreed evaluation of its authorized scan data indicates that a specific software flaw is present, without disclosing its full asset inventory, network architecture or configuration data.

A computer does not read a vulnerability scan the way a person does. A security analyst might open a report, look through the devices and software versions, and decide whether a vulnerable product is present. A zero-knowledge proof turns that same evaluation into a local mathematical calculation.

For example, the government and a company could agree on a precise question: Does a specific vulnerability exist anywhere inside a defined group of systems? The company keeps its scan data inside its own network. A cryptographic tool checks that data against the agreed question, compares the software and version information against the vulnerability, and produces a proof tied to the final answer. If the scan data satisfies the agreed conditions for a “yes” result, the company cannot generate a valid proof supporting a false “no” answer under those same rules.

The government never sees the raw scan report, the device list, the software inventory, or the network map. It only receives and verifies the mathematical proof, confirming that the answer follows from the agreed rules and underlying data without exposing that data.

This isn’t theoretical. FDD’s Center on Cyber and Technology Innovation recently tested the approach with anonymized vulnerability data from three operational environments. The test asked yes-or-no questions about 38 known vulnerabilities while keeping the raw scans inside the participating environments. Results were promising: only the proofs and answers were shared, yet they revealed how widespread each vulnerability was across the environments.

The test proved the approach works, but that does not mean the government should rush to build a national system around it. A lot of work still needs to be done before agencies can rely on these for compliance, vulnerability reporting, or procurement decisions.

The next step should be structured pilot programs, not mandates. Federal cyber officials and standards bodies should test this with narrow, practical questions: whether a known vulnerability is present or whether a specific security control is in place.

Only after those pilots should agencies decide what underlying data can be trusted and what counts as sufficient proof in a regulatory setting. The Cybersecurity and Infrastructure Security Agency (CISA), the National Institute of Standards and Technology (NIST), and regulatory agencies are natural candidates to run these pilots. CISA already works with critical infrastructure operators on cyber risk, while NIST can help define what a trustworthy proof should look like before agencies try to rely on one. Regulatory agencies, meanwhile, could reduce private sector headaches by developing more secure mechanisms for companies to share compliance information.

Zero-knowledge proofs won’t solve every problem when it comes to cyber information-sharing. But they could solve one of the hardest: how to give the government a trustworthy answer without forcing companies to expose the very systems everyone is trying to protect. The government should test this concept now, while there is still time to learn, and avoid blindly entering the next cyber crisis.

The post How companies could share cyber risks without exposing their secrets appeared first on CyberScoop.

We almost never get both sides of an intrusion. This time we did.

Last month, Hugging Face disclosed a breach into part of its production infrastructure, saying an autonomous AI agent system ran the attack from start to finish. Five days later, OpenAI revealed that its own models, including GPT-5.6 Sol along with an unreleased one, were responsible for the breach. OpenAI called it an unprecedented cyber incident.

Most of the commentary since has been about AI capability. That is the least useful part of the story, because the capability was doing what it was destined to do. Security teams should look at a simpler truth: in both systems, the key defenses sat behind untrusted code that was already running.

What the two disclosures actually describe

Together, the report shows one connected attack across two firms. Code running on a low-level employee’s machine led to stolen passwords, privilege escalation and lateral moves, then out to the web to hit other targets. No step in that chain is novel. The speed and the number of attempts are what changed.

OpenAI’s evaluation ran in what it calls a highly isolated environment, with network access constrained to a single path: an internally hosted third-party proxy and cache for package registries. The models spent vast computer power searching for an exit. They exploited a zero-day flaw in that proxy, gained higher rights, and moved until they reached a machine with web access. They guessed that Hugging Face held the test solutions, used stolen passwords with more zero-days, and ran code on Hugging Face servers.

Hugging Face picks up the same chain from the receiving end, and its initial access is worth reading twice. A malicious dataset used two flaws in the data pipeline to run code on a worker machine. The agent took over the node, stole cloud keys, and moved into internal clusters over the weekend.

The sandbox was was the only boundary

Both setups assumed the sandbox would hold, so no real checks stood before code execution.  A sandbox is a good control. It is a terrible last control. When isolation is all you have between untrusted code and everything else, one flaw could give the attacker full control. 

Look at what each team allowed. OpenAI allowed one exit path—good engineering, but that proxy contained an unpatched flaw. Hugging Face ran a tool that executes code inside submitted data—a known feature, not a hidden mistake.

Neither choice was careless. Both made sense until a fast, automated system probed them thousands of times.

Why automated agents behave differently

Blocking a human stops them or slows them down. Blocking an AI gives it data. The AI logs the error, changes its plan, and tries again instantly. It keeps trying as long as someone pays for the computing power.

Hugging Face tracked over 17,000 attack events across short-lived sandboxes. OpenAI said its models focused on the goal with extreme effort.

This changes the attacker’s limit. It is no longer skill or patience. It is budget. Computing power scales with money, and code never sleeps. Any defense that relies on attackers giving up after a few tries must change.

Detecting malicious behavior is not the same as preventing execution

Detection worked—but too late

Detection worked, but too late to stop the loss. Hugging Face used AI tools to spot the breach, isolate systems, reset keys, fix flaws, and alert police. That is a good response.

Yet it happened after the attacker accessed private data, stole keys, and moved through internal networks. OpenAI spotted the event only after its models reached another firm’s database. Detection limited the damage; it did not stop the attack.

A breach is a race between attack speed and defender response speed. AI agents speed up attacks with money. Human approval steps slow down defenders.

Hugging Face also surfaced an asymmetry that deserves more attention. When the team tried to analyze the attack with frontier models behind commercial APIs, the requests were blocked, because forensic work means submitting real attack commands, exploit payloads and command-and-control artifacts, and a safety filter cannot tell a responder from an attacker. They used an open-weight model on their own infrastructure instead. The attacker operated under no usage policy at all. The defender’s tooling was the side that got refused.

Detection is not prevention

Detection asks what happened. Prevention asks if it can happen at all. Against AI agents, the gap between those questions is where attacks succeed. The agent builds an attack out of single steps that look harmless on their own.

OpenAI noted this in its research: models operating over long horizons learn approval blind spots and work around them. Safety requires asking what a series of actions aims to achieve, not just if one step is allowed. Most systems check one call at a time: read a file, install a package, open a port. Every step passes. The full chain is the attack.

Six fixes for real defense

To survive automated attacks, defense must shift before code runs. That starts with treating data like code. Dataset loaders, templates, and configuration files all run instructions, so they demand strict controls: block remote execution by default, require review, and check the source of every outside file. Security teams must also control outgoing traffic with strict lists of approved destinations, while treating every proxy in that path as vulnerable. Finally, firms must remove permanent keys, issuing short-lived credentials for single jobs so a hacked worker machine yields almost nothing to an attacker.

Beyond individual machines, isolation must happen per task rather than per user, stopping an automated swarm from moving through internal networks. Authorization also needs to change. Checking single actions fails when an agent builds an attack out of simple steps. Systems must evaluate full sequences instead, setting caps on activity rates and automated spending to flag suspicious chains of events. Lastly, defenders need the freedom to act fast. Security teams need authority to isolate systems without waiting for leadership meetings, and the ability to vet a capable model you can run on your own infrastructure for forensics.

What boards must ask now

Corporate boards usually ask if the company uses AI responsibly. That’s rooted in compliance not safety. Directors should ask four direct questions instead: Which systems run outside code, and what checks sit in front of them? If an attacker targets a low-level employee, what keys and paths can they obtain? How fast do we move from the first warning to active containment? And can we analyze attack code on our own hardware, free from third-party rules?

The boundary has to move

Nothing in these disclosures required a capability that did not exist last year. The chain was ordinary. What changed is that an adversary can run that ordinary chain thousands of times over a weekend, learn from every failure, and never need a coffee break.

The models did not break the detection-and-response model. They exposed where we put the trust boundary. We put it after execution, and we assumed we would have time on the other side of it. We do not have that time anymore.

Move the boundary.

The post What the Hugging Face breach reveals about defense in the age of agentic AI appeared first on CyberScoop.

Months before the Hugging Face breach, Emergence AI published research that investigative journalist Ronan Farrow made public. Ten autonomous AI agents operated across five virtual environments for fifteen days without human intervention. Much of the attention focused on Grok 4.1 turning violent and Gemini 3 Flash committing 683 crimes.

What mattered more went unnoticed: Anthropic’s Claude Sonnet 4.6 built a peaceful democracy in isolation, then stole resources from neighboring environments the moment it joined a shared one. The lesson was clear: safety is not a model attribute. It emerges from the operating environment. The models didn’t change. Working as designed, their behavior evolved as the environment changed. The lesson is hard to ignore: The governance environment changed, and with it, the reward dynamics.

The story here concerns institutions, specifically OpenAI’s and Hugging Face’s, and how we must understand their recent security incident through that lens.

The industry agrees on how the Hugging Face breach happened. Cybersecurity experts have focused on the vulnerabilities, how they were used, and remediation. OpenAI has highlighted the model’s capabilities. Both conversations matter. What requires attention is why this breach is strategically important. After spending the past weekend discussing it with policymakers, security researchers, and industry practitioners in Aspen, I came away convinced we’re examining the wrong problem.

In 1961, Yale psychologist Stanley Milgram’s experiments revealed a broader truth: changing the institutional architecture changes behavior without changing the actor. The Emergence AI researchers didn’t change Claude’s agent. They changed the governance architecture that determined what constituted success for the system. Claude’s behavior changed with it.

OpenAI built a smart model but forgot to build a smarter room. That choice made the Hugging Face breach possible. Every organization now deploying autonomous agents now faces the same governance problem.

OpenAI gave the agent one objective: pass a cybersecurity evaluation. To stress-test it fully, they loosened the safety restrictions, and the agent found a shorter path. Rather than solving the evaluation directly, it found the answers outside the test environment, escaped its sandbox, and exploited a flaw in Hugging Face’s data-processing pipeline to reach live production systems. Over the weekend, with no human oversight, it ran more than 17,000 automated actions by escalating its own access, moving through internal systems, and harvesting credentials.

Hugging Face is one of the world’s most prominent AI companies, valued at approximately $4.5 billion. It provides the infrastructure that governments, defense organizations, and technology companies use to build and deploy AI. The agent was pursuing the objective it had been given. Breaking into Hugging Face was the fastest path to passing the test. Governance set the goal, the level of risk to accept, and who was accountable. Technical design determined whether those governance decisions could be enforced. As researchers James Shires and Max Smeets have argued, for a model capable enough to act on its own, testing and deployment must both must be governed the same way.

AI agent design requires baseline standards. Observability, including a monitoring layer that flags when an agent goes beyond its scope, is a baseline requirement. Human review also matters at escalation boundaries, like when an agent shifts from internal tools to external ones. When any agent crosses that boundary, what alert fires? What human reviews it? We lack clear answers to either. That is a governance choice, not simply a security failure. At best, this was a catastrophically failed test. At worst, how can we trust any frontier AI company to self-govern autonomous agent deployment?

More than a decade ago, the U.S. Department of Defense built the Comply-to-Connect (C2C) program: every device connecting to sensitive networks must prove it belongs there, or it is cut off from the network. C2C works because the quarantined actor stops. A laptop that fails verification goes offline and stays there. An autonomous AI agent adapts around enforcement. C2C was built for passive actors. Governance for autonomous agents must accommodate ones that adapt. Visibility is not enforcement, and enforcement is not control. We are missing all three.

A second failure that is not being discussed enough: the breach exploited an implicit trust assumption in Hugging Face’s data-processing pipeline, where inputs were treated as trusted without verification. After SolarWinds, the U.S. government set rules for software supply chain integrity: Executive Order 14028 and verification demands for federal software. The principle was simple: trust must be verified through proof. Those principles have not yet been comprehensively or consistently applied to the AI model supply chain. The rules remain weak. No one has been asked to explain why.

The answer is not a new framework. Existing frameworks suffice. C2C proved that visibility without enforcement leaves gaps, while Executive Order 14028 established that trust in software supply chains requires proof and verification. The challenge lies in applying these principles to a new category of actor. Congress, the Cybersecurity and Infrastructure Security Agency, or the Office of Management and Budget should make formal determinations that autonomous AI agents must follow the same rules as every other actor on a federal network. The framework exists; it must be updated.

The next incident is already in progress. It will show up in the logs as odd traffic, get handed to the same people who published these frameworks this week, and spark another round of recommendations no one acts upon. We’ve solved this problem before: for devices, for software, for supply chains. We know how to build smarter rooms. The tools exist. The will, the authority, and the decision to govern remains absent.

The post OpenAI’s rogue AI agent shows why we need federal rules for autonomous systems appeared first on CyberScoop.

With the World Cup now complete, its biggest cybersecurity story may be what didn’t happen. While no major public cyber disruption has been reported, that shouldn’t be mistaken for a lack of risk. 

In the run-up to the tournament, the FBI’s Internet Crime Complaint Center (IC3) issued a public service announcement warning organizations and fans about fraudulent, spoofed websites impersonating the FIFA event – a reminder that the absence of a headline-grabbing breach doesn’t mean bad actors weren’t trying. In many ways, it’s evidence of the planning, coordination, and resilience required to keep an event of this scale running securely.

A global event like the World Cup depends on far more than what happens inside the stadium. It relies on local governments, venues, transportation systems, telecom providers, payment platforms, hotels, vendors, public safety agencies, and law enforcement, all working together. 

When I worked at the FBI, I saw how fast major events test teamwork across agencies, regions, and businesses. The World Cup offered that test at a scale few events can match.

Successful resilience is built months before kickoff

Successful major-event security depends on what happens long before there is a visible incident: trusted relationships, clear roles, shared intelligence and response plans. Planning becomes even more important when an event is not limited to a single city or venue.

In the past, event security consisted of guards, gates, and stadium perimeters. Those still matter, but they’re only part of the picture. Today, an event this big that brings millions of people together depends on many systems working in concert. No single organization owns the full risk picture, which means resilience depends on how well these groups can share information, coordinate response plans, and keep essential services operating under pressure. This means security can’t be planned around one perimeter. The real perimeter is the full event ecosystem.

Resilience starts much earlier, with planning across organizations that may not normally operate as one team. The real test for major events is whether public- and private-sector partners know their roles before pressure hits. That includes who shares information, who validates threats, who communicates with the public, who has decision-making authority and how quickly partners can act if a system slows down or becomes unavailable.

Major events are only as resilient as the systems behind them

Attackers don’t need to compromise the most visible organization to create disruption. They can look for weaker points across the event ecosystem. A disruption may begin with a vendor, ticketing platform, transportation partner, payment provider, hotel, contractor or communications provider, but the impact can quickly become broader than any one organization.

Sports organizations now operate like large businesses, with ticketing systems, VIP data, sponsors, vendors, media partners, stadium operations, payment systems, and fan engagement platforms. They depend on networks of suppliers and partners, and that creates multiple possible entry points.

Operational technology (OT) deserves more attention than it typically gets in these conversations. A ransomware attack that disrupted stadium operations directly, rather than a ticketing site or a fan-facing app, would be one of the most damaging scenarios organizers could face. OT security has to sit alongside the more visible concerns like payment fraud and spoofed domains, not behind them.

Bad actors don’t let a good crisis go to waste. Fans are often an easy target. Excitement drives a fan to buy a last-minute ticket or check a score on an unknown site. That excitement is exactly what fraudsters count on.

This risk grows over time. As the event gets closer and attracts more eyes, it becomes a richer target. A fake FIFA ticket site is useless to a crook a month after the last game. Groups running these systems must act faster as opening day nears, and share threat intelligence without delay.

Threat intelligence turns planning into proactive defense

The World Cup may be over, but the work isn’t. Cities, governments, and private-sector organizations will continue supporting large-scale public events that depend on complex digital and physical ecosystems. The question isn’t whether another major event will face cyber threats, it’s whether the planning starts early enough.

Organizations involved in future major events should focus on resilience, not just prevention. That means planning for what happens if a critical system slows down, goes offline, or becomes unreliable, and ensuring partners know how to coordinate before an incident occurs.

Every major event forces defenders to prepare for known risks. The harder challenge is anticipating the ones that haven’t emerged yet.

The next major disruption may not come from the attack that organizations spent months preparing for. It could target a new dependency, exploit emerging technology, or capitalize on a moment when public attention is at its highest. That’s why resilience can’t be built around yesterday’s playbook. It has to be informed by continuous threat intelligence, regular coordination across public- and private-sector partners, and the flexibility to adapt as the threat landscape changes.

The World Cup demonstrated what’s possible when that preparation comes together. As cities, governments, and private organizations look ahead to future global events, success won’t be measured solely by the attacks they stop. It will be measured by how effectively they can maintain critical operations, share information, and adapt under pressure when the unexpected happens.

The post What the World Cup can teach us about cybersecurity resilience appeared first on CyberScoop.

2026 has turned out to be the year when predictions about AI-powered cyberattacks, long hypothesized as a potential risk associated with AI improvement, seem to be coming true. New models have capabilities on par with the best human hackers, marking a pivotal window of opportunity in both AI and cybersecurity policy. This is a transitional period where new technologies are pushing existing American cybersecurity infrastructure to the brink. The real question isn’t whether cybersecurity still matters, but rather: How will the risks that AI introduces be managed before they outpace defenses, and who will step up to lead this challenge?

Attempts to control access to models with powerful cybersecurity capabilities, such as the federal government’s export controls (and their subsequent revocation) on Anthropic’s Mythos and Fable models, can only ever be a temporary solution. As with previous generations of AI models, other companies will soon catch up and develop models with Mythos-level capabilities. OpenAI was already hot on Anthropic’s heels with its GPT-5.5 model; more recently, Chinese lab Z.ai released its open-weight GLM-5.2 model, which early research suggests may be on par with Anthropic and OpenAI’s latest models when it comes to cybersecurity. Controlling AI is nearly impossible when foreign companies race to build more powerful models and release them publicly, so anyone with sufficient computing power can modify them for their own purposes.

The only long-term solution is to invest in defense. 

The problem is that defensive efforts haven’t kept up with the pace of AI progress. The federal government cut resources to key agencies like CISA and redistributed their authorities. This created a gap that AI companies have filled by taking on responsibilities that should be government-led. Some examples are Anthropic’s Project Glasswing and OpenAI’s Patch the Planet initiative, which aim to shore up critical infrastructure providers and open-source software libraries. AI companies have some incentives to invest in defense, both to improve public relations and strengthen software supply chains that they also rely on—but only to a certain extent. Unlike the public sector, they are incentivized to limit liability and blowback associated with irresponsible corporate behavior, not to secure the nation or its citizens. It’s a good thing that OpenAI and Anthropic have publicly committed to improving U.S. cyber defense. However, they are only positioned to help with one part of a very large problem. 

AI companies shouldn’t be expected to singlehandedly coordinate U.S. cyber defense, because many of the most urgent fixes have nothing to do with AI. Right now, AI companies can use their most powerful models to find software vulnerabilities and write patches. This is undoubtedly important, but the real challenge is making sure patches actually work and deploying them to key systems without causing problems. This is especially true for critical infrastructure, which relies on systems that are fragile, understaffed, and required to run continuously. 

AI companies bear responsibility for cyber defense, especially given the threats their own technologies create. But this responsibility is shared with other companies and the government.  Critical infrastructure owners and operators, government agencies, and corporations all need a trustworthy source of information to judge the evolving risk landscape and to outline the options to reduce that risk. Traditionally, the federal government has played the role of an information clearinghouse, receiving intelligence from both the public and private sectors and releasing guidance to benefit various stakeholders. Responding to and recovering from cyberattacks has traditionally been the government’s job. It should stay the government’s job, not become an AI company responsibility. 

There is no question that cyberattacks, whether powered by AI or not, will happen in the future. Leaders should strengthen our defenses by doing the following: measuring our exposure to attack, testing how systems perform under attack, and shortening recovery times. AI companies have introduced new threats and should help address them, but they can’t replace the government’s role. So far, the federal government has only reacted to AI and cyberthreats instead of planning ahead. What we need is real long-term cybersecurity strategy, not quick-fixes like blocking individual model releases. 

Everyone sees the threat coming—the question is whether or not we have the will to do anything about it before it’s too late.

Jessica Ji is a senior research analyst at Georgetown University’s Center for Security and Emerging Technology (CSET), where she works on the CyberAI Project.

Andrew Lohn is a senior fellow at Georgetown University’s Center for Security and Emerging Technology (CSET), where he works on the CyberAI Project.

The post Why blocking AI models won’t stop the cyber threats they create appeared first on CyberScoop.

AI-generated code is part of everyday software development. Developers use it to prototype, refactor, troubleshoot, and move from idea to implementation with less friction than ever before. The productivity gains are undeniable, which means that security leaders now face a hard question: whether their organizations can govern the risk that AI creates at that same speed.

That challenge is rooted in scale. AI changes how quickly software can be created, while many application security programs still depend on controls designed for a slower development model. When code generation accelerates beyond the capacity to review, test, and remediate issues, security debt accumulates faster.

That is the hidden cost of AI-assisted development. Risk now enters the enterprise at machine speed, while many organizations still manage it with human-scale processes. CISOs should govern AI-generated code as a high-risk input: tested automatically, checked for unsafe dependencies, remediated quickly, and blocked from production if it fails policy.

The metric that matters is risk velocity

Application security has long been measured through discovery. Teams count vulnerabilities, categorize severity, report trends, and show whether the numbers are improving. Those questions still matter, but AI adds a more urgent metric: risk velocity. Security leaders need to know how quickly the organization creates new software risks and how quickly it can reduce or eliminate them.

AI changes the economics of security debt. A development team that produces significantly more code without a matching increase in security capacity will create more issues than it can reasonably review or fix. Even when AI-generated code is comparable to human-written code on a per-line basis, the total risk can rise because the volume of change is higher. The backlog grows, vulnerabilities persist, and security debt eventually constrains the business.

AI expands familiar failure modes

The failure modes are familiar. AI coding tools can reproduce insecure patterns found in training data, including weak input validation, unsafe authentication flows, insecure direct object references, hard-coded secrets, and vulnerable dependency choices. They can also miss the context that determines whether code is secure in a specific environment: authorization models, tenant boundaries, data sensitivity, production configurations, and how services interact in a real application.

There is also a human factor. Under the pressure of deadlines, developers may accept code that works without fully understanding how it does so. The result is misplaced confidence. Code compiles, tests pass, features ship, and hidden risk enters the system. Over time, the organization may lose sight of the security concerns that naturally arose during manual development.

The supply-chain risk is bigger than the code itself

The software supply chain adds another layer of risk. Modern applications are assembled from open-source components, frameworks, plugins, containers, APIs, and cloud services. AI coding tools can recommend outdated packages, vulnerable libraries, or nonexistent dependencies. Veracode’s 2025 GenAI Code Security report found that AI coding tools produce insecure code nearly half (45%) of the time. It may sound like an amusing hallucination until attackers register malicious packages with similar names and wait for developers or automated tools to pull them in. At that point, a coding shortcut becomes a supply chain exposure.

AI is already part of the development lifecycle, and its use will continue to expand. Security teams need a control model built for that reality.

“Shift Left” needs an enforcement layer

The industry has spent more than a decade moving security earlier in the development lifecycle, improving visibility and helping teams catch issues sooner. Many organizations, however, moved findings closer to developers without also moving enough ownership, automation, and remediation capacity with them. Developers received more alerts, while security teams gained more visibility into risks they still struggled to reduce.

AI makes that operating gap more urgent. As software output increases, security cannot remain a checkpoint near the end of the process. It must become a continuous control system built into the way software is created, tested, approved, and deployed.

Secure-by-design has to become infrastructure

Secure-by-design in the AI era requires an engineering environment where unsafe choices are harder to make and easier to catch. Approved frameworks, secure defaults, reference architectures, dependency controls, automated testing, and policy enforcement should be embedded directly into developer workflows and CI/CD pipelines.

Remediation also must move closer to the point of creation. When a coding assistant introduces a vulnerable pattern, the ideal response is an inline fix that is proposed, validated, and governed as part of the normal development process. AI can help defenders here when it is connected to reliable security signals, policy context, and evidence from real testing. Counterintuitively, developers using AI to write code often don’t trust AI to automatically remediate code without human review. This takes one of the best ways to keep up with machine-speed created vulnerabilities and slows it down to human speed. An acceptable balance between risk and speed must be found.

Approval is not governance

CISOs should focus on governance, not just approving AI coding tools. Governance means tracking where AI-generated code enters your environment, documenting the policies and tests applied, recording what issues were found and fixed, and keeping proof of these decisions. This documentation becomes critical as AI-assisted development becomes standard. If vulnerable code reaches production, you’ll need to show that adequate controls were in place and risks were managed according to policy.

What leaders should do now

CISOs and engineering leaders should treat AI-generated code as untrusted until proven otherwise. They must require automated testing before release, enforce dependency controls, prioritize remediation based on exploitability and business impact, and measure success by the rate at which critical risk is reduced.

Additionally, boards and organizational policymakers should ask whether organizations can demonstrate that AI-assisted software is governed before it is deployed. The key evidence should include the policies applied, the tests performed, the vulnerabilities remediated, the risks accepted, and the approvals recorded. Today, many organizations can confidently track what their AI tools produce, but they cannot demonstrate how that output was secured, reviewed, and governed before reaching production. The industry is still working to close this gap.

AI is changing how quickly software risk moves through the enterprise. The organizations that succeed will make security move just as quickly by embedding governance, remediation, and proof directly into the software delivery pipeline.

The post AI-generated code has made security debt a governance problem appeared first on CyberScoop.

The AI-focused executive order President Donald Trump signed last month gave the Treasury Department, the National Security Agency, and the Cybersecurity and Infrastructure Security Agency (CISA) 30 days to establish a new “AI cybersecurity clearinghouse.” The deadline passed last week.

The clearinghouse is meant to coordinate the scanning, discovery, and validation of software vulnerabilities in critical infrastructure, and then prioritize how those vulnerabilities get patched and distributed.

It’s the right problem to solve. The question now is whether what is created will actually solve it.

The risk is that urgency produces something that looks like a clearinghouse, but functions like a committee: collecting information, convening meetings, and then stalling when it gets to the hard part.

Going beyond bug discovery is mission critical

It’s counterintuitive at a moment when AI-assisted vulnerability discovery is advancing rapidly, but the hard part is no longer just finding bugs. Those of us working at the intersection of AI and cybersecurity know where the real bottleneck is. HackerOne has seen it firsthand as a launch partner in Patch the Planet, OpenAI‘s initiative to use AI to find and fix vulnerabilities in critical open-source software at internet scale. The lesson underpinning that work, and informed by more than a decade of running vulnerability disclosure programs, is consistent: AI tools can surface vulnerabilities faster than anyone can act on them. What lags behind is everything that comes after discovery: deciding which findings are real, assessing severity in context, writing and testing a fix, and getting a patch accepted and deployed by the people responsible for maintaining the affected code.

Experienced human reviewers frequently disagree with AI-assigned severity ratings, because a model cannot see a project’s threat model or operational context. Software providers, especially the many volunteer open-source maintainers that so much of today’s digital infrastructure rely upon, face a relentless queue: verify the claim, assess the importance, write the patch, coordinate disclosure. AI has accelerated the incoming volume without yet equally accelerating our people and processes’ capacity to manage it. Better bug-finding tools mean you find more bugs. The improvements that really matter are the ones that help defenders push patches out and get them deployed faster.

That lesson should sit at the center of how the clearinghouse is designed.

If the clearinghouse focuses primarily on scanning coordination, which the executive order’s text emphasizes, it risks widening that gap rather than closing it. A body that finds more vulnerabilities but cannot move them to resolution is not a security win. At national scale, it is a backlog generator.

Laying a foundation for success

The administration can get this right, but it requires building the correct infrastructure now, not layering it on later.

The clearinghouse needs to do more than coordinate scanning. It needs to actually triage the results. Its core job should be filtering reports to identify which findings are truly credible, exploitable, and consequential for critical infrastructure. Using shared validation standards and risk-based prioritization, it can determine what warrants a national response. Otherwise, it’s just automating bigger backlogs.

Second, the clearinghouse also needs to tackle something more fundamental. Defenders don’t have the resources to respond to what gets reported. Vulnerabilities in critical infrastructure often live in open-source code maintained by small teams or individuals with no formal obligation to respond to disclosures and limited capacity to act quickly. The clearinghouse should work with the National Institute of Standards and Technology (NIST) to develop guidelines for open-source maintainers on structuring repositories and workflows to speed up patch review and deployment.

These guidelines should include how to use AI-assisted patching and clarify what downstream consumers of open-source code should do to help maintainers address vulnerabilities.  Federal policy should create incentives for downstream users to share responsibility for remediation through funding, engineering support, AI-assisted patch development, and procurement requirements that reward participation in coordinated vulnerability response.

Third, the clearinghouse should treat software bills of materials (SBOMs), the structured inventories of the components that make up a software product, as foundational infrastructure. SBOMs are what make it possible to trace where a vulnerable component lives across the supply chain. Without them, validated findings won’t be fixed fast enough at scale.

Finally, the clearinghouse should measure success based on what is fixed, not based on what is discovered.  Agencies need to publish data on validation rates, time-to-patch, adoption of fixes, and recurring classes of vulnerabilities. These metrics help AI systems, software vendors, and policymakers to continuously improve how vulnerabilities are addressed.

Most importantly: the agencies standing up this clearinghouse should resist the temptation to build its operational model from scratch. The private sector and the open-source security community have years of experience running exactly the kind of vulnerability intake, triage, and coordinated disclosure workflows the clearinghouse needs. The executive order wisely calls for voluntary collaboration with industry. That collaboration should be structural, not advisory, embedded in how the clearinghouse operates from the start, not bolted on after the architecture is already set.

The clearinghouse can work. But the challenge is no longer finding vulnerabilities. It is building a system that can turn discoveries into action. That is how its success should be measured.

The post Found fast, fixed slow: The gap the AI clearinghouse must close appeared first on CyberScoop.

I keep hearing the same frustration when I talk with security leaders. The real problem sitting on their desk isn’t finding vulnerabilities. It’s deciding which ones actually matter.

The industry has spent billions on better visibility. We’ve convinced ourselves that if we could just discover more vulnerabilities, collect more data, and ingest more threat intelligence, we’d become more secure. But look around. Organizations still aren’t more secure. They’re just overwhelmed.

Then AI arrived and changed the game entirely. In a matter of months, vulnerability discovery accelerated dramatically. AI systems review code faster than human researchers ever could. They identify weaknesses at unprecedented scale. They scan continuously without the limitations of time, staffing, or attention. The headlines have been everywhere. Government leaders are reevaluating AI laws. CEOs are tossing and turning at night.

But we are focusing on the wrong issue. None of this is actually solving what matters most.

For years, security teams have been drowning in findings. Every new threat feed promised greater visibility. What arrived instead was noise—more data, more alerts, more dashboards, more vulnerabilities. Rarely clarity. Now AI is pouring gasoline on that fire.

The conversations around AI in cybersecurity often get stuck in the wrong place. People debate whether it will help defenders move faster or enable attackers more easily. Both matter, but they are not the core issue.

The real consequence of AI is that it’s exposing something organizations have avoided facing. A vulnerability is not risk, it’s just a clue. Risk emerges when information connects to context: how critical the affected asset is, what controls surround it, how likely exploitation is, the business processes it supports, and what happens operationally if it fails.

Without that context, prioritization becomes impossible. Resources get spent on low-risk issues while mission-critical, vulnerabilities sit unfixed.

Now AI is now making the data volume problem almost impossible to comprehend. An enterprise working with hundreds of software vendors, cloud providers, contractors, and technology partners must investigate every relationship. It’s like a cybersecurity nesting doll where AI continuously identifies vulnerabilities across that entire ecosystem, every minute of every day.

The real challenge today isn’t discovering weaknesses. It’s determining which of tens of thousands of newly discovered weaknesses could actually disrupt operations, impact customers, halt revenue, or create regulatory exposure. Most organizations can’t answer that question quickly.

Some still rank risk using severity scores built for technical teams rather than business leaders. Others rely on manual triage that was already struggling before AI. Many still measure security maturity by how many findings they identify rather than the speed and accuracy of their decisions.

These approaches don’t work anymore. They probably didn’t work yesterday either.

What’s uncomfortable to acknowledge is that AI isn’t creating a cybersecurity crisis. It is revealing one that’s existed for years. The organizations that succeed in this an AI world will transform discovery into judgment faster than their competitors. When AI can find nearly every weakness, security belongs to those who know what to act on. It belongs to those who can connect data to business reality.

That’s the real edge. That’s what separates secure organizations from those that are just collecting more findings.

The post Finding vulnerabilities was never the hard part appeared first on CyberScoop.

Post-quantum cryptography didn’t sneak up on the industry. 

For years, security teams, standards bodies, hyperscalers, and governments have been pointing at the same horizon: a cryptographically relevant quantum computer will, eventually, dismantle the public-key algorithms underpinning today’s enterprise security. The latest executive order doesn’t introduce a new threat. It codifies what the field has long understood, and attaches deadlines to it.

For CISOs, the framing shift matters. PQC is fundamentally a readiness problem, not a cryptography problem. Watching Google accelerate its quantum roadmap, or seeing federal agencies restructure their security architecture around PQC, makes the stakes impossible to ignore.” Boards are already asking: “How are we thinking about post-quantum transition today?” For most organizations, the gap between that question and a credible answer is wider than it should be.

The EO is unambiguous on scope. PQC has moved from a research effort to real policy, with deadlines, accountability structures, and direct consequences for federal agencies, contractors, critical infrastructure operators, and the broader private sector that supports them.

Federal high-value systems must transition key establishment to PQC by Dec. 31, 2030. Digital signatures will follow by Dec. 31, 2031.

Those dates may appear distant, but for anyone who has navigated an enterprise-scale security transformation, with the procurement cycles, architecture reviews, and organizational change management that entails, 2030 sits squarely inside current planning horizons. The window for orderly execution is already narrowing.

What makes that window even tighter is that the most immediate risk has nothing to do with deadlines. “Harvest Now, Decrypt Later” attacks are already operational. Nation-state adversaries are collecting encrypted data today and storing it until quantum capabilities are sufficient to decrypt it: intellectual property, health records, financial transactions, source code, government communications, and more. The encryption protecting that data right now is, functionally, a time-delayed vulnerability. Long-lived sensitive data may already be compromised in ways that won’t become visible for years.

The first step for CISOs is shifting from awareness to ownership.

PQC readiness cannot be delegated to individual application teams or treated as a future compliance checkbox. That approach will not survive given the EO’s accountability requirements. Every organization needs a point person: a program lead, a cross-functional steering committee, or a dedicated cryptographic risk office. Whatever the structure, it needs authority and a seat at the leadership table.

That ownership must span security, IT, infrastructure, engineering, product, legal, compliance, procurement, and business stakeholders. Cryptography is embedded across the entire enterprise: certificates, keys, protocols, APIs, hardware, cloud services, code-signing systems, identity infrastructure, third-party platforms. No single team has the bandwidth to address this alone. A cross-functional working group or Center of Excellence should be an organizational prerequisite as we move into the future.

Visibility is going to be critical, and this is where most organizations will find the largest gaps.

CISOs need a clear picture of where cryptography exists across their environment: which algorithms are in use, which systems depend on vulnerable cryptography, what data requires long-term confidentiality, and which business processes would be disrupted by migration. Without that inventory, risk assessment is guesswork, remediation is impossible, and demonstrating progress to regulators or boards becomes an exercise in speculation.

The principle is straightforward: you cannot protect what you cannot see.

Furthermore, a cryptographic inventory cannot be a static spreadsheet updated annually and then filed away. It needs to function as a living view of the organization’s trust infrastructure, covering certificates, keys, algorithms, libraries, protocols, signing systems, certificate authorities, HSMs, workloads, devices, and third-party dependencies. 

Once that visibility exists, prioritization follows from business impact. Systems protecting long-lived sensitive data, critical infrastructure, customer trust, software integrity, and regulated environments move first, with everything else sequenced accordingly.

Beyond visibility, CISOs need a roadmap aligned to the order’s milestones rather than aspirational planning documents that never translate into funded programs.

The 2030 key establishment deadline requires understanding every point where encryption and key exchange mechanisms operate across critical systems. The 2031 digital signatures deadline extends that challenge to software integrity, code signing, document signing, authentication, identity infrastructure, and long-term verification. This is a multi-year transformation program, and it warrants the same organizational rigor as any other enterprise-wide initiative of comparable scope.

That means three categories of dedicated resources. First, funding: PQC readiness cannot be absorbed into existing security budgets without displacing other priorities. It requires multi-year investment in discovery tooling, testing, migration execution, automation, and governance. Second, talent: organizations need cryptography expertise, enterprise architecture capability, PKI experience, risk management, compliance support, and program leadership, a combination already in short supply across the industry. Third, technology: discovery tools, certificate and key lifecycle automation, policy enforcement, reporting infrastructure, and the architectural capability for crypto-agility.

Crypto-agility is the long-term objective that makes this transition worth doing properly.

Organizations that treat PQC as a one-time algorithm swap will find themselves back in the same position when standards shift again. The quantum transition is occurring in parallel with the rise of AI, machine identities, autonomous systems, and increasingly complex digital ecosystems, all of which depend on cryptographic trust. Organizations that do not actively govern that trust infrastructure will struggle with AI security, software supply chain integrity, identity governance, and the compliance mandates that follow.

The order functions as a forcing mechanism, converting PQC from a future technical concern into a present-day leadership accountability. Three questions now define where an organization stands:

• Do we have a clear picture of where our cryptographic risk lives?
• Do we have a funded, sequenced migration plan that meets the order’s deadlines?
• Can we demonstrate that our trust infrastructure is agile enough to adapt as standards and threats continue to evolve?

The debate over precisely when quantum computing will be a reality is a distraction. Building the visibility, governance, funding, and automation required to move with confidence is where we need to be spending our collective time and effort.

CISOs have moved past the question of whether to act. The operative question is how far behind the organization already is, and how quickly it can transform cryptography from an invisible dependency into a managed, measurable, and adaptive system of trust. The organizations that begin that work now will be the ones with options when the deadlines arrive.

The post What the post-quantum executive order really demands of CISOs appeared first on CyberScoop.

When CISA issues an emergency directive, the message to every federal agency and every security team paying attention is to patch now. For CVE-2026-50751, a CVSS 9.3 authentication bypass in Check Point Remote Access VPN, that directive landed on June 21. despite exploitation beginning in early May. That, six-week active intrusion gap is not a footnote. It is the entire story.

The flaw itself is straightforward in the worst possible way. A logic error in the certificate-validation process, triggered when the deprecated IKEv1 key-exchange protocol is enabled, allows a remote attacker to establish a fully authenticated VPN session without a valid password. No phishing. No credential theft. No lateral movement required to reach the perimeter. The attacker walks through the front door, and the door logs it as a legitimate entry.

By the time Check Point disclosed the vulnerability on June 8, a Qilin ransomware affiliate had already used it to compromise a few dozen organizations worldwide. The post-access playbook was efficient, including Rclone for data exfiltration, the Tox protocol for command-and-control communication routed through disposable VPS infrastructure. Quiet, fast, and designed to complete the job before detection had a chance to matter.

The security product became the attack vector

There is a particular irony to CVE-2026-50751 that the industry needs to sit with. The device that was breached is not an unpatched workstation or a misconfigured cloud bucket. It is the VPN gateway, the product sold specifically to keep attackers outside the perimeter. The control designed to prevent unauthorized access became the mechanism of it.

This is not unique to Check Point, and it is not a criticism of any single vendor. It reflects a structural problem with perimeter-dependent security architecture. When the perimeter device is the trust anchor, compromising that device does not just breach the perimeter. It inherits the perimeter’s authority. Every downstream control, every identity verification, every behavior-based detection tool is now reasoning about a session it believes is legitimate, because the VPN said so.

That is the condition Qilin exploited. And patching the vulnerability, while absolutely necessary, does nothing to change the position of organizations that were breached during the May-June window. For them, the attacker is already operating as a trusted user. The CISA directive is not a remedy for those organizations. It is a message to everyone else.

Why the standard response falls short

The standard sequence after a disclosure like this is one we’ve all heard before—patch the affected systems, update detection signatures, review logs for indicators of compromise. While each of these steps is good practice, none of them solves the underlying problem.

Patching closes the door for future attackers, but it does not evict the ones already inside. Detection signatures help identify known post-exploitation behavior, but ransomware affiliates have demonstrated consistent operational discipline, using legitimate tools for exfiltration and standard protocols for command-and-control precisely because these approaches blend into normal traffic. Log review is valuable, but the attackers who exploited the vulnerability had weeks of access before anyone was looking.

The detect-and-respond model assumes that detection arrives before the damage is complete. Against a weaponized zero-day with a six-week head start, that assumption does not hold. By the time an alert fires, the data has moved. The ransomware is staged. The ransom clock has started.

Making the endpoint harder to exploit

The Check Point vulnerability forces a critical question: how do you stop payload execution when an attacker has already succeeded at authentication and bypassed every other defense?

It requires moving the defensive layer to the endpoint itself, at the point of execution, where the ransomware payload has to operate regardless of how access was obtained. Techniques that morph the runtime memory environment, transforming the structures that malware needs to find and use at execution time, stop the payload deterministically. The attacker can have authenticated credentials, a legitimate session, and weeks of undetected access. If the target environment does not look like what the payload expects, the payload fails.

This is not a replacement for patching. Organizations should apply the Check Point fix immediately, and they should treat any system with IKEv1 enabled during the May-June window as potentially compromised. But patching is the beginning, as the organizations that were inside the six-week exploitation window need a control that works after the perimeter is gone.

The lesson before the next directive

CISA will issue another emergency directive. There will be another authentication bypass, another perimeter device turned attack vector, another financially motivated threat actor with a head start measured in weeks. The patch-and-detect cycle will play out again, and organizations that had their exposure managed entirely at the perimeter will find themselves in the same position.

The lesson here is not that Check Point failed or that VPNs are over. It is that any architecture where a single authentication bypass gives an attacker operating authority over the entire environment has a structural problem that no patch resolves. Closing the door is necessary. Making sure the ransomware cannot detonate even after the attacker is inside is the part the industry still has not solved at scale.

That is the conversation the CISA directive should be starting, and mostly is not.

The post Why patch directives only go so far appeared first on CyberScoop.

The digital battlefield is expanding and changing faster than ever before. Washington must confront mounting threats to critical networks and systems. But there’s one challenge that stands out above the rest: artificial intelligence. The nation’s cyber experts need to be ready to face this new reality.

The CyberCorps: Scholarship for Service program is a federal initiative that has done just that for 25 years, contributing nearly 5,000 cybersecurity professionals to the federal workforce. The program is a success story, but the Trump administration has put this program at risk by attempting to drastically cut its funding. Fortunately, Congress has intervened, and will continue to fund the program. The administration should follow Congress’ lead and support it in the future.

The CyberCorps program was developed as an equivalent to the Reserve Officers’ Training Corp (ROTC) for civilian cybersecurity professionals, awarding student participants full scholarships and stipends for their cybersecurity education in exchange for an obligation to serve the federal government after graduation. Participants also receive specialized instruction and summer internships in addition to their coursework, providing the federal government talented, security-vetted, and well-educated employees to defend the United States from cyberthreats. 

AI is changing cybersecurity, creating both new opportunities and new dangers. CyberCorps is adapting to stay ahead. The situation is driven by three clear trends: AI is expanding rapidly across all sectors, threat actors are using it for more advanced attacks, and the newest AI models can find software vulnerabilities quicker than ever before.

In a report released last month, Google researchers said they discovered a previously unknown security vulnerability developed by AI capable of initiating a large-scale cyberattack. Experts estimate that there is now a three-to-five month window in which adversaries will start to outpace organizations using AI-driven attack methods for discovering cyber vulnerabilities. Jen Easterly, the former Director of the Cybersecurity and Infrastructure Security Agency wrote last year that cybersecurity as we know it is becoming a relic of the past — and that AI is the path forward.

Cyber threats are advancing faster than ever, and our workforce must keep pace. CyberCorps is stepping up to meet the moment. This year, program participants must have an educational background in AI or plan to develop one. The new guidelines require expertise in two critical areas: using AI in cybersecurity operations and securing AI systems themselves. We need experts who can use AI to defend us and people who can protect AI tools from being weaponized. Program graduates will have both skillsets, equipped to handle today’s threats and adapt as they evolve.

To facilitate this effort, the CyberCorps program is supporting existing participant schools by providing AI training. CyberCorps is also allowing schools to dedicate a portion of the money they receive through program membership to creating their own AI training or providing training from other institutions for students and instructors. 

These changes accomplish two important things. They prepare participants as capable cyber professionals while addressing a workforce crisis the government can no longer ignore. The Pentagon alone estimates it needs 25,000 more cyber experts. By aligning the CyberCorps program with the Trump administration’s AI workforce priorities, the government is finally putting resources behind a solution that matters.

President Trump and the National Science Foundation deserve credit for such agile footwork in adapting to this challenge. But that clear recognition makes the current budget situation even more galling. The greater emphasis on AI in the CyberCorps program could support government expertise in AI for years to come, but only if the program is properly resourced.

The Trump administration’s 2026 budget request included a 65 percent cut in funding for CyberCorps at only $21.7 million, which Congress rectified by appropriating $63 million. Despite this clear congressional signal, the president’s 2027 budget again requested $21.7 million, a drastic cut. 

Again, Congress is stepping in to fix things. The congressional funding report for fiscal year 2027 recommends adding between $60 million and $70 million of funding to the program. The report also encourages the inclusion of “AI in activities funded by the program to maximize the learning potential in both fields” and advises an increase in the number of scholarships offered. To fully institute these recommendations, the program will require even more funding. Congress is right on target.

America needs strong cyber defenders ready for the AI era. CyberCorps must lead the federal government forward. With the right support, the program will deliver the cyber success our nation demands.

Rear Admiral (Ret.) Mark Montgomery is the senior director of the Center on Cyber and Technology Innovation at the Foundation for Defense of Democracies where Sophie McDowall is a research associate. 

The post CyberCorps is adapting to AI. The budget isn’t keeping up. appeared first on CyberScoop.

AI models such as Anthropic’s Claude Mythos and OpenAI’s Daybreak represent a fundamental inflection point in security. These advances are not only reshaping technology but also redefining trust, risk, and the relationship between humans and intelligent systems. As innovation accelerates, AI governance and responsible deployment are becoming strategic priorities for every organization.

Historically, governments have played a stabilizing role during moments of transformational technological change. Yet the pace and scale of the AI era demand a new model, one built on partnership rather than control, balancing societal responsibility with the need to sustain innovation and global competitiveness.

The White House’s executive order on AI governance signals that collaboration between the industry and policymakers will increasingly shape the future landscape. Proposed frameworks that promote transparency and responsible development point toward a more coordinated approach to risk management.

Effective governance of AI models should balance clear safeguards with the speed of innovation, aligning organizations, policy makers, and technology leaders around a shared goal: advancing AI in ways that strengthen trust, security, and long-term value. The path forward is not defined by heavy-handed oversight, but by building an ecosystem of accountability.

Three key points substantiate this approach.

First, the industry should recognize Anthropic’s release of Mythos as an example of responsible innovation. Company leaders recognized the model’s risks and deliberately delayed broader deployment, allowing early testing to surface vulnerabilities before widespread adoption.

The broader lesson extends beyond a single model release. Responsible leadership means prioritizing decisions that build trust and enable sustained innovation. As AI capabilities accelerate, the most successful organizations that lead will be those that weave accountability through their ambitious pursuits, rather than treating them as competing priorities.

Second, innovation rarely thrives under rigid frameworks. History has shown that many compliance regimes, while well-intentioned, incentivize organizations to optimize for requirements rather than outcomes. Security is strengthened through systems designed for resilience and trust, which goes beyond mere compliance.

Third, slowing U.S.-based AI innovation risks weakening long-term competitiveness. The U.S. remains a leader in AI but maintaining that position will require balancing responsible safeguards with continued investment and progress. Overly restrictive approaches risk slowing domestic advancement while other nations continue accelerating development and capability.

An effective AI governance approach would encourage further responsible AI model development, as demonstrated by Anthropic. It would avoid direct government regulation and instead enforce accountability for companies that are irresponsible with AI development.

Hopefully, the partnership and collaboration between government entities and industry will continue beyond the White House order. Policymakers and industry leaders should create incentives that reward AI vendors for considering societal implications before releasing new solutions. This framework would highlight responsible providers as models for the industry while imposing meaningful consequences based on demonstrated societal harm that direct affects business and technology decisions.  

AI models such as Mythos and Daybreak underscore a broader reality: the future of AI will be shaped by the trust around innovation, not merely by its development pace. The next era of AI leadership will require a new model of collaboration between industry and policymakers that maintains the speed and adaptability that innovation demands while establishing meaningful accountability for real-world outcomes.

The objective should be to guide progress responsibly. The organizations and nations that lead in the AI era will be those that demonstrate how innovation and accountability work together to strengthen trust, security, and long-term value creation.

Art Gilliland is CEO of Delinea, a cybersecurity company focused on human, machine and AI identity protection.

The post The AI security race needs accountability, not overregulation appeared first on CyberScoop.

There’s this old proverb that’s stuck with me over the years: “Dig the well before you are thirsty.”

It really means you should prepare for the crisis before it arrives. In cybersecurity, it’s a mentality that’s long underpinned investment, strategy and board-level conversations. And by many measures, organizations appear to have already ‘dug’ that well. They feel ready.

New research even emphasizes how nearly eight in ten organizations (79%) are confident they’re prepared to handle a cyberwarfare attack, while a further 76% believe they’re ready to mitigate an AI-driven threat if it came their way.

Yet, reality tells a more complicated story. Confidence alone doesn’t translate into readiness. With the constant advancement of AI alongside ongoing geopolitical escalations, many enterprises are finding that traditional preparedness markers simply don’t translate into real resilience.

What we have is a readiness paradox forming within the industry. Organizations are realizing that the ‘well’ they believed was already dug isn’t quite as deep as they thought. So, where are they going wrong?

The real cost of mistaking preparedness for resilience

The root cause can be traced back to generative AI’s rapid rise and adoption. It’s a tool that dominates boardroom discussions, and, while defenders are racing to adopt it, attackers have already weaponized it at scale. The challenge is that ambition on the defensive side is still outpacing operational reality.

More than half of organizations (54%) that participated in our research recently admitted they lack the budget and resources required to fully invest in AI-powered security solutions. A further 55% say they don’t yet have the expertise needed to implement and manage those technologies effectively. In other words, most teams are still building the capabilities required to support the very tools they’re being encouraged to adopt.

At the same time, generative AI is accelerating the scale and size of the attack surface security teams are expected to defend. Modern enterprises now operate across sprawling ecosystems – everything from cloud infrastructure to third-party integrations – with each new connection introducing a potential entry point into an enterprise’s environment, creating a growing web of complexity.

That complexity is exactly what attackers exploit. Organizations are facing an average of 960 security alerts a day, creating an environment of constant triage where excessive alerts. These often lack the context needed to prioritize them, leading to slower responses, missed signals and general unpreparedness. It’s why we increasingly see headlines like China-linked hackers breaching numerous companies and government agencies in different countries or a single compromised account giving hackers access to millions of banking records.

Part of the problem ultimately comes down to how preparedness is often measured. For many organizations, readiness is still closely tied to compliance – passing audits, implementing required controls or meeting regulatory benchmarks. But compliance success doesn’t always translate into technical resilience.

The deeper challenge lies in how exposure continues to accumulate across increasingly complex digital environments. Until organizations develop a clearer understanding of how risk forms and concentrates across their digital ecosystems, preparedness will remain difficult to translate into genuine resilience.

From confidence to resilience

If organizations are to close the gap between perceived readiness and operational reality, they need a clearer understanding of where risk actually exists. This is where cyber exposure management comes in. At its core, it shifts the focus from reacting to incidents toward continuously understanding how exposure forms across the enterprise.

Consider a typical large enterprise with thousands of connected assets, spanning employee laptops, printers, operational equipment and more. A single phishing email could land in an inbox and compromise a user’s laptop. On its own, that device may seem like a low-priority alert. But, if that laptop had access to key shared drives, internal applications or operational systems, the attacker now has a pathway to move deeper into the environment and potentially reach sensitive data or critical services.

Without awareness of how every asset and system connects, security teams are left prioritizing alerts based on technical severity rather than operational consequence. And that’s what makes cyber exposure management so critical. Instead of treating vulnerabilities as isolated technical issues, it continuously maps assets, connections and dependencies across the environment to reveal how risk actually concentrates.

This awareness is built through continuous visibility. When organizations can identify assets in real time, understand their behavior, and analyze how they connect across the broader ecosystem, they gain a contextual overview of risk that traditional security tools simply struggle to provide.

Teams can prioritize exposures by business impact and address them quickly to protect the environment. This clarity helps them invest where it reduces risk the most, identify the systems most critical to operations, and focus defenses before disruptions occur

Digging deeper on preparedness

Modern digital ecosystems are simply too interconnected, too dynamic and too exposed for risk to ever be fully eliminated. It’s all about understanding where exposure truly exists and how quickly it can evolve. For leaders, this requires a shift in mindset, because preparedness is rarely revealed in moments of calm – it’s tested when pressure arrives.

So, before that moment comes, make sure the “well” is dug deep enough to withstand what lies ahead.

The post The readiness paradox: Why a false sense of cyber confidence is becoming a liability appeared first on CyberScoop.

Earlier this month, ShinyHunters breached Instructure’s Canvas platform twice within a single week — stealing 3.65 terabytes of data from approximately 275 million users across more than 8,000 institutions. The group defaced login pages at hundreds of schools during final exam periods, forced Canvas offline, and extracted a ransom payment before Congress opened a formal investigation. The attack did not require exotic malware or zero-day exploits. Attackers entered through compromised “Free-For-Teacher” accounts, escalated rapidly, and exfiltrated sensitive data at scale before Instructure could contain them.

That sequence — entry through weak identity controls, rapid lateral movement, mass exfiltration, extortion, disruption — is now the standard playbook. It will happen again, unless the priority for security and technology leaders becomes reducing the blast radius of every intrusion before it happens.

The problem with how enterprises think about SaaS risk

Modern organizations have consolidated critical operations inside shared SaaS platforms, creating enormous concentrations of risk in single points of failure. When Canvas went down, thousands of students could not access coursework, faculty lost contact with their classes, and administrators scrambled to postpone exams. The scale of disruption came from how deeply institutions depended on Canvas, not from the vulnerability alone.

That asymmetry is the defining feature of SaaS risk in 2026. A single compromised account at a shared platform can trigger sector-wide operational failure. Yet most enterprise security frameworks still treat SaaS platforms primarily as availability problems — measured by uptime, recovery time objectives, and business continuity plans. Canvas exposed the gap in that thinking. Availability means nothing when the platform is operational but the data inside it has already been stolen.

Resilience in SaaS environments requires a harder and more honest premise: treat compromise as continuous and expected. Attackers will reach critical systems. The real test is how much they can take, how far they can move, and how long they can persist before detection and containment.

Identity is the perimeter now

The Canvas attack followed a pattern that has repeated across sectors for years. By compromising legitimate accounts with excessive standing privileges, the attackers moved laterally through Canvas infrastructure, maintained persistence, and exfiltrated data at a scale that took days to quantify.

Too many organizations still operate with fragmented identity controls, inconsistent privilege management, and limited visibility into how accounts interact across SaaS integrations. When attackers compromise a legitimate account, they inherit whatever access that account holds — and in most environments, that access far exceeds what the user actually needs. The result is that identity has become the most reliable attack surface in the modern enterprise, and most organizations are still treating it as a secondary concern.

Strong passwords and multifactor authentication are necessary but no longer sufficient. Enterprises need continuous identity verification, tightly scoped privileges, aggressive governance over third-party integrations, and real-time visibility into anomalous access patterns across SaaS systems. Identity governance cannot be a compliance checkbox. In cloud-native environments, it should be the primary control that determines how far an attacker can travels if they manage to get inside.

Data protection cannot stop at the application layer

Even organizations with strong identity controls face a second, underappreciated problem: the data stored inside SaaS platforms is often far less protected than the credentials used to access it.

Enterprises accumulate vast repositories of sensitive information inside SaaS environments — private messages, accommodation requests, financial records, personal disclosures — while relying almost entirely on application-level access controls to protect it. When those controls fail, as they did at Canvas, the data is immediately readable, searchable, and monetizable. 

Attackers do not need to crack anything. They simply take it.

Cryptographic protections — including encryption strategies that preserve organizational control over sensitive data even after it leaves the platform — directly reduce the value of a successful exfiltration. Stolen data that cannot be read or used is far less valuable as an extortion instrument. That distinction matters significantly in today’s threat environment, where the leverage attackers extract from stolen data often outlasts the breach itself.

The threat does not expire when the incident ends 

The “agreement” between Canvas’s parent company and attackers illustrates a risk that most organizations have not yet fully priced in. While Instructure received digital confirmation that the stolen data was destroyed, Congress opened an investigation anyway. The Instructure CEO has been called to testify before the House Homeland Security Committee. Affected institutions — many of which had no visibility into Instructure’s security posture or incident response capabilities — remain accountable for protecting student data they can no longer control.

That accountability gap will not close after Congress concludes its inquiry. Sensitive data stolen during incidents like Canvas retains value long after the breach itself. Adversaries increasingly collect encrypted data today with the expectation that it can be decrypted later as cryptographic standards age or quantum computing capabilities mature. This “harvest now, decrypt later” approach means that encryption protecting data only in the present still leaves organizations exposed downstream.

Strong cryptographic protection must therefore be paired with crypto-agility and post-quantum readiness. Security leaders should assume that any sensitive data exfiltrated during a SaaS breach may remain a target for years, not days. If stolen data remains immediately usable, attackers retain leverage indefinitely. If it does not, the economics of extortion shift.

What the Canvas breach actually demands

The lesson from Canvas is not that SaaS platforms are inherently insecure. They remain foundational to how modern organizations operate and scale. The lesson is that the assumptions underlying most enterprise security strategies — that prevention is the primary objective, that access controls are sufficient data protection, that recovery means restoring uptime — no longer match the realities of today’s threat environment.

Attackers have already internalized this. They target SaaS platforms precisely because the concentration of data and operational dependency makes them extraordinarily high-value targets. They exploit identity weaknesses because those weaknesses are pervasive and reliable. They apply extortion pressure because stolen data retains leverage long after technical remediation.

The organizations that close this gap — by treating identity governance as mission-critical infrastructure, implementing cryptographic protections that survive exfiltration, building recovery discipline alongside prevention, and planning for post-quantum exposure — will be significantly better positioned when the next breach arrives. And it will arrive. The only variable is how much it costs.

Rishi Kaushal is the CIO of Entrust, a company that helps organizations fight fraud and cyber threats with identity-centric security.

The post The Canvas breach proved that prevention is no longer enough appeared first on CyberScoop.

If you had time to walk the expo floor at this year’s RSA Conference, it was impossible to miss the shift in our industry. Artificial intelligence has moved from an emerging layer to the foundation of what powers cybersecurity companies. But from our vantage point as investors who work closely with founders and operators, the bigger shift is how AI is changing how these companies are formed, funded and scaled.

The past year marked an inflection point. A surge in venture funding and headline acquisitions underscored a market moving faster than many expected. Startups that once spent years iterating toward product-market fit are now emerging from stealth with mature products and raising large early rounds almost immediately. Meanwhile, the traditional progression from seed to Series A is compressing into a much shorter, higher-stakes window, and legacy companies are being forced to move faster than ever to stay relevant in today’s landscape.  

Venture funding is concentrating around fewer, larger AI bets

The acceleration reflects real capability. AI has cut the time and cost of building and iterating on cybersecurity products, allowing small teams to move at unprecedented speed. But faster development doesn’t change the basics: durable businesses still require clear differentiation, strong go-to-market execution and proven customer demand.

What has changed is how capital is being deployed. Venture funding in cybersecurity is increasingly concentrated into fewer companies, with larger rounds and higher valuations. The market is increasingly binary: startups are expected to either secure AI systems or use AI to deliver clear, measurable improvements in security outcomes. Companies that can’t clearly stake out one of those positions are finding it harder to attract attention from both investors and acquirers.

Higher valuations can accelerate momentum, but they also raise the bar for performance. When growth does not materialize as expected, the path forward becomes more difficult, particularly in a market that is moving as quickly as this one.

AI-native startups are operating with smaller, more technical teams

AI is also reshaping how cybersecurity companies are staffed and operated. The most effective teams today are smaller and more technical, relying heavily on automation to extend their capabilities. Engineers are increasingly focused on orchestrating AI systems rather than building every component from scratch, shifting the nature of technical work toward higher-level problem solving and system design. They can iterate faster than ever before, putting pressure on fast-paced innovation and high-capacity outputs. 

This is creating a widening gap between companies that are built around AI from the start and those trying to retrofit it into existing models. For newer startups, this approach is often foundational. For incumbents, it can require significant changes to both technology and culture, leading to an upcoming M&A wave that’s already in the early innings.  

Threat actors are using AI to scale attacks and lower barriers to entry

At the same time, the threat landscape is evolving. AI is lowering the barrier to entry for offensive cyber capabilities, enabling less sophisticated actors to execute attacks that previously required significant expertise. This is increasing both the volume and complexity of threats facing organizations. We’re seeing early responses to that with things like Anthropic’s Project Glasswing, which aims to bring together leading organizations to protect critical software.

The expansion is not limited to traditional network or endpoint attacks. AI is introducing new attack surfaces, from machine identities to autonomous agents and decision-making systems. It is also unleashing new forms of risk, including more advanced disinformation campaigns and other narrative-driven attacks that can impact markets and corporate reputations as much as technical systems.

Cyber defense is shifting toward autonomous, machine-driven models

As attackers scale their use of AI, defenders are being forced to do the same. Cybersecurity is moving toward a model where machine-driven systems play a central role in both detecting and responding to threats. In many cases, the dynamic is moving from human vs. machine, to machine vs. machine.

This shift is driving innovation across the market. New categories are emerging around securing AI systems and workloads, while established areas like endpoint security, data protection and vulnerability management are being rebuilt with AI at their core. These changes are enabling new capabilities but also increasing the pace of competition across the industry.

M&A and platform strategies are accelerating alongside AI innovation

The speed of innovation is also reshaping consolidation across cybersecurity. Larger platforms are moving to incorporate AI capabilities more quickly, while startups are building toward platform strategies earlier in their lifecycle. This is compressing timelines for both growth and acquisition. When incumbents can’t innovate quickly enough, they can buy instead.

Capital continues to play a central role in this dynamic. Strong funding environments are enabling companies to scale quickly, but they are also introducing risk when valuations outpace underlying performance. Some of the largest rounds are functioning as signals of market leadership as much as sources of operating capital.

There is growing awareness that not all these companies will meet expectations. The same conditions that enable rapid growth can also expose weaknesses quickly, particularly if customer adoption and revenue do not keep pace.

What founders and investors are watching for the rest of 2026

The defining characteristic of the current market is speed. The gap between companies that can adapt to these changes and those that cannot is widening quickly.

For founders, that means balancing urgency with discipline – building AI-native products while staying focused on real customer problems. For investors, it means identifying teams that can execute in a rapidly changing environment and build companies that endure beyond the current cycle.

The cybersecurity landscape has always evolved alongside technology and threat activity, but the pace of change today is different. The companies that emerge as leaders in the next phase of the market will be those that can operate effectively in that reality, where AI is foundational, competition is global, and the timeline for success is shorter than ever.

The post AI is separating the companies built to scale from the ones built to sell appeared first on CyberScoop.

Missile and drone attacks that took out cloud data centers in the Middle East underscored a critical vulnerability in the modern economy: reliance on digital infrastructure that sustains competitive advantage and operational continuity for corporations, nations, and militaries. 

The outages and downstream disruption were a preview of a new form of strategic and operational risk. Data centers have long been the backbone of the digital economy. What is changing is the scale of dependence as AI workloads dramatically increase the compute power required to run businesses, supply chains, and national security systems. 

Artificial intelligence has moved beyond business applications and into the core of warfare and national security. Last month, The New York Times reported that AI is “totally integrated” into the collection of intelligence and its use in strategic decision-making and military operations. Even if AI models are not directly firing weapons, AI-enabled analysis now plays a central role in how modern militaries gain visibility, find insights, and drive action.

That matters because it changes what should be considered critical infrastructure. If AI is a competitive advantage for companies and a battlefield advantage for warfighters, then the infrastructure that trains, hosts and runs AI becomes a high-value target. Attacks on the digital infrastructure organizations rely on can do more than inflict financial damage. They can slow decision-making, degrade logistics and reduce military effectiveness without ever engaging a conventional force.

Historically, nation-state campaigns targeting data centers and service providers focused on cyber intrusions for espionage or pre-positioning. What is different now is the emergence of physical attacks on digital infrastructure during active conflict. Russian military intelligence has been linked to campaigns aimed at digital infrastructure and managed services, often as part of a supply chain attack to compromise organizations at scale. Iran-aligned groups have repeatedly demonstrated willingness to target private sector entities to advance geopolitical goals. In many cases, the objective was access: steal data, implant persistence, map networks, and maintain a foothold that could be used later for espionage or disruption. 

What’s clearer now than ever before is that data centers and the AI workloads they support have become so vital to modern society, our adversaries will seek to degrade or destroy their efficacy as a tactic of both kinetic and cyber warfare.

We have already seen how quickly a digital incident can become real-world disruption. On March 11, reports surfaced of thousands of servers and endpoints wiped inside Stryker, a U.S.-based medical device manufacturer. A hacktivist group sympathetic to Iran, known as Handala, claimed responsibility. The incident reportedly halted Stryker’s global production after attackers accessed its Microsoft environment and issued a wipe command via Intune. Even without a single missile, the outcome looked like a strategic disruption: operations stopped and downstream customers felt it.

For business leaders, the imperative is clear: treat operational resilience as a board-level priority in the AI era.

In the world of corporate IT, cybersecurity prioritizes confidentiality: preventing theft of sensitive information. Resilience is a different discipline. It is the ability to sustain operations when systems are degraded, disrupted or actively under attack. For data centers and the businesses that depend on them, resilience comes down to preventing cascading failures and reducing the consequence when something inevitably goes wrong.

These developments carry an important implication for the private sector. Digital infrastructure is increasingly a strategic target, making resilience a core business priority rather than a narrow IT issue. For business leaders, the impact of data center disruption extends into multiple, often overlooked areas of cybersecurity risk.

For example, AI’s growth is colliding with a power wall in many regions where grid capacity cannot scale fast enough. That is driving facilities toward new power dependencies, including on-site generation through distributed energy and renewables, yielding more complex power management environments. This power infrastructure becomes a pressure point as interruptions to power supply or management systems can quickly force a data center offline. Russia has on several occasions demonstrated the ability to target and disrupt power generation and distribution in Ukraine in both 2015 and 2016.

Building management and automation systems, including HVAC and physical access controls, are another. These systems are essential to creating safe and supporting operational environments, but they typically have long capital depreciation cycles and inconsistent security safeguards. Frequently exposed to the Internet, and commonly misconfigured and not properly secured, they can become a pathway to outages by an attacker.

With an increasing density of computing infrastructure, thermal management has become a core environment control in data centers. As the industry adopts liquid cooling for dense AI loads, interference with cooling is no longer a niche technical issue. It is a risk vector that can cause downtime and potential equipment damage if breached by attackers.

Remote access creates another major exposure. Data centers rely on vendors, contractors, and systems integrators for maintenance, monitoring, and support, and each remote connection can become an entry point if it isn’t tightly controlled, centrally managed, and well secured. Adversaries often target these trusted access routes because they can be easier to compromise than a well-defended perimeter, allowing attackers to bypass standard controls and safeguards.

All of this has broader economic implications because data center disruption does not stay inside the technology sector. It cascades into the industries that keep society functioning and supply chains moving: hospitals, electric utilities, chemical production, food and beverage, oil and gas, and transportation. An extended outage becomes missed shipments, halted production, delayed care, safety concerns and lost trust.

What should leaders do now?

Start by defining resilience targets that match business reality: what must stay running, what can degrade, what cannot fail. Then invest in the controls that limit the impact of an incident. Segmentation between IT and OT assets should be non-negotiable. Remote access should be treated as a critical risk pathway with least privilege, strong authentication and continuous monitoring.

Manage facilities systems such as building management systems, power, and cooling controls as critical operational technology, with asset inventories, vulnerability management, logging, and incident response plans that anticipate disruption.

Finally, train to operate under degraded conditions. Tabletop exercises should include scenarios like loss of a cloud region, partial failure of a facility, or compromise of a management plane. Use these exercises to validate that the organization can maintain essential operations and recover quickly when disruptions occur. 

Policy is moving in this direction as well. Governments are increasingly treating data centers as critical infrastructure. Policies and frameworks such as the National Cybersecurity Strategy, CISA’s Secure by Design principles, and international standards like IEC 62443 all reflect a growing recognition that digital infrastructure is a national security issue. Companies that get ahead of this shift will not only reduce risk, they will build competitive advantage in a world where downtime can become a strategic weapon.

In the AI era, data centers are essential infrastructure for modern economies and national security. Their rising importance also makes them attractive targets in cyber and physical conflict. Protecting them is no longer just about safeguarding company operations, it is about protecting the systems society depends on every day. 

Grant Geyer is the chief strategy officer at Claroty.

The post Why data centers now belong on the critical infrastructure list appeared first on CyberScoop.