If you look at social media debates about AI, two extreme patterns emerge. Studying extreme patterns is very useful because understanding boundary conditions helps you understand the whole phenomenon — in this case of security in AI adoption (recent extreme example). You can also do all sorts of fun scenario planning with this.

Predictably, security leaders have caught the same fever, and even some technologists did. Let’s catalog them like this:

• Camp 1 (The Meh Camp): This camp spans a spectrum — from the hard cynics (“it’s autocomplete with a marketing budget,” LLMs are stochastic parrots, there is no ‘intelligence’ anywhere in the building) to the more measured “AI as normal technology” crowd, who concede the tech is real, but expect it to diffuse slowly and messily over decades. What unites them: no discontinuous jump, no paradigm rupture, no exponents, no robot overlords. And yes, “the parrot wing” of this camp is alive and well in some very senior security circles.
• Camp 2 (The Deep Believers): AGI is coming by “next Tuesday” — or 2027 at the absolute latest. This camp also spans a spectrum, from the “doomer” accelerationists who foresee inevitable, systemic collapse to the optimistic futurists anticipating a complete, rapid upheaval of the global security landscape. Some hold this timeline with religious fervor while being unable to define “intelligence” if their bonus depended on it. What unites them is the conviction that we are facing an immediate, discontinuous, exponential leap in capability that will render all traditional defensive strategies obsolete overnight. And yes, there are influential security leaders who lean heavily into this camp.

Here is the fun part and the point of this blog: you don’t need to know who’s right. In fact, betting your security program on either camp being right is the actual mistake I want to point out.

Maybe the Parrot camp is right. Maybe the AGI-doomers are spot on. Or maybe the truth is somewhere in the swampy middle. If you find yourself unable to justify a security investment without first winning a philosophy-of-mind debate, you are doing it wrong.

But let’s instead ponder what works in “either / neither / both” cases.

What security advice remains correct today and for the medium term without relying on either camp being right?

One structural note before we start: every section below runs the same play. What the “parrot future” does to you. What the “AGI Tuesday” future does to you. What you do about both — with one control. Watch how many times the answer converges.

That convergence is my argument (with help from Gemini and Claude Fable).

Universal Security Controls for Both Futures

If you’re Camp 1 — whether the parrot wing or the “normal technology” wing — you believe AI is an incremental extension of “classic” ML: it accelerates existing security processes without any dramatic paradigm shift. But even then, you concede it speeds things up — including for attackers, who now discover vulnerabilities and misconfigurations faster and phish with impeccable grammar (nobody, not even the “parrotiest” parrot will argue with this one!). If you’re Camp 2, you may be surprised to see that these same controls apply, just with the volume knob turned to 11 at times.

1. Configuration Hygiene

Boring? Yes. Optional? Definitely not. Cloud misconfigurations and weak baselines remain the #1 way attackers walk in through the front door — no AGI required, thank you very much.

• Parrot future: attackers use AI to find your misconfigurations faster. The parrot doesn’t need to be smart; your S3 bucket is public.
• AGI future: the “superintelligent” attacker also starts with your public S3 bucket, because why use an AI-crafted zero-day when the door is open?

The universal control: treat configuration hygiene as tier-1 defense, with continuous (not quarterly!) posture validation. Hygiene is the rare control that is equally valuable whether AI is a mildly better “grep” or an existential threat (Claude came up with this metaphor, thanks buddy, it almost rhymes). If your AI security roadmap has “agentic red teaming” on it but not “close the open buckets,” you are accessorizing a house with no doors. See good argument here.

2. Threat Detection & Security Monitoring

You do recall I had a title “Chief Logging Evangelist” a few years back (“A few, Anton”? Who are you kidding?” … Anyhow…) Your SOC or D&R team or whatever you call it still needs to log, sense, detect, investigate, etc.

• Parrot future: your normal systems face automated, AI-accelerated attacks — same TTPs, faster tempo, and phishing that finally spells “invoice” correctly. Your triage queue was built for human-speed adversaries; it is about to meet an assembly line.
• AGI future: the AI systems themselves become the thing to watch — inputs, outputs, tool calls, and internal telemetry — because prompt injection, abuse, and quiet exfiltration through an agent leave traces nowhere in your current detection content.

The universal control: log and detect. Your classic estate under machine-accelerated attack, and your AI stack as a first-class telemetry source with its own detections (devil here is in the details, as usual). I admit this smells like an “Easier Said Than Done” competition entry with some chance of getting a 3rd prize. But the fact remains: good logging helps you in either case.

3. Accelerated Vulnerability Management

Vulnerability management — dealing with security-relevant flaws in vendor software and your own code and open source code — must run on a faster clock in 2026. The clock disagreement between the camps is about how much faster, not whether. Think 30%+, 2x, 10x or “we are all gonna die”x :-)

• Parrot future: AI compresses the exploit timeline the boring way — faster recon, faster PoC-to-prod exploit code, “commodity” attackers punching above their weight class. Your 30-day patch SLA quietly became a 30-day “we have a front door open, locks what locks” period.
• AGI future: “Patching is dead! The machines will find zero-days continuously!” Fine. Even granting the premise, the conclusion isn’t “give up” — it’s that mitigation and rewriting becomes the whole game.

The universal control: vulnerability management inclusive of mitigation planning (segmentation, “virtual” patching, compensating controls, config weakness scanning, etc) becomes more critical under both futures, not less. Most companies cannot break their “patch sound barrier”, AI or no AI. When you can’t fix the flaw, you’d better be able to contain the blast radius. Note the irony: the AGI camp’s own argument makes the boring VM discipline more important. Funny how that works.

4. Data Security & Sensitive Data Discovery

Both camps should care deeply about knowing where their sensitive data lives, but they lose sleep over different nightmares:

• Parrot future: the risk is leakage and compliance. Employees will lovingly paste source code, PHI, and PII into consumer chatbots to “polish an email.” Regulators do not accept “the parrot ate my data” as a defense. Am I overdoing the “parrot thing” here?
• AGI future: the risk shifts to poisoning and exploitation. An agentic system with access to poorly governed data repositories plus one well-crafted prompt injection equals an AI that cheerfully exfiltrates things it should never have touched.

The universal control: build a real-time, accurate inventory of your sensitive data — and yes, AI-automated sensitive data discovery and mapping is finally real (while in 2016, it largely was not, for most organizations). The uncomfortable truth: most organizations spent two decades not doing data security because it was hard and nobody made them. AI just made “we don’t know where our data is” much more painful, whether you are “camp parrot” or “camp AGI.” Heard this advice before? Yes, you did. So? Did you actually try implementing it? Well, now you need to, parrots or not.

5. Shadow AI Governance & Sanctioned Alternatives

Banning public AI tools is the ultimate security theater — right up there with confiscating USB sticks in 2009 or banning Internet connectivity in 1998 (“but why would you need the internet for work?!”). It doesn’t stop usage; it just moves it to personal phones and personal accounts, where you can’t see it, log it, or ever get the data back.

• Parrot future: employees casually feed proprietary code and PII into consumer LLMs, generating incidents and triggering your lawyercats unnecessarily.
• AGI future: well-meaning developers hand API keys and internal data access to unmonitored shadow agents and creating a sprawling, autonomous attack surface that nobody owns. What fun!

The universal control: stop playing firewall whack-a-mole. Get visibility (CASB and DLP are still a thing, yes, really!), then remove the excuse: offer a sanctioned enterprise AI tool with real contractual data protections. People take shortcuts when the official path is a dirt road. Pave it. And if your ban is still in place in 2026, understand that you don’t have a policy — you have a shadow inventory problem you’ve chosen not to measure.

6. Identity & Access for Agents

Here’s the control nobody had on their 2016 bingo card: least privilege for machines that ask nicely. We barely handled NHI (no, we never did, IRL) and now we have “agent identity” with a pillow fight ongoing on “is agent more like an employee or more like a workload”…

• Parrot future: AI tools and integrations quietly accumulate OAuth grants, service accounts, and long-lived API keys — classic non-human identity sprawl, now with extra steps. Regular NHI problem left unsolved would kill you slowly, the agentic one will work faster.
• AGI future: autonomous agents holding broad credentials become the single most attractive target in your enterprise. Compromise the agent, inherit its permissions — and its work ethic. Tricking an agent to do “a rogue action” is becoming more popular every day…

The universal control: treat every agent, and integration as an identity with a lifecycle (!). Scope it, time-limit it, log it, and review it. Your agents currently have more access than your interns and sometimes less judgment. Fix at least one of those ;-)

7. Environmental Reality Testing vs. Marketing Benchmarks

Model capability benchmarks are largely a mirage if they do not match your realities. A high score on a vendor slide means precisely nothing about your production environment, if you are not them.

• Parrot future: blind trust in claimed accuracy yields silent failures, hallucinations in critical workflows, and surprise data leakage — the parrot passed the exam and still can’t do the job. I am not adding “it will peck you to death”, this is where I draw the line…
• AGI future: deploying an agentic system for consequential autonomous tasks without validation invites systemic, unpredictable behavior — an advanced agent breaking things faster than you can file the postmortem.

The universal control: ignore the brochure. Run internal, multi-run reliability testing and AI red-teaming in your environment with your data before any AI system earns operational duties. Trust is earned in your environment, not on the vendor’s leaderboard. Here’s the provocative version: if your AI procurement process accepts benchmark scores as evidence, your procurement process is part of your attack surface.

Moving Beyond the Debate

And, yes, we could keep adding entries (asset management, IR playbook updates for AI incidents; the list of unglamorous-but-necessary goes on). But you’ve seen the pattern ten times now, so let’s name it.

The two camps diverge violently on timelines and on whether a discontinuous “AGI jump” is coming at all — yet they converge on the near-term necessity of architectural control, every single time. Autonomous agents, supply-chain exposure, machine-speed offense: both worldviews agree these risks are real, present, and demand action today.

When two groups who agree on nothing agree on your homework, the homework is probably real. If I hear one more CISO tell me they are “waiting for the dust to settle on AI” before building a security strategy, I’m going to start charging for therapy. The dust isn’t settling. It’s just turning into more data you aren’t logging.

So the next time someone tells you they can’t build an AI security strategy until the AGI debate settles — smile, nod, and go patch something. The philosophers will still be arguing next Tuesday. Your attackers won’t wait that long.

Summary

• The dichotomy: security leaders split into the “normal technology” camp (from stochastic-parrot cynics to slow-diffusion “pragmatists”) and the “AGI by next Tuesday” believers (and of course less extreme middle too)
• The core thesis: we do not need to settle the philosophical debate. Many of the same fundamental, no-regret controls apply regardless of which future arrives, and the camps’ convergence on near-term controls is itself the strongest evidence those controls matter.
• The no-regret controls:
• Treat configuration hygiene as tier-1 defense — both futures start at your public S3 bucket.
• Monitor both your normal systems under AI attack and the telemetry of your AI systems themselves.
• Accelerate vulnerability management loops, with mitigation planning for the flaws you can’t patch
• Prioritize sensitive data discovery — against leakage (low end) and poisoning/exploitation (high end).
• Replace blanket bans with sanctioned enterprise AI plus visibility.
• Govern non-human identities: least privilege, lifecycle, and logging for every agent and integration.
• Re-engineer threat models and containment for machine-speed intrusions.
• Ignore synthetic vendor benchmarks; mandate local adversarial red-teaming before operational trust.

“AI Normal Tech” vs “AGI by Tuesday”: Security Advice That Survives Either Future was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

For 15 years (!), many of us who have touched cloud security have struggled with the shared responsibility model for cloud security. As with many “cyber things,” the theory is simple. Multiple vendors, consulting firms, and industry bodies have published deceptively clear matrices that depict exactly who is doing what for cloud security.

Everyone likes to present trivial cases: for example, the cloud provider is entirely responsible for the physical security of the data center, while the client is responsible for the application they just built and deployed within that cloud provider’s IaaS. In reality, many of the edge cases continue to cause pain to a lot of organizations.

Ok, so none of this is fundamentally new. However, in recent years, similar and more complex - dare I say sinister?- questions have emerged: What does shared responsibility look like for AI security?

Those who haven’t studied this topic in depth might assume there is no difference. Yet, there are fascinating, critical differences between shared responsibility for AI security and traditional cloud security, along with older related challenges like the shared security of outsourcing (that predate cloud).

Add AI with its probabilistic behaviors, untrusted user inputs, and nested vendor dependencies -and that finger-pointing cycle doesn’t just continue, it scales exponentially. When a customer-facing chatbot goes off the rails, the model provider blames your prompt engineering, the platform provider claims infrastructure isolation worked perfectly, and your internal application team swears it’s an upstream model limitation…

Put simply, what are the top 3 differences between shared responsibility for AI vs cloud? In my opinion:

1. A Broader Spectrum of Risk: The range of harms and risks we must consider is much wider. Shared responsibility for AI security frequently touches upon safety, privacy, ethical use, and the unique risk surfaces that emerge specifically in conversations about AI.
2. The Multi-Party Supply Chain: AI security is typically far more multi-party than traditional cloud security. For instance, one company builds the foundational model, another company fine-tunes it, a third party builds a Retrieval-Augmented Generation (RAG) architecture for you, and yet another party builds the consumer-facing application.
3. Non-deterministic Behavior: Unlike traditional cloud infrastructure where secure configurations yield predictable, deterministic outcomes, AI systems are non-deterministic. Because outputs can vary significantly based on user inputs, customers bear increased responsibility for implementing robust guardrails, continuous monitoring, and input/output filtering.

Early attempts to create a logical foundation for AI shared security responsibility produced some answers — and more questions.

In light of this being a tricky problem, here I really want to focus on one thing — a post-incident scenario. While shared responsibility covers numerous use cases (and numerous sources of confusion…), let’s examine a fairly straightforward situation: I am an enterprise end-user company that uses (maybe builds, maybe tunes, etc) AI in some form, then something blows up (digitally, as this is not IoT/ICS security blog). So:

• Who takes a loss vs who is to blame?
• Do I blame the model creator? The application developer? The model hosting platform? Or do I ultimately blame myself?

If you recall, many early challenges with the cloud shared responsibility model began with customers trying to blame the provider, only to discover they were actually at fault in the end. We tried to change this dynamic by introducing a “shared fate” model. While that specific terminology has seemingly fallen out of favor lately, the underlying philosophy remains: providers can probably do more to make AI usage inherently secure.

I was recently involved with a CoSAI (Coalition for Secure AI) working group to develop a paper covering the shared responsibility framework for AI security. As others on the team humorously pointed out, my voice was one of the loudest calling for the paper to be kept simple, crisp, and highly usable. You can judge based on the final result whether we succeeded.

We recently wrapped up and approved Version 1.0 of the CoSAI AI Shared Responsibility Framework (AI SRF) through the Coalition for Secure AI and OASIS Open. The core mission here wasn’t to build more abstract compliance theater, but to solve a practical, glaring operational pain point: Who actually owns what when an AI system fails?

Under the CoSAI framework, accountability traces down the stack with absolute clarity:

• The AI Model Provider (L5) is accountable for the base model’s inherent susceptibility to prompt injection and must document those boundaries explicitly within the model card.
• The Cloud/Platform Provider (L4) is accountable for the blast-radius containment, ensuring infrastructure-level tenant process isolation held firm during the exploitation.
• The Application Developer (L3) is accountable for failing to enforce application-level guardrails, input filtering, and localized data access controls that allowed the chatbot to hit the PII repository in the first place.
• The Deploying Organization (L1/L2) is accountable for the ultimate governance failure: they did not properly classify the data or restrict the chatbot’s system-level access boundaries before pushing it live.

Also, the paper included a phased Implementation Playbook in the document to give security teams a somewhat specific path forward:

1. Phase 1 (Days 1–30): Map your entire AI system inventory and cross-reference vendor contracts against these five layers to highlight immediate responsibility gaps.
2. Phase 2 (Days 31–90): Establish a cross-layer governance committee and formally update vendor procurement contracts with clean, explicit accountability matrices.
3. Phase 3 (12 Months): Run layer-specific tabletop simulations to stress-test your incident response playbooks before an actual threat actor tests them for you.

Fun quotes:

• “Ambiguous ownership is a growing liability for Al system deployments.” [A.C. — filed under ‘no shit, Sherlock’]
• “Without explicitly assigned owners for detection, containment, and remediation, teams default to the finger-pointing cycle” [A.C. — this will get worse, then MUCH worse, then eventually better…]
• “The framework turns ‘whose fault is this?’ into ‘which layer’s controls failed, and who owns remediation for each?’” [A.C. — this is beautifully, I probably wrote this :-)]
• “There should be exactly one accountable party per component to prevent overlaps.” [A.C. — ideal world called, it wants its problem back! Real world picked up and said ‘get lost’]
• “Clear accountability eliminates finger-pointing during incidents” [A.C. — clear evidence that Captain Obvious is alive!]

More seriously, read the paper!

In the end, I hope this work enlightens people on just how complex this problem truly is. This paper is definitely not a silver bullet that solves everything overnight; we have years of discussions and evolving challenges ahead of us down this path. However, I think this paper serves as an excellent first step. Please make sure to check out the resources listed at the end of the paper as well (a lot of gems there!)

Related blogs:

• Who’s Responsible When AI Goes Wrong? A New Framework Aims to Answer That Question
• Where Does Shared Responsibility Model for Security Breaks in the Real World?
• No Snow, No Flakes: Pondering Cloud Security Shared Responsibility, Again!
• EP203 Cloud Shared Responsibility: Beyond the Blame Game with Rich Mogull
• EP145 Cloud Security: Shared Responsibility, Shared Fate, Shared Faith?
• Who Does What In Cloud Threat Detection?
• The Cloud Shared Irresponsibilities Model

From Cloud to Chaos: Defining Shared Responsibility for AI Security was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

Blogs

Blog

America250 Fourth of July Threat Assessment

In this post we break down the intersecting cyber risks, physical security strains, and operational challenges shaping the security landscape for the historic Semiquincentennial celebrations.

SHARE THIS:

Flashpoint Intel Team

June 30, 2026

Table Of Contents

Table of Contents

Key Takeaways

Physical Threat Vectors

Cyber Threat Vectors

Protect People Using Flashpoint

More

The Complete Guide to OSINT for Executive Protection

Download Now

As the United States prepares to mark its 250th anniversary this Fourth of July, the convergence of historic national celebrations, sprawling public events, and simultaneous high-profile sports tournaments is creating an exceptionally complex threat landscape. The multiyear national initiative “America250,” features over 1,200 synchronized grassroots gatherings under the “America’s Block Party” umbrella, with flagship events taking place in Washington DC, Philadelphia, Boston, New York, and Los Angeles.

Key Takeaways

While public sentiment surrounding America250 remains broadly positive, Flashpoint analysts have assessed the physical, cyber, and operational threat vectors that organizations, security teams, and municipalities must navigate during this high-visibility holiday weekend.

America250 Threats & Security Challenges:

1. Distributed Physical & Infrastructure Strain: Massive tourism influxes will collide with ongoing 2026 FIFA World Cup matches in Houston and Philadelphia on July 4, putting historic operational pressure on metropolitan transit grids and soft targets.
2. Elevated Iconicity and “City of Concern” Status: Although no specific, credible plots have been confirmed, the National Mall events in Washington, DC have received their first-ever National Special Security Event (NSSE) designation. Meanwhile, the National Counterterrorism Center (NCTC) has officially designated Philadelphia a “city of concern” due to the volume of synchronized events.
3. Ideological Protest Dynamics: Activist groups are organizing a significant anti-authoritarian march in Philadelphia. While expected to be peaceful, open-source chatter indicates a portion of attendees plan to exercise their license to carry firearms.
4. Disruption & Cyber Threat Vectors: Cyber threat groups, ransomware operators, and hacktivists are expected to attempt to exploit thin holiday IT staffing. Threat vectors range from mass public-transit ticketing fraud to high-consequence digital hoaxes involving rogue cellular infrastructure.

Physical Threat Vectors

Transportation and Infrastructure

Flashpoint assesses that “lone wolf” actors motivated by various ideological grievances, including those inspired by foreign terrorist organizations (FTOs), pose the most likely threat of disruptions to transportation infrastructure during America250 events. This threat is likely to apply to all major transport hubs during the event, including Washington DC, Philadelphia, New York City, and Boston. Attendees can expect to see an increased police and military presence near transit hubs at major events.

Event Threats

While no specific credible threats targeting America250 events have been identified, the July 4th events taking place on the National Mall in Washington DC, have been given a National Special Security Event designation, which is typically reserved for events deemed potential targets for terrorism or other criminal activity. This is the first time such a designation has been given to July 4th celebrations on the National Mall.

Memos released by the National Counterterrorism Center to security agencies also identified Philadelphia as a “city of concern” regarding potential targets for terror attacks due to the number and scale of events taking place on July 4th. Law enforcement officials have indicated that while no specific threats have been identified, increased security measures will be in place throughout the city.

Planned Protest

The Fayetteville Resistance Coalition, alongside Veterans Against Fascism, and the Women’s March is organizing an anti-authoritatian protest march in Philadelphia on July 4th—being the largest mobilization of military veterans in decades.

Flashpoint has identified chatter indicating that march attendees may be armed. However, Flashpoint has not identified any calls for violence at this protest and deem that actions will likely remain peaceful. Despite this, arrests may be possible if attendees gather in unauthorized areas or engage in civil disobedience.

Cyber Threat Vectors

Ransomware and Operational Technology (OT) Disruptions

Financially motivated threat actors frequently deploy ransomware during major US holiday weekends when corporate and municipal IT security staffing is historically thin.

Flashpoint analysts assess that attackers could target automated ticketing systems, regional rail signaling, and digital municipal transit grids. Disruption to public transit during the high-density travel window surrounding major events could induce logistical gridlock. Secondary targets include municipal water treatment facilities, local power grids, and emergency response (911) dispatch systems in primary host cities.

Hactivism

With hundreds of thousands of spectators gathering at prominent national landmarks, hacktivist groups seeking political leverage or global media visibility pose an elevated threat to public messaging infrastructure.

Compromising the digital billboards, stadium screens, or viewing decks used for America250 events presents an attractive vector for defacement. Adversaries may attempt to display political propaganda, anti-war messaging, or explicit content to captive, high-density crowds.

Event App Vulnerabilities and Data Harvesting

The decentralized nature of “America’s Block Party,” featuring over 1,200 grassroots events managed via localized apps, introduces software supply chain vulnerabilities.

Cybercriminals may target the ticketing infrastructure of high-profile, restricted-access events. Phishing campaigns, credential stuffing, or application programming interface (API) vulnerabilities within event-specific mobile applications could result in mass ticketing fraud, legitimate attendees being locked out, or crowd-control issues at venue gates.

Additionally, malicious actors frequently deploy spoofed public Wi-Fi networks around high-density tourist hubs to harvest sensitive personal data, financial credentials, and biometric profiles from unsuspecting attendees.

Protect People Using Flashpoint

To ensure attendee safety, safeguard operations, and protect public-facing brands, Flashpoint recommends implementing the following proactive measures:

1. Secure Public-Facing and Display Infrastructure: Implement strict access controls, multi-factor authentication (MFA), and offline fail-safes for all internet-connected digital signage, stadium screens, and public notification systems to prevent hacktivist defacements.
2. Audit Event Applications and Mobile Endpoints: Conduct rigorous vulnerability scans on event-specific APIs and ticket validation platforms. Advise personnel and contractors against posting photographs of official credentials, badges, or operational passes on public social media channels.
3. Establish Out-of-Band Incident Response Protocols: Prepare alternative communication channels and verified public-address messaging to immediately counter potential rogue emergency broadcasts, digital hoaxes, or localized telecom disruptions that could cause public panic.
4. Monitor High-Risk Overlap Zones: Cross-reference physical security deployment schedules in cities like Philadelphia where World Cup traffic, official America250 parades, and armed protest routes intersect near major transit networks.

Ensure your security team has full visibility into the cyber and physical threat vectors shaping this historic holiday weekend. Request a demo and see how Flashpoint equips organizations with the intelligence needed to detect, analyze, and mitigate emerging risks.

The post America250 Fourth of July Threat Assessment appeared first on Flashpoint.

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].

Malicious streaming devices sold online that enroll the user’s home Internet address in a residential proxy service. Image: HUMAN Security.

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).

Image: F6S.com.

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.”

Synthient’s platform receiving outbound traffic from Popa. Image: Synthient.com.

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).

NetNut and other proxy services have recast themselves as critical infrastructure for the AI scraping economy. Image: Synthient.com.

“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.

Image: Spur.us.

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.

Piracy related apps pushing proxy SDKs onto unconsenting users. Image: Synthient.

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.

Click here to download the guide today. Visit Executive Edge, our C-level thought leadership platform, for more insights for EMEA CXOs.

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.

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.