JPMorganChase's CISO is right: your apps shouldn't answer strangers

On Saturday, the chief information security officer of JPMorganChase posted a short note on X. It is worth reading twice.

Pat Opet

@patopet

if you’re working for a company in cybersecurity, you should be evaluating your options to abstract your companies services from the internet what i mean is: why allow an unauthenticated anonymous agent of an attacker to interact with your systems? consider your architectural levers now, you’re going to need them

November 7, 2026View on X

Pat Opet runs security at the largest bank in the United States, so this isn't a vendor pitch. It's an architectural instruction: stop letting strangers talk to your systems. Not "patch faster" or "buy another scanner", but make sure that most of what you run never answers an anonymous request in the first place.

We agree, and it's most of what we do for customers on Cloudflare One. Here is our reading of why the advice lands now, what it means in practice, and where to start.

Why now: attackers stopped being people

For most of the internet's history, the cost of an attack was human time. Someone had to find your login page, try a few things, read an error message and decide what to do next. That cost was a quiet layer of protection: most exposed systems were never looked at closely by anyone.

That layer is gone. In November 2025 Anthropic described a state-sponsored espionage campaign in which AI agents carried out 80 to 90% of the work against roughly thirty organisations, including financial institutions, with people stepping in at only a handful of decision points.¹ At its peak the agents made thousands of requests, often several a second. Tooling has only improved in the year since.

The consequence is simple. Every service that answers the internet is now examined by automation that doesn't get tired, doesn't get bored and reads every error message. An internal dashboard with a login form, a staging site, a forgotten admin panel or a VPN concentrator is no longer obscure. It's an endpoint in someone's queue.

Opet has made a related argument before. In his April 2025 open letter to JPMorganChase's suppliers, he warned that modern integrations erode the old boundary between a firm's trusted internal resources and the untrusted internet, and that AI agents amplify that risk.² The post on Saturday is the practical conclusion: if the boundary has worn thin, put it back, and put it in front of the application rather than around the network.

What "abstracting a service from the internet" means

A service is abstracted when it only answers requests that have already proved who is asking. Everyone else, human or agent, gets nothing from the application itself: no login form, no version string, no error page to learn from.

In practice that takes three pieces, and Cloudflare One provides all of them:

Put together, an anonymous scanner that finds your hostname sees a Cloudflare sign-in page and nothing behind it. It can't fingerprint the software, can't try passwords against the application and can't exploit a bug in a page it never receives. A staff member signs in once with single sign-on and works as usual, with no VPN client to start.

This is also how you shrink the blast radius of a stolen password. Access can require a managed, healthy device as well as a valid identity, so a phished credential used from an attacker's laptop doesn't open the door on its own.

Which levers to pull first

You don't have to move everything at once, and you shouldn't. This is the order we follow with customers, because each step removes the most exposure for the least disruption:

1. 1

   Find what answers today. List every hostname, IP and port your organisation exposes, including the ones nobody owns any more. External attack surface scans usually turn up a few surprises.

2. 2

   Put Access in front of admin panels and internal tools. Dashboards, CI systems, wikis, ticketing, database consoles and anything with "admin" or "staging" in the name. These are the services attackers want most and the public needs least.

3. 3

   Close the inbound path. Once an app sits behind Access, connect its origin with Cloudflare Tunnel and remove the public IP or firewall rule. Until you do, someone who finds the origin directly can go round the identity check.

4. 4

   Give machines their own identities. Scripts, partners and other services use Access service tokens or mutual TLS, scoped to the one application they need, instead of shared passwords or IP allowlists.

5. 5

   Retire the VPN. Move the remaining private applications to Access and Tunnel, then switch off the concentrator, which is itself one of the most targeted devices on the internet.

6. 6

   Put staff traffic through Gateway. DNS and HTTP filtering blocks known malicious and newly registered domains, and data loss prevention rules stop sensitive files leaving through unapproved apps.

Every step needs a test that intended access still works and a rollback if it doesn't. The policies are the easy part. The work is in knowing which users, groups and devices should reach each app, and keeping that true as people join, move and leave.

What stays on the internet

Some services exist to answer strangers: your website, your checkout, your customer API, your status page. These can't sit behind a sign-in, so the same principle applies differently. Anonymous traffic should meet a WAF, bot management and rate limiting at the edge before it touches your servers, and the origin behind them should still have no direct public path.

The aim is that the only things answering anonymous requests are the ones you chose, and that each of them is defended for it.

How we run it

Opet's last line is the one we'd underline: consider your architectural levers now, because you're going to need them. A lever you haven't installed can't be pulled during an incident.

Vigilbase sells the Cloudflare Enterprise licence, deploys Cloudflare One (Access, Gateway, Tunnel and device posture) and runs it for you as part of Managed Cloudflare. In practice that means:

• Design before rollout. We inventory the applications, identities and devices in scope, agree who should reach what, and connect your identity provider with the group claims and MFA policy you need.
• Cutovers you can undo. Each application moves with access tests and a rollback path, so a policy mistake locks no one out for long.
• Policies under change control. Every change to an access rule, Gateway policy or service token has an owner, a reviewer and a record, and our SLA tiers set how fast we respond.
• Upkeep that doesn't drift. Joiners, movers, leavers, new apps and new contractors are handled as routine requests, and access that nobody uses any more is reviewed and removed.

Vigilbase is ISO 27001 and SOC 2 Type 2 compliant and a Preferred Cloudflare Partner, with follow-the-sun support from teams in Kenya, South Africa, the UAE and Portugal.

If you aren't sure how much of your estate answers the internet today, that's the first question we'll answer together.