Cloudflare’s internal Cloudflare OS lets employees build and run AI agents with identity-aware permissions, execution sandboxes, and audit trails. The result is a blueprint for enterprises: deploy agents only when an operating layer—identity, policy, context, and runtime governance—sits between models and real systems.
Enterprises don’t lack models; they lack an operating layer that makes agents safe and useful at scale. Cloudflare’s internal platform, Cloudflare OS, was built because enthusiastic teams could suddenly automate work with agents—but doing so by handing out broad API keys was a non-starter. The OS sits between models and production systems, enforcing identity-aware permissions, scoped data access, execution sandboxes, and auditable actions. That shift moves the conversation from prompt engineering to operational design: who does the agent impersonate, which capabilities does it have, where can it run, and how are its decisions reviewed? With those questions answered, agents can meaningfully accelerate work without widening security exposure.
A telling proof point is Cloudflare’s Engineering Codex: an opinionated context layer that codifies what “good” looks like across domains. Agents use it to plan, review designs, and gate merges. The impact is measurable—thousands of blocked merges and early detection of architectural issues—because the OS doesn’t increase access; it applies existing Zero Trust rules and domain standards to every agent action. This is the key distinction from model-centric harnesses: an OS treats context, policy, and accountability as first-class citizens rather than bolt-ons. It converts ad hoc experiments into governed workflows with consistent behavior across teams and tools.
For decision-makers, Cloudflare OS offers a practical pattern for agent adoption. Before investing in more models, inventory the identity fabric, permissioning, context stores, execution environments, and evaluation loops that will constrain and shape agents. If these elements don’t exist, the right move is to build or buy that operating layer—not to scale pilots that quietly accumulate tech, data, and compliance debt. The payoff is speed with safety: faster reviews, reliable automation, and a clear chain of responsibility for every agent and action. In other words, production-grade agents are an IT capability, not a chatbot.
What Cloudflare Actually Shipped
Cloudflare OS isn’t a single tool; it’s a stitched platform that aligns developer tooling, Zero Trust controls, and custom services into a coherent agent runtime. Employees can create agents, grant them narrow capabilities, and run them inside sandboxed environments with pervasive logging. The OS foregrounds identity and permissions, routes context from canonical sources, and enforces ownership: humans remain accountable for agent output, and managers inherit that responsibility when team members depart.
This approach recognizes agents as software actors subject to the same governance as services. Outcomes speak: review agents have flagged large volumes of issues before code lands; design-review agents catch architectural drift early; and operational visibility lets security and platform teams see exactly which agent did what, when, and under which identity constraints.
The Missing Layer: Identity, Policy, and Execution
A durable operating layer has four pillars: identity, permissions, context, and execution. First, agents must assume a first-class identity, inheriting least-privilege access through SSO and role-based policies. Second, permissions should be expressed as granular, auditable capabilities, not raw credentials. Third, context must be curated and versioned to steer agents reliably. Fourth, execution belongs in sandboxes with network egress controls, secrets isolation, and consistent observability. Tie all of that to policy evaluation so that actions are allowed or denied based on who the agent is, where it runs, and what the task entails.
Build vs Buy: An Operating-Layer Checklist
If you build: inventory your identity provider, RBAC model, secrets store, policy engine, curated context sources, execution sandboxes, and observability stack. Define capability-scoped connectors and ship evaluation harnesses for critical workflows. If you buy: require identity-bound actions (no shared API keys), granular permissioning, isolated runtimes with egress controls, policy-as-code, replayable audit logs, and native support for versioned context. In both cases, insist on owner assignment, handover rules, and cost controls so teams can forecast and contain agent spend.