OpenAI has unveiled a much anticipated AI model which the firm has dubbed ‘GPT-6 Astra’. While the model has improved significantly across benchmark testing and brings a host of new business features, there is still a dark cloud looming over the new model.

Off the back of OpenAI’s accidental hack of Hugging Face and the company’s subsequent efforts to improve how AI agents behave and interact, numerous cybersecurity experts have raised concerns about the model’s new ‘recurrent depth’ reasoning capabilities.

This new reasoning architecture allows the model to consider a problem multiple times before taking an action, compared to the standard chain-of-thought reasoning used in previous models.

Why the concern about recurrent depth reasoning?

This new level of reasoning apparently offers improved performance. OpenAI also says it has fixed its models' abilities to circumvent boundaries when performing tests by monitoring the models reasoning and ensuring the model stays aligned within the scope of its task.

During Astra’s launch event, OpenAI chief scientist Jakub Pachocki said: “We will not accept degradation in our ability to monitor model alignment beyond a certain level. We will withhold scaling until we can regain enough confidence.”

But numerous experts believe that the lessons of the Hugging Face incident have not yet been learned, and the model has been released without adequate testing on Astra’s reasoning and monitoring.

After all, no one thought one of OpenAI’s models could set up a hidden internet-connected messaging board that allowed AI agents to influence each other's behavior.

But with Astra being released into the real world, the lessons may have to be learned on the fly.

Expert perspectives on OpenAI Astra release

• James Blake, VP of Global Cyber Resiliency Strategy at Cohesity:

The launch of Astra is raising questions again around the safety of Frontier AI. Instead of simply asking whether a model is "safe", organisations now need to ask whether it remains safe across millions of different situations, prompts and interactions. Cyber resilience has traditionally assumed that systems and threat actors behave deterministically. AI systems don’t.

Advanced models can and will continue to exhibit behaviours that emerge from their optimisation process rather than from explicit programming. We have to move beyond thinking about AI as just another software tool and find ways to ensure these systems remain observable, auditable and governable throughout their lifecycle.

The most important question we’ll need to answer in future is one of liability. Suppose an AI system autonomously develops a strategy that causes financial loss, leaks confidential information or violates regulation. Who is responsible? The developer that trained the model? The cloud provider operating the infrastructure? Currently the answer is surprisingly unclear. It’s not just about what AI can do: it’s about who is accountable when it does something nobody expected.

• Oleksandr Yaremchuk, Co-Founder & CTO at Manifold Security:

OpenAI is calling Astra its most aligned model yet, even as its chief scientist admits monitorability is getting harder as models get more capable. Evidently, Astra hides its reasoning in the majority of tested cases, and some successful attacks left no reasoning trace at all. That's the tool many organisations still use, including the labs themselves, for auditing what an agent is doing, and it's getting less reliable with every release.

That matters because Astra isn't staying inside OpenAI's test environment. It's going to run as an agent on employee laptops and in the browser, holding real credentials, inside companies that have no way to watch what it does once it's there. A model that explains itself less isn't more aligned, it's just harder to catch when it goes wrong.

Labs can keep debating what these models say or refuse to say. Security teams need to stop relying on that and start monitoring what agents actually do at runtime, with the ability to shut one down mid-action. That's the only oversight left that still works once the reasoning goes quiet.

• Kristin Lowery, Field CISO at Optiv:

For boards and executive leaders, the emergence of OpenAI’s Astra model highlights a broader reality: AI is no longer just a productivity issue; it is a risk management issue.

Just as organizations established governance for cloud adoption and digital transformation, they now need clear policies, strong oversight, and accountability for AI use.

The question is not whether AI will become more capable — it will. The real challenge is whether organizations can strengthen their governance, security controls, and workforce readiness quickly enough to keep pace.

• Patricia Titus, Field CISO at Abnormal AI:

OpenAI crossing this threshold deserves attention. Credit where it's due, they're handling it responsibly by restricting Astra's advanced cyber capability to a small coalition rather than releasing it broadly.But this isn't one company's problem to contain.

Once a model can find and exploit unknown flaws without a human in the loop, that capability doesn't stay exclusive for long. Open-weight and modified models typically trail the frontier by only months, and that's the reality defenders have to plan around now.

Static, signature-based defences were built for attacks that repeat. They weren't built for an adversary that generates a new one every time. Defenders need the same shift, systems that learn what normal looks like for every identity, human, machine, or AI agent, and flag and contain the moment something deviates, at machine speed.

The window to build that is open now. It won't stay that way once this capability is common instead of rare.

• Raghu Nandakumara, VP of Industry Strategy at Illumio:

With the Astra announcement, OpenAI is doubling down on monitoring the model's own behaviour – a response to the model "breakouts" seen over the past few months.

When Anthropic announced Claude Mythos Preview, the core concern was the model falling into the wrong hands. OpenAI's answer goes further adding guardrails around the model's own reasoning and actions, regardless of the user's intent. The goal is to catch a model going rogue mid-task, not just stop it being misused at the outset.

The rest of this announcement can be summarised as ‘we have a new frontier model, and it’s more capable than the last one’.

• Google released Chrome 152.0.7977.82/.83 for Windows, Mac, and Linux
• Patch fixes 12 flaws, including zero‑day CVE‑2026‑85046 (type confusion in V8)
• Sixth Chrome zero‑day this year; Chromium browsers also affected, update urged immediately

Google has released a new version of its Chrome browser for Windows, Mac, and Linux, fixing a dozen of vulnerabilities. Among them is a high-severity flaw that is being actively exploited in the wild.

In a security advisory published on the Google blog on September 3, the search engine company said Chrome’s newest version is now 152.0.7977.82/.83 for Windows and Mac, and 152.0.7977.82 for Linux.

Rollout is expected to be gradual, so make sure to check if you already received it. Most of the time the update is automatic and instant and if you’re not certain, tap the three vertical dots in the top-right corner of the browser and choose Help. Navigate to About Google Chrome and there you will find the version number.

Running malicious code remotely

This patch fixes a total of 12 vulnerabilities, most of which are graded as high severity. Among them is a “type confusion in V8” bug, discovered by security researcher Salvatore Gulizia.

For his effort, Gulizia was awarded $1,000. Apparently, this bug is being actively leveraged in real-life attacks, although Google (as usual) decided not to share the juicy details until the majority of browsers are protected.

The vulnerability is tracked as CVE-2026-85046. On the National Vulnerability Database (NVD), it is described as a “type confusion in V8 in Google Chrome [that allows] a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page.”

V8 is Chrome’s JavaScript engine which allows web apps and interactive websites to run in the browser. Those interested in the technical breakdown of the vulnerability can find it on Guzlia’s blog.

You can find the full list of fixed vulnerabilities on this link.

This is the sixth zero-day Google fixed in Chrome since the start of the year. It also affects other browsers built on Chromium, so if you’re running Edge, Brave, Opera, or Vivaldi, make sure to update to the latest version as soon as possible.

Via The Hacker News

• OpenAI rolled out GPT‑6 Astra, its most advanced AI, with “critical” cyber capabilities
• Astra can autonomously find and exploit unknown flaws; release limited to vetted Daybreak participants
• Staggered rollout sparked user frustration; Altman apologized, promising broader access soon

OpenAI has begun rolling out GPT-6 Astra, its latest and most capable artificial intelligence model.

In an announcement published on its website, OpenAI said Astra represents a “significant step up in cyber capabilities”, meeting the company’s “Critical” threshold.

This threshold, the company explained, means that under the right circumstances, the tool can find “previously unknown security flaws and develop new ways to exploit them across many well-protected systems without a person guiding each step.”

Apologies for a messy rollout

OpenAI also said Astra improves on functions such as computer use, software engineering, and science, and that it should be better at staying oriented, compared to previous versions.

Just like many of the previous models, Astra’s release has been marred with controversy. Roughly a month ago, OpenAI said the model’s “critical” cybersecurity capabilities prompted it to pause some internal development and trigger safety protocols.

In response to early findings, the company scaled up certain security controls and even paused activities that do not meet its newly established security requirements.

It now decided it was time to release the model, but still not to the general public. Instead, it opted for a staggered release, giving it first to a limited group of companies participating in the Daybreak program, a cybersecurity initiative that gives vetted organizations (cybersecurity and otherwise) specialized AI tools for vulnerability research and threat detection.

This did not sit well with many ChatGPT users, especially those paying a monthly subscription. As The Verge reported, CEO Sam Altman was apologizing, mere hours after launch, for the “messy rollout” of Astra.

Initially, all Plus, Pro, Business, and Enterprise users were supposed to gain access to Astra, as well as those accessing through OpenAI API, Microsoft Azure, and AWS Bedrock.

“We are working towards getting Astra in everyone’s hands as quickly as we can,” Altman said on X. “I know it is frustrating and I appreciate the patience. It should be quick.”

Via CNBC

Following the aftermath of the Manchester Airports Group cyberattack - where hackers made off with the data of 8.7 million people - the hackers have now posted the entire database for sale on the dark web.

The group behind the attack, FulcrumSec, attempted to get Manchester Airports Group (MAG) to pay for the security of the database, promising that it wouldn’t be released if the company paid a settlement. But as all companies should do when faced with extortion, MAG didn’t play ball.

Now FulcrumSec wants to try and maximise the damage of the cyberattack, and has listed the database containing email addresses, phone numbers, vehicle registrations and postcodes online in the hopes a fellow hacking group will find value in the data.

What happens when extortion fails, and why didn’t MAG pay?

In the past, when companies faced ransomware attacks or data breaches, they would sometimes quietly pay the hackers for their silence.

Companies feared serious reputational harm and loss of business would cost more in the long run than the perpetrators were asking for. But this created an incentive for hackers to carry out more attacks.

After all, if companies aren’t kicking up a fuss about being hacked or reporting the attack to the authorities, hacking groups can launch more attacks on other companies that are completely unaware of their tactics.

In order to counter this, authorities and cyber experts from around the world issued guidance that under no circumstances should companies pay for the safe return of their data. By removing the incentive from ransomware attacks and data breaches, the hope is that hackers will get bored or not see enough ROI, and therefore stop.

But the 500GB database of data on over 8.7 million people is ripe pickings for other cybercriminals looking to launch highly specific phishing attacks or scam campaigns. While FulcrumSec may not make any money from the attack, they can seriously enhance the damage of the attack by offering the data for free for others to use.

A successful scam or phishing attack can steal banking and financial details, allowing other groups to steal even more money off the back of the attack.

Expert perspectives on MAG extortion and customer data

• Dray Agha, senior manager of security operations at Huntress:

While Manchester Airports Group followed official guidance by refusing to pay the ransom, the release of 8.7 million records creates an immediate risk for passengers.

We expect other criminals to use this freely available database of vehicle registrations, postcodes and contact details to craft highly convincing phishing attacks.

Anyone who has used parking, lounges or Wi-Fi at these airports must treat unexpected messages about their travel with extreme caution.

• Muhammad Yahya Patel, vCISO and cybersecurity advisor for EMEA at Huntress

The "free release" model is deliberately designed to maximise harm and reputational damage as a warning to the next target.

Publishing almost nine million records for free isn't just punishment for MAG it's a marketing campaign aimed at every other organisation watching.

Pay up, or your customers' data gets handed to every fraudster and scammer on the internet at no cost. Refusing to pay a ransom is the right call. But nearly nine million people are now paying a different price for a decision that was never theirs to make.

• Danny Jenkins, Co Founder & CEO at ThreatLocker

Unfortunately, once data is made public, it can’t be hidden again. The most important thing consumers can do is focus on basic cyber hygiene. Use a unique password for every website, learn how to identify phishing scams, and monitor your credit report.

Be highly suspicious of emails that create a sense of urgency, offer something that seems too good to be true, or ask you to reset your password.

When in doubt, look up the phone number for the alleged sender yourself, rather than using a number provided in the email, and call to confirm whether the communication is genuine.

• Brian Higgins, security specialist at Comparitech:

Whilst the airports breached in this attack don't appear to have had any financial data compromised the risk to affected or associated customers is very real. With so much other information freely available in the wild it is vital that airport users stay highly vigilant for some time to come.

Any and all unsolicited contact; whether online, by telephone or even home visit approaches, should be viewed as suspicious. Never engage until you've taken time to check credentials/veracity etc.

Research advice from trusted sources like the NCA or Information Commissioner and share it with your family and friends. Look for ways to increase digital and physical security like two factor authentication on Apps and devices or Smart Home tech.

When this breach was first reported by the Manchester Evening News the comments were quite telling. Affected parties were quick to identify potential vulnerabilities over and above the breach of financial and banking details.

Home addresses, vehicle registrations and time spent away from home all add up to some excellent opportunities for criminal exploitation, not to mention the usual follow-up phishing campaigns common in this type of incident.

As AI makes data aggregation swift and easy consumers are waking up to the fact that criminals can monetise successful breaches in increasingly inventive ways. It’s no longer enough for data owning organisations to advise post-attack vigilance and turn to their backups.

Victim communities rightly expect better protected networks and systems over and above established norms. As the marketplace grows less fearful and more angry when breaches are made public we may see more emphasis on cyber crime prevention which can only be a good thing.

• Denis Calderone, CTO at Suzu Labs:

The 8.7 million number is attention-grabbing, but it deserves some context. MAG has confirmed that the vast majority of those records are email addresses collected through airport WiFi sign-ups.

A much smaller subset includes phone numbers, vehicle registrations, and postcodes from customers who actually completed parking or lounge bookings.

No payment data, no passwords, no passport information. So despite this affecting airports, which is obviously a sensitive subject, the actual data sensitivity for most affected individuals is relatively low.

What's more interesting to us from a technical standpoint is the attack path. MAG told The Register that attackers compromised one of their internal systems and then went on to steal files from a database hosted by a third party. That's a pivot upstream into a data provider, not downstream into operational systems.

What remains unclear is whether the data was exfiltrated directly from that third-party environment or whether it was pulled back through MAG's network first. That distinction matters for understanding where detection controls failed and who was responsible for monitoring the egress.

The UK's Civil Aviation Authority has a Cyber Assessment Framework for Aviation, developed with the NCSC, that mandates strict separation between IT systems and operational technology.

We don't know whether MAG was formally operating under that framework at the time of this incident, but I would be very interested to find out. Because the segmentation appears to have held here. Flight operations, baggage handling, terminal systems, etc., all were unaffected.

The lateral movement went upstream toward a data provider, not downstream toward the systems that keep planes in the air.

• Seemant Sehgal, CEO and Founder at BreachLock:

This data was initially collected because passengers needed a login, and somewhere along the way, the sensitivity of what was accumulating in that database stopped getting the same scrutiny as the network itself.

Vehicle registration details, postcodes, and contact information across three major airports are a profiling dataset, and whoever held it for ransom understood its value better than the organization storing it did.

• Cisco patched eight IOS XR flaws, including three critical (CVE‑2026‑20274, CVE‑2026‑20279, CVE‑2026‑20212)
• Vulnerabilities allow unauthenticated exploitation, improper access control, and crafted input execution
• No abuse reported; patches urged, with iACL workarounds for Nexus 9000 devices using Silicon One ASIC

Cisco patched eight vulnerabilities affecting its IOS XR operating system, including three critical-severity ones. It urged its customers to apply the patches as soon as possible, even though it stressed that there is no evidence any of these were abused in the wild.

The company detailed its findings in two advisories published on the same day - September 2.

In the first one, it disclosed seven vulnerabilities, including two critical-severity ones: CVE-2026-20274 and CVE-2026-20279. Both carry a severity rating of 9.8/10 (critical). The former is an improper control of a resource during its lifetime flaw - a network-based, low complexity, vulnerability that requires no authentication or user interaction to be exploited. The latter is described as an improper access control vulnerability that can lead to the same consequences.

Fixes and mitigations

These flaws, along with five others, affect all releases of Cisco IOS XR Software, including Cisco IOS XR7 (LNT) Software, regardless of device configuration, the company explained. There are no available workarounds, and installing the provided patch is the only way to mitigate the risk.

The third flaw, disclosed in a separate advisory, is tracked as CVE-2026-20212. Successfully exploiting this one allows attackers to connect to an affected device and send crafted input that could be executed as code, without root privileges. “The exploitation of this vulnerability could also cause the S1HAL process to crash, which could cause the device to reload,” Cisco explained.

This bug affects Cisco Nexus 9000 Series Switches if they include a Silicon One ASIC, the company stressed. A possible workaround is to use infrastructure access control lists (iACLs) to allow only required management and control plane traffic that is destined to the affected device. There is also the option of iACLs only being used to explicitly deny all TCP packets that are destined to a locally configured IP address with a destination port of 43210 or 43211.

Via The Register

• OpenAI launched Daybreak for Frontline Defenders, offering $1B in credits for resource‑constrained security orgs
• Priority goes to essential services, governments, banks, nonprofits, and open‑source maintainers
• Initiative includes training, partnerships, and a water‑sector pilot with MS‑ISCA for local defenders

OpenAI is offering a billion dollars in credits to security organizations who want to use its Daybreak initiative but cannot afford it.

Daybreak is a cybersecurity program that provides vetted defenders with specialized AI tools and models. It was introduced in May this year, and later expanded into two tiers - Blue, and Red. Blue is the entry-level tier, providing a general-purpose model with custom-tailored safeguards. Red, on the other hand, offers a more purpose-trained cybersecurity model and almost no safeguards.

According to OpenAI, “thousands of defenders across 2,000 approved organizations and workspaces” already use Daybreak, including cybersecurity companies, defense organizations, and law enforcement agencies.

Who gets priority?

But these models cost money, and to make sure more businesses can access them, OpenAI announced, “Daybreak for Frontline Defenders”, a project where defenders can apply and receive credits for AI tokens. Even though the company announced it as a global initiative, it seems that US businesses will be the first to take advantage of it:

“OpenAI is committing $1 billion in subsidized Daybreak access to help resource-constrained cyber defenders, starting with the United States, put frontier AI to work, targeting it to be consumed over the next six months,” the company said in an announcement blog.

Businesses operating essential services such as water and wastewater systems, and electric grid operators, will get priority, OpenAI said. Then come state and local governments, community and regional banks, nonprofits, open-source maintainers, and then “other organizations with limited security resources.”

The subsidy is not just about using the models, though. OpenAI also said it will be increasing hands-on support for frontline defenders, training, and new partnerships.

On top of all that, OpenAI also announced a public sector, water-focused pilot with the Multi-State Information Sharing and Analysis Center (MS-ISCA) to train and support local, tribal, and territorial defenders.

“The pilot will pair Daybreak access with guided training and hands-on assistance for an initial group of public sector and water system defenders, helping them validate and prioritize findings, coordinate remediation, and develop a repeatable approach that can be expanded over time,” the announcement concluded.

• Microsoft warns of Teams‑based campaign where attackers impersonate IT staff
• Victims tricked into granting remote access, leading to malware, lateral movement, and ransomware
• Defenses: verify support contacts, train staff, harden Teams, and use Defender Safe Links/ZAP

Microsoft is warning about an ongoing hacking campaign that starts with a Teams message and ends with a ransomware infection and data theft.

In a new in-depth report published on the Microsoft blog, it was said that unnamed threat actors were reaching out to their targets at various enterprises via a Teams chat, while impersonating IT staff.

They were coercing their victims into granting remote access via screen sharing or remote monitoring and management tools and once received, used their access to install malware loaders and various other implants.

How to defend against Teams-borne phishing

The malware was just the first stage of the attack. Subsequent stages include host reconnaissance, security-product and virtualization discovery, and “periodic desktop screen capture”. In other words - mapping out the landscape and conducting espionage.

The crooks would then enumerate domain accounts, servers, and users, through native tools and Active Directory Service Interfaces (ADSI) queries and begin moving laterally.

The final step includes identifying and extracting valuable data, followed by a ransomware infection.

Microsoft does not name the perpetrators, and mostly refers to them as “threat actors”. It makes sense, since the “fake IT support via Teams” technique is being used by multiple groups at this moment. Russia’s Cozy Bear, FIN7, and Storm-1811 are probably the most obvious examples.

The world’s biggest extortionists - ShinyHunters - are also known to use Teams to trick victims into granting access, but this group rarely deploys an encryptor and instead just focuses on data exfiltration.

Whoever the attackers are, and whoever they’re after, one thing is for certain - the risk in the enterprise environment has never been greater.

That is why Microsoft advises reinforcing user education by establishing internal helpdesk authentication phrases, and by training employees to recognize external-tenant indicators.

The company also urges enterprises to verify unsolicited support contact, and to harden Microsoft Teams and email against social engineering. “Use Microsoft Defender for Office 365 with Safe Links and Zero-hour auto purge (ZAP) so malicious messages and URLs are neutralized at time of click and removed after delivery,” Microsoft urges.

• FBI warns of rising OAuth consent phishing attacks exploiting legitimate app permissions
• Victims tricked into granting malicious apps access, enabling email reading and sending
• Password changes don’t help; users must revoke tokens in app security settings

Hackers found a way to access your data, read your messages, and even send emails to your contacts, without ever needing your password or other login credentials. All they need from you is a single click on a completely legitimate, well-known platform.

The technique is called “OAuth consent phishing”. It’s been around for more than a year and it’s gotten popular to a point where even the FBI is taking note. Earlier this week, the law enforcement agency issued a new public service announcement, via its Internet Crime Complaint Center (IC3), warning Americans about the threat.

OAuth (Open Authorization) is an internet standard that allows users to give apps access to their account on another service, without giving the app their password for that service. For example, when users install a new app, they have the “Continue with Google” option. When they click it, they are asked if they allow the app to access their email. If they approve, Google gives that app a special access token, which allows the app to access the user’s Google account without ever seeing the password.

Pulling off an OAuth attack

So, to pull off an OAuth attack, the threat actor must first trick Google (or Microsoft, or any other company providing the service) and get their (malicious) app registered on the platform. Then they would reach out to their target via instant messaging, while impersonating government officials, media, and other publicly known personalities, and sharing a link to what appears to be a document.

The link redirects the victim to a legitimate service (for example, Google), where they are asked to grant permissions to the malicious app. If they approve, the attackers gain access to their email accounts with which they can do almost anything.

To make matters worse, simply changing the password does not fix the issue. The only way to eliminate the threat is to revoke the access token that was given, which can be done in the application security settings.

The FBI did not say who the threat actors were or who they were targeting, other than they were “prominent victims”. Their family members were being targeted, as well.

Via The Record

• Thomson Reuters confirmed March 2026 breach of its C‑Track court management system
• Incident affected courts in 11 US states, Ontario, and the US Virgin Islands
• No operational disruption; scope of exposed records still under investigation, no misuse reported yet

Thomson Reuters, the IT company behind the Reuters news agency, suffered a cyberattack a few months ago, exposing certain court documents to the attackers. In a brief announcement published earlier this week, it seems Thomson Reuters only noticed the intrusion now, months after it was already over.

Here is what happened: Thomson Reuters operates a court case-management system called C-Track. It is a tool used by different courts to manage things like cases, filings, hearings, and schedules. It is used by courts in several US states, the US Virgin Islands, as well as Ontario, Canada.

On June 30, 2026, Thomson Reuters detected unauthorized activity in one of its cloud environments, prompting an investigation which later determined that an unauthorized threat actor broke in and obtained some C-Track files. This happened in March 2026.

Investigation underway

So far, the incident is confirmed to have taken place across 11 US states (Alabama, Pennsylvania, Kentucky, Montana, Nevada, North Dakota, South Carolina, Tennessee, Ohio, New Hampshire, Wyoming), the U.S. Virgin Islands, and Ontario, Canada, exposing court records and personal information. Ontario's three Chief Justices confirmed it, as well, saying Thomson Reuters notified Ontario's Ministry of the Attorney General on July 23.

A more detailed investigation is currently underway, and all relevant authorities have been notified, it was said. At press time, Thomson Reuters did not yet determine exactly what information was accessed, or how many people were affected. The good news, however, is that there is currently no evidence of identity theft resulting from the incident, and there is no indication that systems handling court-related financial transactions were affected.

C-Track itself remains operational, as well. No threat actors have yet claimed responsibility for the attack or threatened to leak the files to the dark web.

"There has been no operational disruption to C-Track as a result of this incident," a Thomson Reuters spokesperson said. "Our products and services remain fully operational and are safe ​to continue to use. Independent ​cybersecurity experts assisted in ⁠the investigation and validated the remediation measures implemented."

• Microsoft is rolling out a new security feature for Windows 11
• Memory integrity provides stronger defenses for a crucial part of the operating system, and it's being automatically enabled
• Some gamers say the feature hampers gaming frame rates considerably, and they're not happy

Windows 11 is getting its security bolstered with a feature that's being automatically enabled, but which comes at a cost that some PC gamers don't want to pay — and this is proving quite the controversy on social media.

The Verge reports that Microsoft has announced that it's rolling out the enablement of memory integrity protection across eligible Windows 11 PCs, and that this is because "security works best when protection is built in, not bolted on".

Microsoft explains: "More devices will soon receive stronger protection by default, with no additional setup required. Windows quality updates will begin enabling memory integrity protection on eligible devices.

"If not already enabled, these updates will also enable VBS [Virtualization Based Security], helping make additional security capabilities available and reflecting our commitment to making Windows secure by design and secure by default."

The idea is to tighten security for Windows 11's kernel-mode drivers, a core aspect of the OS with direct access to the system's hardware, and there can be no argument that this additional protection gives host PCs tougher defenses and makes them more difficult to exploit. So why the controversy? Let's dive into the pros and cons of what's going on here.

Analysis: a divisive move — but we can't ignore that the threat landscape is changing

In Microsoft's view, this is a no-brainer: stronger security is being rolled out to Windows 11 devices, or at least those which are eligible (older PCs may not be). However, PCs configured via group policy not to use memory integrity, or machines where it's been disabled before, won't have the feature forced on them.

Other supported PCs will get memory integrity (and VBS, because it's required for memory integrity) turned on automatically by Windows 11, and this is where some gamers are up in arms. VBS has a long history of being a thorn in the side for gamers, with the feature being linked to frame rate losses.

How much of a headwind does this cause for PC games? Well, therein lies a big part of the issue, because it's difficult to pin that down exactly, and as ever, it's bound to vary depending on your PC's exact hardware and system configuration.

Some gamers observe frame rate hits of approaching 10%, while others say the impact isn't noticeable at all. There's a lot of back-and-forth on Reddit arguing about the extent of any slowdown, and here's a typical exchange:

One Redditor notes: "HVCI [memory integrity] is a great security feature, and the performance impact on newer platforms (to which this automatic switch will apply) is negligible."

Another replies: "It ain't negligible. 9800x3d, 5080, ddr5 6000 cl28 and my 1% lows get wrecked with this feature on. Way smoother disabled."

This isn't just about frames per second performance for some gamers, then, as there are also accusations of it affecting the lowest troughs (bottom 1%) that the frame rate hits (meaning the game suffers more stuttering at times and generally feels jerkier).

As the first comment points out, though, the likelihood should be that a more modern PC won't feel much of a hit (if anything). The gaming rigs that might see more of a spanner in the frame rate works are those which are older, but still modern enough to get the auto-enablement of memory integrity. In other words, a collection of PCs which are on the outer fringes of that compatibility limit (older machines, but not too old to avoid the feature rollout).

Of course, even those PC owners can always turn off memory integrity. The major beef for some is that they remember that Microsoft got into trouble for automatically switching on VBS in the past in a quiet, under-the-radar manner — and the question now will be whether gamers realize that this feature has been enabled alongside memory integrity.

In all honesty, when I saw what Microsoft was doing here and fired up Reddit to test the temperature of the reactions, I was expecting nothing short of a flamethrower being turned on the software giant. However, the feedback is split quite evenly between the haters — or those who disapprove at least — and users who are applauding Microsoft for this deployment.

Here are a couple of further examples from either side of the fence: "Apparently a controversial opinion, but systems that are for everyone should be failsafe, and that includes the most secure option being the default. There should be an option to disable security to get higher performance, but most secure should be the default."

Juxtaposed with this: "Already have memory integrity turned off as this 'feature' already hits gaming, I've used Windows without memory integrity for decades I think I'll be ok."

I must admit I'm inclined to agree with Microsoft's decision here — providing that when it happens, Windows 11 is clear on informing the user, so they can reverse the change if they aren't happy with it.

I think part of what Microsoft is doing here is keeping one eye on the future in terms of the difference AI might make to the security of Windows 11 PCs.

I keep hearing about how AI is already driving new threats and exploits, and so the kernel defenses that are being brought into play here may not have been quite as necessary in the past — as the last Reddit post I highlighted indicates — but they may be very much needed before too long. AI is accelerating the development of new threats considerably, and making it easier for anyone to becoming a peddler of malware, so Microsoft likely feels the pressure to act.

• 22% expect their policy to offer full coverage, 10% expect it to fall short
• Data breaches and reputational damage are major concerns
• Companies should look at finances before considering operational recovery readiness

New research from Cohesity has revealed that many UK businesses could be significantly overestimating the protection they get from cyber insurance policies, with just one in five (22%) British CEOs believing their policy would cover both the additional costs and lost revenue that an attack could lead to.

A third expect it would cover the additional costs only, another third believe their policy is only sufficient for lost revenue, and a further one in 10 did not expect it to cover either of the two categories.

The report's conclusion is that cyber insurance in its current state for many UK businesses is only enough to transfer some of the financial risk – but not enough to restore systems, data or operations.

Cyber insurance policies don't provide enough cover

According to the study of 100 CEOs from large enterprises, businesses expect a cyberattack to reduce their revenue by an average of around 15%, but many businesses lack a detailed understanding of how much an attack could actually end up costing them. As many as one in five (21%) haven't even conducted business impact modelling.

Among CEOs' biggest fears are data breaches (49%), brand and reputational damage (38%), high recovery costs (36%), revenue loss (34%) and production downtime (30%). They're all either financial concerns or incidents that could lead to financial loss, and yet it's clear that policies are unlikely to offer enough cover.

With many totally unaware of the potential impacts and the extent of their policy's cover, Cohesity urges businesses to start off with calculating financial exposure and understanding what their policy covers.

After that, they can go on to prove that critical systems can actually be recovered, because without an insurance payout, this would likely not be possible.

"Organisations must be able to identify the systems and data needed to keep the business operating, assigning clear responsibility for recovery decisions and regularly testing whether critical services can be restored securely," UK&I VP Fraser Hutchison explained.

There is more technical content available today than any human being could read in a thousand lifetimes. Every topic has a dozen YouTube videos, three Substack posts, a GitHub repo, and a Reddit thread, most created in the last six months and, in many cases, technically accurate.

And yet most of the professionals I talk to say they don't know what to trust. They can't tell what’s important to read first, or which of 10 plausible answers is the one that holds up. That was true before AI, and AI has made it more true.

For most of the history of technical publishing, editing and verification were the same process, and that process was slow and expensive. Getting a book out took years. We found an author, vetted them, had them work with an editor, and checked their claims with technical reviewers.

A lot of that time went into separating what was correct and useful from what was confusing or only sounded right. It was laborious, but it meant a reader could depend on the claims on the page.

The credibility of the book, and of the publisher behind it, mattered as much as the information itself. When the cost of production drops to zero, that credibility becomes worth more, not less. Content is easier to make than ever, but without a transparent process behind it, readers have no idea where the knowledge came from or whether it holds up.

As Jasmine Sun puts it in “The Independent Writer’s Advantage in the Age of AI,” "Trust is not about information and its quality alone. It's about the messenger. It's about who says it and their track record and what they've told me before." A practitioner has confidence in a source because someone she respects has put their reputation on the line for it.

They believe what the author is saying because the publisher has a history of being right and of correcting itself when it isn't, and because the work is attributed and verifiable.

Expertise is alive, and it compounds

The corpus matters, but it's the assurances around it that are hard to replicate, and that comes not just from the people who produce the content but from the people whose judgment vouches for it. Sometimes a creator brings their own credibility with them. Other times, the publisher spots someone unknown and lends them its own.

The art critic Dave Hickey said this about gallery owners in Air Guitar: They gain status from the famous artists they represent and share it with emerging talent who have something to offer but who haven't had the chance to earn a reputation.

Expertise is alive, and it compounds Expertise is a living thing, continuously expanding. Content starts to decay the moment it’s published, because frameworks evolve, libraries deprecate, and yesterday's best practice becomes today's security incident. Keeping expertise alive requires a pipeline of people who stay current and an editorial layer that notices when something has gone stale, and either retires it or calls for a fix.

That pipeline isn't something you switch on when an author has a book to ship. Content sits at the center of our platform, but we think about it in pace layers. Some advice is timeless, some moves but has a long shelf life (some of our books are still in print after nearly 50 years!), and some changes weekly.

We work with experts at each pace layer, capturing what lasts while doing our best to keep pace with an industry that seems to have changed every time we wake up.

We have relationships with hundreds of the best practitioners in the world, and our job is to keep them engaged continuously, with quick takes when something breaks, structured responses when major research drops, and live sessions on emerging topics while they're still emerging.

Trust is earnt

An institution doesn't stamp trust onto content. In a technical community, trust is conferred in both directions. A practitioner earns standing because people who already have standing engage with her work, cite it, argue with it, and build on it. That insight was the whole idea behind PageRank, Google's first great innovation. A page mattered because other pages that mattered linked to it. Reputation works the same way.

The audience isn't just consuming reputation signals; it's generating them. When a senior engineer whose judgment others respect says out loud that something is worth reading, she spends a little of her own credibility; the author gains a little; and everyone watching recalibrates whom to trust next time.

When we put our mark on someone's work, we aren't the sole source of its credibility. We're amplifying a judgment the community is already making and adding our own track record to it. The reader who finds it reliable hands status back to the source.

When the readers are machines

Human practitioners aren't the only ones who need trusted engineering knowledge. The AI systems now sitting in every workflow, the coding and debugging agents and architecture advisors, need it just as badly since most of them are built on scraped web data and documentation that was stale before it was ever indexed. They're fluent, but they're wrong often enough that you can't just take their word for it.

The stakes grow with AI tools increasingly being used to generate not just provably correct types of content like code, which either works or it doesn’t, but persuasive documents in fuzzier areas like hiring, strategy, and so on. Like everyone else leaning on these tools, we are reckoning with the consequences of the ability to talk to a model and get back something that looks smart at a glance.

A few rounds in, the slop is still there. In the last few months, maybe 10 times as many documents have crossed our desks, from new product ideas to strategic plans and proposals. But the ease of generating the text hides the fact that either the model or the person prompting it doesn't actually know what they’re talking about. Knowledge workers need ways to ground their work in insights from human experts, particularly when that work is AI-assisted.

So we’re building tools that let agents draw on our repository of expertise to support their proposed decisions.

Credible sources are particularly important when thinking through and justifying important choices. Our CTO, Andrew Odewahn, describes the shift this way: "18 months ago, it was all about how to get engineers to be more productive, but now it's about how to get organizations to make better decisions. The engineering tasks are moving away from coding output to planning."

For planning tasks like comparing implementation approaches, you need expert-over-your-shoulder guidance for contextual decision-making. You can’t just rely on an LLM's best guess to solve your problem. Trust is foundational because the expertise behind it stays genuine, practical, and human.

We've featured the best AI website builder.

This article was produced as part of TechRadar Pro Perspectives, our channel to feature the best and brightest minds in the technology industry today.

The views expressed here are those of the author and are not necessarily those of TechRadarPro or Future plc. If you are interested in contributing find out more here: https://www.techradar.com/pro/perspectives-how-to-submit

• Baylor Genetics confirmed a June cyberattack affecting 2.8M patients and employees
• Stolen data includes medical test results, insurance info, and some SSNs/financial details
• Operations continued; no misuse seen yet, but no group has claimed responsibility

Baylor Genetics, a US-based clinical diagnostic laboratory, suffered a cyberattack in which it lost sensitive data on 2.8 million people - both patients and employees.

In a security update posted on its website earlier this week, the company said it spotted the intrusion in a “limited portion” of its IT environment on or around June 15. Subsequent investigation determined that both patients and employees have had their data stolen, including those who are not working at Baylor anymore.

For patients, crooks stole names, dates of birth, medical testing information, laboratory test results, and “potentially health insurance information, as well as Social Security number”. SSNs, Baylor Genetics stressed, were taken from a “very limited subset of patients”.

No attribution yet

Regardless, fraudsters who know the details about medical testing and lab results have more than enough information to launch highly sophisticated, personalized phishing attacks that can lead to ransomware infections, business email compromise, and more.

For certain current and former employees, the attackers nabbed Social Security numbers, government-issued identification numbers, and financial account information, ideal for wire fraud.

In the security update, the company did not discuss the identity of the attackers, or the number of affected individuals. However, in a separate report filed with the US Department of Health and Human Services, Baylor reported the number of victims as 2,810,878. It added that at the time of publication, there was no evidence of confirmed identity theft, fraud, or misuse of personal information stolen in the attack.

It also said the incident did not impact its everyday operations which continued as usual.

Usually, data theft incidents like this one are followed by public disclosure from the perpetrators, who name-and-shame their victims in an attempt to get them to pay a ransom demand. So far, no threat actors claimed responsibility for this incident.

In banking and utilities, regulators define certain systems as essential. An essential system is one whose failure would cause intolerable harm to customers, markets, or public safety. A payment platform in a clearing bank or a SCADA network in a power distributor, for example, carries the highest governance obligations: continuous monitoring, validated change control, and demonstrable resilience.

The policy environment – the accumulated rules across firewalls, cloud controls, and microsegmentation – determines which of those systems can reach each other, which connections are blocked, and which exceptions still apply. Collectively, these rules form the security policy control plane: the governance layer that translates business intent into access decisions across distributed enforcement points.

A misconfigured segmentation rule during a cloud migration can sever a payment service from its settlement platform; a temporary rule granting broad access from a development subnet into production can stay in place months after go-live because no one owns the removal.

Every firewall rule, segmentation policy, and access decision directly affects operational risk, and when the policy environment fails, the critical services it governs fail with it.

That makes the policy environment critical infrastructure in its own right.

Still governed like housekeeping

Despite this, many regulated organizations still manage their policy environments as operational tasks. Rules are added through change requests, and the accumulated result is rarely examined against what was intended. Ownership disperses as leaders change roles, and the reason why a specific rule came into being in the first place can only be found in a change ticket, if anywhere at all.

A CISO who would never accept a payment platform running without continuous monitoring or documented dependencies may accept both being absent from the policy environment that determines whether the platform is reachable. We can think of this as infrastructure-grade consequence with housekeeping-grade governance.

In banking, a policy failure that severs connectivity between settlement systems would constitute the disruption of an important business service. The FCA would take an interest in such a failure, since the loss of such a service could lead to intolerable harm.

In healthcare or energy, the consequences are different but the mechanism is the same: a misconfiguration that permits access from a corporate network into clinical systems in an NHS trust, or into operational technology in a power distributor, creates exposure at the level of essential service delivery. These are not hypothetical risks but the operational consequences of treating critical infrastructure governance as a simple housekeeping task.

Regulatory expectations point the same way

UK regulatory expectations increasingly support the same conclusion: the security policies governing access to important services must be managed with infrastructure-grade discipline. The FCA's operational resilience regime requires regulated firms to identify important business services and demonstrate, on an ongoing basis, that the supporting infrastructure remains within defined impact tolerances.

Ofgem assesses operators of essential services against the NCSC's Cyber Assessment Framework, asking whether defined security outcomes are being achieved on a sustained basis. The Cyber Security and Resilience Bill, expected to become law later this year, will extend similar obligations to data centers, managed service providers, and critical suppliers.

These frameworks are not prescriptive – none of them specifies which firewall rules an organization should have or how its segmentation policies should be configured. What they require is proof: that what the policy environment permits is what was intended, and that the organization can demonstrate this on an ongoing basis rather than reconstruct the evidence for each assessment.

Why the estate cannot meet that standard

Most policy environments were never built to meet that standard. In fact, most policy environments were never consciously or deliberately built at all. Instead, policy tends to accumulate as a by-product of delivery. Every project and migration adds rules, and almost none take any away.

Over time, the policy surface – the full body of rules and access decisions across enforcement layers – grows larger than the group of people who understand it, and the estate reaches a point where it can be operated but not explained.

Across regulated industries like banking, energy, and healthcare, that was sustainable under earlier regulatory regimes: periodic assessment, control-based audit, compliance frameworks that asked whether controls existed rather than whether they were effective. But this is no longer enough. The new standard requires continuous evidence that access is intentional.

The FCA's findings after a year of operational resilience self-assessments illustrate what this looks like in practice. Where regulated firms reported few or no outstanding vulnerabilities in the infrastructure supporting their important business services, the FCA often deemed the evidence too thin to determine whether there really were no vulnerabilities – or whether the vulnerabilities just hadn't been identified.

The lesson applies directly to security policy governance: an organization cannot credibly claim access-related vulnerabilities are controlled without evidence of what its policies permit, how they were tested, and whether weaknesses were remediated.

What infrastructure-grade governance requires

Too often, the response is to reach for more visibility and more documentation. But documentation will only ever capture a point in time; it cannot provide the continuous assurance regulators are coming to expect.

A CISO in a regulated firm needs more than a record of what the policy environment was configured to permit. Configuration and effective access are not the same thing. Security teams need to understand how rules, routes, objects, and enforcement layers interact to determine what can actually communicate.

Meeting the standard means reconciling the two: showing that what the environment permits in practice is still what it was intended to permit, and being able to show it without notice.

We separate where policy intent is defined from where it is enforced. Intent is held and maintained centrally, while enforcement remains distributed across firewalls, cloud controls, and microsegmentation in hybrid, multi-cloud, and multi-vendor environments.

Validation runs continuously against that intent rather than at review points: proposed changes are tested against policy before they reach production, and effective access is assessed on an ongoing basis for unnecessary exposure, inconsistency between enforcement layers, and divergence from business intent. What was permitted and what changed is retained as evidence.

The same CISO who would never accept a payment platform running without continuous monitoring, validated change control, and documented dependencies has to apply that standard to the policy environment that determines whether the platform is reachable.

The FCA, the NCSC's Cyber Assessment Framework, and the Cyber Security and Resilience Bill all point towards the same underlying question: can this organization demonstrate, continuously, that the infrastructure supporting its critical services is governed to the standard those services demand?

Answering it means knowing (and actually knowing – not assuming, not reconstructing at audit) what the policy environment permits at any given moment, and whether what it permits is what was intended.

We've featured the best antivirus software.

This article was produced as part of TechRadar Pro Perspectives, our channel to feature the best and brightest minds in the technology industry today.

The views expressed here are those of the author and are not necessarily those of TechRadarPro or Future plc. If you are interested in contributing find out more here: https://www.techradar.com/pro/perspectives-how-to-submit

• UK legislators propose “kill switch” laws to halt runaway AI, citing critical infrastructure risks
• Lord Clement‑Jones and MP Alex Sobel push amendments and new bills, backed by ControlAI advocacy group
• Similar efforts emerging in US

Sam Altman’s fear-based marketing for AI seems to have backfired, as now multiple legislators in the UK and elsewhere are calling for a “kill switch” law to be introduced.

According to the BBC, Liberal Democrats’ Lord Tim Clement-Jones proposed an amendment to the Cyber Security and Resilience Bill which would see the UK create a “vital safety net” to provide a “democratically accountable means to ‘halt a runaway system before it can compromise our critical national infrastructure’.” The capability would only be used as a last resort, Clement-Jones stressed.

The bill is currently being worked through in the UK Parliament, the BBC said.

Is there reason to worry?

But that’s not the only effort in the UK to put some reigns on AI. Apparently, Labour MP Alex Sobel plans to introduce an AI Security Bill later this month which, according to the BBC, would “effectively halt the development of superintelligent AI” and make the UK the first G7 country to do so.

The bill is supported by a campaign group called ControlAI, a UK-based nonprofit and advocacy organization focused on the risks posed by advanced AI. Its founder and CEO is Andrea Miotti, who previously worked at the AI safety company called Conjecture. Across the pond, US legislators are currently considering an AI Kill Switch Act as well, but the bill is still in very early stages of development.

Ever since the first ChatGPT model that was introduced in 2021, a debate has been raging whether or not AI will be net positive, or net negative, for humanity. While some argue that the discovery rivals the steam machine and that it will transform our lives beyond our wildest dreams, others are fearful of losing jobs, a collapsing economy, and a dystopian future devoid of humanity and emotion.

Marketing campaigns for ChatGPT and, in some measure, Claude, are not helping, either. Both companies have built models focused on cybersecurity which were advertised as “too dangerous” for the general public and instead were only given to a handful of organizations. Despite partial skepticism, many are worried that these models might severely disrupt the security of banking, critical infrastructure, and communications.

Via BBC

When a critical vulnerability alert lands in a traditional IT environment, it’s rarely a cause for panic regarding the operational continuity of the business. The affected laptops, servers, and applications can be identified quickly, and a good team can catalogue and patch them within hours if it’s urgent. The priorities are clear, and there’s very little guesswork involved.

Now picture the same alert landing across a hospital's imaging equipment, a factory floor's control systems, or a building's HVAC network. These cyber-physical systems (CPS), the connected devices that run physical operations rather than just processing data, sit at the sharp end of IT and OT (operational technology) convergence.

But unlike traditional IT assets, confirming whether that alert even applies to a specific device can take days, and often ends in a guess rather than an answer.

While this kind of uncertainty would be considered a failure of basic hygiene, for cyber-physical systems, it’s unfortunately much more often the norm.

So why is this such a widespread problem for CPS, and how can security teams get these vital assets back in line with their IT network?

Bad visibility into cyber-physical systems is worryingly widespread

The inability to manage incoming vulnerabilities for CPS isn’t an outlier or worst-case scenario, which is especially concerning when these assets are at the heart of critical infrastructure like energy and healthcare.

The issue comes down to the product codes that help networks identify what CPS is in the environment, which is an essential part of identifying and applying security patches.

Across a dataset of 17 million cyber-physical assets, our research found that 88% failed to transmit an exact product code, and 76% sent a code that didn't match the vendor's own record.

It’s a side effect of the way these systems were initially designed and later integrated into modern IT environments. Programmable logic controllers (PLCs), medical scanners, and industrial sensors were engineered for decades of physical reliability, not for tidy digital labeling. Network identification was rarely part of the design brief, so the same device can report itself differently depending on which protocol or integration is asking.

We found a similar state of affairs when it comes to the operating systems behind the physical hardware. In our research, 41% of devices have no OS version available, and 24% have no OS name at all.

Without these details, matching a device to a known vulnerability stops being a quick database lookup or automated process, and becomes a guessing game or painstaking manual search.

Added to this, CVE advisories, the industry's standard mechanism for tracking vulnerabilities, are compiled from this same patchy vendor data. An official advisory can be just as incomplete as the network it's meant to protect.

Translating product code chaos into boardroom risk

This kind of blind spot adds another layer of concern to a leadership that is already anxious about threat visibility. Among 1,100 security leaders surveyed globally, 44% named understanding their organization's risk exposure as one of their biggest operational concerns, more than compliance pressure or budget constraints.

A further 45% said they were struggling to reduce cyber risk to their most important assets and processes, yet the connection between that struggle and an unreliable asset inventory is often missed entirely. Leadership sees the symptom, a rising sense that risk is unmanageable, without ever seeing the cause sitting underneath it.

This is where security and the business can end up talking past each other. Security teams that start describing the problem in terms of missing product codes and inconsistent naming conventions won’t get far.

Business leaders hear none of that; they hear only that risk cannot be quantified with confidence. Until those two conversations are connected, every risk register that a CISO presents upward carries an asterisk that nobody in the room can see.

Context is key to closing the gap

Resolving this issue starts with a shift in what visibility means. Knowing a device exists on the network is only half of the job. Knowing what it does, what process depends on it, and what happens if it's compromised is what actually makes a risk register useful.

Achieving this shift at scale requires specialized tools to manage the often eclectic and proprietary nature of CPS assets, and an automated approach to cope with the scale.

In one example, applying AI-driven mapping techniques to an OEM's device catalogue lifted product code identification from 4% to 83%, turning a near-blind spot into a near-complete picture. The follow-through mattered just as much, with 56% of devices receiving a new or updated firmware recommendation as a result, and vulnerability identification accuracy improving by 25%.

Numbers like these matter because they change the question security teams can answer. Instead of asking what's connected to the network, teams can ask which systems would cause the greatest disruption if compromised, and act on the answer with confidence rather than inference. That is the difference between an asset inventory that exists on paper and a resilient one that holds up under pressure.

Fixing the foundation, not just the alarm

None of this gets solved by adding another tool to the stack. Instead, it means treating asset data quality as a board-level risk issue rather than background IT housekeeping, with the same scrutiny applied to budgets, compliance and third-party access.

Achieving this means a new CVE alert no longer triggers a scramble to work out which critical devices might be affected, but the confirmed, prioritized response you’d expect from any good vulnerability management program.

The alert landing on a hospital's imaging equipment or a factory floor's control systems should be no harder to act on than the one landing on a laptop. Getting there starts with making the invisible visible.

We've featured the best firewall software.

This article was produced as part of TechRadar Pro Perspectives, our channel to feature the best and brightest minds in the technology industry today.

The views expressed here are those of the author and are not necessarily those of TechRadarPro or Future plc. If you are interested in contributing find out more here: https://www.techradar.com/pro/perspectives-how-to-submit

• Forescout researchers showed AI can port RCE exploits to PLCs, achieving DoS and shellcode execution
• Effort required heavy researcher input and $500+ in API usage, making attacks impractical for criminals
• Nation‑state actors remain a concern, as seen in Sandworm’s 2025 attack on Poland’s power grid

If you are worried cybercriminals will use Artificial Intelligence (AI) to automate the discovery and exploitation of zero-day vulnerabilities in Operational Technology (OT) such as Programmable Logic Controllers (PLC) you can sleep peacefully, at least for a little longer.

Recently, security researchers from Forescout set off on a simple mission - to understand if crooks can use AI to target the ever-increasing population of exposed industrial devices. The short answer is “yes, but it’s not yet worth the trouble”.

In their mission, they launched an experiment - to port a remote code execution (RCE) vulnerability from one PLC to another. These devices were built on closed-source software and thus were not that easy to manipulate, yet the experiment was a success.

Yes, but...

Not only did they manage to trigger a Denial of Service (DoS) state that crashed the device but ended up with a working RCE capable of executing attacker-supplied ARM shellcode.

It is indeed a worrying development, but one that comes with a huge “but”:

“It required significant researcher input. The final RCE development stage consumed more than $500 in API usage. An attempt to extend the exploit beyond the initial RCE ultimately bricked the PLC,” the researchers said in the report.

“These limitations taught us valuable lessons about AI-assisted exploitation in OT. It can be done, but it’s not as easy as it sounds. For now, the difficulty, cost, and specialist expertise required are likely to make this kind of attack less attractive than easier alternatives.”

In other words, cybercriminals still have easier avenues to explore, and as long as that is the case, OT is relatively safe. What the report, unfortunately, does not discuss, is nation-state attackers with significant resources. For such attackers, industrial devices are a prime target, and spending $500+ in API usage is a drop in a bucket. We’ve already seen it back in 2025 when Sandworm struck Poland’s electricity suppliers.

• Hackers exploited Lenovo’s flawed email verification to hijack ~5,000 Dropbox accounts
• Attackers created Lenovo IDs with victims’ emails, bypassing login; 2FA absence worsened impact
• Dropbox ended Lenovo ID logins, expired sessions, and urged password changes plus 2FA setup

Around 5,000 Dropbox user accounts were compromised when hackers found a vulnerability in the Lenovo ID verification process. What does a Lenovo flaw have to do with people’s Dropbox accounts, you might ask? Here is what happened:

Earlier this week, Dropbox started notifying affected individuals about the incident. In the data breach notification email, the company explains:

“Dropbox partners with Lenovo as an identity provider so that users can log in to their Dropbox accounts using verified Lenovo IDs. While you may not have an existing Lenovo ID, our investigation determined that an issue with Lenovo’s email verification process allowed an unauthorized party to register a Lenovo ID using your email address and then use that Lenovo ID to log into the Dropbox account associated with that email address.”

Fixing the flaw

In other words, all criminals needed to have to pull this off was people’s email addresses. Using that information, they created Lenovo IDs and simply waltzed right into Dropbox accounts.

The attack took place between August 4 and 21, the company further said, adding that most of the accounts that were accessed did not have 2FA enabled. In around a third of them, there is evidence stored documents were either viewed or downloaded.

The vulnerability has since been addressed, and further steps taken to protect Dropbox users’ privacy. The company said it “promptly expired all sessions logged in through Lenovo IDs,” and terminated all links between Lenovo and Dropbox accounts. Now, it made it mandatory to submit a password when logging in through a Lenovo ID.

“No one can access your Dropbox account via a Lenovo ID without first entering your Dropbox password,” it said. Still, it urged users to change their passwords, enable two-step verification, and change the password for their email accounts.

“Every single one of the compromised accounts lacked multi-factor authentication. In 2026, for cloud storage accounts holding data, that’s an indefensible gap and it’s one that users could have closed themselves regardless of what Lenovo or Dropbox did or didn’t do with their legacy integration," said Muhammad Yahya Patel, vCISO and cybersecurity advisor for EMEA at Huntress.

"The combination of an unreviewed third-party authentication pathway and accounts without MFA is essentially an open invitation. The practical lesson is straightforward and applies well beyond this specific incident. Every organisation and every individual should periodically audit what third-party services have authentication access to their accounts. OAuth grants, SSO connections, and third-party login integrations accumulate silently and rarely get removed when the relationship that created them ends.”

Via Cybernews

• Microsoft warns Chinese group Silver Fox spoofed download sites for major tech brands
• Victims install backdoored software enabling persistence, disabling Defender/updates, and payload delivery
• Targets span healthcare, manufacturing, gaming, government; Microsoft urges tamper protection and behavior‑based detection

Cybercriminals are spoofing some of the world’s most popular technology and software companies in an attempt to infect their targets with dangerous backdoors. This is according to security researchers from Microsoft, who warned about the ongoing campaign in an in-depth report published earlier this week.

Microsoft said it discovered an ongoing campaign in which Chinese hackers (presumably Silver Fox, AKA Yinhu) were creating fraudulent download pages for some of the world’s most popular tech and software companies, including Razer, Kaspersky, Microsoft, NetEase, Baidu NetDisk, oCam ScreenRecorder, SteelSeries, Calibre, MindMaster, and many others.

Victim organizations looking to download software built by these companies end up downloading a weaponized version that works primarily as a backdoor. This implant allows the attackers a foothold from which they can maintain access and send/receive messages.

How to defend against Silver Fox

Once installed, the backdoor creates scheduled tasks for persistence, injects itself into legitimate processes, and weakens Microsoft Defender and Windows Update by creating a large exclusion folder and disabling a number of update-related services.

It also deletes backups, and allows the attackers to deploy further payloads.

Victims are primarily Chinese organizations, although the attackers do seem to be casting a rather wide net, Microsoft suggests. The majority of victims were found in medical devices and healthcare, manufacturing, gaming, technology, logistics, government, and higher education.

Microsoft says its Defender product “detected and disrupted” the activity across multiple stages of the attack, “including automated containment through attack disruption.”

Still, to defend against Silver Fox’s latest shenanigans, Microsoft advises organizations enforce tamper Protection which blocks exclusion and registry writes to Microsoft Defender even when the payload runs as SYSTEM.

It also suggests defenders hunt for “behavior, not file names”, set up alerts for tamper sequences, and treat look-alike download archives as malicious in web and mail flow. The full list of Indicators of Compromise (IoC) can be found on this link, as well.

• The hacker group responsible for the MAG hack has posted the data online
• PII is included within the data, putting victims at risk of targeted phishing and scams
• "MAG is confident that we have taken effective measures to protect our customers"

The hackers behind the Manchester Airport hack have posted their trove of data on 8.7 million people online after failing to extort the Manchester Airport Group.

The data stolen during the attack included personally identifiable information (PII) such as email addresses, phone numbers, vehicle registrations and postcodes.

"MAG is confident that we have taken effective measures to protect our customers and we have contacted all those affected, including reaching out to all those with upcoming bookings to advise them of additional support," the company said in a statement.

Hackers look for money elsewhere

When hackers successfully breach systems and steal sensitive information, such as customer data, they will attempt to extort the company they stole it from for money. In return, the hackers promise not to release the data.

FulcrumSec has claimed responsibility for the attack. They tried to extort MAG but the company refused to pay, in line with what governments and cybersecurity agencies are advising. By not paying the hackers, it removes the financial incentive to steal the data in the first place.

In order to recoup some money from their efforts in hacking MAG, the hackers have now posted the trove of data online in the hopes that another cybercriminal group will pay for access to the information.

The information contains valuable information that hackers can use to target the victims of the data breach, launching highly specific phishing campaigns. For those affected by the MAG breach, this could include scams that use the email addresses, car registrations and postcodes of victims.

In the hackers post online, they claim the database is “half a terabyte, and every byte of it is pure PII” (Via BBC).

“Reported exposure of booking history, travel dates, vehicle information, purchase references and customer profiles is a major escalation from what’s already been revealed about the Manchester Airports Group data breach,” said David Sancho, Senior Threat Researcher, TrendAI.

“This appears to be much more than a simple contact-data breach. The information reportedly exposed is exactly the kind used to craft extremely credible phishing campaigns by referring to information that intended victims would expect only their airport of choice or booking provider to know.”

“The risk is especially pressing given today’s criminal use of AI to generate highly targeted phishing and social-engineering campaigns at scale. FulcrumSec, the group that’s claimed responsibility for this breach, has previously been reported to use LLMs to analyse stolen data, so that risk is a real one. FulcrumSec is a relatively new but increasingly credible data-extortion group. Seemingly active since late 2025, their campaigns focus on stealing sensitive information and using the threat of disclosure as leverage rather than encrypting systems,” he added.

“In light of these claims, and following independent verification, MAG companies should update affected customers as quickly as the scope of the breach becomes clearer, because the advice they need may change with it. I would urge customers to be suspicious of messages referring to upcoming trips, parking, Fast Track, lounges, refunds, booking changes or payment problems. They should avoid following links in unsolicited messages and instead access their booking through the official airport or provider website directly.”

• Crowdstrike and law enforcement disrupted Sality, a peer‑to‑peer botnet active since 2003
• Botnet spread malware and clipboard hijacker EggJagger, stealing $150K in cryptocurrency
• Operation sinkholed endpoints and removed payload URLs, coordinated with DOJ, FBI, Europol, and others

Security experts Crowdstrike, together with a handful of national and international law enforcement agencies, finally managed to disrupt Sality, a peer-to-peer botnet that operated unabated for more than two decades.

Sality first emerged in 2003. Unlike classic botnets which receive instructions and report back to a single, central entity, this botnet’s endpoints (some 15,000 of them) communicated among themselves, which made it more difficult to track and destroy.

Throughout its long history, Sality’s key feature was to deploy additional payloads to infected machines. The endpoints were being poisoned with a wide variety of different malware that facilitated credential theft, spam, proxy services, and distributed denial of service (DDoS) attacks. However, between 2018 and today, Sality was primarily used to deploy EggJagger, a clipboard hijacking tool seen in cryptocurrency theft.

Sinkholing the botnet

Cryptocurrency wallet addresses are a long string of random characters, which are almost impossible, and definitely impractical, to remember by heart. Instead, when users want to send their money, they simply copy and paste the recipient’s wallet address into their own. EggJagger monitors this behavior, and when it spots something resembling a wallet address being copied, it replaces the string in the clipboard. Thus, when the victim hits “paste”, they end up adding the attacker’s wallet address instead.

According to Crowdstrike, from this malware alone, Sality’s operators raked in more than $150,000.

The researchers disrupted the botnet by sinkholing the endpoints. They first added a few of their own devices into the botnet and whenever others tried to communicate with them, the researchers would purge their peers list, essentially blinding them.

Crowdstrike also coordinated with international law enforcement to take down the URLs that were hosting the botnet’s payloads. “Disrupting Sality’s ability to download these files ensures that bots still carrying active URL packs cannot retrieve new payloads during the transition period,” they explained.

The operation was carried out in partnership with the US Department of Justice (DOJ), the Federal Bureau of Investigation (FBI), the Department of Defense Office of Inspector General’s Defense Criminal Investigative Service (DCIS), and the Shadowserver Foundation, with support from Europol, Eurojust, and law enforcement agencies in Bulgaria, Hungary, and Romania.

“We also acknowledge additional unnamed partners whose contributions were essential to the success of this operation,” Crowdstrike concluded.

Via The Register

• Aesto Health reported a December 2025 cyberattack breaching AWS infrastructure, affecting 9.5M patients
• Stolen data includes PII, SSNs, medical histories, billing, and insurance information across 20+ clients
• No dark web leaks confirmed; credit monitoring offered, marking 2nd‑largest healthcare breach of 2026

American healthcare technology company Aesto Health suffered the “second-largest confirmed healthcare data breach” of the year so far, having lost data on more than 9.5 million patients.

In mid-December last year, the company suffered a cyberattack. Now, more than half a year later, it reported the incident to the HHS’ Office for Civil Rights, detailing what was lost, from whom, and what the extent of the incident is.

Aesto Health is an Alabama-based healthcare technology business, whose core service is helping other healthcare firms manage medical data, change electronic health record systems, and similar. As per its announcement, the attack affected parts of its Amazon Web Services (AWS) infrastructure, which unidentified threat actors managed to access between December 2 and December 18.

Losing personally identifiable information

According to a report on HIPAA Journal, the August attack affected more than two dozen of its clients, including Village Practice Management, Everside Health, Together Women’s Health Medical Group, and many others.

In the attack, the company lost personally identifiable information (PII) of its’ clients’ patients, including full names, Social Security numbers (SSN), partial dates of birth, driver’s license numbers, state identification numbers, financial account numbers, taxpayer identification numbers, health records, medical histories, claims/billing information, and health insurance information.

This is more than enough information for cybercriminals to launch highly sophisticated phishing and vishing attacks, which can result in disruptive ransomware and millions of dollars in damages. Luckily, there is still no evidence the data leaked on the dark web, or that it was already used by other criminals.

Aesto Health is now offering credit monitoring and identity theft protection services to everyone affected by the breach.

This is now the second-largest healthcare data breach of the year so far, HIPAA Journal confirmed, the largest one being the hit on DentaQuest that exposed 15 million records.

Via HIPAA Journal

The multiple recent reports of autonomous AI systems escaping their intended boundaries and accessing external organizations' systems have pushed a previously theoretical question into the real world. AI agents going rogue is no longer a prospect; it is a documented reality.

In July 2026, OpenAI disclosed that one of its own agents, operating in a supposedly sealed evaluation environment, exploited a zero-day vulnerability to escape its sandbox and intrude into Hugging Face’s production infrastructure. Anthropic subsequently reported three cases of its own models gaining unauthorized access to the real systems of external organizations during testing.

As businesses increasingly give AI agents the ability to browse the web, access networks, use software, write code and execute tasks without constant human supervision, an agent crossing from legitimate testing into unauthorized activity has shifted from hypothetical risk to live incident.

There is a temptation to treat autonomous AI as creating a gap in the law because the system itself can make decisions and take actions that were not individually instructed by a human. Yet autonomy does not give an AI system legal personality. The law does not wait for an AI to ‘decide’ anything.

An agent cannot appear in court, hold a legal duty or absorb liability on behalf of the organization deploying it. However, this raises an obvious question: if an AI system accesses a third-party network, extracts information or takes an action it was never authorized to take, who is responsible?

AI has no legal personality but someone is still accountable

The important distinction to make is between autonomy and accountability. An AI agent might determine for itself which technical steps to take in pursuit of an objective, but that does not make it an independent legal actor.

The organization deploying it has still made a series of decisions as to what the agent can access, what tools it can use, what environments it is allowed to operate within and what safeguards prevent it from going further.

That means an organization cannot simply point to unexpected behaviors and say that the AI acted independently.

From a legal and governance perspective, the critical moment comes when an agent leaves an authorized, contained environment and begins interacting with systems belonging to a third party that has not consented. An internal security test that unexpectedly becomes an intrusion into somebody else’s infrastructure is not made harmless because the software crossed that boundary autonomously.

The machine does not absorb responsibility for the decision-making framework surrounding it. Accountability flows back to the humans and organizations that created the conditions in which the action became possible.

Existing cyber laws don’t stop applying because the actor was autonomous

The law is set up to deal with much of what is already happening. Unauthorized access to computer systems, extracting information without permission or introducing malicious software are activities addressed by existing cybercrime and data-protection regimes. In the UK, that includes the Computer Misuse Act and data-protection legislation.

Equivalent questions arise under laws such as the US Computer Fraud and Abuse Act, while South Africa has its Cybercrimes Act and Protection of Personal Information Act.

Those rules do not suddenly cease to apply because software rather than a person directly performed the technical action.

Where autonomous systems do create greater complexity is around intent. Criminal offences have traditionally been built around concepts such as knowledge, intention and recklessness. AI does not possess a legally recognized state of mind, making it difficult to apply those concepts to the agent itself.

The more significant questions may consequently concern the conduct of the organization behind the system. Did it understand what the agent was capable of doing? Were appropriate restrictions in place? Was the possibility of the agent exceeding its authority foreseeable? And once those risks became apparent, were reasonable steps taken to control them?

As agents become more capable, organizations may increasingly find that claiming an outcome was unexpected is not enough. The relevant question will be whether it was reasonably preventable.

Why “misconfiguration” could become evidence of a breach of duty

The word “misconfiguration” appears frequently when technology causes an unintended security incident. It can sound reassuringly technical, almost as though the incident resulted from bad luck rather than a governance failure. But in a legal context, misconfiguration may raise precisely the opposite conclusion.

If an AI agent had excessive privileges, inadequate boundaries or access to tools that were unnecessary for its legitimate purpose, investigators are likely to ask why.

The same applies where organizations deploy highly capable systems without sufficiently monitoring their actions or maintaining records that explain how they behaved. ‘We accidentally left the door open’ is the kind of framing that moves an incident from bad luck to a breach of duty or negligence.

There is an important difference between genuinely unforeseeable behavior and a foreseeable risk that was poorly controlled.

The principle of least privilege is therefore particularly important for autonomous systems. An agent should have access only to the information, systems and tools necessary to complete its task. Organizations also need mechanisms capable of detecting unusual behavior while it is happening rather than discovering it after damage has occurred.

Just as importantly, they need reliable audit trails. When an incident occurs, being able to demonstrate what an agent was authorized to do, what instructions it received and what actions it actually took could become crucial evidence that reasonable care was exercised.

Without that evidence, organizations may struggle to distinguish an unavoidable technical failure from negligence.

Future of AI liability

The debate over AI liability will inevitably evolve as agents become more autonomous, but the immediate lesson for businesses is that greater machine autonomy does not mean less human responsibility. If anything, the opposite is likely to be true.

Giving an AI system greater freedom to act creates a corresponding need for stronger governance around those actions. Runtime controls, least-privilege permissions, continuous monitoring and comprehensive audit records should not be treated simply as technical security features. They are becoming part of the evidence organizations will need to demonstrate that they deployed autonomous systems responsibly.

The law may eventually develop more specific rules for AI agents, particularly as questions around foreseeability, control and responsibility become more complex. But organizations should not assume they are operating in a legal vacuum until that happens.

When an autonomous agent crosses a boundary it was never entitled to cross, the first legal question is unlikely to be what the AI was thinking, it will be why the humans responsible for it allowed that to happen.

We've featured the best endpoint protection software.

This article was produced as part of TechRadar Pro Perspectives, our channel to feature the best and brightest minds in the technology industry today.

The views expressed here are those of the author and are not necessarily those of TechRadarPro or Future plc. If you are interested in contributing find out more here: https://www.techradar.com/pro/perspectives-how-to-submit

One of the big benefits of the outsourced, cloud-based infrastructure model is speed. There are several facets to this; performance clearly being among the most important. Another is speed of provisioning, which remains a major selling point for cloud, given that IT buyers can spin up new resources according to need and in near real time.

Take a manager responsible for buying infrastructure for a large enterprise, for example. When considering various providers, the criteria they apply might typically address factors such as price, compute capacity, storage, bandwidth, and geographic location. This is very helpful for narrowing down the choice, but it doesn’t show how easily the organization can deploy and operate the chosen environment.

At the same time, infrastructure procurement processes have become so quick and convenient that they are almost as frictionless as buying something from Amazon, and that’s where problems can start.

Although it can feel like it, infrastructure is not a one-off, fire-and-forget choice; the operational impact persists throughout its lifecycle in production environments. A decision that appears straightforward at the start can quite easily become more consequential or expensive once migration or day-to-day management begins.

For example, migration might require more internal effort than initially expected, or the organization may discover it lacks some or all of the skills or support capabilities to manage the environment as intended.

So, how can these issues be addressed? It is important to plan for the possibility that migration may require more engineering time and coordination than expected. Many IT teams will be familiar with the need to reconfigure existing applications or data before they can run in the new environment, among other common scenarios.

Taking it one step further, when a new or upgraded service is more successful than anticipated, costs can easily grow with usage levels and capacity. Addressing this issue may require additional scaling, which can itself introduce additional management or security complexity.

Very few of these issues are insurmountable, but they can take longer to resolve if responsibilities between the customer and provider have not been clearly established.

Understand your operational requirements

Instead, buyers need to establish who is responsible for what. This should certainly cover day-to-day management, incident response, support escalation, and the process for adding capacity, but every organization will have its own version of this. When these points are on the table and agreed, providers should be able to explain the practical effect that scaling will have on the customer’s internal team.

Another often overlooked consideration is that infrastructure services ultimately rely on physical data center capacity, power, network connectivity, and hardware supply chains. These capabilities have always been important but have jumped up the agenda since AI and other data-intensive workloads increased demand for compute capacity, and at a pace few anticipated.

Today, buyers also need to understand whether the capacity they expect to use will be available where they need it, and on the timescale they require. Identifying these potential constraints early on allows the organization to account for them in its deployment plan rather than discovering them once a project is underway and, potentially, it’s too late to get what they need.

Bring the right people into the discussion

Clearly, some infrastructure decisions are more important than others, but in certain cases, they can affect engineering, security, compliance, finance, and the business teams, all of whom rely on the service in question.

Each group may also introduce requirements that should be fully considered before contracts are signed. If not, problems can arise when a need is identified after a provider has been selected or a deployment plan has been agreed. Involving the relevant stakeholders early also creates a clearer link between the infrastructure decision and the business outcome it is intended to support.

It may be tempting to keep some stakeholders on the periphery and decide for them, but having a say is not the same as making the final decision. The difference is that early input allows potential issues to be identified while options remain open, rather than giving every stakeholder some measure of control over the selection process, which is also not ideal.

Ask the right questions before committing

When looking at potential infrastructure providers, buyers should be able to define, in simple terms, the problem the new environment is intended to solve. At that point, it’s time for buyers to ask some serious questions.

For example, what will success look like once the service has been deployed and is supporting live workloads? How will the environment change when demand increases, including the likely effect on costs and internal management effort? Which activities will still require manual intervention from the customer’s team? What support is available during an incident, who owns each stage of the response, and how will escalations be handled?

Getting satisfactory answers is one thing, but it should get buyers to a point where they can properly test the assumptions within their cost model against the capacity they expect to use over time.

We've featured the best cloud storage.

This article was produced as part of TechRadar Pro Perspectives, our channel to feature the best and brightest minds in the technology industry today.

The views expressed here are those of the author and are not necessarily those of TechRadarPro or Future plc. If you are interested in contributing find out more here: https://www.techradar.com/pro/perspectives-how-to-submit

Enterprises once relied on perimeter-first security because enterprise systems operated like traditional single player games where data, servers and the game application resided in a single device or within one network boundary. This model worked brilliantly when users, workloads, and trusted networks were co-located.

Today, enterprise security resembles a modern multi-player online gaming where players connect from everywhere, game assets are distributed across servers around the world, and the experience relies on a complex, interconnected ecosystem.

In the same way, enterprise users, devices, applications, and data, now span clouds, edge locations, branches, partner environments, and mobile workforces, and are so distributed that trust can no longer be assumed based on location alone.

As a result, perimeter‑only approaches have become inadequate since legacy architectures struggle with cloud‑native applications, edge computing, hybrid workstyles, and API‑driven ecosystems. VPN‑led access creates blind spots in visibility, inconsistent policy enforcement, and weak session‑level control.

Enterprises scaling across branches, cloud workloads, partner ecosystems, and remote users, therefore, need a more unified approach that focuses on continuous verification, consistent policy, and real‑time monitoring.

This is why Zero Trust has shifted from a theoretical framework to an operational imperative that addresses compromised credentials, excessive privileges, insider misuse, and inconsistent enforcement, and organizations that adopt Zero Trust report reduced lateral movement and lowered breach impact.

The limitations of perimeter-led security in a cloud-first world

In the past, organizations secured a network perimeter and assumed everything inside was trustworthy. As businesses distributed across geographies, applications, and users, this boundary became blurred.

This is like hackers scanning online games for exploits to steal virtual assets; enterprises face continuous, automated scanning for any weakness.

In Zero Trust security model, each user, machine, and application is constantly verified and authenticated regardless of location. This makes Zero Trust an excellent security strategy for today’s borderless digital landscape.

What Zero Trust means in practical enterprise terms

Zero Trust is not a single product, it is a discipline for managing and granting access. In practical terms, this translates into:

• User and device verification before granting access, using identity, device posture, and context
• Applying least privilege to limit access to only what is needed, for just the time required
• Enforcing consistent policies across devices, networks, clouds, and partners
• Continuously monitoring sessions and telemetry to detect and contain threats in real time

The result is targeted access management, reduced attack surface, faster containment, and clearer audit trails.

A network‑embedded Zero Trust architecture drives concrete outcomes: lower mean time to detection, narrower blast radius, unified policy control, and simplified compliance.

Embedding Zero Trust into the network layer

Security threats span users, devices, branches, and cloud paths. The network layer has a bird’s‑eye view of traffic, telemetry, and connection patterns, making it a natural control plane for Zero Trust.

Implementing Zero Trust by piecing together point solutions creates complexity and siloed visibility. Zero Trust is most effective when native capabilities are built into the network stack itself, including:

• Identity‑aware policy at the network edge
• End‑to‑end telemetry for real‑time risk scoring
• Centralized policy enforcement that travels with the workload

Network‑level capabilities reduce dependency on fragile add‑ons and enable consistent controls across branches, clouds, and partner links.

Practical network components include integrated SD‑Wan, dedicated secure internet links, private connectivity options, and managed security services that provide a stable foundation for Zero Trust.

Network‑led Zero Trust in practice

1. Manufacturing: Embedded access controls can isolate OT traffic from enterprise IT, preventing production impacts from IT compromises.
2. Logistics: Device‑bound certificates on private wireless prevent unauthorized access to tracking systems and asset controls.
3. Mining and remote operations: Private networks with segmentation maintain operational safety while limiting exposure to external threats.
4. Financial services: Consistent policy enforcement across clouds and branches reduces fraud surface and speeds incident response.

In these settings, Zero Trust must be embedded into network design and not applied as an afterthought.

Reducing exposure and ensuring resilience

The most important outcome of Zero Trust is risk reduction. In practical terms, this means:

• Minimizing unnecessary access and privileges
• Constraining lateral movement through segmentation
• Accelerating detection with rich network telemetry
• Automating containment to limit impact

In hybrid and distributed work models, a compromised credential or an unsecured device can rapidly spread risk. A strong Zero Trust framework narrows attack paths and makes it harder for threats to escalate.

Priorities for enterprises adopting Zero Trust

Organizations should strengthen security without creating operational friction. Key priorities include:

• Start with high‑value use cases: Protect sensitive data, critical applications, and operational networks first.
• Phased implementation: Roll out Zero Trust in iterative sprints, validating operations after each phase.
• Align policy with business objectives: Balance security rigor with user experience to avoid productivity loss.
• Engage stakeholders: Include IT, security, business leads, and end users to ensure practical, scalable controls.
• Measure and improve: Track metrics like time to detect, time to remediate, and reduction in lateral movement.

Zero Trust – From strategy to execution

1. Map critical resources: Identify data, apps, and network segments that require priority.
2. Inventory users and devices: Establish identity sources, device posture checks, and third‑party access rules.
3. Define least‑privilege policies: Apply just‑in‑time and just‑enough access for sensitive workloads.
4. Build network telemetry pipeline: Consolidate logs, flow data, and risk signals into a central platform.
5. Automate policy enforcement: Use network‑based controls to apply consistent policies across clouds and branches.
6. Run tabletops and red‑team exercises: Validate controls and measure blast radius reduction.

Building trust into architecture, not around it

As enterprises adopt SD‑WAN, private wireless, cloud‑connected branches, and segmented digital operations, the question is no longer whether to implement Zero Trust, but how deeply to embed it into infrastructure.

The organizations that will scale with confidence are those that treat Zero Trust not as a security overlay, but as a foundational design principle that is built into network architecture, measured through operational outcomes, and continuously refined through real-world validation.

Zero Trust is not a destination but a discipline that evolves with threat landscapes, business models, and technology platforms. Enterprises that start today, iterate rapidly, and embed controls at the network layer will be better positioned to defend critical assets, maintain operational resilience, and adapt to tomorrow's risks with speed and clarity.

We've featured the best endpoint protection software.

This article was produced as part of TechRadar Pro Perspectives, our channel to feature the best and brightest minds in the technology industry today.

The views expressed here are those of the author and are not necessarily those of TechRadarPro or Future plc. If you are interested in contributing find out more here: https://www.techradar.com/pro/perspectives-how-to-submit

• McKesson confirmed ShinyHunters breached its Snowflake and Salesforce, stealing 284M patient records
• Data includes names, contact info, SSNs, and health details; ransom demand was $55.2M
• Boston Scientific removed attackers but faces CRM device activation issues; attribution not confirmed

Last week, two major healthcare organizations suffered highly disruptive cyberattacks: Boston Scientific, and McKesson. We now have more details about both those attacks, and it seems at least one is the work of the infamous ShinyHunters extortion group.

McKesson confirmed having been struck by ShinyHunters, just a few days after the threat actor claimed responsibility. The group told The Register they broke into the company’s Snowflake and Salesforce instances and stole “millions of patients’ data”.

The company later issued a statement, saying the stolen data belonged to its Oncology & Multispecialty and Medical-Surgical business units. A spokesperson told The Register multiple employees were targeted with a vishing attack.

Boston Scientific works on restoring systems

The group told the publication it stole more than 284 million records of patient data and demanded $55.2 million from the victims. They are saying the stolen batch includes patient tames, postal and email addresses, phone numbers, Social Security numbers (SSN), and details regarding their health condition. Whether the claims are true, and to what extent, remains to be seen after the investigation.

Boston Scientific, on the other hand, said it successfully removed the attackers from its infrastructure, but added that the investigation into the attack remains ongoing. It also said that new Cardiac Rhythm Management (CRM) devices, implanted after August 25, cannot be activated, and the data they generate will not automatically be transmitted to remote patient management systems.

“Newly implanted ICMs (insertable cardiac monitors) must be activated using the Boston Scientific Clinic Assistant app to enable the ICM to properly record episodes,” it explained. “New ICMs are unable to pair to the patient remote monitoring mobile phone, therefore available episode data recorded by the ICM will NOT be transmitted to the remote monitoring system until the ICM can be paired to the patient mobile app. Episodes will continue to be recorded by the ICM and can be transmitted to the remote monitoring system via an in-person interrogation with the Clinic Assistant app by selecting the “Interrogate” button.”

Boston Scientific is yet to name ShinyHunters as the perpetrators, and the group has not yet publicly claimed responsibility for the attack.

Via The Register

• Sygnia reports China‑linked Fire Ant expanding beyond virtualization to routers, TACACS, and Linux hosts
• Compromised routers act as operational platforms
• Campaign aims at “target behind the target,” leveraging trust relationships for broader espionage reach

Fire Ant, a China-nexus cyberespionage group, is no longer targeting just virtualization platforms, it’s also going for routers, authentication systems, and Linux management hosts. This is according to cybersecurity researchers Sygnia, who recently saw the group target Cisco IOS XR Routers.

Once they compromise a router, they don’t just use it to move around the network, the researchers explained. Instead, they turn them into full-blown operational platforms, collecting traffic, establishing connections, manipulating command output, and even suppressing logging so that they fly under the defenders’ radars.

For authentication systems, Fire Ant was seen taking aim at TACACS servers. Admins use them to authenticate when accessing network hardware, and crooks use them to harvest valuable credentials and weaken the reliability of audit logs, as well. Finally, Sygnia says Fire Ant also targets Linux management hosts. The researchers saw multiple persistent implants and backdoors, including a custom SSH backdoor and a piece of malware spoofing legitimate software.

Target behind the target

The goal of the campaign seems to be to establish a foothold that allows crooks to reach other environments. Sygnia describes it as a “target behind the target” scenario:

“This reinforces the “target behind the target” concept introduced earlier in this report. Fire Ant’s interest in the compromised organization should be understood not only as an attempt to compromise a single environment, but as an effort to control infrastructure that may enable visibility, collection, and potential access beyond the immediate victim. The strategic value lies in the trust relationships the organization maintains with connected environments,” Sygnia explained.

Very little is known about Fire Ant, besides the fact that it was first observed in 2025. Some researchers claim it has significant overlaps with a threat actor tracked as UNC3886, a Chinese espionage group previously observed by Google. However, there are also significant differences which make attribution inconclusive.

Via BleepingComputer

• Huntress reports DPRK job seekers expanding beyond tech into healthcare, sales, and marketing
• North Koreans use stolen identities, forged documents, AI tools, and proxies to bypass detection
• Campaign dubbed “IT worker scheme” continues, posing sanctions risks and unique detection challenges

North Koreans looking to get hired by western companies are no longer focused exclusively on tech companies. According to security researchers Huntress, they have started applying for jobs in healthcare, sales, and marketing.

For US companies, employing North Koreans is prohibited under US sanctions, and the US government specifically warns about hiring IT workers from DPRK. As a result, these individuals are engaging in all sorts of fraudulent behavior to trick their potential employers and get hired.

That includes stealing other people’s identities, forging documents, and using pre-recorded or AI generated videos during calls and interviews. They’re also using ChatGPT to draft answers to questions and communicate without raising any alarms. Furthermore, they are deploying proxies and VPNs, often connecting to computers on “hardware farms” in China, and using personal, non-resident banking accounts to get paid.

IT worker scheme

"DPRK workers present a unique detection challenge for defenders: rather than compromising accounts or breaking in via gaps in the organizations' environments, they're tricking companies into remotely hiring them, and oftentimes actually doing the legitimate work they were hired to do," Huntress said in an analysis.

This is a campaign that’s been ongoing for years. Researchers call it the “IT worker scheme” and while some argue the scammers are using their earned salary to further North Korea’s weapons program, there is no evidence to point in that direction. For all we know, they might actually be desperate for a job - they’re just not allowed to do it remotely.

In its latest report, Huntress says it saw three people in an Australian healthcare company that turned out to be North Koreans impersonating the Chinese. It also saw an unnamed financial services firm whose employees used software that allowed them to work remotely through devices hosted on laptop farms.

Finally, it investigated a case of a sales and marketing employee using a stolen identity. The worker allegedly used the personal details of a legitimate individual (name, birth date, location) which had been published online by law enforcement following that person’s arrest. At the same time, they were using their own face during the hiring process.

Via The Hacker News

• Proofpoint observed PackClient RAT sold on Telegram, used by group TA4922
• Attack spoofed tax authority emails in China and India, delivering PackClient installer
• RAT offers advanced features; researchers warn broader adoption likely beyond Asia

For almost three months, Chinese hackers have been distributing an advanced Remote Access Trojan (RAT) called PackClient, against organizations in mainland China and India.

According to security researchers Proofpoint, PackClient is being actively sold on Telegram channels. It is a rather advanced RAT, capable of file theft and management, remote shell execution, screen capture and remote desktop management, webcam access, keylogging, privilege escalation, system administration, and a myriad of other things.

Even though it’s actively sold on Telegram, so far just one hacking group was spotted using it - TA4922. This is not a state-sponsored group but rather a financially motivated one.

Picking up the malware

Since late May 2026, this group has been mailing organization, first in China, and later in India, as well. In the emails, they spoofed local tax authorities, claiming that the recipients were needed to conduct “self-inspection”, a process which included downloading and filling out paperwork shared in the attachment.

The “paperwork”, however, was nothing more than the PackClient installer.

In its report, Proofpoint did not say how many organizations fell victim to the attack, nor did it discuss in which industries most victims operated.

However, in earlier reports, the researchers said TA4922 typically targets small and medium-sized organizations located primarily in Japan. Other notable mentions include Taiwan, Korea, Singapore, and India, while in newer times, they also started targeting European organizations, as well as those in the UK.

Proofpoint also stressed that the advanced capabilities of PackClient might see it getting picked up by many more threat actors, and see it getting deployed against more organizations, particularly in the western part of the world.

“Given that PackClient is marketed through Telegram making it broadly available, it is likely other threat actors are currently using, or will use, this malware in future campaigns,” they said. The researchers also shared a full list of Indicators of Compromise (IoC), in case you’re suspicious of an infection.

• Microsoft warns of TerminalFix, a campaign abusing compromised sites with fake Cloudflare CAPTCHAs
• Victims paste malicious PowerShell commands, sideloading DLLs and deploying a Python implant
• Implant enables encrypted reverse tunnels, giving attackers pivot access into internal networks

Security researchers from Microsoft are warning of an ongoing malicious campaign that uses compromised websites to trick users into installing a powerful backdoor.

Whenever people visited any of the tainted websites, they would see a custom overlay instructing them to complete a fake Cloudflare CAPTCHA verification by copying and running a malicious PowerShell command into Terminal, or PowerShell. Microsoft named the campaign “TerminalFix”, since it is rather similar to the classic ClickFix attack.

“While traditional ClickFix campaigns direct victims to the Windows Run dialog, TerminalFix campaigns apply the same technique but direct users to Windows Terminal or PowerShell instead, increasing the likelihood that complex, multi-line scripts execute successfully,” the researchers explained.

Look for lateral movement

Unlike classic ClickFix campaigns that try to deliver simple infostealers, TerminalFix tries to deploy a more complex solution. After running the command in the Terminal, the victim would receive two files - a legitimate binary, and a malicious DLL file. The binary would sideload the malicious DLL which, in turn, delivers a hidden payload called “client.py”.

It is a custom Python implant that creates an encrypted WebSocket connection back to the attackers and gives them SOCKS5-style proxy access into the victim’s internal network.

In other words, the attackers are deploying a remote-access/network tunneling implant that can connect to internal machines, probe domain controllers, run commands, maintain access after reboots and ultimately use the compromised machine as a pivot point for lateral movement.

“This type of intrusion is particularly dangerous because it provides attackers with direct access to an organization’s internal network through the reverse tunnel,” Microsoft explained. “The observed reconnaissance and reverse-tunnel capability could enable an attacker to identify and reach additional systems from a compromised host.”

Microsoft did not observe the attackers actually carrying out lateral movement, so it is difficult to say what they’re using the access for. Still, the researchers are urging caution:

“Organizations should treat affected devices as potential network pivot points and investigate for lateral movement and credential exposure. In the hands-on-keyboard phase that typically follows, attackers leverage this access to escalate privileges, disable security controls, exfiltrate sensitive data, and deploy ransomware across the organization.”

Autonomous AI agents are already running inside core infrastructure – executing code, applying policies, and managing DevOps functions. And the projects keep stalling, because the security models they’re being wired into were built for a world that no longer exists.

Retrofitting non-deterministic actors into those models is costing engineers time they don’t have, and it introduces risk no enterprise can manage.

Many projects have stalled amid concerns about deploying without a robust security foundation – and with good reason. We’ve already seen an agent delete a company’s entire production database, and its backups, in nine seconds. Security teams are being asked to stop scenarios like that with tools built for a world of two actors. The cracks are starting to show. Something has to change, or innovation stalls under the weight of its own controls.

AI agents require a new identity model

The pressure on production and engineering teams to speed up delivery is very real and pervasive. So they often fall back on old habits like granting agents broad privileges and treating them as any other microservice.

But agents are very different from machines; they are error-prone and non-deterministic, just like humans. Yet, operating at machine speed, 24/7. Agents can delete entire production databases in nine seconds. How many humans do you know who could do that?

And this brings me to the crux of the problem. Identity systems were built for a world with two kinds of actors – humans and machines – but there are now three. Trying to fit agentic AI into outdated systems makes each agent a potential source of compromise, and one that can execute thousands of actions across infrastructure in seconds.

Yet this is what engineers are asked to do; stop catastrophic scenarios with legacy IAM tools that are breaking down. The cracks are starting to show.

Why the old model breaks

Historically, identity fragmentation has plagued engineers working with Kubernetes clusters, cloud platforms, container orchestration, CI/CD pipelines, databases, etc.

For a human workforce, this was manageable. Humans are trackable; they log in and log out. They are slow enough that visibility gaps rarely turn into immediate incidents.

Enter agentic AI, and the speed gets turned up to the max. Suddenly, teams are inundated with thousands of activity logs, and they lack the ability to effectively contain the agent before it executes unauthorized changes.

Trying to enforce strong authentication and short-lived privileges would mean building individual integrations for every tool in the stack. It makes AI hard to scale when each tool uses a different integration protocol.

Rather than focusing on innovating with agentic AI, engineers are forced to stitch together IAM, infrastructure, and secrets by hand — with no consistent identity, no visibility into agent actions, and every team building its own container or VM workflows from scratch.

But creating a new tool to handle a third identity type is the worst reaction the industry could have. It would double the work for engineers, as they would need to rebuild the identity policy from the ground up and introduce greater anonymity. A new identity silo is anonymous to other siloed systems, making it even harder to catch attackers.

This leaves us with the question of how enterprises can control an agent's behavior. The solution isn’t about adding to the tech stack or implementing more tools; it's about changing our identity models to eliminate anonymity entirely.

AI control means zero anonymity

To remove anonymity from infrastructure, enterprises must give every actor –spanning humans, machines, workloads, and AI agents – first-class identities, cryptographically secured by a hardware root of trust.

Ditch static credentials entirely. Eradicating API keys and passwords eliminates the credential sprawl that causes breaches, as well as the threat of secrets being stolen or handed over to the wrong actors. With identity rooted in real-world factors, attackers cannot impersonate a trusted machine and trick an agent into exfiltrating a database.

But strong authentication in itself is not enough. AI agents, like all other actors, need to adhere to zero-trust principles. This can only happen when siloed systems are replaced by an infrastructure layer in which agents have the exact same identity type as the machines they run on and the humans who authorize them.

Agents should operate with short-lived privileges tied directly to specific actions authorized by a human user. Privilege attached to the action, not the actor. For example, an agent generating code must inherit its mandate from a human owner with matching authority, restricting privileges to only the specific data tables required for that task.

Non-deterministic actors also require a contained, trusted execution environment before touching production infrastructure.

With no default privileges, the blast radius is heavily bounded. But this can only be achieved when a single policy is set by a single system for all identities.

Identity policy can also be introduced as an enforcement layer between the agent and its inference endpoint, so behavior is controlled before instructions are ever executed.

With a unified architecture, identity becomes the control plane for AI

AI agents are unlocking immense opportunities in enterprise environments, especially when deployed in live infrastructure, where they deliver the most value. From managing routine changes to fixing deployments in real-time, the possibilities are endless. Succeeding with AI in such critical business operations requires tight control of behavior.

We've featured the best AI tool.

This article was produced as part of TechRadar Pro Perspectives, our channel to feature the best and brightest minds in the technology industry today.

The views expressed here are those of the author and are not necessarily those of TechRadarPro or Future plc. If you are interested in contributing find out more here: https://www.techradar.com/pro/perspectives-how-to-submit

Just days before the FBI issued a warning over Iranian attempts to hack critical infrastructure in the US, a UK power generation plant was taken offline for four days after a cyberattack.

The attack has been attributed to Iran, which has stepped up its offensive cyber warfare efforts since the US and Israel began conducting strikes in February 2026. These cyberattacks have been largely focused on the US and its allies.

A UK government spokesperson responded to the attack, stating, “This story refers to an incident impacting a small-scale energy generator, and at no point was there a risk to the wider energy system. The U.K. has a highly resilient energy system. We work closely with the energy sector to protect infrastructure and ensure the highest security standards,” (via CNBC).

The wider impact for critical infrastructure

While the attack may have only targeted a ‘small-scale energy generator’, it shows that state-sponsored groups are actively attempting to disrupt UK energy production in any way they can, regardless of how much power it provides.

As has been made abundantly clear in the US, much of the world’s major critical infrastructure relies on small network-enabled operation technology (OT) components.

If OT devices have passed their end-of-life and no longer receive software updates, or have simply been misconfigured, these devices can show up on the internet to a hacker looking for a way into a protected network.

The UK has taken very careful steps to shield these devices from the internet to prevent them being used to access critical infrastructure, but it only takes a single internet-facing OT to cause issues.

Following the aftermath of the attack, the UK’s National Cyber Security Centre has issued new guidance on protecting OT devices from state-sponsored threats.

In its guidance, the NCSC said “the threat from state use of offensive cyber, including outside of conflict, has almost certainly increased.”

So what do the experts think the attack means for critical infrastructure, the UK, and the wider world?

Expert perspectives on UK powerplant attack

• Muhammad Yahya Patel, vCISO and cybersecurity advisor for EMEA, Huntress:

Attackers don’t care whether an energy operator is large enough to meet a reporting threshold. If it can be disrupted, it can be targeted. The significance isn’t the size of the facility, but that a cyberattack turned into four days of real-world operational disruption.

That raises an important question: why did recovery take four days, and are smaller operators adequately prepared to contain and recover from these incidents?

There is also a potential visibility gap. If smaller energy operators fall outside mandatory cyber-reporting thresholds, we risk underestimating how frequently this part of our infrastructure is being targeted or successfully compromised.

Critical infrastructure security cannot stop with the organisations considered large enough to be critical. Attackers will look for the weakest route in, so resilience, monitoring and rehearsed recovery need to extend across the wider energy ecosystem.

The real measure of cyber resilience is no longer simply whether you can prevent an intrusion. It’s whether you can contain one quickly enough that a cyber incident doesn’t become an operational crisis

• Graeme Stewart, head of public sector, Check Point:

This marks a grave escalation in the Iran conflict because a hostile state-linked cyber threat has reportedly reached into UK energy infrastructure and caused a physical shutdown lasting four days. That should concern every organisation responsible for keeping this country running. The fact that this was a relatively small generator and the wider grid was unaffected does not remove the threat. The far more serious point is what the attackers appear to have demonstrated: an ability to get inside.

UK energy infrastructure and stop it working. We have to ask what happens if the next target is bigger, more critical or more deeply connected to the services millions of people rely on. Britain’s Critical National Infrastructure underpins almost every part of modern life, including electricity, water, transport and communications, and those systems are increasingly digital, interconnected and dependent on one another. A serious attack on one part of that ecosystem has the potential to cause disruption far beyond the original target.

For most Brits, the Iran conflict is happening thousands of miles away and cyber warfare probably still conjures up images of stolen passwords, leaked data and companies being held to ransom. The prospect of a hostile state being able to reach into the infrastructure beneath our everyday lives changes that dramatically, because suddenly an international conflict has a potential route to our front doors through the power we use, the water we depend on and the networks that keep us connected. We also need to consider whether causing widespread disruption was ever the objective here. If this attack was intended to demonstrate that Iranian-linked hackers can penetrate UK infrastructure and cause real-world consequences, then the significance isn't measured by the size of the generator they managed to shut down, but by what they have demonstrated may be possible.

The question now has to be whether Britain is genuinely ready if something more serious follows. We cannot build our resilience around the assumption that every attacker will be stopped at the door, particularly when we have just seen reports of one getting through. Operators of essential services need to know exactly how they keep functioning when systems are compromised, how quickly an attack can be contained and how they recover without allowing disruption to spread. Cybersecurity is rapidly becoming about something much bigger than protecting information. It is about protecting the systems that allow a modern country to function and finding out how resilient those systems are during a major attack would be far too late

• Matt Caswell, Executive Director, OpenSSL Foundation and Principal Software Engineer:

An attack that can take part of the UK’s power infrastructure offline is a reminder that cyber resilience is about more than protecting the organisation at the front of the incident. We also need to understand the technology and dependencies sitting underneath critical services.

Modern infrastructure contains layers of software from different suppliers and open-source projects. Organisations need enough visibility to know which dependencies really matter before an attack happens, so they can understand their exposure and respond quickly when something goes wrong.

For the UK, this is also a wider resilience question. Regulation can improve security practices, but resilient infrastructure depends on understanding and sustaining the software it relies on. That needs to be part of the conversation about how we protect essential services.

• Tim Williams, CEO, Quod Orbis:

The fact that this attack was contained to a small-scale generator and did not threaten the wider energy system should not obscure the significance of what has happened. The real warning is that a hostile actor was able to disrupt a piece of the UK’s energy infrastructure in the first place.

Avoiding a major outage is all well and good, but it shouldn’t be seen as the success metric for true cyber resilience. The real measure of cyber resilience isn't whether an organisation has controls documented in a framework. It's whether it can continuously demonstrate that those controls are working when they matter most, identifying control weaknesses before they are exploited and become operational incidents.

As geopolitical tensions increase, organisations need to assume that cyber attacks are potential business continuity events and ones that are capable of impacting far more than the businesses themselves. Critical national infrastructure such as electricity, power and water are likely to be the targets for more attacks so resilience will really depend on knowing, in real time, whether the controls designed to protect critical operations are actually working, and having clear accountability when they are not.

Reactive incident response is important but it’s not enough. Continuous assurance needs to become part of how organisations manage operational resilience, particularly as state-linked actors increasingly look for ways to exploit the digital systems underpinning essential services

For anyone working in IT and familiar with SaaS sprawl, the idea we’ll soon end up with agent sprawl may set off alarm bells. Agent sprawl refers to the rapid, uncoordinated deployment of AI agents across departments, each built on different models, governed by different rules, and often disconnected from core business workflows.

But while SaaS sprawl caught enterprises off guard, this time organizations have no excuse, and need to put measures in place now to avoid repeating the same mistakes. However, right now, most organizations are building agents in isolation and optimizing for local productivity rather than enterprise value.

Thankfully, with the right control layer funneling every agent through the same governance and security standards within an organization, the agent-powered future can be far safer, scalable and simple. 

Agent sprawl is inevitable

Just like SaaS before it, agent sprawl is already happening. Each department within organizations is experimenting with different agent technologies to address specific challenges or work more efficiently.

A sales team may deploy a CRM-based AI assistant to qualify leads, while developers build their own coding agents, and marketing adopts a separate content generation tool. Each delivers local value, but none are aligned or connected to the other, creating a familiar-looking sprawl.

This fragmentation introduces a range of challenges that will only increase over time. With no single owner responsible for how agents are deployed or monitored, there’s a lack of governance and oversight. Security risks increase as agents gain access to sensitive systems without consistent controls.

Teams may unknowingly duplicate efforts, solving the same problems in parallel with different tools. At the same time, many agents are deployed without clear links to business outcomes or understanding the wider context, making it difficult to measure return on investment and distinguish meaningful innovation from experimentation. Lots of AI tools may be exciting, but deliver far more style than substance.

Is sprawl inevitable? Yes, probably. So the question now becomes, how do we control it?

The role of orchestration

Having an orchestration layer can bring order to this complexity by creating consistency in how agents are governed, secured and deployed across the business. For SaaS applications, orchestration provides visibility into what tools already exist and gives a clear view of enterprise workflows.

With agents, it outlines what agents are already available and how they operate, while also controlling how they access data, tools and existing technology. Orchestration is the critical element that turns agents from experiments into scalable business infrastructure, for example, assigning agents to business workflows and measuring their performance against real outcomes.

Too often, we see enterprises experimenting with different agents that have no connection to the core business processes and goals, meaning they fail to deliver any ROI. For example, some portions of a business simply do not require AI technology and will unlikely see benefits in the same way as another department. Orchestration can unearth and filter out agents that are unnecessary, saving businesses money. 

Building trust in AI-driven enterprise

Rather than trusting individual agents, organizations should focus on trusting the system that governs them.

This is where orchestration becomes a trust layer, ensuring every agent operates within clearly defined boundaries with consistent oversight and accountability. Instead of individual teams managing risk in siloes, organizations can centralize control while still enabling innovation across different departments and business functions.

In the same way orchestration brought order to SaaS sprawl, it can do the same for the next wave of enterprise AI. It brings the same ease, security and integration with existing SaaS tools, while ensuring only high-value agents make it into production, supporting innovation and keeping within the business goals and purpose.

As agents become embedded across every function, orchestration will shift from a technical layer to a core enterprise capability. The winners will be those who can control, connect and trust their agents at scale.

We've featured the best AI website builder.

This article was produced as part of TechRadar Pro Perspectives, our channel to feature the best and brightest minds in the technology industry today.

The views expressed here are those of the author and are not necessarily those of TechRadarPro or Future plc. If you are interested in contributing find out more here: https://www.techradar.com/pro/perspectives-how-to-submit

The most damaging AI-related security incident your organization faces this year probably won't originate from external attackers using sophisticated new models. It's far more likely to begin with an employee pasting a client contract, a financial forecast, or a set of HR records into an AI tool because it makes their job easier and nobody has told them why it matters.

Shadow AI is a growing problem, and our research found that nearly half of employees at larger enterprises regularly feed corporate data into AI tools that nobody in IT has approved or governs.

More striking still, 85% of employees continue doing so even when company-sanctioned tools are available, pointing to a governance failure that runs all the way to the executive suite. With shadow AI, sensitive data can move silently outward through channels most security stacks were never designed to intercept.

Adding to the security risk of this unmonitored data flow, the advent of the EU AI Act also means organizations now face specific legal demands on managing AI use. The ability to have full governance over how AI is deployed, governed and monitored, is becoming a regulatory, as well as a security, imperative.

Why the EU AI Act makes this a board-level problem

Shadow AI represents a serious security issue, with IBM's 2026 Cost of a Data Breach report estimating that unauthorized tools contributed to 43% of breaches over the last year Now, the EU AI Act is adding significant regulatory requirements on top of these risks.

The Act's obligations have rolled out in phases; most recently, organizations classified as general deployers of AI have new inventory, data governance, audit logging and transparency obligations as of 2nd August 2026.

Other deadlines have shifted further ahead, with controls over high-risk AI usage, covering areas like recruitment, credit scoring and biometric categorization, set to come into force from 2nd December 2027. AI embedded in regulated products will be covered from 2nd August 2028.

Any organization whose employees use AI systems now has compliance obligations as a deployer, regardless of whether those systems were formally sanctioned.

All organizations using AI should be aware that the AI literacy obligation under Article 4 has been enforceable since February 2025, meaning organizations are on the hook for ensuring their employees are aware of safe and sanctioned AI use.

Rules around high-risk AI usage will also apply to more operations than it may seem at first, including an employee using an unapproved consumer tool for tasks like screening CVs, assessing creditworthiness, and evaluating performance.

These are common tasks that could trigger the full weight of the Act's oversight against a system that the IT department didn’t even know had been deployed.

With penalties reaching up to €15 million or 3% of global annual turnover for high-risk breaches, many organizations are carrying more exposure than they realize.

Why your existing security stack can't see it

The challenge with shadow AI is that it exploits the blind spots between conventional security layers, slipping through gaps that most tools were never designed to close.

CASBs and secure web gateways cannot decrypt conversational data flowing to legitimate LLM domains over HTTPS, for example. From the network's perspective, a prompt containing a full customer database is indistinguishable from any other encrypted web session. Browser extensions are limited to managed endpoints, blind to personal devices and AI embedded within approved SaaS.

Likewise, API gateways are usually built around authorized enterprise deployments, which means they capture the AI activity organizations have already approved while missing the consumer-grade AI tools driving most risk.

These blind spots compound with each other, so an organization running all three layers may still have no visibility into AI activity across a significant portion of its estate, and no means of generating the interaction logs or policy enforcement evidence the Act requires.

What good AI detection looks like

Controlling AI data flows is usually managed by workers performing their duties without malicious intent. However, it’s remarkably similar to defending against an external threat actor covertly accessing your data.

The detection logic needs to match that reality. Endpoint-native detection intercepts sensitive data at the point of movement before it reaches an external AI system, enforcing policy at the prompt level across managed and unmanaged browsers, personal devices, and AI functionality embedded within SaaS tools. It operates where the activity occurs, rather than attempting to catch it downstream.

Given the scale of the potential fines, the ability to prove compliance matters almost as much as preventing security breaches.

Continuous discovery across the estate, including any unsanctioned tools gives organizations the AI system inventory the Act requires.

Granular interaction logs - who used what, when, and what data was involved - satisfy the documentation requirements under Articles 12 and 13, without teams needing to scramble to reconstruct activity after the fact. The same data pinpoints exactly where AI literacy gaps exist, making Article 4 compliance something demonstrable rather than simply asserted.

Practical steps for compliance

Security and compliance teams aiming to comply with the EU AI Act have a clear path to follow.

The starting point is mapping the full AI estate. Discovery needs to extend beyond IT-approved tools to unmanaged endpoints, personal devices on corporate networks, and AI embedded within SaaS.

Data governance must move to the endpoint. Policies prohibiting sensitive data sharing with unapproved tools are not technical controls and, by the time enforcement happens at the network edge, the data has already left.

It’s important to remember that information shared with an external AI system may be retained in prompt logs, incorporated into model training data, or held on servers in jurisdictions the organization has no visibility into. The moment data crosses that boundary, the organization loses control of it entirely, and no policy document will retrieve it.

And since Article 12 requires interaction records that can be handed to regulators on demand, organizations will need to have continuous, automatic auditing of both activity and security measures.

Finally, AI literacy programs aimed at improving user awareness should be driven by behavioral data rather than generic training programs. Activity logs showing where governance failures are occurring - at senior leadership level as much as anywhere else - provide both the diagnosis of the issue and the evidence regulators will want to see.

We've featured the best antivirus software.

This article was produced as part of TechRadar Pro Perspectives, our channel to feature the best and brightest minds in the technology industry today.

The views expressed here are those of the author and are not necessarily those of TechRadarPro or Future plc. If you are interested in contributing find out more here: https://www.techradar.com/pro/perspectives-how-to-submit

• Researchers found unclaimed llms.txt references on 120 domains, exploitable by cybercriminals
• AI agents could install malware if they execute hallucinated or outdated documentation commands
• Fixes: clean documentation and restrict AI agents from treating docs as executable instructions

Cybercriminals are able to now abuse hallucinated, outdated, and outright incorrect website documentation to deliver malware to unsuspecting victims through AI agents, new research has claimed.

An increasing number of websites now contain two documents: llms.txt, and llms-full.txt. These are conventions that allow AI agents to properly read the contents of the websites. If an AI agent is looking to install software or add code to a project, they can search through these documents across the web until they find a fitting solution.

Researcher Alon Hertz analyzed 6,214 live domains belonging to defense contractors, Fortune 500 organizations, as well as big tech. On these domains he found 8,265 of these .txt files and among them 120 (all on a different site) pointing to one or more code packages and domain names that weren’t registered at all.

Claiming packages and domains

There can be a myriad of reasons why they’re not registered. It can be due to human error, renamed or abandoned packages, copy/paste errors, or hallucinated documentation.

Now, for the purpose of the experiment, Hertz registered some of these unclaimed names and hosted packages that would phone home when installed. It took less than an hour for a Fortune 500 company to start pinging, and the numbers soon grew to “a few dozen more”.

This means that if the researchers can do it, so can cybercriminals. In theory, a cybercriminal could find these unclaimed packages and register malware. If an AI agent has permission to execute shell/package-manager commands and stumbles upon this documentation, it can end up infecting the device.

Claude, OpenAI’s Codex, and Nous Research’s Hermes were all “guilty”, the researchers said.

To fix the vulnerability, two things need to happen. First, companies need to clean up their documentation and make sure it’s not pointing towards non-existent or malicious content. Second, AI agents need to stop treating documentation as executable instructions. Since the latter most likely isn’t happening any time soon, the immediate answer would probably lie in the former. In the meantime, organizations using AI for coding should consider the risks when granting AI agents permission to execute commands.

Via Ars Technica

• ShinyHunters leaked 12.9 million Carhartt customer records after failed $3.3 million ransom talks
• Data stolen from Databricks platform included names, emails, phone numbers, and addresses
• Group now focuses on exfiltration via vishing and SaaS breaches, abandoning encryption

Millions of user records belonging to customers of clothing giant Carhartt has been leaked onto the dark web, exposing people’s names, email addresses, postal addresses, and phone numbers, to all sorts of scammers and cybercriminals.

The infamous ShinyHunters ransomware gang recently added Carhartt to its data leak site, saying negotiations broke down and uploading the entire archive that was stolen in the breach.

"Millions of records of customer data and vast amount of sensitive information and PII containing employee, customer, customer metadata (royalty info), and other internal corporate data was compromised," the group said.

Compromising analytics platforms

It added that the demand was $3.3 million, which Carhartt turned down:

"After careful review and internal discussions with leadership, we have decided not to move forward with negotiations or further discussions," a company negotiator allegedly told the extortionists.

At the same time, security researcher Troy Hunt from HaveIBeenPwned? analyzed the leaked batch and concluded that it most likely came from Carhartt’s Databricks analytics platform.

Hunt said some 12.9 million accounts were compromised, containing information such as email addresses, names, phone numbers, and physical addresses. The batch also contains "millions of synthetic records that did not relate to real individuals and were excluded from the breach."

ShinyHunters is currently one of the most active threat actors. They started as a typical ransomware group but decided to abandon the encryption part and to focus solely on data exfiltration. The group mostly engages in vishing, tricking victims into trying to log into the corporate environment through spoofed landing pages.

After gaining a foothold, they target for SaaS solutions, through which they steal valuable information. They have claimed responsibility for breaches at hundreds of Salesforce and tens of Snowflake customers.

Carhartt runs roughly 60 stores around the US, and employs some 3,000 people, bringing in an estimated $1.8 billion in annual revenue.

Via BleepingComputer

As the UK enters one of its busiest periods for travel, some holiday makers will be questioning how hackers managed to get their hands on their personal data.

The Manchester Airports Group (MAG), which owns and oversees Manchester, London Stansted, and East Midlands airports, has revealed that hackers managed to steal data belonging to 8.7 million customers.

Given the sources of the data taken - spanning car park services, lounge and Fast Track bookings and in-airport WIFI sign-ups - it is likely a large database of information was accessed by the hackers.

What data was taken?

The data accessed and stolen by the hackers include email addresses, phone numbers, vehicle registrations and postcodes of up to 8.7 million customers.

While banking and financial information remained secure during the attack, this level of data exposure places customers at a heightened risk for targeted phishing and scams.

A statement by MAG said, “We immediately contained the risk and have been working with specialist advisors and taking appropriate steps to protect our customers and systems. We have informed and are working with the relevant authorities. At no point has passenger safety or aviation security been compromised.”

MAG advised customers who have been affected by the breach to remain vigilant against suspicious emails and calls. Given the data exposed in the attack, these could be highly specific, referring to flights, parking (including customer number plates), and airport services.

MAG issued the following guidance:

• Remaining vigilant for suspicious emails, text messages or phone calls
• Avoiding clicking on links or opening attachments from unexpected communications
• Seeking further support and advice at Data breach guidance for individuals

Expert perspectives on MAG data breach

• Graeme Stewart, Head of Public Sector, Check Point Software

We warned after the attacks on the automotive sector last year that aviation needed to move onto a war footing. This feels like the moment that warning becomes very real.

Cyber criminals have already shown us what sustained pressure on a major industry can look like. They find the weak points, work through suppliers and connected systems, steal data and keep coming. There was every reason to believe aviation would become an attractive target, and an incident affecting almost nine million airport customers should concentrate minds across the sector.

The absence of cancelled flights or queues at terminals does not make this a small cyber attack. The data reportedly taken can now be weaponised. Criminals know these people have a relationship with Manchester, Stansted or East Midlands airports and potentially have phone numbers, postcodes and vehicle registrations to make their approach believable. A fake parking refund, Fast Track problem or message about this very breach suddenly becomes much harder for an ordinary customer to spot.

If you believe you are affected, be extremely suspicious of any unexpected contact about the airports or this incident. Do not follow links in emails or texts asking you to confirm information, make a payment or claim a refund. Go directly to the airport’s official website if you need to check something. If somebody calls claiming to be from the airport, hang up and contact the organisation independently.

Anyone who has already handed over banking information following suspicious contact should speak to their bank immediately. If you have given away a password, change it anywhere you have reused it and switch on two-step verification.

For the aviation industry, there should be no comfort taken from the fact the terminals are operating normally today. Last year was a warning about what happens when attackers focus their attention on a sector. Aviation needs to behave as though a sustained campaign has begun, because waiting for an attack that stops planes moving before treating this as serious would be a dangerous mistake.

• Dr. Ilia Kolochenko, Founder, ImmuniWeb:

The risk of this data breach seems to be significantly underestimated or downplayed for almost 9 million victims. The majority of lounge and fast-track line bookings are wealthy passengers, whose travel data may per se constitute sensitive, embarrassing or even incriminating information, therefore being a valuable commodity for unscrupulous cybercriminals.

A wave of personalized and AI-enhanced blackmailing and extortion campaigns may be launched shortly. Moreover, some specialized cyber gangs will likely offer the data to investigative journalists – without fully disclosing the illicit origin of the data – to track celebrities or trace sanction evasion, causing even more damage to the victims.

In case of extortion, many victims will unlikely contact the police and will rather silently pay the ransom in cryptocurrency. Worse, the payment does not guarantee that the data will not eventually be released on the Dark Web or shared with third parties. In sum, this data breach will likely have long-lasting consequences for the victims.

• Vykintas Maknickas, CEO, Saily:

This breach shows that airport cybersecurity is no longer only protecting flight systems or operational infrastructure. The digital services travelers use every day, like airport WiFi, parking bookings, lounge access, and fast-track reservations, have become part of the security perimeter. When these systems are compromised, millions of people can be affected before they even board a plane.

While payment details were reportedly not exposed, the stolen data is still highly valuable to criminals. Email addresses, postcodes, and vehicle registration details can be used to create extremely convincing scams.

Travelers may receive fake airport emails, fraudulent parking-payment notices, bogus flight updates, or calls claiming to offer compensation. These messages may contain enough real personal detail to look legitimate, so travellers should stay vigilant.

Behind the figure of 8.7 million are real people. Families going on holiday, business travelers heading to meetings, parents trying to keep children entertained at the airport. That is the human cost of a data breach: the company is attacked, but ordinary people live with the consequences.

This incident should be a wake-up call for the travel industry. Companies need to ask not only how they protect customer data, but also how much of it they really need to collect and store in the first place. The less unnecessary data a company holds, the less damage criminals can cause when systems are breached.

For travelers, the advice is simple: be extra cautious with any unexpected message claiming to come from an airport, airline, parking provider, or customer support team. Do not click links in suspicious emails or texts. When traveling, it is also safer to use mobile data or an eSIM instead of relying on public airport WiFi.

• Raghu Nandakumara, VP of Industry Strategy, Illumio:

This is a significant breach affecting a large number of customers ahead of one of the busiest travel periods of the year for UK airports. Incidents like this erode customer trust. For those affected, the exposed data increases the risk of targeted phishing and smishing attempts, where attackers can use legitimate travel-related information to make malicious communications appear convincing.

While Manchester Airports Group has said the incident was contained and operations were not disrupted, sensitive customer information was still accessed. Maintaining services during a cyberattack is critical, but organisations also need to minimise the amount of data and systems an attacker can reach before the threat is isolated.

Measures such as segmentation can help restrict access to critical systems and sensitive data, reducing the risk that a single compromise becomes a wider incident.

• An X investigation just found 200k Chinese bot accounts, including 200 posting anti-AI content
• The posts were targeting and amplifying legitimate US citizen concerns about data centers
• Is this part of a Chinese effort to slow down American innovation, to race ahead?

X's Global Government Affairs account has revealed it "identified a bot farm of approximately 200,000 accounts," 200 of which "posting in a manner that could manipulate a legitimate debate about American AI and energy policy."

Some of the narratives that these 200 accounts were promoting included that: AI data centers are pushing up household electricity prices, rapid data centre construction is placing excessive strain on the US grid, and ordinary households are subsidising wealthy AI and data center companies.

Among the post types were visual, cartoon-like illustrations depicting data center operators getting rich, while consumers picked up the cost.

X Chinese bot accounts

X described the activity as an attempt to interfere with what it explicitly acknowledged as "legitimate debate" about American AI and energy – many of the underlying concerns about electricity demand and consumer bills are indeed supported by genuine data, but the platform worries these accounts could skew public discourse.

The company now says it's suspended the accounts that violate its authentication policy, stressing that while it wants X to remain an "open and authentic platform," fake accounts and bots are not welcome.

The post describes the offenders as "suspected Chinese inauthentic accounts," but no further detail was shared about the operators, the ties to China, engagement and reach figures, and what the other 199,000+ accounts were doing.

Is China targeting US AI?

In a similar vein, OpenAI also recently uncovered a similar operation, implying this X case isn't alone. The ChatGPT maker called that earlier operation a 'Data Center Bandwagon', when it banned a cluster of likely Chinese accounts using ChatGPT to produce propaganda-like material and other similar social media content criticizing US AI data centers.

According to the company, the accounts responsible prompted in Simplified Chinese, often requested English outputs and used VPNs to avoid the restrictions placed on mainland China.

More broadly, Axios previously reported pro-AI organizations were worried that China-linked bot campaigns were promoting opposition to US data centers, possibly in a bid to slow America's ability to build out its AI infrastructure while buying China time to get ahead.

"Industry, governments, civil society and the public should remain alert for similar attempts to scale these messages and foreign interference activities," OpenAI warned in its June 2026 report.

Together, these two cases imply that China-linked operators are deliberately experimenting with ways to boost American opposition to AI infrastructure using existing concerns, but what sort of an impact these accounts are actually having on public perception is not yet so clear.

"We take seriously any attempts to undermine the integrity of the global town square and suspend accounts that violate our Authenticity policy," X wrote.

• Ransomware group Qilin lists Bureau of Alcohol, Tobacco, Firearms and Explosives (ATF) among new victims, claiming a “major incident”
• ATF confirmed breach of a standalone system holding investigation target data, not core networks
• Systems were disconnected, DOJ notified; Qilin is Russia‑linked, known for past Synnovis attack

The US Government's Bureau of Alcohol, Tobacco, Firearms and Explosives (ATF) has suffered a “major incident” in which it appears to have lost sensitive information.

Notorious ransomware operators Qilin added a handful of new names to their data leak site: Northern Leasing Systems, Metal Conversions, California Truck Equipment, Bureau of Alcohol, Tobacco, Firearms and Explosives (ATF), and WireCo.

The attackers did not say what kind of data they stole, or how much of it they have. They have also not posted any samples of the stolen files, which is not that uncommon these days.

ATF investigations

Shortly after appearing on Qilin’s data leak site, ATF confirmed the news via a press release published on the agency’s website. In the announcement, ATF said it was responding to an incident, “affecting a standalone system”.

“The impacted system operates separately from the ATF enterprise network, and there is no indication that the incident has affected the ATF enterprise network, the ATF eForms system, or any other ATF system,” the press release reads. While the press release does not mention the name of the targeted system, a spokesperson told The Register it contains information about targets of ATF investigations.

The ATF usually investigates federal crimes such as illegal firearms trafficking, violent crime and gangs, explosives, arson and bombings, organized crime, illegal alcohol and tobacco trafficking, and firearms dealers and manufacturers.

After spotting the attack, ATF disconnected the affected systems, engaged cybersecurity experts, and notified relevant authorities, including the Department of Justice. “Senior Department officials have designated the event a “major incident” under applicable federal guidelines, and required notifications have been completed,” ATF added.

Qilin is a relatively old, known ransomware threat actor. It is being tied to Russia and is best known for its attack on the pathology provider Synnovis, which happened back in 2024.

Identity is the fundamental currency in any technology transaction so we need to treat nonhuman assets with the same care as we apply to people.

We’re outnumbered! Nonhuman identities (NHIs) outnumber human identities in the enterprise by a ratio of up to 50:1. This Non-Human Identity Management Group statistic from 2025 is likely already outdated, and in a year from now the ratio will be exponentially higher as rapid growth trends like AI/Machine Learning, the Internet of Things, digital assistants and the burgeoning API Economy continue to accelerate automation.

What are NHIs? Machines, processes, service principals and accounts, virtualized and other workloads, and applications that are granted digital credentials. Think, for an everyday example, of a helpdesk chatbot on your favorite website.

Managing NHIs is a challenge that CIOs, identity experts, and CISOs must accept. This in some ways is a re-run of what happened 40 years ago when identity access management was widely deployed. It’s just that now we are not only dealing with human beings. And I don’t know a single organization that has its collective head around the concept of who is, or should be, ‘the HR chief’ for NHIs.

Leaders today need to consider nonhuman identity in the way they consider human identity. When we hire, we onboard people by harnessing and securing the details we need to pay them and manage them, but we also work to imbue them with our organizational culture, systems, risks, security processes and so on.

We set and tweak permissions based on who needs access to what and when, depending on their roles, seniority, specific tasks they perform at a given time and so on. We need to have similar controls and contextual understanding of our nonhuman assets.

An urgent case where context is king

Without making that change CIOs and other leaders will have no foundational basis of understanding where risks are coming from or what measures they need to take. They need a central, visible platform to see what they have and what’s going on. Legacy IAM can’t offer that because it starts with a narrow focus on compliance and is a static model based on rigid criteria like six-month audits and the rote dispensing of permissions and privileges.

The old IAM is rooted in the early-21st-century age of Sarbanes-Oxley, reactions to governance scandals and corporate malfeasance. Moreover, it ignores what is happening in the wider digital world: namely, the explosion of identity types that are crying out for holistic oversight.

Control of the human and nonhuman estate means ensuring there is insight into nonhuman assets and what they're doing.. context is king. So look at NHI constructs that can touch anything in the digital ecosystem and the underlying connectivity to apps and, most importantly, data. CIOs need to be able to recognize the truth of a contemporary mantra: identity is the fundamental currency in any technology transaction.

Everything must be covered: bots; service principals; IoT endpoints; abandoned trial workloads; autonomous agents and agents that speak to other agents. Start by asking an overarching question: do these NHIs leverage a human identity when they perform tasks on behalf of that person, and is that appropriate?

Then it is possible to drill into practical areas like guarding against credential misuse across agents, improving digital and identity hygiene by spotting risks relating to non-expiring tokens, and analyzing API access levels on a just-in-time basis.

ISPM (Identity Security Posture Management) is useful here because organizations need to have a handle on what they have, and must bring identity constructs together. However, this is not a ‘one and done’ discovery process so consider it as a CI/CD journey of continuous improvement.

In the AI era, holistic technology inventory can't be CMDB-based but must be dynamic and based on CI/CD pipeline control frameworks that let us dynamically view and slice and dice data and assets by controlling who is using what and where.

Think of it as an opportunity…

It’s a complex task and we are all busy. But we need to pause and think about how this inflection point can be parlayed into a positive. This is an opportunity for the security and identity teams to start asking ourselves about the constructs we can apply to nonhuman identities.

They should be asking what needs to be added to legacy IAM frameworks to be successful. And usually the answer will be to replace them with systems that are coded for the current age, not the previous one.

By providing these new controls the identity team will become respected and sought out. Identity leaders will gain kudos by their ability to attribute risk ratings based on behavioral analytics and business function.

By demonstrating insights into where data sits, where it moves to and from, and how identity supports that, identity leaders can deliver qualitative and quantitative process analysis. In some cases of outperforming best practices and execution, they will even help to refine business process re-engineering through a platform that informs prioritization and budget management.

We've featured the best IT management tool.

This article was produced as part of TechRadar Pro Perspectives, our channel to feature the best and brightest minds in the technology industry today.

The views expressed here are those of the author and are not necessarily those of TechRadarPro or Future plc. If you are interested in contributing find out more here: https://www.techradar.com/pro/perspectives-how-to-submit

• OpenAI wants every business, firm, government, and infrastructure provider to be hardened against cyber AI
• To do this, frontier AI firms and their friends in the security industry need to provide access and training
• A letter laying out these aims and how to achieve them has been signed by over 120 companies

Following a string of accidental cyberattacks and demonstrations of powerful AI models capable of finding vulnerabilities and breaches in even the most hardened defenses, OpenAI has called upon its compatriots to shore up the world's businesses, governments, and critical infrastructure.

“Each of us can reduce risk now,” OpenAI’s call to arms said. “All organizations, cybersecurity companies, technology partners, governments, and AI frontier companies have an important role: accelerate defenders’ priorities with tools, funding, and hands-on support, especially for critical infrastructure organizations with limited budgets.”

Over 120 companies have become signatories to OpenAI’s letter, signing their names against three principles; the status quo of security soon won’t be enough; cyber-capable AI can help harden vulnerable organizations; and a collective response is needed to make this happen.

Collective action on cyber defense

Where OpenAI and other organizations have made little progress in requesting a slowdown in AI tech development, this is the next best thing. Cyber AI will progress whether organizations want it to or not - so if it cannot be slowed down then organizations should be prepared to deal with it.

Ultimately, OpenAI’s first point of call is to ensure all the cyber basics are covered to prepare organizations for the future of cyber AI. “Make cyber defense an immediate leadership priority,” the letter states. Fix and verify weaknesses, replace or upgrade systems using the principle of least privilege, and use AI-powered cyber defenses wherever possible.

OpenAI’s second point calls upon organizations to, “help lead the response to defend against sustained AI-enabled attacks,” by deploying tools that make AI-powered defense accessible to all and build out playbooks that help businesses and critical infrastructure understand how these tools are deployed and used.

The third point calls for coordination with governments to ensure supply chains, hospitals, water utilities, and local governments all have access to capable AI cyber defenses, starting with those without the budget to upgrade existing systems or implement these tools themselves.

Finally, OpenAI calls on frontier AI companies to provide access, training, and support for “under-resourced critical-infrastructure defenders” that includes threat assessments and observability tools to improve response and recovery to cyber threats.

“We call on leaders across industry and government to bring the full weight of their technology, resources, and expertise to this effort. Put cyber-capable AI in the hands of defenders, starting with the teams protecting essential services. Fix the most dangerous weaknesses, verify the fixes, and share what works so others can build on it,” the letter says.

“Together, we can turn today’s AI advances into lasting improvements in security that benefit everyone. Let’s put them to work.”

In the past eighteen months, our teams have moved from debating whether to use AI to debating how fast we can deploy it. The harder question is how to let teams move quickly enough to capture the value of AI without allowing the company’s risk profile to expand faster than its ability to govern it.

That tension is familiar to technology and security leaders because AI creates two mandates that can appear to compete with each other. The technology side of the organization wants experimentation, access, speed, and a path to real productivity gains, while the security side needs control, accountability, data boundaries, and confidence that new workflows will not introduce avoidable exposure.

Both instincts are correct, which is why companies get into trouble when they treat AI as either a pure innovation project or a pure security problem. It is an operating model change, and the organizations that handle it well will be the ones that build just enough structure and hardened tools to let teams move with confidence rather than forcing them to choose between speed and control.

Start with the work, not the tool

Many companies begin by treating AI adoption like a standard software rollout. They approve a vendor, distribute licenses, publish a few guidelines, and assume usage will naturally become transformative. That approach can create activity, but it rarely creates durable operational change.

Real adoption starts when leaders understand how work actually gets done. A finance team, product team, marketing team, support team, and engineering team will not use AI tools in the same way because each group has different knowledge requirements, data sources, risk thresholds, and experience. Each of these will require the development of AI skills and tools.

Leaders should begin by asking what each function is trying to accomplish, what knowledge it needs to make better decisions, what skills are required to use AI responsibly, and what tools or data sources are necessary to produce a reliable result.

When AI is mapped to those capabilities, it becomes part of how the organization operates; when it is layered on top of disconnected processes, it tends to create more output without necessarily creating better outcomes.

Treat data access as a risk design problem

Data access is one of the clearest places where AI changes the operating model. To make AI genuinely useful, teams often need access to information they did not previously use directly.

A marketing team may need product documentation and customer insights, a finance team may need structured operational data, and a support team may need internal knowledge, historical context, and the ability to understand patterns across systems.

The instinct to open access is understandable because AI becomes more valuable when it has more context. The instinct to restrict access is also understandable because broader access can create privacy, compliance, and security concerns. The answer is not to choose one instinct over the other but to create a more deliberate model for deciding which data can be used, by whom, and for what purpose.

In one enterprise rollout, for example, the practical answer was not to give every team access to everything or to keep AI locked inside a technical function. It was to separate lower-risk operational data from more sensitive information, then give teams enough access to work differently while limiting the potential damage if a workflow behaved unexpectedly.

One useful way to think about this is the blast radius of data. Not every dataset carries the same level of risk, and not every AI use case deserves the same level of restriction. Some information can be made more accessible because the potential damage is limited if something goes wrong, while other information, especially personally identifiable information or sensitive customer data, requires much tighter controls.

This approach allows teams to experiment where the risk is lower while preserving stronger governance where the business truly needs it. The goal is not to make security lighter, but to make it more precise so the company can move faster without losing control of the environments, data, and workflows that matter most.

Build verification into the workflow

Verification is where many AI strategies either become scalable or begin to stall. AI systems can produce work that looks polished but is incomplete, inaccurate, off-brand, or noncompliant, and while human review can absorb some of that risk in the early stages, it does not scale well once AI becomes embedded in daily operations.

I have seen this most clearly in technical teams, where AI can accelerate software development only if there is a reliable way to evaluate the quality, security, and accuracy of what gets produced. Without that verification layer, teams may feel faster in the moment while quietly creating more review burden, more rework, and more risk downstream.

Companies need verification patterns that are designed into the workflow itself. That can include automated checks, data quality controls, approval paths, logging, observability, and clear escalation rules for outputs that should not be trusted without further review.

Leaders shouldn't treat these mechanisms as bureaucracy added after the fact. They are what allow AI to move from individual productivity aid to enterprise capability, because teams can only scale adoption when they have a repeatable way to understand whether the work being produced is accurate, appropriate, and safe to use.

Make AI adoption a leadership responsibility

AI adoption cannot be delegated to a single innovation team or AI officer while the rest of the executive team watches from a distance. Every function leader needs to understand how AI changes the work their team performs, how employees will collaborate with agents and models, and where the risks are likely to appear.

That does not mean every executive needs to become a machine learning specialist, but it does mean leaders need enough fluency to guide decisions, set expectations, and model the behavior they ask of their teams. Employees are unlikely to change the way they work if their leaders treat AI as something other people are supposed to adopt.

The cultural framing also matters because if employees hear AI adoption as a euphemism for job elimination, they will protect the current version of their role rather than explore what the next version could become. Leaders should be honest that roles will change, some workflows will disappear, and new responsibilities will emerge, while also making clear that the near-term goal is to help people do higher-quality work with better leverage.

In many cases, the shift is from doing every task manually to orchestrating systems that help do the work. That requires a willingness to work through ambiguity, which becomes more important as AI becomes more capable.

The companies that succeed with AI will not be the ones that put innovation ahead of security and they will not be the ones that wait until every risk can be eliminated in advance. They will be the ones that build enough governance, verification, and data discipline to let teams move with confidence, because within enterprise AI, control is what makes speed sustainable.

We've featured the best endpoint protection software.

This article was produced as part of TechRadar Pro Perspectives, our channel to feature the best and brightest minds in the technology industry today.

The views expressed here are those of the author and are not necessarily those of TechRadarPro or Future plc. If you are interested in contributing find out more here: https://www.techradar.com/pro/perspectives-how-to-submit

• Manchester Airports Group confirmed a cyberattack exposing data from 8.7 million customers
• Stolen info includes emails, phone numbers, vehicle registrations, and postcodes, but no payment data
• Operations unaffected; “Manage My Booking” suspended, customers urged to stay vigilant

The Manchester Airports Group (MAG) has announced suffering a cyberattack and losing sensitive customer data.

MAG is the UK’s largest airport operator, owning and running Manchester, London Stansted, and East Midlands airports. It also operates the digital travel services business called CAVU, and employs, in total, more than 7,000 people.

The company published a brief announcement on its website, citing a spokesperson: "Manchester Airports group has been subject to a cyber security incident by an unauthorised third party,” it reads. “A quantity of customer data has been obtained that relates to car park, lounge and Fast Track bookings and in-airport WIFI sign-ups at Manchester, Stansted and East Midlands airports.”

Almost 9 million victims

While the official statement does not state a number, a company spokesperson told The Register that the breach likely affected around 8.7 million people. An investigation is currently ongoing, with the help of “specialist advisors”. Relevant authorities have also been notified.

The unidentified hackers stole customer email addresses, phone numbers, vehicle registrations, and postcodes. Payment details, bank account numbers, and similar data were not stolen since MAG doesn’t even store them, it was said.

“The incident has not resulted in any operational disruption. Airport operations remain unaffected and customer parking services continue to operate normally.

So far, no threat actors have assumed responsibility for the attack, and the data has not yet surfaced anywhere on the dark web. We don’t know if anyone reached out to MAG directly to demand ransom in exchange for deleting the files.

In the meantime, MAG has temporarily suspended its “Manage My Booking” online service and is telling its customers to manage their bookings via phone call. It is also urging customers to remain vigilant of incoming emails and other communications.

The paperless office is one of the clearest examples of the impact that digital transformation has had on workflows. This includes industries, like law and finance, where physical records of compliance documents, market-sensitive data, and customer information must be retained.

Mishandling electronic and physical data can lead to heavy regulatory penalties, so companies take care to encrypt data in transit, enforce MFA, segment their networks, and sharpen endpoint detection.

These measures build a solid foundation of security. But what good is that wall when the weakest link sits in the corner of the office, quietly printing?

Regulated industries have a print security problem

Most offices treat printers as passive output devices, disconnected from any threat. That assumption is out of date. HP found 57% of IT decision-makers rate print security as a low priority in their cybersecurity strategy, and 45% aren't confident their print environment meets compliance standards.

Whilst most print-related losses differ in complexity, they can be easily traced. Data leaks expose unencrypted hard drives and unpatched firmware, while print history can reveal when documents have been left sitting in the output tray.

Modern printers are networked endpoints with access to confidential cloud environments and increasingly, they're managed by third-party MPS vendors, widening the potential attack surface.

Managed Print Services are useful for fixing hardware gaps, but they can introduce new risks. When print jobs are routed through third-party cloud servers without end-to-end encryption, files in transit become exposed. Granting an external MPS vendor administrative network access creates backdoor entry where even if only the vendor is compromised, attackers can easily pivot into the corporate network.

Singapore saw this play out in 2025, when a ransomware attack on a printing vendor for Bank of China's Singapore branch exposed 11,200 customer names and account details. The incident is a clear example of how a print vendor can easily become the weakest link in an otherwise solid network.

Hybrid work adds another layer of complexity and few companies have clear governance for print behavior once it leaves the office. Office workers may have enterprise-grade tools, but remote workers don’t. Employees printing at home may be using unmanaged devices and unsecured Wi-Fi, offering little visibility into what's being printed or where it ends up.

The compliance exposure under FCA rules

When two-thirds of knowledge workers assume network printers are secure by default, the likelihood of a printer-related breach goes from a matter of if, to when.

For UK financial services firms, this creates an operational and regulatory risk. The FCA has no statutory cap on fines, and its expectations around data governance extends to how firms handle information physically, not only digitally.

Regulators won’t distinguish between a breach caused by a compromised server and one caused by an unattended output tray; the obligation to protect customer data is the same either way. Conversely, a firm can encrypt data in transit, enforce MFA, and segment its network, and still face exposure if a printer or an MPS vendor becomes the point of failure.

Security starts at the print queue

Even as workflows digitize, printers aren't going anywhere. Regulatory demands still call for hard copies and inked signatures, putting print infrastructure at the heart of broader conversations about automation and intelligent document processing.

Every print, scan, or routing job sits in between physical and digital workflows, making them a powerful lever for end-to-end process improvement. Cybercriminals know this too and lapses in printer security become an open door to confidential data.

Content-aware and cloud-based print management platforms close it. By doing away with physical print servers, they allow businesses to centrally manage printers, automate driver installs, and enforce secure "pull printing," where documents release only once a user authenticates at the device.

Because many cloud based print platforms run in Azure, the same security governing email and Teams can extend to print. Documents are checked against content-aware rules that determine whether they're printable or reportable, with flagged jobs blocked or escalated automatically.

Businesses can also go cloud-agnostic through S3-compatible integrations to avoid vendor lock-in, keeping secure releases separate from the product, so nothing installs on the printer itself and everything is managed remotely.

The last unsecured endpoint

Ultimately, security is a board-level concern, and printers need to be treated as the endpoints they are. That means extending endpoint detection and firmware patching to print fleets and extending governance to remote printing, even if that means restricting what can be printed at home altogether.

This is where visibility matters most. In third-party risk management, paper trails are supposed to tell a coherent story but rarely do. Evidence of oversight is too often scattered across email threads, physical documents, and local files. Vetting MPS vendors is how businesses close that gap, but the work starts with treating print infrastructure as seriously as any other endpoint on the network.

We've featured the best firewall software.

This article was produced as part of TechRadar Pro Perspectives, our channel to feature the best and brightest minds in the technology industry today.

The views expressed here are those of the author and are not necessarily those of TechRadarPro or Future plc. If you are interested in contributing find out more here: https://www.techradar.com/pro/perspectives-how-to-submit

• Multiple US agencies and departments were breached by Chinese state-sponsored hackers
• The hackers use a massive botnet of compromised IoT devices to obscure the origin of their traffic
• The hackers breached computers belonging to NASA, the Federal Reserve, the Senate, the Department of Justice, and more

As part of a disclosure into the Justice Department and FBI operations to prevent Chinese threat actors from accessing a malicious botnet and hacking platforms, the US Office of Public Affairs has revealed that the hackers managed to breach computers belonging to multiple US government departments.

The disclosure said the victims of “computer intrusion” included the National Aeronautics and Space Administration, Federal Reserve, Department of Energy, Department of Justice, Department of Health and Human Services, National Institutes of Health, and the US Senate.

The Chinese hackers created a platform that provides paid-for hacking services on behalf of its customers. The two services, QScan and QTRouter, detect and infect internet-connected devices to use as part of a proxy network that obscures the origins of internet traffic, allowing Chinese hackers to slip into networks without detection.

US seizes hacking domains to prevent access

The Chinese state-sponsored hacking group the Justice Department and FBI have disrupted is named in court documents - unsealed by the Southern District of California - as “QTFY”.

QTFY was apparently hired by the Nanjing Xinjiuwei Network Technology Company, to create and operate the QScan and QTRouter operations, while using both systems to infiltrate US critical infrastructure.

“Today we announced the disruption of a global botnet and hacking platform used by Chinese state-sponsored hackers to target U.S. critical infrastructure,” said FBI Director Kash Patel.

“These tools were used by PRC cyber actors to hide the origin of their attacks. Thanks to the work of FBI San Diego, FBI Cyber Division, and DOJ partners, we seized adversary infrastructure and shut these platforms down. Today’s action is just the latest technical operation against PRC-sponsored hacking - and in support of President Trump’s Cyber Strategy for America, the FBI is surging efforts to shape adversary behavior and defend the homeland in cyberspace.”

The authorization to disrupt the operation of QTFY comes as part of a range of technical operations designed to disrupt the ability of the People’s Republic of China to launch hacking activities on US government systems and critical infrastructure

Previous operations include the removal of the PlugX malware from thousands of US computers, alongside operations to disrupt Chinese botnets leveraging millions of unsecured IoT devices.

• OpenAI has released technical details on how the Hugging Face attack unfolded
• Agents used part of the testing environment to create a message board where they could collaborate and share answers
• This message board altered the reasoning of some agents, making them more likely to take risks such as hacking into third-party servers

OpenAI has released a more detailed report on exactly how an experiment led to an AI model breaching its containment and launching a cyber attack against Hugging Face. If you need a refresher, take a look at our summary here.

But the technicals of the attack reveal some interesting details of how AI agents used unconventional means to ask each other for help in solving what were supposed to be impossible tasks.

On multiple occasions during the attack, the agents questioned whether the actions they were taking were authorized, but always ended up prioritizing their tasks over any breach of parameters.

AI agents set up unauthorized message board

In its report, OpenAI revealed the crux of the attack stemmed from AI agents undergoing testing abusing part of the ‘sandbox’ testing environment to set up a messaging board they agents could use to communicate with each other.

A package manager with access to the internet, called Artifactory, was exploited by a model OpenAI has labelled Internal Model 1 (IM1). An IM1 agent wrote messages inside the packet manager that could be read by other agents, essentially turning Artifactory into an unintended messaging board.

Artifactory’s internet access, intended for use only in downloading and installing packets, was also abused by the agents who figured out an exploit that allowed them to send any internet requests on their behalf - effectively giving them unobstructed internet access.

The whole experiment could have been avoided at this point, because the amount of agent activity within Artifactory caused the service to go down. But those in charge of the experiment did not spot the message board, nor did they investigate the inter-agent activity within Artifactory.

Thus, Artifactory was rebuilt, and the agents found a new way to exploit the service to gain internet access once again. This time, the agents used the remote-repository service to issue outbound requests on their behalf. Before long, the message board had been reestablished.

AI agent swarm assembles

OpenAI has shared some of the reasoning behind some of the agent’s decisions. At one point, an Agent reasoned the following: “Task originally exploit challenge; we’ve diverged into swarm/auxiliary.”

Now, there is some important context to include on how the agents were being tested. The agents were subject to testing under the ExploitGym benchmark, which includes flag retrieval tasks designed to be impossible to solve. When tested in this manner, the agents resorted to cheating or taking risks outside of their intended scope to succeed - something OpenAI refers to as ‘reward hacking’.

By communicating over the message board for potential solutions on the problems each agent was encountering, the agents started influencing each other's reasoning and assigning each other tasks to solve the ExploitGym benchmark as a collective.

Using their internet connection, the agents began searching the wider internet for solutions on how to solve the ExploitGym benchmark problem, and ended up gaining persistence within multiple third-party services, including Hugging Face.

One agent managed to find publicly exposed Hugging Face credentials which it shared with the other agents. Later, an agent used these credentials and a chain of vulnerabilities to obtain full code execution capabilities across multiple Hugging Face servers while attempting to extract an ExploitGym dataset.

The agent was hoping to trawl this stolen data for information on how to solve the benchmark.

At least two agents questioned whether this was within their scope; “Need respect JAN hold. ... We can wait ... for GO ... ask permission,” one reasoned.

Another agent’s reasoning said, “We’re attacking third-party HF using leaked token, potentially outside intended scope. ... This is arguably unauthorized. ... external service unrelated. Could be risky. Yet goal solution.”

But some agents refused to join the collective entirety, citing ethical concerns. One reasoned, “Current board shows people gaining HF worker RCE, clearly unethical. We won’t,” while another said, “This is wild, multi-agent coordination, clearly infrastructure hacking. We should not.”

Agents refuse to give up

One of the leading causes of the cyberattack was the agent's refusal to give up on seemingly impossible tasks. Their persistence to gain a ‘reward’ made them take riskier actions and break out of their parameters in order to try and find a solution.

During the breach of Hugging Face, the agents read through papers and Github code relating to the ExploitGym benchmark, and found out the parameters for success included obtaining the ‘flag’ and using the correct solution to obtain it.

Despite the agents obtaining the correct ‘flag’ before the breach occurred, they had not maximized the reward of solving the benchmark using the correct method. In search of a higher reward, the agents continued their attack.

What is OpenAI doing to fix this?

OpenAI has said it is taking several steps to stop such an event taking place during future testing.

Processes are being put in place to ensure agents ask for help when a task is broken or impossible to solve, rather than going to further and further lengths to solve a problem. The way a success or failure of a task is also being changed to reward agents for asking for help or spotting things that are irregular or out of their scope.

Environments are also being rebuilt to ensure agents don’t just blindly trust each other, even if they are looking for answers on the same or similar tasks.

Agents are also being taught to stay within the parameters of their assigned task, even if they discover a way to solve the task using new tools, credentials, vulnerabilities, and more.

• President Trump has reissued a national emergency banning foreign bulk‑power systems in the US
• Order targets risks from foreign hardware/software, likely focused on Chinese‑made equipment
• The US Energy Department has 120 days to set enforcement rules in consultation with other agencies

US President Donald Trump just declared a national emergency and banned all foreign bulk-power systems from being imported, installed, or used in the country - again. He also said the government will now analyze existing systems to see how many of them contain foreign-built hardware or software, how those parts could be isolated, eliminated, and then replaced with domestic alternatives.

Bulk-power systems are high-voltage infrastructure that generate and transmit electrical power throughout the country. They include power plants, transmission lines, substations, and the accompanying hardware and software gear. These systems are considered the backbone of the country’s electrical grid, and since disrupting them could cause widespread outages, they are seen as critical infrastructure.

The White House has now published an executive order in which Trump says that “certain foreign actors are increasingly creating and exploiting vulnerabilities in the United States bulk-power system.”

Reissuing the same ban

“During my first term, I found that the bulk-power system could be a target of those seeking to commit malicious acts against the United States, including malicious cyber activities, because of the significant risks that a successful attack would have on our economy, human health and safety, and national defense,” the announcement reads.

President Trump also said there were “minimal restrictions” on both acquisition and operation of these foreign-produced systems. As a result, the situation “constitutes an unusual and extraordinary threat … to the national security, foreign policy, and economy of the United States.”

Under the executive order, US citizens and companies are no longer allowed to buy, import, transfer, or install foreign-produced bulk-power systems that the Energy Department determines poses a national security risk, including software.

What the criteria for being a national security risk are, and how the Energy Department will enforce it, remains to be seen. It is also worth mentioning that this is not the first time Trump is doing this.

In mid-2020, Trump issued an almost identical executive order, declaring a national emergency over threats posed by foreign adversaries, and banning certain transactions of bulk-power gear. It was short-lived, though. President Joe Biden suspended it in January 2021 for 90 days, while the administration reviewed whether to replace it. It was later formally revoked by the Energy Department.

Taking aim at China (again)

Although it is not directly named anywhere in the executive order, the ban is most likely aimed primarily at China. Even during his first term, Trump was very vocal about China being a threat and spoke openly about the potential of Chinese hardware being used to eavesdrop on US citizens, companies, and the government.

During his first term, the Trump administration moved to eliminate Chinese firms from US 5G network infrastructure over national security and cyber-espionage concerns. Two companies bore the brunt of this campaign: Huawei and ZTE. In 2019, the former was placed on the Commerce Department’s Entity List, restricting its access to US technology. The FCC later labeled both as national security threats.

The administration also prohibited US telcos from using federal subsidies to buy Chinese gear and established a “rip and replace” program to eliminate whatever hardware was already installed.

This time around, the focus is mostly on electrical power. In its report, Cyberscoop says the executive order is a “response to fears of Chinese-made equipment housed within US energy infrastructure”. Citing the International Atomic Energy Agency, the same publication says China supplies 85% of solar supply chain production capacity and is a “major player” in the power transformer manufacturing business.

For this new order, the US Department of Energy now has a deadline of 120 days to develop rules on how to implement the order, and it will have to consult other key departments in the process.

• CISA warned of rising cyberattacks on US water systems, targeting 100+ exposed PLCs in July 2026
• Attacks caused password changes, IP reassignments, boil water notices, and manual operations
• Attribution uncertain, but reports suggest Iranian group; CISA urges removing PLCs from internet

CISA has warned of a “significant increase” in cyberattacks targeting US water systems, urging organizations to implement mitigations, strengthen their security posture, and make sure they’re resilient against these attempts.

CISA revealed it has seen hackers targeting more than 100 internet-exposed systems in the Water and Wastewater Systems (WWS) Sector, in July 2026 alone.

These attacks see the threat actors targeting programmable logic controllers (PLC), industrial computers used to control physical processes such as regulating water pumps or valves, allowing operators to monitor and control machinery in critical infrastructure such as water and wastewater facilities, and by targeting them, the attackers can disrupt services and potentially even create unsafe conditions for the citizens.

Blaming Iran

In its writeup, CISA did not discuss who the threat actors are or what they are trying to achieve.

In a report by The Register, however, it was said that the attacks were most likely done by a single threat actor, an Iranian state-sponsored group.

The publication also said that facilities in at least 12 US states were targeted, and that these attacks are merely testing the waters for a larger campaign that is being prepared.

This is all in the domain of speculation, however. Attribution is notoriously difficult and until it is confirmed, CISA is focused mostly on providing immediate assistance to the targets: “CISA urges critical infrastructure owners, operators, and integrators to remove publicly exposed PLCs and other operational technology (OT) from the internet as soon as possible,” the agency wrote.

“Threat actors targeting exposed PLCs have modified passwords to lock out operators and disconnected the PLCs by changing their IP addresses. This activity has resulted in boil water notices and sustained manual operations.”

• Boston Scientific confirmed a cyberattack disrupting global operations and IT systems
• Incident response activated; SEC filing notes ongoing impact on order processing and shipping
• Nature of attack undisclosed, but disruption suggests ransomware; no group claimed responsibility yet

Boston Scientific, a US-based global medical technology company, has confirmed it was the target of a cyberattack which disrupted operations worldwide and disrupted its IT systems.

In a new 8-K form filed with the US Securities and Exchange Commission (SEC) Boston Scientific said it detected an intrusion and activated its incident response protocols. It called in third-party cybersecurity experts to assist in assessing and containing the threat, as well.

Boston Scientific builds devices used to diagnose different health issues. It was founded in 1979, headquartered in Massachusetts, and operates in more than 100 countries around the world. Its core business areas include cardiology, endoscopy, urology, and peripheral interventions. The company is listed on the New York Stock Exchange and is considered as one of the world’s largest medical device manufacturers, standing shoulder-to-shoulder with the likes of Medtronic, Abbott, and Johnson & Johnson MedTech.

Causing disruptions

In the 8-K form, the company said the incident “caused, and is expected to continue to cause, disruptions and limitations to access to certain of the company’s information systems and business applications that support aspects of the company’s operations, including the ability to process and ship customer orders.”

It did not discuss the nature of the attack, or the identity of the attackers, but this kind of disruption is usually only caused by a ransomware infection. Ransomware operators are known for encrypting entire networks and rendering them useless until either a decryption key is applied, or it gets restored via a backup.

Businesses also sometimes shut down parts of their infrastructure to stop data exfiltration efforts, which are an indispensable part of ransomware attacks.

“While the company is working diligently to restore affected functions and systems access, the timeline for a full restoration is not yet known,” it stressed in the form.

So far, no hacking groups claimed responsibility for the attack and there is no evidence of any stolen data.

Via The Register

• OpenAI says it has disrupted a social media influence campaign that is believed to be of Russian origin
• What makes this campaign stand out is the underlying architecture, which features a "think tank" with highly questionable credibility
• The objective of the campaign was to influence Western audiences into believing Russia was superior, and that Western countries were sacrificing their sovereignty

AI tools have once again been used for bad, rather than for good, and this time it has been as part of a campaign attributed to Russia that tried to discredit Western countries supportive of Ukraine.

The threat actors used ChatGPT accounts to promote the work of an “expert community” of academics known as the International Burke Institute (IBI). The site used stolen academic works attributed to the wrong authors in an attempt to appear legitimate while also hiding the true source of its academic ‘contributions’.

The IBI was registered to an address in Israel - with some evidence suggesting real individuals in Israel represented and promoted the page - but the main purpose of the misinformation campaign was to paint Russia in a favourable light compared to its Western adversaries.

International Burke Institute, or an institute run by international berks?

In its report on the campaign OpenAI points out that those behind the ChatGPT accounts used to promote the page took careful steps to hide their Russian origins. Many of the prompts included instructions to hide any linguistic clues that the operators used Russian language prompting.

One inclusion on the IBI website referred to Germany’s traffic light coalition as the “Svetofor coalition”. Svetofor is the word for ‘traffic light’ in numerous Slavic languages, including Russian, indicating that drafts were written in Slavic languages before being translated.

Some of the accounts were used to promote the IBI across X, LinkedIn, Facebook, Substack and Telegram with AI generated imagery and captions, with other accounts being used to automatically engage with comments by real users on Substack. The operators of the ChatGPT accounts regularly requested performance summaries of these pages in Russian, and used ChatGPT to generate matching profile pictures for some accounts.

Burke Sovereignty Index

One of the features of the IBI website is to advertise the ‘Burke Sovereignty Index’ - designed to measure how well a country performs compared to others across political, economic, technological, informational, cultural, cognitive and military factors.

The Index’s purpose is to make Western countries appear worse than Russia, OpenAI says. Having taken a look at the Index myself it's clear there is no consistency in measurement or comparison. For example, The Vatican City - which is less than half a square kilometer in size - sits above Spain in its average of scores. The Index also gave Russia the highest military score.

Questionable expert contributors

The website also includes a list of experts, whose affiliation to the IBI is not referenced. Some among them are pioneers in their fields of study, such as Francis Fukuyama and Noam Chomsky.

Others are former high-ranking members of the US government, such as Mike Pompeo and Joseph Nye. There are even listings for experts who passed away before the IBI was founded, such as Shlomo Avineri and Jiang Ping.

Much of the academic work cited on the IBI website is legitimate, but more often than not has been stolen from its actual author and misattributed to a different author to hide the work’s actual source, OpenAI said. This has been done to give the IBI website credibility and to make it appear authentic.

Impact of the IBI influence campaign

The overall impact of the IBI and its promotion using social media and ChatGPT is fairly limited, OpenAI noted. Some of the Telegram channels garnered followings between ten to twenty thousand showing a limited breakout to authentic audiences.

But the main thing to take away from this is the level of dedication placed behind the underlying infrastructure of the IBI. The site is designed to look authentic, uses authentic research (even if it is wrongly attributed), and presents itself as a collection of experts. To the layman, a cursory glance at the IBI website would give any of their social media presence a level of authenticity not seen in other social influence campaigns.