Cloudflare OS: Insights on embracing internal AI growth securely

As part of their newly created “Agent Week”, Cloudflare published interesting titbits about how they addressed the exploding demand for AI-assisted workloads internally, embracing innovation while keeping a proper security posture.<br>They released Cloudflare OS, a misleading name for what looks like an Open Source, Cowork-like ecosystem; also allowing to create workflows and full-stack apps. I've not digged into it in details as, while open to everyone, its architecture seems to heavily rely on Cloudflare products like Workers and Cloudflare Access. It's unlikely you can leverage it outside their ecosystem without some heavy customization. What is captivating is how they build the core principles to address common AI quality and security pitfalls. I'll use quotes from “How we’re rethinking work at Cloudflare with Cloudflare OS” and “Cloudflare OS: an open platform for agents, apps, and work” articles.<br>We can all relate to the shape internal demand took at Cloudflare. As AI is bridging the skill gap, especially to curate data and write code, you get swarms of users from non-tech departments starting to ask very specific (and dangerous) things like API keys and service accounts. How do you support them without destroying your security posture?<br>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. [...]

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.<br>One thing they did was to embrace the demands while curating and steering the approach:<br>If you give everyone a harness workspace that is great at writing code, you’ll wind up with way more code than you need. The result became a flood of vibe coded apps looking for a problem to solve. So we worked backwards.

We told everyone at Cloudflare that they could send the work they did not want to do to a “magic AI email bot” that would respond with the output they needed. Behind the scenes, a small team of people staffed this email alias using AI tools to do the work. [...]

Handing over API keys to people and agents is dangerous and does not scale. Keys often provide broad, long-lived access that is difficult to constrain, share safely, and audit.<br>This is a very clever, albeit time-consuming, way to collect business needs. They themselves call it “miserable”, but it allowed them to create a set of “skills” covering most end user requires they received.<br>They also made it clear from the start that “the human owns the output”, the ultimate responsibility lies in the end of the human sponsor. Similar to what Microsoft is trying to build within Agent365 identity governance:<br>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 .<br>This is easier said than done though. Even with good intention, you can't expect a non-technical employee to have the same insight and wisdom as your developers and system architects. How do you infuse the best practices across your organization? You ask the domain experts to define opinionated guidelines, they call it codex. Those guidelines are then enforces by gateways checking AI outputs among other security checks:<br>Anyone at Cloudflare could now write bad code, faster, thanks to AI. We needed better guardrails.

So we built a context layer for engineering. We call it the Cloudflare Engineering Codex. A Codex is an authoritative guide. Ours sets out the principles and practices we work by. Policies tell you what you can't do, whereas a Codex tells you what you should do . It is opinionated by design. Every part of our codebase has a domain owner accountable for what good looks like there. [...]

One agent reviews every Merge Request against Codex requirements. Another reviews technical designs before implementation starts. A third reviews incident reports.<br>The hardest part has yet to be discussed: Accesses and permissions. How do you protect from permission creep and unintended data leakage due to ill-engineered AI apps spawning all over the place? Cloudflare chose to rethink Zero Trust Principles and adapt them to the...