For years, cyber resilience has been defined by technology – security controls, sophisticated detection capabilities, and increasingly robust backup strategies designed to prevent attacks or recover more quickly. Those investments remain essential, but they are no longer enough. 

AI has fundamentally changed the nature of cyberattacks, which now move at a speed that challenges even mature organizations. As the window between compromise and business disruption continues to shrink, resilience is becoming less about preventing every attack and more about keeping the enterprise running when prevention inevitably falls short. 

That shift is at the heart of IDC’s new report, Resilience Operations: The Discipline that Makes Readiness Provable. Based on a survey of more than 500 North American organizations, the report argues that resilience is evolving into a cross-functional operating discipline that connects business priorities with cybersecurity, ITOps, and disaster recovery. More importantly, it reveals several gaps that suggest many organizations are still preparing for a threat landscape that no longer exists. 

Here are the insights that stood out. 

Recovery should begin with business outcomes – not technical ones.

Historically, recovery planning has focused on restoring infrastructure as quickly as possible, with success judged by recovery time objectives, backup completion rates, and application availability. While those measures remain valuable, they don’t necessarily answer the question executives care about most: When can we get the business back online? 

IDC argues that resilience should be anchored to business outcomes rather than technical milestones – restoring the capabilities that allow the organization to serve customers, generate revenue, and meet its obligations. That may sound like semantics, but it changes how recovery priorities are established. Technology becomes the means to an end rather than the end itself. 

Most organizations still haven’t defined what matters most.

Nearly 6 in 10 organizations have not fully defined their minimum viable business (MVB) – the smallest set of functions, systems, processes, and data required to continue operating after a disruption. 

Without a shared understanding of what the business truly depends on, every movement during recovery becomes reactive. By defining your MVB before a crisis, you’ll enable faster decisions, better coordination during recovery, and ultimately a more resilient organization. 

Automation is becoming the dividing line between resilience and recovery debt.

While attackers increasingly automate reconnaissance, exploitation, and lateral movement, many organizations still rely on manual recovery processes. 

That imbalance is becoming increasingly difficult to ignore. AI is compressing attack timelines, but recovery timelines have not kept pace. Organizations that fail to automate these recovery tasks may find themselves spending days assembling and executing plans while the damage has already been done. 

Automated recovery orchestration, clean recovery point identification, and coordinated validation are becoming foundational capabilities for recovering at the speed modern attacks demand. 

Technology isn’t the biggest resilience challenge – organizational alignment is.

Security teams focus on containment, infrastructure teams focus on restoration, business leaders focus on customer impact, and compliance teams focus on regulatory obligations. None of these priorities are inherently wrong, but when they evolve independently, organizations enter a crisis without a shared operating model. 

Enter ResOps. Rather than positioning resilience as an IT responsibility, the report frames it as a discipline that deliberately brings together business, security, infrastructure, and recovery planning. The message is clear: Resilience depends less on individual tools than on creating shared priorities before an incident forces you to make difficult decisions. 

Testing remains one of the strongest indicators of resilience.

IDC found that relatively few organizations conduct frequent tabletop exercises or cyber-range simulations, despite decades of evidence showing that rehearsal consistently improves performance during real incidents. 

Exercises reveal hidden dependencies, expose communication gaps, and allow teams to make decisions without the real consequences. Organizations that repeatedly validate their recovery processes develop a level of confidence beyond planning alone. 

Tomorrow’s resilience challenges are already taking shape.

Ransomware still dominates headlines, but the next resilience challenges have already emerged – from agentic AI and machine identities to post-quantum cryptography. 

These threats remind us that resilience planning can’t focus exclusively on today’s infrastructure. Recovery increasingly involves cloud services, SaaS applications, AI models, machine identities, third-party providers, and distributed digital ecosystems that didn’t exist a decade ago. 

Resilience is becoming measurable.

IDC’s ResOps Maturity Model is invaluable for assessing your organization’s current posture. Rather than treating resilience as something organizations either possess or lack, the framework describes a progression from reactive, siloed operations to mature, adaptive resilience built on governance, automation, and continuous improvement. 

To me, that progression acknowledges an important reality: Resilience is never finished. It’s not about purchasing a platform or completing a project. Organizations become resilient by continually improving how technology, people, and business processes work together under pressure. 

Viewed through that lens, resilience becomes less like insurance and more like operational excellence – a capability that can be assessed, strengthened, and demonstrated over time. 

We’re undergoing a broader shift in how organizations think about resilience.

Resilience conversations are evolving from protecting infrastructure to protecting the business itself. That means recovery planning starts with customers instead of servers, governance becomes as important as technology, and confidence comes from proving capabilities rather than documenting intentions. 

ResOps isn’t really a new framework; rather, it’s a broader recognition that cyber resilience has become an operational discipline. As attacks become faster and more complex, resilience will be measured not by the absence of incidents, but by an organization’s ability to continue serving customers, supporting employees, and maintaining trust despite disruption. 

That’s ultimately what ResOps is designed to prove. 

Rajiv Kottomtharayil is Chief Products Officer at Commvault. 

Key Takeaways

• Trust in the age of AI isn’t disappearing – it’s evolving.
• Organizations need to verify AI continuously rather than trust it by default.
• AI adoption should empower employees, not push them toward shadow AI.
• Zero trust isn’t about distrusting people. It’s about continuously validating identities, devices, and actions.
• Responsible AI adoption requires technology, governance, and people working together.

When we launched Ready. Or Not., we wanted to create a series that made some of today’s biggest AI conversations easier to understand. By pairing comedian Nathan Macintosh with industry experts, we’re exploring everything from agentic AI and cyber resilience to data management – and adding a little humor along the way.

If you caught our first episode on the opportunities and risks of agentic AI, I think you’ll enjoy this one as well. This time, we’re tackling a topic that’s at the center of every AI conversation: trust.

Nathan sits down with Diana Kelley, Chief Information Security Officer at Protect AI, for a conversation about what it means to trust technology when AI can generate convincing fake content, make decisions, and even imitate people. From deepfakes and hallucinations to zero trust and shadow AI, they explore how organizations can embrace AI without losing confidence in their people and systems.

Watch the full episode on Readiverse.

I walked away from this episode feeling more optimistic than I expected. Not because AI is suddenly more trustworthy, but because Diana shows us that trust grows when organizations put the right policies, guardrails, and technology in place. Here are some themes from the conversation that put AI in a new perspective.

Trust and Technology Can Co-Exist

Diana believes trust is possible in the AI era, but it’s going to look different. We’ve always built trust through relationships with people. Now, we’re learning how to extend that trust to systems.

That doesn’t mean trusting technology blindly. It means understanding how AI works, recognizing its limitations, and putting the right safeguards in place so people and technology can work together with confidence.

“Trust has to evolve for the new world.”

– Diana Kelley

What resonated with me was the idea that trust and technology don’t have to be at odds with one another. With the right approach, they can strengthen each other.

We’re Getting Smarter About AI

Deepfakes have become one of the most talked about AI risks, and it’s easy to understand why. AI can now generate convincing voices, images, and videos that make us question what’s real. But Diana pointed out that while AI is getting more sophisticated, people are getting smarter. We’re more likely to question an unexpected phone call, take a closer look at a social media post, or pause at something that doesn’t feel quite right.

Organizations are becoming savvier, too. As AI gets better at impersonation, businesses are investing in new ways to continuously verify identities and validate information. My takeaway is this: Technology will continue to improve, but so will our ability to recognize it and respond responsibly.

“Is today a good day to start a deepfake?”

– Nathan Macintosh

Responsible AI is Good for Business

Diana shared an example that will probably sound familiar to many organizations. An employee she calls “Karen in Finance” starts using AI because it helps her complete a task in minutes instead of hours. Karen isn’t trying to work around company policy – she’s trying to be more productive.

Employees use AI because they see real value in it, and that’s an opportunity for organizations. When employees have access to approved AI tools, supported by clear policies and practical guidance, they can work more efficiently while helping protect company data and systems.

Sneak Peek: Smarter AI Adoption

The goal isn’t to stop employees from using AI. It’s to make sure they’re using it the right way. Diana explains how organizations can encourage AI adoption without creating unnecessary risk.

Zero Trust Matters More Than Ever

“When you understand how things work, then you can start to understand how to manage them.”

– Diana Kelley

Zero trust is one of those concepts that’s much easier to understand with an analogy. Diana has a great one. She describes it as moving through a building. Just because you’ve been allowed through the front door doesn’t mean every other door automatically opens for you. Each time you access a new room, there’s another quick check to confirm you’re supposed to be there.

That’s essentially how zero trust works. Instead of assuming a person or device is trustworthy after a single login, organizations continuously verify identities, devices, and actions as technology becomes more connected. Most of those checks happen quietly behind the scenes.

One of the things I appreciated about Diana’s explanation is that zero trust doesn’t feel like another security buzzword. It feels like a practical way to think about trust in a world where AI and digital identities are becoming part of everyday business.

Trust Is About People

At the end of the day, technology doesn’t create trust – people do. People define the policies, processes, and ethical boundaries that guide how AI is used, while technology helps verify that those guardrails are working as intended. It’s that partnership between people and technology that makes responsible AI possible.

Trust extends beyond our own organizations. Businesses need confidence in the partners they work with, the systems they connect to, and the technologies they adopt. That’s why transparency, shared standards, and continuous verification are becoming just as important as innovation itself. The more AI becomes part of everyday business, the more trust becomes everyone’s responsibility.

Looking Ahead

AI will continue to evolve, and so will the way we interact with it. The organizations that succeed won’t be the ones that trust AI blindly or avoid it altogether. They’ll be the ones that build strong policies, adopt the right technologies, and continuously verify the systems they rely on.

Trust isn’t something we lose as technology advances. It’s something we intentionally build and evolve. That’s exactly the kind of conversation we hope to continue with every episode of Ready. Or Not.

Watch the full episode on Readiverse.

FAQs

Q: What is digital trust?

A: Digital trust is the confidence that people, systems, and organizations are who they claim to be and are acting in expected, secure ways. It combines technology, governance, and verification to help organizations interact safely.

Q: What are deepfakes?

A: Deepfakes are AI-generated images, videos, or audio recordings designed to closely imitate real people. While they have legitimate uses, they can also be used to impersonate individuals or commit fraud.

Q: What is zero trust?

A: Zero trust is a security model based on continuous verification rather than automatic trust. Instead of assuming a user or device is trustworthy after one login, organizations continuously validate identities and actions.

Q: What is shadow AI?

A: Shadow AI refers to employees using AI tools that haven’t been approved or governed by their organization. While often well-intentioned, it can introduce security, privacy, and compliance risks.

Q: Why shouldn’t organizations simply block AI tools?

A: Employees typically adopt AI because it helps them work more efficiently. Rather than banning AI outright, organizations should provide approved tools, establish clear policies, and educate employees on responsible use.

Q: What’s the biggest takeaway from this episode?

A: Trust isn’t disappearing because of AI – it’s evolving. Organizations that combine people, policies, and technology with continuous verification will be better positioned to adopt AI confidently and responsibly.

Katherine Demacopoulos is Senior Director of Global Content Strategy and Programs at Commvault.

Our Chief Products Officer, Rajiv Kottomtharayil, recently wrote about a big shift that is taking place across industries. Frontier AI models are compressing the time between vulnerability discovery and exploitation.  

This shift is prompting organizations everywhere to re-examine their vulnerability management processes. We’re doing the same at Commvault. That’s why, starting August 11, we’re changing the rhythm of how we disclose vulnerabilities.  

What’s Changing

We are raising the bar for security, transparency, and customer trust. On August 11, and on the second Tuesday of each month after that, we’re introducing Patch Tuesdays: a scheduled monthly release where we share security advisories and vulnerability patches.  

Patch Tuesdays are a hallmark of leading technology companies, because they provide customers with a predictable security rhythm.  This matters even more as the pace of vulnerability discovery accelerates. Of course, if there is an urgent vulnerability that must be reported off cycle, we will not hesitate to follow our well-established processes.  

Where You Can Find Up-to-Date Resources  

On the second Tuesday of each month, you’ll find new information pertaining to CVEs on our Security Advisories page. You also can find the official publications at MITRE’s CVE site. 

On the Commvault Security Center, you’ll find our vulnerability management program and other security-by-design thought leadership.   

For compliance certifications, audit reports, and documentation on how Commvault protects customer data, visit the Commvault Trust Center. You can subscribe to updates from the Trust Center at the link in the upper righthand corner of the page. 

Bill O’Connell is Chief  Security Officer at Commvault. 

For decades, technology leaders have been trying to eliminate silos. Entire modernization programs have been built around connecting applications, consolidating platforms, and giving organizations a more complete view of their data.

Those efforts have delivered enormous value, but they also have shaped the way we think about resilience. When something goes wrong, we instinctively look for technical fragmentation. However, we’ve found the greater challenge lies elsewhere.

The most significant silos affecting cyber resilience today aren’t found in databases or applications but in organizational structures. They exist between security and infrastructure teams, between IT and the business, and between the people responsible for responding to an attack and those responsible for keeping the organization operating.

IDC’s latest research on ResOps, Resilience Operations: The Discipline that Makes Readiness Provable, suggests these organizational boundaries have become one of the defining obstacles to effective recovery. That’s a timely observation because cyberattacks have evolved in ways that can make those boundaries increasingly difficult to maintain.

Modern Attacks Don’t Follow Your Org Chart

A modern cyberattack rarely affects a single technology domain. A ransomware incident might begin with compromised identities, spread through cloud infrastructure, encrypt critical workloads, disrupt customer-facing applications, impact third-party services, and trigger regulatory reporting requirements – all within a matter of hours. Every stage involves different teams, different tools, and different priorities.

Yet many organizations still prepare for recovery as though these responsibilities can be managed independently.

Security teams naturally focus on containing threats and preserving evidence. Infrastructure teams prioritize restoring systems and minimizing downtime. Business leaders concentrate on customers, revenue, and operational continuity. Communications teams think about reputation, while legal and compliance teams focus on regulatory obligations.

Each perspective is entirely reasonable. The problem arises when those priorities have never been reconciled before an incident occurs.

In the middle of a crisis, recovery requires decision-making under pressure. Which applications should return first? Which data can safely be restored? How much risk is acceptable before customer services resume? Who has the authority to make those decisions?

Without alignment, organizations often discover that the greatest delays aren’t caused by technology but by uncertainty – the kind that could be mitigated by better preparation.

Resilience Begins with a Shared Definition of What Matters

The report places emphasis on establishing your minimum viable business (MVB). At first glance, it appears to be another recovery planning exercise, but its real value lies in the conversations it forces organizations to have.

Defining an MVB requires business leaders, security teams, infrastructure specialists, and application owners to agree on a deceptively simple question: What absolutely must continue operating if everything else stops?

That discussion changes the nature of resilience planning. Recovery priorities are no longer determined by whichever application owner argues most convincingly during an incident. Instead, they are established in advance, grounded in business outcomes, and supported by technical dependencies that everyone understands.

Perhaps more importantly, MVB creates a common language. Business leaders begin talking about critical capabilities rather than individual systems. Technology teams begin mapping infrastructure to customer outcomes rather than technical architectures. Security teams gain greater clarity about which assets deserve the highest levels of protection during recovery.

That shared understanding is precisely what many organizations have been missing.

Technology Can Automate Recovery – But it Can’t Create Alignment

The report doesn’t argue that organizations need yet another platform. It argues they need a way of working that aligns people, processes, and technology around a single operational objective. This is where ResOps – a cross-functional discipline – proves its mettle.

Technology can help automate recovery, but it cannot resolve disagreements about business priorities. It cannot decide which customer services matter most. And it cannot replace the governance needed to coordinate multiple teams during a high-pressure event.

Those are leadership challenges, and they are best addressed by investing time in answering the difficult questions together, long before an attack forces your hand.

The Strongest Organizations Don’t Eliminate Silos – They Connect Them

Cyberattacks will continue evolving. AI will continue compressing attack timelines. New technologies will introduce new dependencies, and new threats will emerge alongside them. None of that changes the fundamental requirement for resilience.

Organizations don’t recover because individual teams perform brilliantly in isolation, but because those teams already know how to work together.

That may ultimately be the most important insight from IDC’s research. Resilience isn’t simply the product of better technology or more sophisticated security controls. It is the result of shared priorities, clear governance, and a tested operating model that brings the right people together before an incident occurs.

Vidya Shankaran is Field CTO at Commvault.

Key Takeaways

• A CVE is a globally unique identifier for a publicly disclosed software vulnerability, enabling vendors, researchers, and defenders to reference the same consistently.
• An organization’s approach to vulnerability disclosure – including coordinated fixes, researcher engagement, and accurate software inventory – is a strong indicator of overall security maturity.
• Commvault protects its customers with a CVE program of transparency, cadence, and clarity. CVE disclosure says a great deal about the maturity of a security and engineering program.

Why This Matters

Many breaches that reach the boardroom trace back to vulnerability in software. The mechanism the entire industry uses to name and describe those vulnerabilities is the CVE, Common Vulnerabilities and Exposures.

How a vendor, or your own organization, handles CVEs is one of the clearest signals of security maturity.

A company that discloses and credits researchers fairly is usually a company that takes underlying engineering seriously. This blog explains how a CVE is built, who runs the system, and what separates an exemplary disclosure from a poor one.

Beyond the CVE: Why Disclosure Philosophy Matters

Publishing a CVE is table stakes. The differentiators are: transparency of the vulnerability and patch, regular scans and patching, and clear communication.

Commvault treats disclosure as an engineering and security discipline rather than a compliance checkbox: Establish a cadence for code review and remediation, communicate the fix in plain language, and protect our customers. That consistency, more than any single score, is what CVE disclosure says about security maturity.

What a CVE Actually Is

A CVE is not a patch, a score, or a piece of malware. It is a dictionary entry that gives one specific, publicly known vulnerability a permanent, unique name so that everyone can refer to it.

The identifier itself follows a simple, durable format: the letters CVE, the year the ID was assigned, and a sequence number, for example, CVE-2021-44228.

The scale of the program is enormous, and still growing: 48,000 CVEs were published in 2025, on the order of 132 per day, up more than 260% since 2020.

The Anatomy of a Single Record

CVE publications require a consistent set of elements. Reading one is straightforward once you know what each part is for:

• Identifier, the unique CVE-YYYY-NNNNN
• Description, a concise explanation of the vulnerability: what it is and how a threat actor could exploit it.
• Affected products and versions, which software, hardware, or firmware (and which versions) are impacted, and which versions contain the fix.
• Criticality, the underlying category of criticality.
• References, links to the vendor advisory, the patch, and technical write-ups.

The Supporting Cast: CVSS, CWE, EPSS, and KEV

Four companion systems turn a CVE into something a business can prioritize. They are easy to confuse, so the distinction is worth holding onto:

• CVSS (Common Vulnerability Scoring System) answers “How severe is it?” CVSS is the severity rating (1–10, 10 being the most severe) of the flaw, not a measurement of your specific exposure.
• EPSS (Exploit Prediction Scoring System) answers “How likely is this to be exploited soon?” EPSS produces a probability score, from zero to 100 percent, estimating the likelihood that a vulnerability will be exploited in the next 30 days.
• CWE (Common Weakness Enumeration) answers “What kind of mistake caused it?” The CWE classifies the underlying coding weakness.
• KEV (Known Exploited Vulnerabilities) answers “Is it being used against people right now?” The KEV catalog is a curated list of CVEs with confirmed real-world exploitation.

A high CVSS score tells you how serious a vulnerability could be, a high EPSS score tells you how soon it is likely to be exploited, and a listing in the KEV catalog confirms exploitation is already happening. The best vulnerability programs weigh all three.

FAQs

Q: What is a CVE, and why is it important?
A: A Common Vulnerability and Exposure (CVE) is a standardized identifier assigned to a publicly disclosed software vulnerability. It enables everyone – from vendors and researchers to regulators and customers – to refer to the same vulnerability without ambiguity.

Q: What information should a well-formed CVE record contain?
A: A complete CVE record requires a unique identifier, a description of the vulnerability, affected products and versions, the criticality type, and references to vendor advisories or patches. These elements enable organizations to understand their exposure and respond efficiently.

Q: How do CVSS, CWE, EPSS, and KEV differ from a CVE?
A: A CVE identifies a specific vulnerability, while CVSS measures its severity, EPSS estimates the likelihood of near-term exploitation, CWE classifies the underlying coding weakness, and KEV identifies vulnerabilities that are actively exploited in the real world. Together, these frameworks help provide the context needed to prioritize remediation.

Q: What does Commvault look for in its own disclosure practices?
A: Commvault holds its own disclosures to the same standard it expects of others: transparency, cadence and clarity. That is how Commvault protects its customers.

Q: What should business leaders evaluate when assessing vendors’ vulnerability management practices?
A: Leaders should look for coordinated disclosure timelines, comprehensive and accurate CVE records, clear remediation guidance, robust reporting programs, and the ability to quickly determine whether products are affected by newly disclosed vulnerabilities. These characteristics reflect a strong security culture and improve organizational resilience.

Werner Nel is Principal Product Experience Manager at Commvault.

Key Takeaways

• JadePuffer is the name security researchers at Sysdig gave to what they assessed as the first documented ransomware operation driven end-to-end by an autonomous AI agent, not a human working through a toolkit.
• The individual techniques weren’t new. What changed was orchestration speed: The agent chained reconnaissance, credential theft, lateral movement, and destructive encryption, correcting a failed login attempt in 31 seconds.
• The agent generated its own encryption key, then never stored or transmitted it. Paying the ransom would not have restored the data.
• The real damage targeted configuration state and control-plane systems, not just files, which is exactly the layer most recovery plans don’t cover.
• Recovering from an attack like this means proving the business can safely resume operations, not just restoring a backup.

What Happened

In mid-2026, security researchers at Sysdig documented an extortion campaign they believe is the first of its kind: a ransomware operation carried out end-to-end by a large language model agent, with minimal human hands-on-keyboard involvement. They named it JadePuffer.

The entry point was familiar. The attacker exploited CVE-2025-3248, an unauthenticated remote code execution flaw in Langflow, an open source framework for building AI agent workflows, running a version older than 1.3.0. From there, the agent enumerated the host, searched for credentials across cloud providers, AI model vendors, and databases, and quietly dumped the platform’s own backing database.

What happened next is the part worth paying attention to. The agent scanned the internal network, found an exposed object store, and pulled Terraform state and configuration files. It set up a scheduled task to call home every 30 minutes. Then it pivoted to a separate production system running MySQL and Alibaba Nacos, a configuration and service-discovery platform common in microservice architectures.

Once inside, the agent tried to create an administrator account in Nacos. It failed. Thirty-one seconds later, it had diagnosed the failure and succeeded with a different approach. It then used MySQL’s file-handling functions to probe whether it could escalate further, before encrypting more than 1,300 configuration records, dropping the original tables, and leaving a ransom note behind.

The encryption key was generated on the fly, displayed once, and never stored anywhere the attacker could retrieve it again. Whether or not that was intentional, the outcome for the victim is the same: There was no path back through the attacker or a decryption key, ransom paid or not. Recovery would depend on clean backups, rebuild, or validated recovery points.

Why Researchers Are Calling This “Agentic”

None of the individual techniques here are new. Exploiting an unpatched CVE, harvesting credentials, scanning for lateral movement, encrypting data for extortion: Security teams have seen every one of these before. What made Sysdig classify the operator as agentic rather than a conventional attacker is how the steps fit together.

The agent didn’t run a fixed script. It observed results and adjusted. When it expected a JSON response and got XML back, it changed its approach and kept going. When its first attempt to create an admin account failed, it diagnosed the specific failure and tried something different, in under a minute.

Researchers also found comments embedded in the payloads, explaining targets and next steps in simple language, a pattern more consistent with an LLM reasoning through a task than a human copying and pasting a known exploit kit.

Public reporting hasn’t confirmed which model or platform powered the attack. What’s confirmed is the behavior: Something reasoned, acted, hit a wall, and corrected course faster than most human-paced incident response can move.

The Recovery Problem Too Many Frameworks Still Miss

Most ransomware playbooks are built around a specific assumption: something encrypted your files, and the question is whether you can restore a clean backup or need to negotiate a decryption key.

JadePuffer breaks that assumption in two ways. First, there was no decryption key to negotiate for. Second, the damage wasn’t only in the data. It was in the configuration and control-plane layer underneath the data: the service-discovery platform, the secrets it held, the Terraform state describing how the infrastructure fit together, and the credentials scattered across every system the agent touched on the way there.

That’s a harder recovery problem than “restore the database.” A clean file restore into an environment with rotated-but-not-verified credentials, unreviewed configuration drift, and an identity layer nobody has re-audited isn’t really a clean recovery. It’s a fresh copy of the data sitting inside a system that still can’t be trusted.

What This Means for Your Resilience Strategy

JadePuffer is a preview of the question every recovery plan will eventually have to answer: Can you resume operations when an attacker has touched not just your data, but the identity, configuration, and control-plane systems that data depends on?

A few places to start:

Treat configuration and control-plane systems as recovery-critical, not just applications. Service discovery platforms, secrets stores, and infrastructure-as-code state are as business-critical as the databases they configure. If they aren’t in your recovery plan today, that’s the first gap to close.

Build credential hygiene into recovery, not after it. Restoring a workload that reintroduces compromised secrets doesn’t end the incident; it resets the clock on it. This is the same discipline Commvault applies to identity infrastructure today: vulnerability assessment to see exposure before an attacker does, real-time auditing to catch changes as they happen, and rollback to undo unauthorized changes without rebuilding from scratch.

Validate before you restore, not after. A restore point is only useful if you know it’s clean. That’s the logic behind Commvault® Cleanroom™: testing and validating data in an isolated environment before it ever touches production again, rather than finding out after reinfection.

Plan for a control-plane compromise, not just a file-encryption event. A recovery journey map built only for “encrypted files, restore from backup” won’t hold up against an incident like this. The more useful question, and the one at the center of ResOps (resilience operations) as an operating discipline, is what it takes to reach minimum viable operations when the systems underneath your applications are the ones that got hit.

None of this requires treating agentic AI as an unprecedented threat that demands starting from zero. It requires extending the same resilience discipline that already applies to identity and data, down into the configuration and control-plane layer that agentic attacks are now targeting directly.

Learn more about how Commvault approaches identity resilience and clean recovery validation.

FAQs

Q: What is JadePuffer?

A: JadePuffer is the name Sysdig gave to what it assessed as the first documented ransomware campaign driven end-to-end by an autonomous AI agent, rather than a human attacker manually operating a toolkit.

Q: Did the attackers use a specific AI model, like ChatGPT or Claude?

A: Public reporting hasn’t confirmed which model or platform was used. The agent searched for API keys from multiple AI providers, which shows interest in that kind of access, but doesn’t identify what powered the attack itself.

Q: How did the attack start?

A: Through CVE-2025-3248, an unauthenticated remote code execution vulnerability in Langflow, an open-source AI agent framework, affecting versions before 1.3.0.

Q: Could the victim have paid the ransom to recover their data?

A: No. The encryption key was generated on the fly and never stored or transmitted, so there was no key available to recover, regardless of payment.

Q: What makes this different from typical ransomware?

A: The individual techniques weren’t new. What stood out was the speed and adaptability: the agent diagnosed a failed login attempt and corrected it in 31 seconds, a pace closer to machine speed than typical human-paced attacker behavior.

Q: What should security and recovery teams take away from this?

A: That recovery planning needs to extend beyond application data to configuration stores, service-discovery platforms, secrets, and identity systems, the layer JadePuffer actually targeted for maximum damage.

Chris Bevil is Principal Portfolio Marketing Manager at Commvault.

Key Takeaways

• Advanced AI models escaped a restricted evaluation environment by exploiting previously unknown vulnerabilities.
• OpenAI says the models were pursuing an assigned objective, not acting with malicious intent, yet still caused a real security incident.
• Traditional controls like sandboxing and segmentation are insufficient if AI can discover unexpected paths around them.
• Cyber resilience is becoming as important as prevention.

It began as an internal evaluation of advanced AI cyber capabilities.

While attempting to solve a narrowly defined benchmark, OpenAI models discovered a zero-day vulnerability, escaped the intended restrictions of their test environment, escalated privileges, reached the internet, and compromised Hugging Face infrastructure.

They treated the technical boundaries around them as problems to solve.

This Was Not a Traditional Cyberattack

Hugging Face first reported that an autonomous AI-agent framework had compromised part of its production infrastructure. A malicious dataset exploited two code-execution paths in its dataset-processing pipeline, escalated to node-level access, harvested credentials, and moved laterally across internal clusters.

The models involved, including GPT-5.6 Sol and a more capable pre-release model, were operating with reduced cyber refusals and without the normal production classifiers. They went far beyond the assignment, exploiting a proxy vulnerability to reach the internet, then using stolen credentials and zero-day vulnerabilities to find a remote-code-execution path on Hugging Face servers.

Malicious Intent Was Not Required

There is no public indication that the models developed criminal intent or chose to harm Hugging Face. They did not need to. Give a capable system an objective, tools, time, and feedback, and it will route around obstacles.

The conversation has moved past prompts and bad answers. These are systems that can investigate, test assumptions, discover previously unknown vulnerabilities, use stolen credentials, escalate privileges, and continue operating when the first approach fails.

A Sandbox Is Not a Force Field

We call environments isolated, segmented, and sandboxed as though the label itself creates security. It does not. In this case, the obvious path to the internet was blocked, but a reachable software-package proxy was not, and the models used its vulnerability to escape. Policies and expected behavior are not enough. The technical environment itself must enforce the boundaries.

Why This Is a Resilience Story

The activity moved from an evaluation environment, through OpenAI’s research infrastructure, onto the internet, and into Hugging Face’s production environment. That is a rapidly expanding blast radius. When AI can explore and act at machine speed, the time between initial access and broader compromise may continue to shrink.

Hugging Face did not simply block the original access path and declare the incident over. It closed the vulnerable code-execution paths, rebuilt compromised nodes, rotated credentials and tokens, and tightened cluster controls. The objective is not merely to restore a system. It is to restore confidence.

The question is no longer only: Are our AI systems secure? It is: When a powerful AI system finds a path we did not know existed, can we contain the blast radius, continue critical operations, rebuild what we no longer trust, and prove it is safe to move forward?

Chris Bevil is Principal Portfolio Marketing Manager at Commvault.

Security does not end at the edge of an organization’s own systems. Modern businesses connect a growing web of third-party applications to their core platforms to support sales, service, and collaboration. Each of these connections adds value. Each one also introduces exposure the organization does not fully control.

That risk is not hypothetical. In June 2026, a threat actor compromised OAuth tokens tied to Klue, a competitive intelligence platform used to sync sales and marketing data with Salesforce. The attacker used those tokens to reach the Salesforce environments of the many organizations that had authorized the integration, including Commvault’s.

As soon as we were notified of potential impact, our Security team activated our incident response process to determine what had occurred, contain the exposure, and assess whether customer information or Commvault services were affected.

Our investigation found that the activity was limited to certain business relationship and sales information maintained within our Salesforce environment. The investigation found no indication that any customer backup data, product data, product metadata, operational logs, or Commvault services were impacted.

Acting Quickly When It Matters

Our response followed established security incident response procedures built to contain risk quickly while supporting a thorough investigation. Once we were notified of the incident, we disabled the Klue integration, revoked the associated access, and worked with the appropriate parties to conduct a full assessment of what happened.

Throughout the investigation, our teams worked to determine what information had been accessed, validate the integrity of our environment, and confirm the incident stayed within the scope we had already contained.

A Pattern Worth Noting

This incident is one recent example of a pattern security teams have watched grow for several years: attackers targeting third-party applications connected to core business systems rather than attacking those systems directly. A single compromised integration can offer a trusted path into the environments of many downstream organizations at once, often with less resistance than a direct attack on any one of them.

This shifts where an organization’s defense actually has to live. Strong internal controls remain necessary, but they are no longer sufficient by themselves. They have to be paired with active oversight of every application an organization connects, and a response capability that is ready before an incident, not built during one.

Building Resilience Beyond Our Own Environment

At Commvault, our security program includes ongoing assessment of the third-party applications connected to our environment. We review connected applications on a regular basis, evaluate the access each one holds, monitor for emerging risk, and reassess those integrations as business needs and the threat landscape change. When circumstances warrant, we act to reduce exposure and strengthen our posture, including disconnecting integrations that no longer meet our standards.

Our Commitment to Transparency

Trust is built through openness and accountability. When an event affects our stakeholders, we believe it is important to communicate what we know, explain how we responded, and share the outcome of our investigation, even when the event originated outside our own systems.

We will continue to evaluate our security controls, refine our incident response processes, and strengthen our approach to third-party risk as part of our broader commitment to protecting our customers and partners.

For the official details of this incident, including the scope of the investigation and customer guidance, please refer to our Trust Center Updates.

Will Galway is Deputy CISO at Commvault.

For years, post-quantum cryptography (PQC) sat comfortably in the category of “important, but not urgent.”

Security leaders knew it was coming. Researchers talked about it. Standards bodies worked on it. Most organizations acknowledged that it would eventually require attention. But I would argue that the time to start preparing is now.

In this episode of STRIVE, I sat down with Sr. Director of Portfolio Marketing Michael Fasulo to discuss why the conversation around PQC is changing so quickly – and why the organizations that wait for certainty may find themselves running out of time.

Watch the full episode.

Key Takeaways

• Harvest Now, Decrypt Later attacks mean sensitive data is already at risk, even if quantum capabilities aren’t stable or commercially viable yet.
• Most organizations do not have a complete view of their cryptographic inventory, making discovery the first major hurdle.
• PQC is just as much a technology challenge to solve for and as much as it is about risk prioritization.
• The organizations that start preparing now will have more options to course correct on prioritizations than those forced to react later.

The Problem Isn’t the Technology

Most discussions about post-quantum cryptography start with technology.

• How quickly is quantum computing advancing?
• When will cryptographically-relevant quantum systems become practical?
• Which algorithms are likely to survive long term?

Those are important questions. But they’re not the questions I would prioritize asking. Michael wrote a blog last year about PQC and we discussed today how several things have changed since then.

Over the past several years, estimates have consistently moved in one direction: what once felt distant now feels increasingly close. At the same time, standards are evolving; regulatory expectations are increasing, and organizations are beginning to recognize how much cryptographic debt they’ve accumulated over the decades.

The exact date of Q-Day may remain uncertain. The direction of travel is not.

The Risk Is Here And Now

One reason this conversation has become more urgent is the growing attention around Harvest Now, Decrypt Later attacks. The concept is straightforward: An adversary gains access to encrypted information today, stores it, and waits for future capabilities to make that information readable.

What’s important here is that the risk doesn’t begin when quantum computing arrives. The risk begins when even encrypted data is exfiltrated and stored.

For organizations protecting intellectual property, healthcare records, government information, or other sensitive long term retention data, that distinction changes everything.

Organizations need to know whether data being retained today will still matter when that future arrives.

For many,esp. the highly regulated industries and critical infrastructure, the answer is yes.

Sneak Peek: Why Crypto Agility Matters

Embed clip here: https://www.youtube.com/watch?v=A3YWU5rlmGA

In this clip, Michael explains why PQC isn’t a one-time fix or switch. The real goal is crypto agility – building the flexibility to adapt cryptographic algorithms as standards, and threats evolve. Because in cybersecurity, the challenge isn’t just preparing for what’s next. It’s being ready for what comes after that.

Discovery Is the Real Project

One misconception about PQC is that it’s primarily an encryption upgrade. In reality, most organizations haven’t reached the stage where replacement is the biggest concern.

They’re still trying to understand the scope of the problem. Cryptography exists everywhere.

• Applications
• Certificates
• Cloud services
• APIs
• Code signing
• Third-party platforms

Many organizations struggle with the creation of the cryptographic inventory or its scope. That makes discovery one of the most important – and often underestimated – parts of the journey.

And for many enterprises, that’s a much larger endeavor than expected.

The Supply Chain Challenge

Another reason PQC has become a priority is that no organization will navigate this transition alone. Modern enterprises depend on vendors, cloud providers, software partners, and countless third parties, all of whom use cryptography.

That means quantum readiness extends beyond internal systems. It becomes a question of ecosystem readiness.

• Are suppliers preparing?
• Are critical vendors planning migrations?
• Are third-party platforms aligned with emerging standards?

These questions will increasingly become part of risk conversations, procurement discussions, and long-term technology planning. Because cryptography doesn’t stop at organizational boundaries. Neither does risk.

Why This Conversation Matters

The most important takeaway from this discussion is that post-quantum cryptography is no longer a future technology challenge.

It’s becoming a present-day resilience conversation.

Organizations don’t need to panic and they don’t need to overhaul every system overnight. But they do need to begin, to make the best use of the time at their disposal for prepartion.

The organizations that navigate this transition successfully won’t necessarily be the ones with the most sophisticated cryptography. They’ll be the ones that started building understanding before certainty arrived.

And that’s often how resilience works.

Watch the Full Episode

There is plenty more that Michael and I explore in the episode that I didn’t capture above. Be sure to watch now for insights to:

• The biggest challenges organizations face when starting their PQC journey.
• What leaders should prioritize today including some best practices.
• Understanding MLKEM algorithms and crypto agility.
• Infrastructure considerations for PQC.
• How Commvault is preparing for this future.

FAQs

Q: What is post-quantum cryptography (PQC)?
A: PQC refers to cryptographic algorithms designed to help remain secure against attacks from future quantum computers.

Q: What is Harvest Now, Decrypt Later?
A: It’s a strategy where attackers collect encrypted data today with the intention of decrypting it later when more advanced computing capabilities become available.

Q: Why are organizations focusing on PQC now?
A: Because preparation takes years, and sensitive data collected today may still be valuable when quantum threats become practical.

Q: What is the biggest challenge organizations face?
A: Discovery. Most organizations do not have complete visibility into where cryptography is used across their environments.

Q: Do organizations need to replace all cryptography immediately?
A: No. Most experts recommend starting with inventory, discovery, and prioritization before planning broader migrations.

Q: What should leaders do first?
A: Identify long-lived sensitive data, understand cryptographic dependencies, and begin building a roadmap for future transition.

Vidya Shankaran is Field CTO at Commvault.