JPMorgan Chase warns that AI is outrunning enterprise defenses, and the problem is bigger than cybersecurity

When JPMorgan Chase’s global technology leadership team published “200 days into the frontier: What we know and what to do now” on November 2, 2026, it skipped the usual conversation about AI adoption, productivity and innovation. JPMorgan Chase asks what happens when increasingly capable AI systems change the speed, scale and complexity of enterprise threats. Its central argument is that AI is changing the economics and speed of cyberattacks faster than enterprises are improving their ability to defend themselves.

The bank’s framing is deliberately wider than security. It treats the challenge as a question of technology risk, enterprise resilience, infrastructure dependency and corporate governance, which makes it a message for CEOs and boards as much as for CIOs, CISOs and CTOs. The core warning is that vulnerability discovery and attack automation are accelerating while remediation is not keeping pace.

Four shifts reshaping the threat landscape
JpMorgan Chase identifies four forces behind that gap. The first is speed: AI is compressing the time it takes to find vulnerabilities and automate attacks, so enterprises can no longer assume that traditional patching and response timelines will hold. The second is autonomy. AI agents are moving beyond answering questions to accessing enterprise systems, retrieving information and executing tasks, and their capabilities can exceed the authority and controls assigned to them.

The third is scale. A flaw in a widely deployed technology can force urgent remediation across an entire enterprise, and risks that once looked manageable can become material very quickly. The fourth is dependency. AI growth deepens reliance on semiconductors, data centres, telecommunications, water and electricity, which means digital resilience can no longer be separated from the resilience of physical infrastructure.

Technology debt is now a security liability
JPMorgan Chase’s sharpest claim is that technology which still works is not necessarily technology that is safe. It points to unsupported operating systems and programming platforms, outdated open-source libraries, legacy applications that no longer receive patches, ageing network and computing hardware, and internet-facing systems running old software. Its example is PHP, where security fixes for serious vulnerabilities were available only for the current version, leaving organisations on older versions to upgrade or remove the dependency.

The practical advice starts with a complete inventory of hardware and software. Each asset should be judged on exposure, meaning whether it can be reached from the internet, on protection, meaning whether it can still receive timely fixes, and on impact, meaning whether its compromise could disrupt customers or critical operations. Any exception to an upgrade should come with an accountable owner, funding, compensating controls and a dated exit plan. In other words, technology debt is no longer just an IT modernisation problem. It is a business risk.

Rebuilding the perimeter
The bank also separates patching vulnerabilities from reducing the exposure that makes them exploitable. Firewalls, VPN gateways and remote-access tools remain attractive targets precisely because they face the internet, and JPMorgan Chase cites recent Citrix vulnerabilities as an illustration. Its answer is an independent layer in front of sensitive systems that screens out known attacks and malicious traffic, verifies users through multifactor authentication, and authorises only approved individuals, with the underlying system never directly reachable from the internet. There is a caveat that CIOs will recognise. That protective layer needs its own redundancy and tested fallback arrangements, or it simply becomes the next single point of failure.

Capability is not authority
The most forward-looking section concerns AI agents. As they begin to interact with enterprise applications, access organisational information and execute business tasks with limited human intervention, JPMorgan Chase draws a firm line: what an agent is able to do should not automatically determine what it is allowed to do. An agent might technically be capable of moving money, changing production systems or contacting customers without being permitted to do any of it.

JPMorgan Chase recommends four safeguards. Agents should receive only the access their task requires, each should carry an identifiable identity, their activity should be monitored in real time with audit trails retained, and the enterprise should be able to restrict or stop an agent quickly. Oversight should scale with consequences, so a reversible, low-impact task does not need the same approval as a financial transaction or a production change. For enterprises, this points to identity and access management stretching to cover non-human identities, autonomous agents and machine-to-machine interactions, and to agent governance emerging as a discipline in its own right.

Deciding fast is not the same as acting fast
JPMorgan Chase turns on a distinction many organisations blur: decision speed versus execution speed. A company may approve an emergency fix within hours and still take days or weeks to deploy it, held back by incomplete asset inventories, layered approvals, limited testing capacity, complex environments, supplier dependence and difficulty coordinating change across business units. Faster sign-off alone does not produce faster remediation.

The remedy is to settle emergency authority in advance, so everyone knows who can approve urgent changes, when a service can be isolated and when a vulnerable service should come offline. Suppliers belong in incident-response planning too, because if a critical vendor cannot deliver a timely fix, the enterprise needs an alternative.

Resilience reaches the physical world
The final theme takes the discussion beyond conventional cybersecurity. A company can have excellent application security and a solid disaster recovery plan and still suffer a major outage if its data centre, power supply or telecom provider fails. AI intensifies that exposure through energy constraints, geopolitical disruption, supplier concentration and long hardware replacement lead times. JPMorgan Chase’s response is to identify critical dependencies, understand what losing each would mean, reduce concentration risk and arrange alternatives. It does not call for duplicating everything, and says redundancy spending should follow business impact, recovery objectives and the practicality of alternatives.

A framework for the boardroom
JPMorgan Chase distills its advice into three priorities for enterprise leaders. The first is to change assumptions: make technology currency non-negotiable, fortify internet-facing systems, build security into architecture and put hard boundaries around AI agents. The question it poses is which existing risk assumptions were designed for a technology environment that no longer exists.

The second is to shorten decision cycles by redesigning governance for speed, separating decision from execution, bringing suppliers into response readiness, reprioritising resources as risks change, and rehearsing executive decisions and not just technical responses. Here the question is what would stop the organisation from responding within hours if a critical vulnerability emerged tomorrow.

The third is to build resilience, linking digital growth to physical dependencies, removing single points of failure, treating resilience as an architectural requirement, demanding evidence rather than assurances, and testing continuity and recovery under realistic conditions. The question is what evidence shows that critical services can continue or recover when something fails. Organisations should hence learn from every failure and change the controls, architecture or decision-making that let it happen, which makes resilience a continuous process rather than a one-time project.

If AI shortens the window between a flaw being found and being exploited, the organisations best placed to cope will be the ones that already know what they own, have decided in advance who can act, and have given their AI agents limits that hold. For CIOs, the work starts with a plain audit of which of those three things is not yet true.