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.

The post We know how to protect our troops from telecom attacks. We’re just not doing it. 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.

On July 1, the Cybersecurity and Infrastructure Security Agency (CISA) published a seven-page notice in the Federal Register that could fundamentally change how the U.S. government works with private companies to protect critical infrastructure from cyber threats and natural disasters.

The notice, “Establishment of the Alliance of National Councils for Homeland Operational Resilience – Critical Infrastructure (ANCHOR-CI),” details a new framework for CISA to build councils that let private partners advise the government on cybersecurity and critical infrastructure issues. This replaces the 20-year framework that the federal government used to work with critical infrastructure partners, formerly known as the Critical Infrastructure Partnership Advisory Council (CIPAC). For at least the next two years, ANCHOR-CI will dictate how the government and industry collaborate to protect critical infrastructure.

When former Homeland Security Secretary Kristi Noem terminated CIPAC in March of last year, Congress and private-sector partners objected immediately. The damage was real. The 16 sector-coordinating councils (SCCs), that brought together private partners from each critical infrastructure sector lost their legal mechanism to meet with the federal government. They could no longer advise and provide group consensus to their federal counterparts without triggering laws that CIPAC exempted. To be sure, CISA still had the Joint Cyber Defense Collaborative. Department of Energy had the Energy Threat Analysis Center. The National Security Agency had the Cybersecurity Collaboration Center. But none, however, replaced what the SCC ’s did: stand as steady forums where industry and government hashed out how to best assist critical infrastructure owners and operators.

Not that the SCCs were flawless. I worked with or alongside SCCs for more than a decade, most recently at CISA, and I am familiar with their shortcomings. SCC membership could be stagnant. The quality of recommendations to the government varied.  New members faced barriers based on each sector’s rules.

The core problem was how the model locked each sector in. DHS built SCCs in an era when critical infrastructure risks were looked at through a sector-specific lens: energy, transportation, water, communications, and so on. Today’s cyber threats jump across these sectors. A vulnerability in a cloud service provider or industrial software platform can harm hospitals, pipelines, manufacturers, water utilities, and financial institutions simultaneously.

To see why ANCHOR-CI works better than the CIPAC structure, we need to go back 20 years and understand what CIPAC was trying to do. Congress didn’t codify CIPAC into law. Instead, Congress authorized DHS to establish advisory committees exempt from the Federal Advisory Committee Act (FACA). This exemption let the federal government and SCCs hold private meetings without public notice, convene quickly without complying with FACA procedural requirements, pick members based on expertise rather than balanced public representation, and skip FACA’s public recordkeeping requirements. (But these FACA exemptions do not exempt records from the Freedom of Information Act, a common misconception.)

ANCHOR-CI carries this power forward. Crucially, ANCHOR-CI end the siloed, sector-by-sector approach by creating four types of councils: Critical Infrastructure Sector Councils; Cross-Sector Councils; Critical Infrastructure Industry Councils; and Regional Coordinating Councils.

Critical Infrastructure Sector Councils: These are basically the old SCCs, but with a change in power.  The CISA director now approves or removes any council member directly.

Cross-Sector Councils: These councils matter most. Specifically, they tackle “current and emerging threats, interdependencies, or other issues impacting multiple critical infrastructure sectors or industries.” Examples might include councils on countering unmanned aerial systems, AI threats, or reducing dependence on foreign supply chains. CISA could also revive and expand the Space Systems Critical Infrastructure Working Group.

Critical Infrastructure Industry Councils: Like cross-sector councils but designed for issues that span sectors in ways that don’t fit neatly into a given sector. After Volt Typhoon—a Chinese campaign that installed malicious malware in critical infrastructure—CISA could establish an Operational Technology council with original equipment manufacturers, software providers, and critical infrastructure owners to address and stop the threat.

Regional Coordinating Councils: CISA says these will help state and local governments tackle regional risks. What that means in practice is unclear. CISA could create 10 councils tied to 10 regional offices. Or it could create councils focused on real regional risks: preparing for the Cascadia subduction zone in the Pacific Northwest, droughts in the Southwest, or hurricane in the South and Mid-Atlantic.

In the end, like any policy, success hinges on how CISA carries it out. If CISA runs ANCHOR-CI thoughtfully and with transparency, it could become the biggest upgrade in of public-private cybersecurity collaboration work in two decades.

The post ANCHOR-CI could fix 20 years of broken government-industry collaboration 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.

Similar to the events that unfolded with the Conti ransomware group’s demise in 2022, leaked internal chat logs of the Black Basta cybercrime group last year gave us a peek behind the curtain of modern ransomware operations. We found that these groups have continued to evolve into highly sophisticated and organized syndicates, taking a corporate-style approach to extortion.

According to our analysis, Black Basta members carefully studied victims to launch advanced phishing and malware campaigns, exploit vulnerabilities and intimidate victims into paying via panic-triggering tactics. They were exceptionally organized: A call team responsible for social engineering schemes worked a set schedule from 6 p.m. to 2 a.m. Moscow time. Additional tasks were outsourced to third parties — malware services, phone operators and spammers — as if they were hiring contractors. Internal performance assessments weighed heavily in determining wages and ransom payment distributions to teams, just like profit sharing in the corporate world.

Before shutting down in 2025, Black Basta launched attacks against 520 victims in 39 industries using two dozen ransomware variants, collecting at least $107 million in bitcoin payments.

The leaked chat logs illustrate that ransomware — which now amounts to a $74 billion global industry annually — has matured far beyond its isolated, primitive beginnings. The negotiation phase has emerged as a deliberate part of the attackers’ business model, taking up to two weeks so they can escalate pressure while giving targeted organizations a narrow window to make coordinated decisions.

Negotiations are also becoming more customized to the victim, with tiered pricing models based on the company’s size, along with data audits of the compromised information with respect to value and sensitivity.

The entire modern ransomware experience appears sharply influenced by two ever-developing components:

Personalization. Reconnaissance and post-compromise assessments are driving how adversaries set and adjust their payoff demands. As part of the process, they look closely at revenue and financial position, contracts and customer relationships, board-level communications, backup and recovery capabilities, sensitivity levels of data and cyber insurance policy details. Cyber insurance actually acts as a “pricing signal,” lending insights into the victim organization’s financial means, willingness to pay and likely ransom amount boundaries during negotiations.

Pressure tactics. Multi-extortion execution is turning up the heat on targeted companies. This includes standard file encryption and data exfiltration, while adding layers like distributed denial-of-service (DDoS) attacks, operational disruption and third-party harassment. The aforementioned data audits give ransomware groups a more precise valuation of the stolen data, helping them further force victims to pay during negotiations.

The attackers will also intentionally manipulate deadlines to maximize their odds of success. They may first set a tight deadline to create urgency, then extend it if they sense doing so will result in a more certain payday. Or they could take the opposite approach by compressing deadlines from days to mere hours to inspire a panic-led decision to meet the ransom demand.

The presence of an increasingly expanding cybercriminal ecosystem enhances these personalization and pressure tactics, with ransomware groups able to hire internal workers or outside support for initial access, data theft, victim profiling, stolen data analysis, DDoS/harassment and payment facilitation. This reflects a broader shift toward specialization.

So how should organizations, typically the chief information security officer (CISO), respond? By incorporating the following best practices into their cyber defense strategies:

Understand the options and risks. Often CISOs must decide between two terrible options: pay a ransom or face reputational or operational damage. In some countries, sending money to a sanctioned entity is illegal, and though paying a ransom demand may not be universally illegal, it is regularly discouraged by law enforcement as it incentivizes future malicious activity. However, not paying a ransom could impact not only immediate operations, but also long-term organizational growth.

Understand the criminal ecosystem. Maintain awareness of ransomware trends. Track the new, the growing and the mature ransomware operations. Require the cyber threat intelligence (CTI) function to keep CISOs apprised of the ransomware threat. Through established relationships, CISOs should gather information about experiences from peer organizations who have previously been compromised.

Prepare and rehearse. Use all available information to prepare for a ransomware incident. This will allow CISOs to make better, cooler-headed decisions under pressure. They will be less inclined to treat negotiations as an improvised crisis situation and more as a scenario they have planned for and rehearsed, as assisted by threat intelligence.

In classic action moves like “Dog Day Afternoon,” “The Taking of Pelham One Two Three” and “Captain Phillips,” both victims and authorities spend considerable time analyzing their opponents. In modern ransomware incidents, CISOs and other leaders need to take a similar approach to understand how a broad criminal ecosystem, corporate-level structure, multi-extortion techniques, data audits, cyber insurance assessments and deadline manipulation come together to make for a more formidable opponent.

With this understanding, security teams gain insight into how they can more effectively conduct negotiations in real time. As a result, they will ensure their organizations survive these incidents with minimal operational damage and financial losses while discouraging cybercriminals from future attack attempts.

The post How ransomware syndicates weaponize corporate-style organization 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.