Sam Rhea is Cloudflare’s Chief Information Officer. I knew we had a problem about six months ago when a member of our sales organization reached out to me asking for API keys. Keys plural.
They used AI to build what they described as a SuperApp that would transform our go-to-market teams. All they needed was production access to about a dozen systems of record at Cloudflare and admin permissions to a deployment pipeline to make it work. We had taken a fairly cautious approach to rolling out AI at Cloudflare during 2025.
We deployed informational chat applications and tinkered with using AI to help write some boilerplate code, but we felt that the technology was not ready to change how we work. And then, over the course of a few days at the end of last year, better models and more powerful harnesses changed that calculus. AI agents could do things, and they could do them well.
Hundreds of team members across Cloudflare, in technical and non-technical roles, spent the quieter weeks around the New Year experimenting with new tools that made it easier than ever to build. That sales team member building their SuperApp was just the first in an avalanche of people raising their hands to use these tools to transform how they get things done.
We had an obligation to equip and enable them to do so. But we also had an obligation to keep our systems, internal data, and customer data safe. We have spent the last several months building a platform to do exactly that inside of Cloudflare.
We call it Cloudflare OS. We started by stitching together off-the-shelf components from our Developer and Zero Trust platforms like Cloudflare Workers and Access . As we learned more about the challenge, we also created custom services tailored to this new way of working.
As with many of Cloudflare’s products, we set out to solve a problem we had internally. As it turns out, many of you had the same problem. That’s why today we are excited to share Cloudflare OS, the sum of what we have launched internally to give our own team members the ability to safely and productively use AI and deploy agents.
You can read more about what is available right now in Phillip’s post here . In this post, I want to walk through our own internal journey that led to this release, both what has gone well and where we have fumbled. There are five sections: the principles we put in place to begin; how we piloted to figure out what the jobs were to be done; what we built for engineers, and for non-engineers; and how we created champions across the organization to help drive change.
During the last few months, I have felt like the luckiest CIO in the world as the team I support had access to these emerging technologies. Today’s goal is to share that platform and its lessons with every team. Set the ground rules We started by defining a set of principles around how this should work.
Cloudflare’s CTO and I sat down in our office in Austin, Texas, and began to sketch out what needed to be true in how we adopted AI. We invited leaders from across the organization to give us feedback on the draft. The result became the guidelines below.
- We use AI to spend more time with our customers and build technology to solve more of their problems. We do not want to use AI just for the sake of using AI. We push teams to start by defining their “jobs to be done” first, the pain points, bottlenecks, or missed opportunities that can improve how we serve our customers.
Then we find the right tool. 2) Everyone deserves superpowers. AI is very, very good at writing code.
By extension, the first wave of AI tools that could take actions consisted of interfaces that developers already used: command lines, code editors, terminals, Git repositories. These formats could leave behind large parts of our team. While we have a very technical and curious workforce, not every member of our team spends their day in developer tools.
And we do not think they need to! We want our employees to bring their subject matter expertise and we would provide them with an intuitive platform they could use to rethink how we do work. 3) The human owns the output.
We view AI as a tool and toolmaker, not a team member. We expect humans to take responsibility for defining the quality, testing, and workflows that rely on AI output. The rule extends to deploying agents, as well.
The users and teams that ship agents are responsible for the output of those agents. Someone leaves? Their manager inherits the responsibility of their agents in the same way they inherit their other workflows.
The context from the organization matters more than the model. The workflows and agents that we deploy at Cloudflare need to know about Cloudflare. The time we spent on the technology had to be paired with time invested in a curated, canonical context layer.
You should never have more permission with systems of record when using AI. Everyone at Cloudflare has a scoped view into the underlying data at Cloudflare for good reason. We use our own products to segment data access by factors ranging from device to role to region.
We also configure and monitor the controls inside our third party applications. Those controls need to apply when I manage an AI agent that interacts with the same data. I should never have “more” access to data when using an AI tool and my AI agents should only have access to exactly what they need, nothing more.
And if I deploy an agent and share it with someone, the access the agent provides to them should reflect their permissions, not mine. Meet your users where they are With those rules in place, we got to work. We ran two parallel programs: the first for our engineering teams, and the second for every other type of work.
Provide your engineers with guardrails AI tools took the work our engineers already did and made it faster — faster than our review process could keep up with. Anyone at Cloudflare could now write bad code, faster, thanks to AI. We needed better guardrails.
Originally published at blog.cloudflare.com
