Jot 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.
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.
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?
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.
One thing they did was to embrace the demands while curating and steering the approach:
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.
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.
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:
We viewAI 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.
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:
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.
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 specific challenges brought by AI agents.
To ensure least privileges principle, they always start with no access:
[...] every agent and app starts with access to nothing. An agent can ask for access to a specific resource, which you can grant or deny. [...] Neither can reach the Internet except through capabilities you explicitly provide.
From this secure start, how do you make sure you only give what is needed and nothing more? First, you bound the permissions to what the user already has. In access control lingo, we call it access delegation or OBO (On-Behalf-Of) access: 5) You should never have more permission with systems of record when using AI.
[...] 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.
This works great for static content generation, but Cloudflare OS allows creating dynamic content like webapps. To address this, they make sure the underlying piece of code continues to leverage the current user's permission and not the original author's:
And if I deploy an agent and share it with someone, the access the agent provides to them should reflect their permissions, not mine. [...]
Following our rule around permissions, the access a user session has in Cloudflare OS is scoped to their existing permission set in a given system of record. [...]
When I share the agent I built with others, they authenticate the agent using their own permissions through the same gatekeepers, so we do not cross data boundaries.
With this design approach, the builders never need to request API keys as the building blocks adds an abstraction layer above it and leverages their own access instead.
Sometimes there are no easy way to apply this OBO approach directly with the source data, or maybe you want to cache results. How do you make sure the current user should be able to see what the agent or app shows? Cloudflare addresses it by an extra intermediary, the gatekeeper:
A Gatekeeper is a service-specific[Worker]that sits between Cloudflare OS and an external service.It understands the service’s API, its resources, and the operations that can be performed on them.[...]
Gatekeeper can give itaccess to a single repository, allow it to read issues but not source code, mask particular fields, apply rate limits, and require approval before merging a pull request.[...] The Gatekeeper handles[OAuth], holds the credential, enforces policy, records what was read, andmediates anything with an externally visible side effect. [...]
Cloudflare OS records every resource agents observe. These observations remain attached to the agent and its work.When another person tries to open the workspace, interact with the agent, or view what it produced, Gatekeepers verify that person's access to the observed resources. [...]
A read of sensitive data can prevent the agent from writing data to certain sources, inviting new collaborators, handing work to another agent, or making an outbound request.
In other words, gatekeeper “taints”, or “contaminate”, every output with the sensitivity and permission requests of the input it used to build it, making access control transitive. Think of it as a generic equivalent to your Mailbox app immediately tagging an email with the highest classification level of its attachments.
This is the most fascinating part, but also the one with the least explanation of how it technically works. It's still unclear to me whether this is a deterministic system, AI based, or a bit of both. It feels very similar to what Google is building with BeyondZero.
I'll conclude with a statement I love from their article, highlighting Cloudflare's philosophy regarding security controls:
People using agents or building apps do not have to worry about making these mistakes. The platform can now be used to handle this.
Don't rely your security posture on awareness and wise behaviour. Protect users from themselves by making it impossible by design to take the wrong decision. More on that in my article: Design your controls, so security awareness becomes irrelevant.