Microsoft is taking a new approach to fighting cybercrime, targeting the cyberattack supply chain, not just individual services. In a case unsealed today, we are simultaneously targeting two widely used cybercrime tools, Amadey and StealC, after AI-assisted analysis revealed they rely on the same infrastructure.

This action goes after the cybercrime “assembly line,” where coordinated tools drive ransomware, financial fraud, and disruptions to public services. Amadey and StealC are often used alongside each other: Amadey helps attackers gain access to devices, while StealC steals passwords and sensitive information. Together, they form a critical link in the chain. In the first two weeks of May alone, Amadey and StealC were linked to more than 140,000 infected computers globally, highlighting how widely they are used.

Working with Europol and industry partners, we targeted both tools at once. The goal: break the chain. Since the start of the operation, Microsoft has identified more than 18,000 victim computers, severed criminal control of those devices, and is working with telecommunications providers to help protect affected customers globally.

When multiple parts of an operation are disrupted together, attacks are harder to launch, scale, and recover from. The result: fewer disrupted services, fewer opportunities for cybercriminals to profit, and more friction when they try to rebuild.

It’s no longer enough to go after threats one by one. We need to interrupt how the attacks are put together. 

What’s different about this action   

Microsoft has long used civil legal action to disrupt cybercriminal infrastructure and pioneered the innovative use of existing laws, including the Racketeer Influenced and Corrupt Organizations Act (RICO), a US law designed to target organized crime.

What’s new is how we’re combining AI analysis with an expanded use of that law.

Amadey and StealC were developed by separate cybercriminals, but they relied on the same infrastructure. To understand how they worked, investigators used AI, including Copilot, to quickly analyze the malware, asking questions in plain English instead of manually combing through complex code. That helped surface key details, uncover hidden data, and test findings in a fraction of the time, turning what would have taken hours or days into minutes and enabling the team to spot connections faster.

Those insights allowed the legal team to treat both malware families as part of a single conspiracy. Instead of going after each tool separately, as we have done in the past, we used RICO to charge multiple complicit enablers involved across the operation. In total, Microsoft’s Digital Crimes Unit disrupted over 200 command-and-control servers—the systems criminals use to control infected devices, steal data, and keep attacks running.

By targeting tools together, we can disrupt the cybercrime chain more efficiently and more effectively, in a way that better reflects how these networks actually operate today.

Cybercrime now runs like an assembly line 

Cybercrime is no longer a series of isolated attacks—it’s a coordinated system.

Specialized tools handle each step: one gains access, another steals credentials, and others sell or exploit that access for fraud, ransomware, espionage, or other nefarious purposes. Different actors may be involved at each stage, but together they turn access into profit, quickly and at scale.

That structure also creates a point of vulnerability. The people behind these cybercriminal tools may never interact directly, but their tools are designed to work together. If those connections can be identified, multiple stages of an attack can be disrupted at once.

How these attacks play out in the real world 

Most people will never hear the names Amadey or StealC, but they feel the effects. A hospital locked out of critical systems. A city unable to deliver essential services. A small business losing access to accounts overnight. A retiree who lost their life savings.

These attacks don’t happen all at once. They unfold step by step: attackers get in, passwords are stolen, access is reused or sold, and sometimes repurposed for more targeted operations. For example, Microsoft has observed Russian-affiliated actor Secret Blizzard leveraging Amadey infections to deploy custom malware against targets in Ukraine.

By targeting multiple points in that chain at once, we reduce the chance that a single compromise turns into widespread harm. Put simply: fewer attacks succeed and fewer people feel the impact when they do.

No one organization can do this alone 

Actions like this underscore a fundamental reality: we’re successful when we collaborate. No single organization, whether government or industry, has full visibility into how cyber threats operate across borders and sectors. What makes this effort effective is the combination of perspectives and data.

Microsoft had been tracking Amadey due to its impact on customers, working with cybersecurity partners ESET, BitSight, Lumen, and Mitsui Bussan Secure Directions (MBSD) to better understand how it operated. At the same time, Europol’s European Cybercrime Centre (EC3), together with European law enforcement partners including Germany’s Federal Criminal Police Office and the Dutch and Danish National Police, was investigating StealC as part of Operation Endgame, alongside IBM X-Force and Proofpoint.

Bringing those efforts together expanded our collective datasets and made it possible to identify the connections between the two tools and act on them quickly. That shared understanding enabled a coordinated response that went further than any single organization could achieve alone.

 

This shows why partnerships matter. Industry shares technical insight, government brings visibility, and we need trusted ways to exchange that information. Only by working from the same picture can we stay ahead of attackers, disrupting not just individual tools but also the systems that make cybercrime possible.

Creating sustained pressure on cybercrime  

This work doesn’t end with a single action. Cybercriminals adapt quickly, which is why we continue tracking how these operations evolve and working with partners to disrupt them.

Microsoft’s court-authorized disruption in this case is paired with ongoing efforts to track how cybercriminals rebuild, identify new infrastructure, and work with partners to disrupt the services they rely on to operate. It also includes incorporating the findings from this disruption into initiatives like Microsoft’s Statutory Automated Disruption program, which helps accelerate the removal of malicious domains and infrastructure.

The goal is not just to stop one operation but to slow the system itself—making attacks harder to launch, scale, and recover from. By combining AI-driven insight, legal action, and strong partnerships, we can continue to raise the cost of cybercrime and reduce its impact.

For more than a decade, Microsoft’s Digital Crimes Unit (DCU) has worked to disrupt cybercrime and nation-state threats, filing around 40 cases since 2008 and partnering with law enforcement to take down criminal networks. Learn more about the team’s efforts here.

 

The post Scaling cybercrime disruption through innovation and AI appeared first on Microsoft On the Issues.

For the past four years, a sprawling Android-based botnet called Popa has forced millions of consumer TV boxes to relay Internet traffic linked to advertising fraud, account takeovers, and mass data-scraping efforts. This week, researchers from multiple security firms concluded that the Popa botnet is linked to NetNut, a “residential proxy” provider operated by the publicly-traded Israeli firm Alarum Technologies Ltd [NASDAQ: ALAR].

Popa is a massive botnet, but by all accounts it is unlike traditional botnets that enlist compromised systems in destructive activities, such as coordinating huge distributed denial-of-service attacks. Rather, Popa appears designed with a singular purpose: Implementing a persistent communications layer capable of registering a device, maintaining long-lived encrypted connections, and opening communication tunnels on demand.

Experts say Popa is a plugin component associated with the Vo1d botnet, a large-scale malware campaign targeting unofficial Android-based TV boxes. These devices, which are marketed under thousands of brand names and model numbers and broadly available for purchase at top e-commerce destinations, all advertise the ability to stream hundreds of subscription video services for an up front one-time fee.

But as the FBI and security industry experts have warned repeatedly, these streaming boxes typically bundle or come pre-installed with software that turns the user’s TV into a “residential proxy” — allowing anyone to route their Internet traffic through that device for as long as it remains plugged into a wall socket and connected to a local network. More concerning, some of these proxy networks do little to stop malicious customers from communicating with and even compromising systems on the local network of the unsuspecting device owner.

The first clues about Popa’s origins came in a 2025 report from the Chinese security company XLAB, which flagged at least nine domain names that were used to register and direct the activities of compromised devices. In a report released today, the security firm Qurium described how it stumbled on some of those same domains while investigating a series of disruptive and expensive data scraping events targeting the company’s hosted organizations in May 2026, in which the scraping activity was scattered evenly across more than 1.4 million Internet addresses.

Qurium said it found several dozen domains used to control Popa that were all hosted in lockstep across multiple Internet addresses over time, including gmslb[.]net, safernetwork[.]io, tera-home[.]com, and ninjatech[.]io. Digging deeper, Qurium discovered gmslb[.]net was referenced in dozens of pirated or modded video content streaming apps, such as CRICFy, DooFlix, Sprozfy, RTS Tv, Flixoid, CyberFlix, Rapid Streamz, TvMob and HD/OceanStreams.

Qurium’s report notes that most of the domains long used to control the Popa botnet were seized or dismantled in July 2025, after Google, HUMAN Security and Trend Micro teamed up to disrupt Badbox 2.0, a botnet that is closely associated with Vo1d. Qurium said that immediately after that disruption, several dozen new domains were registered to serve as controllers for the Popa botnet, but that one of those control domains was not new: ninjatech[.]io.

Ninjatech is a company founded by Moishi Kramer, whose LinkedIn profile says he is vice president of research and development at NetNut. That resume credits Kramer for helping NetNut to build from the “ground up,” “designing the architecture,” and “scaling the NetNut” before the company was acquired by Alarum Technologies. A self-created listing at the job board F6S references Kramer as the sole owner of the Ninjatech domain (a screen capture of it is pictured below).

Responding via email, Mr. Kramer said Ninjatech ceased operations approximately five years ago, when the company sold a software development kit (SDK) called Popa that was designed to use a small portion of a device’s bandwidth and to run only after the host application obtained user consent.

“That code was sold and licensed to third parties including resellers years ago,” Kramer said. “Once software is distributed that way, the original developer has no control over how others later modify, rebrand, or deploy it.”

Kramer said neither he nor NetNut builds, operates or maintains the infrastructure being described as Popa, nor does he control the Ninjatech domain.

“I didn’t register the June 2025 domains you mention, and I don’t know who did,” he continued. “I have no control over, or visibility into, that infrastructure. I can only tell you it isn’t operated by me or by NetNut.”

But in a separate Popa research report released today, the proxy-tracking company Synthient said a recent analysis of the Popa SDK revealed outbound traffic clearly associated with NetNut.

“The research team assesses with high confidence that devices running Popa forward traffic from Netnut clients,” Synthient wrote. “This proves without a shadow of a doubt that Popa actively continues to be used by NetNut as part of their proxy pool.”

Alarum Technologies, NetNut’s Tel Aviv-based parent company, said the reports by Synthient and Qurium contained “demonstrably inaccurate assertions and flawed deductions rather than verified facts.” Alarum shared a statement saying they reject the basic characterization of the SDKs and technologies discussed in the reports as a “botnet.”

“The SDKs at issue are designed to facilitate bandwidth-sharing functionality and do not transform user devices into malware-controlled systems or otherwise compromise the devices on which they operate,” the statement reads. “Netnut operates a commercial proxy network and maintains policies, procedures, and technological measures designed to promote lawful and responsible use of its services.”

Alarum said NetNut places “significant emphasis on appropriate notice and consent mechanisms, conducts customer due diligence, monitors for potential misuse, and takes steps intended to detect and mitigate suspicious or unauthorized activity.”

“This method of operation is supported both by internal procedures and policies, including performing KYC checks and additional due diligence of NetNut’s customers, as well as employing various technological measures, designed to assist in identifying and addressing suspected misuse of the network,” their statement continued.

However, in a report released on June 8, the proxy tracking service Spur asserted that NetNut does not require corporate verification or meaningful “know your customer” procedures before allowing customers to purchase proxy access.

“An individual can sign up, pay, and route traffic through partner address space, including space belonging to institutions whose users never opted in,” Spur wrote. “The ‘verified corporations only’ claim is simply marketing for bandwidth sellers, not an access control on who actually uses the proxies.”

“Nor is NetNut the only front door,” Spur continued. “A number of downstream white labelers and resellers repackage the same ISP proxy pool under their own brands. These outlets typically perform no KYC at all, less scrutiny than NetNut itself, who at the very least might assign an account manager to potential users. Anyone who knows where to look can buy access through a reseller with nothing more than a burner email address and $5 in crypto.”

Synthient found that although the most recent builds of Popa (as of three months ago) have added the ability to ask the user for consent before installing proxy components, not all variants or previous versions of Popa contain this functionality.

“Of the over 20 genuine Popa publishers analyzed, none of them were observed asking for user consent,” Sythient wrote.

THE PREVALENCE OF POPA

Chris Formosa is senior lead information security engineer for Black Lotus Labs, a division of the Internet backbone carrier Lumen Technologies.

“What especially makes Popa dangerous is just how widely used NetNut is for reselling and sharing,” Formosa said, explaining that many other proxy services simply resell NetNut proxies rather than building out their own far-flung proxy networks. “So these Popa IPs appear in tons of different services all over the ecosystem, which makes it one of the most problematic and dangerous proxy botnets on the market currently.”

Formosa said the Popa botnet averages between 1.5 million to 2.5 million distinct IP addresses each day, relying on between 250 and 300 Internet addresses that are used to direct its activities.

“That’s why Popa is so dangerous,” Formosa said. “It may not be the largest botnet we have seen, but it is spread all over the industry, making its power very amplified.”

Formosa said while that makes Popa one of the larger botnets out there today, its numbers pale in comparison to those previously boasted by IPIDEA, a China-based proxy provider that until recently operated a daily pool of nearly 10 million devices that they resold as proxies to anyone. In January 2026, Synthient published research showing that multiple new large DDoS botnets had grown rapidly by tunneling through IPIDEA proxies into the local networks of unsuspecting TV box owners and infecting other Android-based devices behind the user’s firewall.

IPIDEA is based largely on SDKs used to view pirated streaming content on a vast number of TV box devices, but the service’s numbers have dwindled since January, when Google and industry partners took legal action to seize domain names that IPIDEA used to control devices and proxy traffic through them.

Jérôme Meyer, a security researcher at Nokia Deepfield, said the total population of devices participating in the Popa botnet may be far higher than Lumen’s estimates. Meyer told KrebsOnSecurity that Nokia is monitoring 26 of at least 359 known relay nodes for the botnet, and estimates that each relay node handles between 35,000 and 60,000 clients simultaneously.

“On the relay node subset I am looking at (26 of them), 750,000 unique sources in 24 hours,” Meyer wrote in response to questions.

Nokia Deepfield released its own report today on RoboVPN, a VPN app tied to the Vo1d botnet’s Popa plugin that Qurium attributes to NetNut/Alarum Technologies.

THE SYMBIOSIS OF PROXIES AND DATA SCRAPING

Experts say many of the world’s largest proxy providers have updated their public-facing branding to highlight their utility for training AI platforms, implying it is a primary use case for their residential proxies. That’s because AI services tend to rely on constantly mass-scraping the Internet for new text, images and video content that can be used to train large language models (LLMs).

“AI companies depend on web-scraped content: for pre-training, for retrieval, for agent grounding, for search,” reads a report this month from Include Security that examines the prevalence of proxy SDKs in smart TV apps. “But the modern web isn’t scrapeable from a datacenter. Cloudflare, DataDome, HUMAN, among others throttle or block requests from known cloud IPs. The workaround is residential proxies. A scraping job routed through a Comcast or T-Mobile subscriber’s connection arrives at the target site from an IP that belongs to a paying residential customer.”

This non-stop content scraping has spawned more than 70 copyright infringement lawsuits against major tech companies that have acknowledged large-scale data scraping as a major source of the “brains” behind their commercial AI offerings. Ironically, much of that scraping is being aided by proxy services that are intimately tied to unofficial Android TV boxes and associated SDKs whose stated purpose is streaming pirated content.

The scraping activity has become so aggressive that it often overwhelms the targeted websites, preventing them from being reachable by legitimate visitors. In many reported cases, nonprofit organizations, libraries and universities have complained of constantly battling to keep their services online in the face of relentless data-scraping firms hiding behind residential proxy services.

A survey conducted last year by the Confederation of Open Access Repositories (COAR) found while some content scraping bots are rather innocuous, “others are sufficiently aggressive that they are increasingly causing service disruptions in repositories and other scholarly communications infrastructures.” More than 90 percent of survey respondents indicated their repository is encountering aggressive bots, usually more than once a week, and often leading to slow downs and service outages.

“Automated web scraping is nothing new, and has been the key technology underlying search engines such as Google for over 30 years,” wrote Brendan O’Connell, platform manager at the Directory of Open Access Journals (DOAJ), a free, community-curated index of peer-reviewed academic journals. “However, the current investor-fueled AI startup craze means there are now thousands of well-funded companies developing and deploying their own scraping tools to train AI models, alongside existing major players like OpenAI and Google.”

DON’T TOUCH THAT DIAL!

Across the United States, local communities are pushing back against the proliferation of new data centers aimed primarily at improving the capabilities of AI. But security experts say the general public remains largely unaware that using one of these unsanctioned Android TV boxes means their “smart TV” is almost certainly using a significant amount of bandwidth each month to help train modern AI models.

Even households without these sketchy TV boxes can still have their smart TVs turned into residential proxy nodes, just by downloading one of thousands of apps made available on Samsung and LG smart TVs. Spur said it recently scraped the LG and Samsung app stores and found that each had approximately 3,000 apps available for download. Many of these apps are simple games or utilities that state in the fine print that the user’s Internet connection will be used to download data and that they can opt out at any time.

Spur said it found that more than 42 percent of apps available for download via the webOS operating system on LG smart TVs include SDKs that turn one’s television into an always-on residential proxy node. More than a quarter of the apps made for Samsung’s Tizen operating system had similar residential proxy components, Spur found.

Experts say it’s questionable whether TV apps with proxy SDKs can obtain meaningful consent from users for installing an always-on proxy connection, particularly when anyone in a household — including children — can effectively opt the family TV into a residential proxy network just by installing a simple game or app.

“Privacy-policy disclosure is the wrong control surface for a TV,” Include Security wrote. “It is hard to scroll through a legal document navigated by arrow keys on a remote, and the in-app consent dialog doesn’t convey that a paying customer is about to route their scraping traffic through the user’s home internet.”

Spur’s head of research Sean Simmons told KrebsOnSecurity that most people do not have a working mental model for what it means to sell access to their residential IP address, no matter what device they are using.

“And on a TV, the gap is even wider,” Simmons said. “A one-time prompt navigated with a remote can disappear into the setup flow, while the app keeps monetizing the connection long after anyone remembers what they accepted.”

Simmons said LG and Samsung should follow the lead of other TV platforms that have already drawn a line against residential proxy providers, pointing to policies by Amazon that prohibit apps facilitating proxy services for third parties. Likewise the TV streaming device maker Roku reportedly now bars developers from using proxy SDKs and has removed apps that bundled them.

Apps that turn one’s device into a residential proxy node are not limited to smart TVs and no-name streaming boxes, of course. As noted by the security firm Infoblox, mobile app developers can embed SDKs provided by the residential proxy networks into their products to monetize their software, allowing them to receive a small amount of money on each installation.

The result, Infoblox said, is that devices are frequently enrolled without the owner’s knowledge, typically through free applications such as VPNs, streaming apps, screensavers and “productivity” apps such as PDF viewers and break reminders.

All too often, these proxy services are beaconing out from employee devices brought into the workplace, Infoblox found. In a blog post earlier this month, Infoblox said it discovered that fully 65% of its customer base was querying one or more residential proxy related domains.

“We saw steady growth in these queries in 2025, with a 25% increase over the year to over 500 billion per month,” Infoblox wrote. “Over 90% of our pharmaceutical and food & beverage customers have queried residential proxy indicators. Perhaps even more concerning is that over 60% of government and banking customers have as well.”

Infoblox researchers Nick Sundvall and David Brunsdon warned that with residential proxies in the corporate environment, external access is granted to an organization’s IP space.

“If threat actors were to abuse the residential proxy to attack a third party, the third party’s incident response would, correctly, identify your residential proxy as the source,” they wrote. “Untangling that, by proving that you were the conduit and not the threat actor, costs time, creates legal exposure, and can damage your reputation. The stunning prevalence of these services within customer environments warrants attention from both network defenders and policy makers who should consider how the risks posed by residential proxies could be impacting their security posture.”

Last week, national security agencies from the Five Eyes—that’s the rich, English-language-speaking countries club—jointly released a statement warning of the increasing cyber risks of AI models: in particular, their ability to autonomously hack into systems and networks. The statement was more measured than some of the breathless headlines about it, and the advice they gave is pretty much the standard advice everyone gives—albeit with newfound urgency.

Internet risks are nothing new, and cyberattacks—both large and small—have been a significant issue since long before the current crop of generative AI models.

What’s been changing over the decades, and what AI is changing even faster, is the gap between skill and ability. For most of human history, the two terms were synonymous—but computers have decoupled them. As the gap between the two expands, humans empowered with these AI tools can do more: more writing, more research, more analysis and also more damage than ever before. These models can, with little detailed direction, autonomously hack into networks, steal data, deploy ransomware and destroy systems. And to the extent there is a solution, it’s going to involve harnessing AI for the defense.

In 1998, seven people from the hacker group L0pht testified before Congress. They told a mostly clueless Senate committee that they could take down the internet in 30 minutes. That was partly real and partly bravado, but it illustrates an important point: hacking into systems, stealing data and causing damage all required skill.

Contrast the L0pht hackers with hackers derided as “script kiddies.” They didn’t understand computers, or security. Instead, they used hacker tools written by others. Their actions required minimal skill and even less knowledge. But once those hacking tools became widespread, the number of potential attackers increased.

That number has continued to increase, as quality and availability of prewritten attack tools has grown. And it is growing dramatically with AI. Today’s AI systems—not just the frontier models, but most of them—are capable of carrying out cyberattacks automatically. They all do better in the hands of skilled attackers, but increasingly they are able to act autonomously with only minimal prompting.

The thing about people with ability but no skill is that they are often outsiders, not part of any professional community, and not bound by any rules or norms. This phenomenon is much more general than in cybersecurity. Any doctor can tell you how to untraceably poison someone, and many virus researchers know how to create a bioweapon. Any bridge engineer can tell you how to place explosives to blow a bridge up. The reason that murderous doctors and terrorist engineers are so rare is that the lengthy process of acquiring those skills also instills a moral and ethical code. If every random person has access to good poisoning advice, that puts us all in danger.

Modern AI systems are, in effect, a universal adviser to help people do harmful things. And while the current AI megacorporations are trying to build guardrails to prevent people from asking questions whose answers will enable the questioner to do harm, that’s not going to work in the long term. Smaller, cheaper, open-source models, including models that can run on people’s computers, and especially groups of models that run in concert with each other, are just as good as the frontier models from companies like OpenAI and Anthropic. And they continue to get better. These models will be passed around from person to person, like script kiddie hacker tools, and they won’t have any such guardrails.

Instructing AI models to spy on people and report any malicious prompts to the authorities fails for similar reasons. The megacorporations can do that, but the locally run open source models won’t. This could buy us a few months at best.

A third possibility is to somehow make the models themselves unable to hack into computers, create bioweapons or do anything else that might harm people or society. That won’t work, for the same reason we can’t teach doctors how to treat poisonings without also teaching them how to poison. It’s the same knowledge. It’s the same with construction and demolition. And it’s the same with cybersecurity. We want these AI models to be able to review computer code, find vulnerabilities and automatically fix them. The benefit to our collective security will be enormous. Unfortunately, the same knowledge can be used for attacks.

Where this leaves us is in a world of increased volatility. Super-powered humans with AI assistants will be able to do both wonderful and horrible things.

This brings us back to the Five Eyes statement. Everything they recommend is something security professionals have been recommending for years, if not decades. They are things talked about at that congressional hearing back in 1998, titled “Weak computer security in government: Is the public at risk?” Even the Five Eyes admitted that their security advice is not new, only more urgent.

What’s new is how fast things are changing: “The rapid pace of frontier AI development means cyber risk assumptions can become outdated in months, not years. We must act before and be prepared to adapt and withstand evolving threats.” The Five Eyes point to AI technology—not necessarily chatbots, but AI more generally—being used to strengthen every aspect of defense, to “detect vulnerabilities earlier, improve software quality, monitor unusual behavior, and respond faster to incidents—reducing both the cost and impact of incidents.”

Excellent advice from the Five Eyes security agencies. We need to do this with every risk that AI heightens, not just cybersecurity.

This essay was originally published in The Guardian.

You've watched the demos. Whether it's Claude Cowork, ChatGPT Enterprise, GitHub Copilot, Cursor, or internally developed agents, AI systems are no longer answering questions. They are connecting to enterprise data, invoking tools, making decisions, and executing multi-step workflows across applications without human intervention. The capability is real, and organizations are rapidly moving from experimentation to deployment.

Teams are no longer asking if they should use this, they have accepted agentic tools as the reality. But the board and the infosec team are asking a different question: can this capability be secured and controlled at enterprise scale? Can security teams prevent sensitive company data from being exchanged without oversight?

Anthropic built meaningful access controls into Cowork — role-based permissions, group spend limits, usage analytics and connector restrictions — so the answer is a qualified yes. Those controls handle who can use the tool and what they can connect to, but they don't answer whether a specific action inside a given session is safe. That gap is the one standing between a successful pilot and a successful org-wide rollout.

The Gap That a Demo Doesn’t Expose

The organization’s admin assigns roles, sets spend ceilings per user group and restricts which connectors have access to write to your database. Anthropic's OpenTelemetry support even lets your team pipe session events into your SIEM. These controls cover real ground, but they operate at the permissions level — answering whether a person is authorized to use the tool rather than whether what's happening inside a session is safe.

Consider what that gap looks like in practice. Let’s consider two scenarios. Your finance analyst has full Cowork access and uploads a quarterly forecast containing unannounced acquisition figures. The access controls confirm she is authorized to use the tool, but nothing evaluates whether that information should be exposed to a model. That's an AI data loss prevention risk, and access controls are blind to it.

The risk becomes greater when agents move beyond information retrieval and begin taking actions. Let’s say a scheduled Cowork automation is set up to pull weekly competitor pricing from the web. A target site embeds hidden instructions in its page content. The agent, running unattended, reads them as legitimate commands and begins modifying local files and triggering actions your team never authorized. By the time anyone notices, the agent has already acted.

The first scenario exposes a governance problem because your security team has no visibility into what data is flowing through AI tools across the organization. The second is a runtime security problem as there is nothing evaluating whether an action in progress is safe, regardless of whether the user was authorized to start it. Neither gap is addressed with the predefined controls in Cowork; both need to be solved before you can say yes to Cowork adoption in the whole organization.

Why Traditional Controls Break Down

Traditional enterprise software behaves predictably. Access controls work because administrators can reasonably anticipate what an authorized user or application will do once access is granted. 

AI systems operate differently. Agents combine models, tools, data sources, and reasoning paths dynamically at runtime. An authorized user may start with a simple request, but the resulting chain of actions may evolve in ways that were never explicitly programmed or anticipated. The challenge is no longer controlling who can access a system. The challenge is securing and governing what happens after access has been granted.

The Missing Layer is Runtime Security 

Anthropic's access controls establish who can use Cowork and what they can connect to. But as the examples above show, they don't protect against what happens inside a session: a finance analyst uploading sensitive acquisition data to the model, or a scheduled automation being hijacked by a malicious instruction embedded in a webpage it was directed to visit. What organizations working with Cowork need is a layer that enforces data and security controls and gives complete visibility at runtime across all Cowork agents in the enterprise every interaction boundary.

An AI runtime security layer that sits between your teams and the model providers such as  Anthropic, AWS Bedrock, Google Vertex or any combination, and evaluates risk in every interaction. It inspects every request, every tool call and detects sensitive data like client names, financial projections, internal pricing and contract terms.  It enforces agent identity controls, so every automated action is traceable to a specific workflow and owner. 

Your CISO gets the audit trail and your Infosec team gets the evidence.

The AI Enterprise Needs a Control Plane

The CIO needs the observability for all Cowork activity and costs. An AI control plane allows the CIO to set spending limits per team and use case across every AI tool from a single console. Procurement asks for a quarterly forecast across all AI spend, and you pull it from one place instead of aggregating reports from four different vendor dashboards. If you need to move providers for cost or compliance, the gateway reroutes traffic without disrupting your teams or breaking your workflows.

Claude Cowork may be where organizations begin scaling their AI journey, but it won't be the only AI tool your teams use. Developers will use coding assistants,  business teams will leverage the AI built into SaaS applications and data science teams will deploy custom agents for their workflows. New models, new providers and new workflows will continue to appear.

The challenge isn't just governing one AI application; it’s governing AI activity across the entire AI enterprise.

Everyone looks to secure each tool individually: configure Cowork's controls, configure your coding assistant's controls, configure your internal agents separately. But this approach doesn't scale. This is the sole purpose of the control plane. It sits above individual tools, applications and models and enforces  security policies,  across every AI interaction. 

Prisma AIRS AI Gateway provides that centralised control plane. Organizations that deploy Cowork behind our gateway get runtime security, data protection, agent identity controls, and full visibility, applied consistently, without changing how teams use the tool. The same gateway secures every other AI tool in your environment on the same terms.

Cowork may be where the journey begins, the gateway is what allows it to scale and secure the AI Enterprise.

The post What It Takes to Secure Claude Cowork Across the AI Enterprise appeared first on Palo Alto Networks Blog.

As artificial intelligence (AI) adoption surges and organisations move from the ‘should we?’ phase to the ‘how do we?’ phase, it’s natural to evaluate the likelihood of positive returns on AI investments. That’s always been the case with the onset of each new technology paradigm: C-suite executives, guided by their boards and aided by technical and business teams, remain keenly focused on traditional metrics such as return on investment, shareholder equity, developing and extending competitive advantage, and ensuring superior customer relationships.

This time is different, however. I recently experienced that firsthand when I went to visit a major customer. My contact, a senior decision maker, gave me a pointed piece of advice about how to talk about AI with his boss, the CEO: “Please don’t say anything negative about AI.” The subtext was clear: The company was fully committed to AI and didn’t want any cognitive dissonance to dissuade them from their mission.

It's hard to imagine a CEO taking such an absolutist stance on previous technology waves, such as cloud, bring your own device, or the internet of things. CEOs, board members, and technical leaders would be pragmatic in evaluating the benefits of investments and put mileposts in place to gauge progress – and to determine if and how to proceed.

AI is certainly a different kind of paradigm, though. While no one is casting aside careful evaluation and monitoring of AI investments, the underlying assumption is that we’re stepping on the accelerator. We’re all enthused not only by its potential for transformation and innovation, but also by how this technology can be leveraged for remarkable societal good.

However, while the accelerating momentum toward AI and agentic systems is undeniable, it is vitally important to set aside the fervour around AI and take a sober look at how to deliver safe, secure, and tightly governed systems at enterprise scale. 

Many organisations are underestimating the challenges of AI governance, in large part because they think they’ve been here before. They already have many experiences of ensuring robust cybersecurity and strict governance for new technologies, as they’ve done for remote systems, cloud computing, the internet of things, and more. They already have a corporate commitment to doing governance correctly and a sound governance model. 

But this new era of AI and agentic systems is different. New challenges abound, and AI strategy, build-out, and governance must be in alignment from the start to ensure proper operational, ethical, and regulatory outcomes. 

Our intention with this Peer Insights guide is to raise what we believe are existential issues around governance for this powerful, complex, and unprecedented technology wave. Few technologies have merited the often overused phrase ‘inflection point’ more than AI. The speed of AI adoption is nothing short of breathtaking; however, today’s runaway embrace of AI is far stronger than our current ability to govern it. That’s because AI represents a fundamental shift in how organisations do their business, interact with customers, make vital decisions, and execute their plans. This isn’t just a technology play: It’s a strategy for success and survival for entire industries and our global economy. The stakes have never been higher.

CEOs care so passionately about AI because they see it changing nearly everything we’ve learned and believed to be true about organisational success and failure. CEOs are in their positions for one purpose: to grow the business. AI can do that by transforming their processes and sparking new ideas. When that customer representative forewarned me, I really wasn’t surprised to hear his CEO felt so strongly about AI: Research from BCG indicates that more than 94% of CEOs say they still plan to deploy AI irrespective of demonstrated business value, even if there is a lack of tangible ROI or financial benefits from the start. 

Which brings us to the central role of AI governance. As we all know, there are many fundamental elements to any governance strategy, starting with robust, scalable, and intelligent cybersecurity. Cybersecurity - the foundation of governance - also includes the twin imperatives of accountability (‘rogue AI’ being a real thing, after all) and regulatory compliance.

But good AI governance has to go even further. Operational integrity is key to good governance because so much sensitive and even proprietary data is poured into AI models and accessed through powerful agentic AI systems. Now more than ever, organisations have to be transparent with customers and trading partners about how their AI systems operate, what kind of data is accessed, and how it is protected. And that doesn’t just mean being upfront with customers by telling them when they are interacting with an AI agent. Let’s take a typical retail use case: Imagine you’re on a website looking at clothing, and the agent recommends specific styles of clothing in specific colours. True operational integrity would allow you to discover why and when the agent made those recommendations. Was it based on your prior purchasing history, or on your browsing patterns on a recent web session? AI and agentic governance take the guesswork out of the equation for those interacting with the system and help breed greater confidence and trust.

It's critically important for decision makers to view AI governance holistically, rather than through a series of narrow lenses. For instance, even though cybersecurity is the foundation of good AI governance, it’s a mistake to treat AI governance primarily as a cybersecurity problem. If asked about ownership of AI governance, CEOs cannot and should not reply, “Oh yeah, the CISO has that covered.”

AI governance is fundamentally an enterprise risk problem, which means everyone must be involved in creating, deploying, managing, evaluating, and adjusting AI governance guardrails on a real-time basis. Again, AI is a different kind of risk environment than any we’ve previously encountered. For the most part, organisations are simply not adequately prepared to apply the right level and right type of governance to AI and agentic systems. I’ve spent much of the past 15 years of my career building governance frameworks, and while it has never been easy, we have had the advantage of being able to control many of the variables – such as infrastructure and network access – impacting governance decisions. With AI and agentic, we no longer have that advantage.

To explore the critical and complex issues of AI governance, we’ve enlisted five leading voices to bring their real-world experience to the discussion. Together, our five authors help lay out the new rules of the road for governing AI and agentic systems at scale.

Just as my customer gave me a heads up about the realities of speaking with his boss about AI, I’d like to offer you a heads up about the realities of AI governance challenges before you read this Peer Insights guide. 

1. Visibility is paramount for successful AI governance. As we learned during the growth of trends such as cloud, bring your own device, and remote work, our employees will push the envelope with a do-it-yourself mindset. These tech-savvy and resourceful users are already making rogue AI a reality, so organisations need more visibility than ever into where AI ‘science projects’ and sandboxes are operating without anyone’s knowledge.
2. AI governance must reflect the stunning velocity of change in AI development and deployment. Not only does AI have its own never-imagined rate of change, but the technology is changing everything else faster – product development, supply chains, marketing programmes, and more. AI governance has to evolve just as rapidly. Governance in the AI world must be a living system, constantly evolving with new technology use cases.
3. Trust boundaries are incredibly different and difficult to manage in AI governance. AI represents a new class of identity that simply didn’t exist before. That means AI doesn’t fit neatly into your existing identity management framework, making things like application whitelists and zero trust network access less effective.

Unfortunately, many CEOs, board members, and business executives simply don’t understand the profound importance and complexity of these issues. They may have been heartened by how they integrated generative AI into their technology frameworks and their business processes, but GenAI was pretty familiar territory for CIOs, CTOs, and CISOs. Agentic AI is different for several reasons, including its automation and self-learning capabilities. Don’t be lulled into a false sense of security: Agentic AI is not simply a refresh of GenAI.

As you get ready to dive into the following chapters, rethink how you define governance when applying it to AI systems and agentic AI. Most traditional governance models are imagined, constructed, and deployed as gates, preventing people from doing things or going places they shouldn’t. Instead, think of AI governance as a guardrail to guide and direct people to get the most out of AI without creating problems. With so much excitement and investment around AI, organisations – and their employees – want to get the most out of their AI and agentic systems. We all know people don’t want to hear “no, you can’t do that”, so an effective governance system should use guardrails to drive proper, responsible, and safe usage of the technology.

Finally, as complex as AI and agentic governance are and will continue to be, don’t overthink things in hopes of creating the perfect model – it doesn’t exist. My advice is to start now, even if the model and framework are imperfect, and then bring the business along with you.

We at Palo Alto Networks are excited to give you insights, ideas, and actions you can take away from the chapters of this guide. We encourage you to share what you learn with your colleagues, peers, and team members – and to take prudent steps to build an AI governance model that rewards innovation without allowing your organisation to drift into dangerous waters.

 

Haider Pasha is VP & Chief Security Officer, EMEA, Palo Alto Networks

The post It Might Feel Like We’ve Been Here Before, But We Haven’t appeared first on Palo Alto Networks Blog.

Interesting paper: “Cybersecurity Mission Creep.”

Abstract: Cybersecurity is experiencing mission creep. Policymakers are casting more and more problems as issues of cybersecurity. So reframed, wildly different policy issues, from misinformation, to child social media safety laws, to antitrust regulations, to alleged journalist misconduct, to anti-sex trafficking statutes become what this Article calls “cybersecuritized.” Before this reframing, these issues present as important but not existential. But once cybersecuritization positions the issues as threats intensified by their technological nature, they gain access to the politics and law of urgency and exceptionalism and invite troubling governance responses.

Positioned as security threats, cybersecuritized issues become endowed with the apparent normative power to override countervailing considerations, oversimplifying the problem. Cybersecuritization’s oversimplification similarly risks unidimensional solutions and invites use of argumentative trump cards, like First Amendment challenges. Cybersecuritization also invites deference to purported specialists and their proposed solutions. Together, the reductive tendencies of cybersecuritization and the deference it prompts to specialists renders ultimate governance choices more opaque. And this opacity can erode public trust and political legitimacy.

This Article surfaces the phenomenon of cybersecuritization and offers a novel framework for analyzing and critiquing it. Mining cases from across criminal and civil domains, the account also demonstrates the insidiousness of cybersecuritization and the likelihood that it will continue to expand. Confronting cybersecuritization is crucial. If we continue to ignore it, we risk abdicating further responsibility for difficult choices to the trump card of cybersecurity. This Article’s analysis and critique aim to help reclaim the hard work of governance for our hands.

Artificial intelligence (AI) is changing the enterprise faster than most security models were built to handle. In just a few years, it has become part of everyday enterprise work. And soon, AI agents will do much more than provide assistance. They will act autonomously across applications, workflows, data stores and infrastructure.

This shift is already changing the security conversation – as it should. When agents can act on behalf of users, systems and business processes, identity is no longer a supporting layer of cybersecurity. It becomes the control plane for deciding who or what can act, what they can access, how much privilege they should have and when that access should be removed. Fragmented tools weren’t built to support this level of real-time visibility and control. It requires a unified identity security platform.

Palo Alto Networks recent acquisition of CyberArk reflects our conviction that identity is a core platform pillar for securing the future of AI. Identity security is now a foundational layer across our portfolio, building on CyberArk's trusted privileged access management (PAM) heritage and extending it to address the complexity of hybrid, cloud-native, and AI-driven environments. It also advances Palo Alto Networks broader platformization strategy, driven by customer demand for integrated, AI-powered security solutions that reduce complexity and close gaps created by disparate point products.

For partners, the launch of Idira™, our next-generation identity security platform, represents a significant opportunity to help customers secure access, privilege and identity risk through a more unified platform approach. More than ever, our customers need knowledgeable, trusted advisers to help them rethink how identity connects to the rest of their security architecture across network security, cloud, security operations (SecOps) and the broader AI-enabled enterprise.

Identity Security is No Longer Human-Centered

Research for our 2026 Identity Security Landscape report found that 96% of organizations have human identities operating with access far beyond what is required for their roles. That finding is unsettling enough, but also consider how modern identity security must account for far more than human users and privileged administrators. It includes machine identities and AI agent identities, ranging from service accounts, workloads and APIs to secrets and certificates and to agents operating across multiple systems.

Our recent report on identity security also notes that there are now roughly 109 machine identities for every human identity. Each identity can carry privilege, create risk and expand the attack surface. That scale makes real-time discovery, governance and control of identities essential. Yet many organizations are still managing privilege in ways that weren’t built for the AI era. When identities can act across systems and attacks can move faster, standing privilege (i.e., always-on access rights granted to users or machines) becomes harder to defend.

The premise of Idira is that every identity within an enterprise is privileged. The platform helps enterprises move from the traditional operating model of human-centered identity architectures and static access tools to embrace one platform that secures every identity – human, machine and AI agent. Idira discovers identities, entitlements and access paths, dynamically applies privileges through just-in-time controls and continuously governs identity lifecycles.

These capabilities become even more crucial as customers work to reduce fragmentation across their security environments. They want better visibility, faster time to value, stronger controls and a simpler way to manage risk across the enterprise. They still need advisory, implementation and managed services expertise, but the conversation is no longer limited to firewalls, privileged access, cloud workloads or SOC operations in isolation. Customers want expert help in connecting these areas into a unified strategy that reflects how their environments actually operate, especially with AI in the mix.

The Identity Security Opportunity for Partners

My message to partners following our launch of Idira is simple but direct: Now is the time to seize this defining moment in identity security. The speed of business is accelerating, as is the speed of attacks. And we know many of our customers around the world are already trying to understand what AI means for their security architecture, operating model and risk posture.

Partners can help lead those conversations with customers. For specialized and regional partners, this might mean expanding the advisory conversation beyond a single domain of cybersecurity. For global systems integrators, it might involve creating a more scalable delivery model by reducing the cost and complexity of stitching together multiple vendor environments. We are also actively welcoming partners into the broader Palo Alto Networks ecosystem, creating new opportunities for identity-focused partners to expand their role across the full platformization strategy.

Across partner types, the identity security opportunity is both strategic and economic. By connecting identity security to the broader Palo Alto Networks platform strategy, partners can expand services offerings, deepen customer relationships and build a stronger model for helping customers reduce complexity, improve visibility, strengthen controls and get to value faster. 

But first, sales teams, technical teams, solution consultants and managed service teams need to understand how Idira fits into the Palo Alto Networks platformization strategy and where identity security connects to customer priorities. That means taking full advantage of the sales demos, AI role plays, technical enablement and other active learning resources in Palo Alto Networks newly evolved NextWave program.

I encourage you to move quickly to build your understanding of Idira’s role in securing human, machine and AI agent identities and the shift from standing privilege to dynamic access. Be prepared to talk with customers about identity security in the context of cloud, network, SASE and SOC transformation, as you can be assured questions will be coming. Also, think about the services and offerings you can build around this opportunity. Identity security assessments, privilege modernization, machine identity protection, AI agent identity readiness and broader platformization road maps can all help customers take practical steps toward strengthening security in the rapidly evolving AI era.

Our partners play a frontline role in driving Palo Alto Networks platformization strategy and enabling our shared success. To help your teams educate customers about AI-related identity risk and how Idira can help them secure every identity in the enterprise, human or not, explore the latest resources, enablement and partner tools available through the NextWave Partner Portal.

Key Takeaways

• With the launch of Idira, identity security became a core pillar of Palo Alto Networks platformization strategy for the AI era.
• Idira helps organizations secure every identity – human, machine and AI agent – with dynamic access, continuous governance and real-time control.
• Partners have a timely opportunity to help customers reduce complexity, improve visibility and connect identity security to broader cloud, network, SASE and SecOps priorities.

The post A Defining Moment in Identity Security appeared first on Palo Alto Networks Blog.

The White House Executive Order on securing the nation against advanced cryptographic attacks accelerates the mandatory timeline for post-quantum readiness.

For years, post-quantum cryptography has been discussed as an important, yet abstract future technical migration. Because of the uncertain timeline for quantum computing, it has been difficult for most organizations to prioritize quantum readiness against more immediate security demands.

That is changing.

Signed on June 22, 2026, the Executive Order mandates the transition of federal information systems to post-quantum cryptography and establishes a national policy to migrate them to NIST-approved standards. It also extends the urgency beyond government by directing support for critical infrastructure owners and operators, advancing requirements for federal contractors, and calling for cryptographic bill of materials guidance.

The order directly addresses harvest now, decrypt later risk and sets transition milestones for federal high-value assets and high-impact systems: 2030 for key establishment and 2031 for digital signatures.

While the order directly applies to U.S. Federal civilian agencies, it should be seen as a signal of broader policy and procurement momentum. Organizations that do business with the government, support critical infrastructure, or operate in regulated industries such as energy, financial services, and healthcare should expect post-quantum readiness expectations to accelerate.

Quantum risk has shifted from a long-term research concern to a national cybersecurity priority tied to sensitive data, critical infrastructure, federal systems, procurement, and the broader digital economy. For security teams, the challenge now is turning that urgency into an operational plan.

Operationalizing the quantum mandate

As quantum computing advances, widely used public-key cryptography will become vulnerable to future attacks. Even before a cryptographically relevant quantum computer exists, adversaries can capture encrypted data now with the goal of decrypting it later.

This “harvest now, decrypt later” risk is especially concerning for organizations that protect sensitive information with a long shelf life. The response cannot wait until the threat fully materializes.

The broader ripple effect matters because compliance alone will not equal readiness. As requirements flow into federal acquisition rules and contractor obligations, the vendor ecosystem will be pushed to support quantum-safe capabilities in the products and services that enterprises, critical infrastructure organizations, and regulated industries rely on.

Adding support for post-quantum algorithms is not the same as safely migrating to them. Support means a system can use new algorithms. Readiness means the organization knows where cryptography exists, which systems are exposed, which dependencies matter most, and how to execute changes without creating disruption or new risk.

That matters because post-quantum migration can affect more than cryptographic libraries. Larger cryptographic objects, new protocol behaviors, hybrid modes, hardware acceleration requirements, interoperability constraints, and legacy system limitations can create real performance, availability, and compatibility challenges if changes are made blindly.

This is why cryptographic visibility must lead to actionable migration planning.

Security teams cannot migrate what they cannot see. But visibility by itself is not enough. They also need to classify exposure, prioritize high-value systems and long-lived data, understand operational dependencies, and plan changes in a way that avoids disruption, downgrade risk, or incomplete migration.

Cryptographic bill of materials guidance will be an important step toward mapping cryptographic assets. But a CBOM should be the starting point, not the finish line. An inventory can show where cryptography exists, but readiness requires understanding business impact, migration complexity, interoperability risk, ownership, and the order in which changes should happen.

Post-quantum readiness is not just an algorithm swap. It is an operating model for managing cryptographic change at scale.

Five actions for post-quantum readiness

The path forward starts with five practical actions.

• First, see cryptographic exposure. Organizations must gain visibility into cryptographic usage across all environments to mitigate the risks associated with undocumented encryption.
• Second, prioritize what matters most. Cryptographic exposure varies in urgency. Organizations should prioritize protecting authentication, high-value assets, and long-lived sensitive data based on risk and business impact.
• Third, modernize trust infrastructure. Existing systems rely on fixed cryptographic assumptions. Post-quantum readiness demands flexible infrastructure and trust services that support evolving standards.
• Fourth, automate cryptographic change. Manual tracking with spreadsheets provides an incomplete, point-in-time snapshot that quickly becomes outdated and is insufficient for the coming changes. Automation allows organizations to manage cryptographic updates and trust operations in a consistent, controlled manner.
• Fifth, govern readiness over time. Post-quantum migration requires continuous governance to track progress, align ownership, and adapt to evolving threats and standards.

These actions help security leaders move from awareness to readiness.

What this means for cybersecurity now

The Cryptographic Reset is already underway, driven by post-quantum risk, shorter certificate lifecycles, machine identity growth, fragmented cryptographic ownership, CA distrust events, and expanding digital infrastructure.

The organizations that move first will not simply be the ones that adopt new algorithms the fastest. They will be the ones that build the visibility, operating model, and governance needed to manage cryptographic change continuously.

Take the next step

Read the guide: The Post-Quantum Readiness Race Is On: Five Actions Security Leaders Can Take to Accelerate Crypto Agility.

More resources

• Blog: The Cryptographic Reset Has Begun
• Watch: Palo Alto Networks Quantum
• Blog: Palo Alto Networks Leads the Way with Quantum and Multicloud Security
• Blog: Introducing Palo Alto Networks Quantum-Safe Security
• Blog: Palo Alto Networks Announces New Quantum Security Innovations
• Press Release: Palo Alto Networks Delivers Enterprise Wide Quantum Security Readiness for All Customers

The post New Executive Order Accelerates Post-Quantum Readiness Amid the Cryptographic Reset appeared first on Palo Alto Networks Blog.

Anyone who has seen the impressive frame of Stonehenge against the morning’s sunrise cannot help but be struck by its resilience, how it has withstood time and the unpredictable impact of nature and humans. And partly because of this, a recent conversation I had with the CIO of a large healthcare technology company made me realize that it was a fitting metaphor for cybersecurity.

As our conversation wove through familiar topics — the challenges and breakthroughs in enterprise IT architecture — we recognised and discussed a recurring pattern throughout most EMEA and multinational enterprises. Those organisations have gradually but surely evolved into a mosaic of vendor fragmentation, ‘micro-platforms’ across vendor-specific technologies, and rapidly developing data silos that no single IT architecture can solve on its own. 

The increased heterogeneity of hardware, operating systems, and cloud architectures now comes with a dizzying mix of cybersecurity tools and services, often optimised for Vendor X’s platform. This has led to the situation that a large organisation typically has more than 30 cybersecurity point solutions in place to protect their digital assets. And now that we have thrown AI into that mix, designing the right cybersecurity solution is as confusing as it is imperative.

That’s when I was reminded of Stonehenge. Its lintel-and-joinery design is strikingly simple and elegant, and it stands as a brilliant monument to long-term resilience. Just as Stonehenge has endured against natural and human threats, so organisations must build a cybersecurity architecture that endures a revolutionary rate of change and threat diversity, including geopolitical turbulence and AI entering the value chain. 

For CISOs, CIOs, board members, C-suite executives and line-of-business leaders concerned with operational resilience, cybersecurity architecture matters—deeply. 

And we should not forget that cybersecurity is a data problem. The more telemetry data you have, the more effectively you can execute security algorithms and protect your digital essentials across all your enterprise IT pillars, i.e., IT, OT, Clouds, Networks, Workplace, Endpoints, etc. We at Palo Alto Networks are able to combine relevant telemetry data from networks, firewalls, clouds, browsers, endpoints and the internet. 

Stonehenge was built from massive, self-reinforcing pillars and platforms of stone. The lintels and joinery help hold together the overall structure as a cohesive unit, and they have striking similarities to how IT architects are now thinking about cybersecurity. In today’s technology architecture, Stonehenge’s vertical pillars are an IT organisation’s specialised, vendor-specific IT domains—sometimes with its own security tools and capabilities rather than as a strategically integrated zero-trust cybersecurity framework across your enterprise IT pillars.

Now, Stonehenge’s with its unique resilience, can also serve in its own construction as a model for modern cybersecurity architecture. Like our evolution towards modular platformisation evolved deliberately and assuredly over time and it spans all key domains of cybersecurity, ie network, cloud, AI,  identity security and all key building blocks for an AI-driven SOC, the last line of defense that has to be real-time. In other words, it is the linchpin of our strategy for enterprise security built upon such key areas as Identity, the Autonomous SOC, and Network Security. 

Stonehenge’s lintel is analogous to cybersecurity platformization, a growing trend rapidly replacing the now-outdated best-of-breed point solution mindset. This employs a modular approach that gives flexibility and control to the security architect looking to add security domain capabilities as needs evolve. The mortise-and-tenon joinery of Stonehenge works because the parts fit together rather than being stacked as an afterthought, in much the same way modern cybersecurity frameworks are built upon the concept of embedded functionality rather than being bolted on. 

An important example here is Palo Alto Networks’ decision to power the cybersecurity platform core with Precision AI, rather than its technology being added as a separate tool. This approach enables Precision AI to power data, analytics, and workflows, making it an omnipresent resource for smarter and faster prevention, detection and response.

Another important element of any enduring architecture is its ability to provide stability to the overall framework. In cybersecurity architecture, this is the all-important cyber data layer across an integrated zero trust framework. As organisations continue to struggle with data silos across networks, cloud environments, security operations centres, and edge systems, the cybersecurity data lake takes on a heightened role of importance for the resilience of the entire cyber framework. Again, let’s not forget, cybersecurity is a data problem, a domain in its own right across all vertical IT pillars.

Now, Stonehenge with its unique resilience, can also serve in its own construction as a model for modern cybersecurity architecture. Like our evolution towards modular platformization evolved deliberately and assuredly over time and it spans all key domains of cybersecurity, i.e.  network, cloud, AI, endpoints, identity security and all key building blocks for an AI-driven SOC, the last line of defense that has to be real-time. In other words, it is the linchpin of our strategy for enterprise security built upon such key areas as Identity, the Autonomous SOC, and Network Security/SASE. 

Another critical element of the cyber platform is something even Stonehenge hasn't had to face: securing AI itself, especially the opportunity and threat represented by agentic AI. AI security must become part of the platform design and implementation, as we have done with our Prisma AIRS (AI Runtime Security) platform for enabling an organisation's growing AI portfolio to remain a vital asset and not an inviting attack vector. Agents now are not just another non-human identity; they are an entirely new class of identity, with a striking mismatch in speed between agent decision-making and human governance. The inside-out attack paths taken by hackers' ill-intentioned agents represent a major threat to under-protected AI supply chains. The same pressure now also comes from geopolitics and from AI moving into the value chain itself, such as in the case of the Factory of the Future.

Similarly, our recent acquisition of CyberArk gives us what we believe is the industry’s strongest identity security platform, Idira, positioning it as yet another vertical pillar connected to the overall cybersecurity platform lintel. Cortex XSIAM and its security data lake are deliberately open — ingesting and correlating third-party telemetry alongside our own, over 17 petabytes of telemetry data each day — to form a secure data layer that is accessible to users based on policy management and credentials validation. Palo Alto Networks leverages this mountain of data, along with around-the-clock scanning of more than 5 billion daily security events, to feed Precision AI in order to detect and block potentially devastating attacks. Currently, we detect about 9,6m new attacks per day that have not been there the day before. The use of automated AI in attack vectors has been accelerating the time of exfiltration of data from the compromise of an organization. This delay was 9 days about 3 years ago, now data is exfiltrated in most cases in less than a day, sometimes already within less than one hour!

In this context, it's also important to highlight the importance of an Autonomous SOC pillar, particularly since compliance reporting windows are continuously contracting from days to mere hours calling for real-time, highly automated defence. Today, mean-time-to-detect and mean-time-to-respond are board-level imperatives commanding more conversation and attention at an organisation’s highest levels. The Autonomous SOC pillar is a vital element in helping enterprises achieve even faster detection and remediation, ideally down into single minutes. If it also integrates the historic enterprise SIEM you can further simplify your SOC operations and gain solid financial benefits by platformization of your security relevant data.

Finally, keep in mind the use of supply chains to build the actual platform. For Stonehenge, that was an impressive physical supply chain: The bluestones used in the structure were hauled about 250 kilometers from Wales without the benefit of air, rail, or truck transport. For Palo Alto Networks’ cybersecurity platform, the supply chain was no less impressive, but more virtual than physical, often faced with attacks on third-party interdependencies such as SaaS applications, APIs and in times of Frontier AI models, the Open Source components. 

Like the pyramids, the Great Wall of China, and the Roman road system, the most remarkable aspect to Stonehenge isn’t just its engineering elegance, but its ability to withstand changing conditions and threats over time. Whether you’re a CEO, board member, CIO, CISO or security engineer, the decisions you make about cybersecurity carry significant impact and implications. In order to achieve Stonehenge-like resiliency, technical and business leaders should commit to an architectural model designed not only for today’s needs, but for what those needs are likely to be over the long term. 

Therefore, cybersecurity should be architected as a horizontal, dedicated platform across all your IT domains and businesses. With this you are able to provide real-time and platformized cybersecurity for tomorrow. And tomorrow is going to be a more and more AI-driven business world. 

 

Helmut Reisinger is CEO for Europe, Middle East, and Africa at Palo Alto Networks.

The post Built to Last: What Stonehenge Teaches us About IT Architecture & Cyber Resilience appeared first on Palo Alto Networks Blog.

When a major cyber incident hits, all eyes are on the CISO.

They become the invisible CEO of crisis, steering the entire enterprise through the storm, managing stakeholders and making major decisions under immense pressure. The clock is ticking. Every minute can mean more systems affected, more data exposed, greater operational disruption and a growing risk to customer trust and corporate reputation.

And this on top of an already expanded day-to-day role, where they are expected to make decisions with incomplete information, brief the board, support legal and communications teams, manage technical response and reassure the business, all while knowing that any delay could increase the damage.

But a troubling pattern often emerges once the smoke clears. The CISO may find themselves held responsible for the incident that just happened, and in some cases personally liable, while still being expected to prevent the next one. Yet, at the same time, their influence over the strategic decisions that shape cyber risk can quickly diminish. 

This cycle takes a toll. Across EMEA, we are seeing the personal and organisational impact of that pressure, from burnout and leadership turnover to growing concerns about long-term resilience.

That pressure often comes at a demanding stage of life too. Many security leaders reach the CISO role when career responsibility is peaking at the same time as responsibilities outside work, from ageing parents and family commitments to their own health.

With an average CISO tenure now reduced to between 18 and 26 months, and nine out ten reporting feeling moderate to high stress, a more sustainable model is needed for structural and personal resilience.

Cybersecurity is far more complex than it was a decade ago. AI-powered attacks and autonomous agents are increasing the speed and scale of threats. At the same time, the CISO has never had more potential influence over business strategy. The challenge is ensuring the support around the role evolves as quickly as the threat landscape.

That is why it’s time to stop treating cybersecurity as a technical function alone and recognise the CISO as a strategic business leader.

Structural equity - breaking the cycle of isolation

The burden of cyber resilience should not rest on one individual. Yet too often, organisations place responsibility on the CISO without providing the support, influence or measures of success needed to help them thrive.

Part of the problem is how the role is measured. CISOs are judged by whether incidents happen, rather than by the quality of preparation, resilience planning, risk reduction and secure business enablement.

And preparation can really help reduce the pressure. Regular red teaming, tabletop exercises and incident simulations mean the CISO is not carrying the crisis alone when a breach happens. The organisation has rehearsed its roles, decision points and escalation paths before the stakes are at their highest. 

But after a crisis, organisations also often fall back into day-to-day survival mode, undoing the progress made when security was treated as a critical part of business planning rather than a technical function. Strong resilience requires the CISO to have a permanent seat at the table for all strategic decisions, from M&A to digital transformation.

That influence only comes with strong foundations. This includes visibility of critical assets and risks, security controls that are fit for purpose and the operational discipline to maintain them over time.

• Invest in leadership as much as certifications: The modern CISO needs diplomacy, judgement and the ability to translate risk into business terms. Different backgrounds can strengthen that role, bringing fresh perspective when solving problems that are no longer purely technical
• The ‘Shared CISO’ model: Cyber resilience should not rest on one pair of shoulders. The most resilient organisations embed responsibility for cybersecurity across the business, while creating stronger support structures around the CISO through deputies, shared ownership of cyber risk and clear succession planning. This reduces pressure on individual leaders and helps ensure resilience is built into the organisation itself

Strategic diplomacy - aligning people and purpose

Cyber resilience depends on people as much as technology, and a CISO’s success depends on building alliances across the business. The strategic diplomat CISO focuses on moving the conversation from ‘no’ to ‘how?’ by building deep relationships with other leaders, every team and every department across the organisation.

By understanding the business’ growth drivers, the CISO can align security goals with the board’s priorities. That means agreeing meaningful measures of risk and readiness, preparing for difficult questions and giving the business a clear view of where it is exposed. 

Security and growth must be seen as a single strategic fabric. Integrating security into the development of internal AI tools and customer-facing products helps ensure innovation is secure by design, rather than being a hurdle to overcome later.

The post The Invisible CEO of Crisis: Breaking the Cycle of CISO Burnout appeared first on Palo Alto Networks Blog.

The rise of Agentic AI is rapidly reshaping the enterprise, yet its deployment opens a complex new frontier for cyber threats.  As organizations race to harness the power of enterprise agents, the "Data Estate" has become the new perimeter. CISOs today face a high-stakes trade-off: enabling developers to build at the speed of AI while keeping proprietary data visible, governed, and secure across the entire AI lifecycle. This requires meticulously checking user inputs, agent outputs, and tool calls for threats like prompt injections, sensitive data loss, and malicious code, while simultaneously preventing autonomous agents from performing destructive actions.

Securing the AI-driven enterprise requires a fundamental shift from reactive measures to proactive runtime protection. Palo Alto Networks and Databricks are delivering on that vision. Our partnership will integrate the Prisma AIRS API with Databricks Unity AI Gateway, embedding seamless security at runtime. This collaboration will enable organizations to innovate with AI agents, applications, models and MCP Servers at scale while maintaining a robust, policy-driven security posture. By combining the centralized AI governance and control capabilities of the Databricks platform with the runtime security protections of Palo Alto Networks, organizations can scale AI innovation without sacrificing visibility, compliance, or security.

 

The Context: Why AI Security is Different

AI security represents a fundamental departure from traditional defense. Legacy tools are designed for structured threats, leaving them incapable of parsing the intent behind complex, conversational attacks. Furthermore, the integration of Retrieval-Augmented Generation (RAG) and autonomous workflows creates a dynamic attack surface that goes far beyond traditional data loss. Without AI-native oversight, organizations can face severe risks from prompt injections, custom topics, and toxic content manipulating model logic, to tool misuse, malware execution, and malicious URLs hijacking agent actions.

Modern AI development requires more than just a perimeter; it requires contextual intelligence. By integrating Prisma AIRS directly into Databricks Unity AI Gateway, we will evolve security from a reactive layer into a native pillar of the AI architecture.

 

The Joint Solution: Centralized Security at the Gateway

The most effective way to secure an entire AI environment is at the governance layer. Our integration focuses on Databricks Unity AI Gateway, which serves as the centralized interface for all AI activity within the Databricks environment. Unity AI Gateway is designed for managing, governing, and monitoring access to all models, agents and MCP Servers—whether they are open-source models deployed within Databricks or external proprietary models. As organizations deploy more agents, applications, and models, centralized governance becomes critical. Unity AI Gateway provides a single control plane for AI usage, enabling teams to apply consistent policies, monitor activity, and manage access across AI workloads.

Through this integration, Unity AI Gateway will make real-time calls to the Prisma AIRS Runtime Security API for security inspection. Instead of managing fragmented security policies across dozens of individual applications, SecOps teams will be able to enforce consistent guardrails across the entire Agentic AI estate from one location, providing a single, unified enforcement point for all AI workloads.

Figure 1: Centralized AIRS guardrail configuration delivers instant protection across all applications, agents and MCP Servers without requiring client-side code refactoring

 

Mechanism: API Intercept for AI Runtime Security

Prisma AIRS operates as an advanced inspection layer, leveraging its API Intercept capability to provide real-time security embedded directly into the application flow. By embedding Prisma AIRS directly into the workflow, we offer a seamless 'Security-as-Code' experience that unifies development and defense. Prisma AIRS intercepts AI prompts, responses, and MCP calls—inspecting them in real time to enforce security policies with an immediate Go/No-Go verdict or by sanitizing the data in transit. Prisma AIRS uses deep learning classifiers to detect data exfiltration risks, such as the presence of PII (Personally Identifiable Information), PHI, or PCI data. If sensitive data is found, it can be dynamically redacted or blocked based on corporate policy.

 

Key Benefits for the Enterprise

This integration isn't just about blocking threats—it’s about accelerating your AI roadmap. By removing the "security friction" that often slows down production deployments, we enable teams to move faster with confidence. Key benefits include:

• Zero-Friction Governance: Developers continue working within their familiar Databricks environment. Security is enforced via the Unity AI Gateway API, meaning there are no bulky agents to install and no complex architectural re-wiring required.
• Prevention of Data Leakage: Leverage Prisma AIRS’s data classifiers to automatically protect sensitive intellectual property, preventing data leaks to public models and unauthorized users.
• Resilience Against AI-Specific Attacks: Protect your Unity AI Gateway deployments from emerging threats that standard network security tools cannot see, including prompt injection, toxic content, custom topics, malware detection and malicious URL detection.

 

Key Takeaway

• Ease of use and unified Policy Management: Enable runtime security through the Unity AI Gateway to gain centralized control over security enforcement.
• Audit-Ready Compliance: Every transaction mediated by the Unity AI Gateway is logged with detailed security metadata, delivering enriched insights in Strata Cloud Manager. This provides the forensic trail required for regulatory compliance in highly governed industries like finance and healthcare.
• Protection for Agentic Workflows: Future-proof your multi-step AI agents against sophisticated Agentic Threats by inspecting function and tool calls within the runtime.

 

Looking Ahead

As agentic workflows and multi-step model interactions become the standard, a 'fail-closed' runtime security posture is no longer optional; it is foundational. The integration of Prisma AIRS API and Databricks Unity AI Gateway marks a definitive shift toward a future where enterprise AI is secure by default.  By integrating Prisma AIRS API with the Databricks platform through Unity AI Gateway, organizations can centrally govern AI across models, agents, applications, and MCP servers while enforcing consistent runtime security policies. Together, Databricks and Palo Alto Networks are helping customers scale AI innovation with the control, visibility, and protection required for the agentic era.

Are you ready to secure your AI workloads and agentic applications?
check out the latest Databricks blog and stay tuned for technical deep-dive sessions coming soon.

 

Forward-Looking Statements

This blog contains forward-looking statements that involve risks, uncertainties and assumptions, including, without limitation, statements regarding the benefits, impact, or performance or potential benefits, impact or performance of our products and technologies or future products and technologies. These forward-looking statements are not guarantees of future performance, and there are a significant number of factors that could cause actual results to differ materially from statements made in this blog. We identify certain important risks and uncertainties that could affect our results and performance in our most recent Annual Report on Form 10-K, our most recent Quarterly Report on Form 10-Q, and our other filings with the U.S. Securities and Exchange Commission from time-to-time, each of which are available on our website at investors.paloaltonetworks.com and on the SEC's website at www.sec.gov.  All forward-looking statements in this blog are based on information available to us as of the date hereof, and we do not assume any obligation to update the forward-looking statements provided to reflect events that occur or circumstances that exist after the date on which they were made.

The post Securing the Agentic AI Frontier: Palo Alto Networks and Databricks Deliver a New Standard for AI Security appeared first on Palo Alto Networks Blog.

From August 3, 2026, Google will use IP addresses from UK, EEA and Switzerland users for ad measurement and personalization. It lands as the ICO weighs new consent rules, and years after Google itself called using such signals to identify devices "wrong." [...]

What we believe

We’ve been thinking deeply about enterprise security. The operating model that served us for the past decade (collect telemetry, store it, query it, build dashboards to watch it) is no longer keeping pace. We need to shift to the new world: telemetry, context, reasoning, and actions. An approach that produces outcomes. The latest cybersecurity frontier models further made this shift urgent. Models like Claude Mythos can now find software vulnerabilities and reason through complex attack paths at machine-speed, leading to an exponentially increasing backlog of vulnerabilities.

Introducing AWS Continuum for code vulnerabilities

Today, we’re announcing AWS Continuum for code vulnerabilities, now available in gated preview. Continuum for code vulnerabilities addresses the full lifecycle of a code vulnerability at machine speed: from discovery through actions. It reasons over your environment, confirms what is real, and drives toward resolution. It’s model agnostic, using multiple frontier models where each performs best, and is built to incorporate the latest and most capable models as they emerge.

Continuum is built on lessons learned from running security across AWS and Amazon.com. Securing businesses that operate in different industries required a system that understands business context rather than applying generic rules uniformly.

How it works

Continuum for code vulnerabilities reasons over your full environment. This context includes structured data already living in Amazon Web Service (AWS) (your infrastructure, permissions, network topology, code) and the unstructured data that captures how your organization operates and your risk profile (your documents, communications, business priorities).

Continuum for code vulnerabilities operates in four continuous phases.

1. Discovery: Security teams tackle a backlog of vulnerabilities, and many are already using frontier models to find more. Continuum starts by ingesting that existing backlog and performing its own vulnerability scan of your environment. This creates a more comprehensive view of vulnerabilities and the associated attack paths.
2. Prioritization: Continuum uses context to evaluate, enrich, and prioritize every finding. Is the affected component deployed, is it reachable, is it in a production path, and what would the business impact be if exploited? The result is an evidence-backed list of priorities, allowing Continuum and your team to focus on what’s most important.
3. Validation: Continuum validates findings to surface false positives before they waste your team’s time. It contextualizes vulnerabilities against your environment. It then constructs working exploit examples in a sandboxed environment that provide concrete, reproducible evidence of the issue.
4. Mitigation and remediation: Continuum assesses existing defenses around a validated issue, including blocking and compensating controls along with detection mechanisms. It then draws on its understanding of the codebase, context, and findings to recommend mitigation or remediation of the vulnerability with a network change, policy change, or code patch. The patch recommendation is validated using the same system that confirmed the vulnerability. It also provides blast radius visibility and rollback paths where feasible.

This is just the beginning. We’re starting with code (1^st and 3^rd party) and then expanding to other aspects of security.

Trust is graduated

Continuum starts in learn mode with a human in the loop. Every recommendation includes the reasoning behind it. As you gain confidence, you can graduate Continuum to enforce mode, enabling remediation that can be increasingly automated based on categories and risk profiles you define.

Continuum capabilities

In addition to Continuum for code vulnerabilities, Continuum includes capabilities you might already know. The AWS Security Agent penetration testing and code scanning functionality is now part of Continuum as Continuum pen testing and Continuum code scanning (Preview). We’re also launching Continuum threat modeling in preview, which automatically generates comprehensive threat models from design documents or source code and outputs results in STRIDE format. These capabilities serve as detection and analysis sources that feed into the broader Continuum loop of discovery, prioritization, validation, and remediation.

Getting started

We’re working with customers across financial services, automotive, and technology to shape AWS Continuum. Customer feedback confirms the direction: security teams want tools that earn trust and take action.

AWS Continuum for code vulnerabilities is available in gated preview. Sign up to request access at AWS Continuum.

If you have feedback about this post, submit comments in the Comments section below.

---

A newly discovered data leak dubbed "FortiBleed" has exposed what appears to be a collection of Fortinet and FortiGate VPN credentials for 73,932 firewall URLs at organizations worldwide. [...]

Europe, like much of the world, is living through a period of heightened geopolitical uncertainty in which sanctions risk, legal divergence, and cyber disruption have moved from abstract concerns to board-level variables. Digital sovereignty is shifting from aspiration to operational requirement, driven by resilience expectations, critical service dependency, and rising geopolitical and cyber risk. Definitions of sovereignty vary, ranging from blanket data localization edicts to industrial policy to national security, but the absence of an agreed definition should not be mistaken for an absence of intent. Sovereignty is already shaping procurement, regulatory compliance, and technology strategy. From my years working at the intersection of government and the technology industry, I have seen how quickly digital policy can harden into operational constraints. I have also seen how easily "sovereignty" becomes a stand-in for broader concerns: dependency, geopolitics, and the fear that critical services may not remain available during a crisis Two issues are at play. First, policymakers are right that over-dependency on foreign technology can become a national resilience problem. Cloud market concentration is a case in point: last year across Europe, the three leading cloud providers accounted for around 70 percent of the market, while European providers' collective share remained around 15 percent. Concentration is not, by itself, a security failure, but it is a strategic dependency that can become acute when legal regimes diverge, access is contested, or a geopolitical shock tightens the room to maneuver. It also amplifies the "ripple effect": disruption at a small number of providers can cascade across thousands of organizations and supply chains. Second, business leaders are right to worry that blunt sovereignty initiatives raise costs and regulatory complexity. A hard localization mandate or a "sovereign-only stack" duplicates infrastructure, slows modernization, and in practice keeps organizations tied to legacy systems longer than planned while limiting access to leading technologies. The same tension is shaping Europe's competitiveness debate. Former Italian prime minister Mario Draghi has argued that security is a precondition for sustainable growth and that deep dependencies can leave Europe vulnerable to coercion as geopolitical volatility increases. The question is not whether sovereignty matters but how to pursue it without turning it into a counterproductive procurement ideology. From policy to platform choice A recent decision by the French government to restrict certain foreign-made video conferencing tools in favor of a homegrown alternative illustrates the direction of travel across the EU. Whether one agrees with the decision or not, it signals something larger: sovereignty is becoming a set of practical constraints that can reshape technology choices quickly. Many organizations are responding with a third, damaging outcome: delay. In a recent Zscaler-commissioned survey, 73 percent of respondents said digital sovereignty concerns had caused them to delay or cancel transformation initiatives. That "pause dynamic" is dangerous because it prolongs exposure to legacy risk, weakens cyber readiness, and leaves organizations less able to absorb disruption from ransomware, supply chain compromise, systemic outages, or sudden changes in cross-border rules at a time when the threat landscape is shifting faster than ever. If Europe wants sovereignty that strengthens resilience rather than undermines it, political and business leaders need a framework that is practical, measurable, compatible with open markets, and informed by the technology sector's expertise. Here is one: control, choice, and continuity. An outcome-based framework Sovereignty begins with what an organization can control in practice: who can access data, who can administer systems, whether a vendor can see customer content, where logs are stored, how keys are managed, what subcontractors can see, and how policies can be enforced. Control is not about isolation; it is about enforceable governance and reducing hidden dependency. Sovereignty also requires choice: credible options when assumptions break. Too many organizations discover too late that their "vendor strategy" is really a dependency strategy, with few realistic alternatives. Choice is not achieved by buying two of everything. It is achieved through architecture and contracts that keep an organization mobile and avoid vendor lock-in: portability for data and configurations; full transparency on who they rely on, where access sits, and which jurisdictions and subcontractors are in the chain; and pre-agreed exit paths that can be executed under time pressure. It also requires leaders to prevent the sovereignty debate from becoming an excuse to stop transformation. Every program facing sovereignty constraints should be forced through a decision path: redesign, mitigation, or exit on a timeline. The third C is continuity: keeping critical services running during any kind of disruption. If sovereignty is meant to reduce strategic vulnerability, continuity is where it either becomes real or becomes theater. Continuity is measurable through recovery time objectives, tested failover, supplier-failure drills, and exercises for jurisdiction-change scenarios. Across Europe, the urgency is reinforced by the threat environment. Zscaler ThreatLabz data shows rising numbers of damaging ransomware attacks year over year across the region: Spain (+116 percent), Germany (+74 percent), Belgium (+73 percent), Italy (+53 percent), and France (+34 percent) among others. Separate research on resilience found that 52 percent of IT executives believe their current security measures are insufficient to defend against existing or emerging threats such as agent-based AI and quantum computing. The UK's National Cyber Security Centre, meanwhile, reported a 130 percent rise in "nationally significant" incidents over the past year. AI is accelerating these risks. It already gives "bad actors" new capabilities to increase the speed, scale, and sophistication of their attacks. The question is not whether disruption happens, but whether systems can withstand it. Mandate outcomes, not vendors Business leaders argue that sovereignty will raise costs, increase compliance friction, and shrink access to leading technology. That is often true. Policymakers' concerns are also legitimate: strategic dependency can undermine national security and resilience. The mistake is writing sovereignty rules that dictate which vendors to buy rather than what controls buyers must have to keep services running during shocks. The most useful sovereignty requirements are outcome-based: enforceable control over access and data, credible choice through portability and exit, proven continuity through testing and recovery. They create room for organizations to use global platforms safely while meeting local requirements, without freezing modernization. If sovereignty is now an operating requirement, every stakeholder has a role. Boards should define what "sovereign enough" means for their organization, then require regular reporting and testing, with incentives tied to resilience outcomes. CEOs and COOs should treat sovereignty as continuity, fund the modernization that reduces brittle legacy dependency, and force decisions on blocked programs. CIOs and CISOs should map and minimize third-party access, implement localization and multi-region resilience where required, and build plans for supplier failure and jurisdiction-change scenarios. Regulators should clarify definitions, harmonize requirements where possible, and create compliance pathways with transition periods that reward modernization rather than incentivize delay. The approach must be risk-based and agreed in consultation with industry. Scaling control, choice and continuity To make control, choice and continuity achievable at scale, two additional disciplines are required: collaboration and compliance. Collaboration keeps sovereignty compatible with openness through interoperability, shared incident readiness, transparent subcontracting, and trusted vendor partnerships that reduce concentration risk instead of merely relocating it. Solutions must be tailored for local demands and drive investment in local ecosystems. Compliance makes sovereignty measurable through clear definitions, auditable evidence, and regulatory approaches that focus on operational controls so that organizations are pushed to modernize rather than to delay. Sovereignty on European terms should be judged by outcomes rather than rhetoric: whether organizations can govern access, keep options open, recover quickly when incidents happen, and continue delivering critical services when dependencies fail. Done well, digital sovereignty becomes a catalyst for resilience, innovation, growth and competitiveness; done bluntly, it becomes a brake on the very transformation it is meant to protect. Contributed by Zscaler.

Account takeovers are rising as attackers bypass traditional defenses through phishing, session hijacking, and MFA fatigue. Specops Software explores how device trust and continuous verification help reduce account takeover risk. [...]

Cisco has updated a February security advisory, adding another product to the list of those affected by the maximum-severity CVE-2026-20127. Switchzilla made a small amendment to the original advisory on Tuesday evening, noting that Cisco Catalyst SD-WAN Validator, formerly vBond, was also among the boxes attackers could pop open. Readers may remember the fuss over CVE-2026-20127 (10.0) a few months ago. The make-me-admin improper authentication flaw prompted a Five Eyes alert since attackers could essentially gain persistent root access to all vulnerable instances. In other words, it's a far-from-ideal situation that could could create espionage opportunities, given the prevalence of Cisco's SD-WAN offerings in Western networks. Cisco said at the time that attackers could exploit CVE-2026-20127 to gain admin rights, access NETCONF, and reconfigure the SD-WAN fabric, before exploiting CVE-2022-20775 (7.8), a path traversal flaw discovered in September 2022, to gain root access. Cisco Talos, the company's threat intel arm, posited that the bug could have been exploited for as long as three years by the time it was discovered. Talos attributed the exploitation activity to a group it tracks as UAT-8616, whose activity dates back to at least 2023, according to its researchers' estimates. No one has formally attributed UAT-8616 to a specific country or group of individuals, but experts say that it is a highly sophisticated outfit that has a history of targeting critical infrastructure sectors. Ollie Whitehouse, NCSC-UK's CTO, said at the time: "Our new alert makes clear that organizations using Cisco Catalyst SD-WAN products should urgently investigate their exposure to network compromise and hunt for malicious activity, making use of the new threat hunting advice produced with our international partners to identify evidence of compromise. "UK organizations are strongly advised to report compromises to the NCSC, and to apply vendor updates and hardening guidance as soon as practicable to reduce the risk of exploitation." The Register asked Cisco for more information, but it did not immediately respond. Customers should not have to make any new changes, provided that they upgraded their software to a fixed version across all systems when the advisory was first published in February, not just SD-WAN Controller and SD-WAN Manager. The update comes weeks after Cisco disclosed another zero-day affecting Catalyst SD-WAN, suggesting that it had been exploited for at least a week at the time. Tracked as CVE-2026-20245, it marked the sixth SD-WAN flaw disclosed this year, and the second to be exploited as a zero-day in as many months. ®

India has banned Telegram until June 22 after the app was used to circulate leaked exam papers. CEO Pavel Durov accuses telecom Reliance of BGP hijacking that disrupted the app as far away as the UAE. Here's what happened, and how to get around the block with an MTProto proxy. [...]

AI security is getting attention because AI has stopped being a side experiment.  It is now part of how work gets done. Employees use copilots to write, research, code, and analyze. Product teams are adding AI into customer experiences. Developers are building applications on top of foundation models. Business teams are experimenting with agents that can read email, summarize documents, query data, and trigger workflows.  That is a very different world from the one many AI review processes were designed for.  An AI system can pass a benchmark and still fail in production. It can behave safely in a clean test environment and then encounter real […]

The post AI Red Teaming Makes the Unknowns Known appeared first on Check Point Blog.

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) has ordered federal agencies to patch a maximum-severity flaw in the Widget Factory Joomla Content Editor (JCE) plugin that is being actively exploited in the wild. [...]