For decades, security companies treated the Internet as something enterprises had to defend themselves from.

They protected infrastructure and applications by stacking boxes, appliances, gateways, and inspection tools around them.

The assumption was simple.

Build the infrastructure first.

Layer security on top of it after.

Traffic has to reach the edge of that infrastructure before anything even looks at it.

Which means the attacker is already close by the time anything gets stopped.

Cloudflare asked a different question: what if the Internet itself could be that security layer?

That question is the origin story.

And it is the reason the company matters more than ever.

The story starts in 2004 with Project Honey Pot.

The founders wanted to understand where email spam actually came from, so they built a way for website owners to plant traps for spammers and malicious bots. Over five years, thousands of websites across 185 countries joined.

The data grew quickly.

But customers kept asking for something more useful.

Do not just tell us where the bad traffic is coming from.

Stop it.

That is the turn in the story.

This did not begin as another security vendor trying to sell a better box.

It began with a different belief about where security should live.

Not layered on top of the infrastructure.

Not bolted onto the network.

Not after the threat has already reached the customer.

Security should live in the path of the interaction itself.

Roughly a quarter of the world’s Internet traffic runs through this network today. It’s built to sit within 50 milliseconds of nearly every connected person on Earth, running out of more than 337 cities in over 125 countries — with AI inference alone running from over 210 of those locations, offering access to more than 350 different models, and 80% of the top 50 generative AI companies use Cloudflare.

Which means wherever your users are, wherever your employees are, wherever your AI agents are operating, none of them are ever far from this network.

But the numbers are not the real story.

The architecture is.

Lee Holloway didn’t build just another standard proxy.

He built something else entirely: a global reverse proxy layer where the same software runs on every machine, in every location, at the same time.

The physical equipment was not exotic.

It was commodity x86 servers in colocation facilities around the world.

The radical part was what the software made possible.

Lee did not just write code that moves traffic from one place to another.

He wrote the code that lets a request get received, understood, and decided on — then blocked, challenged, routed, cached, accelerated, or passed safely through.

All inside the same flow of handling that request.

That is the important part.

A request does not need to bounce from one security tool to another, then to another routing layer, then to another performance product before a decision gets made.

It gets evaluated as it moves through the network path it is already taking.

The software looks at what the request is, where it came from, what it is trying to reach, whether it matches customer policy, whether it looks automated or malicious, whether it should be served from cache, and where it should go next.

That is what makes the architecture different.

The network is not just carrying traffic.

It is understanding traffic.

And because the same software runs everywhere, the same kind of decision can happen close to the user, close to the application, and before the request reaches the customer’s infrastructure.

For a customer, that is not a technical detail. That is the difference between managing five tools that each see part of the problem, and having one system that sees all of it, at the moment it matters.

That is why so many use cases can run from the same foundation.

Not because every product was bolted on later.

Because the original architecture already put this company in the right place: directly in the path of the interaction, with the ability to understand and act on a request before it reaches something important.

Once you understand that, the rest makes more sense.

Zero Trust makes sense because it already sits between users and applications.

API security makes sense because it already sits between API traffic and the services behind it.

Bot management makes sense because it sees automated traffic before it reaches the customer.

AI security makes sense because it sits in the path between agents, models, tools, APIs, and data.

This is why it can support so many use cases without feeling like a pile of separate products.

The original bet was never just to build a faster website service.

The bet was to put intelligence in the path of Internet traffic, make it fast enough that customers would actually use it, and make it global enough that location stopped being the limiting factor.

That is easy to say now.

It was brutally hard to build.

It required high-performance networking code so security would not slow everything down.

It required the ability to push policy changes across the world quickly.

It required keeping every location aligned.

It required making every location capable of handling every customer.

And it required walking away from the business model most networking companies were built on: selling expensive hardware appliances.

That conviction is exactly what a customer is buying into today — not just a product, but a company that bet its entire business on being architected right, instead of selling more boxes.

The bet was simple.

If you own the network path, you do not need to sell boxes.

That bet now matters more than ever.

Because the enterprise problem has changed.

For a long time, the question was:

How do we protect the application?

That question is no longer enough.

Now the question is:

How do we protect every interaction before it reaches something important?

That is the AI problem.

AI agents do not behave like traditional software.

Traditional software usually runs in known places, follows known workflows, and talks to known endpoints.

AI agents behave differently.

They make decisions.

They call APIs.

They retrieve data.

They use tools.

They talk to models.

They may trigger actions across applications.

They may interact with other agents.

That creates a very different security challenge.

It is not enough to ask whether an application is protected.

Enterprises now have to ask:

Who is making the request?

What are they asking for?

What data is involved?

What tool is being used?

What action is about to happen?

Should it be allowed?

Should it be blocked?

Should it be logged?

Should a human approve it first?

That is why this origin story matters.

AI does not need another security product sitting beside the action.

It needs control at the point of interaction.

That is what this architecture was built to do.

The punchline is not that a better security company got built.

The punchline is that the old security model got rejected entirely.

It did not assume the Internet was something to hide from.

It assumed the Internet itself could become the place where security, performance, routing, and application logic happen.

That is why the same architecture now applies to websites, applications, APIs, employees, bots, and AI agents.

This was not built for AI.

It was built for the world AI creates.