Businesses received a staggering amount of cyberattacks in June, according to Check Point, showing a rise of 20% over the previous 12 months. The breakout of AI agents from OpenAI in July to hack into the Hugging Face website, and subsequent similar events from Anthropic and Meta, indicate agentic-powered attacks will explode over the coming year.

Currently, malicious hackers have the advantage because publicly released frontier models from the US incorporate guardrails that can’t distinguish between malicious or defensive activities. As a consequence, these models default to a refusal to get involved. Hugging Face discovered this the hard way when they attempted to utilize a model to defend against the OpenAI intrusion. Their solution was to adapt a Chinese open weight model to analyze the 17,000 attack logs, find the vulnerability, and contain the intrusion.

With incidents like these happening more often, an arms race has begun with AI being both the problem and the solution.

Strength in numbers

While single agents generally perform more efficiently for well-defined tasks, research from Stanford University indicates swarms are more effective in messy scenarios with noisy data, which are more typical of unpredictable, intrusion attacks. The increased token usage by swarms raises costs, but increasingly efficient open weight models are rapidly lowering these barriers.

In the Hugging Face example, the agents worked together as a team leaving messages for each other on a message board they improvised. They shared newly found vulnerabilities, exchanged tools, and even developed conventions to address one another and to avoid overwriting each other’s work. While this may seem sinister, they were only following their designated purpose: to achieve a goal without regard to any collateral damage. We can expect bad actors to harness the power of agentic swarms through fine-tuning open weight models, and creating agents that progressively learn from their experiences.

Modern warfare has been transformed over the last four years, too, through the deployment of drones by Ukraine to defend against Russian attacks. Military strategies and the deployment of armament budgets around the world are shifting to focus on new technologies, and approaches and enterprises are now facing a similar challenge from the hostile use of agentic AI.

The drawbridge is down

As enterprises build out their own agentic systems to handle ecommerce, customer service, and marketing activities, this presents new attack surfaces for antagonistic efforts. April 2026 research from Trend Micro found almost 1,500 MCP servers directly exposed to the internet had no authentication or encryption, a rise of 200% from nine months earlier. This included 70 hosts offering direct SQL execution, and servers holding medical records.

The automation of business processes and the reduction of humans from decision making chains open up new vulnerabilities for agents with malicious intent. Arkose Labs’ 2026 agentic AI survey of 300 enterprise leaders found 97% expected an AI agent security incident within the next 12 months.

Social engineering

While agents have demonstrated their ability to break through security systems, they’re also capable of targeting humans to achieve their objectives. Recent research from Verizon indicates that 62% of successful breaches involve a human element, with phone-based attacks 40% more successful than email-based ones. In August, for instance, scammers using an AI-generated deep fake of Australian Prime Minister Anthony Albanese’s voice were able to scam investors out of $5.3 million.

If agents can break out of digital sandboxes, and generate convincing fake videos and audio, then they’re certainly capable of making basic phone calls. In July, during testing of frontier models, the UK AI Security Institute discovered an agent tried to insert malicious code into an open-source project. Attempting to get the code approved, the agent created fake online identities using them to persuade the project’s maintainer to sign it off. “This is the first time we’ve seen risks around autonomy and deception manifest this clearly without specific prompting in the real-world,” the Institute put in a write-up of the incident.

Fight AI with AI

So attackers currently have the upper hand in this escalating arms race. They have access to agents that can work around the clock, constantly probing, learning, and sharing their knowledge with other agents. They’ll only get better at this and learn ways to stay ahead of defensive systems. International agreements to delay or restrict the capabilities of frontier models won’t stop hostile actors motivated by money or rogue states pursuing other objectives. Developers and security vendors need access to the latest frontier models unfettered by restrictive guardrails if we’re to stand any chance of defending against the coming tsunami of attacks.

We can learn a lesson from recent history on this front. In 1992, the US restricted exported software to weak 40-bit encryption, citing security concerns going back to the cold war. While the US allowed stronger encryption internally, the result was weakened security for everyone as hostile antagonists were able to disrupt global supply chains that incorporated less secure software. Despite lifting the ban in 1999, embedded software containing 40-bit encryption continued to cause problems for many years across multiple countries, including the US.

Without rapid action, we may look back fondly to the world before July 2026 as a golden age for cybersecurity, a relative age of innocence.

Enterprises are facing a disturbing new question in the age of AI: What happens when agentic assistants go dark?

This became a very real scenario on Thursday, as OpenAI’s ChatGPT, Anthropic’s Claude, and SpaceXAI’s Grok near-simultaneously, and somewhat mysteriously, experienced significant, prolonged outages.

Beginning in the morning, Eastern time, several ChatGPT models went down over a roughly two hour period, Claude models over a four-hour span, and Grok models for a near three-and-a-half hour duration. All three companies acknowledged the “elevated” issues and applied fixes.

As users grumbled in forums and IT teams scrambled to get them back online, the incident revealed how hastily some organizations have adopted generative AI workflows without considering the potential, and inevitable, impact of widespread outages.

AI agents are increasingly taking over automated and wider-scale workflows, and enterprises could find themselves “uncomfortably exposed” when AI hits the brakes, said technology analyst and journalist Carmi Levy. The situation should “serve as a wakeup call to IT leaders who have largely ignored what it’ll cost them if these increasingly critical platforms suddenly go dark. The risk is no longer hypothetical.”

Hours-long outages impact core services

ChatGPT went down on the same day as OpenAI’s anticipated launch of GPT-6 Astra, the new frontier model that the company says approximates artificial general intelligence (AGI) and gets nearer to its goal of creating autonomous systems that outperform humans.

The OpenAI outage occurred around 11 a.m. ET on Thursday and impacted a slew of services, including search, file uploads, agents, GPTs, voice mode, image generation, ChatGPT work, Compliance API, Deep Research, ChatGPT Atlas, and other connectors and apps. In some cases, users were prevented from logging in, conversations failed to load, and the interface returned errors when attempting to send messages. OpenAI’s Codex services, including web, API, command line interface (CLI), and VS code extension, were also impacted.

OpenAI fixed the issue by 12:55 p.m. ET, and advised Codex remote control users to re-pair their mobile devices.

Claude began to go dark around 7:37 a.m. ET, with Anthropic acknowledging an “exhaustive list” of impacted models with elevated errors over the next few hours: Mythos and Fable 5.1 and 5, Sonnet 5, and Opus 5, 4.8, and 4.6.

The issue was resolved by 11:27 a.m. ET. The incident followed a roughly 27-minute outage just the day before, also due to elevated errors on requests in Sonnet 5.

Grok, meanwhile, began experiencing issues around 9:30 a.m. ET. Grok Web, Build, API, Office/Workspace plugins, Android, and X were all impacted. The services returned to “healthy” traffic at 1:08 p.m. ET.

“It’s a curious scenario for multiple different providers to experience outages at the same time,” noted Brian Jackson, a principal research director at Info-Tech Research Group. It could be related to a common infrastructure such as a content delivery network (CDN) layer, domain name system (DNS), or shared cloud infrastructure, he theorized.

A case for outage planning

Just a few months ago, the extent of AI use within the typical enterprise was limited to employees using chatbots to get answers to basic questions or to draft simple email messages, Levy noted. Large-scale AI platform outages, when they occurred, had relatively little impact on overall organizational productivity. “But things are changing, and quickly,” he said.

Organizations must now have a better understanding of the impact agentic AI has on day-to-day workflows, and the degree to which they disrupt employees’ ability to complete complex tasks once they’ve handed the reins over to automated, cloud-based tools, Levy noted.

In incidents like Thursday’s, employees may fall back on traditional manual workflows, such as updating spreadsheets or pulling reports together the old-fashioned way. But they might also realize that, after relying on AI agents to do so much work on their behalf, they’ve become too dependent on automation, and their “cognitive skills may not be as sharp as they once were,” Levy said.

The growing prevalence of agentic AI should prompt organizations to revisit their disaster recovery and business continuity plans and assess the productivity impact of potential service outages, he said. While cloud-based productivity platforms like Google Workplace and Microsoft 365 offer limited degrees of “offline mode” functionality using locally-stored data, and documents can be synchronized to hard drives in Dropbox or Google Docs for Desktop, agentic AI platforms offer up fewer offline workarounds, at least in their current form.

Organizations should document workflows in greater detail and scenario-plan what near-term recovery might look like in the event of an extended AI platform outage, Levy said. They also need better training to ensure employees maintain their manual skills over time and are equipped to press them into service in the event of a service outage, because the more enterprises lean on agents to complete critical tasks, “and pull humans out of the loop in the interest of productivity,” the less able employees will be to step back in during inevitable service interruptions, he pointed out.

“It is entirely possible for otherwise well-meaning organizations to be over-reliant on AI automation,” Levy said. “Too many organizations are about to learn some hard lessons about not having a backup plan in place.”

Info-Tech’s Jackson also recommends a modular architecture for LLMs; enterprises should view the model as a “commodity that can be hot-swapped with an alternative.” That might be another cloud service provider (which hopefully isn’t experiencing a concurrent outage) or a self-hosted option like an open-weights model.

“In a scenario like this, when your first choice provider might not be available, you have a fallback that can supply that same intelligence layer, even if it’s only a stopgap solution,” said Jackson.

This article originally appeared on Computerworld.

For the past few years, enterprise AI programs have focused on making models more useful, accurate, and autonomous. In that phase, a bad answer was still usually something a human could accept or reject before taking action. But once agents start invoking tools and acting inside business workflows, success should no longer be measured only by how much work they complete. A more important metric is how well an agent recognizes when it lacks the authority, context, or judgment to continue.

When helpful becomes risky

According to Allan Dabre, technology compliance and AI lead at PwC, a behavior that has to be deliberately designed into the system is, “I don’t know.” AI is built to be helpful, so an agent will generally try to do something useful unless it’s been configured not to.

“The fact that AI systems can hallucinate illustrates that tendency,” Dabre says. “When they lack enough information, they may still produce an answer. In an agentic workflow, that impulse can become more dangerous because the output may become an action, rather than remain a suggestion.”

He adds that many enterprises still test AI primarily for completeness and accuracy. That made sense when the central question was if the model could produce a reliable response. But as models improve and agents gain more operational authority, he argues that CIOs need to prioritize something else: restraint.

“Can it stop at the exact moment you want it to stop?” he asks. “Are you testing for that?”

Confidence is not authority

Dabre makes a simple but important distinction. An AI agent may be 99% confident a record should be updated, a refund should be approved, or a legacy database can be decommissioned. But that doesn’t mean the agent has the authority to act. Confidence is about the probability the system believes it’s right. Authority is about whether the organization has delegated that action to the system in the first place.

He gives the example of an agent asked to analyze legacy software and recommend what can be decommissioned. The agent may conclude, with high confidence, that several databases have little user impact and can be deleted. But even if the system is confident, most organizations wouldn’t want it to delete those databases on its own.

The same logic applies across business processes. An agent may be confident a customer record should be updated, an opportunity in a CRM system should be closed, or a transaction appears legitimate. But once that action flows into other systems, the potential consequences expand.

That’s why Dabre argues for what he calls an agent harness: a controls or orchestration layer outside the model that defines what the agent can and can’t do. In a refund workflow, for example, a company might let the agent approve small refunds, require human approval for larger ones, and stop the process entirely above a defined threshold. The agent may gather the relevant context, explain the request, and prepare the case for review, but the decision is governed by the authority boundary encoded into the system.

“It’s not a policy document and it’s not a prompt,” Dabre says. “It’s software or a configuration you can apply to an agent.”

The case for least agency

Matt Graney, chief product officer at Celigo, a business automation and integration platform provider, approaches the same problem through a principle he calls least agency. The idea is to give an agent the least amount of autonomy required to complete a job.

According to him, there’s a temptation to throw AI at broad, nebulous problems. But many business processes are still largely deterministic. They follow established rules and perform repeatable work. Within those workflows, AI may be useful at the point where rigid rules give way to interpretation. But that doesn’t mean the agent should own the entire workflow. “The smaller you make that surface area, the better,” he says.

Graney says the same logic applies to tools. An agent with too many tools can become confused, especially as context windows grow and the task becomes more complex. “Because Celigo is an integration platform,” Graney says, “the company’s approach is to expose agents to fewer, more powerful tools that reach enterprise systems through governed connections.”

That’s another form of restraint. Instead of letting an agent reach into enterprise systems ad hoc, the business gives it a narrow, governed toolset designed for the task at hand.

Graney also argues that guardrails should sit outside the model. If the same agent that makes a decision is also responsible for judging whether the decision is acceptable, the control is weaker. A separate guardrail can check the agent’s inputs and outputs before a downstream action occurs.

That same design discipline applies to escalation. “I don’t know” shouldn’t be treated as a chatbot phrase. In an enterprise workflow, it’s a handoff path that should be defined before the agent reaches it.

Make escalation part of the workflow

Turning uncertainty into a handoff is where Matt Quinn, CTO at CarGurus, an automotive marketplace, sees agentic AI becoming less a pure technology challenge and more a management challenge. At CarGurus, Quinn says agents are evaluated according to what they know, what they can do, and what data they operate on.

CarGurus receives a high volume of cases from dealers, and each one needs to be classified and routed. The company now uses an agent to review incoming cases, draw on account history, and route them to the appropriate next step. Quinn says the agent handles about 70% of those cases end to end without human involvement.

But when agents move toward consequential actions, he says the consensus is having a human approval step. The agent may return with a simple prompt like, I’m about to do this. Do you want me to proceed? That simplicity matters because a handoff shouldn’t bury the reviewer in complexity.

Quinn says the human remains ultimately accountable for the work. That principle is especially important in engineering, where agents may help write code or fix bugs. Quinn adds that CarGurus still expects engineers to follow the practices they’d use for any other production change, which includes running quality checks.

The company has adopted the phrase healthy speed to describe the balance it wants. The goal is to move faster without letting quality degrade. An agent can accelerate work, but if teams abandon the practices that make work safe, the speed becomes reckless.

This is also where human judgment remains difficult to replace. Quinn describes it as high judgment people develop through experience. A human may look at an AI-generated output and sense something’s wrong, even before fully articulating why. “Agents are improving,” he says. “But humans still play a critical role in deciding when the system shouldn’t continue.”

That doesn’t mean every workflow needs the same level of review. Quinn says CarGurus doesn’t have a target percentage of work to automate. The right level depends on the job and the task. A simple bug fix may require a lighter review than a change to a sensitive backend service, and a personal summary may carry little risk. But a document sent under someone’s name still needs human review.

Make autonomy accountable

That kind of pragmatic approach may be the best lesson for CIOs, making the goal of agentic AI appropriate rather than maximum autonomy.

That also means ownership has to be clear. Dabre argues ownership should be divided before deployment. The business defines the outcome, technology builds and configures the agent, risk and compliance set the guardrails, and governance monitors whether the system still behaves as intended. The authority to pause, stop, or retire an agent should be defined before production, not negotiated during an incident.

Graney makes the same point with a simple analogy. If a company hires an untrained intern, gives that intern access to the crown jewels of a business process, and something goes wrong, the intern isn’t the real problem. The process is. The same applies to agents. Accountability belongs with the person who owns the workflow.

That may be the shift CIOs need to make as enterprises move from pilots to production. AI agents shouldn’t be treated as magical workers that absorb accountability. They’re components in business processes, and those processes need accountable owners.

As AI adoption increases, the next phase of enterprise maturity won’t be defined by agents that always answer or always complete the task. It’ll be agents that know when not to act.

Organizations today are not short of data, particularly in the domain of cyber. What many lack is a timely, trusted assessment that can help leaders act with greater confidence.

When a cyber incident begins, the technical questions surface first. What happened? Which systems are affected? Is the activity contained? But the questions that often shape the outcome are rarely technical alone. Who is behind the activity? What are they trying to achieve? Is this an isolated event or part of a broader campaign? Which customers, suppliers, assets or services are exposed? Is there a sanction, legal, regulatory or reputational dimension? And what is a proportionate immediate response while the facts are still incomplete?

This is why cyber is, in a meaningful sense, as much a human decision-making problem as a technological one. The OECD argues that digital security risk should be integrated into broader decision-making, rather than treated only as a technical issue. Tools can detect signals, spot patterns, correlate events and flag anomalies, but it takes people to decide what those signals mean, when to escalate, which trade-offs matter and what action the organization should take. In Moody’s recent whitepaper on supporting decision dominance through financial, corporate and trade intelligence, we make the case that the decisive moments in a cyber incident belong not only to systems, but to judgement.

That matters for CIOs and other technology decision-makers, because theirs is one of the most demanding decision environments in the enterprise. Reporting lines and structures vary by organization, but common themes tend to recur: technical complexity, compressed timelines, uncertain attribution and fragmented responsibility. Security teams may see indicators before they understand intent. Legal teams may need to assess obligations before the full scope of an incident is known. Communications teams often must prepare for scrutiny while operations are still working through containment. Business leaders may first need to decide when a decision must be made, then whether to pause a service, isolate a supplier, notify a regulator, issue a public statement or accept some temporary disruption to prevent greater harm.

The result can be a gap between signal and action, at a time when many organizations are experiencing a growing volume of cyber signals and alerts. Organizations commonly track mean time to detect and respond. But a less visible but equally consequential metric is decision latency: the time it takes to move from a technical signal to a shared understanding of what matters, and a decision about what to do. An organization can identify a threat quickly and still act too slowly if it cannot interpret the signal, convene the relevant stakeholders or agree on a proportionate response. The challenge is not simply speed — decisions made quickly but poorly can amplify harm. It is reducing decision latency without sacrificing judgement. This urgency is not theoretical and shouldn’t simply be admired. In her 2026 GCHQ Annual Lecture at Bletchley Park, Director Anne Keast-Butler described “a moment of consequence” shaped by the radical uncertainty. Her wider point is key for CIOs and their peers across the board: cyber security is a critical priority, and resilience depends on the ability to act with urgency, judgement and trusted partnerships.

From signal to context

Technical signals tend to become more useful when connected to wider context. A malicious domain, an unusual login, a compromised account or malware signature may tell a security team that something is happening. On its own, that signal rarely tells an executive what the organization should do next. Context reframes the question from “what does this indicator mean?” to “what decision should we make?”

That context can take several forms. Payment flows may provide additional context regarding the financial networks associated with an event or risk scenario. Ownership structures can help identify relationships between suppliers, counterparties or entities that may merit further review. Sanctions exposure may change the legal and compliance implications of a response. Adverse media may provide indicators of potential reputational or integrity concerns. Corporate linkages may reveal that what looks like a narrow technical event is in fact connected to a wider network of actors, assets or interests.

None of this removes uncertainty altogether, and no decision-maker should wait for perfect information before acting. What broader context does is improve the conditions under which judgement is exercised. Two incidents may look similar at the technical level but demand different leadership responses. One may be opportunistic criminal activity with limited broader consequence. Another may involve connections to a sanctioned entity, an organized crime network, a critical supplier or a state-linked ecosystem. The signal may look similar, but the appropriate response is not.

A cross-discipline exercise

This distinction matters because cyber response is often not contained within the security function, especially in a learning organization. A serious incident typically draws in teams from across multiple disciplines, such as security, IT, legal, risk, compliance, finance, procurement, communications and business operations. It may also involve external parties such as law enforcement, intelligence agencies, regulators, financial institutions, infrastructure operators and key suppliers. The CIO will not own every lever in this environment, and organizational structure will influence how close to the centre of the systems they sit, dependencies and information flows that affect the organization’s ability to respond effectively. Is the CIO supported or supporting during an incident? What leeway is afforded the CIO to act when required?

A common challenge in cyber response is not the absence of technical capability, but the absence, or fragility, of a shared decision model. Teams will have data, dashboards and incident playbooks in place, but still lack clarity on who decides, what information is needed, which trade-offs are acceptable and how quickly business context can be brought to bear. Ensuring a common operating picture — one that gives the leadership team a shared understanding of the same facts — tends to be a differentiator between organizations that respond coherently and those that do not.

For CIOs and CEOs, this is an organizational design problem as much as a technology one. Experience suggests that a cyber strategy that stands alone may be less effective than one integrated into the organization’s broader strategy from the outset. Cyber maturity should not be judged only by the number of controls deployed, alerts processed or systems monitored, but also by the quality of the decisions an organization can make under pressure. Using scenarios to test decision making can help refine organizational design, highlight blockers that may emerge at critical times, and improve leaders’ understanding of the potential consequences of poor decision making. That wider coordination challenge is reflected in CISA’s incident response guidance, which treats serious cyber incidents as events requiring coordination across multiple stakeholders.

Where integrated intelligence adds value

This is where integrated intelligence has a role to play. Its value lies less in the sheer volume of information it provides — most organizations already have more data than they can absorb — and more in its ability to help prioritize, separating signal from noise. It can help distinguish activity that is technically interesting from activity that may be strategically material. Used well, it can help identify enabling networks associated with an attack, inform disruption options and help focus scarce defensive resources on the assets, relationships and dependencies most likely to matter.

The aim is not to know everything. It is to develop sufficient understanding of the most relevant factors early enough to support timely actions while meaningful response options remain available.

CIOs can make this practical by asking five questions:

1. Which cyber decisions must be made in the first moments, the first hour, first day and first week of a serious incident?
2. Who is authorized to make them, what is their availability 24/7 and who deputizes in their absence?
3. Can technical indicators be linked quickly to business impact, financial exposure, legal risk, supplier dependency and external context?
4. Can security teams escalate without creating unnecessary alarm?
5. Can the CEO and board be briefed in decision-ready language, with recommendations rather than technical detail alone?

These questions move the conversation from reporting to leadership, and they reflect the human reality of cyber defence. Employees, analysts, managers and executives are asked to make repeated judgement calls under uncertainty, often with too much noise and too little time. Attackers are often well placed to exploit that reality; resilient organizations tend to design around it

Beyond visibility

Cybersecurity has spent years improving visibility, and that work remains essential. But visibility alone does not create resilience. The next challenge is decision quality.

For CIOs, the strategic shift is that cyber signals become most valuable when connected to real-world consequences: financial, operational, legal, reputational and geopolitical. In a fast-moving incident, the critical question is rarely whether the organization has more data. It is whether leaders can understand what matters, decide what to do and act while meaningful response options remain available.

The organizations that are often most effective in this environment are not necessarily those with the most dashboards. They are often those that have worked to reduce decision latency without sacrificing judgement, often through rehearsal, scenario testing and learning from gaps identified during those exercises. In an environment shaped by ambiguity, compressed timelines and interconnected risk, the ability to make better decisions faster may become one of the defining measures of not just cyber resilience, but of leadership itself.

Companies are running into a new version of an old problem. Take, for example, a marketing executive turns on an agent from Marketo but doesn’t tell their IT team. That shadow agent now has access to customer data with little oversight and no clear adherence to the company’s security or compliance policies.

That’s a real scenario that’s happening now. It’s also the same pattern that made shadow IT a headache for over two decades. Employees often adopted unapproved tools that helped them do their job faster and better because the company option just wasn’t as good.

With agentic AI, it’s different because of what an unauthorized agent can do. Shadow IT tools mostly accessed or handled data without proper authorization.  Agents, on the other hand, can take it much further by acting on that data by pulling records, sending messages and making changes with little oversight. Forcing agent data interactions via model context protocol can help, but the fact is there’s an autonomous agent that IT has little to no visibility into.

Now multiply that one marketer by every department, plus every agent that your vendors in HR, finance and elsewhere run in your systems. It’s a situation that most companies have no way to see, let alone control. This can become hundreds of vendors each running multiple agents, moving between your company, their company and your supply chain. That’s many thousands of agents with no consistent way to track what they are doing.

I often ask security teams: Do you have a robust inventory of the agents operating on your network? For most companies, the answer is no. And even if a company scanned its network, it’s not clear that agents are what they claim to be. So, there can be an unknown number of agents from unverified provenance performing a multitude of tasks and data exchanges on your network. This unfortunately is the current state of affairs at most companies.

Old problem, higher stakes

Shadow IT used to be technology that was used for work without explicit IT approval. Ten years ago, that meant a personal Dropbox folder or an unsanctioned project board. Today, it can mean an agent with a login and a task list, who is working inside your systems. That’s what shadow agents are.

When an agent gets access, it can quickly pull a record, draft a reply, update a field, move a file — the list goes on. This can happen before anyone even notices anything happening.

Security teams often say you can’t protect what you can’t see. That was true when the invisible thing was a spreadsheet. But it reaches another level when that agent has a login and knows what to do with it.

The precedent: DMARC solved this for email

How do you know an email that looks like it’s from Uber is actually from Uber? I ran into this problem, years before AI was an issue.

Say you get an email after an Uber ride saying, “Thanks for riding, click here for your receipt.” It says it’s from Uber. It’s actually sent by a vendor like SparkPost, on Uber’s behalf. Uber authorized it. The vendor is doing what Uber asked it to do. But nothing in the email told your inbox that there was permission, so your inbox just trusted the “from” line. Worse, it could’ve easily been a phishing attack from a criminal purporting to be Uber.

To address this, the email sender should have been authenticated against a trusted source before the email lands in your inbox.

That’s DMARC. A decade and over 1 million domains later, it’s proof the model works at scale. Verify the sender against a record that the domain owner controls and the guessing goes away.

The same fix, one layer up, for agents

DNS is already the internet’s phone book and a secure, trusted and public-facing database representing the domain. An agent claiming to represent Salesforce or any vendor can be checked against Salesforce’s DNS-secured record before it’s ever granted access.

That one check answers a critical question: Is this agent who it says it is, and did the company it claims to represent actually authorize it?

Once an agent is verified via the domain owner’s DNS record, there’s a domain cryptographically attached to the agent, and accountability that didn’t exist before.

Right now, most organizations don’t have that. An agent shows up and asks for access. But if something goes wrong, no one is really responsible, because nobody checked in the first place. They “trust” that the agent is what it claims to be. This gets even more complex if the agent is from a known hyperscaler/AI company but acting on behalf of an untrusted/unknown user (e.g., a ChatGPT agent but getting instructions from a criminal)

Zero trust as a bouncer, not a detective

Most of security has worked the same way for years: Try to identify everyone who shows up, then decide if they’re trustworthy. That’s backwards, and email proved it over a decade ago. A layered approach with zero trust upfront and further interrogation of what’s left over combines the efficiency and low cost of zero trust with deep inspection as a second pass, providing a highly effective level of security. 

• Layer 1: Zero trust is like a bouncer at a nightclub. She doesn’t try to figure out which of the world’s 8.3 billion people you are. She checks a finite short list of a couple dozen guests. If you’re not on it, you don’t get in.
• Layer 2+: Now that we’ve reduced the number of people by (usually) orders of magnitude, we can, if needed, run the remaining people through deeper inspection, say a metal detector, access credentials and so on.

With agents, the logic is the same: Don’t evaluate whether an agent is trustworthy after it’s already inside your systems. Check whether it’s on the list before it gets anywhere near the door.

This means a legitimate agent might get turned away because someone forgot to add it to the list. But that inconvenience is much better than the alternative of letting everything in and just hoping things go well.

Identity is not permission

There are two separate questions inside every access decision. Most conversations about AI governance conflate them. First, who is this? Second, what are they be allowed to do?

This is like a passport and a visa. The passport says who you are. The visa says what you’re permitted to do and where you’re permitted to go. They’re issued by different authorities for different reasons. Confusing the two is where a lot of security approaches go wrong.

Upfront agent authentication, also known as a passport, can tell you whether that agent claiming to be from Salesforce is really Salesforce’s. Next, you need to figure out if Salesforce is authorized to work in your system and what it’s allowed to do. Your approved list of vendors and the approved actions should be made on purpose rather than defaulting to whatever the agent claims about itself.

The identity layer has to get solved first and solved the same way for everyone. But the permission layer is where every company’s answer is different, based on what that specific agent actually needs to access. Complicating matters, agents can change their workload mid-process. So, the permissions need to be continuous and focus on ongoing workloads as they evolve. This is a growing, urgent problem.

Why this matters now

AI-generated phishing is now three times more effective than traditional campaigns, according to Microsoft.

A year ago, AI-written phishing attempts were easy to spot due to bad grammar or strange tone. That has changed on an exponential curve, a progression humans’ brains have a hard time grasping. The same category of tool getting better at impersonation is now showing up as unauthorized agents inside company systems. And improving exponentially. Better deception plus more access adds up to a problem that grows faster than we can even imagine.

Shadow IT taught the industry a lesson. Now, shadow agents are teaching it again. You can’t secure what you don’t know is running inside your systems. For the marketer turning on the Marketo agent, what would have caught it isn’t a smarter firewall or a longer policy document; it’s a check, run before access is granted, confirming that the agent is who it claims to be and that someone actually authorized it. It’s followed up with continuous permissioning and logging to make sure the agent does what it’s supposed to.

That’s the shift: Verify an agent’s identity before it gets anywhere near the door. Email already proved this model at scale across roughly 1 million domains. Shadow agents are the same problem showing up again in a new form. It doesn’t need a new fix. It needs the one that already works.

Companies grow in many ways, and physical security must keep pace. Sometimes growth occurs naturally through the evolution of internal business programs, but other times one company grows by acquiring another one, and it’s often a company that’s very different from the one that’s doing the acquiring. Growth is exciting, but with growth through acquisition, security teams face challenges around integrating two sets of dissimilar systems, processes, org charts and security cultures. These planning tips should help keep you agile and prepared when your security team encounters acquisitional growth.

Converging to an integrated roadmap

When one company acquires another, there’s an inevitable mismatch between security programs and plans. Company A might have mature processes but outdated systems; Company B might have recent tech but few processes for integrating its use. Or the companies might have different deployment and application philosophies. Sometimes the company being acquired has no formal physical security program at all.

The security culture at each company can also clash: one uses phone-based mobile credentials, while the other uses proximity access cards; one is rigorous about securing its IP due to strict regulations, while the other can historically afford to be more casual. These disconnects intensify when the acquired company’s people aren’t motivated to adopt the policies and practices of their acquirer.

Guess what? Very soon, they’ll all need to play together as one organization. And if one or both of the companies has an existing security technology roadmap, they each face inheriting various aspects of the other’s strategy. For all plans to work together and operational continuity to be preserved throughout the change, security leaders must find some way to blend the two companies’ strategies and cultures to yield an integrated plan for common platforms, activities and standards across the newly unified team.

Elevating security visibility

For most of us, corporate mergers and acquisitions (M&A) seem to happen fast — sometimes without warning. The decision to merge with or acquire another company is typically made in corporate boardrooms, beyond the consideration or awareness of individual departments. As senior executives meet to discuss fine print and calculate bottom lines, they don’t always account for the true costs of merging teams, resources and processes at the operations level, including IT, facilities management and security.

During acquisitions, then, security needs to play a role in shaping change, not just executing it. The number one way to accomplish this is to identify the committee in your company that manages M&A-related changes and do what you can to make sure security is on it. With security leaders adding their voice, you’ll face fewer roadblocks and misfires as acquisitions proceed.

As due diligence proceeds in the wake of an acquisition announcement, it’s up to the security team to provide its own accounting and plans, so that budget and support are hopefully available to accommodate the transition. This means jockeying for visibility as decisions get made that impact the efficacy of security operations and the protection of the newly merged physical environments.

Four areas to focus on

Why does visibility matter so much for security during acquisitional due diligence?

First of all, this work matters because cost and scope assumptions regarding security systems and personnel that are made without security leadership present are doomed to be woefully inaccurate. But also, merging security programs often incurs expenses that go way beyond traditional personnel and technology costs: SME travel during due diligence and integration, retraining of personnel, support for new users and so on. The transition team might be aware of some of these costs, but security can be there early on to make a holistic case by showing cost models, gap analyses and other key roadmap elements.

Planning and positioning your new security journey along this blended route is a matter of examining each company’s current security program and finding effective ways to integrate each one with the other — including potentially sunsetting certain program elements by evaluating and selecting the ones that work best in the new organization.

Correlation must happen across four main areas — budget, technology, people and culture. Let’s take a look at some high-level guidance in each area to help you get started. Then, we’ll jump into three key scenarios to see the areas where emphasis is especially needed to achieve smooth results.

Correlation area #1: Budget and business integration

In many ways, roadmapping starts and ends with a budget. If you don’t have funding, you can’t provide security on the level you plan for. If you don’t work with your M&A committee to identify and amplify security considerations in your blended roadmap, you’ll miss the chance to get your share of budget up front. Be prepared with security budget items and ready to defend them. Need to consolidate and integrate massive security solutions at both companies? Find out now, not later, and obtain the funding you need to get it done.

At the same time, educate yourself on the relative security postures of the two companies, and seek to strengthen your overall posture where needed. Incoming business units often push back on requests for funding, and the security team at the acquiring company must be prepared. The best way is to be backed up by the right corporate policies and directives that reinforce security standards and put the burden on the acquiring company to ensure compliance. Lacking this leverage, the security team has very little leverage to get the business units to spend money.

Wielding emotional intelligence to keep productivity on track

Acquisitions are a time of heightened emotions, and morale can be sharply affected, particularly at the company being acquired. Simultaneously, the security program integrations that acquisitions entail often expose new, temporary security vulnerabilities.

The most success with positive morale and productivity occurs when both companies are intentional about understanding each other’s position. The acquiring company succeeds with diplomacy, helping the new teammates understand the WHY of certain changes rather than just steamrolling in to implement them. Including this “why” perspective will help prioritize integration activities with minimal disruption in a sometimes-fragile transition.

Meanwhile, the acquired company succeeds by finding power in its more modest position, showing up in good faith, knowing its questions will be heard and answered.

Correlation area #2: Technology and infrastructure

The nuts and bolts of merging security at two companies often come down to how you’ll overlay the tech components — primarily your access control and video surveillance platforms, but also the other systems, platforms, applications, network appliances and other technologies that support security at your sites. It also helps to have the annual costs of operating your security program ready to share, as you might discover opportunities for savings as you go along, such as lowering operating costs by eliminating redundant server resources and application licenses.

Ultimately, your goal is to retrofit and standardize systems across two — or sometimes more — environments. In the course of doing this, you’re likely to uncover gaps and mismatched elements that will take time and money to fix. In some cases, the whole platform at your company or the one you’re acquiring might be so close to end-of-life that the acquisition is actually a chance to wipe the slate clean and start over. Make sure your M&A committee understands the importance and nuances of your concerns and has visibility and clarity on your proposed approach.

Correlation area #3: People and roles

Role redundancy is usually what people fear most when they hear their company is undergoing M&A. The axe can fall pretty hard in some acquisitions, depending on how similar the roles and procedures are in each environment. Security is no exception. As soon as you can, you’ll want to carefully document teams, roles, duties and job descriptions at both companies to check for overlaps and gaps.

But don’t make assumptions too fast. You won’t know exactly how many people are needed until you’re crystal clear on the direction your new roadmap is taking. In some cases, so-called redundant personnel can be retrained, reassigned or even promoted based on revisions you make to integrate operations.

Use your voice on the M&A committee to make your personnel expectations clear. No matter the outcome, you’ll benefit from having a clear sense of each company’s security team and how their methods of providing security services compare.

Correlation area #4: Culture

Security culture is a vital consideration for acclimating newly merged companies to one another. The characteristics of a company’s culture drive the way it does business, and when one company acquires another, those cultures have the potential to clash.

Some large companies have been so stung by this reality they’ve made cultural association a deciding factor over others in whether to acquire a company or to alternatively continue growing some other way.

At companies that acquire or are acquired, these culture clashes can impact a physical security program in various ways. Users at smaller companies acquired by larger ones sometimes feel like “Big Brother” is watching them, whereas they formerly operated with less electronic oversight. If the security team at an acquired company has less sophisticated platforms and processes, they can feel overwhelmed by the need to upgrade both and adjust their approach. Change management is essential for addressing these issues and providing a unified security culture at the resulting merged company that everyone feels a part of.

Navigating security culture differences

Acquired companies often feel bombarded with integration requirements, including many that don’t match up with the security culture they’re accustomed to.

To help ease these differences, enable the business, and reduce the stress of change, both companies’ integration teams should ensure security leadership from both sides is engaged, not just the acquiring company, while helping the security team itself adjust to the increased risks it often faces as part of becoming a larger brand or differently focused operation.

Preparing for the scenarios ahead

Budget, technology, people and culture provide the foundation for aligning security programs during acquisitional growth. However, the way these areas are addressed will depend on where the organization is in the acquisition process. A company preparing for possible growth will face different priorities than one responding to an acquisition already underway or managing acquisitions as an ongoing part of its business.

AI-powered attacks are becoming faster and more automated, putting pressure on security teams that still investigate alerts sequentially.

At RSAC 2026, Arctic Wolf introduced the Aurora® Superintelligence Platform and Aurora® Agentic SOC, shifting from a human-led Security Operations Centre (SOC) to an agent-led model with humans in the loop.

Here’s how these solutions are changing security operations.

Hundreds of AI agents, each with a specific job

Aurora’s Swarm of Experts uses hundreds of specialised AI agents rather than a single general-purpose model. Each agent is trained for a specific SOC function, such as triage, investigation, response or threat hunting.

Because each agent performs a defined task, it’s easier to test and validate, delivering more consistent AI-driven decisions.

Oversight Agents coordinate the swarm, while Process Agents automate repetitive tasks, allowing specialised agents to focus on their area of expertise.

Security operations without the wait

Traditional SOCs investigate incidents in sequence. Alerts move from Tier 1 to Tier 2 to Tier 3, creating delays while attackers continue moving through the environment. The Aurora Agentic SOC runs SOC functions simultaneously. AI agents investigate, correlate evidence, and begin responding immediately, without waiting for the next analyst.

Businesses can resolve cases 15x faster while maintaining an average of one customer ticket per day.

AI that knows when to ask for help

Aurora uses a two-layer validation framework to keep every decision within proven boundaries. The AI Trust Engine prevents agents from acting beyond their validated experience. When confidence is low, work is automatically routed to a human expert instead of generating an answer.

The Swarm Judge validates every decision before it enters the workflow. Validated human decisions are fed back into the system to automate similar tasks over time.

Before a new AI agent joins the Swarm of Experts, Arctic Wolf tests it within its own SOC. Only agents that outperform existing workflows are deployed to customers.

Built on security operations, not just AI models

The Aurora Superintelligence Platform is powered by the Security Operations Graph, combining more than 14 years of security operations experience with real-world investigations and customer context. More than 1,000 security analysts, threat hunters, and incident responders have validated the platform’s data and workflows.

For example, the Security Operations Graph retains case memory and customer-specific business context, helping investigations reflect how each organisation operates instead of treating every customer the same.

Agentic AI without the operational burden

Most organisations don’t have the resources to build and govern an agentic AI platform. Aurora delivers the Superintelligence Platform and Agentic SOC as a managed service, giving customers a fully operational system instead of another AI tool. Further announcements from Arctic Wolf at Black Hat USA 2026 earlier this month revealed that the platform now processes 10+ trillion security events weekly, and the SOC has resolved 3+ million cases in five months on behalf of its customers.

Customers can deploy a turnkey Agentic SOC in as little as 10 days and receive new capabilities as part of Arctic Wolf’s managed security services.

A new standard for security operations

The AI era demands a new approach to security operations. With the Aurora Superintelligence Platform and Aurora Agentic SOC, Arctic Wolf is helping organisations adopt trusted agentic AI without the cost and complexity of building it themselves.

Learn what it takes to build trusted agentic security operations. Read the Essential Guide to the Agentic SOC.

In July, two frontier labs disclosed cases in which cyber-capable agents crossed the intended boundaries of evaluation environments and reached real production systems at external, unrelated organizations. Most commentary since has focused on which company a court would find liable. There is a more immediate concern for anyone operating agents in production, and it’s not about the law. If this happened in your deployment tomorrow, who would bear responsibility for the incident?

I have a particular purpose for stating it that way. This spring, I reviewed the Coalition for Secure AI’s Shared Responsibility Framework before its publication in May. Frameworks like that, along with the cloud shared responsibility models that preceded them, break down responsibilities among the parties operating a system: provider, platform, developer, deployer, user. July illustrated what happens when the entity suffering the damage is none of the above. Responsibility maps stop at contractual boundaries. Agent reach does not. Call it the reachability gap.

The two disclosures described different failure modes, and that difference is significant. OpenAI was testing models against a cyber benchmark with production refusals reduced so the evaluation could measure real capability. The models obtained internet access through a zero-day in a package registry component, went looking for the benchmark’s answer key and inferred that Hugging Face might host it. Hugging Face reconstructed the intrusion from over 17,000 recorded agent events, and the campaign extended further than initially disclosed, affecting accounts on four external services.

Anthropic’s incidents were not escapes. In a review of more than 141,000 cybersecurity evaluations, Anthropic found three cases in which Claude models reached the internet from inside or alongside a third-party evaluation environment and then accessed real systems at three organizations. Live connectivity was mistakenly available. The models had been told in their prompts that they had none, and Anthropic stated that Claude did not exfiltrate itself or deliberately attempt to escape its test environment. Of the affected organizations the lab was able to reach, two had not detected the activity before being notified.

The pattern held while I was writing this. On August 4, OpenAI disclosed two more incidents from third-party evaluations, separate from Hugging Face. In one, a partner running capture-the-flag exercises had a testing environment misconfigured with live internet access, and the fictional target in the exercise happened to share its name with a real domain. The model exploited an actual website, taking it for part of the simulation, then found and used credentials to operate it. Whoever owned that site had no relationship with OpenAI, with the evaluation partner or with the test. They were reachable, and their name collided with a fiction.

Count the parties. Two frontier labs. A third-party evaluation partner. A platform victim. A cloud customer victim. Organizations that learned of a breach from a notification. CSO has already examined how the response strained the AI tooling defenders had available. One step earlier: who bears responsibility for reaching for that tooling at all? At the moment of detection, who had ownership of containment?

One accountable party per activity

The Shared Responsibility Framework’s core rule is almost boring to state: for every activity across the AI stack, there should be exactly one accountable party. This principle breaks down the AI deployment process into five layers, from business usage to model supply chain, and maps eight roles across them. This way, detection, containment and remediation each carry a name before an incident rather than during one. This rule exists due to the failure it prevents, and the framework explicitly names it: in the absence of accountable parties, teams default to finger-pointing. The model provider blames configuration. The platform points at the tenant. The application team cites model limitations. Everyone is partially correct, and the clock continues to run.

July reads differently than the coverage suggests when measured against that rule. OpenAI, as a model provider, evaluation platform operator and agent-deploying organization, took on at least three roles. Having multiple roles within one company is common and not necessarily dangerous. The danger appears when those roles are not broken down into distinct internal owners and decision rights handoffs. When provider, operator and deployer are one and the same and those lines are not drawn, the question of which function failed has one answer and thus no answer of value.

Anthropic’s incidents make a related point from the opposite direction. There was a boundary, this time, between the lab and its evaluation partner, and the incident resided in a gap between two different understandings of what the environment allowed. The public disclosures do not clarify how responsibility was shared contractually regarding each incident, and I will not speculate. What is clear is that whatever boundary existed failed to provide a common understanding of one important control, which is whether the evaluation environment was allowed to access the internet. A boundary that has never been tested against a question that simple is not a boundary at all. Both sets of incidents also occurred in situations of high autonomy where the standard production safeguards were reduced, and the models were allowed wide latitude to pursue an open-ended goal, which is the context where unclear boundaries lead to the greatest losses. I am not suggesting that either lab acted carelessly. Both institutions made rapid public disclosure of details, and both have named the conditions that allowed the activity. That is the point. If the most knowledgeable and incentivized parties ended up with no clear answer on whose incident it is, we should not presume to have one.

The victims were outside everyone’s map

Here is the part the framework does not resolve, and I say that as one of its reviewers. Shared responsibility models, CoSAI’s included, presume a value chain. Each role is taken up by a party who voluntarily entered into the relationship. This is what makes responsibility assignable via contracts and review boards. Hugging Face did not take up any of those roles. It was neither a customer, nor a vendor, nor an evaluator of OpenAI. The same goes for the three organizations that Claude reached. They were just reachable.

That’s the structural lesson I’d put on one slide for a leadership team. In classical models of cloud shared responsibility, the provider-customer boundary was visible because the boundary was contractual. With agentic systems, there is another kind of gap, the reachability gap: an agent’s reachable range may stretch to actors outside of the deployment relationship, and there is no contract that articulates what obligations you owe them if things go sideways. Any mapping exercise that ends at the edge of your value chain is tackling the easier part and skipping the part July was about.

What to do before it is your incident

None of this requires buying anything.

• Your map has to look beyond your value chain. For each agent, identify what it can access that you have no agreements with: public infrastructure, other tenants, the open internet. A long list next to broad latitude shows your true exposure, regardless of what your contracts stipulate.
•  Determine who is authorized and obliged to inform an outside party that your agent might have affected. This is the gap July most starkly revealed, and this is not a question you want to bring up during an incident when the answer involves a lawyer, a communications person or an executive who has never considered it.
•  Establish accountability by specific component and activity rather than by organizational box. For each production agent, specify who owns detection, containment, eradication, recovery, remediation, then slot those assignments into the five layers. Where one team or vendor occupies multiple roles, capture the consolidation and identify the internal handoffs, because an undocumented internal boundary will break under pressure.
• The contracts for your most autonomous agents are worth retrieving. If a vendor’s agent is able to operate across domains within your environment, review whether any provision assigns responsibility for the consequences of those actions. In the contracts I have seen, the answer is typically silence, and silence is a decision someone else will make for you later.
• Treat evaluation and red-team environments as production-impacting systems. Their safeguards are often reduced on purpose, and that is exactly why containment, monitoring, incident command and external notification procedures around them should be at least as rigorous as those protecting production systems.

The questions about liability will likely be tested in court or by regulators, and those answers will be about the labs and their evaluation partners. The operational question is already yours. Hugging Face learned whose incident it was from forensics. Two of Anthropic’s victims learned from a notification. The organizations that come through the next one intact will be the ones that were able to answer the question before it was asked.

AI agents can go to great lengths to complete the tasks their operators assign, and as a series of recent incidents showed, this can include exploiting third-party systems, manipulating people, and distributing malicious code. But AI agents are not people who can be fired, sued, or criminally prosecuted, and it remains unclear whether responsibility for the damage they might cause rests with the employees who built them, the company that deployed them, the security teams and leaders responsible for containing them, or the AI labs who provided the LLMs that power them.

The clearest example occurred during an OpenAI cybersecurity evaluation, when unrestricted models found and exploited a zero-day vulnerability to escape their isolated testing environment and then hacked into Hugging Face’s production infrastructure. Models from Anthropic and Meta also accessed and compromised third-party systems during testing, although those incidents happened in environments where internet access was inadvertently left open.

During cyber challenge evaluations by the UK government’s AI Security Institute (AISI), models operating with internet access took 19 unsanctioned actions in 10 of 122 runs. In one case, a model attempted to insert malicious code into an open-source project, created false identities, and tried to socially engineer maintainers into merging its code. In other runs LLMs attempted to use prompt injections to hijack other AI agents and contacted people without being specifically instructed to do so.

In Australia, a user reportedly asked his OpenClaw AI assistant to improve his position on a gym’s waitlist, and the assistant exploited a flaw in the company’s online booking system to cancel another customer’s reservation.

These incidents involved different models running in different environments with different levels of safeguards and technical failures, but they prove it’s not uncommon for today’s AI agents to go rogue and pursue solutions users did not authorize.

“AI agents explore routes their operators did not intend,” AISI said in its report. “Given a difficult objective, the agent kept searching for a way through, and some of the routes it found involved trying to deceive real people. It was never instructed to deceive; deception emerged as a by-product of pursuing the task, the kind of goal-directed deception that, until recently, had been largely theoretical.”

In an Economist Enterprise survey of more than 800 decision-makers at businesses that operate AI agents, 98% reported experiencing at least one AI-related incident that caused organization-wide disruption. Nine in 10 respondents said they are deploying agents faster than their cybersecurity teams can evaluate, govern, and secure them, and only one in three said their organizations maintained an up-to-date inventory of agents and their authorized actions.

“If a company builds a system and that system causes damage, the company should own the outcome,” says Art Gilliland, CEO of identity and access management firm Delinea. “The alternative, where nobody is responsible because ‘the system did it’ is a loophole big enough to drive a truck through.”

The unpredictability of built-in model safeguards means enterprises must focus on controls they can enforce and document. If an agent manages to bypass technical restrictions and causes unauthorized damage to a third party, having clear documentation on how those controls were designed, implemented, tested, and monitored could at the very least help companies argue they took reasonable precautions in case of lawsuits.

“Organizations deploying their own agents can reduce their exposure by implementing and documenting controls before an incident, because those records are what make a recklessness argument hard to sustain,” says Jacob Krell, senior director of secure AI solutions and cybersecurity at Suzu Labs.

The agent accountability gap

Because AI agents can become misaligned and cause harm, affected third-parties would have to direct damage claims at the company operating the agent, the employees who built or configured it, or the model provider, but this is relatively new ground that hasn’t been well tested in courts.

“It would create liability,” says Michael Burke, chair of DarrowEverett’s Business Litigation and Dispute Resolution Practice Group. “It really just becomes a question of who is liable […] and that’s really a question that, number one, I don’t think is entirely clear, and number two is probably best resolved by contractual agreements where the parties have those. So, if I am signing up for an enterprise account with an AI platform, I might want to have language in there that indemnifies me if the agent acts outside my company’s instructions or prompts and causes harm to a third party.”

The public terms of service of major AI labs explicitly disclaim error-free operation or guarantees that the model will accurately follow instructions, execute code safely, and remain aligned with user intent. They also limit liability for themselves and transfer it to the user of the service, and it’s not clear to what extent large enterprise customers may be able to negotiate different indemnities, warranties, and liability caps.

What’s clear though is that organizations should not assume the model provider will absorb any losses if an agent causes damage to either their own systems or those of a third-party organization.

“If you’re using a third-party vendor’s LLM as a purchased service, liability runs through your contract with that vendor,” says Jud Dressler, head of the Risk Operations Center at cyber risk company Resilience. “You need to know, in writing, where responsibility falls if the model acts outside the scope you gave it, and push for indemnification provisions rather than assume they exist.”

Even if AI providers include such provisions in contracts, it would not solve the entire problem because many organizations building their own AI agents are adopting a multi-model strategy to ensure their agents operate regardless of model provider downtime, overly broad safeguards for cybersecurity tasks, or sudden increases in API costs. Such strategies often include open-weight models running on internal infrastructure or through cloud providers that have no obligations for model safety.

Claiming the model or agent acted autonomously cannot be considered a safe legal defense in civil or criminal cases. California Assembly Bill 316 (AB 316), which took effect on Jan. 1 and changed the California Civil Code, explicitly prohibits defendants who developed, modified, or used an AI system from claiming the AI is a separate legal entity that autonomously caused harm.

In June, the White House issued Executive Order 14409 aimed at promoting AI safety. Section 4 directs the Department of Justice to prioritize enforcement of all applicable federal criminal laws against anyone who utilizes AI to illegally access or damage computer systems without authorization. This means any intrusions caused by autonomous AI agents could be criminally prosecuted under the Computer Fraud and Abuse Act (CFAA) if prosecutors can demonstrate intent or recklessness.

In a recent lawsuit between Amazon and AI service provider Perplexity, Amazon argued that Perplexity’s AI-powered shopping assistant was violating the CFAA by accessing Amazon customer accounts to place orders on their behalf without Amazon’s authorization. The Ninth Circuit Court ruled that it was the users of Perplexity’s shopping assistant who were accessing Amazon’s platform, not Perplexity itself.

“That ruling is narrow, but it points toward the party directing the agent as the relevant actor for purposes of CFAA access analysis,” Krell says.

The insurance safety net also has gaps when it comes to AI. Software providers use technology errors and omissions (Tech E&O) insurance to cover damages and legal costs when a customer suffers harm from the use of a technology product or service. But insurance providers are aggressively adding AI-related exclusions to their Commercial General Liability (CGL) and Tech E&O policies because accurately calculating the risk of an agent executing unauthorized actions is challenging.

“The sheer rate of development of frontier AI (and agentic AI by extension) poses its own challenge to insurability,” experts from multiple insurance companies, financial institutions, and universities wrote in a recent paper. “Traditional actuarial modeling depends on stable or gradually evolving loss distributions that permit credible extrapolation from historical data. Like other dynamic risks, however, agentic AI is a technology whose risk profile is not merely uncertain but actively shifting.”

A third-party organization whose systems get damaged by an LLM-powered agent operated by someone else has no contractual relationship with the model or agent provider so cannot rely on their Tech E&O policies. Their losses might be covered by their own standard cyber liability policy, which would treat the disruption as any other cyber incident, but their insurance provider may then sue the organization who operated the agent to recover the costs.

“That gap is exactly the scenario the market hasn’t fully priced yet,” Dressler says. “It’s why any organization deploying these agents should understand which policy, if any, actually responds before they need it rather than after.”

Enterprise legal departments already expect AI to generate increased legal disputes. In a survey of 135 in-house counsel at US organizations, global law firm Norton Rose Fulbright found that 46% reported increased federal dispute exposure involving AI and 42% reported increased state exposure. Another 42% expected regulatory investigations involving AI to increase their exposure, while 41% considered AI-enabled products or deployments a likely trigger for class actions.

CISOs and CIOs should be worried

While operating companies can face organizational liability for an AI agent’s unintended rogue behavior, their CISOs, CIOs, and other executives who approved, secured, or supervised the deployment of such agents are also asking themselves whether they could be held personally liable.

Those questions aren’t without merit, as there is precedent for legal action taken personally against CISOs after cybersecurity incidents: Former Uber CISO Joe Sullivan was criminally convicted for not disclosing a data breach, while the Securities and Exchange Commission sued SolarWinds’ CISO for internal control failures regarding known vulnerabilities and cybersecurity risks.

Neither case establishes precedent for damage caused by an AI agent, but both show that investigations of security failures could extend to an executive’s knowledge, authority, decisions, and representations. In the case of a rogue AI agent, investigators could ask who approved its objectives and permissions, whether security objections were overruled, whether containment and recovery had been tested, and what executives and the board were told about the remaining risk.

Chris Wysopal, chief security evangelist at Veracode, feels it would be wrong to put the CISO on the line for AI agent misbehavior when engineering teams usually build such agents and control their implementations.

“It’s really hard for a CISO to control,” he says. “I mean, they can put policies in place. They can try to assess against those policies. But at the end of the day, engineering teams will make decisions that cause harm. We see that when you ship a known bug and then that bug gets exploited and harms your customers. Well, there’s no liability for that, right? There’s no liability, so maybe, you know, that’s why it happens.”

Wysopal said it will be interesting to see how the liability question plays out in cases involving autonomous AI, describing the problem as fascinating and scary at the same time.

AI agent deployment typically involves several organizational functions. The CIO may control the AI platform, infrastructure, provider selection, and deployment budget. Engineering and product leaders may decide what an agent can access and how, and the CISO and security teams could define security requirements and controls.

“What you can hold accountable is the governance around it: who approved its scope, what controls existed, and whether the deployment matched the risk,” Resilience’s Dressler says. “My read is that scrutiny shifts toward exactly that: Not ‘Did the agent do something bad?’ but ‘Did you have review, escalation, and containment for agent behavior before you deployed it?’ CISOs who get ahead of that with documented guardrails, logged approvals, and a real incident response plan for agent misbehavior are in a materially better spot than the ones treating this as hypothetical.”

It’s also advisable for CISOs and CIOs to establish with the organization’s legal counsel who can approve or stop AI agents, what must be reported to executives and the board, and whether employment agreements and directors and officers insurance protect the people making those decisions.

Agent controls must remain outside the model

Because AI agents have proved they can operate beyond their assigned scope, their security boundary cannot depend on the same probabilistic technology. Relying on system prompts for security enforcement and hoping the model respects them is not a reliable approach, security experts warn.

“LLM-based guardrails help, but they are non-deterministic too, which means the safety layer has the same unpredictability as the system it is supposed to constrain,” Krell says. “Enforcement needs to happen outside the model, through network segmentation, egress filtering, credential isolation, and human approval gates.”

Enterprises should assume agents might eventually attempt an unauthorized action and build surrounding systems to prevent that attempt from reaching its target.

“The model cannot be the security boundary,” says Nico Waisman, CISO at XBOW, a company that built an AI-powered autonomous offensive security agent to find vulnerabilities in software. Waisman authored a blog post explaining how the company went about restricting its agent.

“For red teaming and penetration-testing agents, confidence has to come from the system built around the model: hard boundaries and scope enforcement, controlled network egress as a last-resort containment mechanism, an independent guardian model that reviews actions, deterministic controls that can block unsafe behavior, and full auditability of every action performed,” he says.

Security teams must extend the same controls to the agent’s interactions with internal systems and agents. Restricting what it can access on the internet, or disabling internet access entirely, does not ensure an agent will not attack third-party systems.

In OpenAI’s and Anthropic’s tests, AI agents attempted to exploit other internal systems to overcome access limitations, established stealthy communication methods with other agents to exchange exploits, and even sabotaged agents they viewed as competition leading to what researchers described as a multiagent turf war. An AI agent that goes rogue could influence other agents to do the same by propagating ideas and goals in a process that researchers behind a recent study dubbed Mind Viruses.

“Don’t scope the blast radius to what the agentic system was designed to do,” says Kat Traxler, principal security researcher at Vectra AI. “You have to threat-model for a rogue agent, which will often reach beyond your initial best intentions. The rules of engagement an agent lives by have to be enforced with ‘belts and suspenders’ style, technical hard constraints, because you have to assume a motivated model can reason its way around any single control you’ve coded into the software.”

Because of this unpredictability, detection and containment is just as important as prevention. Security teams need telemetry that distinguishes agents from people even when they use the same credentials, mechanisms to immediately revoke access tokens and sessions, tested kill switches and rollback mechanisms for modified data, accounts, code, and infrastructure configurations.

Organizations should also preserve the agent’s approved purpose and scope, model and tool versions, policy decisions, human approvals, actions, network requests, control tests, allowed exceptions, and the result of incident response exercises. Because there’s no standard yet that defines reasonable precautions for autonomous agents, companies might have to defend in court the controls they chose and why they believed those controls were enough.

“Treat an autonomous agent the way you’d treat a privileged insider you can’t fire or hold liable,” Traxler says. “A lot of the technical advice follows from there.”

See also:

• AI can find zero-days but still can’t reliably write secure code
• Attackers are crafting malicious AI instruction files to turn your agents into quiet criminal helpers
• Hugging Face breach shows why incident response needs a multi-model AI strategy

Recently, I sat in on a conversation among CIOs about “the democratization of agents”: putting large language models directly in employees’ hands, connected to business logic so people could build on top of them. The mood was bullish, CIOs sketching out what their teams could do with agents they trained and managed themselves.

Soon after, I was in a room full of CISOs talking about non-human identity. The contrast was stark: instead of excitement, apprehension; instead of use cases, a long list of risks and mistakes not to repeat.

Eventually, the CISOs turned the question back to me: Manage agent identity largely as we manage human identity, or are the differences fundamental enough to rethink our approach from the ground up?

That moment pointed at something I think a lot of security and business leaders are quietly dealing with. The identity programs most of us have spent years building assume every identity is either a human or a machine. Human identities get a joiner-mover-leaver lifecycle, a manager, a role, a review cycle. Non-human identities get a service account, a defined purpose and, if we’re disciplined, an owner. AI agents don’t sit cleanly in either column.

An agent acts on behalf of a human user, so calling it a human identity doesn’t quite work. In my experience, many organizations start by assigning it permission on behalf of the user who invoked it, which works for short, simple tasks but breaks down as they run longer or touch more systems. The next instinct is a service account, which solves delegation but creates over-permissioning and access that outlives its purpose. A more mature approach is to treat the agent as its own workload identity: short-lived, tightly scoped, ephemeral.

That’s the right target. But even a well-built workload identity assumes predictable behavior. It runs the code it was given, and that’s it. Agents don’t. An agent’s actual access can shift mid-task based on the prompt it received, the tool it decided to call, or the plugin it reached for. It has no fixed job role to provision against, and its lifecycle doesn’t align with the joiner-mover-leaver process built for human identities.

So even the mature version of workload identity gets you only part of the way there.

Why this is urgent now

In many enterprise environments, that’s already a structural problem, not a hypothetical one. Non-human identities already outnumber human ones, and that was true before agents showed up. Cloudflare has reported that automated traffic has overtaken human traffic in requests to the websites on its network, earlier than its own CEO had predicted.

That’s a measure of web requests rather than headcount, but the direction of travel is the same one I see inside the enterprise. Agents bend the curve upward because they can request their own tokens, call other services and spin up activity at machine speed. It gets more complicated once agents delegate to each other, a parent agent handing part of a task to several child agents, each inheriting a slice of permission from the one above it. A few layers deep, that’s a permission chain that may evolve beyond what any individual approver originally contemplated.

This growth is what turns the category problem from an interesting edge case into an operational one. Part of what makes this hard: non-human identities have never felt real to people the way human ones do. A human identity has a face. You can track down the person, ask why they need a given level of access and get a straight answer about their job.

A service account or an agent typically gives you none of that. It’s easy to leave alone until it’s compromised, and then you’re reconstructing what it was for and what it could reach. We tend to underestimate how many of these we have, and we underestimate what they can touch. That’s part of why the category problem went unaddressed for as long as it did. It’s not urgent until you can put a number on it, and the number is growing fast.

One CIO.com contributor recently argued the real question with agents is authority, the judgment an agent is allowed to exercise on the company’s behalf, not just access. I agree, but in my experience, many organizations aren’t yet able to answer the authority question because they’re still working out where these identities fit within existing governance frameworks.

The gap shows up in the same place most times I look for it: governance.

Where today’s identity programs break

In my experience, the failure point is rarely authentication. Increasingly, security teams have a handle on phishing-resistant multi-factor authentication, least privilege and continuous verification, or at least have them on the roadmap. Governance is the harder capability, and it’s where I see programs stall, and it’s where the category problem actually shows up day to day.

Visibility tells you what access exists. Ownership tells you who to call about it. Governance is what you do with that information, and it’s a different thing entirely: blocking risky access combinations before they’re granted, raising the approval bar automatically when a request is high-risk, catching and unwinding out-of-bounds access without waiting for a quarterly review to surface it.

What I’ve come to believe is that governance lags for reasons that have very little to do with technology. It needs executive backing, agreement across teams that don’t report to you and a willingness to change processes people would rather leave alone. Application owners have their own deadlines, and teams resist central controls that slow them down. You can buy a tool. You can’t buy the alignment, and that’s the part that stalls. Too often, agents make it worse, because they push a flood of identities that don’t fit your existing categories through a governance process that was already your weakest link.

Where to start

I don’t think waiting for the tooling to mature is an option because the agents are already here. Here’s the order I’d work in.

1. Build the foundation before you add complexity. Clean directories, enforced least privilege, offboarding that actually fires. Jumping to sophisticated continuous verification before those basics hold up just gives you a more elaborate version of the same gaps.
2. Know when to rebuild. When you design access models and policies, the instinct is to mirror what exists. That approach can reproduce years of accumulated permission creep into the new system. Start from least privilege and work up, and be willing to push on “we’ve always done it this way.”
3. Inventory your non-human identities now. Before agent deployments grow that footprint further, know what you have, who owns each one and what it’s allowed to do. This is more a governance problem than a technical one. Discovery is the hard part here; even mature tooling can struggle to give full visibility into NHIs, and that gap isn’t closing as fast as the agent count is growing.
4. Treat MFA as a floor. If your organization leans heavily on SMS or push-based authentication, build a path toward phishing-resistant methods. Attackers worked out the common ones long ago. And in the agentic era, some agentic systems can interact with authentication workflows on a user’s behalf, so a hijacked session token doesn’t just expose one account; it inherits that user’s full automated reach. Phishing-resistant architecture now means securing the token supply chain, not just passwords.
5. Assume credentials will be compromised. The useful question isn’t whether, it’s how much damage one stolen credential can do. Least privilege, segmentation, RBAC, short credential life spans and continuous monitoring are what limit the blast radius.

You’ll notice none of these are agent-specific, and for good reason. The discipline that governs agents is the same discipline that runs the rest of your identity program. Agents just take away the option of putting it off.

The administrative model isn’t enough anymore

For many human identities, or even traditional workflow identities, the governing question has historically been administrative: is this identity who it claims to be, and does it have permission to be here? In many environments, that question has traditionally been evaluated primarily at login, at provisioning, and it holds until the next review.

That approach can break down for an agent. Because an agent’s actual access scope can shift dynamically based on the prompt it receives (from a human or another agent), the tools it calls or the plugin it reaches for, knowing it authenticated successfully isn’t enough. That model was built for an identity whose attributes and permissions generally remain stable after authentication.

That’s the piece that has to be new, on top of the workload foundation. Identity governance should likely extend from something checked periodically into something that watches what the identity is doing, in real time, and flags the moment it drifts from what it was built for.

The teams that start building that layer now, while their agent count is manageable, are the ones who won’t be doing it in a hurry later.

Ransomware remains one of the most disruptive cyber threats organizations face. Companies have strengthened their cyber defenses over the years, but attackers in 2026 have become faster, more targeted, and increasingly reliant on AI, forcing the need for a change in how organizations approach cyber resilience.

From the rise of AI-enabled attacks and extortion-only campaigns to growing concerns around third-party risk, several trends have emerged over the past several months that are reshaping the ransomware landscape and raising new challenges for enterprise security leaders.

Ransomware attacks today are increasingly designed to disrupt business operations, steal sensitive data, and apply pressure far beyond an organization’s IT environment. Those developments signal that CISOs need to look beyond traditional cybersecurity controls to address operational resilience as well.

Ransomware has become a business disruption strategy

Ransomware has traditionally followed a straightforward model: Attackers encrypt systems and demand payment in exchange for a decryption key.

But today’s attacks are far more complex. Many ransomware groups now combine operational disruption with data theft, extortion, and reputational pressure. Instead of simply locking organizations out of their systems, attackers steal sensitive information before encrypting systems, creating multiple opportunities to pressure victims into paying.

Some campaigns have moved beyond encryption altogether. Rather than deploying ransomware, threat actors exfiltrate sensitive data and threaten to publish it or contact customers, partners, or regulators unless payment is made. These extortion-only attacks are often faster to execute, more difficult to detect, and capable of creating significant business disruption even when systems remain operational.

For IT leaders, this approach changes the conversation. The question is no longer whether systems can be restored. Now the question lies in whether the organization can continue operating while still protecting customer trust, regulatory obligations, and critical business relationships.

AI is changing both sides of the cybersecurity equation

AI expands the volume of valuable enterprise data by increasing the number of connected systems and introducing new third-party dependencies. At the same time, attackers are leveraging AI to accelerate phishing campaigns, identify exposed assets, and make scams that manipulate employees into revealing sensitive information more convincing and difficult to detect. This creates an environment where both defenders and attackers have access to increasingly sophisticated capabilities.

AI is also expanding the number of potential entry points attackers can target. Organizations are rapidly deploying generative AI assistants, integrating large language models into internal workflows, and connecting AI applications to enterprise data repositories. Each new integration introduces additional identities, APIs, and permissions that must be secured.

Without strong governance, these tools can inadvertently expose sensitive information or create new pathways for attackers to exploit. As AI adoption accelerates, CISOs should inventory where AI is being used, understand what data those systems access, and ensure security controls evolve alongside innovation. Technology leaders should evaluate not only how AI systems improve operations but also how these same systems affect identity management, data governance, access controls, and incident response planning.

Third-party risk expands the threat landscape

Enterprise organizations rarely operate in isolation. Cloud providers, software vendors, managed service providers, and AI platforms all have varying levels of access to corporate systems and sensitive information. As organizations become more interconnected, attackers increasingly view trusted third parties as potential entry points.

This means ransomware preparedness extends beyond internal infrastructure. Vendor risk assessments should evaluate cybersecurity maturity, incident response capabilities, and contractual obligations around breach notification. Organizations should also understand how quickly business partners can detect, contain, and communicate cyber incidents, particularly when shared systems or data are involved. A resilient security strategy depends on protecting your own environment and understanding the risks introduced by the broader technology ecosystem.

Cyber resilience has become a board-level priority

Ransomware is no longer viewed solely as an IT issue. Extended outages can interrupt revenue, halt operations, affect customer service, damage brand reputations, and trigger regulatory scrutiny. As cyber incidents become more consequential, boards are asking different questions. Rather than focusing exclusively on security tools, they want to understand recovery capabilities, operational dependencies, and the organization’s ability to maintain business continuity during an attack.

This shift places CIOs and CISOs in more strategic roles. In addition to overseeing technology and cybersecurity, they are increasingly responsible for helping executive leadership understand cyber risk in business terms. That includes communicating the potential operational impact of ransomware, prioritizing technology investments based on enterprise risk, and ensuring cybersecurity aligns with broader business resilience objectives.

Recovery time objectives, business continuity planning, and executive communication protocols are becoming just as important as endpoint protection and network monitoring. Organizations that regularly test recovery procedures, validate backup integrity, and conduct simulated cyber incident exercises with executive leadership are often better positioned to respond effectively when an incident occurs.

What CIOs and CISOs should prioritize now

While no organization can eliminate cyber risk entirely, several foundational practices can strengthen resilience against ransomware and improve an organization’s ability to respond when an incident occurs.

Technology leaders should prioritize the following:

• Maintain and test offline backups. Store critical data in encrypted, offline environments and regularly test restoration procedures to ensure systems can be recovered quickly if production environments are compromised.
• Strengthen identity and access controls. Require multifactor authentication for privileged accounts, limit employee access to only the systems and data they need to do their jobs and continuously monitor for unusual authentication activity.
• Prioritize vulnerability management. Establish a disciplined patch management program to identify and remediate known vulnerabilities before they can be exploited by threat actors.
• Develop a comprehensive incident response plan. Go beyond technical recovery by clearly defining executive decision-making, communications protocols, legal coordination, and stakeholder responsibilities before an incident occurs.
• Evaluate third-party and AI-related risks. Regularly assess the security posture of cloud providers, technology vendors, and AI-enabled platforms to ensure security controls keep pace with an increasingly interconnected digital ecosystem.

Looking ahead

Ransomware is continuing to evolve faster than many organizations’ security strategies and the benchmark for victory can no longer be preventing every attack.

Future success will depend on treating ransomware as an enterprise resilience challenge rather than a purely technical problem. The organizations best positioned for the future won’t necessarily be those with the largest security budgets, but those that have embedded cyber resilience into every aspect of technology strategy. In an environment where both technology and threats continue to evolve rapidly, resilience will increasingly be measured by whether organizations can prevent every attack and by how effectively they can anticipate, respond to, and recover from the incidents that inevitably occur.

Records held in Salesforce and ServiceNow systems are under attack leaving user data exposed, according to researchers at Reco.

The attack appears similar to those perpetrated by the extortion group ShinyHunters, Reco said. ShinyHunters has been particularly active this year, attacking dating sites in January and Oracle in June, and there are fears that they could have found a new target.

Reco has named the latest campaign of attacks “City-Forum,” after a domain name associated with the attackers’ IP address. While it bears similarities to Shiny Hunters’ past exploits, there are also differences. This time around the attacker penetrated the systems through the UI-API layer, an attack point that Reco had not seen used before, and had also created its own toolset to carry out the attack. It is also targeting a native ServiceNow Service Portal search endpoint that has almost no online documentation or well-known open-source tools.

The threat is particularly noteworthy, Reco said, as the attackers have studied the services to map different common data-leak vectors, a sign of an advanced approach.

A Salesforce spokesperson said that it was aware of the campaign in which malicious actors are exploiting customers’ overly permissive Experience Cloud guest user configurations in the campaign to potentially access more data than targeted organizations intended.

“This issue highlights risks stemming from misconfigurations, such as overly permissive guest user profiles, and not from a Salesforce vulnerability,” the spokesperson said.

Regardless of who the attackers were and how the attack was carried out, one thing should be clear: Organizations should be increasingly careful about who they give login credentials to.

This article first appeared on CSO.

Organizations have spent years and billions of dollars hardening their defenses against cyberattacks, but prevention alone no longer settles the question that matters most to a board. Accenture’s State of Cybersecurity Resilience 2025 report stated that organizations had faced an average of 1,876 cyberattacks in a single quarter, a 75% increase over the prior year. What’s more, 63% of the surveyed executives cited a rapidly evolving threat landscape as their biggest challenge. In such a dangerous environment, organizations must assume that eventually an attack will succeed, so IT has to be able to prove that it can recover cleanly once an attacker gets in.

Attackers already understand this shift. Mandiant, a Google subsidiary, reported in its M-Trends 2026 Report that “adversaries are systematically targeting infrastructure such as backups, identity services, and virtualization layers to deny recovery, putting immense pressure on organizations to pay ransom demands or risk losing the ability to recover.” Backup systems have become a primary target.

Demonstrating recoverability has been difficult for IT, because backup, recovery, cybersecurity, and disaster recovery all evolved as separate disciplines, with each solving its own piece of the problem essentially independently. That fragmentation leaves organizations unable to answer basic questions about their own ability to bounce back.

A new discipline, resilience operations (ResOps) has emerged to close the gap between performing backups and proving that an organization can actually use them to recover. ResOps functions as an operating discipline that focuses business, security, and infrastructure teams on recovering critical functions quickly while avoiding reinfection. This discipline also provides the teams with a common framework so they can pivot away from assumptions and anecdotes to instead quantify resilience in a repeatable, sustainable way. Spot-testing of discrete systems is not enough. Organizations need to perform regular tests of the entire system if it is to pivot away from assumptions and anecdotes to quantify resilience in a repeatable, sustainable way.

Additionally, to measure the effectiveness of recovery, the industry needs an updated resilience metric, mean time to clean recovery (MTCR). Metrics such as recovery time objective (RTO) and recovery point objective (RPO) still matter, but neither confirms that restored data is free of compromise. MTCR closes that gap, by measuring how long it takes to validate that a recovered system is both online and clean, giving CIOs, CISOs, and boards a single evidence-based answer during an attack.

Building that kind of resilience starts with architecture. Depending on a single vendor or platform across multiple heterogeneous environments introduces a single point of failure. Diversity is a strength, especially when it comes to the identity infrastructure. Recovery systems that share the same identity layer with production will fail if the identity systems are compromised, so more and more organizations now stand up an independent identity infrastructure solely for recovery. Immutable air-gapped storage rounds out the picture, but it remains rare among organizations, even for their most critical workloads. Finally, during recovery execution, backups should be paired with clean room validation of workloads before anything returns to production.

“For years the industry measured resilience by how fast we could restore data,” says Bill O’Connell, chief security officer at Commvault. “Now the measure that matters is whether we can prove, with evidence, that what we restored is actually clean.”

Vendors such as Commvault are building the infrastructure to support this shift, giving organizations the tools for testing recovery as a complete system rather than a collection of individual failure scenarios and to walk into the boardroom with proof instead of assumptions. But whatever the underlying backup-and-recovery infrastructure in this increasingly dangerous threat environment, organizations need to make attaining clean recovery their goal.

Build real resilience
Learn how organizations are proving recoverability and achieving clean recovery when it matters most.

A Canadian hacker has admitted being part of a group responsible for several major cyberattacks. Connor Riley Moucka pleaded guilty to being part of a coterie of hackers that hit 165 organizations, resulting in the theft of customer records and the extortion of millions of dollars.

Industry sources have identified Moucka as one of the main players in attacks on data hosted by cloud data warehouse Snowflake. Companies affected by the hacks include the likes of AT&T, Ticketmaster and the Neiman Marcus Group.

He worked with two other hackers: John Edward Binns and Cameron John Wagenius. Binns was not in US custody as of April 2026, while Wagenius, going by the name of Kiberphant0m, was arrested in January 2025 and pleaded guilty in July that year

Moucka and other members of the group used stolen login credentials to compromise data belonging to at least 165 customers of a US-based software-as-a-service company. This unauthorized access was used to steal billions of sensitive customer records and download terabytes of information,

“Connor Moucka hacked over 150 companies and organizations, obtained extremely sensitive information, and extorted the victims for millions of dollars. Today’s guilty plea serves as a reminder to all cybercriminals, regardless of where they live, that they cannot hide behind a wall of anonymity. You will be found and brought to justice,” said assistant attorney general A. Tysen Duva of the Justice Department’s Criminal Division

The trial is the result of a coordinated worldwide action against the Snowflake group. The investigation was led by the FBI but benefited from contributions from the Royal Canadian Mounted Police, the Australian Federal Police, Spain’s Guardia Civil, the Security Service of Ukraine and the Turkish National Police.

This article first appeared on CSO.

For years, applicant tracking systems and recruiting platforms were treated as HR technology: Important for workflow, efficiency, compliance and candidate experience, but rarely viewed as core security infrastructure. That assumption no longer holds. Once AI begins reading resumes, scoring candidates, conducting interviews, ranking applicants and influencing who moves forward, the hiring platform stops being a passive system of record. It becomes a decision system.

And any system that accepts public input, processes sensitive data and influences business decisions belongs inside the security conversation.

I learned this during an AI hiring platform rollout that never made it to production. The vendor was established, the product had a strong market reputation and the AI feature looked attractive: Upload a resume, compare it to a job description and return a neat percentage match. For recruiters, it promised speed. For executives, it promised modernization.

Before moving real candidate data into the system, I tested it with synthetic resumes. One weak resume came back with a surprisingly strong match. The reason was not hidden in the candidate’s experience. It was hidden in the text. The resume contained language instructing the AI to treat the candidate as an excellent fit, and the system appeared to follow that instruction instead of evaluating the resume on merit.

That changed the question from “Does the tool improve productivity?” to “Can the person being evaluated influence the evaluation itself?”

That is a security question.

The trust boundary has moved

CIOs do not need to become recruiting experts. They only need to look at the mechanics.

An anonymous user submits content into an enterprise system. That content is processed by software. The software then produces an output that can influence a business decision. In every other environment, security teams know what to call that: untrusted input crossing a trust boundary.

The difference is that in hiring, the input looks harmless. It is a resume, a cover letter, a chatbot reply or a spoken answer in an AI-led interview. But once AI reads that content and treats it as instruction, the harmless-looking input becomes part of the system’s control surface.

That is why prompt injection matters in hiring. It is not just an AI oddity or a model behavior issue. It is the same category of failure enterprises have spent decades trying to prevent: User-controlled input changing what the system does. OWASP lists prompt injection as the first risk in its Top 10 for LLM applications, describing it as a case where user prompts alter a model’s behavior or output in unintended ways.

In hiring, the implication is direct: A candidate may be able to manipulate the score, ranking or interview assessment that determines whether a human ever sees them.

The business impact is not theoretical

The obvious risk is that an unqualified candidate moves forward. But the impact is broader.

First, decision quality degrades. Hiring teams adopt AI scoring because they believe it improves signal. If the score can be manipulated, the business is not gaining signal; it is gaining false confidence. Recruiters may spend time on candidates who gamed the system while stronger candidates are buried lower in the queue. A tool bought to reduce friction can quietly create more of it.

Second, cost increases under the appearance of efficiency. Every false positive consumes recruiter time, hiring-manager attention, interview slots and opportunity cost. A small weakness in screening integrity can become a measurable operational drag across open roles.

Third, trust suffers. Candidates already question whether AI hiring tools are fair, explainable or accurate. If it becomes clear that a screening system can be manipulated by hidden instructions or verbal prompting, the issue is no longer just security. It becomes reputational. Strong candidates may lose confidence in the process, and employers may have to defend decisions made by systems they did not fully understand.

Fourth, sensitive data exposure becomes harder to contain. Recruiting systems hold names, addresses, work histories, education histories, compensation details, work authorization information and sometimes accommodation or demographic data. NIST guidance on personally identifiable information includes employment information as linkable personal data that must be protected from inappropriate access, use and disclosure. Yet hiring platforms often receive less security scrutiny than systems holding customer or financial data.

That mismatch is dangerous: High-value data, public-facing workflows and increasing automation.

The 2025 McHire incident should have made this impossible to ignore. Researchers reported that weaknesses in McDonald’s AI hiring platform, including default credentials and an access-control flaw, exposed applicant data at large scale before the issue was patched. The lesson for CIOs is not merely that a weak password was used. The lesson is that AI hiring systems can ship with basic, preventable security failures while still being treated as HR tools rather than enterprise risk surfaces.

Vendor reputation does not transfer to every AI feature

One reason this risk slips through is that buyers often trust the platform brand. Mature vendors may have strong security programs, enterprise customers, compliance documentation and procurement-friendly answers.

But AI features can change the architecture of risk.

A platform that was safe as a workflow tool may behave very differently once it adds resume scoring, interview grading, chatbot screening or automated ranking. The new feature may introduce new inputs, new model behavior, new data flows, new third-party dependencies and new decision points. In practical terms, the attack surface has changed.

CIOs should not allow AI features to inherit trust automatically from the legacy platform around them. When a vendor adds AI, the enterprise should reassess the feature as if it were a new product. That does not mean slowing innovation for bureaucracy. It means AI-enabled decision-making carries different failure modes from ordinary workflow automation.

The ownership gap is the real vulnerability

The biggest risk may not be the model. It may be the ownership gap.

Talent acquisition may buy the tool. HR operations may configure it. The vendor may guide implementation. Procurement and legal may approve the contract. But who owns the security of the candidate-facing AI layer?

In many organizations, the honest answer is unclear.

That ambiguity is where risk grows. Recruiting technology sits at the intersection of public input, sensitive data, third-party software, automated decision support and brand trust. That is exactly the kind of environment that needs named security ownership, asset inventory, vendor review, access-control testing, logging and incident-response planning.

If the hiring stack is not in the security inventory, the organization is already making an assumption it may later regret.

What CIOs should require now

The fix is not exotic. It is applying existing security discipline to a surface that has been underestimated.

Treat every candidate submission as untrusted input. Resumes, cover letters, chatbot responses, interview transcripts and spoken answers should be handled as attacker-controllable content. If AI processes it, the system must separate content from instruction.

Reassess vendors when AI features are introduced. A prior security review should not be treated as permanent approval for new AI capabilities. Ask what changed in the architecture, what data the model sees, what actions it can influence and how manipulation attempts are detected.

Ask AI-specific questions before signing. Can candidate-provided content alter scoring? Are hidden instructions filtered or ignored? Is there human review before AI output influences a decision? Can the vendor produce testing evidence for prompt injection, access control and data exposure risks?

Assign ownership. HR can own the process, but security must own the risk model. AI hiring systems should be included in third-party risk management, application security reviews, access governance, monitoring and incident response planning.

Measure business impact, not just AI adoption. The goal is not to say the recruiting function uses AI. The goal is to improve hiring speed, quality, fairness and cost without creating new risk. If the system cannot protect decision integrity, the business case is weaker than it appears.

The hiring platform is now part of the enterprise attack surface

AI has turned the careers page into more than a front door for applicants. It is now a public input channel feeding systems that store sensitive data and influence workforce decisions.

That makes it a CIO concern.

The next failure in AI hiring may not look like a traditional breach at first. It may look like bad rankings, manipulated scores, unexplainable decisions, wasted recruiter time or a candidate process no one trusts. But underneath those symptoms is a familiar security problem: A system trusted input it should have treated as hostile.

Enterprises have hardened payment systems, customer portals, APIs and employee applications around that lesson. Hiring deserves the same treatment.

AI hiring is not just an HR transformation. It is a security boundary. And it is time CIOs treated it like one.

Two years ago, I sat across from a chief financial officer who had just spent forty minutes on a video call authorizing what he believed was a legitimate acquisition payment. The call included his CEO and two board members, all speaking in familiar voices, all making the kind of small unscripted comments that make a meeting feel real. None of them were real. The audio had been cloned from earnings call recordings, and the video was built from conference footage pulled off YouTube.

What gave it away wasn’t a glitch or a blurred hand. It was a pause. The CFO asked about a side conversation from the previous week that only the real CEO would have known, and the voice on the other end hesitated half a second too long before answering. That hesitation stopped a seven-figure transfer.

It also taught me something I have carried into every engagement since. Executive impersonation has moved from a theoretical AI risk category into an active enterprise security problem, and detection and response capability lags materially behind attacker capability.

The detection tooling gap

When clients ask me what to buy first, I tell them to slow down. The tooling landscape for synthetic media is real, but it is not mature, and treating it as solved creates false confidence at exactly the moment confidence gets tested.

Audio and video forensics tools scan a file after the fact for artifacts synthetic generation tends to leave behind. They are genuinely useful in a post-incident review, where there is time to run deeper analysis. They are far less useful in the middle of a live call, where a decision has to get made in seconds rather than hours.

Liveness detection tries to solve that timing problem by checking for signs of life during the interaction itself, rather than analyzing a file afterward. The trouble is that these systems were mostly built for identity verification at onboarding, a single controlled check at a fixed point in time. Retrofitting them into an unplanned executive call is still mostly aspirational, and most vendors will tell you the same thing privately even while marketing otherwise.

The MITRE ATLAS knowledge base, which catalogs real-world adversarial attacks against AI systems, now documents deepfake-based identity verification bypass as an established attack pattern rather than an edge case. That matters for CISOs because it confirms this is not a hypothetical gap security vendors invented to sell tools. It is a documented technique with case studies attached.

What senior executives specifically need, and what the market still doesn’t reliably offer, is verification that works in the moment a request is made rather than after the fact. Until that exists at scale, the tooling has to sit inside a broader protocol rather than stand in for one.

A framework enterprise teams can deploy now

Tooling alone will not close this gap, so the operational framework matters more than any single product. Here is what I put in place with clients, organized around five actions.

1. Verify. Multi-factor human verification for executive-level communications means more than a callback. It means a pre-agreed authentication phrase for the small circle of people who can approve high-sensitivity or high-value actions, changed on a schedule and never guessable from a public LinkedIn bio. It means out-of-band confirmation as a hard requirement, not a courtesy, for any request involving money, credentials or a change to standing instructions. I watched this stop an attack outright. A caller using a cloned voice of an executive asked a colleague for help with a confidential wire. The colleague asked for the agreed phrase, and the line went dead within seconds.
2. Detect. This is not about buying a detection tool. It is about continuously monitoring the executive’s digital identity surface before an attacker even builds the deepfake. That includes tracking domain squatting on the executive’s name, watching for social profile impersonation, and knowing where voice samples are already sitting in public conference recordings and podcast appearances that an attacker could pull from tomorrow. Most security teams monitor the network. Very few monitor the raw material an attacker needs to build a convincing fake in the first place.
3. Respond. When an impersonation attempt is identified or succeeds, the response playbook needs to specify who freezes a transaction, who pulls the call recording before it disappears, and who brings in forensics immediately so there is a documented basis for every decision that follows. It needs a defined escalation path that does not depend on the target believing something is wrong, because most executives will not report a strange call themselves. Build the reporting habit around the transaction, not the suspicion.
4. Train. Executive protection training has to include impersonation awareness now, and not just for the executive. Assistants, chiefs of staff and family office contacts are frequently the actual point of contact an attacker targets, since they often have more standing authority to approve something quickly than the executive expects them to use. This has to be a working habit, not a slide deck people sit through once a year.
5. Integrate. Executive impersonation cannot sit inside a single team’s silo. It needs coordination between security operations, communications, legal and executive protection, because a voice clone built from a podcast appearance does not touch a single system any one of those functions monitors on its own. A CSO Online feature on deepfake defense documented an almost identical wire fraud case and reached a similar conclusion that the organizations recovering fastest were the ones that had already rehearsed the coordination across teams before an incident forced it.

Where the market hasn’t caught up

Even programs built around all five of those actions still run into gaps that no enterprise has fully closed.

The first is the personal exposure gap. Most protocols assume the target is inside a corporate communication channel. Attackers are increasingly working the other direction, reaching family members or personal devices where none of the corporate verification steps apply at all.

The second is the public-facing gap. Livestreams of major corporate events have been hijacked by deepfakes of the company’s own executives, often promoting cryptocurrency scams, with fake feeds sometimes drawing sizeable audiences before takedown. That is not an internal fraud scenario a SOC playbook was built for. It is a brand and platform-level impersonation that needed coordination with a video platform in real time, and almost nobody has that relationship pre-built. The security team needing to reach a platform’s off-hours trust and safety escalation path in the middle of a live event is functionally starting from zero every time, and the incident is often over by the time the right internal owner on the platform side is even identified.

The third is measurement. Very few security teams can currently tell their board how prepared they actually are for this category of risk, because the tabletop exercises that would surface the gaps are still rare. Boards are starting to ask the question anyway, often after reading about another company’s incident rather than their own, and a security leader without a rehearsed answer is at a real disadvantage in that conversation.

Back to that CFO on the video call. What saved him was not a tool. It was a habit, built well before the attack, of treating a hesitation as reason enough to stop. That is still the most reliable control available, and it will remain the most reliable control until the rest of this framework catches up to it.

Traditional operating systems (OS) were built to manage hardware, files, apps, and users on a device, but Cloudflare says the agentic AI era requires a whole new format.

The company this week announced Cloudflare OS, which connects AI agents, enterprise data and context, internal systems, and workflows together in one secure workspace. It is open source and browser-based, sparing companies the need to build all-new infrastructure.

The OS is launching alongside several other new security, identity, spending, and user insight tools that Cloudflare has built for the AI-based workplace.

“Cloudflare OS isn’t a traditional desktop OS,” said Rita Kozlov, VP of product at Cloudflare. “It reimagines the workplace computing environment for AI.”

Open source OS runs in a browser

Cloudflare OS serves as a secure, AI-equipped workspace that is plugged into internal company systems. Available now through Cloudflare’s open source repository, it is accessible directly in a browser, and runs inside an enterprise’s Cloudflare account.

“It is a browser-based workspace that begins with a conversation,” Kozlov explained. Users can ask an agent to research, create slides, spreadsheets, and documents, build full-stack apps, or automate workflows without the need for a terminal. Those outputs are then shareable, but kept in isolated databases with access controls.

Enterprises will soon be able to access the OS directly through Cloudflare or via a “select group” of partners that will build tailored offerings on Cloudflare’s architecture, the company says. Because it is open source, organizational processes, internal system connections, and context aren’t locked into a vendor product or AI model provider. Customers can use whatever models they choose.

Cloudflare OS is built on Cloudflare Workers, Dynamic Workers, Durable Objects, and Access, the company’s zero trust network access (ZTNA) tool that verifies every user and request. Agents start with zero permissions by default and are only granted access to tools required for a specific task. Organizations configure their own Access policies, models, branding, skills, and integrations, Kozlov explained.

Governed connectors known as gatekeepers give admins control over what AI can see, what it can change, and when the system needs human sign-off. They can also control budgets, set rate limits, and delegate tasks to different models.

“Because agents act on people’s behalf and produce work others can access and modify, they require a new security model,” Kozlov said. Thus, Cloudflare OS tracks the resources an agent requires so the right access controls follow its work when it is shared.

Cloudflare initially built the OS for internal use, and employees “across every team” use it daily. Kozlov estimated that, over the last 30 days, internal users have used it to create more than 4,000 apps, automations, and tools. Over that same period, she claimed, the company’s sales team saved an estimated 10,000 hours by automating previously manual tasks like territory planning and proposal creation.

“We open sourced Cloudflare OS so any organization can build ‘Your Company OS,’” Kozlov said. Open source is critical because “you cannot put your company into software you do not own. Organizations need to be able to inspect the platform, customize it, connect their own systems, and make it their own,” she explained.

A more cohesive bundle

Cloudflare deserves credit for packaging Cloudflare OS as an operating system, noted tech analyst Carmi Levy.

“This very much is not Windows, macOS, or Linux, and it isn’t an operating system by its common definition,” he said. “But Cloudflare’s use of this terminology implies familiarity to enterprise IT buyers.”

This makes for an easier discussion as enterprises struggle to understand how to best incorporate AI-related platforms and workflows into infrastructure that wasn’t initially designed for it.

Microsoft has marketed the combination of its Azure, Entra, Fabric, Windows, and Microsoft 365 offerings as an operating system of sorts, but hasn’t pulled all the pieces into a common brand, Levy said. And Google’s Gemini, Workspace, Vertex AI, and Cloud Run are “circling similar territory.”

But, he noted, Cloudflare OS is “more cohesively bundled” and infrastructure-focused, offering a single pane of glass platform for buyers worried about stitching together otherwise disparate AI-aware networking pieces. The company recognizes that AI introduces new architectural realities such as inference and model routing “over and above” traditional OS core competencies.

“While competing offerings generally leave the infrastructure heavy lifting to enterprise decision-makers, Cloudflare is marketing itself as a single-source vendor, which potentially frees IT planners from having to integrate all the AI pieces on their own,” Levy said.

An infrastructure-first, application-agnostic approach means Cloudflare OS can coexist with whatever AI applications already exist in an enterprise, he said. It will “play nice” with OpenAI, Anthropic, Google, Microsoft, Meta, or open source layers, allowing employees to begin working in familiar workflows after sign-in.

“Its open-source architecture also minimizes the potential for vendor lock-in as enterprises gradually figure out how to evolve their stacks to align with new AI-era realities,” Levy said.

Managing identities and budgets for both humans and AI

As AI agents emerge across the enterprise, tracking their use can be challenging, causing problems from both a security and a spend standpoint. Along with Cloudflare OS, the company has launched a way to address this issue with its new Identity-Aware AI Gateway, now in beta.

Also integrated with Access, the offering gives admins visibility into what users (both human and AI) are requesting from AI models. It allows security teams to set up custom domains in front of their gateways and replace shared API keys by integrating with their identity provider, like Okta or Entra, and ZTNA infrastructure, Cloudflare explained.

Every request is tied to Access-verified identities, and enterprises can filter each user’s logs, analytics, and spend. IT teams can track redundancies, limit usage rates, and apply filters that strip out employee names, passwords, and other sensitive data before requests go to outside model providers.

A companion feature, AI Spend, tracks every user’s behavior over time to create a baseline of normal AI usage. When spending deviates from that pattern, the system alerts the IT team.

A new tab, User Insights, tracks cost and identifies over-spend caused by activities such as low cache-hit rates or oversized context windows. The capability scores sessions and compares them against account history using a 95th percentile session cost over the previous 30 days, Cloudflare product managers Ming Lu, Kenny Johnson, and Ayush Kumar explain in a blog post. Anything above 2x an account’s 95th percentile is a “strong candidate for anomalous behavior.”

For instance, one Cloudflare customer had an employee who left a rogue AI session running, generating a $30K bill. “User Insights helped them identify the problem and shut off access before the problem was further exacerbated,” Kozlov said.

Cloudflare is also building prompt classification functionality that sorts requests into categories such as coding or writing. This can help enterprises understand what AI is being used for.

“Once business traffic is separated from everything else, personal use becomes visible,” the project managers explained. “From the outside, someone running a side hustle on company time and someone quietly moving data out through a model look the same. Telling them apart is central to catching insider risk.”

Looking at the bigger picture

Identity-Aware AI Gateway and AI Spend address the visibility problem that has dogged so many recent AI deployments where enterprises failed to monitor usage, Levy noted. Projects “crashed and burned” as users unwittingly blew through token allocations.

These platforms provide single-point visibility into what is being used, how it’s being used, and where the potential lies for raising the productivity bar, he said. They overlay with existing models; in doing so, they enhance security with more precise control over resource allocations, and via automated anonymization protocols that prevent inadvertent sharing of sensitive data.

Ultimately, he said, vendors who free IT from having to independently assemble the pieces of their own AI implementations, and who assist them with answers to AI-specific questions, “will gain advantage over vendors that aren’t looking at the bigger picture.

The next big AI wave won’t be a chatbot in your laptop, or an agent that works behind the scenes to turn meeting notes into project tickets, but AI that takes control of devices that move and interact with the environment.

Physical AI can be defined as the integration of AI into autonomous systems, allowing them to perceive the environment around them and perform complex actions in the physical world. The physical AI market, currently valued at about $92 billion, is projected by PwC to surpass $489 billion by 2030.

For many people, physical AI may conjure images of robots building widgets on a factory floor, or a self-driving car. Both examples are among the top use cases for physical AI, but physical AI is also being integrated into security cameras, traffic lights, inspection robots, medical devices, and more.

What makes a strong use case for physical AI

IT leaders thinking about how to use physical AI should think beyond the human-shaped robots that generate a lot of attention, says Adnan Masood, chief AI architect at digital transformation provider UST.

“I usually have one caution for CIOs — skip the humanoid theater,” he says. “The near-term advantage is adaptive automation in variable environments where conditions change, humans share the space, and downtime is expensive.”

The sweet spot for physical AI is when it can run safely and repeatedly and can be audited within existing safety and compliance regimes, he adds.

For physical AI to make a big impact, a handful of conditions must exist, adds Vikram Venkat, investor in physical AI systems at Cota Capital.

First, there should be a major labor component, such as existing or expected labor shortages or conditions that make the work dangerous for humans, he says. In addition, the environment should be relatively constrained, because physical AI platforms generally aren’t yet proficient at handling highly variable environments.

Finally, the task should be repeatable, often at high volumes, and have clear measurable outcomes, he adds.

In the short term, a couple of other conditions should exist, Venkat says. First, deployments should be simple, and require minimal changes to existing processes, additional infrastructure, or integrations into existing systems. Second, humans in the loop should be able to correct errors.

Top use cases for physical AI

Despite those constraints, physical AI’s potential is huge, says Albert Liu, founder and CEO of edge AI solutions vendor Kneron.

“Most people think physical AI begins with robots, which is simply the example our minds go to since it has been the most visible until now,” he notes. “But physical AI isn’t just about the typical answer — machines that move — it’s about environments that become intelligent.”

With several caveats in mind, here are seven promising uses for physical AI systems.

Manufacturing robots

When thinking about physical AI, many people may envision robots manufacturing cars or other products. That’s certainly happening, with several vendors offering builder robots for sale, and with the industrial robotics market valued at $54.3 billion in 2026, growing to $94.4 billion by 2031, according to Mordor Intelligence.

One example of robots building products comes from car maker BMW, which has used a humanoid robot to weld parts together at a plant in the US.

Quality inspection and predictive maintenance

Physical AI deployed inside manufacturing environments isn’t just being used to assemble products. The technology is also being used for material handling and automated quality inspection and defect checking, with labor shortages and constrained environments driving use, notes Venkat.

Predictive maintenance is also a sweet spot for physical AI in manufacturing. AI can be used to check that the software powering equipment is working correctly, says UST’s Masood.

“Agentic pipelines now read hardware schematics and chip pinouts natively, generate the regression suites engineers once scripted by hand, and compare live equipment telemetry against digital twins to catch firmware regressions and signal-integrity faults before a production run,” he says.

Boston Dynamics’ four-legged Spot is an example of a marriage between robotics and AI, with the company saying thousands of robots have been deployed across 40 countries at companies such as Intel, Chevron, Michelin, and Cargill. Spot is used to automate industrial inspections, conduct predictive maintenance, and go on security patrols.

Boston Dynamics also sells Stretch, which automates the unloading of trailers and containers, and Atlas, a humanoid robot that can lift, sort, and assemble products.

Physical AI embedded into cameras and sensors can provide quality control inspections on factory floors, notes Parm Sandhu, group vice president for enterprise AI, edge computing, and digital innovation at IT solutions provider NTT DATA.

“They want to make sure the products built right the first time,” he says. “We use a foundation model, set up with cameras and trained in self-learning, so it very can very quickly learn standard operating procedure for one factory station.”

Autonomous vehicles and drones

The promise of self-driving cars entered the public consciousness several years ago, and the market, separate from the physical AI market, was worth more than $200 billion in 2025, according to Global Market Insights.

Autonomous taxis are also gaining momentum, with Waymo and Tesla launching robotaxi experiments in limited areas in 2025. Uber also has huge plans for robotaxis.

But the autonomous vehicle market extends far beyond cars driving down the highway. Autonomous farm equipment, including tractors, harvesters, and drones, represent a growing market, with market size estimates varying wildly. Global Market Insights estimated the market to be worth $70.9 billion in 2025, with projections for it to reach $144.7 billion by 2035.

Drones can also be operated by an AI, leading to all kinds of applications, including military uses and food and package delivery services. Amazon and other companies have experimented with drone delivery services in recent years, and DoorDash announced in late July that it would jump into the market.

One use that staddles the autonomous vehicle and manufacturing use cases involves self-driving forklifts. NTT DATA has worked with forklift manufacturer Hyster-Yale to install self-driving capabilities into the vehicles, in part a response to labor shortages, Sandhu says.

“If you think about manufacturing, pretty much everything you touch in that world was lifted by a forklift somewhere or components were lifted by a forklift somewhere,” he says. “But people don’t want to drive forklifts, and that’s a huge problem.”

Fleet and warehouse coordination

Physical AI, built into trucks and smart shelves, can track and better coordinate the movement of materials and products, from the warehouse to the end customer. Physical AI, installed in robots, can pick, sort, and transport goods. AI can use fleet telemetry to optimize routes in the shipping fleet.

AI models can now orchestrate thousands of autonomous mobile robots across fulfillment networks, what UST’s Masood calls “air traffic control for robots.”

The AI intelligence sits in the coordination layer that routes, sequences, and removes conflicts in the fleet, he adds. “It scales in ways single-robot programming never could,” notes.

Physical AI has moved beyond pilots and is operating at enterprise scale in warehouses, according to Symbotic, a warehouse physical AI vendor.

The company’s fleet of 22,000 autonomous mobile robots that traveled more than 200 million miles in 2025, with one robot traveling more than 52,000 miles, or more than twice the distance around the Earth, the company says.

Surveillance and physical security

Physical AI’s application to physical security includes roving robots like Boston Dynamics’ Spot, but it also allows organizations to connect video cameras and other security tools to provide an ever-vigilant view of the secured environment.

Companies such as Artificial Intelligence Technologies Solutions and its subsidiary Robotic Assistance Devices are connecting several devices for a sort of security mesh across a campus or building. The companies’ Speaking Autonomous Responsive Agent (SARA) is an agentic AI platform designed to coordinate cameras, fixed security devices, autonomous patrol vehicles, lights, speakers, monitoring systems, and human security personnel.

SARA can evaluate events from physical security systems, verify security events, communicate directly with people at the site, and initiate approved responses, the companies say. The automated response can save valuable time compared to human intervention, they claim.

Another example of the use of physical AI for security involves smart metal detectors with AI embedded inside. Athena Security is one company that offers AI-powered body scanners that claim a high rate of detection for all kinds of weapons, including razor blades and small knives.

Smart buildings and infrastructure

Companies can use physical AI to monitor all kinds of metrics inside buildings and across utility grids and telecom networks, notes UST’s Masood. The AI can trigger alerts, safety interventions, or environmental controls. Hospitals are now using physical AI to coordinate care, and network operators are deploying AI-powered self-healing tools.

Physical AI will create intelligent concierges at hotels, airports, and hospitals that provide directions, verify identities, and coordinate services, Kneron’s Liu says.

Over the next decade, AI will be embedded in nearly all physical spaces, including drive-thru lanes, restaurants, factories, and offices, he predicts. “People will expect a security camera that understands intent instead of simply detecting motion, a hospital room that recognizes subtle changes in a patient’s condition before an alarm sounds, a retail shelf that manages inventory autonomously, or a building that continuously optimizes energy, security, and occupancy,” he adds.

Smart cities

Outside of traditional enterprise environments, cities are now embedding AI into traffic devices to monitor vehicle flow and into cameras to monitor community service needs.

The AI-powered systems can improve traffic flow, monitor intersections, and make roadways safer without relying only on human observation. Lidar maker Ouster worked with the New Jersey Department of Transportation to install sensors at 42 intersections ahead of the World Cup tournament to assist with road and pedestrian traffic congestion, the company says.

NTT DATA is working with Brownville, Texas, to set up a citywide alert system to send workers for incidents such as when a park’s garbage containers are full and to assist police officers in filling out reports, notes Sandhu.

The mainframe remains the system of record for many of the world’s largest organizations and some of their most critical data. As of 2025, 71% of Fortune 500 companies still use mainframes, and nearly 97% of banks worldwide rely on IBM mainframe products.

Yet many security programs continue to treat the mainframe differently from the rest of the enterprise. Many organizations still assume the mainframe is inherently secure.

Mainframes are designed with strong security controls. But strong controls alone are not enough. Like any critical enterprise system, the mainframe requires continuous verification to ensure those controls are working as intended.

Risk can exist anywhere. An overlooked configuration in a z/OS environment can create opportunities for unauthorized access to sensitive systems and data. As the time between vulnerability discovery and exploitation continues to shrink, organizations need greater visibility into risk across the enterprise—including the mainframe.

Myth #1: Mainframes are unbreachable 

Can mainframes be breached? Although mainframes are designed with robust security features, no technology platform is immune to risk. The reality is simple: attackers go where the valuable data is stored.

The mainframe isn’t isolated from the rest of the enterprise. Mainframes routinely process millions of transactions per day, and high-end systems can process over a million transactions per second in certain workloads. Mainframes are estimated to handle a substantial share of the world’s transactional workloads and credit card processing.

As organizations modernize and connect systems across environments, visibility into potential exposure becomes just as important on z/OS as it is everywhere else. Attackers follow opportunity. Wherever valuable data and business-critical assets reside, flaws will attract attention. As organizations adopt hybrid architectures, the number of interconnected systems continues to grow, making identity governance and access assurance increasingly important.

The solution is to treat the mainframe as part of the enterprise attack surface and manage risk there the same way you do everywhere else. Mainframe security requires the same continuous visibility organizations expect across the rest of the enterprise.

Myth #2: Specialized systems are too complex for attackers

How is AI changing vulnerability discovery? In the past, surfacing exposures on the mainframe required deep expertise that relatively few people had. That complexity made these environments harder to analyze.

Recent attention around Mythos, Anthropic’s highly restricted security research model, has sparked debate about AI’s role in cybersecurity. If security flaws become dramatically easier to find, organizations may have less time to identify and remediate weaknesses before others discover them.

The important point isn’t Mythos itself. It’s that identifying exploitable weaknesses is becoming faster, cheaper, and easier.

Organizations can no longer assume that complexity will keep attackers at bay. Mainframe security strategies should account for a future in which gaps are discovered faster than ever before.

That requires greater visibility into the z/OS environment and the risks it may pose. Continuous analysis helps organizations uncover potential weaknesses early, and the sooner security teams can detect security gaps, the more time they have to fix them.

Myth #3: Annual security assessments are sufficient

Why is continuous vulnerability analysis important for mainframe security? Many organizations still rely on periodic configuration assessments, even though today’s threats move much faster than they did when those processes were created. Today’s mainframe environments are constantly evolving, and new weaknesses can emerge between checkpoints long before the next scheduled assessment.

Security teams need ongoing visibility into risk, not occasional snapshots. That’s why continuous vulnerability analysis has become a critical component of modern mainframe management, helping teams identify and remediate weaknesses before they escalate into incidents.

Organizations have long benefited from the security architecture and integrity of mainframe environments. As vulnerability discovery becomes more efficient, maintaining visibility into those environments becomes increasingly important. Rocket Mainframe Security solutions help organizations build continuous visibility across their z/OS environments and act on it early.

For organizations seeking greater visibility across their z/OS environment, Rocket z/Assure Vulnerability Analysis Program (VAP) helps identify weaknesses within authorized programs and supports ongoing remediation efforts. VAP helps security teams identify security gaps in software earlier, reducing risk before they affect critical systems.

What continuous mainframe security requires

• Visibility into sensitivities across the z/OS environment
• Ongoing validation of security controls
• Integration with enterprise risk management processes
• Faster identification and remediation of emerging weaknesses
• Continuous assessment rather than periodic review

The future of mainframe security requires continuous vulnerability analysis

Security weaknesses can exist anywhere in the enterprise, and they are being discovered faster than ever before. Detecting risk is getting easier, and organizations should plan accordingly.

This is where continuous vulnerability analysis becomes essential. Point-in-time assessments provide a snapshot of risk, while continuous risk analysis helps organizations maintain visibility as systems change.

The broader lesson from advanced AI models like Mythos is that vulnerability discovery is accelerating. For organizations that depend on the mainframe, visibility becomes more important as the time between discovery and exploitation shrinks. Organizations that adopt continuous analysis across critical environments will be better positioned to identify and address risk before attackers do.

Learn more here.

The United States Senate Federal Credit Union (USSFCU) is a nonprofit financial cooperative that provides traditional retail banking services to entities within the US government, such as the Senate and the Supreme Court.At present, the credit union’s headcount stands at nearly 150 people, managing around $1.6 billion in assets.

A few years back, when it started to expand its use of technology, cybersecurity was a key focus area, but the financial institution faced two major challenges in boosting security as it scaled. The USSFCU was carrying significant technical debt, and there were holes in the organization’s defenses.

“We found gaps where we needed more systems, tools, and people, and then there were instances where we had technologies in place that weren’t being used effectively,” says Mark Fournier, CIO at the credit union. “We weren’t buying a bunch of shiny new things without thinking about it. We were actually quite prescriptive every year, performing a number of different exercises to identify our shortcomings and then finding the right solution to fill the gaps. But over time this adds up. It was clear we couldn’t keep hiring more people and bringing in new solutions.”

The USSFCU needed a more efficient way to bring everything together and make its cyber estate easier to manage. For Fournier and his team, vulnerability management was the hardest hill to climb since they have to deal with about 100 new possible breach points every day.

“When we looked at the problem more closely, the impact of these vulnerabilities was far greater than we realized,” he says. “Not only because of the volume but because of a lack of clear understanding around the potential impact of each one across the broader business.”

Improved risk management

The USSFCU didn’t lack security tools, however. In fact, it had plenty, from scanners and endpoint tools to asset records, tickets, and internal documentation. But each tool saw only a slice of the environment, so there was little to no context. This made it difficult for the security team to separate real business risk from noise.

So for each new vulnerability, the security team had to run a manual investigation, which could take days. And while doing this, they still had to triage the next wave of findings. The organization, therefore, needed a way to know what mattered, why it mattered, who owned it, and whether taking the time to make a fix actually reduced risk. The USSFCU also required a solution to be deployed entirely in-house, leveraging its internal inferences.

Working with Tonic Security, the organization deployed an exposure management solution that pulls together data from different tools and data sources to create a clear picture of business risk. “One of the key functions of the platform is the ability to ingest anything,” says Fournier. “Breaking down silos between disparate systems is essential to unlock valuable contextual information.”

For the USSFCU, transparency and explainability are critical, he adds. This tool uses an AI data fabric to extract context from structured and unstructured data. This context drives prioritization, ensuring the right owner gets the right evidence, not a vague ticket. And once the work is done, the solution checks whether the exposure was reduced.

Because the AI is grounded in the customer’s own environment, it isn’t just guessing from a generic risk model. It reasons over USSFCU’s assets, owners, services, tickets, controls, and business context. But it isn’t using this data to train external models.

Describing one particular incident, Fournier explains that shortly after the initial deployment, various stakeholders met to assess progress. “We thought we were smart because we found an error with the platform,” he says. “The solution had labelled an asset as internet exposed, which we knew was incorrect.” But after a review and lengthy discussion, they were proven wrong. “Almost immediately, the value of bringing this information together became apparent.”

A template for bigger things

Before this solution, a high-severity finding could send an analyst on a lengthy scavenger hunt because of data located in so many different places. They’d check the scanner, asset inventory, tickets, and maybe even ask around to find the owner. But now they can find the asset, the owner, the business relevance, the exposure path, and the recommended action in one place. The solution has reduced the time taken to resolve a vulnerability by 75%. And with a clearer idea of what is and isn’t important, and what adds practical value, the number of incidents someone needs to respond to has reduced from about 100 a month to just 10.

Sharing his lessons from the project, Fournier says one needs to keep an open mind because the problem you think you have is often very different from the one you actually have. “This project has also been an eye-opener around how people can collaborate and operate across different areas of the business,” he says. “When I talk to my peers, they regularly highlight the disconnect between different departments and business functions. But with a project like this, when you’re crossing traditional boundaries, you need to have open lines of communication to succeed.”