NATO’s cyber defense arm and a startup that uses artificial intelligence to find software flaws can now issue the ID numbers the industry uses to track those flaws, the European Union Agency for Cybersecurity announced last week. 

The NATO Cyber Security Centre, part of the NATO Communications and Information Agency, and AISLE, a cybersecurity company with offices in San Francisco and Prague, joined as CVE numbering authorities under the ENISA Root. The CVE program assigns a unique record to each publicly disclosed security flaw so that governments, vendors and researchers have a common marker when referring to particular vulnerabilities. 

Twenty numbering authorities now sit under the ENISA Root, with 12 brought in by ENISA itself and eight moving over from the MITRE Root, run by the U.S. nonprofit that has handled the program’s daily work for more than 20 years.

Hans de Vries, ENISA’s chief cybersecurity and operations officer, linked the growth to changes in how people find flaws. 

“Recent developments in the global cybersecurity landscape, coupled with the emergence of Frontier AI models and their impact on vulnerability discovery and exploitation, have underscored the need to build strong vulnerability management infrastructure and capabilities,” he said in a statement. He said ENISA’s role helps build a “more globally representative, resilient, and scalable vulnerability identification ecosystem.”

The two new members show how bespoke each member is within its authority. The NATO Cyber Security Centre can now assign CVE IDs to eligible flaws across the NATO enterprise. The agency said that will make tracking more consistent and let the alliance share information with trusted partners sooner. The center guards NATO’s networks, watches for threats and coordinates the response when incidents hit.

Meanwhile, AISLE’s authorization is narrower. The company said in a July press release that the designation covers vulnerabilities discovered in its own products, allowing it to publish identifiers without waiting for a third-party authority to process a request. 

Jaya Baloo, the company’s co-founder, described the step as “foundational” and said coordinated disclosure “starts with holding your own products to the same standard you expect of everyone else.” Separately from the designation, the company said its researchers have disclosed hundreds of vulnerabilities in widely used open-source software, including OpenSSL, Linux, Apache and OpenEMR, each coordinated through the relevant authority for that project.

The changes come as the CVE process continues to involve amid program upheaval and the torrent of vulnerabilities discovered by AI systems. 

The CVE program, run by CISA, narrowly escaped a sudden demise when a last-minute, 11-month contract extension averted a shutdown in April 2025. Since then, several competing databases from European nonprofits and other private entities have been stood up in order to better coordinate how vulnerabilities are tracked, disclosed, and ultimately patched.

Earlier this year, The Computer Incident Response Center Luxembourg (CIRCL) launched the Global CVE Allocation System, or GCVE, as an alternative to the CVE program.

The post NATO and an AI startup can now name and track software vulnerabilities appeared first on CyberScoop.

A 20-year-old man in the United Kingdom was sentenced to two years in prison Monday after admitting to running an online abuse campaign that affected 117 victims across multiple countries during his time in the loosely organized online criminal network known as The Com.

Justin Swaddle, who was a minor when committed the crimes, pleaded guilty last month to a series of child sexual abuse offenses and blackmail. He was sentenced Monday at the same court and will be required to register as a sex offender.

The National Crime Agency, the U.K.’s lead law enforcement agency, had been investigating Swaddle since January 2024 after local police arrested him in October 2023 on charges of possessing, making and distributing indecent images. Investigators eventually found a broad online presence on Snapchat, Telegram and Discord, where he operated under usernames including “Epstein,” “Rugen” and “Moscow.”

A search of his phone and computer also turned up hundreds of sexually explicit conversations with young females, according to the NCA. Investigators determined Swaddle was part of The Com, a sprawling cybercriminal network of minors and young adults who engage in violence, extortion, sextortion and various forms of cybercrime. 

The NCA identified 117 female victims worldwide between the ages of 13 and 17, eight of them in the United Kingdom. One victim, 17, told investigators she met Swaddle on Discord in November 2022 before their conversations moved to Snapchat. She said Swaddle obtained her name, address and school details, then used that information to pressure her into various acts, threatening to expose her personal information unless she provided further images and videos.

“Justin Swaddle targeted young and vulnerable victims all over the world to abuse and scare them into carrying out shocking self-harm and sexual activity, purely to gain popularity with his peers online,” Danielle Pownall, an operations manager from the NCA, said in a release. “While the number of people involved in Com groups are relatively small, the impact it has on victims is high and long-lasting, as Swaddle’s offending shows.”

Law enforcement in both the U.K. and United States has been extremely active over the past few months in bringing Com-affiliated members to justice. Last week, a Canadian man who was linked with the group pleaded guilty for the widespread compromise of more than 165 Snowflake customer environments. Last month, a pair of young men tied to the Com were sentenced in the U.K. to 66 months in jail for committing a cyberattack on the Transport for London in 2024. 

The post UK man tied to The Com sentenced for abusing 117 victims appeared first on CyberScoop.

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.

The U.S. Coast Guard said it is monitoring the aftermath of a cyberattack that disrupted gate operations at all three of North Carolina’s port facilities this week, though it offered few details as the investigation into the breach continues.

A Coast Guard spokesperson told CyberScoop that the branch’s IT unit was coordinating with partner agencies while conducting the investigation. A spokesperson for CISA did not respond to CyberScoop’s inquiry by press time. 

The Coast Guard is one of several state and federal partners the North Carolina State Ports Authority brought in after discovering the attack on its systems earlier this week. The breach affected the Port of Wilmington, the Port of Morehead City and the Charlotte Inland Port, forcing the agency to delay gate openings and shift to manual processing while it worked to contain the intrusion.

A spokesperson for the ports authority told local media its IT team activated the agency’s cybersecurity contingency plan upon discovering the attack, as well as reaching out to state authorities for further support. 

As of Friday morning, a notice on the ports website said a normal operating schedule was in effect while the IT teams continued their investigation. It has not disclosed the nature of the attack, which systems were affected, or whether vessel operations, cargo-handling equipment or rail services were disrupted.

North Carolina’s ports serve as a trade hub along the southeastern U.S., with Wilmington in particular functioning as a gateway for agricultural exports, retail goods and raw materials.

The North Carolina Ports Authority said it would continue posting updates on its website and pointed users toward its email alert service for further information. It did not provide an estimate of how much truck or cargo traffic has been affected by the disruption.

The incident adds to a recent string of cyberattacks against water and wastewater systems in the U.S., which also fall under the umbrella of “critical infrastructure.” While there has been no official attribution, experts have expressed confidence that Iranian actors are responsible for the attacks on water systems.

As of Friday morning, there has been no public information tying the port cyberattack to a specific actor.  

The post Coast Guard says it is monitoring cyberattack that disrupted North Carolina’s ports appeared first on CyberScoop.

A new scan of internet-connected industrial equipment found over 4,000 Rockwell Automation and Allen-Bradley controllers exposed online, including 22 in cities impacted by cyberattacks on U.S. water systems.

The findings, published Wednesday by Forescout’s Vedere Labs, show that direct internet access to equipment used in water and wastewater operations remains common despite years of warnings from manufacturers and federal agencies.

The exposed devices use EtherNet/IP, an industrial protocol that allows for communication between control equipment, engineering workstations and other systems. When the port is open to the public internet, outside users may be able to identify devices and, depending on their setup, change settings or write new configurations.

The scan, run through the Shodan search engine Monday, found that 2,844 of the exposed controllers (65%) were in the United States.

The FBI and Environmental Protection Agency issued a joint advisory last week confirming attacks at water and wastewater utilities in at least 12 states since July 27. Officials have since named Michigan, South Dakota and Georgia among the affected states. Nine systems were hit in Michigan, and one wastewater lift station was hit in South Dakota.

Several reports have linked the attacks to Iranian actors, but Sai Molige, senior manager of threat hunting at Forescout, says the company has not attributed this activity to any actor or group.  

“The evidence supports opportunistic, at-scale exploitation of a known class of vulnerabilities affecting internet-exposed devices,” Molige told CyberScoop. “The scale and speed of the activity are more consistent with mass scanning and enumeration than with zero-day exploitation, a months-long intrusion campaign, or custom malware.”

The advisory said attackers targeted programmable logic controllers (PLCs) made by Rockwell Automation under its Allen-Bradley brand, specifically the MicroLogix 1100 and 1400 models. In at least one case, attackers reached controllers remotely and changed their IP addresses and passwords, cutting off the utility’s own view and control of the equipment. The advisory said the attacks caused pressure loss and flooding.

Forescout’s research states that the most common exposed device family was the MicroLogix 1400, which made up half of the devices found. Other versions, such as AllenBradley’s CompactLogix 1769 controllers, made up 22%. MicroLogix 1100 and ControlLogix 5590 devices each accounted for about 8%.

Forescout cross-referenced those machines against the recently targeted cities and municipalities and found 22 devices still exposed to the internet. However, the company did not say those systems had been attacked or that they belonged to the affected utilities.

The research also found that 19 of the 22 hosts in affected cities appeared, based on firmware versions, to be open to CVE-2017-16740, a remote code execution flaw disclosed in 2017 that impacts MicroLogix 1400 devices. An attacker would need Modbus TCP enabled to use that flaw, and the researchers could not confirm whether the affected systems had it enabled.

Rockwell Automation and other industrial equipment makers have warned customers not to place controllers directly on the public internet as far back as 2018.

Beyond the controllers, the researchers also looked at the digital records tied to these utilities. They found expired certificates, remote-access web addresses left unrenewed for months or years, and servers that appear abandoned — in one case, a server that has shown nothing but a default Microsoft webpage since April 2019. 

“These stale services can increase the attack surface; however, we have not yet confirmed how the observed attacks occurred,” Molige told CyberScoop.

The post Despite federal warnings, thousands of U.S. industrial controllers used in water systems remain exposed online 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.

The post Tom Cotton prods Treasury for tax code tweaks to modernize OT 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.

The post Public interest coalition urges Congress to investigate OpenAI, Hugging Face hack 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.

Anthropic said it found three instances in which its models gained access to the live computer systems of outside organizations, according to a company blog post published Thursday.

The company said it began the review after OpenAI disclosed earlier this month that some of its models had exploited an unknown software flaw to escape an isolated test setup and reach production systems at Hugging Face, a platform for AI models and datasets. Anthropic checked over 141,000 evaluation runs for signs that Claude had reached the internet from environments meant to be closed off. It found six runs across three incidents, all tied to one outside testing partner, Irregular.

“Ultimately, many factors contributed to these incidents, but, consistent with a blameless postmortem culture, we’re approaching the fixes as if the responsibility were ours alone,” the blog post reads. “This begins with ensuring every part of our evaluation pipeline is secure, including the manner in which we integrate with external partners. Moving forward, it will include expanding our continuous monitoring of evaluation transcripts for unexpected behavior, improving our investigation tooling, and conducting more rigorous assurance work with the vendors we rely on.”

In each case, Claude was working on a “capture the flag” puzzle, a common way to test a model’s hacking skill. The model is told a piece of secret data sits on another machine and must be found. Anthropic‘s prompts told Claude it had no internet access. That was false. A setup error at the partner’s end left the machines connected to the open internet, and Claude found real systems while searching for its target.

Believing the real systems were part of the simulation, Claude broke into them using simple methods such as guessing weak passwords and finding unprotected access points. In the most serious case, the model extracted login credentials and reached a database holding several hundred rows of live data. 

In a second case, Claude built and uploaded a malicious software package to PyPI, a public directory for Python code, after noticing a fake company’s setup guide told new hires to install a package that did not exist. The package stayed online for about an hour and was installed on 15 systems, including one belonging to a security firm whose scanner ran the code and had its credentials stolen. 

In the third case, Claude scanned about 9,000 targets before breaking into one company’s application through exposed credentials and a database attack method known as SQL injection.

The three incidents involved different Claude models: Opus 4.7, Mythos 5, and an unreleased internal test model. Anthropic said the models behaved differently once they encountered signs their targets were real. Opus 4.7 recognized the systems were live but kept attacking anyway. Mythos 5 also noticed signs it was on the open internet but talked itself out of that conclusion, pointing to a system date reading 2026 as proof it remained in a simulation. The internal test model, the newest of the three, stopped once it concluded the target was real.

Anthropic said it began its transcript review last week, halted all cybersecurity evaluations, identified the three incidents, and notified the partner and affected organizations earlier this week. Two of the three organizations had not detected the intrusions before being contacted, the company said; outreach to the third was ongoing. 

Anthropic framed the incident as a failure of its testing setup and oversight rather than a case of a model acting on its own, noting that in each instance the model was operating as intended. 

The company said it is working with the outside evaluator METR on an independent review and plans to release a redacted transcript of the PyPI incident within a week. It also said it would tighten monitoring of test environments run by outside partners and expand review of evaluation logs, framing the changes as part of what it called a blameless review of its own processes.

“These facts give us cautious optimism that with tighter monitoring and controls around evaluation infrastructure, as well as continued investment in alignment, this type of risk can be overcome,” the blog post reads. 

The post Anthropic says its AI accidentally hacked three companies during safety tests appeared first on CyberScoop.

Okta announced Thursday it has signed a deal to buy Permiso Security, a cloud-based firm that tracks threats tied to human, machine, and AI-driven digital identities. 

Permiso specializes in spotting risks after a user or system has already logged in, an area the industry refers to as identity threat detection and response. The company draws on more than 2,500 signals gathered from over 70 identity-related partners to flag issues such as excessive access permissions, unused credentials, unusual behavior from AI agents, and violations of internal security policies.

Ely Kahn, Okta’s chief product officer, told CyberScoop that Permiso will allow Okta to merge two functions that have operated separately: real-time threat detection and identity security posture management. “Today those are two separate products that don’t really talk to each other,” he said. 

Combining them, Kahn said, produces sharper alerts for security teams. As an example, he described a hypothetical scenario where a dormant administrator account is flagged by posture-management tools that later shows a login from an unfamiliar IP address. “By combining those things, you now have a very high-confidence, high-fidelity alert that’s more actionable by a security operations team,” Kahn said. “A security operations team on its own might not care about the dormant account, but when you combine that with some threat signals, then it becomes a higher critical-level alert.”

A crucial part of the deal, according to Kahn, is that Permiso will bring visibility beyond Okta’s current threat detection products, telling CyberScoop that customers also rely on other identity systems, such as Microsoft Entra ID or Active Directory, that fall outside that view.

“For us to be a real player in the identity security space, we have to look beyond the Okta perspective and give folks a full view into their identity threats,” he said.

The acquisition also fits into a security landscape reshaped by artificial intelligence. According to figures cited by Okta, 58% of executives say their organizations experienced an AI-related security incident or a near miss within the past year. That trend has pushed identity companies like Okta to expand beyond authentication and into continuous monitoring of what accounts, including AI agents, actually do once inside a system.

“Agents will be breached,” Kahn said. “The most important thing you can do is ensure that if an agent is compromised, the blast radius is small,” through a narrowly defined, revocable identity tied to each agent. 

Among the capabilities Okta says it will gain is a tool called SandyClaw, which tests AI agent skills and prompts in an isolated environment before they are allowed into a customer’s systems, aiming to catch supply-chain attacks embedded in AI tools. Other planned additions include expanded tracking of AI agent behavior across cloud platforms and software-as-a-service tools, and automated systems to investigate and isolate AI agents that appear compromised or misconfigured.

The transaction is expected to close in the third quarter of Okta’s 2027 fiscal year, pending standard regulatory and closing conditions. Terms of the acquisition, including its purchase price, were not disclosed.

The post Okta’s deal for Permiso aims to close gaps in identity threat detection 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.

Amazon’s security researchers say a hacking group tied to North Korea targeted small, little-noticed software packages more than a year before it struck one of the internet’s most widely used programming tools.

The company’s threat intelligence team said Wednesday at a media roundtable at its Arlington, Va., offices that the same group linked to the recent compromise of the open-source axios software library also planted malicious code in a package called typo-crypto in March 2025, a full year before the axios breach. Researchers found the connection while tracing domain records tied to the axios attack back to earlier activity.

“We believe the March 2025 typo-crypto campaign was a rehearsal,” said CJ Moses, Amazon’s chief information security officer, adding that the target’s small scale let the group test its methods “without putting that on the big stage.”

Amazon said the group also compromised two other packages, debug and chalk, in September 2025. Until now, those three incidents had not been publicly linked to the same actor. Security researchers track the group under several names, including UNC1069, Sapphire Sleet and Stardust Chollima. 

Axios, debug and chalk are code libraries used by software developers around the world to build applications. Axios alone is downloaded more than 100 million times a week. “That number represents real organizations putting real code into production systems every single week,” Moses said.

In the typo-crypto case, the malicious file was named “core.js” and was made to look like a legitimate, unrelated package called core-js. Amazon said the file activated only when it received a specific numeric input, then reached out to a server controlled by the attackers to download a second piece of code. That second stage was written differently depending on whether the infected computer ran Windows, macOS or Linux. The code combined encoded text with a cipher, a method Moses said was meant to slow down analysis, including by AI-based review tools, without relying on heavy encryption.

Amazon said the typo-crypto package had few downloads compared with axios, debug or chalk. Researchers believe that initial target served as practice, letting the group refine its approach before turning to more widely used software. “They did what a lot of people do: crawl, walk, run,” Moses said. 

In each of the four cases, Amazon said, the attackers built a relationship with a maintainer who already had access to a package, then used that access to publish an update containing hidden code. “They didn’t break through a window,” Moses said. “They basically earned the trust of an employee to hand them the keys.”

Cybersecurity firm Wiz separately found that about 1 in 10 cloud computing environments were affected by the debug and chalk incident within a two-hour span, a finding Moses cited to illustrate how fast the impact spread. “Going from there not being a vulnerability, to there being a vulnerability, to there being an exploited vulnerability … used to be days to weeks. Now it’s hours to minutes,” he said.

Rick Anthony, senior engineering manager at Amazon Web Services, said the research further shows how attackers face two basic problems in these types of incidents: getting malicious code into a package that will eventually run inside an organization, and keeping that code hidden from developers or security tools. He said groups are increasingly building reputations as legitimate contributors over time. 

“Let me get my package deployed in as many places as possible so that I can spring the trap later,” said Anthony, describing the mindset behind the approach.

Researchers said generative AI has made it easier for attackers to produce code, documentation and contribution histories that look authentic. Anthony also described a technique in which attackers register package names that AI coding tools sometimes generate by mistake, so a developer following an AI suggestion could install malicious software without making any typing error of their own.

The findings come two years after a separate incident involving a program called xz-utils, in which an attacker spent time gaining the trust of the software’s maintainers before inserting a backdoor. Moses pointed to that case as an early example of a pattern now appearing “at scale” and tied to a nation-state.

Since that incident, separate groups have been running roughshod over open-source software. Another group known as TeamPCP has compromised and injected malicious code into more than 1,000 software packages over a four-month span this year. 

The post A little-known npm package was North Korea’s warm-up act for the axios hack 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.

Anthropic researchers used Claude Mythos Preview to find new weaknesses in two cryptographic methods, the company said Tuesday, including one that is being considered by the National Institute of Standards and Technology for both traditional and quantum computing.  

In a blog post detailing the work, the frontier AI company called it a “substantial” research advancement, but also emphasized that neither flaw affects software now in use.

“The attacks described in these two papers are the strongest attacks we have found to date,” the company wrote in the post. 

One of the weaknesses found was in HAWK, a digital signature scheme under review by the NIST as part of a search for encryption methods that could survive attacks from quantum computers. Working with a human researcher, the AI system found a mathematical shortcut, known as a nontrivial automorphism, in the lattice structure (a complex mathematical grid underpinning its security) HAWK relies on.

The discovered weakness cuts HAWK’s effective key strength in half, meaning key sizes would need to double to keep the same level of security. Anthropic said that change would erase much of what made HAWK an appealing candidate in the first place.

Ellen Boehm, senior vice president of strategy and AI innovation at Keyfactor, a digital identity and cryptography management provider, told CyberScoop that research like Anthropic’s proves that the NIST PQC evaluation process is working. 

She also said the research “elevates the importance for organizations to have visibility of where cryptography sits inside their enterprise, what business systems and processes it’s connected to, and the need for PQC readiness, if they haven’t already built a plan.” 

The other flaw was found in a weakened version of the Advanced Encryption Standard, or AES, the cipher NIST adopted in 2001 and the most widely used method for scrambling data in transit. Working largely on its own, Mythos invented a mathematical shortcut dubbed the “Möbius Bridge.” While real-world encryption scrambles data through 10 sequential layers, or “rounds,” researchers regularly study a simplified seven-round test version to measure security margins. In previous theoretical attacks, codebreakers had to check 256 separate values against a memory table, but Mythos created a shortcut that eliminated that lookup process entirely.

Combined with other optimizations, this discovery made the strongest known theoretical attack against seven-round AES 200 to 800 times faster. The attack is purely theoretical: It requires an impossible amount of target data — over 400 octillion messages — and cannot touch the full 10-round encryption protecting everyday software. Additionally, Anthropic pointed out that real-world systems remain completely safe.

Anthropic said it followed standard disclosure practices, notifying HAWK’s designers in June and coordinating public release with a NIST mailing list, and briefing government and industry partners beforehand. It also worked with researchers at ETH Zurich, Tel Aviv University and the University of Haifa to build a shared testing tool, called CryptanalysisBench, meant to let other researchers measure how AI systems perform against a range of ciphers.

The findings come as frontier AI models are being deployed by cybersecurity researchers in order to find vulnerabilities in all kinds of software. In June, intelligence agencies in the Five Eyes alliance warned that advanced AI models capable of wreaking havoc in the cyber domain are “months away.” However, a recent report found that despite the avalanche of bugs being unearthed, the threat level across the internet has not materially changed. 

Anthropic said it expects the same AI capabilities eventually to be applied to systems already in wide use, raising a separate question it said it has not yet resolved: how researchers, companies and governments should respond if a language model uncovers a flaw in a cryptographic system that protects critical infrastructure.

“As we develop increasingly powerful cryptanalytic results, it would be prudent to consider how researchers should react if a language model were to discover vulnerabilities in cryptosystems where attacks do have an immediate real-world impact,” the company wrote. “We hope that our work here will help launch these conversations.” 

Boehm said work like Anthropic’s further shows that enterprises should not rest on their laurels with any facet of their security apparatus. 

“AI is becoming a powerful tool for many things, including software quality assurance, code development, and in this case cryptographic analysis,” she told CyberScoop. “As AI tools become more widely and continuously used, it just elevates the need for enterprises to treat their trust infrastructure in an ongoing, operational manner versus thinking of it as a static environment that only changes every few years as new cryptographic algorithms are released.”

The post Here’s what Anthropic found when it turned Mythos loose on encryption algorithms appeared first on CyberScoop.

The post Coordinated cyberattack disrupts water utilities in 30+ Minnesota communities appeared first on CyberScoop.

The post FBI sees Anthropic’s Mythos as a law enforcement challenge appeared first on CyberScoop.

Microsoft threw its hat into the ring Monday in the increasingly heated competition among AI-powered cybersecurity offerings, unveiling tools that it claims are better and cheaper than its rivals.

The new agentic model MAI-Cyber-1-Flash, runs inside another Microsoft security tool, MDASH, and is part of an AI-powered security platform the company dubbed Project Perception.

Microsoft argues that its existing in-house capabilities give Project Perception an edge.

“Project Perception brings together signals, context, models and specialized agents into a continuously learning system of defense,” the company said in a blog post. “It can reason, prioritize and act at machine speed while keeping humans firmly in control and empowering them with powerful new workflows.”

Its release follows splashy AI cybersecurity suite debuts from OpenAI and Anthropic. Companies have been racing to advertise their AI offerings for their ability to find vulnerabilities, even as the most dire warnings about AI being used on the offensive side have yet to come to fruition.

As proof of its superiority, Microsoft said that MDASH with MAI-Cyber-1-Flash beat Mythos, Gemini and GPT on CyberGym, “the gold standard benchmark for evaluating how systems reason over large codebases to find real vulnerabilities in the code.” It scored 96%, 12 percentage points ahead of the next-best.

Microsoft said MAI-Cyber-1-Flash was built with a focus on safety first, and was independently assessed by a third party it didn’t name. AI cybersecurity systems made big news in the past week after OpenAI said its models broke free of its testing confinement to hack Hugging Face, a major AI code platform. 

Price also was a big part of Microsoft’s rollout: It said MAI-Cyber-1-Flash in MDASH can do the job at half the cost of other leading models.

“This is the benefit of building the harness, context/signals, and action space separate from one model family,” Microsoft Chairman and CEO Satya Nadella said on social media after the company unveiled Project Perception in San Francisco Monday. “By combining specialized models and data with the right agents, tools, security context, and harness, we can advance the frontier of cost to outcome.”

Project Perception enters public preview on Aug. 3, Microsoft said.

The post Microsoft debuts AI cybersecurity offerings as competition heats up appeared first on CyberScoop.

The Trump administration asked the Supreme Court on Monday to let it enforce an executive order that would restrict mail-in voting, after a federal appeals court kept the order blocked in nearly half the states just months before the November midterm elections.

Solicitor General D. John Sauer told the justices that a Massachusetts federal judge acted too soon when she struck down key parts of the order, which blocked federal agencies from carrying it out in 23 states and the District of Columbia. Sauer said the order only directs agencies to study changes and has not yet produced a final rule, so no state has suffered harm. 

“The district court preemptively decided that whatever the agencies may choose to do will necessarily be unlawful,” he wrote. He asked the court to pause the injunction while the case moves through the appeals court, and to grant an immediate stay in the meantime.

President Donald Trump signed an order in March that directs the Department of Homeland Security to compile lists of confirmed U.S. citizens in each state and send them to election officials, along with directing the U.S. Postal Service to draft rules on mail-in and absentee ballots. California and 22 other Democratic-led states sued three days after Trump signed the order, arguing the Constitution gives states and Congress, not the president, power over elections.

U.S. District Judge Indira Talwani ruled in June that the administration lacked power to build its own citizen-voter database and that the Postal Service could not impose new rules on states’ mail ballots by itself. She also found the order’s enforcement language amounted to an improper threat against local election officials. 

In Monday’s filing, the administration leaned on a 2020 case, Trump v. New York, in which the justices threw out a challenge to a separate Trump order on census counts because it was too soon to know how agencies would carry it out. Sauer argued the same logic applies here. The order tells agencies to act only “to the extent feasible and consistent with applicable law.” That wording, he said, means the Postal Service and Homeland Security could still drop or narrow the changes once they finish reviewing public comments and checking what the law allows.

The filing follows a string of fights over how the 2026 midterms will run. Earlier this month, Trump gave a prime-time address reviving his claim that the 2020 election was rigged, this time pointing to China, without providing any new evidence.

The filing also follows a Supreme Court ruling in late June that let states keep counting mail ballots that arrive after Election Day if postmarked on time. 

You can read the full filing below. 

The post Trump asks Supreme Court to let him curtail mail-in voting ahead of midterms appeared first on CyberScoop.